Changes B for Issue 38

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)<ipc-work-label>` components by providing an echo application on a remote which simply returns (echoes) packets as they are received at an :ref:`RPMsg endpoint <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)<ipc-work-label>` components by providing an echo application on a remote which simply returns (echoes) packets as they are received at an :ref:`RPMsg endpoint <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<echo-test-remote-app>` runs as an echo service, which returns packets it receives on an :ref:`RPMsg endpoint <rpmsg-endpoint>`.
-The :ref:`host application<echo-test-host-app>` is the test application sending packets to the echo service and monitoring for their return.
+The :ref:`main controller application<echo-test-host-app>` 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 <rpmsg-endpoint>` running as the main task on the remote processor, once loaded and started using :ref:`Remoteproc<overview-remoteproc-work-label>`.
+The remote application, rpmsg-echo, is the core of the demonstration. It is a simple application serving a :ref:`RPMsg endpoint <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<echo-test-remote-app>` and starting the remote processor using :ref:`Remoteproc<overview-remoteproc-work-label>`.
+The main controller is also responsible for loading the firmware containing the :ref:`RPMsg Echo Remote Application<echo-test-remote-app>` and starting the remote processor using :ref:`Remoteproc<overview-remoteproc-work-label>`.
 
-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<docker-images-label>` 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 <https://github.com/OpenAMP/open-amp/blob/main/apps/examples/echo/rpmsg-echo.c>`_
+The RPMsg Echo service application is available as a baremetal solution in the `open-amp Repository <https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/legacy_apps/examples/echo/rpmsg-echo.c>`_
 
 It is a CMake application and can be built for any remote as long as the relevant :ref:`OS/HW abstraction layer<porting-guide-work-label>` 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 <https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/linux/rpmsg-echo-test/echo_test.c>`_.
 
 It is a Makefile application and can be built using the `Yocto rpmsg-echo-test recipe <https://github.com/OpenAMP/meta-openamp/blob/master/recipes-openamp/rpmsg-examples/rpmsg-echo-test_1.0.bb>`_
 
-An example host control script is given in the `echo test readme <https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/linux/rpmsg-echo-test/README.md#run-the-demo>`_
+An example main control script is given in the `echo test readme <https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/linux/rpmsg-echo-test/README.md#run-the-demo>`_
 
 *******************************
 Reference Board Implementations

demos/hvl_virtio.rst

@@ -22,7 +22,7 @@ All demonstrations are run on a remote running `Zephyr Operating System (OS) <ht
 Hypervisorless Virtio Components
 ********************************
 
-This demonstration uses a single application on the remote and a setup and demo script on the host.
+This demonstration uses a single application on the remote and a setup and demo script on the main controller.
 
 The underlying OpenAMP architectural components used by these applications are
 
@@ -46,14 +46,14 @@ The top-level control flow is shown in the following message diagram.
 Hypervisorless Virtio Remote Application
 ========================================
 
-The remote application is the core of the demonstration. It is a simple application utilising a number of Virtio devices, once loaded and started using :ref:`Remoteproc<overview-remoteproc-work-label>`.
+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 <https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-3360004>`_ to obtain entropy values to print to the UART console. Subsequently, it sets up `Virtio Network Device <https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-2340001>`_ 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 <https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-3360004>`_ to obtain entropy values to print to the UART console. Subsequently, it sets up `Virtio Network Device <https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-2340001>`_ 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 <https://en.wikipedia.org/wiki/TUN/TAP>`_, loading the firmware containing the :ref:`Hypervisorless Virtio Application<hvl-virtio-remote-app>` and starting the remote processor using :ref:`Remoteproc<overview-remoteproc-work-label>`.
+The main controller is responsible for setting up a `virtual/tap network <https://en.wikipedia.org/wiki/TUN/TAP>`_, loading the firmware containing the :ref:`Hypervisorless Virtio Application<hvl-virtio-remote-app>` and starting the remote processor using :ref:`Remoteproc<overview-remoteproc-work-label>`.
 
 The scripts are available in the :ref:`Demo Docker Images<docker-images-label>` as `demo4 <https://github.com/OpenAMP/openamp-demo/blob/main/demos/demo-hvl-virtio/my-extra-stuff/home/root/demo4>`_ and `setup.sh <https://github.com/OpenAMP/openamp-demo/blob/main/demos/demo-hvl-virtio/my-extra-stuff/hvl/setup.sh>`_.
 

demos/inter_process.rst

@@ -4,11 +4,11 @@
 Running Demos as Processes on Linux
 ===================================
 
-The `OpenAMP project examples <https://github.com/OpenAMP/open-amp/tree/main/apps/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 <https://github.com/OpenAMP/openamp-system-reference/tree/main/examples>`_
+are intended to execute on the remote of a reference board but can also be demonstrated by implementing as a process on the main controller, effectively emulating a remote.
 
 This can be useful for demonstration purposes, but can also be leveraged for component testing, even as part of a continuous integration setup.
 
-Effectively the `OpenAMP Library <https://github.com/OpenAMP/open-amp/tree/main/lib>`_ and `reference examples <https://github.com/OpenAMP/open-amp/tree/main/apps/examples>`_ are built for the host system along with the `host examples <https://github.com/OpenAMP/openamp-system-reference/tree/main/examples/linux>`_.
+Effectively the `OpenAMP Library <https://github.com/OpenAMP/open-amp/tree/main/lib>`_ and `reference examples <https://github.com/OpenAMP/open-amp/tree/main/apps/examples>`_ are built for the main controller system along with the `main controller examples <https://github.com/OpenAMP/openamp-system-reference/tree/main/examples/linux>`_.
 
 To build and execute on a Linux system, refer to the `example to compile OpenAMP for communication between Linux processes <https://github.com/OpenAMP/open-amp/blob/main/README.md#example-to-compile-openamp-for-communication-between-linux-processes>`_.

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)<overview-proxy-rpc-work-label>` 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)<overview-proxy-rpc-work-label>` 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<overview-proxy-rpc-work-label>`
 * :ref:`Libmetal<overview-proxy-libmetal-label>`
 
-The Linux file and stdio access is performed in the `linux_rpc_demod application <https://github.com/OpenAMP/open-amp/blob/main/apps/examples/linux_rpc_demo/linux_rpc_demod.c>`_.
+The Linux file and stdio access is performed in the `linux_rpc_demod application <https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/legacy_apps/examples/linux_rpc_demo/linux_rpc_demod.c>`_.
 
 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 <https://github.com/OpenAMP/open-amp/blob/main/apps/examples/linux_rpc_demo/linux_rpc_demod.c>`_, 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 <https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/legacy_apps/examples/linux_rpc_demo/linux_rpc_demod.c>`_, 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 <https://github.com/OpenAMP/open-amp/blob/main/apps/examples/linux_rpc_demo/linux_rpc_demo.c>`_
+The current implementation is a Linux process `linux_rpc_demo <https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/legacy_apps/examples/linux_rpc_demo/linux_rpc_demo.c>`_
 
 
 *******************************