This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: How to disable print msg "virtio_rpmsg_bus virtio1: msg received with no recipient"

Part Number: AM6442


We are sending the RpMsg from R5_0 to A53 application, and when application A53  killed then r5 is still sending the RPMsg and we are seeing the log "virtio_rpmsg_bus virtio1: msg received with no recipient".

How to disable this msg. 

Is there is any mechanism available in A53 to tell to R5 thal application got killed.

  • Hello Venkat,

    Is this a planned closing of the Linux side application? If so, you can have the Linux application send a specific message to the R5F that it is going to end before the program exits.

    Regards,

    Nick

  • Hello Venkat,

    The thread is unlocked. Feel free to reply here, or create a new thread if you have a new question.

    Regards,

    Nick

  • As per your suggestion we have implemented in Linux application to send a specific message to the R5F that is going to end and then in R5 we are handled it.

    But in some cases the Linux application is still running but we get these messages "msg received with no recipient". When we debugged further this msg is coming from "struct rpmsg_endpoint *ept" is NULL in method rpmsg_recv_single in file virtio_rpmsg_bus.c

    This issue happens in every boot for the first time and after restarting manually R5 and Linux application this issue will never appear.

    What couldn't be issue here?

  • Hello Venkata,

    1) What is your R5F code doing when it "handles" the message that the Linux application is going down?

    2) What boot process are you using? How is the R5F getting initialized during that boot process?

    3) Please explain what you mean here: "This issue happens in every boot for the first time and after restarting manually R5 and Linux application this issue will never appear." I thought that the issue only happened after you had started the Linux application, and then stopped the Linux application. Is that incorrect?

    4) Please provide a diagram or something to help me understand what is going on in your system, and when it is happening. i.e.,
    a) which cores are interacting with each other
    b) how is the Linux application and the remote core interacting before this "stop IPC" message is sent?
    c) how do you expect the system to work after the "stop IPC" message is sent?

    5) Are you expecting the R5F to shut down and come back up during Linux runtime? Graceful shutdown of the R5F is not supported as of SDK 8.6, but we will add it for Linux SDK 9.0.

    Regards,

    Nick

  • 1) What is your R5F code doing when it "handles" the message that the Linux application is going down?
    [Venkat] When the Linux application is going down, from R5 side we stop sending further messages. So we don't see "msg received with no recipient" messages.

    2) What boot process are you using? How is the R5F getting initialized during that boot process?
    [Venkat] We are using "MMC1 - SD Card" boot process, in which during the linux boot up at 6th seconds all the R5 cores will be powered up and then using the bashrc script running the BDApp.

    3) Please explain what you mean here: "This issue happens in every boot for the first time and after restarting manually R5 and Linux application this issue will never appear." I thought that the issue only happened after you had started the Linux application, and then stopped the Linux application. Is that incorrect?
    [Venkat] Here "every boot" means during the normal power on board, and at 6th second R5 will be up and after linux complete boots up and login we run the BDApp(linux application) with bashrc script automatically. After few mins, we see the issue always. Here BDApp and R5 both are running.

    When this issue happens we do 2 things:
    1. Kill the BDApp application
    2. stop and start the R5 core

    And after the above 2 steps, issue never appears.


    4) Please provide a diagram or something to help me understand what is going on in your system, and when it is happening. i.e.,
    a) which cores are interacting with each other
    [Venkat] we use only am64-main-r5f0_0-fw core

    b) how is the Linux application and the remote core interacting before this "stop IPC" message is sent?
    [Venkat] They both interacting using RPMsg

    c) how do you expect the system to work after the "stop IPC" message is sent?
    [Venkat] we should not see these sporiodic messages "msg received with no recipient" on the serial console.

    5) Are you expecting the R5F to shut down and come back up during Linux runtime? Graceful shutdown of the R5F is not supported as of SDK 8.6, but we will add it for Linux SDK 9.0.
    [Venkat] we should not see these sporiodic messages "msg received with no recipient" on the serial console.

    So basically During the powered on first time, we see these "msg received with no recipient" even though R5 and BDApp is running properly. So what could be the issue here? How to solve this issue?

  • Hello Venkata,

    Is BDApp using RPMsg to communicate with the R5F core? It would be helpful to see the IPC code you are writing to communicate on both the R5F and the Linux side. You can send it to me through Lawrence if you don't want to post it here.

    Regards,

    Nick

  • Hello Venkata,

    Following up on our discussion, I asked around to see if any team members had any other suggestions. People echoed our idea of adding a "heartbeat" print statement to the userspace application to make sure it was still running as expected. GDB debug can also be used to inspect the userspace code. I do not have much experience with GDB debug, so if you were interested in using it, you would want to search other parts of the web.

    Regards,

    Nick

  • Hi Nick,

    We debugged further in userspace application program, R5 core application and encountered that R5 core application is receiving the alien message on core 0, may be from the other user example application (PRU_RPMsg_Echo_Interrupt*_*) process. When this message is received by the R5 core application the end point is modified and then the connection from R5 core application to userspace application lost which resulting this error.

    We fixed, not to modify the endpt when this alien message received by the R5 core application. With this R5 core application is always has the connection to the userspace application.

    This is fixed. we can close this thread. Thanks

  • Glad to hear the issue was resolved Venkata! Thanks for replying back with your solution.

    Regards,

    Nick