Back to
Blog

How To Use The OpenAMP Framework For Heterogeneous Devices, Part 2

OpenAMP provides a software framework to developers that they can utilize to manage firmware across a multi-processor system and establish communication between the processors. In part 1 of our post, we looked at Linux AMP and some of the challenges associated with heterogeneous software architecture before examining what OpenAMP is. In this second part, we will look closer at what you need to know about using OpenAMP with heterogeneous devices.

We will cover topics such as topology, the start-up process, the API, and vendor support.

Getting started with the OpenAMP framework

The OpenAMP project can be found at github.com/OpenAMP and includes example code. While early examples targeted two Cortex-A cores, more recent examples demonstrate heterogeneous AMP.

Here’s what developers need to know before getting started with OpenAMP.

Topology

  • Both star and daisy chain topologies are supported, or any combination thereof. The CPU with dual-responsibility (remote & master) provides chaining.
  • Linux is not required to be on any CPU.
  • Linux is not required to be the master. However, note that Linux as remote is currently only supported between Cortex-A cores.

OpenAMP = Unsupervised AMP

  • OpenAMP offers unsupervised AMP. The framework is embedded into the application and/or OS code. There are no natural isolation benefits, such as those provided by a hypervisor.
  • The designer, consequently, has more responsibilities. This include partitioning memory, partitioning devices, and failure recovery.

Start-Up Process

  • The framework assumes the master is already running and the remote processor is in some sort of standby or powered down state.
  • The master loads firmware for remote processor into memory based on configuration information embedded into firmware.
  • The master then starts remote processor and waits for it to initialize. For example, wake-up, release from reset, power-on, etc.
  • The master is notified when initialization is complete and then establishes a RPMsg communication channel to the remote processor.

OpenAMP RemoteProc API

The OpenAMP RemoteProc API issues remote procedure calls. The actual API is fairly straightforward.

  • API calls for master
  • remoteproc_init
  • remoteproc_deinit
  • remoteproc_boot
  • remoteproc_shutdown
  • API calls for remote
  • Remoteproc_resource_init
  • Remoteproc_resource_deinit

Header files provided by the framework include configuration parameters that developers can customize. For example, how long a master should wait after starting a remote.

OpenAMP RPMsg API – interprocessor communication

The RPMsg API is responsible for interprocessor communication. Like the OpenAMP RemoteProc, this is also fairly straightforward.

Example of RPMsg Available Functions

 

  • The framework must be ported to a specific architecture and/or device.
  • Special structures must be populated and embedded into the user code.
  • Remote firmware must be accessible to the master.
  • (Linux only) The Linux RPMsg driver must be ported to support remote processors.

Completing the API

  • The OpenAMP framework includes a Hardware Interface Layer (HIL); think HAL, but with an ‘I’. The HIL declares functions and structures that must be filled in. For example, the hil_platform_ops structure in hil.h declares platform operations/functions
  • Platform-specific functions and structures are kept separate from the baseline framework. These are given a specific location in the source structure; for example, lib/system/. Alternatively, they are incorporated into remote application; for example,  rsc_table.c.

Resource Table

  • A resource table must be included with the remote application. The C structure is declared by HIL and the application supplies information (e.g., rsc_table.c).
  • The resource table includes some essential information for the master, including firmware carve-out requirements and VirtIO device information.
  • The framework includes a mechanism for the master to retrieve this information from the remote FW.

What vendor support is available for OpenAMP?

Commercial OpenAMP is now available for NXP, TI, and Xilinx devices.

Typically, we are seeing the following when it comes to current vendor support for OpenAMP.

  • Vendor handles the low-level porting/targeting for their specific platform(s)
  • Vendor supplies example applications for their platform(s)
    • Application includes demonstration of resource table
    • Example application demonstrating basic IPC (e.g., echo)
    • Example application demonstrating master off-loading
  • Vendor supplies Linux RPMsg driver for their platform(s)
  • Vendor supplies example kernel module and userspace application for interacting with remote device

Things to keep in mind about the OpenAMP framework

  • The project is still in its infancy; source structure is still fluctuating and standardization is a work in progress.
  • Commercial support for several platforms is available, but openly available ports are limited.
  • Porting of the framework still necessary for many commonly used platforms.
  • The existing examples make porting to other ARM-based SoCs easiest.
  • IPC performance needs improvement (WIP).
  • It is not possible to attach to running remote processor.

Conclusion

OpenAMP provides a software framework to developers that they can utilize to manage firmware across a multi-processor system and establish communication between the processors.  The framework provides these features in a platform agnostic manner, once the device-specific components of the framework have been ported.  Existing ports, whether commercially available or open-source, are currently limited, but enough open source code is available to ease future adoption and standardization from the MCA will, additionally, help make porting efforts more future-proof.