Is openamp support the multi endpoint to communicate with each other through one channel(soft)?

[e665107]

Hi
At present, i am debugging the openamp communication, and one side is linux, the other side is baremetal. On the linux side , i use the rpmsg framework, which is supplied by the linux kernel. On the baremetal side, i use openamp framework. Now one endpoint, one channel is ok, multi endpoint, multi channel is also ok. But multi endpoint, one channel get me in stuck. I can't debug it out. So, is this way supported now? I can't find any examples in the source code to reference. Can you help me?
Thanks a lot!

[arnopo]

Hello,
To debug messages in Linux kernel trace you can use 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

Here is an example in zephyr that uses multi endpoint / multi channel:
https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/ipc/ipc_service/static_vrings/src/main.c

Another example on stmp157-dk2 platform running with two instances of the Linux rpmsg_tty driver:
https://github.com/STMicroelectronics/STM32CubeMP1/blob/master/Projects/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo/Src/main.c

[e665107]

Hi
I'm very glad to receive your advice. But the method of multi-endpoin with multi-channel, i have completed it. Now multi-endpoint with one channel doesn't work. It confuses me a lot.

[arnopo]

Sorry I read your comment too fast.
Could you share your code to understand how you create your endpoints on the Linux and coprocessor side?

[e665107]

Hi
I have found that the rpmsg framework of linux kernel only support one endpoint binds with one channel, but openamp support multiendpoints bind with one channel. By theirs rpmsg_device struct info. Do you think so?

[arnopo]

Hi I have found that the rpmsg framework of linux kernel only support one endpoint binds with one channel, but openamp support multiendpoints bind with one channel. By theirs rpmsg_device struct info. Do you think so?

on linux side for the virtio implementation there is a default endpoint associated to a channel.
In your Linux driver you can create several endpoints per channel as done in rpmsg_char.c
But there is no name service announcement associated. So creating your endpoint you have to fix the source and destination address on both side.

[e665107]

On the openamp side, i find that it only supports one endpoint bind with one channel. Is it as what i thought?

[arnopo]

On openAMP side the notion of endpoint and channel are mixed. You reference an endpoint with a name service.
If ept->dest_addr == RPMSG_ADDR_ANY a name service announcement is sent to the remote side

you can instantiate several endpoints with the same service name. If ept->dest_addr == RPMSG_ADDR_ANY this lead to the creation of several channel on Linux side.
Same approach as for Linux, if you want muti endpoint you have to fix the addresses of the endpoints.

[e665107]

Hi friend:
Now, i am confused with one application scenario, one side is two linux processes which works with ttyrpmsg0 and ttyrpmsg1, the other side is baremetal whith openamp's virtual uart0 and uart1, do they can work well? On the linux side, work with rpmsg and mailbox, but the mailbox only have one notify intrrupt signal, this is my case.

[arnopo]

This page can help you to understand how it is working: https://github.com/OpenAMP/open-amp/wiki/RPMsg-Messaging-Protocol
In summary.
Being able to mix endpoint messages on a single VirtIO instance is the main goal of the RPMsg protocol. The mailbox is associated with the VirIO transport layer not with the RPMsg.
In the rpmg TTY usecase:

• On linux side 2 "rpmsg_tty" channels are created with one default endpoint and one /dev/ttyRPMSGx interface per channel.
• On OpenAMP side the notion of channel and endpoint have been concatenated. 2 endpoints with the same name service are created.

As RPMsg messages integrate an header containing the endpoint source address and the endpoint destination address, each message is routed to expected endpoint.