Why You Should Use OpenAMP to Isolate Critical Software Processes

Posted on April 16, 2020 by Jeff Kubascik

No, OpenAMP is not some community project to design the next guitar amplifier. Instead, it stands for Open Asymmetric Multi-Processing, an open source framework that provides software tools for developing applications in systems with multiple processors.

The framework is maintained by the OpenAMP project, which includes members from companies such as Xilinx, ARM, Linaro, STMicroelectronics, Texas Instruments, Nordic Semiconductor, and Wind River. Within the Xilinx ecosystem, OpenAMP is supported on both the Zynq-7000 SoC and Zynq UltraScale+ MPSoC.

Heterogenous System-on-Chip (SoC) platforms like those from Xilinx rely on a combination of applications and real-time processors.
Heterogenous System-on-Chip (SoC) platforms like those from Xilinx rely on a combination of applications and real-time processors.

What is OpenAMP?

First off, you may be wondering, what exactly is Asymmetric Multi-Processing (AMP)? A computer system is considered asymmetric when it contains multiple processors and not all of them are “treated equally.” Typically, this means that there is no single unified operating system or task scheduler managing all processing resources in the system. This is the compliment of Symmetric Multi-Processing (SMP), where a single operating, such as Linux, is responsible for scheduling tasks across all processors. AMP is commonly applied in heterogenous System-on-Chip (SoC) platforms, where there is a mixture of application and real time processors.

The OpenAMP framework is built upon a foundation known as libmetal. The libmetal library provides an abstraction layer that hides the details of the underlying operating system or processor architecture. This enables the OpenAMP library to be portable across platforms such as Linux, FreeRTOS, and baremetal. It also provides the benefit of allowing your applications and libraries to be portable as well.

There are three important components of the OpenAMP framework that you should be aware of. They are virtio, rpmsg, and remoteproc.

  • Virtio is a virtual device framework that provides shared memory management. Virtio is a standard that comes from the Kernel-based Virtual Machine (KVM) project for para-virtualized network and disk drivers, where drivers are aware that they are running in a virtualized environment. In this case, though, a virtio device is aware that it is running in an OpenAMP environment. Data is shared through virtio rings, which are FIFO queues of buffer pointers to the data. Virtio is a great solution for working with large chunks of data or streaming data.
  • Rpmsg is a virtio-based messaging bus that enables inter-processor communications in an AMP system. It enables your application to send and receive variable length binary message data, with the message format to be defined by the application. A rpmsg device is known as a communication channel, and is identified by a unique textual name. Each channel has a local source address and remote destination address. Rpmsg is well suited for exchanging asynchronous control and event messages with remote processors.
  • Remoteproc provides APIs for life cycle management of remote processors. It has the ability to load firmware, start, and stop the remote processor. It is also able to automatically probe drivers for virtio and rpmsg devices, based on a device table located in the firmware file.

Why Asymmetric Computing?

Back to the question at hand, why should you consider asymmetric computing? And why should you use OpenAMP? While general purpose application processors are more powerful than ever, they are not well suited for many real-time applications. Moreover, general-purpose operating systems such as Linux were not specifically designed for correctness and determinism; a no-go in applications with stringent safety or security requirements. But these operating systems bring a large complement of capabilities and libraries that cut down significantly on product development time; for example, a full networking stack or graphical user interface library.

Heterogenous computing provides the convenient middle ground, where critical code is segregated to dedicated processors, giving you the benefits of both worlds. However, segregating your design like this comes with the problem of how to mesh your applications together across processors and operating systems. Such a design would use interfaces that are above and beyond what most operating systems APIs provide, requiring you to develop a custom implementation. This is where OpenAMP comes in, providing an established framework for AMP lifecycle management and the exchange of data between processors.

Out of the box, OpenAMP is supported on Linux, FreeRTOS, and baremetal platforms. Additionally, DornerWorks has previously demonstrated OpenAMP working on both the seL4 microkernel and Xen hypervisor.

Powerful computing platforms like the Xilinx Zynq UltraScale+ MPSoC can take advantage of OpenAMP to run real-time applications more efficiently, and separate critical and non-critical processes.
Powerful computing platforms like the Xilinx Zynq UltraScale+ MPSoC can take advantage of OpenAMP to run real-time applications more efficiently, and separate critical and non-critical processes.

How Do I Use OpenAMP?

Let’s use an example to demonstrate how OpenAMP could be used in an application.
Say we want to implement a networked industrial robotic controller on the Xilinx Zynq UltraScale+ MPSoC, which contains a quad core Cortex A53 Application Processor Unit (APU) and a two Cortex-R5 Real-time Processor Units (RPU). We could split the application design so that real-time motion control of the robot arm runs on the RPU with FreeRTOS, as this application must meet hard deadlines for control and safety protections to prevent harm to people and equipment. We can then use Linux on the APU to take advantage of a fully featured network stack and accelerate development efforts while minimizing the scope of the safety and real-time requirements.

In this design, Linux will boot up first on the APU. We could develop a Linux application named “robot-control” responsible for managing the remote processor, receiving network traffic, and generating coarse position coordinates. This application could use the remoteproc APIs during initialization to read a firmware file from the filesystem, load it into memory, and kick off the RPU. This design makes updating the RPU firmware simple, as it is a matter of updating a file on the Linux filesystem.

For our system, we will need two data paths between the robot-control and RPU applications. The first is a virtio device that streams the position coordinates from the robot-control application to the RPU application. The robot-control application can buffer several seconds worth of this position data to smooth out any jitter from the network or Linux kernel and guarantee the buffer is never empty. The RPU application can then read one coordinate at a time from the virtio stream in real-time and perform its motion control algorithm.

The second data path could be an event and control channel for asynchronous messaging both ways between the robot-control and RPU applications. This would enable the robot-control application to send control messages to the RPU application such as start, stop, set/get configuration, and poll status. It would also enable the RPU to issue asynchronous events to the robot-control application such as run state changes and fault codes.

This design goes a long way to separating critical and non-critical code and minimize development efforts. However, alone it does not guarantee isolation of these two components. For instance, it is possible for a critical flaw or vulnerability in the Linux kernel to cause it to interfere with the RPU application, such as overwriting memory. This is where SoC architecture can help; for instance, the Xilinx Zynq UltraScale+ MPSoC provides several features to provide hardware isolation.

  • Xilinx Peripheral Protection Unit: Limit which processors can access a peripheral
  • Xilinx Memory Protection Unit: Limit regions of memory to certain processors
  • System Memory Management Unit: Limit memory accessible by a peripheral
  • Arm Trusted Firmware: Separation of privileged or critical functions into a “secure zone”
  • QoS Control: Set priorities for memory bus traffic from processors and peripherals to provide real-time guarantees when there is resource contention

I’m Sold – How Do I Get started?

OpenAMP is open source and free to use under the BSD 2 or 3 clause license, making it an easy choice for your application. However, it is just one piece of the puzzle for AMP – to ensure that your design is meeting critical safety or security requirements requires full understanding of the SoC architecture. This is where DornerWorks comes in, with extensive experience in SoC architectures such as the Xilinx Zynq UltraScale+ MPSoC to guide you to a stronger business.

Contact us today and schedule a free meeting.

Jeff Kubascik
by Jeff Kubascik
Embedded Engineer
Jeff Kubascik is an embedded engineer at DornerWorks.