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

Technical Support
, , ,
8

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello and thank you for providing your dmesg log and confirming the memory range alignment!

Let’s address your questions step by step:

1. Does dmesg show any driver/overlay errors?

From reviewing the dmesg output, here are some key observations:

  • The overlay colibri-imx8x_hmp_overlay is applied successfully, as seen in:
    [    1.807057] OF: overlay: overlay #0 is applied
  • Reserved memory for vdevbuffer is defined:
    [    0.000000] Reserved memory: created CMA memory pool at 0x98000000, size 32 MiB
[    0.000000] Reserved memory: created CMA memory pool at 0x90000000, size 8 MiB
...
[    0.039701] vdevbuffer: reserved memory at 0x0000000090000000, size 8 MiB, compatible device
  • The error you cited:
    [   25.450720] platform 90000000.rpmsg: deferred probe pending
  • There do not appear to be memory overlap errors or device tree application errors in dmesg.

2. What does “deferred probe pending” mean here?

  • Yes, 90000000 refers to the base address of the reserved vdevbuffer region.
  • Deferred probe means the driver is waiting for a dependency that is not yet available in the system. Common reasons are:
    • The remote processor (e.g., M4 core) is not running or not ready when Linux tries to probe rpmsg.
    • The memory region is correctly allocated, but the RPMSG endpoints are not initialized on the remote side.
    • Another hardware resource (such as a GPIO, clock, or power domain) is not ready.

3. What do you need to check next?

  1. Is the M4 firmware started and running before Linux probes rpmsg?

    • You mentioned firmware outputs rpmsg_lite starting remote link.... However, if Linux boots too quickly after launching the M4 core, the M4 may not have initialized its endpoints yet.
    • If the M4 UART is shared with Linux, you might miss critical logs.

  2. Try delaying Linux boot

    • Consider inserting a brief delay between starting the M4 core and booting Linux, ensuring the M4-side RPMSG stack is fully initialized and waiting for a Linux peer.

  3. Verify M4-side endpoint initialization

    • The remote firmware must initialize and announce RPMSG endpoints before the Linux driver completes probe. Missing or late initialization on the M4 side is a common cause of “deferred probe pending.”

  4. Typical dmesg output (in a working case)

    • In a healthy setup, you should see after your current dmesg lines:
      imx-rpmsg 90000000.rpmsg0: assigned reserved memory node vdevbuffer
virtio_rpmsg_bus virtio0: rpmsg host is online
    • These are missing, supporting the theory the kernel is waiting for remote endpoints that haven’t appeared yet.

Summary

  • There are no errors regarding memory reservation or overlay application in your dmesg.
  • The deferred probe pending suggests a remote-side (M4) initialization timing issue or dependency, not a Linux or overlay setup problem.
  • The 90000000 does correspond to your vdevbuffer, as expected.

Next Suggestions

  • Ensure your M4 firmware is fully running and endpoints set up before Linux boots. If possible, instrument your M4 firmware with blinking LEDs or an independent UART to confirm endpoint initialization.
  • You can find more details on similar issues here: RPMSG on a Toradex Apalis iMX8.
  • More background on deferred probe: deferred probe pending - community case.

If you can time or guarantee the remote core is ready before Linux boots, the deferred probe should resolve.

Best regards,
Toradex AI Assistant.