OpenAMP linux kernel vs userspace implementation

[sriramster]

Hello,

My name is Sriram, I'm working on adapting/developing an openamp based communication model for a heterogenous SoC. I've a minimal working implementation where Linux serves as the master and the remote-core working as a slave. I'd stumbled upon couple of trivial doubts and decision making help with respect to OpenAMP. Writing here, to get some expert opinions on the same. Thank you.

• What would be the pros-cons of Linux driver based implementation against that of an Linux user-space implementation?
• The system that I'm trying to build has multiple people from the Linux talking to a single executable running on the remote-core (baremetal). What is the recommended method here? i.e do I make the remote-core the master and linux the slave?
• At this point, I'm using openamp without remoteproc, do you see any disadvantages of the same.

Please help, thank you.

[arnopo]

Hello @sriramster

have never used OpenAMP in Linux user space, but I do use Linux kernel RPMsg. @edmooring and @tnmysh use both, perhaps they will have another opinion.

Here is my view:

• What would be the pros-cons of Linux driver based implementation against that of an Linux user-space implementation?

pro:

• Utilizes the Linux kernel RPMsg bus:
  • Device discovery mechanism based on the name service announcement feature.
  • RPMsg devices are unbound when remoteproc stops.
• Possibility to implement other protocols over RPMsg and offer a standard API to user space (e.g., RPMsg char, RPMsg tty).

cons:

• You may need to develop a kernel driver depending on your needs.
• You need another way to probe the virtio and RPMsg if you are not using the Linux kernel remoteproc framework.
• you probably need some kernel code to expose the shared memory and Notification mechanism to the user space.

• The system that I'm trying to build has multiple people from the Linux talking to a single executable running on the remote-core (baremetal). What is the recommended method here? i.e do I make the remote-core the master and linux the slave?

We speak more in terms of driver and device than master and slave. The device provides the service, and the driver is the client. An example is a coprocessor managing a physical bus (it is the device), and Linux has different applications accessing this bus (the drivers).

• At this point, I'm using openamp without remoteproc, do you see any disadvantages of the same.

One advantage of using the remoteproc framework in the Linux kernel is to manage resources associated with the remote processor (memory regions, RPMsg bus creation, etc.), but its use is not mandatory.

[sriramster]

@arnopo Thank you for the detailed write up on this.

I'm trying to understand further on your explanation about the device & driver. When this is the case, we let the device allocate the shpool for the vrings and let the driver access it? But from my understanding the driver doesn't work like this right?

There is also different problem where I'd wish to know your insights, on using the linux kernel remoteproc, rpmsg, virtio I could load the remotefirmware, and establish connection between the two upto the namespace announcement and binding. But there is a limitation on the device i.e it can only access address within a few physical-address range. But linux kernel provides a virtqueue-buffer which it allocates using the dma_* subsystem. How do we manage this? i.e let linux know that the device can only access data when its available from a specific range.

Thank you again.

[sriramster]

@arnopo ignore the above query, i got it work with linux kernel openamp infrastructure. I've a follow up with this,

My need is as such that, we've multiple data producers on the linux kernel (driver) and a dsp (which is the device). How do you recommend creating multi-process support here? (i.e multiple producers and one consumer) problem with OpenAMP.

Thank you.

[arnopo]

@arnopo Thank you for the detailed write up on this.

I'm trying to understand further on your explanation about the device & driver. When this is the case, we let the device allocate the shpool for the vrings and let the driver access it? But from my understanding the driver doesn't work like this right?

No, it's the opposite:

• When virtio is used for virtualization, the driver in the guest allocates memory for vrings and provides it to the host.
• In AMP systems with Linux and a remote processor, it's similar. The Linux remoteproc virtio driver typically allocates the vrings and provides the addresses to the remote processor via the resource table. If Linux remoteproc is not used, the vring addresses can be statically fixed on both sides.

There is also different problem where I'd wish to know your insights, on using the linux kernel remoteproc, rpmsg, virtio I could load the remotefirmware, and establish connection between the two upto the namespace announcement and binding. But there is a limitation on the device i.e it can only access address within a few physical-address range. But linux kernel provides a virtqueue-buffer which it allocates using the dma_* subsystem. How do we manage this? i.e let linux know that the device can only access data when its available from a specific range.

For this purpose, we typically use device tree memory regions such as vdev0vring0, vdev0vring1, and vdev0buffer. You can examine the usage here:

• remoteproc_core.c
• remoteproc_virtio.c

and find some example of the usage in following drivers:

• imx_rproc.c
• stm32_rproc.c
• xlnx_r5_remoteproc.c