OpenAMP · sipke · Feb 16, 2025 · Feb 16, 2025 · Feb 16, 2025 · Feb 16, 2025
diff --git a/demos/inter_process.rst b/demos/inter_process.rst
@@ -4,7 +4,7 @@
 Running Demos as Processes on Linux
 ===================================
 
-The `OpenAMP project examples <https://github.com/OpenAMP/open-amp/tree/main/apps/examples>`_
+The `OpenAMP project examples <https://github.com/OpenAMP/openamp-system-reference/tree/main/examples>`_
 are intended to execute on the remote of a reference board but can also be demonstrated by implementing as a process on the main controller, effectively emulating a remote.
 
 This can be useful for demonstration purposes, but can also be leveraged for component testing, even as part of a continuous integration setup.

diff --git a/demos/reference_boards.rst b/demos/reference_boards.rst
@@ -12,4 +12,5 @@ In general the OpenAMP feature being exemplified is found in the `OpenAMP source
    docker_images
    system_reference-AMD-Xilinx
    system_reference-ST
+   system_reference-NXP
    inter_process
diff --git a/demos/rpmsg_multi_services.rst b/demos/rpmsg_multi_services.rst
@@ -157,3 +157,7 @@ This RPMsg Multi Services Sample is demonstrated in the following reference impl
 
    * Refer to `Zephyr Build Instructions <https://github.com/OpenAMP/openamp-system-reference/tree/main/examples/zephyr/rpmsg_multi_services>`_.
    * Refer to `example demo script <https://github.com/OpenAMP/openamp-demo/blob/main/demos/demo-stm32mp157c-dk2/my-extra-stuff/home/root/demo1>`_.
+
+* :ref:`NXP <reference_board_NXP>`
+
+   * Refer to Application Note `AN13970 Running Zephyr RTOS <https://www.nxp.com/docs/en/application-note/AN13970.pdf>`_
diff --git a/demos/system_reference-NXP.rst b/demos/system_reference-NXP.rst
@@ -0,0 +1,13 @@
+
+
+.. _reference_board_NXP:
+
+====================
+NXP Reference Boards
+====================
+
+A number of the `OpenAMP project examples <https://github.com/OpenAMP/openamp-system-reference/tree/main/examples>`_ can be executed on NXP Reference boards.
+
+* NXP `8MPLUSLPD4-EVK <https://www.nxp.com/design/design-center/development-boards-and-designs/8MPLUSLPD4-EVK>`_.
+
+The `AN13970 Running Zephyr RTOS on Cadence Tensilica HiFi 4 DSP <https://www.nxp.com/docs/en/application-note/AN13970.pdf>`_ application note provides instructions for setting up the evaluation board.
diff --git a/index.rst b/index.rst
@@ -16,6 +16,7 @@ Welcome to the OpenAMP Project Documentation
    tools/index
    protocol_details/index
    docs/index
+   openamp/glossary
 
 Indices and tables
 ==================

diff --git a/openamp/contributing.rst b/openamp/contributing.rst
@@ -4,38 +4,10 @@
 Contributing to the OpenAMP Project
 ===================================
 
-Release Cycle
--------------
-- Release branch (feature freeze) cut 1 month before release target
-- Maintainence releases are left open-ended for now
+You are encouraged to contribute to the OpenAMP project to help create a successful solution through a vibrant and engaged community.
 
-Roadmap discussion and publication
-----------------------------------
-- Feature freeze period of a release used for roadmap discussions for next release
-- Contributors propose features posted and discussed on `mailing list <https://lists.openampproject.org/mailman3/lists>`_
-- Maintainer collects accepted proposals
-- Maintainer posts list of development tasks, owners, at open of release cycle
+Contribution process and guidelines are provided in the project's `Governance Page <https://www.openampproject.org/governance/>`_.
 
-Patch process
--------------
-- Pull request on github for review and merging
-   - Against `OpenAMP main branch <https://github.com/OpenAMP/open-amp/tree/main>`_
-   - Against `libmetal main branch <https://github.com/OpenAMP/libmetal/tree/main>`_
-- Maintainer ensures a minimum of 1 week review window prior to merge
+You can contribute, through pull requests, directly to the main `OpenAMP libraries <https://github.com/OpenAMP>`_ or propose your platform as a reference platform.
 
