RPMSG buffer not cleared after M4 firmware reload

[olivier_riff]

Hello,

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:

1.       Load the M4 firmware (/usr/bin/m4fwloader …) : OK
2.       modprobe of rpsmg tyy driver : OK
3.       Start the M4 firmware (/usr/bin/m4fwloader kick 0) : OK
4.       Exchange data between Linux application and M4 through rpmsg tty driver : OK
5.       Kill the M4 firmware (/usr/bin/m4fwloader stop) : OK
6.       Remove the driver (rmmod …)
7.       Load the M4 firmware (/usr/bin/m4fwloader …)
8.       modprobe of rpsmg tyy driver : OK
9.       Start the M4 firmware (/usr/bin/m4fwloader kick 0) : KO : lost of old messages are received in a row by M4 (those from step 4)

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 ?

Thanks,

Olivier

[ZeeFrench]

Hello Olivier,

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:
drivers/rpmsg/virtio_rpmsg_bus.c
• i.MX platform-related code:
arch/arm/mach-imx/imx_rpmsg.c
• i.MX RPMsg ping-pong tests:
drivers/rpmsg/imx_rpmsg_pingpong.c
• i.MX RPMsg TTY driver
drivers/rpmsg/imx_rpmsg_tty.c

Best regards, Philippe.

[olivier_riff]

Hello 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.

Best regards,

Olivier

[ZeeFrench]

Hello Olivier,

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.