m4 reload from linux fails

[evanthompson]

On an i.mx7d, I can't get reloading the m4 from linux to work. I'm trying the utility from this blog post:

New i.MX6SX & i.MX7D AMP debugging tool: imx-m4fwloader 

The problem is that swapping between 2 different m4 binaries does not work (reloading the same binary repeatedly does work). I'm using a stock sabre board and demo examples from the nxp bsp, so hopefully this will be easy to reproduce.

Setup to reproduce the issue:

i.mx7d sabre board with imx7d-sdb-m4 device tree

Copy these files to the sabre board:

m4fwloader binary from the above blog post

hello_world_ocram.bin example from nxp's FreeRTOS BSP

hello_world_2.bin, a second m4 binary that has one extra printf() call. Replace the hello_world main.c with the attached and rebuild hello_world_ocram. Rename the binary"hello_world_2.bin"

Boot linux and run these commands:

./m4fwloader /path/to/hello_world_2.bin 0x910000

./m4fwloader /path/to/hello_world_ocram.bin 0x910000

After the first command, the m4 starts, and the messages print to the terminal.

After the second command, the m4 will not start.

Original Attachment has been moved to: main.c.zip

[evanthompson]

For anyone who comes across this in the future - the problem was in register SRC_M4RCR (0x3039_000C), which is used to stop and start the m4. The m4fwloader program is leaving the ENABLE_M4 bit set while the new firmware is written, but it needs to be disabled - otherwise the currently-running application may attempt to write to the same memory area as the new firmware.

[dogisfat]

When ENABLE_M4 is set to "0" it seems like some of the memory doesn't get written. I am using the TCM for reference and I am guessing the ENABLE_M4 bit may disable the clock to that memory. Instead I am using the SW_M4C_NON_SCLR_RST (bit 0) to hold the M4 in reset while I do the programming. The reference manual and AN5317 BADLY need to be updated to reflect a proper programming cycle when the M4 is already running. In my case the M4 uses DDR (RPMSG and general memory). Occasionally without the M4 being held in reset it would crash BOTH the A7 cores and the M4 rendering the system completely dead.

[dry]

EDIT

I've re-checked it now, and the original imx-m4fwloader app as referred to,  the author was from NXP, also didn't fully follow ap note as recommended.

No full platform reset was issued, only core reset & hold (bit 0).

I kinda feel full platform reset is what one would want 

[art]

Try to do 'm4fwloader stop' first, then reload a binary then do 'm4fwloader start'.

Have a great day,
Artur

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[evanthompson]

Hi Artur,

Any further ideas on this issue?

Thanks,

Evan

[evanthompson]

Hi Artur,

Thanks for the response.

Running 'm4fwloader stop' and 'm4fwloader start' does not fix the problem. This is expected - if you look at the m4fwloader code, you will see that reloading a binary was already doing a stop and start.

Thanks,

Evan

[art]

mareknovak‌ , can you please help us here with your m4fwloader tool?

Thanks in advance.

Artur