imx6sx M4 - enabling/hard reset from linux

[mtx512]

I want to get clarification on the enabling/resetting the M4  because its not documented in the reference manual. From what I understand the following bits can cause the M4 to reset using the SCR (20D8000h) register

bit 3 - m4c_rst : M4 core reset

bit 4 - m4c_non_sclr_rst - Non-self-clearing SW reset for M4 core

bit 12 - m4p_rst : M4 platform reset

If the M4 isn't enabled from uboot via a bootaux, should it be possible to enable and reset the M4 (ie using bit 4 or bits 3+12) from a Linux application? From my testing with kernel 3.14:

1. enabling the M4 (bit 22) + resetting using bit 3+12 has no effect

2. enabling the M4 (bit 22) + resetting using bit 4 causes the kernel to hang.

As side note I would also like to point out the M4 is poorly documented as the reference manual no has description on what the M4 does when a reset occurs. From the code examples it seems to jump to address 0x007F8000 where it expects a Vector Table to exist?

[mtx512]

Hi Alejanro,

Unfortunately I think don't you took time too fully understand my query and seem to have responded with example code rather than actually responding to the questions raised. I have  implemented something similar to your example (which I presume is for bare metal) as a kernel driver and a simple linux application (using mmap). From my testing with the kernel 3.14:

1. copying to TCM causes a kernel hang
2. releasing the M4 reset "writel(readl(SRC_SCR) & ~(1<<4), SRC_SCR);" causes a kernel hang

As a starting point could you reply to the questions in the initial email?

Many thanks

[alejandrolozan1]

Hi,

If the M4 isn't enabled from uboot via a bootaux, should it be possible to enable and reset the M4 (ie using bit 4 or bits 3+12) from a Linux application?

This for sure can be done from Linux, but as far as I know it is not implemented.

You can develop a driver to achieve that.

As side note I would also like to point out the M4 is poorly documented as the reference manual no has description on what the M4 does when a reset occurs. From the code examples it seems to jump to address 0x007F8000 where it expects a Vector Table to exist?

The 0x007f8000 is a fixed memory where the vector table is looked for by the the CM4 when booting.

There is foudnd the initial SP and PC at vector 0 and vector 1 respectively.  Make sure that the clock is enabled before copying the TCM

/* M4 Clock On */

    writel(readl(CCM_CCGR3) | (0x3<<2), CCM_CCGR3);

/Alejandro

[mtx512]

Hi,

As stated in my initial post I've tried implementing this as a kernel driver on 3.14 :

1. copying to TCM causes a kernel hang
2. releasing the M4 reset "writel(readl(SRC_SCR) & ~(1<<4), SRC_SCR);

Can this be tested by team? Furthermore after reviewing the 3.14 kernel source, there are a number of places in the code (while the kernel boots) where detection of a running M4 is used as a trigger for setting sharing of clocks, memory and power management. If I try to start the M4 after the kernel has booted then the kernel is unaware of this and that set-up won't occur. Therefore I'm not convinced the kernel can handle the enabling of the M4 after it boots because it can't keep track of it's state?

[alejandrolozan1]

Hi,

This is code from one of my peers  that enable the CM4

void m4_run_bin(unsigned char *bin, size_t size)

{

    /* M4 access for all peripherals on the bus */

    writel(0x77777777,  AIPS1_ON_BASE_ADDR );

    writel(0x77777777,  AIPS2_ON_BASE_ADDR );

    writel(0x77777777,  AIPS3_ON_BASE_ADDR );

    /* M4 Clock On */

    writel(readl(CCM_CCGR3) | (0x3<<2), CCM_CCGR3);

    memcpy(TCM, bin, size);

    /* Enable M4 and Assert the soft reset */

    writel(readl(SRC_SCR) | (1<<22) | (1<<4), SRC_SCR);

    /* Release the reset for M4 */

    writel(readl(SRC_SCR) & ~(1<<4), SRC_SCR);

}

You have to make sure in the CA9 that the clock of the M4 is enabled too.

The 0x007f8000 is a fixed memory where the vector table is looked for by the the CM4 when booting.

Best Regards,

Alejandro