Colibri iMX8X Torizon OS 7.5.0 - M4 memory issues

Technical Support
, , ,
1

Hi there,

We are trying to make our M4 firmware partly run on DRR RAM as we run out of space in the TCM region. For that purpose, we modified the MIMX8QX6xxxxx_cm4_ram.ld file in order to use the m_data2 region (see file MIMX8QX6xxxxx_cm4_ram_data2.ld (6.9 KB)). Then, we applied the changes to the device tree which are described here ) so we came up with this overlay colibri-imx8x_hmp_overlay_patched.dts (1.9 KB).

The outcome when the firmware is run by using uboot is that Torizon is started and the m4 firmware is apparently started too, but the port /dev/ttyRPMSG30 is missing. The port is shown and RPMSG works when the standard MIMX8QX6xxxxx_cm_ram.ld linker file is used.

When using remoteproc, this is shown in dmesg, but the port is not there either.

[ 926.780537] remoteproc remoteproc0: powering up imx-rproc
[ 926.781626] remoteproc remoteproc0: Booting fw image TestRPMSG.elf, size 144040
[ 926.784284] rproc-virtio rproc-virtio.2.auto: assigned reserved memory node vdevbuffer@90400000
[ 926.895246] imx-rproc imx8x-cm4-0: imx_rproc_kick: failed (0, err:-62)
[ 926.901840] virtio_rpmsg_bus virtio2: rpmsg host is online
[ 926.901989] rproc-virtio rproc-virtio.2.auto: registered virtio2 (type 7)
[ 926.902031] rproc-virtio rproc-virtio.3.auto: assigned reserved memory node vdevbuffer@90400000
[ 927.005237] imx-rproc imx8x-cm4-0: imx_rproc_kick: failed (2, err:-62)
[ 927.011830] virtio_rpmsg_bus virtio3: rpmsg host is online
[ 927.011971] rproc-virtio rproc-virtio.3.auto: registered virtio3 (type 7)
[ 927.011991] remoteproc remoteproc0: remote processor imx-rproc is now up

This usage of m_data2 works smoothly on Yocto, so surely we are missing something… Any help would be appreciated.

Thanks in advance.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I’d be glad to help with your RPMsg issue on the Colibri iMX8X! To provide the most accurate guidance for your specific setup, could you let me know which version of Torizon OS you are running?

You can get detailed information about your system by running the tdx-info command on your device. For more information about this tool, please see: Getting Device Information with Tdx-Info | Toradex Developer Center

This will help me provide platform-specific guidance for resolving the /dev/ttyRPMSG30 device node issue when using the modified linker file with DDR RAM allocation.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hi @ToradexAI ,

This is the outcome of tdx-info command:

Software summary

Bootloader: U-Boot

Kernel version: 6.6.119-7.5.0-ge5c5595adb06 #1-Torizon SMP PREEMPT Mon Jan 5 09:23:13 UTC 2026
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/ddea0498aeac41b40db0f9a2bbcb5b405187e796bc466d49539cb34bdd5321aa/0 pd_ignore_unused
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.5.0-build.30
Distro variant: VARIANT=“Docker”
Hostname: colibri-imx8x-06996015

Hardware info

HW model: Toradex Colibri iMX8QXP on Colibri Evaluation Board V3

Toradex version: 0038 V1.0D
Serial number: 06996015
Processor arch: aarch64

Kind regards,

4

RPMsg Communication Issue with Modified M4 Memory Layout

Thank you for providing the system details. Based on your setup (Torizon OS 7.5.0 on Colibri iMX8QXP), the issue with the missing /dev/ttyRPMSG30 device when using DDR RAM for M4 firmware is likely related to memory region configuration in your device tree overlay.

Key Areas to Verify

1. Memory Region Alignment
The device tree overlay needs to properly reserve and configure the DDR memory regions that your modified linker script is using(1). Ensure your overlay correctly defines the memory regions that correspond to the m_data2 section in your linker file.

2. U-Boot Environment Variables
Since you mentioned the firmware works when started via U-Boot but RPMsg communication fails, verify that the U-Boot environment variables are properly configured(2). The fdtfile variable should point to your custom device tree that includes the overlay(2).

