Use remoteproc to start M7 core on Verdin iMX8M-Plus

Technical Support
, , , ,
22

Hello @vix,

While I could not reproduce the issue with the kernel panic when loading a Cortex-M7 firmware to DDR, I could confirm that remoteproc fails to start the Cortex-M7 in the correct address in such cases.

This use case is not currently supported.

Looking at the .elf files, the entry points are correct:

TCM:

$ readelf -h debug/hello_world.elf 
ELF Header:
...
  Entry point address:               0x48d
...

DDR:

$ readelf -h ddr_debug/hello_world.elf 
ELF Header:
...
  Entry point address:               0x8000048d
...

However, remoteproc always starts the Cortex-M7 core at the TCM address.

To test this, I did the following tests, rebooting the device each time:

Test 1:

  • Loaded TCM program
    • Output of TCM program is printed in the Cortex-M serial output
  • Loaded DDR program
    • Output of TCM program is printed in the Cortex-M serial output

Test 2:

  • Loaded DDR program
    • No output is printed in the Cortex-M serial output

I could also conclude that remoteproc is loading the DDR program in the correct location, by running the following test:

  • Loaded DDR program
    • No output is printed in the Cortex-M serial output
  • Loaded TCM program which jumps to the entry point of the DDR program at the end of execution
    • Output of TCM program is printed in the Cortex-M serial output, followed by the output of the DDR program.

Please note that this method may have unintended side effects, as remoteproc is no longer taking ownership of the memory used by the DDR program.

Do you need to dynamically load the Cortex-M7 firmware in your application?
Or do you intend to use remoteproc for development only?

If you intend to use it for development, would the above workaround work for you?

I understand that the firmware is too large to be stored exclusively on the TCM, but storing it on DDR will lead to a much lower performance, so please keep that in mind.

Best Regards,
Bruno

23

Hi @bruno.tx
thank you very much.
Your deep investigation confirm what I found an dmy thougths.
We need that NXP fixes this :frowning:

This is a loop:

  • I use u-boot to load the firmware, and it works
  • but every update of the firmware requires a new release of Torizon OS
  • and so Toradex told me “why you don’t use remoteproc + subsystem (or container)?”
  • I tried, but remoteproc doesn’t work
  • and Toradex told me “why you don’t use u-boot?” :sweat_smile:

I don’t know how much Toradex can do with this.
I suggest to improve the documentation, so that it’s clear for everyone.

EDIT:
In a private support ticket, NXP told me that they will not fix this in their linux-imx.
But the fix is already available upstream (see [PATCH V3 0/6] remoteproc: imx_rproc: support firmware in DDR (kernel.org)).
I think that this is another reason to have great expectations on the first mainline-based Torizon OS for iMX8M-Plus.
I look forward :slight_smile:

24

Hi @vix,

Sorry for the confusing advice.

Now, with a complete picture of the situation, the following should work to update the firmware on the Cortex-M7:

  • Load the Cortex-M7 firmware using u-boot, from the /var directory.
  • Use a subsystem update to update the firmware.bin file on the /var persistent user data.
  • As the final step of the subsystem update, trigger a reboot.

Please note that the secondary update should not be sent together with other updates, as it will run concurrently with OS or application updates, and the reboot is likely to cause it to fail.

Thanks for sharing this information.

Best Regards,
Bruno

25

One doubt from my side:
to load a .bin firmware from uboot, its size is necessary.
Should I set this to the size of the whole memory region (so thta it doesn’t change with a new firmware)?
Otherwise, I don’t know how to change the firmware size in uboot.

26

Hello @vix,

An approach of adding padding to the binary to keep it a constant size would be an alternative.

However, you could also set the firmware size as an u-boot variable, using fw-setenv from the subsystem update script.

Best Regards,
Bruno