-Platform maintainers
---------------------
-- Platform code refers to sections of code that apply to specific vendor's hardware or operating system platform
-- Platform maintainers represent OS or hardware platform's interests in the community
-- Every supported OS or hardware platform must have a platform maintainer (via addition to MAINTAINERS file in code base), or patches may not be merged.
-   - `OpenAMP Maintainers <https://github.com/OpenAMP/open-amp/blob/main/MAINTAINERS.md>`_
-   - `libmetal Maintainers <https://github.com/OpenAMP/libmetal/blob/main/MAINTAINERS.md>`_
-- Support for an OS or hardware platform may be removed from the code base if the platform maintainer is non-responsive for more than 2 release cycles
-- Responsible for verification and providing feedback on posted patches
-- Responsible to ACK platform support for releases (No ACK => platform not supported in the release)
-
-Push rights
------------
-- Push rights restricted to the Core Team
-- Generally exercised by the maintainers for each repository
-- Maintainers manage delegation between themselves
+If you want to contribute by porting OpenAMP to your platform read more about OpenAMP porting :ref:`here<porting-guide-work-label>`.
diff --git a/openamp/glossary.rst b/openamp/glossary.rst
@@ -0,0 +1,22 @@
+========
+Glossary
+========
+
+.. csv-table:: Glossary
+   :header: "Acronym", "Description"
+   :widths: 20, 200
+
+    AMP, `Asymmentric Multiprocessing <https://en.wikipedia.org/wiki/Asymmetric_multiprocessing>`_
+    API, Application Interface
+    GPL, `GNU General Public License <https://en.wikipedia.org/wiki/GNU_General_Public_License>`_
+    IPC, `Inter-Processor Communications <https://en.wikipedia.org/wiki/Inter-process_communication>`_
+    LCM,  Life-Cycle Management
+    OALK, OpenAMP Linux Kernel
+    OAOS, `OpenAMP Open Source Project <https://github.com/OpenAMP>`_
+    OAPI, OpenAMP Proprietary Implementations
+    RPC, :ref:`Remote Procedure Calls (RPC)<overview-proxy-rpc-work-label>`
+    RTOS, Real Time Operating System
+    RPMsg, `Remote Processor Messaging <https://en.wikipedia.org/wiki/RPMsg>`_
+    SMP, `Symmetric Multiprocessing (SMP) <https://en.wikipedia.org/wiki/Symmetric_multiprocessing>`_
+    SoC, System on Chip
+    Virtio, Virtual Input Output
diff --git a/openamp/overview.rst b/openamp/overview.rst
@@ -8,28 +8,37 @@ OpenAMP Intro
 
 `Asymmetric Multiprocessing (AMP) <https://en.wikipedia.org/wiki/Asymmetric_multiprocessing>`_ involves the management, control and communication of multi-core computer systems, where processors have independent tasks and are often in a `heterogeneous <https://en.wikipedia.org/wiki/Heterogeneous_computing>`_ embedded environment where there are different types of processors. This is in contrast to `Symmetric Multiprocessing (SMP) <https://en.wikipedia.org/wiki/Symmetric_multiprocessing>`_ which involves central control and load sharing using identical processor cores and is common place in servers and desktop computers.
 
-The **OpenAMP** project is a community effort that is standardizing and implementing how these multiple embedded systems interact with each other in an AMP environment. It provides conventions and standards as well as an open source implementation to facilitate AMP development for embedded systems.
+The **OpenAMP** project is a community effort that is promoting and implementing how these multiple embedded systems interact with each other in an AMP environment. It provides conventions and open source implementation to facilitate AMP development for embedded systems.
 
 The vision is that regardless of the operating environment/operating system, it should be possible to use identical interfaces to interact with other operating environments in the same system.
 
-Furthermore, these operating environments can interoperate over a standardized protocol, making it possible to mix and match any two or more operating systems in the same device.
+Furthermore, these operating environments can interoperate over a common protocol, making it possible to mix and match any two or more operating systems in the same device.
 
 Read more about Asymmetric Multiprocessing :ref:`here<asymmetric-multiprocessing-work-label>`.
 
 