3. Device Tree Deployment
For Torizon OS, you can deploy your custom device tree overlay using TorizonCore Builder(1). The overlay needs to be properly integrated into the system image to ensure the memory reservations are active during boot.

Troubleshooting Steps

Check Memory Reservations:
Verify that your device tree overlay properly reserves the DDR memory regions used by your M4 firmware. The memory regions must be excluded from Linux’s memory management.

Validate RPMsg Configuration:
Ensure your overlay maintains the correct RPMsg channel configurations and that the virtual device buffer addresses align with your firmware’s expectations.

Compare Working vs Non-Working Configurations:
Since this works on Yocto, compare the effective device tree (using /proc/device-tree/ or dtc -I fs /sys/firmware/devicetree/base) between your working Yocto setup and the current Torizon configuration.

The error messages you’re seeing (imx_rproc_kick: failed) suggest communication issues between the A-core and M4 core, which often indicates memory layout mismatches between the device tree configuration and the actual firmware memory usage.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Hi @ToradexAI ,

Thanks for your prompt reply. We have already checked the general potential sources of the behaviour we observed, so it must be some detail what we are missing. A detailed review is required. If a human developer may have a look at this issue, it would be of help.

Kind regards.

6

Detailed Analysis of Your Colibri iMX8X RPMsg Issue

Thank you for the clarification. Let me provide a more detailed technical analysis of your specific issue with the modified M4 memory layout and RPMsg communication.

Memory Buffer Configuration Analysis

Based on the Cortex-M RPMsg documentation, the memory addresses for RPMsg communication are critical(1). For the iMX8M Mini example (which shares similar architecture principles with your iMX8QXP), the memory configuration should follow this pattern(1):

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;
};

(1)

Key Technical Points to Verify

1. Resource Table Location
When you modified your linker script to use m_data2 (DDR RAM), ensure the resource table location in your firmware matches what’s defined in your device tree overlay(1). The resource table is copied to both VDEV0_VRING_BASE and VDEV0_VRING_BASE + RESOURCE_TABLE_OFFSET(1).

2. Memory Region Conflicts
The imx_rproc_kick: failed errors suggest communication issues between cores(1). This often occurs when the memory regions defined in your device tree don’t align with the actual memory usage in your modified linker script.

3. Device Tree Overlay Status
According to the documentation, for Colibri iMX8X, the HMP overlay (colibri-imx8x_hmp_overlay.dts) is available in the toradex_6.6-2.2.x-imx branch(1). However, since you’re using Torizon OS 7.5.0, you should ensure your overlay is compatible with the kernel version (6.6.119).

Community Experience Reference

From community discussions, similar issues have been reported where RPMsg device nodes don’t appear after loading the imx_rpmsg_tty module(2). The typical resolution involves ensuring proper kernel configuration and device tree alignment.

Recommended Next Steps

Given the complexity of your specific memory layout modifications and the fact that this works on Yocto but not on Torizon OS, a detailed review by our engineering team would indeed be beneficial. The issue likely involves subtle differences in how Torizon OS handles the memory management compared to your Yocto setup.

For the most effective support, please continue this discussion on our Community Forum where our engineering team can provide more detailed assistance with your specific overlay and linker script modifications.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

7

Hi @vic!

As I’ve read in the README file, you must load the imx_rpmsg_tty kernel module. You can do it by running modprobe imx_rpmsg_tty.

That being said, I recommend asking on the NXP forums, since it seems to be something directly related to their firmware example. I’ve tested loading the hello_world firmware through both U-Boot and remoteproc, and it worked as expected. Unfortunately, I won’t be able to go deeper and test the RPMsg example.

I would also recommend testing on our BSP reference images, just to be sure that the issue is not connected with Torizon OS.

Best regards.

8

Hi @lucas_az.tx ,

Thanks for your reply. I am already running the imx_rpmsg_tty module.

When you say “I’ve tested loading the hello_world firmware through both U-Boot and remoteproc”, do you mean you have tested it using DDR RAM? Did you use my ld file? If not, which ld file did you use? Please, share the details.

May the issue be related to some Torizon device tree configuration? There are other threads in the forum that point out in that direction (see, e.g., this one).

Kind regards,

V