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)
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

Linaro Presentation about OpenAMP in AGL: Meeting Notes - Virtualization EG - Confluence (

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

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, XOSNXP
IPCFNo updates in Linux SHM driver in 3-4 yearsNLinux, AUTOSAR, FreeRTOS, Zephyr, Bare metalNXP

Open issues:

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

ICCom architectural overview

  • 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


  • Linux kernel drivers under GPL-2.0
  • Middleware Proprietary

please list more ... 


  • 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.
  • No labels