/dev/ttyRPMSG30 not created in Torizon OS 7 on Colibri iMX8QXP

Technical Support
, , ,
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! Thank you for your detailed description.

Let’s walk through the key points for getting RPMSG working on your Colibri iMX8X module with Torizon OS 7, especially when seeing the message: platform 90000000.rpmsg: deferred probe pending. This message does indeed indicate the driver is waiting on a dependency before initialization.

Here’s a focused checklist and specific points to double check:

  1. Device Tree Overlay Placement & Activation

    • Ensure colibri-imx8x_hmp_overlay.dtbo is placed in /boot/overlays/ (not only in the OSTree deployment path).
    • overlays.txt should reference only the filename, for example:
      colibri-imx8x_hmp_overlay.dtbo
    • After editing overlays.txt, make sure to run:
      sync
      then reboot (do not power cycle). More details here:
      Get started with device tree overlays

  2. Check Overlay is Applied

    • Run:
      sudo dmesg | grep -i overlay
    • And check for files in /proc/device-tree/chosen/overlays/ matching your .dtbo, not just colibri-imx8x_dsihdmi_overlay.dtbo.
    • If the overlay didn’t get applied, your kernel can’t instantiate the RPMSG device on that SoC.

  3. M4 Firmware Boot Timing

    • Your M4 firmware should be running before Linux kernel tries to initialize the imx_rpmsg_tty device. U-Boot launching firmware is correct, but sometimes the required memory region may be in use/conflict. Make sure firmware is entirely loaded and held in low-power state or running before Linux boots.

  4. RPMSG Initialization in Linux

    • In a working scenario, you should see messages like:
      [    X.XXXXX] imx rpmsg driver is registered.
[    X.XXXXX] imx-rpmsg 90000000.rpmsg0: assigned reserved memory node vdevbuffer
[    X.XXXXX] virtio_rpmsg_bus virtio0: rpmsg host is online
      If you only see “deferred probe pending”, Linux is waiting for a device or memory it can’t resolve yet (often the reserved memory assigned for RPMSG is missing from the device tree or the overlay didn’t load properly).

  5. Double-Check Device Tree Memory nodes

    • The Mali firmware and Linux RPMSG driver should both reference the correct reserved memory node (for buffer exchange), usually named “vdevbuffer”. If your overlay accidentally omits or misnames this memory node, the kernel driver’s probe will defer. Compare your overlay against official overlays.

  6. Kernel Module Status

    • It’s expected that imx_rpmsg_tty is loaded (lsmod output), but /dev/ttyRPMSGX appears only after the link is fully up and the device is present (see previous steps).

  7. M4 Serial Output

    • If the M4 UART output is shared with Linux/U-Boot, its output may be suppressed or overwritten; this is normal and not usually the root cause unless your firmware isn’t running.

Suggestions:

  • Re-copy your overlay to /boot/overlays, re-add it to /boot/overlays.txt, run sync, then reboot (not power cycle).
  • Compare your overlay and dmesg output with the Apalis iMX8 RPMSG example discussion to confirm the reserved memory and vdevbuffer nodes are present.
  • Check dmesg for memory reservation or overlay errors early in the boot log.
  • It may also help to use a minimal overlay that only adds the vdevbuffer and HMP, to debug in isolation.

If you do these steps and still get “deferred probe pending”, please share your full dmesg output related to overlays and the RPMSG driver for further analysis.

Best regards,
Toradex AI Assistant.