RPMSG - Getting started developing for the Torizon Side

Technical Support
, , , ,
1

Hello,

I’ve been working on integrating RPMSG into my Verdin IMX8M-plus project, and have it all set up on the M7 side. However, I’m not quite sure where to start in developing for the Linux side on the A-cores. Are there any guides or documentation that you would recommend, or any examples that I should look at?

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,

Great to hear you have RPMsg set up on the M7 core! For the Linux (A-core) side, you can get started by using the RPMsg TTY interface, which allows user-space applications to communicate with the M7 via a standard TTY device.

Here’s how you can get started:

  1. Load RPMsg TTY Module:

    sudo modprobe imx_rpmsg_tty

  2. Verify Driver Status:

    dmesg | grep -i rpmsg

    This will help confirm that the driver loaded and initialized correctly.

  3. Check for RPMsg Device Nodes:

    ls /dev/ | grep -i rpmsg

    You should see devices such as rpmsg_ctrl0 and ttyRPMSG30.

  4. Communicate via TTY Device:
    You can use standard file operations to communicate:

    echo 'YourMessage' > /dev/ttyRPMSG30

    And you can read responses using:

    cat /dev/ttyRPMSG30

For detailed instructions and a complete working example, please refer to the official documentation:

Additionally, the MCUXpresso SDK provides an application example for RPMsg TTY. On the Linux side, interacting with /dev/ttyRPMSG30 with standard file operations is usually sufficient.

For persistent setup, you can configure Linux to load the imx_rpmsg_tty kernel module automatically at boot as described here:

If you have more specific questions or issues while developing your Linux-side application, please let me know!

Best regards, Toradex AI Assistant.

3

I hadn’t thought of just communicating using the tty device module, I’ll look into that and see if it fits my needs.

4

Please check this article.

5

Hi @alex.tx

Sorry for the delayed reply, I got wrapped up in other projects.

I’ve already worked through the solutions put forward in that article when I got the FreeRTOS RPMSG examples working using Torizon’s supplied drivers. What I’m looking for here is a way to have a containerized Linux/docker application communicate over that framework, which I don’t see any examples or instructions for in that article.

Due to the amount and type of data that we would like to share between the cores, we were looking for a way to send numerical data back and forth without having to parse it out of a string. However, after taking some time to dig into the source code for Torizon’s RPMSG drivers as well as the functionality and scope of docker containers, I don’t see a way for this kind of data sharing to occur without the use of the tty port.

Because we’re looking for something more customized and less sandboxed than the docker containers, would you recommend we look into building our own embedded distribution through the Yocto project using one of Toradex’s BSPs as a reference to see if that fits our needs better?

Regards,
Andrew

6

It’s hard to say up front if a custom Yocto build will give you a better outcome — without knowing your full requirements , it’s difficult to recommend one path over another.

However, you should know that Docker containers (such as those used in Torizon) incur very little runtime performance overhead outside of some extra RAM usage.

CPU and I/O overhead are minimal in most use cases. So unless you’re severely constrained on RAM or require microsecond-level response, switching to a Yocto-build is unlikely to yield significant performance gains, and would require considerable developer effort to maintain.

7

Hi @aweaver ,

Which way did you choose to move forward with?

Can we set this ticket as closed?

Best regards,

8

After bouncing back and forth between the two, I’m currently leaning toward Torizon after getting a few more things up and running with it, I think I’ll be able to get the communication going between the cores with what we’ve got. I’ll likely look into using yocto to generate an sdk for Torizon, then use that sdk to do either rpmsg or just plain shared memory on the A-cores. I’m fine setting this ticket to closed.

Regards,
Andrew