Future Topics for OpenAMP remoteproc sub group

Table of Contents Future Topics for OpenAMP remoteproc sub-group HW description (Xilinx, TI, ST, Mentor) System Resource Management – (ST, Xilinx, TI, Cypress) OpenAMP project support for Virtio spec (Xilinx, TI, ST, Mentor) Big data – (Xilinx, TI, ST) Kernel remoteproc patches - Loic Remoteproc/rpmsg regression test – Loic Secure coprocessor support – Loic Early coprocessor boot – late attach - Loic Lifecycle management and Trusted & Embedded Base Boot Requirement (T/E-BBR) – Etsam Lifecycle management with Linux remote – Etsam Rpmsg protocol documentation for remote – Etsam MCU – MCU issues, rpsmg only - Mark 64 bits support - Clément

Future Topics for OpenAMP remoteproc sub-group

2019-10-24: This list (needs update) covers topics for the "OpenAMP remoteproc" sub-group to discuss what to work on at their first sub-group meeting. This sub-group covers areas such as remoteproc, rpmessage, virtio, big buffers, etc.

HW description (Xilinx, TI, ST, Mentor)

• How to describe HW to System SW – Complete HW vs. OS centric subsystems – DT, IPExact. More info can be found here.

System Resource Management – (ST, Xilinx, TI, Cypress)

• How to configure and assign resources and peripherals to coprocessors

OpenAMP project support for Virtio spec (Xilinx, TI, ST, Mentor)

• Packed vrings, indirect descriptors, …
• Virtio device handshake improvements

Big data – (Xilinx, TI, ST)

• Rpmsg buffer management
• Zero copy and big buffer
• Heterogeneous Memory Management. More info can be found here
• libmetal shared memory allocation: https://github.com/OpenAMP/libmetal/issues/70

Kernel remoteproc patches - Loic

Remoteproc/rpmsg regression test – Loic

Secure coprocessor support – Loic

Early coprocessor boot – late attach - Loic

Lifecycle management and Trusted & Embedded Base Boot Requirement (T/E-BBR) – Etsam

Lifecycle management with Linux remote – Etsam

Rpmsg protocol documentation for remote – Etsam

The RPMSG master side protocol sequence is well manifested in Linux upstream and new masters (e.g. OpenAMP) can be written using it as a reference. However, there is no standard Doc/Implementation for remote which often leads to problematic protocol scenarios. For instance, consider the two cases below:

• At what point VDEV Resource is initialized by the Master, specially when the vrings are dynamically allocated?
  • Conversely, at what point remote should access that vdev resource? Consider the case where vdev resource is accessed by the remote right after boot up, assumption here is that it is initialized by the master before starting the remote. This worked for kernel v3.18 , however, it is broken for v4.9 (may be for others as well) where the vring addresses are populated after remote is booted. For latter, this leads to race condition and sometimes remote ends up accessing uninitialized vdev resource. Apparently, the correct point to access vdev resource is after vdev status field (DRIVER_OK) is updated by the master.
• When to send the Name service announcement?
  • In response to first kick from the master: This works if remote is up and running. What if kick is sent and remote is not yet operational? It will miss the kick and consequently NS will not be sent.
  • In response to VDEV status update (DRIVER_OK). Will work if remote comes up after the first kick. The status will still be in the shared memory and can be used to send the NS.

The foolproof approach would be to use both kick and VDEV status to send the NS. This point was found after trial and error.

It is required to document all such scenarios i.e. all master actions and expected response from the remote, to enable seamless operation with different remotes.

MCU – MCU issues, rpsmg only - Mark

64 bits support - Clément

• 64 bits support in elf file (https://patchwork.kernel.org/patch/11175161/)
• 64 bits addresses in resources table
• 64 bits features in vdev declaration