RPMsg device nodes not appearing in /dev after booting M7 and loading imx_rpmsg_tty on Verdin iMX8MP

Technical Support
, ,
1

Hello Team,
I’m working on enabling communication between Cortex-M7 and Cortex-A53 cores on the Verdin iMX8MP module using RPMsg.

Setup:

  • Booting M7 core via U-Boot using the following commands:(SD_BOOT)

setenv load_cmd “ext4load mmc 1:2”
setenv cm_image “/home/rpmsg_lite_pingpong_rtos_linux_remote.bin”
setenv cm_isize 20000
setenv load_cm_image “${load_cmd} ${loadaddr} ${cm_image}”
setenv cm_boot “${load_cm_image}; cp.b ${loadaddr} 0x7e0000 ${cm_isize}; dcache flush; mw.w 0x550ff000 0 64; bootaux 0x7e0000”
run cm_boot
43792 bytes read in 3 ms (13.9 MiB/s)

No elf image at address 0x007e0000

Starting auxiliary core stack = 0x20020000, pc = 0x000004DD…

  • DT Overlay passed: verdin-imx8mp_hmp_overlay.dtbo
  • Using the rpmsg_lite_pingpong_rtos_linux_remote example from the MCUXpresso SDK

Observations:

  • Kernel logs show that the RPMsg framework is initialized:
    dmesg | grep -i rpmsg
    [ 0.035695] imx rpmsg driver is registered.

I can see the modules are loaded:
lsmod
imx_rpmsg_pingpong 12288 0
imx_rpmsg_tty 16384 0

Problem: No /dev/rpmsg* or /dev/ttyRPMSG* nodes are created:

ls /dev/ | grep -i rpmsg

No output

Regards,
prem0919

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:

Hello Prem,

Thank you for the detailed explanation of your setup and the steps you’ve followed. Let’s go through a checklist and suggest possible solutions for the missing /dev/ttyRPMSG* device nodes:

1. Memory Address Configuration

Your U-Boot script loads the M7 firmware to 0x7e0000, which is consistent with the TCM (Tightly Coupled Memory) region typically used for the M7 core on Verdin iMX8MP. Please ensure that the resource table memory address (0x550ff000 in your script) matches the address specified in your device tree overlay (Reference: Device Tree Modifications).

2. Device Tree Overlay

  • Make sure that the verdin-imx8mp_hmp_overlay.dtbo sets the correct memory regions for RPMsg, VRING base addresses, and the resource table. Incorrect configuration here will prevent the Linux side from communicating with the M7 RPMsg instance.
  • Double-check that you are including the overlay in your extlinux configuration or via U-Boot variables.

3. Verifying M7 Firmware Execution

  • After booting, connect to the M7 debug UART (UART4 is typically the default).
  • Check for the output:
    RPMSG Ping-Pong FreeRTOS RTOS API Demo...
Link is up!
Nameservice announce sent.
    If you don’t see this, the firmware may not be running or initializing RPMsg correctly (Case Oriented Examples).

4. Kernel Module Loading

  • The standard order is to load the base rpmsg driver, e.g.:
    modprobe imx_rpmsg_tty
  • Check with dmesg | grep -i rpmsg for any warnings or error messages after loading the driver.

5. Linux Kernel Parameters (Preventing M-core Interruptions)

  • On recent Torizon OS or upstream kernels, you may need to add specific kernel command line arguments to prevent Linux from taking over the M7 core and interrupting its operation. Community reports have found that without this, devices like /dev/ttyRPMSG* are not created (Related Community Topic).

6. Additional Troubleshooting Steps

  • Confirm your image is NOT an ELF but a binary file. The “No elf image at address 0x007e0000” is not blocking, but ensure you use the correct file format.
  • Make sure you are not missing any mandatory systemd services or udev rules to create the /dev/ttyRPMSG* node.
  • Try rebuilding your MCUXpresso firmware example, and verify you’re using a version compatible with your Linux drivers and device tree overlay.

If all above items are confirmed and the problem persists, please check carefully for any mismatches between the addresses and configuration in the firmware, the device tree, and the Linux kernel.

Useful documentation for further details:

Would you like more specific guidance on checking the device tree or kernel arguments?

Best regards,
Toradex AI Assistant.

3

Hi @prem0919!

After you run run cm_boot, do you see any outputs in the Cortex M terminal?

Best regards.

4

Hi @lucas_az.tx ,
I’ve connected a USB-to-TTL (1.8V level) converter to the following SODIMM pins:

  • SODIMM 151 → UART4_TX (M7 RX)
  • SODIMM 153 → UART4_RX (M7 TX)
  • GND is also properly connected.

I’m running a Cortex-M7 firmware (e.g., hello_world.bin from MCUXpresso SDK), which is supposed to print messages over UART. However, I see no output on my terminal