• About Us
    • History
    • Mission
    • Team
    • Partners & Memberships
    • Customer Stories
  • Applications
    • Video
    • Automotive
    • Aerospace & Defense
    • Industrial
    • Telecommunications
  • News
    • Press Releases
    • Blog
    • Events
  • Careers
  • Contact
  • LinkedIn
  • Twitter
  • Engineering
    • FPGA & ASIC Design
    • FPGA & ASIC Verification
    • ASIC Prototyping
    • Digital Signal Processing
    • Embedded Software Design
    • Electronic System-Level Design
    • Power / Signal Integrity Analysis
    • System & Hardware Architecture
  • IP Products
    • Why Choose Hardent IP Products?
    • VESA DSC IP Cores
    • VDC-M IP Cores
    • DisplayPort 1.4 IP Subsystem
    • HDMI 2.1 IP Cores
    • ECC/Reed-Solomon FEC IP Cores
    • Mathematically Lossless Video Compression IP Cores
  • Training
    • Training Schedule
    • Training Courses
      • Xilinx Training
      • Verification Training
      • Complete Course List
    • Training Formats
      • Classroom Training
      • Private Training
      • Live Online Training
      • On-Demand Training
Back to
Blog

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

July 19, 2017

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.

Latest News
Contact Us
Hardent Announces Availability of New Xilinx Versal ACAP Training Courses
New Xilinx Versal ACAP training courses will cover all aspects of designing with the latest Xilinx device category.
More
Hardent Announces Expansion of Xilinx Training in the USA
Hardent selected by Xilinx to be the new Xilinx training provider in four U.S. states.
More
Hardent and PLC2 Announce New IP Partnership to Support German Semiconductor Companies
PLC2 named as the official IP representative for Hardent’s video compression IP cores in Germany, Austria, and Switzerland.
More
Upcoming Sessions
Jan 26–28
Designing with the Zynq UltraScale+ RFSoC
Register
Jan 26–28
Vivado Design Suite Advanced XDC and Static Timing Analysis with Design Methodology
Register
Jan 27–28
Designing with Versal AI Engine 2
Register
Feb 01–04
Introduction to UVM
Register
Complete Course Schedule
Contact Hardent
Simon Robin
President
Linked-in
HardentMontreal
450 rue Saint-Pierre, suite 300
Montreal
,
QC
H2Y 2M9
Canada
T +1 (514) 284-5252
F +1 (514) 284-5052
Tick to hear more from Hardent by email. This includes our newsletter, details about offers, new courses, and events. You can opt out at any time. For further information, please refer to our privacy policy.

Having worked in the past with independent electronic design consultants, we appreciate Hardent’s quality, team work and timely service. The company has excellent project management skills, open communication, constant follow-up and a flexible approach. We have been working with Hardent for about two years now. Though initially I was not excited about outsourcing R&D, I feel that I can 100% count on Hardent, as they know their business well and they directed us toward good technical decisions.

Michel Bitar
R&D/ I.T Manager
Prodco International Inc.
More testimonials
Partners & Memberships
Xilinx APC logo
mipi member logo
VESA
Hardent © 2002-2021.
All rights reserved.
  • Privacy Policy
We use cookies to ensure that we give you the best experience on our website. By continuing to use this website, you consent to our use of cookies. OK