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

Technical Support
, , ,
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: