diff --git a/current/application_services.rst b/current/application_services.rst deleted file mode 100644 index bc5a772..0000000 --- a/current/application_services.rst +++ /dev/null @@ -1,42 +0,0 @@ -============================== -Application Services Sub-Group -============================== - -Introduction ------------- - -This sub-group covers the application space that sits on top of OpenAMP and describes higher level services for - - - file sharing - - proxy and/or forwarding of IP ports - - debug proxy - - high level IPC APIs for send-receive-reply / byte streams / message-based connections / pub/sub - - IPC server registration and client binding - - application partitioning using RPCs, C & non-C languages, canonical format - - bare metal APIs (using RPC) for stdio, socket IO, other APIs - -Communications --------------- - -Mailing list -~~~~~~~~~~~~ - -We have a Mailman list for app-services discussions. You can find info about it, reach the link to the archives, and subscribe/unsubscribe `here `_. - -Meetings -~~~~~~~~ - -Check out the meeting notes for the Application Services meetings on the :ref:`OpenAMP Meeting Notes page`. - -Documentation -------------- - -Placeholder -~~~~~~~~~~~ - -Placeholder for other documentation here - -Future work ------------ - -Check out the future work list for the Application Services sub-group in the :ref:`future-services-work-label` section. \ No newline at end of file diff --git a/current/ci.rst b/current/ci.rst deleted file mode 100644 index 9441b7d..0000000 --- a/current/ci.rst +++ /dev/null @@ -1,6 +0,0 @@ -==================== -OpenAMP CI Sub-Group -==================== - - - CI regression for every push request from OpenAMP repo - - Enabling OpenAMP tests for different users to run on different platforms diff --git a/current/device_trees.rst b/current/device_trees.rst deleted file mode 100644 index 8893b94..0000000 --- a/current/device_trees.rst +++ /dev/null @@ -1,44 +0,0 @@ -============================ -System Device Tree Sub-Group -============================ - -Introduction ------------- - -Todays heterogeneous SoCs are very hard to configure. Issues like which cores, memory and devices belongs to which operating systems, hypervisors and firmware is done in an ad-hoc, error prone way. System Device Trees will change all that by extending todays device trees, used by Linux, Xen, uboot, etc. to describe the full system and also include configuration information on what belongs where. - -Communications --------------- -Mailing list -~~~~~~~~~~~~ - -We have a Mailman list for system-dt discussions. You can find info about it, reach the link to the archives, and subscribe/unsubscribe `here `_ - -Meetings -~~~~~~~~ - -Check out the meeting notes for the System Device Tree meetings on the :ref:`OpenAMP Meeting Notes page`. - -Documentation -------------- -System DT intro presentation given at Linaro Connect SAN19 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - - `Video `_ - - `Slides `_ - -Placeholder for Stefano to populate -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Placeholder for other documentation here - -Lopper -~~~~~~ - -Lopper is a device tree manipulation tool that has been created to provide data driven manipulation and transformation of System Device Trees into any number of output formats, with an emphasis on conversion to standard device trees. - -The source code and information can be found at: https://github.com/devicetree-org/lopper/ - -Future work ------------ - -Check out the future work list for the System Device Tree sub-group in the :ref:`future-device-tree-work-label` section \ No newline at end of file diff --git a/current/inclusive_language.rst b/current/inclusive_language.rst deleted file mode 100644 index 7c3af18..0000000 --- a/current/inclusive_language.rst +++ /dev/null @@ -1,39 +0,0 @@ -============================================= -Inclusive Language and Biased Terms Sub-Group -============================================= - -This proposal from Bill Mills was approved at the 10/22/21 OpenAMP TSC: - -replace master with main ------------------------- - -github has special case logic to make this easier: https://github.com/github/renaming - -remoteproc context ------------------- - - - "slave" should be "remote processor" - - "master" should be "remoteproc host" - -virto context -------------- - -virtio spec uses "device" and "driver". suggest we use "virtio device" and "virtio driver" - -Examples of devices: - - - vitioblk device - - virtio network interface - -For today's remoteproc rpmsg, Linux is always the driver side. - -Some virtio "devices" are not very device like and instead are more like services. Alternative for such cases - - - "application service" and "application client" - -Examples: - - - vsock: service is the one that calls accept on the socket - - p9fs: service is the side that has the filesystem - -Note that a remote processor can host a service and be a client at the same time. The terminology is per service. \ No newline at end of file diff --git a/current/index.rst b/current/index.rst deleted file mode 100644 index d49a089..0000000 --- a/current/index.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. OpenAMP documentation master file, created by - sphinx-quickstart on Wed Oct 5 10:21:26 2022. - You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. - -Current Work -============ - -.. toctree:: - :maxdepth: 2 - :caption: Contents: - - remoteproc - device_trees - application_services - inclusive_language - ci - ipc - system_reference - older_topics \ No newline at end of file diff --git a/current/ipc.rst b/current/ipc.rst deleted file mode 100644 index c5947ea..0000000 --- a/current/ipc.rst +++ /dev/null @@ -1,5 +0,0 @@ -============= -IPC Sub-Group -============= - - - Shared memory support to use DMA buffer in Linux userspace \ No newline at end of file diff --git a/current/older_topics.rst b/current/older_topics.rst deleted file mode 100644 index 4e4f79a..0000000 --- a/current/older_topics.rst +++ /dev/null @@ -1,9 +0,0 @@ -============ -Older Topics -============ - -Formation of OpenAMP project ----------------------------- - - - Launched as a `Linaro Community Project at Linaro Connect SAN19 `_ - diff --git a/current/remoteproc.rst b/current/remoteproc.rst deleted file mode 100644 index 3abbd17..0000000 --- a/current/remoteproc.rst +++ /dev/null @@ -1,40 +0,0 @@ -==================== -Remoteproc Sub-Group -==================== - -Introduction ------------- - -Bill to revise summary about this group The OpenAMP remoteproc sub-group (A.K.A. "OpenAMP Classic") works on the original parts of OpenAMP, focusing on open-amp, libmetal, remoteproc, rpmsg, virtio. - -Communications --------------- -Mailing list -~~~~~~~~~~~~ - -We have a Mailman list for OpenAMP Remoteproc sub-group discussions. You can find info about it, reach the link to the archives, and subscribe/unsubscribe `here `_. - -Meetings -~~~~~~~~ - -Check out the meeting notes for the OpenAMP Remoteproc meetings on the :ref:`OpenAMP Meeting Notes page`. The cadence is every 2 weeks on Thursday mornings at 11am Eastern Time. Join the openamp-rp mailing list (see above) for the latest about the upcoming calls. - -Documentation -------------- -Placeholder for Bill to populate -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Placeholder for other documentation here - -OpenAMP Introduction from Linaro Connect HKG18 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Slides_ - -.. _Slides: http://connect.linaro.org.s3.amazonaws.com/hkg18/presentations/hkg18-411.pdf - -Future work ------------ - -Check out the future work list for the OpenAMP Remoteproc sub-group in the :ref:`future-remoteproc-work-label` section. - diff --git a/current/system_reference.rst b/current/system_reference.rst deleted file mode 100644 index a6259a6..0000000 --- a/current/system_reference.rst +++ /dev/null @@ -1,53 +0,0 @@ -=============================================== -System Reference / End-to-End Example Sub-Group -=============================================== - -What is OpenAMP System Reference / End-to-end example? ------------------------------------------------------- - -This working group aims to put together end-to-end system reference material showcasing all the different aspects of OpenAMP, on multiple vendor platforms. - -Communications --------------- - - - To sign up for the mailing list and to see the archives, visit `this page `_ BROKEN LINK - - Meetings: Small group who is working on the project is meeting meeting weekly on Wednesday during Aug-Oct 2021 & then will decide on frequency. - * Reach out on the `Mailing list `_ BROKEN LINK if you need info about this. - * :ref:`Project Meeting Notes` - -Repository ----------- - -`GitHub repository openamp-system-reference `_ - -Documentation -------------- - -WIP documentation folder on `Google Drive `_ (Note: Google doc access is currently restricted to working group members. Will publish documents once they are sufficiently ready) - -Samples and demos ------------------ - -Please refer to :ref:`Samples and demos page`. - -Milestones ----------- - -Future work ------------ - -Efforts -~~~~~~~ - - - Baremetal-baremetal - - RTOS-RTOS - -High level plan for Xilinx Software Stack -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - - QEMU & initial doc – Mid Sept. - - Userspace & kernel space demos – Sept end - - Hardware demo – End - Oct. - - System-dt flow (Without using Xilinx tools) – End-Nov - - Advanced app – End-Jan - - Completely upstream flow – (Based on When Xilinx driver is merged in upstream kernel) diff --git a/demos/echo.rst b/demos/echo.rst index a330dd8..69c47d5 100644 --- a/demos/echo.rst +++ b/demos/echo.rst @@ -8,7 +8,7 @@ OpenAMP Echo Test Sample Echo Test Intro *************** -The echo test reference sample, as the name suggests, demonstrates OpenAMP :ref:`Interprocessor Communications (IPC)` components by providing an echo application on a remote which simply returns (echoes) packets as they are received at an :ref:`RPMsg endpoint ` from the host controller. The host controller then verifies the returned packet for integrity. +The echo test reference sample, as the name suggests, demonstrates OpenAMP :ref:`Interprocessor Communications (IPC)` components by providing an echo application on a remote which simply returns (echoes) packets as they are received at an :ref:`RPMsg endpoint ` from the main controller. The main controller then verifies the returned packet for integrity. .. image:: ../images/demos/echo-test-intro.svg @@ -20,7 +20,7 @@ Echo Test Components There are two applications involved in this demonstration. The :ref:`remote application` runs as an echo service, which returns packets it receives on an :ref:`RPMsg endpoint `. -The :ref:`host application` is the test application sending packets to the echo service and monitoring for their return. +The :ref:`main controller application` is the test application sending packets to the echo service and monitoring for their return. The underlying OpenAMP architectural components used by these applications are @@ -45,22 +45,22 @@ The top-level control flow is shown in the following message diagram. RPMsg Echo Remote Application ============================= -The remote application, rpmsg-echo, is the core of the demonstration. It is a simple application serving a :ref:`RPMsg endpoint ` running as the main task on the remote processor, once loaded and started using :ref:`Remoteproc`. +The remote application, rpmsg-echo, is the core of the demonstration. It is a simple application serving a :ref:`RPMsg endpoint ` running as the main task on the remote processor. .. _echo-test-host-app: -Echo Test Host Application +Echo Test Main Application ========================== -The echo_test application forms the host controller side of the demonstration. It repeatedly writes an increasing length payload of 0xA5's up to the maximum data size (packet size minus header) to the RPMsg endpoint. Following each packet send, it reads from the same endpoint and verifies the returned packet for correctness. The application will stop and report on the first corruption found. +The echo_test application forms the main controller side of the demonstration. It repeatedly writes an increasing length payload of 0xA5's up to the maximum data size (packet size minus header) to the RPMsg endpoint. Following each packet send, it reads from the same endpoint and verifies the returned packet for correctness. The application will stop and report on the first corruption found. -Echo Test Host Script +Echo Test Main Script ===================== -The host is also responsible for loading the firmware containing the :ref:`RPMsg Echo Remote Application` and starting the remote processor using :ref:`Remoteproc`. +The main controller is also responsible for loading the firmware containing the :ref:`RPMsg Echo Remote Application` and starting the remote processor using :ref:`Remoteproc`. -For host controllers, like Linux, a script can be used to pipe the firmware to the exposed remoteproc system, followed by the execution of the user space echo_test application. For controllers without scripting capability, like baremetal and RTOS (Real Time Operating systems), this would be achieved in the code. +For main controllers, like Linux, a script can be used to pipe the firmware to the exposed remoteproc system, followed by the execution of the user space echo_test application. For controllers without scripting capability, like baremetal and RTOS (Real Time Operating systems), this would be achieved in the code. In the :ref:`Demo Docker Images` this is script demo1A. @@ -71,7 +71,7 @@ Echo Test Source RPMsg Echo Baremetal Source =========================== -The RPMsg Echo service application is available as a baremetal solution in the `open-amp Repository `_ +The RPMsg Echo service application is available as a baremetal solution in the `open-amp Repository `_ It is a CMake application and can be built for any remote as long as the relevant :ref:`OS/HW abstraction layer` components like libmetal are ported for that platform. @@ -80,12 +80,12 @@ It is a CMake application and can be built for any remote as long as the relevan Echo Test Linux Source ====================== -The echo test Linux application is executed on the Linux host controller as a user space application. +The echo test Linux application is executed on the Linux main controller as a user space application. The application is available in the `OpenAMP System Reference repository `_. It is a Makefile application and can be built using the `Yocto rpmsg-echo-test recipe `_ -An example host control script is given in the `echo test readme `_ +An example main control script is given in the `echo test readme `_ ******************************* Reference Board Implementations diff --git a/demos/hvl_virtio.rst b/demos/hvl_virtio.rst index 24697e4..a4dec50 100644 --- a/demos/hvl_virtio.rst +++ b/demos/hvl_virtio.rst @@ -22,7 +22,7 @@ All demonstrations are run on a remote running `Zephyr Operating System (OS) `. +The remote application is the core of the demonstration. It is a simple application utilising a number of Virtio devices. -The remote application when started initially calls on the `Virtio Entropy Device `_ to obtain entropy values to print to the UART console. Subsequently, it sets up `Virtio Network Device `_ to provide communications between the host at 192.168.200.254 and remote at 192.168.200.2. +The remote application when started initially calls on the `Virtio Entropy Device `_ to obtain entropy values to print to the UART console. Subsequently, it sets up `Virtio Network Device `_ to provide communications between the main controller at 192.168.200.254 and remote at 192.168.200.2. -Hypervisorless Virtio Host Script +Hypervisorless Virtio Main Script ================================= -The host is responsible for setting up a `virtual/tap network `_, loading the firmware containing the :ref:`Hypervisorless Virtio Application` and starting the remote processor using :ref:`Remoteproc`. +The main controller is responsible for setting up a `virtual/tap network `_, loading the firmware containing the :ref:`Hypervisorless Virtio Application` and starting the remote processor using :ref:`Remoteproc`. The scripts are available in the :ref:`Demo Docker Images` as `demo4 `_ and `setup.sh `_. diff --git a/demos/inter_process.rst b/demos/inter_process.rst index a00cff9..7b98da8 100644 --- a/demos/inter_process.rst +++ b/demos/inter_process.rst @@ -4,11 +4,11 @@ Running Demos as Processes on Linux =================================== -The `OpenAMP project examples `_ -are intended to execute on the remote of a reference board but can also be demonstrated by implementing as a process on the host, effectively emulating a remote. +The `OpenAMP project 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. -Effectively the `OpenAMP Library `_ and `reference examples `_ are built for the host system along with the `host examples `_. +Effectively the `OpenAMP Library `_ and `reference examples `_ are built for the main controller system along with the `main controller examples `_. To build and execute on a Linux system, refer to the `example to compile OpenAMP for communication between Linux processes `_. diff --git a/demos/linux_rpc.rst b/demos/linux_rpc.rst index 4e73b1d..71f5feb 100644 --- a/demos/linux_rpc.rst +++ b/demos/linux_rpc.rst @@ -9,7 +9,7 @@ OpenAMP Linux RPC Demo Linux RPC Intro *************** -The RPMsg Multi Services reference sample demonstrates OpenAMP :ref:`Remote Procedure Call (RPC)` components between two linux processors, one as the host and the other as remote. +The RPMsg Multi Services reference sample demonstrates OpenAMP :ref:`Remote Procedure Call (RPC)` components between two linux processors, one as the main controller and the other as remote. .. image:: ../images/demos/linux-rpc-intro.svg @@ -31,7 +31,7 @@ The underlying OpenAMP architectural components used by these applications are * :ref:`RPC` * :ref:`Libmetal` -The Linux file and stdio access is performed in the `linux_rpc_demod application `_. +The Linux file and stdio access is performed in the `linux_rpc_demod application `_. The following architecture diagram shows the primary components involved in the demonstration. @@ -58,7 +58,7 @@ Whenever the server receives an RPMsg on this end point with the associated iden Linux RPC Client ================ -The Linux RPC Client application is a remote/client application requiring file handling, but lacking a file system. Instead it relies on a host server to provide the file handling via RPMsg. It initialises an RPC client, associated through the server identifiers. For each IO handler it will send an RPMsg on the associated endpoint. +The Linux RPC Client application is a remote/client application requiring file handling, but lacking a file system. Instead it relies on a main server to provide the file handling via RPMsg. It initialises an RPC client, associated through the server identifiers. For each IO handler it will send an RPMsg on the associated endpoint. The OpenAMP RPC client does not block to await the RPMsg response, leaving this to the application to perform. In the sample client this is performed for each of the input output functions. @@ -71,12 +71,12 @@ Linux RPC Demo Source Linux RPC Server Source ======================= -The current implementation is a Linux process `linux_rpc_demod `_, which can be run as a daemon to provide the host/driver side of the demonstration. +The current implementation is a Linux process `linux_rpc_demod `_, which can be run as a daemon to provide the main controller/driver side of the demonstration. Linux RPC Client Source ======================= -The current implementation is a Linux process `linux_rpc_demo `_ +The current implementation is a Linux process `linux_rpc_demo `_ ******************************* diff --git a/demos/matrix_multiply.rst b/demos/matrix_multiply.rst index 9fd10fa..df1b6f8 100644 --- a/demos/matrix_multiply.rst +++ b/demos/matrix_multiply.rst @@ -8,7 +8,7 @@ OpenAMP Matrix Multiply Sample Matrix Multiply Intro ********************* -The matrix multiply reference sample, as the name suggests, demonstrates OpenAMP :ref:`Interprocessor Communications (IPC)` components through matrix multiplication. The demonstration uses a host client, which generates random matrixes. It sends them to a service/daemon on a remote which performs a matrix calculation and returns the result via a :ref:`RPMsg endpoint `. The host controller then writes the matrix result to console output. +The matrix multiply reference sample, as the name suggests, demonstrates OpenAMP :ref:`Interprocessor Communications (IPC)` components through matrix multiplication. The demonstration uses a main controller client, which generates random matrices. It sends them to a service/daemon on a remote which performs a matrix calculation and returns the result via a :ref:`RPMsg endpoint `. The main controller then writes the matrix result to console output. .. image:: ../images/demos/matrix-multiply-intro.svg @@ -20,7 +20,7 @@ Matrix Multiply Components There are two applications involved in this demonstration. The :ref:`remote application` runs as an daemon/service which performs a matrix calculation and returns the result on an :ref:`RPMsg endpoint `. -The :ref:`host application` is the client application sending two matrixes as a packet to the daemon/service and monitoring for the return result. +The :ref:`main controller application` is the client application sending two matrices as a packet to the daemon/service and monitoring for the return result. The underlying OpenAMP architectural components used by these applications are @@ -43,25 +43,25 @@ The top-level control flow is shown in the following message diagram. RPMsg Matrix Multiply Remote Application ======================================== -The remote application, `matrix_multiplyd `_, is the core of the demonstration. It is a simple application serving a :ref:`RPMsg endpoint ` running as the main task on the remote processor, once loaded and started using :ref:`Remoteproc`. +The remote application, `matrix_multiplyd `_, is the core of the demonstration. It is a simple application serving a :ref:`RPMsg endpoint ` running as the main task on the remote processor. .. _matrix-multiply-host-app: -Matrix Multiply Host Application +Matrix Multiply Main Application ================================ -The host application generates two matrices into a structure with size and 6x6 matrix, sequentially into a RPMsg packet. It then waits for matrix sized bytes to be returned and prints the resultant matrix as calculated by the remote. +The main controller application generates two matrices into a structure with size and 6x6 matrix, sequentially into a RPMsg packet. It then waits for matrix sized bytes to be returned and prints the resultant matrix as calculated by the remote. -There are two implementations. The `mat_mul_demo `_ application forms the host controller side of the demonstration, as a linux user space client application. The `matrix_multiply `_ application forms the host controller side of the demonstration, as a baremetal client application. +There are two implementations. The `mat_mul_demo `_ application forms the main controller side of the demonstration, as a linux user space client application. The `matrix_multiply `_ application forms the main controller side of the demonstration, as a baremetal client application. -Matrix Multiply Host Script +Matrix Multiply Main Script =========================== -The host is also responsible for loading the firmware containing the :ref:`RPMsg Matrix Multiply Remote Application` and starting the remote processor using :ref:`Remoteproc`. +The main controller is also responsible for loading the firmware containing the :ref:`RPMsg Matrix Multiply Remote Application` and starting the remote processor using :ref:`Remoteproc`. -For host controllers, like Linux, a script can be used to pipe the firmware to the exposed remoteproc system, followed by the execution of the user space mat_mul_demo application. For controllers without scripting capability, like baremetal and RTOS (Real Time Operating systems), this would be achieved in the code. +For main controllers, like Linux, a script can be used to pipe the firmware to the exposed remoteproc system, followed by the execution of the user space mat_mul_demo application. For controllers without scripting capability, like baremetal and RTOS (Real Time Operating systems), this would be achieved in the code. ********************** Matrix Multiply Source @@ -70,11 +70,11 @@ Matrix Multiply Source RPMsg Matrix Multiply Baremetal Sources ======================================= -There are two baremetal applications, a daemon/service to run on the remote and a host/controller application which is the matrix multiply client requesting the calculations. +There are two baremetal applications, a daemon/service to run on the remote and a main controller application which is the matrix multiply client requesting the calculations. -The RPMsg Matrix Multiply daemon/service application is available as a baremetal solution in the `OpenAMP Repository `_. Take note of the d for daemon at the end of the file. +The RPMsg Matrix Multiply daemon/service application is available as a baremetal solution in the `OpenAMP Repository `_. Take note of the d for daemon at the end of the file. -The RPMsg Matrix Multiple host client application is available as a baremetal solution in the `OpenAMP Repository `_. +The RPMsg Matrix Multiple main controller client application is available as a baremetal solution in the `OpenAMP Repository `_. Both are CMake applications and can be built for any remote as long as the relevant :ref:`OS/HW abstraction layer` components like libmetal are ported for that platform. @@ -83,12 +83,12 @@ Both are CMake applications and can be built for any remote as long as the relev Matrix Multiply Linux Source ============================ -The matrix multiply Linux application is executed on the Linux host controller as a user space application. +The matrix multiply Linux application is executed on the Linux main controller as a user space application. The application is available in the `OpenAMP System Reference repository `_. It is a Makefile application and can be built using the `Yocto rpmsg-mat-mul recipe `_. -An example host control script is given in the `matrix multiply readme `_. +An example main control script is given in the `matrix multiply readme `_. ******************************* Reference Board Implementations diff --git a/demos/reference_boards.rst b/demos/reference_boards.rst index 89e5b3b..d233413 100644 --- 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/replicate_firmware.rst b/demos/replicate_firmware.rst index d8faa10..5a75e23 100644 --- a/demos/replicate_firmware.rst +++ b/demos/replicate_firmware.rst @@ -18,7 +18,7 @@ The Replicate Firmware Demo is provided to demonstrate the use of two remote pro Replicate Firmware Components ***************************** -This demonstration uses a single application, sent independently to the two remotes, utilising a demo script on the host. +This demonstration uses a single application, sent independently to the two remotes, utilising a demo script on the main controller. The underlying OpenAMP architectural components used by these applications are @@ -45,16 +45,16 @@ The remote application is a hello world application, which once loaded calls pri .. _replicate-firmware-linux-script: -Replicate Firmware Host Script +Replicate Firmware Main Script ============================== -The host is responsible for loading the firmware and starting the remote processors by writing start and stop to /sys/class/remoteproc/remoteproc0 and /sys/class/remoteproc/remoteproc1 alternately. +The main controller is responsible for loading the firmware and starting the remote processors by writing start and stop to /sys/class/remoteproc/remoteproc0 and /sys/class/remoteproc/remoteproc1 alternately. The same firmware is loaded, and this is made possible as the system uses `Tightly Coupled Memory `_, so each processor is assigned its own bank of memory. The scripts is available in the :ref:`Demo Docker Images` as demo3. -Replicate Firmware Host Configuration +Replicate Firmware Main Configuration ===================================== The remoteproc configuration binding `cluster-mode `_ is set to 0 for split-mode as per the `system reference implementation `_. diff --git a/demos/rpmsg_multi_services.rst b/demos/rpmsg_multi_services.rst index 15fd5ec..77bdd08 100644 --- a/demos/rpmsg_multi_services.rst +++ b/demos/rpmsg_multi_services.rst @@ -17,7 +17,7 @@ Three channel types are demonstrated. * Raw `character device `_ Channel * `tty Device `_ Channel -The host side is implemented in Linux as client drivers to the remote services. The Direct RPMsg driver is a dedicated demo driver and the character and tty RPMsg drivers are generic character drivers that can be used by any user space application through their respective device files. +The main controller side is implemented in Linux as client drivers to the remote services. The Direct RPMsg driver is a dedicated demo driver and the character and tty RPMsg drivers are generic character drivers that can be used by any user space application through their respective device files. .. image:: ../images/demos/rpmsg-multi-services-intro.svg @@ -30,7 +30,7 @@ The remote sets up three RPMsg channels, one for each service, starting at addre RPMsg Multi Services Components ******************************* -The three :ref:`Interprocessor Communications (IPC)` paths in this demonstration provide an identical application flow, namely a host based client sending packets via RPMsg to the remote which echoes the packet. +The three :ref:`Interprocessor Communications (IPC)` paths in this demonstration provide an identical application flow, namely a main controller based client sending packets via RPMsg to the remote which echoes the packet. The main target of the demonstration is to show the different RPMsg types as supported by Linux drivers, namely 'direct', 'character' and 'tty' driver. @@ -42,7 +42,7 @@ The underlying OpenAMP architectural components used by these applications are * :ref:`Virtio` * :ref:`Libmetal` -The supporting Linux architectural components used by the drivers on the host side are +The supporting Linux architectural components used by the drivers on the main controller side are * `RPMsg character device `_ * `tty device `_ @@ -53,7 +53,9 @@ The following architecture diagram shows the components involved in the demonstr .. _rpmsg-control-flow-label: -The top-level control flow is shown in the following message diagram. The remote threads are show sequentially for clarity of diagram but could be executed in parallel. +The top-level control flow is shown in the following message diagram. The control flow for each service is exemplified in the three boxes labeled A, B and C for the drivers direct, tty and character/raw. +The remote threads are shown sequentially for clarity of diagram but could be executed in parallel. + .. image:: ../images/demos/rpmsg-multi-services-control-flow.svg @@ -63,10 +65,11 @@ The top-level control flow is shown in the following message diagram. The remote RPMsg Client Sample =================== -The Linux rpmsg_client_sample driver begins sending 'hello world!' messages on a rpmsg_driver probe, initiated by a name service announcement from the remote. This is repeated a predefined count times for each response from the remote. The response from the remote application is to return the same packet received at the :ref:`RPMsg endpoint ` of the host controller. +The Linux rpmsg_client_sample driver begins sending 'hello world!' messages on a rpmsg_driver probe, initiated by a name service announcement from the remote. This is repeated a predefined count times for each response from the remote. The response from the remote application is to return the same packet received at the :ref:`RPMsg endpoint ` of the main controller. When the count (100) responses have been sent, the endpoint is destroyed by the remote. +Refer to box A (direct) in :ref:`flow control diagram`. .. _rpmsg-character-driver-sample-label: @@ -86,11 +89,11 @@ Raw Character Driver Sample When started, the character/raw remote service (app_rpmsg_raw thread) creates two RPMsg endpoints. The first with the special RPMSG_ADDR_ANY (-1) address which sets up the RPMsg channel and the second with destination and source address set to 1. -In addition to demonstrating the use of the raw character driver, this application demonstrates the use of an arbitrary number of Linux side RPMsg endpoints, all connected to a single endpoint on the remote side (with address 1). The Linux side end points are created using the `rpmsg-utils rpmsg_export_ept utility `_, and establish a many to one connectivity between host and remote endpoints. +In addition to demonstrating the use of the raw character driver, this application demonstrates the use of an arbitrary number of Linux side RPMsg endpoints, all connected to a single endpoint on the remote side (with address 1). The Linux side end points are created using the `rpmsg-utils rpmsg_export_ept utility `_, and establish a many to one connectivity between main controller and remote endpoints. Although there are many endpoints on the Linux side, the remote has only two endpoints. -Refer to the :ref:`flow control diagram`. +Refer to box C (char) in :ref:`flow control diagram`. .. _rpmsg-tty-driver-label: @@ -103,7 +106,7 @@ The management thread (rpmsg_mng_task) also sets up a 'New Service Callback' (ne This application demonstrates the creation and release of RPMsg channels using the `rpmsg-utils rpmsg_export_dev utility `_, which exercise the ioctl commands RPMSG_CREATE_DEV_IOCTL and RPMSG_RELEASE_DEV_IOCTL. -Refer to the :ref:`flow control diagram`. +Refer to box B (tty) in :ref:`flow control diagram`. ******************************** RPMsg Multi Services Demo Source @@ -143,6 +146,7 @@ The tty 'client' is the `PRMsg tty driver `_ provided in the Linux source and is used by the `rpmsg-utils rpmsg_export_dev utility `_, which exercise the ioctl commands RPMSG_CREATE_DEV_IOCTL and RPMSG_RELEASE_DEV_IOCTL. + ******************************* Reference Board Implementations ******************************* @@ -152,3 +156,8 @@ This RPMsg Multi Services Sample is demonstrated in the following reference impl * :ref:`ST Micro Platforms` * Refer to `Zephyr Build Instructions `_. + * Refer to `example demo script `_. + +* :ref:`NXP ` + + * Refer to Application Note `AN13970 Running Zephyr RTOS `_ diff --git a/demos/split_mode.rst b/demos/split_mode.rst index 8e5f61c..f8bf684 100644 --- a/demos/split_mode.rst +++ b/demos/split_mode.rst @@ -18,7 +18,7 @@ The `Split Mode Demo ` as `demo2 `_. -Split Mode Host Configuration +Split Mode Main Configuration ============================= The remoteproc configuration binding `cluster-mode `_ is set to 0 for split-mode as per the `system reference implementation `_. diff --git a/demos/system_reference-NXP.rst b/demos/system_reference-NXP.rst new file mode 100644 index 0000000..c247f1a --- /dev/null +++ b/demos/system_reference-NXP.rst @@ -0,0 +1,13 @@ + + +.. _reference_board_NXP: + +==================== +NXP Reference Boards +==================== + +A number of the `OpenAMP project examples `_ can be executed on NXP Reference boards. + +* NXP `8MPLUSLPD4-EVK `_. + +The `AN13970 Running Zephyr RTOS on Cadence Tensilica HiFi 4 DSP `_ application note provides instructions for setting up the evaluation board. diff --git a/future/device_tree.rst b/future/device_tree.rst deleted file mode 100644 index 326a098..0000000 --- a/future/device_tree.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _future-device-tree-work-label: - -======================================== -System Device Tree Sub-Group Future Work -======================================== - -2019-10-17 - This list (to be populated) covers topics for the OpenAMP System Device Tree sub-group to discuss what to work on at their sub-group meetings. This sub-group welcomes participants from other areas of Device Tree beyond OpenAMP as well, such as DeviceTree.org, Device Tree Evolution projects. OpenAMP Project is hosting this discussion because of its cross-functional nature. \ No newline at end of file diff --git a/future/hardware_description.rst b/future/hardware_description.rst deleted file mode 100644 index 35d03c6..0000000 --- a/future/hardware_description.rst +++ /dev/null @@ -1,29 +0,0 @@ -==================== -Hardware Description -==================== - -Problems --------- - - - Need to communicate HW details (addresses, topologies, …) to SW subsystems during build - * Both at system level (complete HW including all CPUs) and subsystem level - * Tool to create subsystems with assigned devices out of system level info - - Need to communicate HW details during runtime - * Device trees used by Linux, Xen, etc. - * How to communicate to coprocessors (remoteproc) what devices it has? - - Need tools to create static config data (#defines, .h, .c files) from HW description - * Zephyr working on this. Need general solution. - - Need compact format for runtime use cases - * DTB is not very compact. Using strings instead of labels, no compression - -Potential solutions -------------------- - - - Come up with standard, humanly readable, HW description format for usage during build - * Possible candidates include extended Device Trees, IPExact, … - * A “System Level Device Tree” would add another level with multiple CPUs and mappings - - Come up with standard compressed HW description - * Potential candidate is CBOR - -Others interested in this problem? ----------------------------------- \ No newline at end of file diff --git a/future/hmm.rst b/future/hmm.rst deleted file mode 100644 index c738034..0000000 --- a/future/hmm.rst +++ /dev/null @@ -1,22 +0,0 @@ -===================================== -HMM (Heterogeneous Memory Management) -===================================== - -Use Cases ---------- - - - pcie/ccix endpoint side memory pools - - embedded soc e.g. dedicated media buffer alloc pool - -zone device and memory hotplug (on arm64) ------------------------------------------ - - - arch pte devmap bit options (mair bits, pte_none?, pte_special?) - - device pluggable private and public memory - -hmm address space mirroring w/ rproc ------------------------------------- - - - tie into vfio-map shmem model w/ remoteproc instances? - - could we somehow do better than dma migration w/ pgtable remapping? - - (opt.) tie into vfio-bind shmem model needs intg. iommu fault handling diff --git a/future/hypercalls.rst b/future/hypercalls.rst deleted file mode 100644 index 9b9db20..0000000 --- a/future/hypercalls.rst +++ /dev/null @@ -1,5 +0,0 @@ -================================== -Standardizing Hypercalls Sub-Group -================================== - -2019-10-17: This list (to be populated) covers topics for the OpenAMP Standardizing Hypercalls (sub-group to decide what name they want to use) sub-group to discuss what to work on at their sub-group meetings. \ No newline at end of file diff --git a/future/index.rst b/future/index.rst deleted file mode 100644 index 0760451..0000000 --- a/future/index.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. OpenAMP documentation master file, created by - sphinx-quickstart on Wed Oct 5 10:21:26 2022. - You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. - -Future Work -=========== - -.. toctree:: - :maxdepth: 1 - :caption: Contents: - - remoteproc - services - device_tree - hypercalls - hmm - hardware_description - diff --git a/future/remoteproc.rst b/future/remoteproc.rst deleted file mode 100644 index b334e46..0000000 --- a/future/remoteproc.rst +++ /dev/null @@ -1,232 +0,0 @@ -.. _future-remoteproc-work-label: - -================================ -Remoteproc Sub-Group Future Work -================================ - -This list (needs update) covers topics for the "OpenAMP remoteproc" sub-group to discuss and work on. This sub-group covers areas such as remoteproc, rpmessage, virtio, big buffers, etc. - -The sections below should include an short abstract and links to prior discussion etc. More detailed information should be added on a new wiki page and a link to that page should be added to the topic here. - -HW description (Xilinx, TI, ST, Mentor) ---------------------------------------- - - - How to describe HW to System SW – Complete HW vs. OS centric subsystems – DT, IPExact. More info can be found here. - - Q: 2019/11/7, Is this the same as SystemDT and should be moved to that group, or are there rp specific topics? - -System Resource Management – (ST, Xilinx, TI, Cypress) ------------------------------------------------------- - - - How to configure and assign resources and peripherals to coprocessors - - Complications include clock and power domain control, system firewall and/or IOMMU configuration - - Some of this gets easier if both Linux and the remote processor are using a central system controller for clock. power, and peripheral access control like SCMI or TISCI - -OpenAMP project support for Virtio spec (Xilinx, TI, ST, Mentor) ----------------------------------------------------------------- - - - Packed vrings, indirect descriptors, … - - Virtio device handshake improvements - - Use of existing virtio drivers (ex: virtblk, virtnet, virtcon) from remoteprocs - * remoteproc could be frontend or backend (ex:could be the block user or block device) - * Q: 2019/10/7, should this be its own topic and leave this one to be just virtio mechanics? - -Remoteproc Virtio driver ------------------------- - -Remoteproc framework is covering coprocessor management (init, load, start, stop, crash, dump...), but also provides functions for vring support. That complicates the device management, mainly the parent/child relation and the memory region assignment. Idea is to create a virtrproc like virtmem or virtcon and rely on DT definition for driver probing. - - - ST has some patches to share - -Big data – (Xilinx, TI, ST) ---------------------------- - - - Rpmsg buffer management - - Zero copy and big buffer - - Heterogeneous Memory Management. More info can be found here BROKEN LINK - - libmetal shared memory allocation: https://github.com/OpenAMP/libmetal/issues/70 - - sub topics include allocation, mapping, IOMMU, remoteproc MMU, cache maintenance, address translation - - DMA-BUF heaps seems to be the obvious choice for allocation API now - -Kernel remoteproc CI patches - Loic ------------------------------------ - -The rate of remoteproc/rpmsg patch review/acceptance seems slow, what can we do to accelerate it? This page has a lot of stuff (and there is a lot more waiting as 2nd tier of features). (This is not about maintainer bashing; it is about working better together.) - - - more mailing list discussion - * patch review should be done on kernel rpmsg list not openamp-rp list - * openamp-rp list can be used for broader arch discussion and Linux/RTOS interaction - - more reviewed by/acked by/tested by cooperation - - remoteproc CI loop should help - -OpenAMP kernel staging tree - Bill ----------------------------------- - - - Create an OpenAMP github repo for linux to collect all carried and WIP patches in one place - - This is not to create a product, it is to more easily see what problem everyone is working around - - Suggestion is to have a branch per vendor where they collect all the remoteproc related patches as a rebase branch - - Extra: Some have suggested trying to merge all the vendor work together ahead of getting to mainline - * However this step seems controversial, lets not focus on that, at least for now - - Alternative: just collect a list of links to the vendor trees - * This is definitely easier but it can be a lot of work to find the relevant patches - -Remoteproc/rpmsg CI & regression test – (Xilinx, TI, ST) --------------------------------------------------------- - -Create a CI environment that can build both RTOS and Linux side and test existing and new operations. - - - QEMU based AMP SOC highly desired as target - - Should be usable in cloud CI (travis etc) and on individual developers desktop - - V0.1: Start with QEMU fork and any publicly reproducible build - - V1: Add build flow for easy developer mode - - Expand to board farm as second phase - - Nice to have: use upstream QEMU - -There is a Docker container (work in process), that runs an instance of Xilinx QEMU that supports up to 4 A-53 cores and 2 R5 cores. This boots Linux, loads the firmware into the R5 via remoteproc, and can run the OpenAMP rpmsg echo test. https://hub.docker.com/repository/docker/edmooring/qemu - -Secure coprocessor support – Loic ---------------------------------- - -Add a generic rproc driver to support secure and isolated coprocessor thanks to some trusted services based on OPTEE or other Trusted OS. Standard flow will be to load coprocessor firmware and its associated signature somewhere in secure/non-secure shared memory and then to request secure world to load, authenticate coprocessor image and then start coprocessor Some tasks: - - - Define a standard file format for firmware to authenticate (is ELF still relevant or should we rely on PKCS11 header like to integrate signature ?) - - Define TA API to control secure coprocessor (load, start, stop...) - - How to manage resource table in that case? Should we rely on some secure services or should we consider it as input for communication link (aka rpmsg) configuration between coprocessor and Linux kernel (and in that case could stay non-secure) - - Q: Can we make this generic enough to be used when coproessor is to be owned/trusted by a hypervisor instead of the secure world - -Linux RPMSG only mode - Bill (TI,) ----------------------------------- - -RPMSG should be usable in the Linux kernel when Linux will never be the life-cycle manager for that coprocessor. - -In many modern systems the Linux kernel is not the most trusted entity in the system. Sometimes a given coprocessor is loaded and managed by another entity that is more secure (ex: secure world), more safe (ex: dual lock-set R5), or more trusted (hypervisor). In these system Linux may never be the one that loads/starts/restarts/crash dumps the coprocessor but Linux still needs to use a rpmsg channel and perhaps other virtio based communication channels. - - - Need to tell remoteproc that it is not the controller - - Need to find the resource table in use - - remoteproc still needs to do: IOMMU mapping, PA to DA, etc - - Q: Can we make a generic remoteproc that is usable for this case that can handle some (but not all) SOCs? - - This model brings up many cases for robustness - -RPMSG robustness - Bill (TI,ST) -------------------------------- - - - If coprocessor goes down and comes backup, Linux needs to recognize that and re-establish rpmsg communication - - If Linux goes down (crash/shutdown) and restarts while the coprocessor stays running, coprocessor needs to recognize that and re-establisg rpmsg communication - - The restart should be advertised to the applications not hidden from them. Applications should take recovery actions themselves. - * On Linux this would probably mean an error code from the existing handle and a need to open a new one (or a issue a reset ioctl) - -Early coprocessor boot – late attach, detach - Loic (ST,TI) ------------------------------------------------------------ - -Late attach is different from rpmsg only mode in that once Linux comes up, it becomes the life cycle controller for the coprocessor. - - - Linux should have the option to stay with the firmware already loaded on the coprocessor. - - Linux could later stop or reload the coprocessor with different firmware - - Linux may take ownership of crashdump and debug logs - - Late attach could require that matching firmware file exists in the filesystem, this would make finding the resource table easier - - Or late attach could require to know where firmware resource table has previously been loaded as would be required in RPMSG only mode - -Detach means that Linux stops becoming the life cycle owner. This could happen while Linux is running or as part of Linux crash/shutdown. - -Early booted processor patch sent on ML: https://lore.kernel.org/patchwork/patch/1147726/ - -Lifecycle management and Trusted & Embedded Base Boot Requirement (T/E-BBR) – Etsam ------------------------------------------------------------------------------------ - -Lifecycle management with Linux remote – Etsam ----------------------------------------------- - -The life cycle management of Linux is required in scenarios where it provides the rich execution environment and certified software environment (e.g on low end CPUs such as cortex M or R) is the system master and responsible to start/stop/recover Linux. The intent here is to cover the driver architecture (e.g. remoteproc replacement ) and device tree bindings for remote Linux. No plan to cover the Linux bootstrapping and RPMSG remote mode operation. They can be treated as separate topics. Linux will still assumed to be the RPMsg master. - -Rpmsg protocol documentation for remote – Etsam ------------------------------------------------ - -The RPMSG framework master side protocol is well manifested in Linux upstream and new masters (e.g. OpenAMP) can be written using it as a reference. However, there is no standard Doc/Implementation for remote which often leads to problematic protocol scenarios. For instance, consider the two cases below: - - - At what point VDEV Resource is initialized by the Master, specially when the vrings are dynamically allocated? - * Conversely, at what point remote should access that vdev resource? Consider the case where vdev resource is accessed by the remote right after boot up, assumption here is that it is initialized by the master before starting the remote. This worked for kernel v3.18 , however, it is broken for v4.9 (may be for others as well) where the vring addresses are populated after remote is booted. For latter, this leads to race condition and sometimes remote ends up accessing uninitialized vdev resource. Apparently, the correct point to access vdev resource is after vdev status field (DRIVER_OK) is updated by the master. - - When to send the Name service announcement? - * In response to first kick from the master: This works if remote is up and running. What if kick is sent and remote is not yet operational? It will miss the kick and consequently NS will not be sent. - * In response to VDEV status update (DRIVER_OK). Will work if remote comes up after the first kick. The status will still be in the shared memory and can be used to send the NS. - -The foolproof approach would be to use both kick and VDEV status to send the NS. This point was found after trial and error. - -It is required to document all such scenarios i.e. all master actions and expected response from the remote, to enable seamless operation with different remotes. - -MCU – MCU issues, rpsmg only - Mark ------------------------------------ - - - libopenamp example of rpmsg only - * Does it exist, are there any remaining issues? - * target for CI loop - * how big is it? Measure as regression test - - MCU boot first - late-attach - * Crash recovery - - Are there MISRA issues with libopenamp? - * Is malloc required? Can this be easily mapped to something more static - - "Big" Data in context of MCU to MCU (same SOC) - * zero-copy? - - OpenAMP improvement - * Libmetal rework to be continued - * Integrates last feedbacks coming from Nordic benchmark - * Reduce memory footprint - * Stack usage - - rpmsg-lite: anything missing from libopenamp? - -64 bits support - Clément -------------------------- - - - 64 bits support in elf file, see https://patchwork.kernel.org/patch/11175161/ - * Elf 64 files are needed for 64 bits processors - - 64 bits addresses in resources table - * Currently, addresses are only on 32bits, this is really limitating for 64bits - - 64 bits features in vdev declaration - * Virtio Features are now using 64 bits. Without this support, we are tied to legacy 32bits features. - * Need to switch to at least 64 bits and provisioned more bits for future evolution - -Misc I/O over VirtIO/RPMSG - Loic, Bill ---------------------------------------- - - - Put the "IO" in VirtIO - - Virtual UART - * ST has patches - * should this be full UART control (baud rate, HW flow control, RI/DCE/DTE/CTS/RTS) or just a communication channel - * Is Linux the device or the user? - * example: MCU wants to send console messages to Linux for logging - * example: MCU owns a physical UART but wants Linux to use it. - - Virtual I2C - * ST has some patches - * exmaple: MCU owns phy I2C with multiple devices, presents virtual I2C for to Linux so it can use some but not all of the devices - - Virtual SPI - * ST has some patches - - Virtual GPIO - - Virtual register bank - * via: regmap - * Can be used on its own or as the base level of some of the above (GPIO seems obvious) - - Should these be over RPMSG, direct over virtio, or both? - -Reference: ST Presentation at ELC-E 2019, https://elinux.org/images/6/63/ELC_EU19_rpmsg.pdf - -Improve Coprocessor debug capabilities - Loic ---------------------------------------------- - -Today rproc framework offers access to a virtual trace file (circular buffer filed by coprocessor) which limit coprocessor debug capabilities. Tracks to explore: - - - How to store coprocessor traces in a log file (syslog like) to improve trace depth? - - How to get same timestamp between Linux and coprocessors to correlate trace - - How to control coprocessor debug infrastructure (coresight?) - - Is it possible to debug coprocessor firmware thanks to GDB/GDB server over rpmsg or mailbox? - - How to avoid clashing with external JTAG debugger (RPMSG only mode may help here) - -Past presentations and TODO lists -================================= - - - TI presentation on TODO list from 2017 - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2017/OpenAMP-TI-Roadmap.pdf - - ST presentation from 2018 on short term TODO list - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2018hkg/OpenAMP-short-term-topcis-st.pdf - - Xilinx presentation from 2017 on Intro - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2017/OpenAMP-Intro-Feb-2017.pdf - - TI presentation from 2018 on Big Data and robustness, IPC only and life cycle - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2018hkg/OpenAMP-Buffer-Exchange.pdf - - TI presentation from 2017 on coprocessor memory types and howto handle - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2017/OpenAMP-memory-types.pdf diff --git a/future/services.rst b/future/services.rst deleted file mode 100644 index f581921..0000000 --- a/future/services.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _future-services-work-label: - -=========================================== -Higher Level Services Sub-Group Future Work -=========================================== - -2019-10-17 - This list (to be populated) covers topics for the OpenAMP Higher Level Services (sub-group to decide what name they want to use) sub-group to discuss what to work on at their sub-group meetings. This sub-group covers areas such as Proxy, eRPC, WindRiver islet. \ No newline at end of file diff --git a/images/architecture/overview-architecture-libmetal.svg b/images/architecture/overview-architecture-libmetal.svg index eb7b30e..7d32252 100644 --- a/images/architecture/overview-architecture-libmetal.svg +++ b/images/architecture/overview-architecture-libmetal.svg @@ -132,7 +132,7 @@ - Host + Main @@ -182,7 +182,7 @@ - Remote Host + Remote Main diff --git a/images/architecture/overview-architecture-proxy.svg b/images/architecture/overview-architecture-proxy.svg index 31aa81c..178a562 100644 --- a/images/architecture/overview-architecture-proxy.svg +++ b/images/architecture/overview-architecture-proxy.svg @@ -132,7 +132,7 @@ - Host + Main @@ -173,7 +173,7 @@ - Remote Host + Remote Main diff --git a/images/architecture/overview-architecture-remoteproc.svg b/images/architecture/overview-architecture-remoteproc.svg index 11556f2..2f99240 100644 --- a/images/architecture/overview-architecture-remoteproc.svg +++ b/images/architecture/overview-architecture-remoteproc.svg @@ -132,7 +132,7 @@ - Host + Main @@ -175,7 +175,7 @@ - Remote Host + Remote Main diff --git a/images/architecture/overview-architecture-rpmsg.svg b/images/architecture/overview-architecture-rpmsg.svg index decef84..1282c46 100644 --- a/images/architecture/overview-architecture-rpmsg.svg +++ b/images/architecture/overview-architecture-rpmsg.svg @@ -132,7 +132,7 @@ - Host + Main @@ -174,7 +174,7 @@ - Remote Host + Remote Main diff --git a/images/architecture/overview-architecture.svg b/images/architecture/overview-architecture.svg index 83d1a88..b5c8b6e 100644 --- a/images/architecture/overview-architecture.svg +++ b/images/architecture/overview-architecture.svg @@ -132,7 +132,7 @@ - Host + Main @@ -173,7 +173,7 @@ - Remote Host + Remote Main diff --git a/images/demos/echo-test-components.svg b/images/demos/echo-test-components.svg index ae08c3c..6828b17 100644 --- a/images/demos/echo-test-components.svg +++ b/images/demos/echo-test-components.svg @@ -40,7 +40,6 @@ - @@ -129,7 +128,7 @@ - Host + Main @@ -304,7 +303,7 @@ - + @@ -313,7 +312,7 @@ - + @@ -322,7 +321,7 @@ - + diff --git a/images/demos/echo-test-control-flow.svg b/images/demos/echo-test-control-flow.svg index fe9c5b5..7b72b6b 100644 --- a/images/demos/echo-test-control-flow.svg +++ b/images/demos/echo-test-control-flow.svg @@ -1,12 +1,12 @@ - + - + - + @@ -41,8 +41,8 @@ + - @@ -53,8 +53,28 @@ + + + + + + + + + + + + + + + + + + + + - + @@ -104,7 +124,7 @@ - Host + Main @@ -112,167 +132,886 @@ - Remote + Remote - - + + - - + + - - - - Load Firmware + + + + Load Firmware - + - + - - - - Setup Resource Table + - + - + + + + SetupRemoteprocVirtio - + - - - - Setup Remoteproc + - + - + + + + Create RPMsgVirtio Device - + - - - - Create RPMsgVirtio Device + - + - + + + + Create RPMsgEnd Point - - - - Create RPMsgEnd Point + + + + Announce endpoint"rpmsg-openamp-demo-channel" - - - - Announce endpoint"rpmsg-openamp-demo-channel" + + + + Start Remote - - - - Start Remote + + + + Startecho_test - - - - Startecho_test + + + + Send RPMsg Packet - - - - Send RPMsg Packet + + + + Return RPMsg Packet - - - - Return RPMsg Packet + + + + Verify and repeat - - - - Verify and repeat + + + + Stop Remote - - - - Stop Remote + + + + Send RPMsg Shutdown Packet - - - - Send Shutdown Packet + + + + Return RPMsg Shutdown Packet - - - - Return Shutdown Packet + + + + Release RPMsgVirtio Device - - - - Release RpmsgVirtio Device + + + + RemoveRemoteproc Virtio - - - - RemoveRemoteproc + + + + Parse Resource Table + + + + + + + + Create RPMsgVirtio Device + + + + + + + + RPMsg Destroy Announcement + + + + + + + + Destroy RPMsgEnd Point + + + + + + + + Destroy RPMsgEnd Point + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platform Dependent + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platform Dependent + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platform Dependent + + + + + + + + Create RPMsgEnd Point diff --git a/images/demos/echo-test-intro.svg b/images/demos/echo-test-intro.svg index 0525a4f..7471b7c 100644 --- a/images/demos/echo-test-intro.svg +++ b/images/demos/echo-test-intro.svg @@ -14,17 +14,14 @@ - - - + + - - - + @@ -107,20 +104,20 @@ - + - + - Host Controller + Main @@ -131,14 +128,14 @@ - - + + - - + + @@ -164,7 +161,7 @@ - echo_test + echo_test @@ -172,7 +169,7 @@ - rpmsg_echo + rpmsg_echo diff --git a/images/demos/hvl-virtio-components.svg b/images/demos/hvl-virtio-components.svg index f72d6e3..70a6db0 100644 --- a/images/demos/hvl-virtio-components.svg +++ b/images/demos/hvl-virtio-components.svg @@ -42,7 +42,6 @@ - @@ -58,34 +57,25 @@ - - - - - - - - - - + @@ -135,7 +125,7 @@ - Host + Main @@ -158,28 +148,20 @@ - - - Virtio + + + Virtio - - - - ResourceTable - - - - Remoteproc - + @@ -195,7 +177,7 @@ - + @@ -205,31 +187,21 @@ - + Virtio - + OpenAMP - - - - - - - Resource Assign - - - - + @@ -239,29 +211,29 @@ - + libmetal - - - - libmetal + + + + libmetal - - - - - /hvl/setup.sh + + + + + /hvl/setup.sh - + @@ -269,7 +241,7 @@ - + @@ -277,17 +249,17 @@ - - + + - - - + + + - + @@ -296,36 +268,36 @@ - - + + - - + + - - - - Console Prompt + + + + Console Prompt - + - UART Prompt + UART Prompt - + ping/net - + @@ -334,11 +306,18 @@ - + Entropy Result + + + + + PMM + + diff --git a/images/demos/hvl-virtio-control-flow.svg b/images/demos/hvl-virtio-control-flow.svg index 5cfd6da..d47ccfd 100644 --- a/images/demos/hvl-virtio-control-flow.svg +++ b/images/demos/hvl-virtio-control-flow.svg @@ -1,12 +1,12 @@ - + - + - + @@ -32,13 +32,12 @@ - - + @@ -59,7 +58,7 @@ - + @@ -109,7 +108,7 @@ - Host + Main @@ -122,14 +121,14 @@ - - + + - - + + @@ -142,58 +141,32 @@ - + - - - - Setup Resource Table + + + + Get Random EntropyFrom Virtio Driver - + - - - - Setup Remoteproc - - - - - - - - - - - - - Get Random EntropyFrom Virtio Driver - - - - - - - - - - - - - Setup Virtio net interface192.168.200.2 + + + + Setup Virtio net interface192.168.200.2 - + @@ -201,23 +174,23 @@ - - - - - Ping from Host Console + + + + + Ping from Host Console - - - - - Ping from Remote Console + + + + + Ping from Remote Console - + diff --git a/images/demos/hvl-virtio-intro.svg b/images/demos/hvl-virtio-intro.svg index 602e235..22de96f 100644 --- a/images/demos/hvl-virtio-intro.svg +++ b/images/demos/hvl-virtio-intro.svg @@ -14,17 +14,14 @@ - - - + + - - - + @@ -124,7 +121,7 @@ - Host Controller + Main diff --git a/images/demos/matrix-multiply-components.svg b/images/demos/matrix-multiply-components.svg index 9eb4c8f..735f9ec 100644 --- a/images/demos/matrix-multiply-components.svg +++ b/images/demos/matrix-multiply-components.svg @@ -41,7 +41,6 @@ - @@ -129,7 +128,7 @@ - Host + Main @@ -265,7 +264,7 @@ - mat_mul_demo + mat_mul_demo diff --git a/images/demos/matrix-multiply-control-flow.svg b/images/demos/matrix-multiply-control-flow.svg index 27c9d98..67255ab 100644 --- a/images/demos/matrix-multiply-control-flow.svg +++ b/images/demos/matrix-multiply-control-flow.svg @@ -1,12 +1,12 @@ - + - + - + @@ -42,7 +42,6 @@ - @@ -53,8 +52,28 @@ + + + + + + + + + + + + + + + + + + + + - + @@ -104,7 +123,7 @@ - Host + Main @@ -112,172 +131,886 @@ - Remote + Remote - - + + - - + + - - - - Load Firmware + + + + Load Firmware - + - + - - - - Setup Resource Table + - + - + + + + Setup RemoteprocVirtio - + - - - - Setup Remoteproc + - + - + + + + Create RPMsgVirtio Device - + - - - - Create RPMsgVirtio Device + - + - + + + + Create RPMsgEnd Point - - - - Create RPMsgEnd Point + + + + Announce endpoint"rpmsg-openamp-demo-channel" - - - - Announce endpoint"rpmsg-openamp-demo-channel" + + + + Start Remote - - - - Start Remote + + + + Startmat_mul_demo - - - - Startmat_mul_demo + + + + Send RPMsg Packet - - - - Send RPMsg Packet + + + + Return RPMsg Packet - - - - Return RPMsg Packet + + + + Stop Remote - - - - Stop Remote + + + + Send RPMsg Shutdown Packet - - - - Send Shutdown Packet + + + + Return RPMsg Shutdown Packet - - - - Return Shutdown Packet + + + + Release RPMsgVirtio Device - - - - Release RpmsgVirtio Device + + + + RemoveRemoteproc Virtio - - - - RemoveRemoteproc + + + + Parse Resource Table - + - + + + + Create RPmsgVirtio Device - - - - MultiplyMatrices + + + + RPMsg Destroy Announcement + + + + + + + + Destroy RPmsgEnd Point + + + + + + + + Destroy RPMsgEnd Point + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platform Dependent + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platform Dependent + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platform Dependent + + + + + + + + MultiplyMatrices + + + + + + + + Create RPMsgEnd Point diff --git a/images/demos/matrix-multiply-intro.svg b/images/demos/matrix-multiply-intro.svg index 997d941..57bc84b 100644 --- a/images/demos/matrix-multiply-intro.svg +++ b/images/demos/matrix-multiply-intro.svg @@ -14,17 +14,14 @@ - - - + + - - - + @@ -129,7 +126,7 @@ - Host Controller + Main diff --git a/images/demos/replicate-firmware-components.svg b/images/demos/replicate-firmware-components.svg index 05b7632..5ac3a18 100644 --- a/images/demos/replicate-firmware-components.svg +++ b/images/demos/replicate-firmware-components.svg @@ -15,7 +15,6 @@ - @@ -41,7 +40,6 @@ - @@ -56,31 +54,22 @@ - - - - - - - - - - + @@ -130,7 +119,7 @@ - Host + Main @@ -153,21 +142,13 @@ - - - - ResourceTable - - - - Remoteproc - + @@ -183,7 +164,7 @@ - + @@ -193,24 +174,14 @@ - + OpenAMP - - - - - - - Resource Assign - - - - + @@ -220,14 +191,14 @@ - + libmetal - + @@ -235,7 +206,7 @@ - + @@ -243,7 +214,7 @@ - + @@ -252,7 +223,7 @@ - + @@ -260,7 +231,7 @@ - + @@ -269,21 +240,21 @@ - + OpenAMP - + libmetal - + @@ -291,13 +262,13 @@ - + printf - + @@ -306,13 +277,13 @@ - + printf - + @@ -322,7 +293,7 @@ - + @@ -332,7 +303,7 @@ - + @@ -340,14 +311,14 @@ - + TCM B - + TCM A diff --git a/images/demos/replicate-firmware-control-flow.svg b/images/demos/replicate-firmware-control-flow.svg index cd6df68..cbc5d43 100644 --- a/images/demos/replicate-firmware-control-flow.svg +++ b/images/demos/replicate-firmware-control-flow.svg @@ -1,12 +1,12 @@ - + - + - + @@ -14,28 +14,23 @@ - - - - - + - @@ -44,7 +39,7 @@ - + @@ -94,7 +89,7 @@ - Host + Main @@ -102,19 +97,19 @@ - Remote 1 + Remote 1 - - + + - - + + @@ -125,34 +120,8 @@ Load Firmware - - - - - - - - - - Setup Resource Table - - - - - - - - - - - - - Setup Remoteproc - - - - + @@ -160,29 +129,29 @@ - - - - - printf + + + + + printf - + - Remote 2 + Remote 2 - - - + + + - + @@ -190,70 +159,54 @@ - - - - - Setup Resource Table - - - - - - - - Setup Remoteproc - - - - - - - - Start Remote + + + + + Start Remote - - - - - printf + + + + + printf - - - - - Stop Remote + + + + + Stop Remote - - - - + + + + - - - Repeat + + + Repeat - + - UART + UART - - - + + + diff --git a/images/demos/replicate-firmware-intro.svg b/images/demos/replicate-firmware-intro.svg index 40a1cd2..3ff0ae3 100644 --- a/images/demos/replicate-firmware-intro.svg +++ b/images/demos/replicate-firmware-intro.svg @@ -14,17 +14,14 @@ - - - + + - - - + @@ -127,7 +124,7 @@ - Host Controller + Main diff --git a/images/demos/rpmsg-multi-services-components.svg b/images/demos/rpmsg-multi-services-components.svg index 0a01c68..31de664 100644 --- a/images/demos/rpmsg-multi-services-components.svg +++ b/images/demos/rpmsg-multi-services-components.svg @@ -44,7 +44,6 @@ - @@ -83,7 +82,7 @@ - + @@ -133,7 +132,7 @@ - Host + Main @@ -282,20 +281,20 @@ - + - - - + + + - + - - + + @@ -321,7 +320,7 @@ - app_rpmsg_client_sample + app_rpmsg_client_sample @@ -340,16 +339,16 @@ - - - rpmsg_char + + + rpmsg_char - - - Character + + + Character @@ -361,35 +360,35 @@ - - - rpmsg_client_sample + + + rpmsg_client_sample - - - rpmsg_tty + + + rpmsg_tty - + - - - + + + - + - - - + + + @@ -411,6 +410,22 @@ IPC + + + + + rpmsg_ctrl + + + + + + + + + + + diff --git a/images/demos/rpmsg-multi-services-control-flow.svg b/images/demos/rpmsg-multi-services-control-flow.svg index c45a5dd..56de496 100644 --- a/images/demos/rpmsg-multi-services-control-flow.svg +++ b/images/demos/rpmsg-multi-services-control-flow.svg @@ -1,12 +1,12 @@ - + - + - + @@ -50,7 +50,6 @@ - @@ -73,22 +72,40 @@ + + + + + + + + + + + + + + + + + + - + @@ -138,7 +155,7 @@ - Host + Main @@ -146,145 +163,137 @@ - Remote + Remote - - + + - - + + - - - - Load Firmware + + + + Load Firmware - + - + - - - - Setup Resource Table + - + - + + + + Setup RemoteprocVirtio - + - - - - Setup Remoteproc + - + - + + + + Create RPMsgVirtio Device - + - - - - Create RPMsgVirtio Device + - + - + + + + Create RPMsgChannel and End Point - - - - Create RPMsgChannel and End Point + + + + Name Service Message (RPMSG_NS_CREATE)"rpmsg-client-sample" - - - - Name Service Message (RPMSG_NS_CREATE)"rpmsg-client-sample" + + + + Start Remote - - - - Start Remote + + + + Create/dev/ttyRPMSG0 - - - - Create/dev/ttyRPMSG0 + + + + Send RPMsg Packet - - - - Send RPMsg Packet + + + + Return RPMsg Packet - - - - Return RPMsg Packet - - - - - - - - Repeat 100 times + + + + Repeat 100 times - - - - - app_rpmsg_client_sample + + + + + app_rpmsg_client_sample - - - + + + - + @@ -292,21 +301,21 @@ - - - + + + - - - - - Start thread + + + + + Start thread - + @@ -314,7 +323,7 @@ - + @@ -322,19 +331,19 @@ - - - + + + - - - + + + - + @@ -342,7 +351,7 @@ - + @@ -350,7 +359,7 @@ - + @@ -358,7 +367,7 @@ - + @@ -366,445 +375,3156 @@ - + rpmsg_ctrl + + + + + + - - + + + + Destroy RPMsgEnd Point - - - - Destroy RPMsgEnd Point + + + + Name Service Message (RPMSG_NS_DESTROY) - + - - - - Name Service Message (RPMSG_NS_DESTROY) + - + - + + + + Create RPMsgChannel and End Point - + - - - - Create RPMsgChannel and End Point + + + + app_rpmsg_tty - + - - - - app_rpmsg_tty + + - - + + + + Start thread - - - - Start thread + + + + Name Service Message (RPMSG_NS_CREATE)"rpmsg-tty" - - - - Name Service Message (RPMSG_NS_CREATE)"rpmsg-tty" + + + + Send RPMsg Packet - - - - Send RPMsg Packet + + + + Return RPMsg Packet - - - - Return RPMsg Packet + + + + Echo with prefix TTY 0 - - - - Echo with prefix TTY 0 + + + + echo Message - - - - echo Message + + + + cat Message - - - - cat Message + + + + Create/dev/rpmsg0 - + - - - - Create/dev/rpmsg0 + - + - + + + + Create RPMsgChannel and End Point - + - - - - Create RpmsgChannel and End Point + + + + app_rpmsg_raw - + - - - - app_rpmsg_raw + + - - + + + + Start thread - - - - Start thread + + + + Name Service Message (RPMSG_NS_CREATE)"rpmsg-raw" - - - - Name Service Message (RPMSG_NS_CREATE)"rpmsg-raw" + + + + Send RPMsg Packet - - - - Send RPMsg Packet + + + + Return RPMsg Packet - - - - Return RPMsg Packet + + + + Echo with prefixFrom ept 0x402 - - - - Echo with prefixFrom ept 0x402 + + + + rpmsg_ping /dev/rpmsg0 - - - - rpmsg_ping /dev/rpmsg0 + + + + cat /dev/rpmsg0 - - - - cat devrpmsg0 + + + + rpmsg_export_dev (RPMSG_CREATE_DEV_IOCTL) - - - - rpmsg_export_dev (RPMSG_CREATE_DEV_IOCTL) + + + + Create RPMsgChannel and End Point - - - + + + + Name Service Message (RPMSG_NS_CREATE)"rpmsg-tty" - - - - Create RPMsgChannel and End Point + + + + Create/dev/ttyRPMSG1 - - - - Name Service Message (RPMSG_NS_CREATE)"rpmsg-tty" + + + + Send RPMsg Packet - - - - Create/dev/ttyRPMSG1 + + + + Return RPMsg Packet - - - - Send RPMsg Packet + + + + Echo with prefix TTY 1 - - - - Return RPMsg Packet + + + + echo Message - - - - Echo with prefix TTY 1 + + + + cat Message - - - - echo Message + + + + RPMsg “bound” - - - - cat Message + + + + rpmsg_export_dev -d (RPMSG_RELEASE_DEV_IOCTL) - - - - RPMsg “bound” + + + + RPMSG_RELEASE_DEV_IOCTL - - - - rpmsg_export_dev -d (RPMSG_RELEASE_DEV_IOCTL) + + + + Destroy End Point - - - + + + + Name Service Message (RPMSG_NS_DESTROY) - - - - Destroy End Point + + + + Remove/dev/ttyRPMSG1 - - - - Name Service Message ()RPMSG_NS_DESTROY + + + + rpmsg_export_ept - - - - Remove/dev/ttyRPMSG1 + + + + Create/dev/rpmsg1 - - - - rpmsg_export_ept + + + + rpmsg_export_ept - - - - Create/dev/rpmsg1 + + + + Create/dev/rpmsg2 - - - - rpmsg_export_ept + + + + Send RPMsg Packet - - - - Create/dev/rpmsg2 + + + + Return RPMsg Packet - - - - Send RPMsg Packet + + + + Echo with prefixFrom ept 0x0001 - - - - Return RPMsg Packet + + + + rpmsg_ping /dev/rpmsg1 - - - - Echo with prefixFrom ept 0x0001 + + + + cat /dev/rpmsg0 - - - - rpmsg_ping /dev/rpmsg1 + + + + Send RPMsg Packet - - - - cat devrpmsg0 + + + + Return RPMsg Packet - - - - Send RPMsg Packet + + + + Echo with prefixFrom ept 0x0001 - - - - Return RPMsg Packet + + + + rpmsg_ping /dev/rpmsg1 - - - - Echo with prefixFrom ept 0x0001 + + + + cat /dev/rpmsg0 - - - - rpmsg_ping /dev/rpmsg1 + + + + Parse Resource Table - - - - cat devrpmsg0 + + + + Create RPMsgVirtio Device + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platform Dependent + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platform Dependent + + + + + + + + + + + + + Create RPMsgEnd Point + + + + + + + + Create RPMsgEnd Point + + + + + + + + Destroy RPMsgEnd Point + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A(direct) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + B(tty) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + C(char) @@ -812,4 +3532,4 @@ - + \ No newline at end of file diff --git a/images/demos/rpmsg-multi-services-intro.svg b/images/demos/rpmsg-multi-services-intro.svg index 8a58d20..8562190 100644 --- a/images/demos/rpmsg-multi-services-intro.svg +++ b/images/demos/rpmsg-multi-services-intro.svg @@ -14,17 +14,14 @@ - - - + + - - - + @@ -131,20 +128,20 @@ - + - + - Host Controller + Main @@ -155,20 +152,20 @@ - - + + - - + + - - Remote + + Remote @@ -188,7 +185,7 @@ - rpmsg_client_sample + rpmsg_client_sample @@ -220,7 +217,7 @@ - hello world!(100 times, then goodbye) + hello world!(100 times, then goodbye) @@ -272,19 +269,19 @@ - TTY 1: hello dev1 + TTY 1: hello dev1 - hello dev0 >/dev/ttyRPMSG0 + hello dev0 > /dev/ttyRPMSG0 - TTY 0: hello dev0 + TTY 0: hello dev0 @@ -342,7 +339,7 @@ - from ept 0x0402: ping /dev/rpmsg1 + from ept 0x0402: ping /dev/rpmsg1 @@ -354,7 +351,7 @@ - from ept 0x0402: ping /dev/rpmsg0 + from ept 0x0402: ping /dev/rpmsg0 @@ -384,7 +381,7 @@ - hello dev1 >/dev/ttyRPMSG1 + hello dev1 > /dev/ttyRPMSG1 diff --git a/images/demos/split-mode-components.svg b/images/demos/split-mode-components.svg index 8f64af5..e717b78 100644 --- a/images/demos/split-mode-components.svg +++ b/images/demos/split-mode-components.svg @@ -14,7 +14,6 @@ - @@ -32,13 +31,11 @@ - - @@ -51,31 +48,22 @@ - - - - - - - - - - + @@ -125,7 +113,7 @@ - Host + Main @@ -148,21 +136,13 @@ - - - - ResourceTable - - - - Remoteproc - + @@ -178,7 +158,7 @@ - + @@ -188,24 +168,14 @@ - + OpenAMP - - - - - - - Resource Assign - - - - + @@ -215,21 +185,21 @@ - + libmetal - + libmetal - + @@ -237,7 +207,7 @@ - + @@ -245,7 +215,7 @@ - + @@ -254,14 +224,14 @@ - + Console Prompt - + @@ -270,7 +240,7 @@ - + @@ -278,7 +248,7 @@ - + @@ -287,21 +257,21 @@ - + OpenAMP - + libmetal - + @@ -309,13 +279,13 @@ - + printf - + @@ -324,13 +294,13 @@ - + printf - + @@ -340,7 +310,7 @@ - + diff --git a/images/demos/split-mode-control-flow.svg b/images/demos/split-mode-control-flow.svg index b3b8590..a6dbc83 100644 --- a/images/demos/split-mode-control-flow.svg +++ b/images/demos/split-mode-control-flow.svg @@ -1,12 +1,12 @@ - + - + - + @@ -14,27 +14,21 @@ - - - - - - + - @@ -42,7 +36,7 @@ - + @@ -92,7 +86,7 @@ - Host + Main @@ -100,19 +94,19 @@ - Remote 1 + Remote 1 - - + + - - + + @@ -123,34 +117,8 @@ Load Firmware - - - - - - - - - - Setup Resource Table - - - - - - - - - - - - - Setup Remoteproc - - - - + @@ -158,29 +126,29 @@ - - - - - printf + + + + + printf - + - Remote 2 + Remote 2 - - - + + + - + @@ -188,56 +156,40 @@ - - - - - Setup Resource Table - - - - - - - - Setup Remoteproc - - - - - - - - Start Remote + + + + + Start Remote - - - - - printf + + + + + printf - - - - - Stop Remote + + + + + Stop Remote - - - - + + + + - - - Repeat + + + Repeat diff --git a/images/demos/split-mode-intro.svg b/images/demos/split-mode-intro.svg index fea1b51..e0c8f6a 100644 --- a/images/demos/split-mode-intro.svg +++ b/images/demos/split-mode-intro.svg @@ -14,17 +14,14 @@ - - - + + - - - + @@ -120,7 +117,7 @@ - Host Controller + Main diff --git a/images/fundamentals/host-2-remote.svg b/images/fundamentals/main-2-remote.svg similarity index 97% rename from images/fundamentals/host-2-remote.svg rename to images/fundamentals/main-2-remote.svg index e0e4c40..286cf56 100644 --- a/images/fundamentals/host-2-remote.svg +++ b/images/fundamentals/main-2-remote.svg @@ -41,15 +41,16 @@ - + + - + @@ -177,7 +178,7 @@ - Host Controller + Main Controller diff --git a/images/topo_types.svg b/images/topo-types.svg similarity index 93% rename from images/topo_types.svg rename to images/topo-types.svg index fbd9e7c..0f938e8 100644 --- a/images/topo_types.svg +++ b/images/topo-types.svg @@ -14,15 +14,16 @@ - + + - + @@ -52,7 +53,7 @@ - + @@ -113,14 +114,14 @@ - - + + - - + + @@ -131,20 +132,20 @@ - - + + - - + + - HostController + MainController @@ -155,14 +156,14 @@ - - + + - - + + @@ -203,14 +204,14 @@ - - + + - - + + @@ -221,14 +222,14 @@ - - + + - - + + @@ -270,19 +271,19 @@ - + - + - HostController 1 + MainController 1 @@ -294,59 +295,59 @@ - + - + - HostController 2 + MainController 2 - - + + - - + + - - + + - - + + - Host managing two remote contexts in start topology + Main controller managing two remote contexts in start topology - Two host contexts managing two remote contexts in chain topology + Two main controller contexts managing two remote contexts in chain topology diff --git a/index.rst b/index.rst index 8d850f1..b41a399 100644 --- 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 index dacbf44..7f7c961 100644 --- 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 `_ -- 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 `_. -Patch process -------------- -- Pull request on github for review and merging - - Against `OpenAMP main branch `_ - - Against `libmetal main branch `_ -- Maintainer ensures a minimum of 1 week review window prior to merge +You can contribute, through pull requests, directly to the main `OpenAMP libraries `_ or by porting OpenAMP to your 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 `_ - - `libmetal Maintainers `_ -- 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`. diff --git a/openamp/glossary.rst b/openamp/glossary.rst new file mode 100644 index 0000000..892d092 --- /dev/null +++ b/openamp/glossary.rst @@ -0,0 +1,22 @@ +======== +Glossary +======== + +.. csv-table:: Glossary + :header: "Acronym", "Description" + :widths: 20, 200 + + AMP, `Asymmentric Multiprocessing `_ + API, Application Interface + GPL, `GNU General Public License `_ + IPC, `Inter-Processor Communications `_ + LCM, Life-Cycle Management + OALK, OpenAMP Linux Kernel + OAOS, `OpenAMP Open Source Project `_ + OAPI, OpenAMP Proprietary Implementations + RPC, :ref:`Remote Procedure Calls (RPC)` + RTOS, Real Time Operating System + RPMsg, `Remote Processor Messaging `_ + SMP, `Symmetric Multiprocessing (SMP) `_ + SoC, System on Chip + Virtio, Virtual Input Output diff --git a/openamp/overview.rst b/openamp/overview.rst index ef152cf..dbdb6cf 100644 --- a/openamp/overview.rst +++ b/openamp/overview.rst @@ -8,28 +8,37 @@ OpenAMP Intro `Asymmetric Multiprocessing (AMP) `_ involves the management, control and communication of multi-core computer systems, where processors have independent tasks and are often in a `heterogeneous `_ embedded environment where there are different types of processors. This is in contrast to `Symmetric Multiprocessing (SMP) `_ 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`. +******* +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`, 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`) + * A guidance group under Linaro Community Projects + - Provides guidance for the low-level protocol that allows systems to interact (:ref:`more info here`) + Built on top of the `Virtio Open Standard `_ - - Standardizing on the user level APIs that allow applications to be portable + - Maintaining common user level APIs that allow applications to be portable + :ref:`RPMSG` + :ref:`remoteproc` - - **Standardizing on the low-level** :ref:`OS/HW abstraction layer` **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` 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` @@ -56,15 +65,15 @@ There are some AMP fundamentals which influence the OpenAMP architecture. Topology ======== -The OpenAMP framework assumes a host controller to remote system architecture, but otherwise the **topology** of the different runtime systems may be star, chain or a combination. +The OpenAMP framework assumes a main controller to remote system architecture, but otherwise the **topology** of the different runtime systems may be star, chain or a combination. .. image:: ../images/topo_types.svg -A host will control one or more remotes cores each on a remote processor (star), and any remote processor could also act as a controller to manager another set of cores on a different remote processor (chain). Each remote could be an individual or multiple cores of a processor. +A main controller will control one or more remote cores each on a remote processor (star), and any remote processor could also act as a controller to manage another set of cores on a different remote processor (chain). Each remote could be an individual or multiple cores of a processor. -To exemplify, the following sections use diagrams detailing a star topology with a single Linux host controller and dual remote cores, with one remote core running an RTOS and the other a bare metal image. The choice of operating systems is arbitrary and just for this example. +To exemplify, the following sections use diagrams detailing a star topology with a single Linux main controller and dual remote cores, with one remote core running an RTOS and the other a bare metal image. The choice of operating systems is arbitrary and just for this example. -.. image:: ../images/fundamentals/host-2-remote.svg +.. image:: ../images/fundamentals/main-2-remote.svg .. _resource-assignment-work-label: @@ -75,7 +84,7 @@ This diagram details the Resource Assignment using a different color for each ** .. image:: ../images/fundamentals/resource-assignment.svg -The yellow colored boxes are the Linux **runtime domain** as the host controller running on a single processor, utilizing the two cores in a `Symmetric Multiprocessing `_ setup. The green and blue colored boxes details the RTOS and Bare Metal remote applications each running on a single core of a remote processor as their own **runtime domain**. The Linux system shares memory with both remotes, but the remote applications do not share memory. Each domain owns independent peripherals in the system. Although the Linux domain is `SMP `_, all three **runtime domains** together make up an `AMP `_ system. +The yellow colored boxes are the Linux **runtime domain** as the main controller running on a single processor, utilizing the two cores in a `Symmetric Multiprocessing `_ setup. The green and blue colored boxes details the RTOS and Bare Metal remote applications each running on a single core of a remote processor as their own **runtime domain**. The Linux system shares memory with both remotes, but the remote applications do not share memory. Each domain owns independent peripherals in the system. Although the Linux domain is `SMP `_, all three **runtime domains** together make up an `AMP `_ system. .. _runtime-control-work-label: @@ -84,7 +93,7 @@ Runtime Control .. image:: ../images/fundamentals/runtime-control.svg -With the domains defined, **runtime control** of the asymmetric remote applications can be started to handle :ref:`Life Cycle Management (LCM)` of the remotes. The host controller will load and control the images as required. In this example the RTOS image could be loaded at power on to perform say environmental instrument monitoring and the bare metal image on demand to perform some specific high intensity calculations, but stopped on completion for power savings. The control flow will be implementation specific. +With the domains defined, **runtime control** of the asymmetric remote applications can be started to handle :ref:`Life Cycle Management (LCM)` of the remotes. The main controller will load and control the images as required. In this example the RTOS image could be loaded at power on to perform say environmental instrument monitoring and the bare metal image on demand to perform some specific high intensity calculations, but stopped on completion for power savings. The control flow will be implementation specific. .. _ipc-work-label: @@ -93,10 +102,10 @@ Inter Processor Communications .. image:: ../images/fundamentals/ipc.svg -`Inter Processor Communications `_ is performed through shared memory and is between host controller and remote. -In the example, the IPC could be instrument updates from the RTOS remote to the Linux host controller to display, and independently :ref:`Remote Procedure Calls (RPC)` between the Linux host controller and the other, bare metal, remote responsible for resource intensive calculations. +`Inter Processor Communications `_ is performed through shared memory and is between main controller and remote. +In the example, the IPC could be instrument updates from the RTOS remote to the Linux main controller to display, and independently :ref:`Remote Procedure Calls (RPC)` between the Linux main controller and the other, bare metal, remote responsible for resource intensive calculations. -In this star topology example the remotes cannot communicate with each other. If that were required a chain topology would be used instead to allow one remote to be both a remote and a host controller in which case they could communicate (refer to :ref:`Architecture Section` for an example). +In this star topology example the remotes cannot communicate with each other. If that were required a chain topology would be used instead to allow one remote to be both a remote and a main controller in which case they could communicate (refer to :ref:`Architecture Section` for an example). .. _resource-isolation-work-label: @@ -128,9 +137,9 @@ The components comprising OpenAMP are: :ref:`Libmetal`, Hardware Abstraction -The :ref:`topology` is limited to host controller to remote system but otherwise open to the implementation. +The :ref:`topology` is limited to main controller to remote system but otherwise open to the implementation. -The architecture is exemplified below via a daisy chained topology, with the center processor being both remote and host controller for the next processor in the chain. This is an alternate topology to the previous example in the :ref:`OpenAMP Fundamentals` section. +The architecture is exemplified below via a daisy chained topology, with the center processor being both remote and main controller for the next processor in the chain. This is an alternate topology to the previous example in the :ref:`OpenAMP Fundamentals` section. .. image:: ../images/architecture/overview-architecture.svg @@ -154,20 +163,20 @@ RPMsg and Virtio Standardization of the IPC is promoted by the OpenAMP project through the use of :ref:`RPMsg `, using `Open Standard Virtio Devices `_ as a HW abstraction or MAC layer. -This abstraction, using virtio, means that the implementer can optionally use :ref:`resource isolation` (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` (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 .. _overview-proxy-rpc-work-label: -Proxy and RPC -============= +RPMsg Services +============== -The OpenAMP Proxy and RPC Service are higher level IPC components. +OpenAMP provides higher level IPC components as RPMsg Services. There is a Remote Procedure Call (RPC) service and Proxy service. -The proxy provides file IO on the remote allowing access to the filesystem on the host controller. This provides a mechanism for remotes to access files occasionally without having to introduce a full filesystem on the remote. In the architecture diagram the center processor remote proxies file IO from its host controller on the left. +The proxy provides file IO on the remote allowing access to the filesystem on the main controller. This provides a mechanism for remotes to access files occasionally without having to introduce a full filesystem on the remote. In the architecture diagram the center processor remote proxies file IO from its main controller on the left. -The RPC service provides for remote procedure calls from a server to a client. In the architecture diagram the right hand processor has the RPC server servicing the center host controller processor's RPC client. +The RPC service provides for remote procedure calls from a server to a client. In the architecture diagram the right hand processor has the RPC server servicing the center main controller processor's RPC client. .. image:: ../images/architecture/overview-architecture-proxy.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 `_ (OAOS), - - a Linux kernel project (OALK), coming through the regular `remoteproc `_/`RPMsg `_/`Virtio `_ efforts in the kernel. + - an OpenAMP Linux Kernel (OALK) project, coming through the regular `remoteproc `_/`RPMsg `_/`Virtio `_ efforts in the kernel. - multiple proprietary implementations (OAPI). The operating environments that OpenAMP supports include: @@ -223,9 +232,7 @@ There are a few guiding principles that governs OpenAMP: * In particular :ref:`remoteproc`, :ref:`RPMsg ` and 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`/:ref:`RPMsg `/virtio + * In particular make sure to be compatible with the Linux kernel implementation of :ref:`remoteproc`/:ref:`RPMsg `/`Virtio `_ There are a number of project members as outlined in `OpenAMP Project Page `_ as well as many community members, so please join the :ref:`OpenAMP open source project`! - 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`. diff --git a/protocol_details/components.rst b/protocol_details/components.rst index adcd322..1f9b5c2 100644 --- 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) `_ between independent software contexts running on homogeneous or `heterogeneous `_ 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 ********** diff --git a/protocol_details/lifecyclemgmt_overview.rst b/protocol_details/lifecyclemgmt_overview.rst index e5f95ab..1413dec 100644 --- a/protocol_details/lifecyclemgmt_overview.rst +++ b/protocol_details/lifecyclemgmt_overview.rst @@ -47,4 +47,4 @@ Gracefully bringing down the remote context is not part of the remoteproc LCM, b 3. On receiving the shutdown acknowledge message, the host application invokes the remoteproc_shutdown API to shut down the remote processor and de-initialize remoteproc using remoteproc_deinit on its side. -The OpenAMP samples and demos exemplify the use of an application specific message to perform graceful shutdown before the hard remoteproc_shutdown is performed. For an example, see the Shutdown Packet in the `Echo Test Messaging Flow diagram` which is implemented as the SHUTDOWN_MSG in the source `open-amp Repository `_. +The OpenAMP samples and demos exemplify the use of an application specific message to perform graceful shutdown before the hard remoteproc_shutdown is performed. For an example, see the Shutdown Packet in the `Echo Test Messaging Flow diagram` which is implemented as the SHUTDOWN_MSG in the source `open-amp Repository `_. diff --git a/protocol_details/rpmsg_protocol.rst b/protocol_details/rpmsg_protocol.rst index 0fa8f1e..ee344e1 100644 --- a/protocol_details/rpmsg_protocol.rst +++ b/protocol_details/rpmsg_protocol.rst @@ -27,7 +27,7 @@ This layer is the key part of the whole solution - thanks to this layer, there i This technique is however applicable only in core-to-core configuration, not in core-to-multicore configuration, since in such a case, there would be multiple writers to the “IN” ring buffer. This would require a synchronization element, [such as a semaphore?], which is not desirable. -The above shown picture describes the vring component. The Vring is composed of three elementary parts - buffer descriptor pool, the “available” ring buffer (or input ring buffer) and the “used” ring buffer (or free ring buffer). All three elements are physically stored in the shared memory. +The above shown picture describes the vring component. The Vring is composed of three elementary parts - buffer descriptor pool, the available ring buffer and the used ring buffer. All three elements are physically stored in the shared memory. Each buffer descriptor contains a 64-bit buffer address, which holds an address to a buffer stored in the shared memory (as seen physically by the “receiver” or host of this vring), its length as a 32-bit variable, 16-bit flags field and 16-bit link to the next buffer descriptor. The link is used to chain unused buffer descriptors and to chain descriptors, which have the F_NEXT bit set in the flags field to the next descriptor in the chain. @@ -35,15 +35,17 @@ Note that the available and used ring buffer areas contain pointers to buffers, .. image:: ../images/vring_descriptor.jpg -The input ring buffer contains its own flags field, where only the 0th bit is used - if it is set, the “writer” side should not be notified, when the “reader” side consumes a buffer from the input or “avail” ring buffer. By default the bit is not set, so after the reader consumes a buffer, the writer should be notified by triggering an interrupt. The next field of the input ring buffer is the index of the head, which is updated by the writer, after a buffer index containing a new message is written in the ring[x] field. +The available ring buffer contains its own flags field, where only the 0th bit is used - if it is set, the “writer” side should not be notified, when the “reader” side consumes a buffer from the available ring buffer. By default the bit is not set, so after the reader consumes a buffer, the writer should be notified by triggering an interrupt. The next field of the available ring buffer is the index of the head, which is updated by the writer, after a buffer index containing a new message is written in the ring[x] field. -.. image:: ../images/vring_descriptor_flags.jpg +.. figure:: ../images/vring_descriptor_flags.jpg -The last part of the vring is the “used” ring buffer. It contains also a flags field and only the 0th bit is used - if set, the writer side will not be notified when the reader updates the head index of this free ring buffer. The following picture shows the ring buffer structure. The used ring buffer differs from the avail ring buffer. For each entry, the length of the buffer is stored as well. + Flags (16 bit) Fields of Available Ring Buffer Descriptor + +The last part of the vring is the used ring buffer. It contains also a flags field and only the 0th bit is used - if set, the writer side will not be notified when the reader updates the head index of this used ring buffer. The following picture shows the ring buffer structure. The used ring buffer differs from the available ring buffer. For each entry, the length of the buffer is stored as well. .. image:: ../images/vrings_used_buffers.jpg -Both “used” and “avail” ring buffers have a flags field. Its purpose is mainly to tell the writer whether he should interrupt the other core when updating the head of the ring. The same bit is used for this purpose in both “used” and “avail” ring buffers: +Both used and available ring buffers have a flags field. Its purpose is mainly to tell the writer whether he should interrupt the other core when updating the head of the ring. The same bit is used for this purpose in both used and available ring buffers: .. image:: ../images/vrings_used_buffers_flags.jpg @@ -75,7 +77,7 @@ Every remote core in the RPMsg component is represented by an RPMsg device that RPMsg Endpoint ~~~~~~~~~~~~~~ -RPMsg endpoints provide logical connections on top of an RPMsg channel. They allows the user to bind multiple rx callbacks on the same channel. +RPMsg endpoints provide logical connections on top of an RPMsg channel. They allow the user to bind multiple rx callbacks on the same channel. Every RPMsg endpoint has a unique src address and associated call back function. When an application creates an endpoint with the local address, all further inbound messages with the destination address equal to the local address of endpoint are routed to that callback function. Every channel has a default endpoint which enables applications to communicate without even creating new endpoints.