OpenAMP · sipke · Jan 27, 2025 · Jan 27, 2025 · Jan 27, 2025 · Jan 27, 2025
diff --git a/current/application_services.rst b/current/application_services.rst
diff --git a/current/ci.rst b/current/ci.rst
diff --git a/current/device_trees.rst b/current/device_trees.rst
diff --git a/current/inclusive_language.rst b/current/inclusive_language.rst
diff --git a/current/index.rst b/current/index.rst
diff --git a/current/ipc.rst b/current/ipc.rst
diff --git a/current/older_topics.rst b/current/older_topics.rst
diff --git a/current/remoteproc.rst b/current/remoteproc.rst
diff --git a/current/system_reference.rst b/current/system_reference.rst
diff --git 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)<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

diff --git 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) <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>`_.
 

diff --git a/demos/inter_process.rst b/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>`_.