Skip to main content
Y
YRink.1
Visitor II
March 23, 2021
Solved

Multiple Endpoints on A7 and M4

  • March 23, 2021
  • 4 replies
  • 3107 views

Hello,

iam trying to implement more or less the same example as with the virtualUARTs with multiple Endpoints just with the rpmsg_char driver and plain endpoints without virtualUART on M4 side. Iam struggling to get multiple Endpoints to work. One is working fine and the other is created as well. But i cant send and receive data through the second endpoint. Does anyone have an example with multiple endpoints with the rpmsg_char driver?

    This topic has been closed for replies.
    Best answer by ArnaudP

    Hello,

    The rpmsg_char is not compatible with the rpmsg virtio neither in ST or in kernel.org distribution. So I assume that you are using a specific Linux Kernel patch coming from Xilinx, right?

    Xilinx has patched the kernel to be able to use the rpmsg_char. So no guaranty that this works with several endpoints and on another platform. Seems the same for the example, only one endpoint is created (charfd is a global variable).

    So you have to understand the behavior of such implementation, as mentioned in my previous mail, a good entry point is to analyze the RPMsg exchanged by enabling the dynamic debug 

    echo -n 'file virtio_rpmsg_bus.c +p' > /sys/kernel/debug/dynamic_debug/control
echo -n 'file virtio_ring.c +p' > /sys/kernel/debug/dynamic_debug/control

    4 replies

    A
    ArnaudP
    ST Employee
    March 23, 2021

    Hello,

    Could you detail your context, as the rpmsg_char is not supported in the ST distribution.

    Do you back-port this series: https://patchwork.kernel.org/project/linux-remoteproc/list/?series=446305&state=%2A&archive=both ?

    Be careful in this case to fix the Linux Local endpoint addresses to avoid that this address change, each time you open/close the /dev/rpmsgX.

    On my side i tested using the OpenAMp TTY echo exemple ( so the virtualUARTs) , by disabling the rpmsg TTY on Linux side and it works well.

    I would suggest you to enable the dynamic debug on Linux and enable rpmsg_virtio traces :

    https://wiki.st.com/stm32mpu/wiki/Linux_RPMsg_framework_overview#How_to_trace_and_debug_the_framework

    Theses traces print messages with source and destination addresses to help you to debug.

    Y
    YRink.1Author
    Visitor II
    March 29, 2021

    Hello,

    i enabled the rpmsg_char device via Yocto and with one endpoint its working fine for me but not with two. I tried to use fixed adresses not based on RPMSG_ADR_ANY. Still it only works for one endpoint. My usage of the rpmsg_char is based on the Xilinx example https://github.com/Xilinx/meta-openamp/blob/master/recipes-openamp/rpmsg-examples/rpmsg-echo-test/echo_test.c. The M4 creates the two "Channels" virtio0.rpmsg-openamp-demo-channel.-1.0 and virtio0.rpmsg-openamp-demo-channel.-1.1. Iam actually able to acess both it but with the virtio0.rpmsg-openamp-demo-channel.-1.1 i cant exchange data.

    A part of my M4 code is attached.

    A
    ArnaudPAnswer
    ST Employee
    March 29, 2021

    Hello,

    The rpmsg_char is not compatible with the rpmsg virtio neither in ST or in kernel.org distribution. So I assume that you are using a specific Linux Kernel patch coming from Xilinx, right?

    Xilinx has patched the kernel to be able to use the rpmsg_char. So no guaranty that this works with several endpoints and on another platform. Seems the same for the example, only one endpoint is created (charfd is a global variable).

    So you have to understand the behavior of such implementation, as mentioned in my previous mail, a good entry point is to analyze the RPMsg exchanged by enabling the dynamic debug 

    echo -n 'file virtio_rpmsg_bus.c +p' > /sys/kernel/debug/dynamic_debug/control
echo -n 'file virtio_ring.c +p' > /sys/kernel/debug/dynamic_debug/control

    A
    ArnaudP
    ST Employee
    April 7, 2021

    More of the discussion is available here : https://github.com/OpenAMP/open-amp/discussions/279

    Terms & ConditionsAccessibility statement