Changing RPMsg Buffer Size

[kashyap_gada]

Dear All,

I'd like to thanks the team and community for being supportive. I hope each one of you is safe. I am using Toradex iMX7D EMMC Model. 

I've successfully implemented and tested RPMsg on imx7 with default size of 512. I get about 5 KBytes/Sec of transfer rate from M4 to A7 (Python Serial script) with the default settings. Anything beyond this creates buffer full warnings on Linux. I have a requirement of around 100KBytes/Sec.

As per my previous post at https://www.toradex.com/community/questions/43578/imx7-remoteproc-communication-speed.html?childToVi... and a reference to the following post https://www.toradex.com/community/questions/35761/how-to-change-the-size-of-rpmsg-buffer.html?childT...

I am trying to set RPMsg Buffer size to 8192 Bytes.

1. imx_rpmsg.c file location has changed to drivers/rpmsg/imx_rpmsg.c (different from 2nd post).

2. I changed the buffer size to 8192 at that file and compiled kernel, also rpmsg_core.h in FreeRTOS rpmsg buffer size is changed to 8192. Yet buffer size allocated by rpmsg on m4 side is 496 Bytes only.

3. Could I get a right method to change RPMsg Buffer Size?

4. Is the Buffer size right amount for 100KBytes/Sec Transfer Rate.?

Regards

[Swiss2]

Hi @pdubois , @dogisfat ,
Thank you both for your answers!
Looks like I am just having problems recompiling the rpmsg linux kernel module.
I am using the torizoncore builder provided by Toradex instead of building a custom linux image, which you probably weren't using.
Could you still share your Makefile or KConfig file that you used for this, if you still have them.

Thanks!

[pdubois]

Hello,

I used the makefile and kconfig provided for rpmsg driver. You can take a look at https://github.com/varigit/linux-imx/tree/imx_4.9.11_1.0.0_ga/drivers/rpmsg . I have never used the torizoncore builder so I can't help you.

[dogisfat]

When examining the RPMSG transport speed I found the biggest thing affecting performance was diagnostics printed in the kernel modules. Disabling these helped the most. Attached is the patch I *believe* is what we used to improve performance. You may need to review dmesg to ensure no other virtio/rpmsg logging is occurring.

[dogisfat]

Here are the patches, attachments aren't working:

https://pastebin.com/daUne427

https://pastebin.com/RctQ9Yfw

[igorpadykov]

Hi Kashyap

first one can try to rebuild all images from scratch, to verify that changes took effect.

Also one can try to debug it, use toradex sources

imx_rpmsg.c\rpmsg\drivers - linux-toradex.git - Linux kernel for Apalis and Colibri modules 

be aware of some restrictions:

#define RPMSG_NUM_BUFS        (512)
#define RPMSG_BUF_SIZE        (512)
#define RPMSG_BUFS_SPACE    (RPMSG_NUM_BUFS * RPMSG_BUF_SIZE)

rpmsg available memory defined in dts

imx7d-sdb-m4.dtsi\dts\boot\arm\arch - linux-toradex.git - Linux kernel for Apalis and Colibri module... 

Using Open Source Debugging Tools for Linux on i.MX Processors

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[kashyap_gada]

First one can try to rebuild all images from scratch, to verify that changes took effect.

I just did that yesterday, built a new Linux image, but it didn't make any difference.

Also one can try to debug it, use toradex sources

imx_rpmsg.c\rpmsg\drivers - linux-toradex.git - Linux kernel for Apalis and Colibri modules 

be aware of some restrictions:

#define RPMSG_NUM_BUFS        (512)
#define RPMSG_BUF_SIZE        (512)
#define RPMSG_BUFS_SPACE    (RPMSG_NUM_BUFS * RPMSG_BUF_SIZE)

Using Open Source Debugging Tools for Linux on i.MX Processors

I'll check out this. 

Regards

K

[kashyap_gada]

Is it possible to change RPMsg Buffer Size? If yes, how? Toradex says its NXP Implementation so only they can help.

[pdubois]

Have you changed the MAX_RPMSG_NUM_BUFS and MAX_RPMSG_BUF_SIZE in virtio_rpmsg_bus.c for memory allocation? However, that doesn't solve the problem. I suppose the RPMSG_BUFS_SPACE should be less or equal at the memory space reserved in device tree. I tried to set  MAX_RPMSG_NUM_BUFS to 128 and MAX_RPMSG_BUF_SIZE to 2048 to keep the same amount of memory than 512*512 but when I load imx_rpmsg_tty with modprobe the "hello word" message was not send. Of course, I have changed defines in the freertos libs and the m4 program was launch before. Does anyone have an idea?

[Swiss2]

Hi, sorry for jumping in this late, but I am finding myself right now in the same position as you, trying to go from 512x512 to 128x2048 and I'm facing same issues (hello world not sent). Did you manage to solve this issue in the end? Thanks in advance!

[pdubois]

Yes, I was able to change the buffer size and the buffer count. For linux, in the folder drivers/rpmsg/, change RPMSG_NUM_BUFS to 128 and RPMSG_BUF_SIZE to 2048 in the file imx_rpmsg.c. In the file virtio_rpmsg_bus.c, change MAX_RPMSG_NUM_BUFS to 128 and MAX_RPMSG_BUF_SIZE to 2048. Recompile your kernel.

For freeRtos, you have to modifiy the file rpmsg_default_config.h in \middleware\multicore\rpmsg_lite\lib\include. Set RL_BUFERR_PAYLOAD_SIZE to 2032 (you have to subtract the header size) and I also changed RL_BUFFER_COUNT to 64 (First, I tried to set to 128 but the driver didn't work, I found out you have to divide by 2 your buffer count. If I remember correctly, there are half the number of buffers in each direction).

Pay attention to the define RL_BUFERR_PAYLOAD_SIZE because it is also defined in rpmsg_config.h (\middleware\multicore\rpmsg_lite\template_application\)  

Make sure your rpmsg is enabled in your device tree.

If everythink is correct, you should have a log like that "virtio_rpmsg_bus virtio0: creating channel rpmsg-virtual-tty-channel-1 addr 0x1e"

I hope it will help you.

[dogisfat]

No only do you need to change the virtio_rpmsg_bus.c you'll also need to change the m4 code to have matching sizes and possibly modify the dts for the board if you are allocating more memory for the virtual queues. I don't remember which files in the m4 BSP need to change other than they live in the openamp implementation.