Rpmsg buffer size on TorizonOS

I developed an application on Verdin iMX8M-Plus that uses rpmsg to communicate between Torizon OS and FreeRTOS.
Everything works fine and I’m able to communicate.
In FreeRTOS I see that rpmsg uses buffers of 512 bytes, and if I look to the address of the messages sent and received I see that it increments of 512 at every message.
So this is ok.
Moreover, I’m able to send messages with a paypload of 496 (they require 512 bytes) from FreeRTOS to Torizon Os, where I have a python application that receives them properly. No issue here.

But if I write a message of 300 bytes from python to /dev/ttyRPMSG30 on Torizon OS, I see that this message is automatically split into two different messages: the first is 256 bytes long, and the other 44 bytes long.
On FreeRTOS side, I see both of them and I can merge them into the original message.
I did several test, and I see that the message is automatically split into chunks of 256 bytes (even if the mailbox is 512).
Do you know why this happens?
Is this the Torizon OS rpmsg_tty driver?
Or python?
Or some rpmsg configuration?

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


The behavior you’re observing, where messages larger than 256 bytes are being split into multiple messages, is related to the rpmsg_tty driver’s handling of message sizes in the Linux kernel used by TorizonCore. The rpmsg framework, which facilitates communication between Linux (running on the A core) and FreeRTOS (running on the M core), has its own set of constraints and configurations that can affect how data is transmitted and received.

The rpmsg_lite implementation used in FreeRTOS is designed to work with the default buffer size of 512 bytes, as you’ve noted. However, the splitting of messages into 256-byte chunks when sending from Torizon OS to FreeRTOS suggests that there’s a limitation or configuration within the rpmsg_tty driver or the underlying rpmsg implementation that caps the maximum message size that can be sent in a single transaction to 256 bytes.

This behavior is not directly related to Python or any specific application-level code running on Torizon OS. Instead, it’s more likely tied to the way the rpmsg subsystem or the rpmsg_tty driver itself handles message segmentation and transmission. The rpmsg protocol requires that both the sender and receiver agree on the maximum message size. If the sender attempts to send a message larger than this agreed size, the message will be segmented into smaller chunks that fit within the maximum size limit.

To address this issue, you might consider the following approaches:

  1. Check the rpmsg_tty Driver Configuration: Review the source code of the rpmsg_tty driver in the Linux kernel used by TorizonCore to see if there are any configurable parameters related to maximum message size or segmentation behavior.

  2. Adjust Application Logic: Since you’re able to successfully reassemble the messages on the FreeRTOS side, you might continue using this approach as a workaround. Ensure your application logic on both sides can handle message segmentation and reassembly correctly.

  3. Review rpmsg Documentation: Although direct modifications to the rpmsg or rpmsg_tty driver code are beyond the scope of this support, reviewing the documentation and source code for these components might provide further insights into their behavior and any potential configuration options.

  4. Kernel Configuration: It’s also worth checking if there are kernel configuration options related to rpmsg that might influence message size limits or segmentation behavior.

Understanding the exact cause of this behavior requires a deeper dive into the `rpmsg

Please, also check if these links can help you solve your problem:

Cortex-M RPMsg Guide | Toradex Developer Center.

Hello @vix,

As you imagined, this limitation is related to the imx_rpmsg_tty driver.
You can see here that RPMSG_MAX_SIZE is defined as 256 and this seems to be the code that does the message splitting.

To change this behavior, the driver needs to be modified.

Best Regards,

Hi @bruno.tx
as far as I can see there is a mismatch on NXP software for rpmsg between cortex-A (buffer size 256) and cortex-M (buffer size 496).
Toradex uses the NXP values without any change.
I think that NXP should fix it (and afterwards, Toradex can update it).
I reported this to NXP tech support and I’ve been waiting for their answer.

1 Like