Skip to content

Future Topics for OpenAMP remoteproc sub group

Jump to bottom Edit New page
Bill MIlls edited this page Nov 7, 2019 · 28 revisions

Table of Contents

Future Topics for OpenAMP remoteproc sub-group

This list (needs update) covers topics for the "OpenAMP remoteproc" sub-group to discuss and work on. This sub-group covers areas such as remoteproc, rpmessage, virtio, big buffers, etc.

The sections below should include an short abstract and links to prior discussion etc. More detailed information should be added on a new wiki page and a link to that page should be added to the topic here.

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.
  • Q: 2019/11/7, Is this the same as SystemDT and should be moved to that group, or are there rp specific topics?

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

  • How to configure and assign resources and peripherals to coprocessors
  • Complications include clock and power domain control, system firewall and/or IOMMU configuration
  • Some of this gets easier if both Linux and the remote processor are using a central system controller for clock. power, and peripheral access control

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

  • Packed vrings, indirect descriptors, …
  • Virtio device handshake improvements
  • Use of existing virtio drivers (ex: virtblk, virtnet, virtcon) from remoteprocs
    • remoteproc could be frontend or backend (ex:could be the block user or block device)
    • Q: 2019/10/7, should this be its own topic and leave this one to be just virtio mechanics?

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
  • sub topics include allocation, mapping, IOMMU, remoteproc MMU, cache maintenance, address translation
  • DMA-BUF seems to be the obvious choice for allocation API now

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

The life cycle management of Linux is required in scenarios where it provides the rich execution environment and certified software environment (e.g on low end CPUs such as cortex M or R) is the system master and responsible to start/stop/recover Linux. The intent here is to cover the driver architecture (e.g. remoteporc replacement ) and device tree bindings for remote Linux. No plan to cover the Linux bootstrapping and RPMSG remote mode operation. They can be treated as separate topics. Linux will still assumed to be the RPMsg master.

Rpmsg protocol documentation for remote – Etsam

The RPMSG framework master side protocol 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
Add a custom footer
Add a custom sidebar
Clone this wiki locally