+*******
+History
+*******
+
+Texas Instruments’ remoteproc and RPMsg infrastructure available in the upstream Linux kernel enable the Linux applications running on a host processor to manage the life cycle of remote processor/firmware and perform IPC with them. However, there was no open- source API/software available that provided similar functionality and interfaces for other possible software contexts (RTOS- or bare metal-based applications) running on the remote processor to communicate with the Linux host. Also, AMP applications may require RTOS- or bare metal-based applications to run on the host processor and be able to manage and communicate with various software environments (RTOS, bare metal, or even Linux) on the remote processor.
+
+The OpenAMP Framework fills these gaps. It provides the required LCM and IPC infrastructure from the RTOS and bare metal environments with the API conformity and functional symmetry available in the upstream Linux kernel. As in upstream Linux, the OpenAMP Framework's remoteproc and RPMsg infrastructure uses virtio as the transport layer/abstraction.
+
+
 ************
 Project Aims
 ************
 
 To provide a solution to cover the :ref:`AMP Fundamentals<openamp-fundamentals-work-label>`, the OpenAMP project is divided into the following efforts:
 
-    * A standardization group under Linaro Community Projects
-        - Standardizing the low-level protocol that allows systems to interact (:ref:`more info here<rpmsg-protocol-work-label>`)
-            + Built on top of the `Virtio Open Standard <https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html>`_
-        - Standardizing on the user level APIs that allow applications to be portable
+    * A guidance group under Linaro Community Projects
+        - Provides guidance for the low-level protocol that allows systems to interact (:ref:`more info here<rpmsg-protocol-work-label>`)
+            + Built on top of the `Virtio Open Standard <https://docs.oasis-open.org/virtio/virtio>`_
+        - Maintaining common user level APIs that allow applications to be portable
             + :ref:`RPMSG<rpmsg-protocol-work-label>`
             + :ref:`remoteproc<lcm-work-label>`
-        - **Standardizing on the low-level** :ref:`OS/HW abstraction layer<porting-guide-work-label>` **that abstracts the open source implementation from the underlying OS and hardware, simplifying the porting to new environments**
+        - **Provide low-level** :ref:`OS/HW abstraction layer<porting-guide-work-label>` APIs **that abstracts the open source implementation from the underlying OS and hardware, simplifying the porting to new environments**
 
     * An open source project that implements a clean-room implementation of OpenAMP
         - Runs in :ref:`multiple environments<operating-environments-work-label>`
@@ -152,9 +161,9 @@ RemoteProc
 RPMsg and Virtio
 ================
 
-Standardization of the IPC is promoted by the OpenAMP project through the use of :ref:`RPMsg <rpmsg-protocol-work-label>`, using `Open Standard Virtio Devices <https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html>`_ as a HW abstraction or MAC layer.
+Standardization of the IPC is promoted by the OpenAMP project through the use of :ref:`RPMsg <rpmsg-protocol-work-label>`, using `Open Standard Virtio Devices <https://docs.oasis-open.org/virtio/virtio>`_ as a HW abstraction or MAC layer.
 
-This abstraction, using virtio, means that the implementer can optionally use :ref:`resource isolation<resource-isolation-work-label>` (e.g. using a hypervisor or secure context), which is exemplified by the first processor in the architecture diagram. The other two remotes are in what is referred to as a hypervisorless-virtio setup because they are using virtio (virtual io) as an abstraction layer but without a hypervisor.
+This abstraction, using virtio, means that the implementer can optionally use :ref:`resource isolation<resource-isolation-work-label>` (e.g. using a hypervisor or secure context), which is exemplified by the first processor in the architecture diagram.
 
 ..  image::  ../images/architecture/overview-architecture-rpmsg.svg
 
@@ -195,7 +204,7 @@ OpenAMP aims to provide components which are portable and aim to be environment
 
 The result is that OpenAMP is supported in various operating environments through
   - an `OpenAMP open source project <https://github.com/OpenAMP>`_  (OAOS),
