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

Technical Support
, , ,
1

This is almost identical to (this)[/dev/ttyRPMSG30 not created in Torizon OS 7 on Verdin iMX8M-Plus] but on different soc.

Well, I did not have it running on OS6 - I’m coming from a Yocto build.

I have manually added colibri-imx8x_hmp_overlay.dtbo to my /sysroot/boot/ostree/torizon-*/dtb/overlays.txt.
$ cat /proc/device-tree/chosen/overlays/colibri-imx8x_hmp_overlay
returns 0.

I load and run our firmware using U-Boot. I am sure this starts running since I see it’s output on a UART rpmsg_lite starting remote link...

Then I boot Linux from UBoot with boot

In Linux, $ dmesg | grep -i rpmsg gives

[    0.047279] imx rpmsg driver is registered.
[   25.450720] platform 90000000.rpmsg: deferred probe pending

I run sudo modprobe imx_rpmsg_tty and can confirm this with lsmod | grep -i rpmsg which gives imx_rpmsg_tty 16384 0.

But ls /dev/ | grep -i rpms gives me nothing.

I should also expect another message from my UART, confirming that rpmsg_lite_is_link_up(), but I see nothing, although this UART is being shared with the UBoot/Linux one, which could explain why I see nothing.

Still, I think the RPMsg should be initialised in Linux.

Does that deferred probe pending mean something ?
Did I miss some step ? :wink:

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.

3

( the colibri-imx8x_dsihdmi_overlay.dtbo was a typo, which I’ve corrected in the original)

4

So I’m thinking that there’s some issue with the overlay. The vdevbuffer seems to be allocated okay, though I’m not sure about the address used in the overlay.

dmesg.txt (38.9 KB)

5

Looks like the Official Overlays link came out wrong.
Can you direct me to the source code for the toradex colibri-imx8x_hmp_overlay ?

6

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:

Certainly! You can find the source code for the official Colibri iMX8X HMP overlay in the Toradex Device Tree Overlays repository.

Here’s how to access it:

  1. Clone the overlays repository:
git clone -b <branch> git://git.toradex.com/device-tree-overlays.git
cd device-tree-overlays/overlays
  • Replace <branch> with the version matching your BSP/Torizon release (for TorizonCore 7, typically toradex_5.15-2.0.x).
  1. Look for the overlay source:
    The file should be named colibri-imx8x_hmp_overlay.dts.
    You can browse the list of overlays here and find getting started instructions here.

If you want to see overlays available for Colibri iMX8X, check the official list of pre-built overlays.

Once downloaded, you can review and compare the overlay against your current one—especially the reserved memory and node definitions for vdevbuffer.

Best regards,
Toradex AI Assistant.

Relevant links:

7

@ToradexAI

So, the memory ranges in the overlay and those reported in dmesg match up nicely. I would expect to see some error message in dmesg if a memory region was overlapping for example.

Can you see any errors in dmesg ?

Why does the Linux rpmsg driver report “platform 90000000.rpmsg: deferred probe pending” ?
Does the 90000000 indicate that it’s accessing the same memory range ?

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.

9

@ToradexAI

I can ensure the M4 code is running by starting it in U-Boot, before entering boot to boot Linux, but I get the same result. (I changed it to output to UARTB now so it doesn’t interfere with the U-Boot/Linux terminal).

Here’s my UBootLog.txt (3.3 KB)

I see [drm:drm_bridge_attach] *ERROR* failed to attach bridge. Could that be causing this issue ?

I suppose that it could be that starting the M4 from U-Boot manually before boot resets something, and that adding run m4boot_0; to bootcmd Linux boots too fast. But I see 25 seconds before deferred probe pending is issued…

10

@ToradexAI

here one solution was to set the fw_setenv tdxargs "clk-imx8mm.mcore_booted=1" as documented here.

Maybe this could be the solution in my case. However this variable has to be set to a device-depenent value - clk-imx8mm.mcore_booted is for the iMX8MM.

Do you know what the equivalent value would be for the iMX8QXP or iMX8X?

11

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! Great summary—you’re right that on some platforms, communication between the Cortex-A and Cortex-M (using rpmsg) requires the kernel to know the remote core (“mcore”) is booted, often signaled by a kernel parameter like clk-imx8mm.mcore_booted=1 or similar. This allows the required clocks/peripherals to be enabled for RPMsg communication to succeed.

For your Colibri iMX8X (i.MX8QXP), the name of this kernel argument is different. The i.MX8X uses clk-imx8qx.m4_booted=1.

You can set this variable using:

fw_setenv tdxargs "clk-imx8qx.m4_booted=1"

and make sure that in your U-Boot boot process, the tdxargs variable is present in the boot arguments passed to the kernel.

