# OpenAMP: messaging between a Linux host and a baremetal remote > open-amp is the OpenAMP library implementing rpmsg, virtio and remoteproc in C, so software on a Linux host and software on an RTOS or baremetal processor can exchange messages and share a filesystem. It needs libmetal ported to your platform, and it builds with CMake rather than the kernel build system. **OpenAMP/open-amp** — The main OpenAMP library implementing RPMSG, Virtio, and Remoteproc for RTOS etc - Repository: https://github.com/OpenAMP/open-amp - Website: https://www.openampproject.org/ - Stars: 926 · Forks: 321 - Language: C - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/openamp-open-amp ## What the framework is for OpenAMP stands for Open Asymmetric Multiprocessing, and the project is the home for the framework of that name. The framework provides software components that enable development of software applications for AMP systems, and the key capabilities are listed as five items. The first is life cycle management and inter processor communication for the management of remote compute resources and their associated software contexts. That is the remoteproc part of the library: loading a remote image, starting and stopping it, and tracking its state. The second capability is that it stands alone as a library usable with RTOS and baremetal software environments, which is what separates it from a kernel subsystem. There is no Linux to run it on the remote side. The third is compatibility with the upstream Linux remoteproc and rpmsg components, and this is the interoperability guarantee that matters most in practice. The remote side of an OpenAMP system speaks the same protocol that the Linux rpmsg virtio driver expects, so a Linux host can treat the baremetal processor much like another remote processor. The fourth capability lists the supported AMP configurations, and there are exactly two: a Linux host with a generic baremetal remote, and a generic baremetal host with a Linux remote. Both directions are supported, which is unusual for a framework of this kind. The fifth is the proxy infrastructure and the supplied demos, which show the ability of a proxy on the host to handle printf, scanf, open, close, read and write calls from baremetal based remote contexts. That is the feature that makes a remote processor feel like a local one for simple file and console operations. ## Four directories under lib/ and what each one does The library libopen_amp is composed of four directories, and the split is by protocol layer rather than by feature. ```bash |- lib/ | |- virtio/ # virtio implementation | |- rpmsg/ # rpmsg implementation | |- remoteproc/ # remoteproc implementation | |- proxy/ # implement one processor access device on the | | # other processor with file operations |- cmake # CMake files |- scripts # helper scripts (such as checkpatch) for contributors. ``` The virtio directory implements the transport, which is the shared memory ring buffer mechanism that carries the messages. The rpmsg directory implements the messaging protocol on top of it, which is the part that gives you named channels and a send and receive API. The remoteproc directory implements the lifecycle control, so the host can load and start a remote image. The proxy directory is the unusual one. Its comment describes it as implementing one processor access device on the other processor with file operations, which is the mechanism behind the printf and file call capability listed in the features. Two other directories complete the picture. The cmake directory holds the CMake files, and the scripts directory holds helper scripts such as checkpatch for contributors, which tells you the project follows kernel style conventions even though it does not use the kernel build system. There is also a note that OpenAMP system and machine support has been moved to libmetal, which is the next thing to understand. ## libmetal is the porting burden This is where the real work is, and the project says so directly. If you want to port OpenAMP for your system, you need to implement the libmetal APIs in the libmetal lib/system/ directory. The list is short and specific. There is alloc for memory allocation and free, cache for flushing and invalidating the cache, io for memory mapping, which OpenAMP requires in order to access the vrings and the carved out memory, irq for handler registration, disable and enable, and global IRQ handling. There is also mutex, shmem, sleep, time, init and atomic. Two of those have explanatory notes that are worth reading. The shmem implementation note says that for RTOS you can usually use the one from lib/system/generic/. The sleep note explains that OpenAMP only requires microsecond granularity sleeps, because when it fails to get a buffer to send a message it calls sleep and then tries again. That tells you something about the transport design, since a producer that cannot get a buffer backs off briefly and retries rather than blocking on a condition variable. If you use a compiler other than GNU gcc, the project points at lib/compiler/gcc/ for the port, and notes that OpenAMP needs the atomic operations defined in lib/compiler/gcc/atomic.h. The reference implementation to copy from is lib/system/generic. For many RTOS ports this is the whole port, and the memory mapping and cache operations are the parts that genuinely differ between silicon. ## Building it with CMake, and libmetal comes first OpenAMP uses CMake for library and demonstration application compilation, and it requires libmetal. For now you need to download and compile libmetal separately before compiling OpenAMP, and the project acknowledges that this is awkward and says it will try to make libmetal a submodule in future. The example given is for communication between Linux processes on a host. You install the libsysfs and libhugetlbfs development packages, then build libmetal into its own directory. ```shell mkdir -p build-libmetal cd build-libmetal cmake make VERBOSE=1 DESTDIR= install ``` Then OpenAMP is built with the include and library paths pointed at the libmetal output. ```shell mkdir -p build-openamp cd build-openamp cmake -DCMAKE_INCLUDE_PATH= \ -DCMAKE_LIBRARY_PATH= make VERBOSE=1 DESTDIR=$(pwd) install ``` The install lands the library in build/usr/local/lib and the headers in build/usr/local/include. For Zephyr there is a separate route. The Zephyr open-amp repository implements the library for the Zephyr project and is mainly a fork of this repository with add-ons for Zephyr integration, and the WITH_ZEPHYR CMake option is described as mandatory in a Zephyr environment. The documented way to build is the standard Zephyr build environment, with examples in the Zephyr samples tree. ## The CMake options that decide what you actually get The option list tells you what the library can be trimmed to, and reading the defaults shows the intended configuration. WITH_PROXY defaults to OFF, so the proxy support is opt-in. WITH_VIRTIO_DRIVER defaults to ON and can be turned off if only the remote mode is implemented, and WITH_VIRTIO_DEVICE defaults to ON and can be turned off if only the driver mode is implemented. Those two options are how you cut the library down to one side of an AMP pair, which matters on a small target where every kilobyte of firmware counts. WITH_VQ_RX_EMPTY_NOTIFY defaults to OFF and is the notify mode switch. When set to ON, notification happens only when there are no more messages in the RX queue. When OFF, it notifies for each RX buffer released. That is a real performance trade-off: notifying only when the queue is empty reduces the number of interrupts on the host, at the cost of latency, because a release does not immediately wake the host. WITH_STATIC_LIB and WITH_SHARED_LIB both default to ON, so both library forms are produced by default. WITH_DCACHE defaults to OFF and, when ON, enables cache operations for vrings, buffers and the resource table, which you need on a platform with a data cache where the shared memory region is not coherent. The one with a hard constraint is RPMSG_BUFFER_SIZE, default 512, which adjusts the size of the RPMsg buffers. The default value is compatible with the hard coded value in the Linux kernel, and if the configuration is a Linux kernel host with an OpenAMP remote, this option must not be used. The Linux side hard codes the buffer size, so changing it on the remote produces a mismatch that will not fail cleanly. ## Demos, documentation and how the project is governed The example applications have moved to a separate repository, openamp-system-reference, which is described as a new repository for the OpenAMP demos. Project documentation lives at readthedocs, published from the doc/ directory in this repository. The repository root carries the files you would expect from a project with kernel style conventions: a LICENSE.md, MAINTAINERS.md, a VERSION file, a CMakeLists.txt at the root, a cmake/ directory, a .checkpatch.conf and a .gitlint. The checkpatch configuration and the gitlint file are worth noting because they enforce commit message and patch style rules automatically, which is why the contribution guidance focuses on the mechanics of submitting a clean patch. Licensing is handled in a way kernel contributors will recognise. The guidance explains that code is contributed to the Linux kernel under a number of licenses, but all code must be compatible with the BSD License that covers the OpenAMP distribution as a whole, and in practice contributors should use a short SPDX tag in each file rather than the full license text. The two tags given are BSD-3-Clause and BSD-2-Clause. The Signed-off-by requirement is stated as well: a commit message must contain a Signed-off-by line and the email must match the change authorship information, which means your git configuration has to be correct before you commit. ```shell git config --global user.name "first-name Last-Namer" ``` ## Where OpenAMP is the wrong choice The framework is narrow by design, and several common needs fall outside it. If both sides of your system run Linux, OpenAMP buys you nothing. The remoteproc and rpmsg subsystems in the kernel already do this job, and using OpenAMP there means reimplementing what you have. If your requirement is shared memory between two processors running different operating systems that are not Linux and not baremetal, the supported configurations do not cover it. The documented list is a Linux host with a baremetal remote and a baremetal host with a Linux remote, and while the code is portable, portability is not the same as a tested configuration. There is also a cost in the layering. OpenAMP sits on libmetal, which you must port to your platform, and the memory mapping and cache coherency work is the part that hardware engineers actually get stuck on. Budget for that port rather than for the OpenAMP API itself, which is small. Finally, consider the maintenance model. The releases follow a date based version scheme, with v2026.04.0 corresponding to v1.10.0, v2025.10.0 to v1.9.0 and v2025.04.0 to v1.8.0, so the year and month of the release identify the upstream base and the minor version moves within it. The repository is not archived and the last push was on 2026-10-19, so the project is active, but a library that sits in firmware should be pinned to a release you have qualified rather than tracked on a branch. ## Conclusion Adopt open-amp when you are bringing up an AMP system where a Linux host and a baremetal or RTOS remote must exchange rpmsg messages, because it supplies the remoteproc lifecycle, the virtio transport and the rpmsg layer that the Linux side already speaks, so interoperability is built in rather than hand rolled. Do not adopt it if you need the Linux remoteproc and rpmsg drivers themselves, since compatibility with them is the goal rather than a replacement, and expect real porting work on new hardware since libmetal has to be implemented for your platform first. Verify first that your processor configuration is one of the two supported ones, that you have ported the libmetal APIs the library calls, and that you check the RPMSG_BUFFER_SIZE constraint before changing it, because it is tied to a hard coded value in the Linux kernel. ## FAQ ### What does open-amp provide? It provides life cycle management and inter processor communication for remote compute resources, a standalone library usable with RTOS and baremetal environments, compatibility with the upstream Linux remoteproc and rpmsg components, support for both a Linux host with a baremetal remote and a baremetal host with a Linux remote, and a proxy layer for printf, scanf, open, close, read and write calls from baremetal contexts. ### What do I need to port to use open-amp on my hardware? You need to implement the libmetal APIs in the libmetal lib/system/ directory: alloc, cache, io for memory mapping, irq, mutex, shmem, sleep, time, init and atomic. The project points at lib/system/generic as the reference, and notes that for RTOS the generic shmem implementation is usually usable. ### How do I build open-amp for Linux host communication? Install the libsysfs and libhugetlbfs development packages, build libmetal separately with CMake into a build-libmetal directory, then build OpenAMP with cmake pointing CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH at the libmetal output. The install lands the library under build/usr/local/lib and the headers under build/usr/local/include. ### Can I change RPMSG_BUFFER_SIZE in open-amp? Only in certain configurations. The default of 512 is compatible with the hard coded value in the Linux kernel, and the documentation states that if the configuration is a Linux kernel host with an OpenAMP remote, this option must not be used. ## Sources - [Issues](https://github.com/OpenAMP/open-amp/issues) - [OpenAMP/open-amp on GitHub](https://github.com/OpenAMP/open-amp) - [Project website](https://www.openampproject.org/) - [README](https://github.com/OpenAMP/open-amp/blob/main/README.md) - [Releases](https://github.com/OpenAMP/open-amp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openamp-open-amp