OpenAMP brings control to multicore SoCs
The Multicore Association has begun standardization of a set of interprocessor communications mechanisms intended to make it easier to have the multiple processor cores on an SoC cooperate with each other and which will fit naturally into existing Linux-based environments.
OpenAMP borrows applications programming interfaces (APIs) from Linux and uses them to support communications with cores running software either on bare metal or a real-time operating system (RTOS). Rather than start from scratch, the working group is using a code base that is already available on Github and which has been used by Mentor Graphics for its Nucleus RTOS.
Felix Baum, Mentor product manager, said: “We see two trends emerging. First, there are more and more processor cores in the silicon. And we are seeing companies such as Xilinx use different cores together. An example is the MPSoC: there are four ARM Cortex-A53 cores, two Cortex-R5 cores and also, because it’s an FPGA, the fabric can be used to create Microblaze soft cores. How do you configure the operating systems on each of those? And how do they communicate with each other?”
Linux-oriented API
The key decision for the group creating the infrastructure for a multicore, multiple operating-system communication and configuration scheme was to decide on an API model for interprocessor communication that could underpin both requirements.
“A lot of projects use Linux for at least one operating system in their embedded systems. Going to Linux folks and telling them to transition to some proprietary method for embedded? That’s really hard. So we looked at Linux and picked capabilities that are already present in a mainstream Linux kernel,” Baum said.
The developers of the initial code base that feeds into OpenAMP selected virtio and rpmsg for interprocessor communication and remoteproc for issuing remote procedures calls.
“We know that Freescale, Wind River, and Micrium are already using it. They have already been fixing bugs and feeding back patches to move the technology forward,” Baum said.
An issue for some developers of commercial embedded systems is the General Public License (GPL) used by Linux distributions, which demands that code improvements made by a user be supplied in source-code form to others.
Cleanroom option
“We created cleanroom implementations so that people can use the code and build it into their own operating systems. We did that for Nucleus,” Baum said.
Xilinx software product manager Fahd Abidi said: “The cleanroom implementation is supplied using a BSD licence. It provides the advantage that vendors can take the reference code and supply it with their own proprietary software licence. Often, the end customers don’t want an open-source licence.”
The virtio API provides the ability for tasks to exchange data across processors using a shared-memory model, although the underlying SoC framework might implement it using two discrete memory areas and by passing messages across an on-chip network.
“We looked at shared memory as being the lowest common denominator. Every SoC has shared memory between cores but if a vendor has a fast communications fabric underneath, they can replace that,” Baum explained. “To the software developer, the details should be irrelevant: this hides the hardware implementation details.”
Core setup and control
Baum said the remote procedure call functions would be useful in a number of ways. They can be used to send operating-system and application images to a processor. Potentially the code could be encrypted with the Linux processor supplying the image and then issuing a call to the target to decode the image using its private key. “This way, all the passwords are secure even if the Linux part is at risked of being hacked,” he said.
The on-demand loading of images supports coarse-grained power management. A processor may sit dormant for long periods and, once it is needed, is provided with a software image that it runs to completion before powering down again.
“In another situation, you might have a core that wants to use resources that aren’t normally available to it. For example, if you want a core to run a ‘hello world’ application but it doesn’t have access to the serial port, it can execute the ‘hello world’ code using a printf statement that initiates communication with Linux. The Linux processor acts as its proxy, using its serial driver to write the text to the UART,” Baum explained.
Abidi added: “For Xilinx, it’s very interesting to us. We have in our MPSoC a Mali GPU. The GPU is accessible from the A53 but we find that customers are interested in accessing it from the R5 cores. OpenAMP provides the infrastructure to pipe data to the Linux processor and on to the GPU. We see OpenAMP as a way not only of implementing management but also device-driver sharing between operating systems.”