-  - a Linux kernel project (OALK), coming through the regular `remoteproc <https://www.kernel.org/doc/html/latest/staging/remoteproc.html>`_/`RPMsg <https://www.kernel.org/doc/html/latest/staging/rpmsg.html>`_/`Virtio <https://docs.kernel.org/driver-api/virtio/virtio.html>`_ efforts in the kernel.
+  - an OpenAMP Linux Kernel (OALK) project, coming through the regular `remoteproc <https://www.kernel.org/doc/html/latest/staging/remoteproc.html>`_/`RPMsg <https://www.kernel.org/doc/html/latest/staging/rpmsg.html>`_/`Virtio <https://docs.kernel.org/driver-api/virtio/virtio.html>`_ efforts in the kernel.
   - multiple proprietary implementations (OAPI).
 
 The operating environments that OpenAMP supports include:
@@ -220,12 +229,10 @@ There are a few guiding principles that governs OpenAMP:
     - Provide a clean-room implementation of OpenAMP with business friendly APIs and licensing
         * Allow for compatible proprietary implementations and products
     - Base as much as possible on existing technologies/open source projects/standards
-        * In particular :ref:`remoteproc<lcm-work-label>`, :ref:`RPMsg <rpmsg-protocol-work-label>` and virtio
+        * In particular :ref:`remoteproc<lcm-work-label>`, :ref:`RPMsg <rpmsg-protocol-work-label>` and `virtio <https://docs.oasis-open.org/virtio/virtio>`_
     - **Never standardize on anything unless there is an open source implementation that can prove it**
     - Always be backwards compatible (unless there is a really, really good reason to change)
-        * In particular make sure to be compatible with the Linux kernel implementation of :ref:`remoteproc<lcm-work-label>`/:ref:`RPMsg <rpmsg-protocol-work-label>`/virtio
+        * In particular make sure to be compatible with the Linux kernel implementation of :ref:`remoteproc<lcm-work-label>`/:ref:`RPMsg <rpmsg-protocol-work-label>`/`Virtio <https://docs.oasis-open.org/virtio/virtio>`_
 
 There are a number of project members as outlined in `OpenAMP Project Page <https://www.openampproject.org/about/>`_ as well as many community members, so please join the :ref:`OpenAMP open source project<openamp-maintenance-work-label>`!
     - See https://github.com/OpenAMP/open-amp
-
-If you want to contribute and port OpenAMP to your platform read more about OpenAMP porting :ref:`here<porting-guide-work-label>`.
diff --git a/protocol_details/components.rst b/protocol_details/components.rst
@@ -20,15 +20,6 @@ The key components, and the capabilities they provide, of the OpenAMP Framework
     remoteproc, This component allows for the Life Cycle Management (LCM) of remote processors from software running on a host processor. The remoteproc API provided by the OpenAMP Framework is compliant with the remoteproc infrastructure present in upstream Linux 3.4.x kernel onward. The Linux remoteproc infrastructure and API was first implemented by Texas Instruments.
     RPMsg, The RPMsg API enables `Inter Processor Communications (IPC) <https://en.wikipedia.org/wiki/Inter-process_communication>`_ between independent software contexts running on homogeneous or `heterogeneous <https://en.wikipedia.org/wiki/Heterogeneous_computing>`_ cores present in an AMP system. This API is compliant with the RPMsg bus infrastructure present in upstream Linux 3.4.x kernel onward. The Linux RPMsg bus and API infrastructure was first implemented by Texas Instruments.
 
-
-*******
-History
-*******
-
-Texas Instruments’ remoteproc and RPMsg infrastructure available in the upstream Linux kernel enable the Linux applications running on a host processor to manage the life cycle of remote processor/firmware and perform IPC with them. However, there was no open- source API/software available that provided similar functionality and interfaces for other possible software contexts (RTOS- or bare metal-based applications) running on the remote processor to communicate with the Linux host. Also, AMP applications may require RTOS- or bare metal-based applications to run on the host processor and be able to manage and communicate with various software environments (RTOS, bare metal, or even Linux) on the remote processor.
-
-The OpenAMP Framework fills these gaps. It provides the required LCM and IPC infrastructure from the RTOS and bare metal environments with the API conformity and functional symmetry available in the upstream Linux kernel. As in upstream Linux, the OpenAMP Framework's remoteproc and RPMsg infrastructure uses virtio as the transport layer/abstraction.
-
 **********
 Topologies
 **********