As part of our feasibility tests and performance tests on the Verdinn imx8mm, we are now trying to use DDR instead of TCM to run a simply ‘Hello world’ application on the Core M side.
Unfortunately, we don’t know how to do it and we haven’t found much info on this topic.
We are able to launch the application from the eboot or linux side when using the TCM.
We tried to run an application compiled for DDRAM from Linux side without success.
Do you have a tutorial to help us?
Thank you for your help.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Running Hello World on Verdin iMX8M Mini Cortex-M4 Using DDR
Memory Configuration for DDR Execution
For the Verdin iMX8M Mini, the Cortex-M4 core can access DDR memory in addition to the TCM regions(1). The memory layout shows that DDR is accessible by the M4 core at address range 0x4000_0000-0xBFFF_FFFF(1).
The Verdin iMX8M Mini uses a modified Harvard architecture where the Cortex-M4 CPU has two buses connected to the main interconnect(1):
Code bus - for instruction fetching
System bus - for data fetching
For optimal performance, program code should be located in a region accessed through the code bus, while data should be in a region accessed through the system bus(1).
$ cd <verdin-imx8mm-sdk>/boards/
$ tree -L 2
.
└── evkmimx8mm
├── cmsis_driver_examples
├── demo_apps
├── driver_examples
├── evkmimx8mm.png
Modify the linker script to target DDR memory instead of TCM. You’ll need to configure the memory regions to use the DDR address space accessible by the M4 core (0x4000_0000-0xBFFF_FFFF)(1).
Important Considerations
Memory allocation in advance is required for the M4 core to use DDR memory(1)
The TCM regions provide zero wait-states and massively better performance than DRAM, even if cached(1)
When using DDR, ensure proper memory management between the Cortex-A53 cores running Linux and the Cortex-M4 core
The key difference when using DDR is ensuring your linker script targets the correct DDR memory regions accessible by the M4 core and that memory allocation is properly coordinated with the Linux system running on the A53 cores.
Running the Cortex-m firmware from the DDR is not directly supported via remoteproc.
It is technically possible to do so, but a small amount of code will need to run on the TCM to jump the Cortex-M to the DDR area.
Otherwise, running the firmware from the DDR can be done via u-boot.
To do that, the steps on the following page are mostly valid: How to Load Compiled Binaries into Cortex-M | Toradex Developer Center
When building the binary, please make sure to build the one for DDR, using the corresponding build_ddr_release.sh script from the MCU Xpresso SDK.
When setting up the firmware to be started from u-boot, the following commands can be used:
Ideally, you could also check that filesize is always smaller than the area of reserved memory defined in your device-tree overlay.
This should be enough to get the firmware running from u-boot.
The default device tree overlay for HMP has a region defined as reserved at 0x80000000.
If you need a larger region for a larger firmware, this would need to be modified in the device tree overlay.
Another detail to keep in mind is that the 0x80000000 address is valid for modules with 2 GB of RAM.
For modules with 1 GB of RAM, a different address and adjustments to the linker script from MCU Xpresso are needed.
Running the firmware from the DDR has performance impacts, therefore I recommend that you check if doing so is really needed for your use case.
That’s exactly what I did but it doesn’t work. I may have forgotten something.
We have a Toradex Verdin iMX8M Mini DualLite 1GB board, so I modified the linker script by changing the address 0x80000000 to 0x70000000 …
Verdin iMX8MM # run cm_boot_ddr
14980 bytes read in 3 ms (4.8 MiB/s)
## No elf image at address 0x70000000
## Starting auxiliary core stack = 0x70400000, pc = 0x700002FD...
With the two changes above, the firmware should work from u-boot.
However, to allow the Linux system to start, additional changes are needed.
These changes are to the device tree overlay, which needs to reserve a different area of memory and also setup the rpmsg areas in a different place:
Thank you @bruno.tx … It’s working with 0x77000000 as base address.
Why it’s not working with 0x70000000 as base address ?
What is the maximum size I can allocate to m4 core on verdin 1Gb ?
It is good to know that you got it working with 0x70000000 as well.
Any area on the DDR that is not used elsewhere should be usable for this.
The limit will depend on the DDR that needs to be allocated for the rest of the system.
For most use cases, not much storage should be needed for the firmware.
If large amounts of data need to be shared between Cortex-M and Cortex-A, this could be done in a separate region of reserved memory defined in the device tree overlay, not necessarily in a region which the firmware is loaded to.
Thanks @bruno.tx
It works fine when I launch the application from boot, I get a “hello world” message.
However, when I try to launch it from the Linux side, nothing is displayed and I don’t get any errors.
I only adapted the overlay and build the application with DDR config
As I mentioned previously, unfortunately the remoteproc driver cannot start a firmware on the DDR.
This is a known limitation of the driver.
While the driver does correctly load the firmware to the correct region on the DDR, it only starts the firmware from the TCM.
What you could do is to add an entry point your firmware on the TCM that jumps to the address where your actual code resides on the DDR.
This would require some customization on the MCU Xpresso SDK side.
Unfortunately no.
The generally recommended approach would be to load the firmware from u-boot, if you plan to have it on the DDR.
Do you have a strong requirement to start the firmware with remoteproc?
