Timeline
Timeline
2026-07-04
init
This article introduces the OpenAMP (Open Asymmetric Multi-Processing) software framework, developed by Mentor Graphics and Xilinx, to solve the communication problem between RTOS or bare-metal programs and Linux in AMP systems. The article elaborates on the core components of OpenAMP: Virtio provides a virtual device framework for shared memory management, using vring ring buffers for data transfer; RPMsg, as a message bus based on Virtio, is responsible for inter-core message communication; Remoteproc is used for lifecycle management of remote processors, including firmware loading, start/stop, and resource parsing. Taking STM32MP157 as an example, the article explains the mechanism of communication between Cortex-A7 and Cortex-M4 via OpenAMP, and compares the differences in underlying drivers on the Linux side and the bare-metal side.
OpenAMP (Open Asymmetric Multi-Processing) was originally a software framework developed by Mentor Graphics and Xilinx to enable communication between RTOS or bare-metal programs and the Linux interface in AMP systems. Currently, OpenAMP can be used on platforms such as ST, NXP, TI, and Xilinx. These manufacturers have provided ported OpenAMP development examples, and users can refer to these examples for development. This article takesSTM32Cube_FW_MP1_V1.2.0\Projects\STM32MP157C-DK2\Applications\OpenAMPas a reference example.
OpenAMP Project official website
OpenAMP official documentation
OpenAMP GitHub open-source repository
The main OpenAMP library (implementing RPMSG, Virtio, and Remoteproc for RTOS etc)
STM32CubeMP1 MPU Firmware Package
- STM32MP157C-EV1 RevC
- STM32MP157C-DK2 RevC
OpenAMP provides implementations of RPMsg, Virtio, and Remoteproc:
virtio
Virtio is a virtual device framework that provides shared memory management. The vring (virtio ring) in Virtio is a ring buffer mechanism based on a descriptor table, consisting of a descriptor table, an available ring, and a used ring, used to transfer I/O data between the host and the virtual machine (or between the main processor and the coprocessor). Each Virtio device has a pair of vrings, each responsible for data transmission in one of two directions:
- One vring is dedicated to messages sent to the remote processor (TX)
- The other vring is used for messages received from the remote processor (RX)
Data between A7 and M4 is shared through the buffers referenced by the vrings. These buffers are located in the shared memory of the two processors (Shared memory, also known as IPC Buffers or Vring buffers).
In the reference configuration provided by ST, the shared memory of STM32MP157 is located in SRAM3. As shown in the figure below, the processors complete data flow forwarding through the vring ring buffers.
The relevant code is located atlinux-5.10.256/drivers/virtio
rpmsg
The RPMsg framework is shown in the figure below. It can be seen that the RPMsg framework sits on top of Virtio. The RPMsg (Remote Processor Messaging) framework is a message bus based on Virtio. RPMsg can communicate with the remote side via Virtio under the coordination of IPCC, while Remoteproc, under the control of IPCC, can write firmware and other data to the remote side, or control the lifecycle and status of the remote side.
As can be seen from the figure, OpenAMP uses IPCC at the underlying layer. Reference:
On Cortex-A7, the Remoteproc framework activates Linux-based inter-process communication (IPC) based on the available information in the coprocessor’s firmware resource table. RPMsg services are implemented through the RPMsg framework, and mailbox services are implemented by the mailbox driver stm32_ipcc.
On Cortex-M4, RPMsg services are implemented by the OpenAMP library, and mailbox services are implemented by the HAL_IPCC driver.
This is a bit convoluted. The general idea is that the A core running Linux and the M core running bare-metal or FreeRTOS communicate through OpenAMP. The A core and M core have correspondingly designed OpenAMP implementations, but they are compatible with each other, except that the underlying calls are different. For example, the A core mailbox service is provided by the driver stm32_ipcc, and the M core mailbox service is provided by HAL_IPCC driver implementation.
In the default configuration provided by ST, the SRAM3 area in MCUSRAM has two vrings, used for sending and receiving messages respectively. The buffers referenced by the vrings are the shared memory. The RPMsg framework is based on Virtio vrings. It sends messages to the remote processor or receives messages from the remote processor through the Virtio vrings. When a new message is already in the shared memory, the mailbox framework notifies the processor that there is a message to receive.
RPMsg is actually a message bus based on Virtio, used to implement message passing (transferring inter-core data). RPMsg can be considered a channel for communicating with remote processors; we can also call it an RPMsg device. Each channel has a local source address and a remote destination address. Messages are transmitted between the source address and the destination address. The communication process is shown in the following figure:
Regarding RPMsg, refer to:
Based on these software frameworks, all data is transmitted over RPMsg. RPMsg transfers data to the RPMsg client in the kernel layer, and then to user space through kernel device nodes. Combined with the hierarchical structure of the network TCP/IP, shared memory and inter-core interrupts correspond to the physical hardware layer, Virtio corresponds to the MAC sublayer, and RPMsg corresponds to the transport layer, as shown in the following figure:
remoteproc
For SoCs with asymmetric multiprocessing, different cores may run different operating systems. For example, the Cortex-A7 of the STM32MP157 runs the Linux operating system, while the Cortex-M4 can run the OneOS operating system or bare-metal programs.
To enable easy communication between the main processor running Linux and the coprocessor, the Remoteproc inter-core communication framework was introduced after Linux version 3.4.x. The Remoteproc framework was developed by Texas Instruments. On this basis, Mentor Graphics developed the OpenAMP software framework. Under this framework, the Linux operating system on the main processor can perform lifecycle management of the remote processor and its associated software environment, i.e., start or shut down the remote processor.
Let’s take the STM32MP157 as an example to look at the Remoteproc framework of the M4 and A7, as shown in the following figure:
Remoteproc is a generic remote processor management framework. Its functions are:
- A7 loads the code and data segments of the M4 firmware image into M4 memory for in-place execution;
- Parse the firmware resource table to set up associated resources (including information such as the start address and size of each segment in the firmware, as well as Virtio device features, vring address, size, and alignment information);
- Control the start and shutdown of the M4 core firmware;
- Establish an RPMsg communication channel for communication with the M4;
- Provide monitoring and debugging remote services (using the sysfs and debugfs file systems, which are already configured by default in the development board’s Linux file system and can be used immediately after boot).
Note: RPMsg communication uses the Mailbox, but this is not well reflected in the figure. The general process can be understood as: Remoteproc loads the firmware into the M core, and message passing needs to be carried out through the channel established after initialization. In the figure, RCC and others are configured by stm32 after the firmware image is loaded_rproc automatically configures, i.e., stm32_rproc is the backend driver of Remoteproc and will perform a series of subsequent operations
stm32_rproc is the driver for the remote processor (M4 core). Its functions are:
- Register vendor-specific functions (such as callback function parts) with the Remoteproc framework;
- Handle platform resources associated with the M4 (e.g., registers, watchdog, reset, clocks, and memory);
- Forward notifications to the M4 through the mailbox framework (Mailbox).
The firmware mentioned above is the executable file of the M4, such as the one compiled under MDK.axffile or the one compiled under STM32CubeIDE.elffile.
A7 is called the main processor, and M4 is called the coprocessor or remote processor. The main processor starts first, and then boots the coprocessor:
- The main processor can first load the coprocessor firmware through the Remoteproc framework, and then parse the information published in the firmware resource table to configure coprocessor system resources and create Virtio devices.
- Once the Remoteproc on the main processor loads and starts the remote processor’s firmware, the coprocessor begins running.
- After the coprocessor starts, inter-core communication between the two cores is not yet possible. It is necessary to first create an RPMsg channel, and after the main processor sends the first message, the two cores can then perform inter-core communication and exchange data.
- If the firmware needs to be stopped, the main processor can also shut down the firmware, and the coprocessor program stops running immediately. In summary, the Remoteproc framework implements lifecycle management (LCM) and control of the remote coprocessor, as shown in the following figure:
The relevant code is located atlinux-5.10.256/drivers/remoteproc
Summary
Based on the above analysis, the OpenAMP open-source software framework has the following functions and features:
- Provides remote processor lifecycle management and inter-processor communication functions;
- Provides standalone libraries usable in RTOS and bare-metal software environments;
- Compatible with upstream Linux Remoteproc, RPMsg, and VirtIO components.
Process of using OpenAMP to implement inter-core communication:
Assume the main processor is already running and the remote processor is in some state, such as standby or power-off state.
- The main processor, based on the Remoteproc framework, first loads the remote processor’s firmware into memory.
- Then the main processor starts the remote processor (runs the firmware) and waits for it to complete initialization, such as wake-up, de-asserting reset, powering on, etc.
- The remote processor notifies the main processor after initialization is complete.
- The main processor and the remote processor establish an RPMsg communication channel.
- Through the RPMsg channel, the two can perform inter-core communication.