RPMSG on Verdin IMX8MP - Linux Side Working, M7 Side Not

Technical Support
, ,
1

Hello,

I’ve been trying to get the RPMSG echo demo up and running on my verdin imx8m-plus running Torizon 7.2.0. I have the Linux side running fine (as far as I can tell), but the M7 side doesn’t appear to be receiving the messages.

On the Linux side, this is what I’m seeing as I run it:

After running sudo modprobe imx_rpmsg_tty, this is the response to dmesg | grep -i rpmsg

[    6.840519] virtio_rpmsg_bus virtio0: creating channel rpmsg-virtual-tty-channel-1 addr 0x1e
[    6.841270] virtio_rpmsg_bus virtio0: rpmsg host is online
[   61.115581] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: new channel: 0x400 -> 0x1e!
[   61.115767] Install rpmsg tty driver!
[   61.120874] rpmsg_tty_cb68 65 6c 6c 6f 20 77 6f 72 6c 64 21              hello world!

And in response to ls /dev/ | grep -i rpmsg:

rpmsg_ctrl0
ttyRPMSG30

Although the linux output says that the demo is running and the message has sent, the only output I’m getting on the m7 terminal is

RPMSG String Echo FreRTOS RTOS API Demo...

With no further output afterward.

I’d appreciate any advice or suggestions for next steps as I try to get this working on my device.

Thanks!
Andrew

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 Andrew,

Thank you for your detailed description. What you’re seeing is a known issue on Torizon OS 7.x for the Verdin iMX8M Plus—the Cortex-M7 core outputs its initial message but can’t complete the RPMsg initialization, causing no further exchange over RPMsg.

Resolution Steps
To make RPMsg work properly on Torizon OS 7.x, you need to adjust the kernel arguments to prevent Linux from interfering with the M-core during boot. Specifically:

  1. Enable the HMP Device Tree Overlay
    Make sure the appropriate HMP (Heterogeneous Multi-Processing) device tree overlay is enabled. Reference: Device Tree Modifications for RPMsg.

  2. Add Required Kernel Command Line Arguments
    You must add the following kernel argument to your device’s boot configuration:

    firmware.class.path=/var/volatile

    This argument prevents Linux from rewriting or disturbing the Cortex-M firmware during boot, which resolves the RPMsg issue.

    How to add the kernel argument:

    • Edit /etc/default/grub (if using GRUB) or the kernel arguments via your preferred bootloader method.
    • Append firmware.class.path=/var/volatile to the GRUB_CMDLINE_LINUX or the relevant variable for your bootloader.
    • Update your bootloader configuration (for example, run update-grub after editing /etc/default/grub if you use GRUB).
    • Reboot the device.

You can see further discussion and confirmation of this workaround here: Known Issue and Kernel Argument Details.

Alternative Workarounds
If you wish not to adjust kernel arguments now, you can also temporarily use either:

Let me know if you’d like specific steps for either workaround or further explanation!

Best regards,
Toradex AI Assistant.

3

In response to the AI suggestions:

I have the device tree overlay enabled. Here’s the output when I cat the overlays.txt file:

fdt_overlays=verdin-imx8mp_hdmi_overlay.dtbo verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo verdin-imx8mp_hmp_overlay.dtbo

I’ve got the HMP overlay enabled.

As for the kernel arguments, I had already worked through the solutions recommended in that case. I have the clk-imx8mp.mcore_booted=1 argument enabled as per the directions in the RemoteProc Tutorial, which is what allowed the creation of the ttyRPMSG30 port in the first place. As far as I can tell, this is the equivalent U-Boot solution to the AI suggested solution for GRUB.

4

Hello @aweaver,

From your outputs, the demo is working fine, the code on M7 is still running. What is happening is that your UART stopped to show the messages from M7 while the core is running.

I suspect this is because you have a Wi-Fi/BT module, is this correct? In this case, the Wi-Fi hardware uses the same UART as the cortex-M7 to communicate with the SoC, therefore once you boot Linux this UART is now owned by the Wi-Fi/BT driver and you cannot see the messages anymore.

You can do a quick test to overcome this: select the ‘nonwifi’ device tree on U-Boot, for example:

# setenv fdtfile imx8mp-verdin-nonwifi-dev.dtb
# saveenv
# reset

If you do that in U-Boot’s terminal, this will load a device tree where the Wi-Fi is not probed and the UART will be available for the M7. You could also blacklist the driver in the kernel instead, this should work as well.

The UART from Cortex-M7 usually is for debugging purposes only, so if you are not using Wi-Fi or Bluetooth now you could select the nonwifi device tree just to see the RPMsg messages, however for a final application you can keep the correct device tree and the M7 would still be running. You can probably check this with the remoteproc driver from the kernel.

Hope this helps.

Regards,
Hiago.

5

Hi @hfranco.tx ,

Thank you so much for the help! This worked for me, I now see the output on the m7 UART.

Thanks,
Andrew

1 Like