Supporting Protocols

Owned by elberger
Last updated: Aug 09, 2023
2 min read
ProtocolFeatures/NotesVIRTIO CompatOS SupportMaterialDeveloped ByUsed ByLicense(s)
remoteproc/rpmsgUpstream Linux kernel implementation, assumes Linux master, tight coupling between remoteproc/rpmsg.Limited - rpmsg depends on remoteproc for platform-specific transport mechanism.Linux, Binary FW (ELF)
TI/Wizery/Linaro
GPL-2.0
OpenAMP remoteproc/rpmsg

Implementation of remoteproc/rpmsg on top of the OpenAMP libmetal framework.

Focus on decoupling remoteproc/rpmsg, allowing non-Linux master cores.

Interest in exploring rpmsg protocol implementation on alternative transport mechanisms (e.g. socket, UART, SPI, PCIe).

Limited - with plans to extendLinux, Zephyr, FreeRTOS, Bare metal

https://drive.google.com/file/d/198kbwHojBHeM8QFnmSJd7dz5FLCpXPM9/view

https://www.openampproject.org/

Linaro Presentation about OpenAMP in AGL: Meeting Notes - Virtualization EG - Confluence (automotivelinux.org)

Linaro/OpenAMP project (Xilinx, ST, Wind River)Xilinx, ST, Wind River
  • BSD-3-Clause
  • BSD-2-Clause
  • Apache-2.0
  • GPL-2.0
rpmsg-lite

Lightweight RPMSG implementation targeting resource-constrained MCUs.

Usable as transport layer for e.g. eRPC.

MISRA C-2012 adherence, good basis for ISO26262

Limited - transport mechanism implemented in platform-specific code.Bare metal, FreeRTOS, QNX, ThreadX, Zephyr, XOS

GitHub

RPMsg-Lite Architecture

NXP
BSD-3-Clause
IPCFNo updates in Linux SHM driver in 3-4 yearsNLinux, AUTOSAR, FreeRTOS, Zephyr, Bare metal

GitHub, Overview


NXP
BSD-3-Clause
ICCOM

Open issues:

  • Middleware licensing?
  • OS support?
  • SoC drivers for transport layer?
  • No GitHub updates in 2-3 years
NLinux, ???

ICCom architectural overview

Bosch
  • Bosch-side drivers under GPL-2.0
  • Bindings under MPL-2.0
NvSciIpcGeneral IPC/stream framework that supports secure buffer sharing between threads, processes, VMs (inter-SoC), and across SoCs (via PCIe)NLinux, QNX

image

NVIDIA
  • Linux kernel drivers under GPL-2.0
  • Middleware Proprietary


please list more ... 

Observations

  • In-kernel remoteproc/rpmsg is tightly coupled, and assumes a Linux-based master booting a slave core/OS (not suitable for > ASIL B).
  • In-kernel rpmsg depends on remoteproc / remoteproc platform drivers provide the transport.
  • Current rpmsg implementations do not make use of virtio backends for abstracted transport and control mechanisms (virtio-scmi, net/vsock, mmio, etc).
  • Current remoteproc/rpmsg protocols are not defined in the OASIS VIRTIO spec, only generally through documentation and a number of papers (need alignment/collaboration with Linaro/OASIS)
  • OpenAMP driving new work on rpmsg protocol standardization, abstraction, and new transport mechanisms, as well as devicetree integration (good opportunity for AGL/Linaro collab)
  • rpmsg-lite currently provides the best starting point for RTOS→Linux processor control and the shortest path to ISO26262, could also benefit from the advancements being made in OpenAMP.