In our OpenAMP webinar last month, we looked at the OpenAMP framework and outlined how it can be used to navigate the complex software architecture of heterogeneous devices. Find out in this article how to use OpenAMP to assist with development and interactions between cores!
In this post, we will introduce the concepts of Linux AMP and some of the challenges associated with heterogeneous software architecture, before presenting the OpenAMP framework itself. A follow-up post will show how you can get started with using OpenAMP for Zynq SoCs and MPSoCs.
Heterogeneous (multi-processor) devices
Single, high-performance embedded processors are often not adequate to meet today’s SoC demands for sustained high-performance and efficiency. As a result, chips increasingly feature multiple processors of varying architectures to deliver flexible compute power, real-time features, and energy conservation requirements.
These heterogeneous (multi-processor) devices yield an extremely robust SoC, but also require a more complex software architecture capable of orchestrating multiple dissimilar processors. Heterogeneous SoCs are by no means a “new” concept, but in the past developers generally only had “raw” access to one processor architecture, on which firmware could be run, with other architectures abstracted away through libraries or tools. Now, however, we’re seeing chips that give the developer direct access to multiple architectures. The Xilinx Zynq UltraScale MPSoC is one such example; this chip has four ARM Cortex-A53 cores, two Cortex-R5 cores, as well as additional MicroBlaze “soft” processor cores.
With the increasing complexity of managing multiple processors and architectures on these devices, the OpenAMP framework can be used to facilitate development and interactions between cores.
Linux Asymmetric Multiprocessing (AMP)
In order to understand OpenAMP, we first need to understand the concept of Linux Asymmetric Multiprocessing (AMP) on multi-core and heterogeneous devices.
Introduced into the Linux kernel c. 2011, based on work for TI OMAP 4 (Quad-core Cortex-A9 + Cortex-M3), the Linux frameworks called RPMsg (Remote Processor Messaging) and RemoteProc (Remote Processor) provide support for using Linux to run firmware on additional ‘remote’ processors in a device.
Example of an AMP system with Linux as the master
Linux RemoteProc is a framework that allows a Linux master to control/manage remote processors (power on/off, reset, and load firmware). A RemoteProc driver is used for lifecycle management of remote firmware.
The Linux RemoteProc framework:
- Provides an API for control of remote processor through driver code.
- Abstracts hardware differences between involved processors.
- Establishes communication channels between master and remote processors using the RPMsg framework.
- Declares a minimal set of device-specific low-level handlers.
Linux RPMsg is a messaging framework that provides inter-processor communication (IPC) between kernel drivers and remote processors. An RPMsg driver represents a communication channel between the Linux master and a specific remote processor.
The Linux RPMsg framework:
- Defines only vendor agnostic aspects of communication such as API and the format of messages.
- Relies on RemoteProc for device-specific handlers.
- Can leverage existing code developed for messaging between VMs.
Heterogeneous software architecture: more cores = more complexity
Using only the Linux AMP framework, however, becomes more complicated when designers try to ensure communication between multiple processors and architectures. Device-specific features, such as cache subsystems, shared memory, inter-processor interrupts, and dissimilar processor architectures, add to the complexity of coordinating different software platforms on the various processors.
Increased levels of complexity on a multi-core SoC
Designers are faced with a number of challenges.
- The Linux framework only covers Linux kernel code and no bare-metal, or low-level counterpart code.
- The master may not be not Linux. For reliability reasons, the master may be an RTOS. The slave could be similar (Standalone/RTOS) or even Linux.
- Who fills in the low-level device-specific code?
Enter the OpenAMP framework…
This is where the OpenAMP framework comes in! The framework extends support for the RemoteProc and RPMsg components beyond Linux and into the world of bare metal and RTOS systems. It also plays a key role in helping developers abstract the device-specific behavior mentioned previously.
Examples of the OpenAMP framework in a real-time operating system (RTOS)
What is the OpenAMP framework?
The OpenAMP provides an open source framework that allows operating systems to interact within a broad range of complex homogeneous and heterogeneous architectures and allows asymmetric multiprocessing applications to leverage parallelism offered by the multicore configuration.
Source: The Multicore Association
Originally a joint effort from Mentor Graphics and Xilinx, OpenAMP has been an open source project since 2014. The OpenAMP framework is now managed by The Multicore Association and a working group was established in 2016 in order to ensure standardization.
Now that we have looked at what OpenAMP is, in part 2 we will take a closer look at how to use it. We’ll be covering key points for getting started with OpenAMP including topology, the start-up process, the API, and vendor support. Stay tuned for the next installment coming soon!