The Open Asymmetric Multi-Processing (OpenAMP) is a framework providing the software components needed to enable the development of software applications for Asymmetric Multiprocessing (AMP) systems.
The Xilinx release of the OpenAMP framework provides:
Fully functional remoteproc and RPMsg components usable with a Linux master running with bare metal or FreeRTOS remote configuration
Proxy infrastructure and demos that showcase the ability of a proxy on a master processor to handle printf, scanf, open, close, read, and write calls from bare metal-based remote contexts
The OpenAMP Project is an open source project hosted by the Linaro Community Projects division. Xilinx drove the formation of the community project and continues to play a leadership role in the work. The community project has multiple member companies and multiple working groups. More information can be found below.
It is common for the master processor in an AMP system to bring up software on the remote cores on demand. These cores then communicate using Inter Process Communication (IPC). This allows the master processor to off-load work to the other processors. The general OpenAMP flow is as follows:
The Linux master configures the remote processor and shared memory is created.
The master boots the remote processor.
The remote processor calls remoteproc_resource_init() which creates the virtIO/RPMsg channels for the master.
The master receives these channels and invokes the callback channel that was created.
The master responds to the remote context, acknowledging the remote processor and application.
The remote invokes the RPMsg channel that was registered.
The RPMsg channel is now established and both sides can use the RPMsg calls to communicate.
To shut down the remote processor:
The master application sends an application-specific shutdown message to the remote application.
The remote application cleans up its resources and sends an acknowledgement to the master.
The remote calls the remoteproc_resource_deinit() function to free the remoteproc resources on the remote side.
The master shuts down the remote processor and frees the remoteproc on its side.
See the specific functions at the end of the document for more information.
The two key components that are provided by the OpenAMP framework include:
remoteproc: This is used to control the Life Cycle Management (LCM) of the remote processors from the master processor. The remoteproc API that is provided with OpenAMP is compliant with the infrastructure present in the upstream Linux kernel 3.18 onwards. The remoteproc uses information published through the firmware resource table to allocate system resources and to create virtio devices.
RPMsg: The RPMsg API allows Inter Process Communications (IPC) between software running on independent cores in an AMP system. This is also compliant with the RPMsg bus infrastructure present in the upstream Linux kernel 3.18 onwards.
The mainline Linux kernel allows Linux applications running on the master processor to control the LCM of a remote processor. It also allows IPC between the master and remotes. The OpenAMP framework provides the infrastructure for RTOS or bare metal environments to communicate with the upstream Linux kernel in AMP systems using RPMsg and virtIO in the Linux kernel.
OpenAMP demo applications
The following applications are provided as pre-built with Petalinux to demonstrate OpenAMP features.
A simple test application that sends a number of payloads from the master to the remote and tests the integrity of the data.
This example uses the Linux master to boot the remote firmware using remoteproc. The Linux master then transmits payloads to the remote firmware using RPMsg. The remote firmware echoes back the received data using RPMsg. Finally the Linux master verifies and prints the payload.
For more information on the echo test application see the relevant source code in the PetaLinux BSP:
Linux Master (kernel space): components/modules/rpmsg_echo_test_kern_app/
Linux Master (user space): components/apps/echo_test/
The remote echo test firmware is located at: components/apps/echo_test/data/r5_image_echo_test
The matrix multiplication application provides a more complex test that generates two matrices on the master. These matrices are then sent to the remote which is used to multiply the matrices. The remote then sends the result back to the master which displays the result.
This application creates a proxy between the Linux master and the remote core. This allows the remote firmware to use console and execute file I/O on the master. The Linux master boots the remote firmware. This is done using the proxy_app. The remote firmware does file I/O on the Linux File System (FS) which is on the master processor. The remote firmware also uses the master console to receive input and display output form and to the user. For more information on the proxy application see the relevant source code:
Linux Master (kernel space): components/modules/rpmsg_proxy_dev_driver/
Linux Master (user space): components/apps/proxy_app/
The remote proxy app firmware is located at: Bare metal remote: components/apps/proxy_app/data/r5_image_rpc_demo
Building/booting Linux and OpenAMP demo applications:
To run the demo applications, you will need to build Linux with the corresponding Device Tree for OpenAMP, additionally if you do not use the above mentioned pre-built images for the remote processor, you can use the Xilinx Vitis default template applications to create a project and rebuild them.
Getting Started with OpenAMP
The Getting Started Guide for OpenAMP UG1186 provides a step-by-step guide to run the above mentioned demos applications. It is recommended you start with one of those demos before you try to write your own OpenAMP application. Additional release specific information is provided at the links below to support and complement the document.
The OpenAMP open source project originally was hosted by the Multi Core Association as a working group. Eventually, the Multi Core Association was no longer active. The OpenAMP open source project found a new home at Linaro Community Projects.
The community project has a Board, Technical Steering Committee, working groups, GitHub repository, and mailing lists. The working groups are: