Linux CMA issue when booting iMX8MP 1.1B with M7 core enabled

Technical Support
, , ,
1

Good evening,

I am standing up a custom image for a proprietary board which uses the iMX8MP SOM. Because this is a follow-on from a number of previous projects, it uses Toradex BSP 5.4.129 and Yocto Dunfell 3.1. We are actively working on standing up a development pipeline for Scarthgap and the updated BSP/kernel, but felt the path of least resistance for our initial board bringup was to build off of the existing image.

For this specific board, we are running an application on the M7 core which controls a number of GPIOs, does some memory accesses (system time and others), and communicates with Linux through RPMsg. In order to get everything booted and functioning, we converted the verdin-imx8mp_hmp_overlay.dts into a .dtsi file and made adjustments to some of the other device tree nodes with a combination of .dtsi files and .patch files.

Everything appears to be working fine when the image is installed on a Verdin iMX8MP 1.1A SOM. However, the exact same image does not boot the same way on a 1.1B SOM, which is what we plan to use in the production system. Specifically, “linux,cma” has a memory allocation error very early in the boot process. 1.1B dmesg is shown on the left, and 1.1A on the right:

image
image1796×189 24.6 KB

Because of this, the Linux-side /sys/bus and /dev interfaces to the realtime core and rpmsg are missing once Linux boots, and our applications are not able to start.

Please advise on any recommended paths to debug this. I was not able to find a changelog for 1.1A → 1.1B, but if it’s as simple as adjusting memory ranges then I believe that’s the only number I need.

Thank you!

2

Hi, I’m the Toradex AI Assistant.

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? :+1: :-1:

CMA Memory Allocation Issue Between V1.1A and V1.1B

The issue you’re experiencing is related to the Contiguous Memory Allocator (CMA) configuration differences between hardware revisions. The CMA is critical for RPMsg communication between the Cortex-A53 and Cortex-M7 cores(1).

Understanding CMA Configuration

CMA works by reserving a large memory area at boot time for hardware blocks that access memory directly using physical addresses, such as DMA controllers or companion CPUs in heterogeneous multicore processing (HMP) environments(1). The Cortex-M controllers in the iMX8MP require this for proper operation(1).

Memory Buffer Requirements for RPMsg

For RPMsg to work properly, specific RAM buffers must be allocated in the device tree(2). The memory addresses used are critical and must match what the M7 firmware expects(2).

The typical memory configuration for Verdin iMX8M Mini (which shares similar architecture) includes these addresses(2):

vdev0vring0: vdev0vring0@b8000000 {
    reg = <0 0xb8000000 0 0x8000>;
    no-map;
};

vdev0vring1: vdev0vring1@b8008000 {
    reg = <0 0xb8008000 0 0x8000>;
    no-map;
};

rsc_table: rsc_table@b80ff000 {
    reg = <0 0xb80ff000 0 0x1000>;
    no-map;
};

vdevbuffer: vdevbuffer@b8400000 {
    compatible = "shared-dma-pool";
    reg = <0 0xb8400000 0 0x100000>;
    no-map;
};

(2)

Troubleshooting Steps

  1. Check CMA Size Configuration: The default CMA size for Verdin iMX8M Plus is max(256MB or 25% of DDR size)(1). Hardware revisions may have different memory layouts requiring adjustment.

  2. Verify Memory Ranges: Compare the memory addresses in your device tree with the addresses expected by your M7 firmware. The addresses must match exactly between Linux and M7 sides(2).

  3. Adjust CMA Size: You can modify CMA size through three methods (device tree overrules kernel cmdline, which overrules kernel configuration)(1):

    • Device Tree: Add a /reserved-memory/linux,cma node(1)
    • Kernel Command Line: Use cma=256MB parameter(1)
    • Kernel Configuration: Set CONFIG_CMA_SIZE_MBYTES(1)

  4. Check for Memory Conflicts: Ensure your reserved memory regions don’t conflict with the hardware revision’s memory map.

Recommended Debugging Approach

  1. Check the CMA reserved size in your running kernel(1):

    # dmesg | grep cma

    (1)

  2. Compare the memory layout between V1.1A and V1.1B by examining the full device tree and memory allocation.

  3. Consider using the pre-compiled HMP overlay (verdin-imx8mp_hmp_overlay.dtbo) from the BSP instead of your custom .dtsi conversion, as it’s tested for compatibility(2).

The memory allocation error suggests that the reserved memory regions in your device tree are conflicting with the actual memory layout of the V1.1B hardware revision. You’ll need to adjust the memory addresses or CMA size to accommodate the hardware differences.

Best regards, Toradex AI Assistant.

3

Hi,

I have been looking at changes in a similar area.
I would check the reserved memory configuration in your device tree as you may have some that are overlapping.
The imx8mp.dtsi reserves 960MiB if I recall, but the imx8mp-verdin.dtsi changes that to delete some of the defined reservations.

Might be worth double checking those as a starting point?

Regards,
Izzy

4

@sarrasmi Unfortunately you haven’t specify which variant of the Verdin iMX8MP 1.1A/B modules do you have . I assume it’s either 0058 Verdin iMX8M Plus Quad 4GB WB IT or 0063 Verdin iMX8M Plus Quad 4GB IT. In both cases the V1.B has the RAM part Micron MT53E1G32D2FW-046 IT:A been replaced with the Micron MT53E1G32D2FW-046 IT:B.
The RAM part Micron MT53E1G32D2FW-046 IT:A has been replaced with the Micron MT53E1G32D2FW-046 IT:B.
The Replacement Product is supported in BSP 6 from the 6.2.0 Quarterly Release onwards. The Replacement Product is supported in BSP 5 from the 5.7.4 Maintenance Release onwards. When using the Replacement Product with any older BSP release, the product will not function properly.