i.MX8MP memory layout for Cortex M7 with DRAM 1GB We have a project where we use i.MX8MP with 1 GB DRAM. We adjusted Linker files for Cortex M7, Devicetree for RPMSG shared memory and DRAM reserved memory for Cortex M7. Starting rpmsg ping pong from U-Boot works, e.g. we are able to boot into linux, load the kernel module and see correct output. The memory map looks correct also for the m_data2 section which is in the configured space inside the 1GB DRAM Starting the same firmware (elf) from linux using remoteproc works but the demo hangs when waiting for rpmsg nameservice announce. Is there someting we miss when porting? Thank you Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB
Add run prepare_mcore before booting Linux
In U-Boot, before run bootcmd / run bsp_bootcmd, add:
run prepare_mcore
If they want this automatic, include it in the board boot command before Linux is launched.
Keep unused clocks enabled during debug
For bring-up, also add:
setenv mmcargs "${mmcargs} clk_ignore_unused"
saveenv
Some downstream BSPs use a more specific workaround such as clk-imx8mp.mcore_booted=1; Toradex notes that this prevents Linux from disabling the Cortex-M7 root clock on i.MX8MP.
Confirm the runtime DTB is the RPMsg-enabled DTB
For EVK, NXP support responses commonly point to using imx8mp-evk-rpmsg.dtb for M7 remoteproc/RPMsg. In i.MX8MP M7 remoteproc failure – “carveout doesn't fit da request” with valid NXP RPMsg firmware, the NXP support answer says to make sure imx8mp-evk-rpmsg.dtb is used in Linux. [community.nxp.com]
For a custom 1 GB board, the filenames will differ, but the important point is that the runtime DTB must include the imx8mp-cm7 remoteproc node, MU mailboxes, and all RPMsg reserved-memory nodes.
Verify reserved-memory and resource table alignment
For i.MX8MP, the common RPMsg layout uses regions such as:
dts isn’t fully supported. Syntax highlighting is based on Plain Text.
vdev0vring0: vdev0vring0@55000000 {
reg = <0 0x55000000 0 0x8000>;
no-map;
};
vdev0vring1: vdev0vring1@55008000 {
reg = <0 0x55008000 0 0x8000>;
no-map;
};
vdevbuffer: vdevbuffer@55400000 {
compatible = "shared-dma-pool";
reg = <0 0x55400000 0 0x100000>;
no-map;
};
rsc_table: rsc_table@550ff000 {
reg = <0 0x550ff000 0 0x1000>;
no-map;
};
A public Linux Remoteproc on i.MX8MP discussion shows this style of DT setup, including rsc-da = <0x55000000>, mboxes = <μ 0 1 μ 1 1 μ 3 1>, and memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>, .... [community.nxp.com]
For your 1 GB DRAM case, make sure none of these regions are inside Linux normal memory, CMA, GPU, OP-TEE, or another reserved range. Also verify that the M7 firmware’s rsc_table.c and linker file use the same vring/resource addresses as Linux DT.
For the 1 GB DRAM port, check the ELF program headers
Because Linux remoteproc loads the ELF by program headers, not just by “where U-Boot copied it,” verify:
readelf -l your_m7_firmware.elf
readelf -S your_m7_firmware.elf | grep -E "resource|data|bss|text"
Check that every loadable segment maps to an address Linux remoteproc can translate for i.MX8MP, and that your m_data2 region is inside the actual 1 GB DRAM range and matches the reserved-memory carveout.
Clear stale resource table area during debug
If testing repeated boot modes, clear the RPMsg resource table area before booting M7. The i.MX Linux User’s Guide says that for i.MX8M Plus LPDDR4 EVK, the resource table area can be cleared with:
mw 0x550ff000 0 4
This is specifically documented for avoiding garbage resource table values Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB As I wrote, the devicetree and linker file were adjusted. The remoteproc elf loader will load the file and start it. The ported hello world demo from MXUXSDK runs fine when started from Linux. The RPMSG demo is loaded and starts (we have valid output on M7 debug console) but rpmsg itself does not work. I suspect, there is anything incompatible with the MPU initialisation code for the M7. There are addresses above 1 GB in DRAM space for the 8MP EVK? Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB do you have an y error log to share？ it seems the rpmsg may not link with DRAM setting directly Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB Discussing with the AE team. Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB The binary file and elf file are generated on the same time, by the same code and linker file, oright?
"I suspect, there is anything incompatible with the MPU initialisation code for the M7. There are addresses above 1 GB in DRAM space for the 8MP EVK?"
- If everything on uboot is OK but linux rproc is not, then it seems not the issue of MPU.
I may first suspend the differences between uboot and linux rproc boot M. Please suggest customer check below two things:
1) imx_rproc.c imx_rproc_att_imx8mn has been modified according to your new DRAM size?
2) Make sure the section .resource_table is in a suitable position? Because Uboot load this table by copyResourceTable, but Linux parse the .resource_table section from .elf file.
Which demo they are using? can they provide all the patch of the modification, towards Linux and M7 SDK? And what isCan they share their log shows "The RPMSG demo is loaded and starts (we have valid output on M7 debug console) but rpmsg itself does not work"?
View full article
