I am using rpmsg to communicate between a linux (A53) and a FreeRTOS (M4) on an imx8 through a rpsmg driver based on imx_rpmsg_tty.c.
M4 implementation is based on example rpmsg_lite_str_echo_rtos_imxcm4 with last SDK SDK_2.8.0_EVK-MIMX8MM
When established, the communication works well, sending and receiving is fine. But when I reload a FreeRTOS image on the M4 side…all the previous sent rpmsg messages will be received from the M4 again.
Afterwards I can send and receive new messages normally. But it seems that the virtio buffer ring in the shared memory remains “valid” even if I run "rmmod" of the kernel module and reinitialize the rpmsg communication on the M4 side.
Here are the steps that are done:
Do you have any hints to help ?
Do you think it most likely comes from the rpmsg driver or from a bad init (or missing init) on the M4 side ? Who is responsible for clearing the rpmsg vring queues, and how ?
Had a look at the str_echo example of the CM4 SDK, it act as a remote and free the queue after sending each message as described here : RPMsg-Lite User's Guide: RPMsg Component, it shouldn't be a problem if you are not sending anything while stopping CM4. You could stop it more gently but there is no function to free the endpoint you have created.
Rpmsg Lite can't access the VirtQueue, only CA53 cluster running full Rpmsg can, but killing the tty driver might not be enough, it is only a part of the driver if you look at linux reference manual :
• Common code:
• i.MX platform-related code:
• i.MX RPMsg ping-pong tests:
• i.MX RPMsg TTY driver
Best regards, Philippe.
Thank you for your answer and the info.
We are currently trying to modify our driver based on drivers/rpmsg/imx_rpmsg_tty.c. Our idea is to create a dedicated endpoint (rpsmg_create_ept) and not using the standard one. This created endpoint will be destroyed once rmmod is called (rpsmg_destroy_ept). We hope that it will then completely free the allocated resources (virtqueue content).
Do you think it is the right way to proceed ?
For now, we do not manage to link this new endpoint to the CM4 code. On Linux driver side, the standard reception callback of the standard endpoint is still called instead of our dedicated new one.
There is no firmware loader in our linux BSP, official procedure is to load m4 firmware from u-boot only, do you get the same endpoint / channel number (ie /dev/ttyRPMSGxx) the second time ?
I would keep the standard endpoint, just make shure you release or destroy it when removing rpmsg_tty driver (imx_rpmsg_tty.c\rpmsg\drivers - linux-imx - i.MX Linux kernel that should communicate to rpmsg driver that got a delete endpoint function but only used in case of error during creation : imx_rpmsg.c\rpmsg\drivers - linux-imx - i.MX Linux kernel ).
Best regards, Philippe.