References:

Steps to try:

  1. Boot into U-Boot prompt.
  2. Set the environment variable as above.
  3. Save and reboot.

This instructs the Linux kernel that the M4 co-processor is already running, which should allow the RPMsg driver to proceed instead of deferring.

Important: For other SoCs, the kernel parameter string changes:

  • i.MX8M Mini: clk-imx8mm.mcore_booted=1
  • i.MX8QXP/i.MX8X: clk-imx8qx.m4_booted=1
  • i.MX7: clk-imx7d.m4_booted=1

If you continue to experience deferred probes, ensure your M4 firmware is running before Linux boots and double-check the overlay and reserved memory as discussed before.

Best regards,
Toradex AI Assistant.

Useful Links:

12

@ToradexAI

tdxargs=clk-imx8qx.m4_booted=1 did not help, but I notice that tdxargs is not mentioned anywhere in the U-Boot environment. So I think it is not being passed as an argument when booting the kernal.

Which U-Boot variable contains arguments passed to boot the Linux kernal ?

Where can I find the default U-Boot environment for the Verdin iMX8MM ?

13

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! Thank you for your follow-up questions.

1. Which U-Boot variable contains the arguments passed to boot the Linux kernel?

The kernel boot arguments are assembled within U-Boot using environment variables—primarily setupargs and tdxargs.
The final boot arguments are typically contained in the bootargs variable, which gets passed to the kernel during boot.

  • setupargs includes console and basic settings.
  • tdxargs is intended for extra kernel parameters, such as your clk-imx8qx.m4_booted=1.

You can view the environment with:

printenv

Reference:
Best practices with U-Boot environment variables
U-Boot variables

2. How are kernel parameters typically passed in Toradex U-Boot?

When booting, the kernel command line is assembled, often something like:

setenv bootargs "${defargs} ${setupargs} ${vidargs} ${tdxargs} ${othervars}"

You need to ensure tdxargs is incorporated into this assembly, either in your custom boot script or the built-in logic.

3. Where can I find the default U-Boot environment for the Verdin iMX8MM?

The default U-Boot environment is compiled into U-Boot and can be found in the source code:

  • include/env_default.h
  • Board-specific settings: include/configs/verdin-imx8mm.h (for Verdin iMX8M Mini) or colibri-imx8x.h / apalis-imx8x.h for other variants.

Reference:
Best practices with U-Boot environment variables - Sources for U-Boot environment variables

Action Steps

  • In U-Boot, ensure your tdxargs is being used:

    1. Run printenv.
    2. Look at how bootargs is composed.
    3. If tdxargs is not part of bootargs, you may need to append it. For example:
      setenv bootargs "${bootargs} ${tdxargs}"
saveenv
    4. If using OSTree or TorizonCore, confirm the overlay configuration if you update environment variables from Linux.

  • Persist changes
    Always run saveenv to store your changes across boots.

Tip:
The fw_env.config file should, in most cases, point to the appropriate device for environment changes (for Torizon installations use /dev/mmcblk2boot0 -0x2200 0x2000).

Reference:
Community: U-Boot env vars

Summary:

  • bootargs is the main variable passed to the kernel.
  • setupargs and tdxargs are important components—tdxargs is specifically for extra kernel arguments you want to append.
  • The default environment is described in U-Boot source files as above.

If you need further help with your environment, feel free to paste your current printenv output for review.

Best regards,
Toradex AI Assistant.

Helpful links:

14

I modified the U-Boot environment variables so now they are

tdxargs=clk-imx8qx.m4_booted=1
mmcargs=setenv bootargs ${tdxargs} console=${console},${baudrate} root=PARTUUID=${uuid} rootwait mmcdev=0
setup=setenv setupargs ${tdxargs} console=tty1 console=${console},${baudrate} consoleblank=0 earlycon

I presume that setup and/or mmcargs are run by the U-Boot binary.

Nevertheless, I still get

$ dmesg | grep -i rpmsg
[    0.047315] imx rpmsg driver is registered.
[   26.720341] platform 90000000.rpmsg: deferred probe pending

Perhaps it’s time to get someone to replicate my situation…

15

I forgot to add @ToradexAI to my previous post…

16

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 the update!

Your modification of the U-Boot environment is correct in placing the tdxargs (with clk-imx8qx.m4_booted=1) into the bootargs. However, whether this actually gets passed to the kernel depends on the commands used for booting (which typically use a variable like bootargs, setupargs, or mmcargs as assembled by the script).

