Project Overview
OpenAMP Intro
Asymmetric Multiprocessing (AMP) involves the management, control and communication of multi-core computer systems, where processors have independent tasks and are often in a heterogeneous embedded environment where there are different types of processors. This is in contrast to Symmetric Multiprocessing (SMP) which involves central control and load sharing using identical processor cores and is common place in servers and desktop computers.
The OpenAMP project is a community effort that is promoting and implementing how these multiple embedded systems interact with each other in an AMP environment. It provides conventions and open source implementation to facilitate AMP development for embedded systems.
The vision is that regardless of the operating environment/operating system, it should be possible to use identical interfaces to interact with other operating environments in the same system.
Furthermore, these operating environments can interoperate over a common protocol, making it possible to mix and match any two or more operating systems in the same device.
Read more about Asymmetric Multiprocessing here.
History
Texas Instruments’ remoteproc and RPMsg infrastructure available in the upstream Linux kernel enable the Linux applications running on a host processor to manage the life cycle of remote processor/firmware and perform IPC with them. However, there was no open- source API/software available that provided similar functionality and interfaces for other possible software contexts (RTOS- or bare metal-based applications) running on the remote processor to communicate with the Linux host. Also, AMP applications may require RTOS- or bare metal-based applications to run on the host processor and be able to manage and communicate with various software environments (RTOS, bare metal, or even Linux) on the remote processor.
The OpenAMP Framework fills these gaps. It provides the required LCM and IPC infrastructure from the RTOS and bare metal environments with the API conformity and functional symmetry available in the upstream Linux kernel. As in upstream Linux, the OpenAMP Framework’s remoteproc and RPMsg infrastructure uses virtio as the transport layer/abstraction.
Project Aims
To provide a solution to cover the AMP Fundamentals, the OpenAMP project is divided into the following efforts:
- A guidance group under Linaro Community Projects
- Provides guidance for the low-level protocol that allows systems to interact (more info here)
Built on top of the Virtio Open Standard
- Maintaining common user level APIs that allow applications to be portable
Provide low-level OS/HW abstraction layer APIs that abstracts the open source implementation from the underlying OS and hardware, simplifying the porting to new environments
- An open source project that implements a clean-room implementation of OpenAMP
Runs in multiple environments
BSD License
OpenAMP Fundamentals
There are some AMP fundamentals which influence the OpenAMP architecture.
Topology: Different runtime systems need to coexist and collaborate as Asymmetric Multiprocessing sets no restrictions on how systems can or should be utilized.
Resource Assignment: Resources need to be assigned and shared into runtime domains.
Runtime Control: Remote application/firmware loading, starting and stopping is required to manage the system.
IPC: Inter Processor Communications needs to be established to enable communication and control.
Resource Isolation: AMP systems can be supervised (e.g. using a hypervisor) or unsupervised.
Topology
The OpenAMP framework assumes a main controller to remote system architecture, but otherwise the topology of the different runtime systems may be star, chain or a combination.
A main controller will control one or more remote cores each on a remote processor (star), and any remote processor could also act as a controller to manage another set of cores on a different remote processor (chain). Each remote could be an individual or multiple cores of a processor.
To exemplify, the following sections use diagrams detailing a star topology with a single Linux main controller and dual remote cores, with one remote core running an RTOS and the other a bare metal image. The choice of operating systems is arbitrary and just for this example.
Resource Assignment
This diagram details the Resource Assignment using a different color for each runtime domain.
The yellow colored boxes are the Linux runtime domain as the main controller running on a single processor, utilizing the two cores in a Symmetric Multiprocessing setup. The green and blue colored boxes details the RTOS and Bare Metal remote applications each running on a single core of a remote processor as their own runtime domain. The Linux system shares memory with both remotes, but the remote applications do not share memory. Each domain owns independent peripherals in the system. Although the Linux domain is SMP, all three runtime domains together make up an AMP system.
Runtime Control
With the domains defined, runtime control of the asymmetric remote applications can be started to handle Life Cycle Management (LCM) of the remotes. The main controller will load and control the images as required. In this example the RTOS image could be loaded at power on to perform say environmental instrument monitoring and the bare metal image on demand to perform some specific high intensity calculations, but stopped on completion for power savings. The control flow will be implementation specific.
Inter Processor Communications
Inter Processor Communications is performed through shared memory and is between main controller and remote. In the example, the IPC could be instrument updates from the RTOS remote to the Linux main controller to display, and independently Remote Procedure Calls (RPC) between the Linux main controller and the other, bare metal, remote responsible for resource intensive calculations.
In this star topology example the remotes cannot communicate with each other. If that were required a chain topology would be used instead to allow one remote to be both a remote and a main controller in which case they could communicate (refer to Architecture Section for an example).
Resource Isolation
Resources isolation is not essential, but the ability to utilise a supervisor, such as a hypervisor, to enforce isolation and allow virtualization is an important fundamental for the OpenAMP Architecture to allow, as some implementations may have it as a safety requirement.
OpenAMP Architecture
The OpenAMP framework utilizes a number of distinct components to achieve the OpenAMP Fundamentals, with most of them using or derived from existing standards or frameworks.
The components comprising OpenAMP are:
AMP Component |
AMP Fundamentals |
|---|---|
Resource Assignment and Runtime Control |
|
Resource Table |
Resource Assignment |
IPC |
|
Hypervisor and Hardware Abstraction |
|
IPC for File Input Output (IO) |
|
Hardware Abstraction |
The topology is limited to main controller to remote system but otherwise open to the implementation.
The architecture is exemplified below via a daisy chained topology, with a main processor controlling a single remote in the chain. This implements the left half of the daisy chain topology detailed in the OpenAMP Fundamentals section, and is the commonly implemented topology.
In an attempt to keep the diagrams clear, not all OpenAMP components are drawn on each processor.
RemoteProc
Runtime Control is part of the Life Cycle Management (LCM) of the remote(s) and performed through the remoteproc component which allows for the loading of the firmwares to the remote processor and starting and stopping the remote.
Resource Assignment is also achieved through the remoteproc component utilizing a Resource Table, which provides the memory and peripheral allocation as well as information for establishing the IPC between associated processors.
RPMsg and Virtio
Standardization of the IPC is promoted by the OpenAMP project through the use of RPMsg, using Open Standard Virtio Devices as a HW abstraction or MAC layer.
This abstraction, using virtio, means that the implementer can optionally use resource isolation (e.g. using a hypervisor or secure context), which is exemplified by the first processor in the architecture diagram.
RPMsg Services
OpenAMP provides higher level IPC components as RPMsg Services. There is a Remote Procedure Cal (RPC) service and Proxy service.
The proxy provides file IO on the remote allowing access to the filesystem on the main controller. This provides a mechanism for remotes to access files occasionally without having to introduce a full filesystem on the remote. In the architecture diagram the center processor remote proxies file IO from its main controller on the left.
The RPC service provides for remote procedure calls from a server to a client. In the architecture diagram the right hand processor has the RPC server servicing the center main controller processor’s RPC client.
Libmetal
Libmetal is a hardware abstraction component, intended to provide for portability across different platforms. Vendors porting OpenAMP will provide an implementation of libmetal for their system.
Read more about the OpenAMP System Components here.
Operating Environments
OpenAMP aims to provide components which are portable and aim to be environment agnostic.
- -The result is that OpenAMP is supported in various operating environments through
an OpenAMP Linux Kernel project, coming through the regular remoteproc/ RPMsg/ Virtio efforts in the kernel.
multiple proprietary implementations.
The operating environments that OpenAMP supports include:
OpenAMP Governance and Guidelines
The OpenAMP Project governance is detailed on the OpenAMP Project Page.
There are a few guiding principles that governs OpenAMP:
- Provide a clean-room implementation of OpenAMP with business friendly APIs and licensing
Allow for compatible proprietary implementations and products
- Base as much as possible on existing technologies/open source projects/standards
In particular remoteproc, RPMsg and virtio
Never standardize on anything unless there is an open source implementation that can prove it
- Always be backwards compatible (unless there is a really, really good reason to change)
In particular make sure to be compatible with the Linux kernel implementation of remoteproc/ RPMsg/Virtio
There are a number of project members as outlined in OpenAMP Project Page as well as many community members, so please join the OpenAMP open source project!