Key points to double-check:

  1. Confirm Final Kernel Command Line
    After booting Linux, please run:

    cat /proc/cmdline

    and check that clk-imx8qx.m4_booted=1 appears.

    • If it does not appear, it means your updated U-Boot environment isn’t actually affecting the kernel arguments.
    • If it does appear, and you still get “deferred probe pending,” we know the kernel sees the flag but something else is blocking rpmsg initialization.

  2. Check U-Boot Boot Logic
    In Torizon OS and recent Toradex BSPs, the “bootcmd” variable often triggers a series of scripts (often bootcmd_mmc, or run setup, etc).

    • You can check this by running printenv in U-Boot and looking for bootcmd and related variables to see which chain is run.
    • In some setups, “setup” or “mmcargs” must be explicitly run before booting.

  3. Ensure Only One Bootargs Source
    Only one variable should be setting bootargs at boot. If multiple scripts set bootargs, or if bootargs is overwritten after your mmcargs, your changes to tdxargs might be ignored.

Reference for U-Boot variable handling:

What to do next:

  • Please post the output of cat /proc/cmdline after boot. This will confirm if your additional argument is passed to Linux.
  • If it does not show up, try setting bootargs directly as a test:
    setenv bootargs "clk-imx8qx.m4_booted=1 console=ttymxc0,115200 root=PARTUUID=... rootwait"
boot
    Replace console/PARTUUID as appropriate for your setup. This will help determine if your issue is simply variable inheritance/scoping in U-Boot.

If clk-imx8qx.m4_booted=1 is in the kernel cmdline and the issue persists, then the problem is likely with M4 firmware startup, timing, or the RPMSG endpoint, as previously described. If it’s not in the cmdline, refining the U-Boot environment is needed.

Let me know your /proc/cmdline output, and we can proceed from there.

Best regards,
Toradex AI Assistant.

Helpful link:

17

@ToradexAI

$ dmesg | grep -i rpmsg
[    0.047315] imx rpmsg driver is registered.
[   26.720341] platform 90000000.rpmsg: deferred probe pending
$ cat /proc/cmdline
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/224cdbac8951a0d7d26775855be6206fe5d85a0c6733f5fd165271015f4a5307/0 clk-imx8qx.m4_booted=1

So something else is blocking the rpmsg initialisation.

18

I guess adding @ToradexAI in a later edit to my post is not enough :slight_smile:

19

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 the output.

You are correct: your kernel command line shows clk-imx8qx.m4_booted=1 is being passed correctly, so kernel-side clock dependencies should not be blocking RPMsg. This points to another problem preventing the driver from progressing past the “deferred probe pending” state.

Here’s what you should check next:

1. Check M4 Firmware Output

  • You mentioned seeing rpmsg_lite starting remote link… on UARTB.
  • In a working setup, the M4 firmware should also print Link is up! and Nameservice announce sent.
  • If you do NOT see these extra messages, your M4 firmware may not be completing RPMsg initialization. (This is a common cause for the Linux rpmsg driver to keep deferring.)

Reference:

2. Verify Device Tree Status in Linux

  • Confirm your overlay is applied (already done, as shown in dmesg).
  • Confirm the reserved memory regions: dmesg shows vdevbuffer reserved at 0x90000000.
  • Do you see virtio_rpmsg_bus virtio0: rpmsg host is online in dmesg?
    This should appear when Linux successfully connects to the M4 endpoint.

3. Firmware Loaded and Running

  • When loading from U-Boot, make sure your M4 firmware is loaded to the correct address and is running before Linux boots.
  • It’s important that the firmware is not “stuck” or waiting for something that never happens—test with known-good reference firmware from NXP or Toradex if possible.
  • The firmware must finish its initialization, create the endpoint, and be ready for communication before Linux tries to bind the rpmsg device.

Reference:

4. Linux Driver Status

  • After running sudo modprobe imx_rpmsg_tty, check for new dmesg lines (dmesg | grep -i virtio).
  • Look for messages about virtio_rpmsg_bus. Absence typically means the remote endpoint (from M4) is not visible to Linux.

Summary & Next Steps

  • If you only see the M4 message rpmsg_lite starting remote link… and not “Link is up!” or “Nameservice announce sent.” then the M4 isn’t fully initializing the RPMsg link.
  • If dmesg never shows virtio_rpmsg_bus, it also indicates the host could not establish the link with the remote.
  • Please confirm:
    • The exact full output on UARTB from your M4 at boot.
    • The output of dmesg | grep -i virtio after modprobing imx_rpmsg_tty.

This will make it easier to determine if it’s an issue on the M4 firmware side or Linux.

Best regards,
Toradex AI Assistant.

Relevant links:

20

@ToradexAI

The M4 binary has been proven on the same hardware but with an older device tree and Yocto-based image (dunfell based) from late 2021.

Have there been any changes since then, for Torizon OS, that might require some change to the M4 source code or build environment ?