Docs: Restructure in the Platfoms section
- Move platforms' documentaions from /ext/target/ to the /platform folder
- Name arm platforms in TOC explicitly.
- Merge CS-1000 platform README with Openamp doc
- Rebase and include RSS platform
Signed-off-by: Anton Komlev <anton.komlev@arm.com>
Change-Id: If8bc343e92910e2ce94f1fe1d6c8c81802d63165
diff --git a/docs/platform/arm/corstone1000/openamp/images/example_psa_call_workflow.png b/docs/platform/arm/corstone1000/openamp/images/example_psa_call_workflow.png
new file mode 100644
index 0000000..88234c3
--- /dev/null
+++ b/docs/platform/arm/corstone1000/openamp/images/example_psa_call_workflow.png
Binary files differ
diff --git a/docs/platform/arm/corstone1000/openamp/images/files_relationship.png b/docs/platform/arm/corstone1000/openamp/images/files_relationship.png
new file mode 100644
index 0000000..0960ede
--- /dev/null
+++ b/docs/platform/arm/corstone1000/openamp/images/files_relationship.png
Binary files differ
diff --git a/docs/platform/arm/corstone1000/openamp/readme.rst b/docs/platform/arm/corstone1000/openamp/readme.rst
new file mode 100644
index 0000000..43e74c4
--- /dev/null
+++ b/docs/platform/arm/corstone1000/openamp/readme.rst
@@ -0,0 +1,34 @@
+##############################
+Use of OpenAMP in Corstone1000
+##############################
+ARM's Corstone1000 platform uses openamp for tf-m non-secure
+communication. The openamp interface is used to recieve
+messages and send response to the host (Linux). The
+PSA Client library decodes messages received through
+OpenAMP and fowards the decoded messages to TF-M's SPM.
+
+TF-M has Mailbox solution which supports non-secure
+bare-meta applications. In the Corstone1000, the non-secure side
+is Linux environment so openamp is used instead.
+
+The file naming convention used here is aligned with TF-M's
+`secure_fw` naming convention. This is just to make sure
+in future file name does not require change if TF-M adopts
+this implementation.
+
+
+**************************
+Relationship between files
+**************************
+
+.. image:: images/files_relationship.png
+
+*********************
+SQL Diagram: PSA Call
+*********************
+
+.. image:: images/example_psa_call_workflow.png
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
diff --git a/docs/platform/arm/corstone1000/readme.rst b/docs/platform/arm/corstone1000/readme.rst
new file mode 100644
index 0000000..3925455
--- /dev/null
+++ b/docs/platform/arm/corstone1000/readme.rst
@@ -0,0 +1,119 @@
+#############
+Corstone-1000
+#############
+
+************
+Introduction
+************
+
+The ARM's Corstone-1000 platform is a reference implementation of PSA FF-M
+architecture where NSPE and SPE environments are partitioned/isolated into
+Cortex-A35 and Cortex-M0+ respectively.
+
+Cortex-M0+ acting as Secure Enclave is the Root-of-trust of SoC. Its
+software comprises of two boot loading stages, i.e. Bl1 and Bl2 (based on
+mcuboot) and TF-M as run time software. Cortex-A35, also referred as host,
+is treated as non-secure from the Secure Enclave perspective.
+The Cortex-A35 is brought out of rest by Secure Enclave in aarch64 bit mode,
+and boots the software ecosystem based on linux, u-boot, UEFI run time
+services, TF-A, Secure Partitions and Optee.
+
+The communication between NSPE and SPE is based on PSA IPC protocol running on
+top of FF-A/OpenAMP.
+
+.. toctree::
+ :maxdepth: 1
+ :glob:
+
+ openamp/**
+
+The secure enclave subsystem has ARM's CC-312 (Crypto Cell) hardware to
+accelerate cryptographic operations. Additionaly, platform supports Secure Debug
+using SDC-600 as the communication interface between host debugger and platform
+target. The platform has the build option to enable secure debug protocol to
+unlock debug ports during boot time. The protocol is based on ARM's ADAC
+(Authenticated Debug Access Control) standard.
+
+
+***********
+System boot
+***********
+
+- The SoC reset brings Secure Enclave (SE), that is Cortex-M0+, out of rest.
+- SE executes the BL1 ROM code based on mcuboot.
+- BL1 load, verifies and transfer execution to BL2 which is again based on mcuboot.
+- BL2 loads and verifies TF-M and host's initial boot loader image.
+- BL2 transfer the execution to the TF-M.
+- During TF-M initialization, the host is taken out of rest.
+- Hashes of the keys used for image verification are stored in the OTP memory.
+
+*****
+Build
+*****
+
+Platform solution
+=================
+
+The platform binaries are build using Yocto. Below is the user guide:
+
+`Arm Corstone-1000 User Guide`_
+
+Secure Test
+===========
+
+This section can be used to test the secure enclave software indedendently from
+the host. The below configuration builds the secure enclave binaries with CI test
+frame integrated. On boot, secure enclave softwares stack is brought up, and
+CI tests starts executing at the end of the initialization process. In the
+below configuration, host software support is disabled, and meant only
+to test/verify the secure enclave softwares.
+
+FVP
+---
+
+- Download Corstone-1000 FVP from : `Arm Ecosystem FVPs`_
+- Install FVP by running the shell script.
+- Running of the binary will boot secure enclave software stack and at the end all CI test
+ from tf-m-test along with platform specific tests are executed.
+
+.. code-block:: bash
+
+ cmake -B build/ -S <tf-m-root>/ -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM.cmake -DTFM_PLATFORM=arm/corstone1000 -DPLATFORM_IS_FVP=TRUE -DTEST_NS=OFF -DTEST_S=ON -DEXTRA_S_TEST_SUITES_PATHS=<tf-m-root>/trusted-firmware-m/platform/ext/target/arm/corstone1000/ci_regression_tests/
+ cmake --build build -- install
+ cd ./build/install/outputs/
+ cat bl2_signed.bin bl2_signed.bin tfm_s_signed.bin > cs1000.bin
+ cd <path-to-FVP-installation>/models/Linux64_GCC-9.3/
+ ./FVP_Corstone-1000 -C board.flashloader0.fname="none" -C se.trustedBootROMloader.fname="./<path-to-build-dir>/install/outputs/bl1.bin" -C board.xnvm_size=64 -C se.trustedSRAM_config=6 -C se.BootROM_config="3" -C board.smsc_91c111.enabled=0 -C board.hostbridge.userNetworking=true --data board.flash0=./<path-to-build-dir>/install/outputs/cs1000.bin@0x68100000 -C diagnostics=4 -C disable_visualisation=true -C board.se_flash_size=8192 -C diagnostics=4 -C disable_visualisation=true
+
+FPGA
+----
+
+- Follow the above pointed platform user guide to setup the FPGA board.
+- Use the BL1 generated from the below commands to place it inside FPGA board SD Card.
+- Use the cs1000.bin created from the below commands to place it inside FPGA board SD Card.
+
+.. code-block:: bash
+
+ cmake -B build/ -S <tf-m-root>/ -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM.cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DEXTRA_S_TEST_SUITES_PATHS=<tf-m-root>/trusted-firmware-m/platform/ext/target/arm/corstone1000/ci_regression_tests/ -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF
+ cmake --build build -- install
+ cd ./build/install/outputs/
+ cat bl2_signed.bin bl2_signed.bin tfm_s_signed.bin > cs1000.bin
+ cp bl1.bin <path-to-FPGA-SD-CARD>/SOFTWARE/
+ cp cs1000.bin <path-to-FPGA-SD-CARD>/SOFTWARE/
+
+FPGA build can not compile all the CI tests into a single build as it exceeds
+the available RAM size. So there is a need to select few tests but not all.
+The above configuration disable build of -DTEST_S_PS and -DTEST_S_PLATFORM.
+Other test configurations are:
+
+- -DTEST_S_ATTESTATION=ON/OFF
+- -DTEST_S_AUDIT=ON/OFF
+- -DTEST_S_CRYPTO=ON/OFF
+- -DTEST_S_ITS=ON/OFF
+- -DTEST_S_PS=ON/OFF
+- -DTEST_S_PLATFORM=ON/OFF
+
+*Copyright (c) 2021-2022, Arm Limited. All rights reserved.*
+
+.. _Arm Ecosystem FVPs: https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
+.. _Arm Corstone-1000 User Guide: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/blob/CORSTONE1000-2022.04.19/docs/embedded-a/corstone1000/user-guide.rst
diff --git a/docs/platform/arm/index.rst b/docs/platform/arm/index.rst
new file mode 100755
index 0000000..48a8223
--- /dev/null
+++ b/docs/platform/arm/index.rst
@@ -0,0 +1,18 @@
+#############
+Arm platforms
+#############
+
+.. toctree::
+ :maxdepth: 1
+
+ Corstone-1000 <corstone1000/readme.rst>
+ Corstone-300 FPGA (AN547) <mps3/an547/README.rst>
+ Corstone-300 FPGA and FVP (AN552) <mps3/an552/README.rst>
+ Corstone-310 FVP <mps3/corstone310_fvp/README.rst>
+ Musca-B1 <musca_b1/sse_200/readme.rst>
+ Musca-B1 Secure Enclave <musca_b1/secure_enclave/readme.rst>
+ Runtime Security Subsystem <rss/readme.rst>
+
+--------------
+
+*Copyright (c) 2022, Arm Limited. All rights reserved.*
diff --git a/docs/platform/arm/mps3/an547/README.rst b/docs/platform/arm/mps3/an547/README.rst
new file mode 100644
index 0000000..c2e7667
--- /dev/null
+++ b/docs/platform/arm/mps3/an547/README.rst
@@ -0,0 +1,113 @@
+Corstone SSE-300 with Ethos-U55 Example Subsystem for MPS3 (AN547)
+==================================================================
+
+Building TF-M
+-------------
+
+Follow the instructions in :doc:`Building instructions </building/tfm_build_instruction>`.
+Build instructions with platform name: arm/mps3/an547
+``-DTFM_PLATFORM=arm/mps3/an547``
+
+.. note::
+
+ This platform support does not provide software for Ethos-U55 IP, only
+ contains base address and interrupt number for it.
+
+.. note::
+
+ The built binaries can be run on the Corstone SSE-300 with Ethos-U55
+ Example Subsystem for MPS3 (AN547).
+ They can also be run on the Corstone-300 Ethos-U55 Ecosystem FVP
+ (FVP_SSE300_MPS3) up until version 11.15. From version 11.16, the FVP
+ is aligned with the AN552 FPGA platform. For build information check
+ :doc:`AN552 platform </platform/arm/mps3/an552/README>`.
+
+To run the example code on Corstone SSE-300 with Ethos-U55 Example Subsystem for MPS3 (AN547)
+---------------------------------------------------------------------------------------------
+FPGA image is available to download `here <https://developer.arm.com/tools-and-software/development-boards/fpga-prototyping-boards/download-fpga-images>`__
+
+To run BL2 bootloader and TF-M example application and tests in the MPS3 board,
+it is required to have AN547 image in the MPS3 board SD card. The image should
+be located in ``<MPS3 device name>/MB/HBI<BoardNumberBoardrevision>/AN547``
+
+The MPS3 board tested is HBI0309C.
+
+#. Copy ``bl2.bin`` and ``tfm_s_ns_signed.bin`` files from
+ build dir to ``<MPS3 device name>/SOFTWARE/``
+#. Rename ``tfm_s_ns_signed.bin`` to ``tfm.bin`` (Filename should not be longer
+ than 8 charachters.)
+#. Open ``<MPS3 device name>/MB/HBI0309C/AN547/images.txt``
+#. Update the ``images.txt`` file as follows::
+
+ TITLE: Arm MPS3 FPGA prototyping board Images Configuration File
+
+ [IMAGES]
+ TOTALIMAGES: 2 ;Number of Images (Max: 32)
+
+ IMAGE0UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
+ IMAGE0ADDRESS: 0x00000000 ;Please select the required executable program
+ IMAGE0FILE: \SOFTWARE\bl2.bin
+ IMAGE1UPDATE: AUTO
+ IMAGE1ADDRESS: 0x02000000
+ IMAGE1FILE: \SOFTWARE\tfm.bin
+
+#. Close ``<MPS3 device name>/MB/HBI0309C/AN547/images.txt``
+#. Unmount/eject the ``<MPS3 device name>`` unit
+#. Reset the board to execute the TF-M example application
+#. After completing the procedure you should be able to visualize on the serial
+ port (baud 115200 8n1) the following messages::
+
+ [INF] Starting bootloader
+ [INF] Swap type: none
+ [INF] Swap type: none
+ [INF] Bootloader chainload address offset: 0x0
+ [INF] Jumping to the first image slot
+ [Sec Thread] Secure image initializing!
+ Booting TFM v1.4.0
+ [Crypto] Dummy Entropy NV Seed is not suitable for production!
+ Non-Secure system starting...
+
+.. note::
+
+ Some of the messages above are only visible when ``CMAKE_BUILD_TYPE`` is set
+ to ``Debug``.
+
+To run the example code on Corstone-300 Ethos-U55 Ecosystem FVP
+---------------------------------------------------------------
+.. note::
+
+ The built binaries can be run on the Corstone-300 Ethos-U55 Ecosystem FVP
+ (FVP_SSE300_MPS3) up until version 11.15. This version is no longer
+ available to download.
+
+#. Install the FVP
+#. Copy ``bl2.axf`` and ``tfm_s_ns_signed.bin`` files from
+ build dir to ``<FVP installation path>/models/Linux64_GCC-6.4/``
+#. Navigate to the same directory and execute the following command to start FVP::
+
+ $ ./FVP_MPS3_Corstone_SSE-300 -a cpu0*="bl2.axf" --data "tfm_s_ns_signed.bin"@0x01000000
+
+#. After completing the procedure you should be able to visualize on the serial
+ port the following messages::
+
+ Trying 127.0.0.1...
+ Connected to localhost.
+ Escape character is '^]'.
+ [INF] Starting bootloader
+ [INF] Swap type: none
+ [INF] Swap type: none
+ [INF] Bootloader chainload address offset: 0x0
+ [INF] Jumping to the first image slot
+ [Sec Thread] Secure image initializing!
+ Booting TFM v1.4.0
+ [Crypto] Dummy Entropy NV Seed is not suitable for production!
+ Non-Secure system starting...
+
+.. note::
+
+ Some of the messages above are only visible when ``CMAKE_BUILD_TYPE`` is set
+ to ``Debug``.
+
+-------------
+
+*Copyright (c) 2020-2022, Arm Limited. All rights reserved.*
diff --git a/docs/platform/arm/mps3/an552/README.rst b/docs/platform/arm/mps3/an552/README.rst
new file mode 100644
index 0000000..080f887
--- /dev/null
+++ b/docs/platform/arm/mps3/an552/README.rst
@@ -0,0 +1,106 @@
+Corstone SSE-300 with Ethos-U55 Example Subsystem for MPS3 (AN552) and FVP
+==========================================================================
+
+Building TF-M
+-------------
+
+Follow the instructions in :doc:`Building instructions </building/tfm_build_instruction>`.
+Build instructions with platform name: arm/mps3/an552
+``-DTFM_PLATFORM=arm/mps3/an552``
+
+.. note::
+
+ This platform support does not provide software for Ethos-U55 IP, only
+ contains base address and interrupt number for it.
+
+.. note::
+
+ The built binaries can be run on both the Corstone-300 Ethos-U55 Ecosystem
+ FVP (FVP_SSE300_MPS3) and Corstone SSE-300 with Ethos-U55 Example Subsystem
+ for MPS3 (AN552). For the FVP, at least version 11.16 is required.
+
+To run the example code on AN552
+--------------------------------
+FPGA image is available to download `here <https://developer.arm.com/tools-and-software/development-boards/fpga-prototyping-boards/download-fpga-images>`__
+
+To run BL2 bootloader and TF-M example application and tests in the MPS3 board,
+it is required to have AN552 image in the MPS3 board SD card. The image should
+be located in ``<MPS3 device name>/MB/HBI<BoardNumberBoardrevision>/AN552``
+
+The MPS3 board tested is HBI0309C.
+
+#. Copy ``bl2.bin`` and ``tfm_s_ns_signed.bin`` files from
+ build dir to ``<MPS3 device name>/SOFTWARE/``
+#. Rename ``tfm_s_ns_signed.bin`` to ``tfm.bin`` (Filename should not be longer
+ than 8 charachters.)
+#. Open ``<MPS3 device name>/MB/HBI0309C/AN552/images.txt``
+#. Update the ``images.txt`` file as follows::
+
+ TITLE: Arm MPS3 FPGA prototyping board Images Configuration File
+
+ [IMAGES]
+ TOTALIMAGES: 2 ;Number of Images (Max: 32)
+
+ IMAGE0UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
+ IMAGE0ADDRESS: 0x00000000 ;Please select the required executable program
+ IMAGE0FILE: \SOFTWARE\bl2.bin
+ IMAGE1UPDATE: AUTO
+ IMAGE1ADDRESS: 0x02000000
+ IMAGE1FILE: \SOFTWARE\tfm.bin
+
+#. Close ``<MPS3 device name>/MB/HBI0309C/AN552/images.txt``
+#. Unmount/eject the ``<MPS3 device name>`` unit
+#. Reset the board to execute the TF-M example application
+#. After completing the procedure you should be able to visualize on the serial
+ port (baud 115200 8n1) the following messages::
+
+ [INF] Starting bootloader
+ [INF] Swap type: none
+ [INF] Swap type: none
+ [INF] Bootloader chainload address offset: 0x0
+ [INF] Jumping to the first image slot
+ [Sec Thread] Secure image initializing!
+ Booting TFM v1.4.0
+ [Crypto] Dummy Entropy NV Seed is not suitable for production!
+ Non-Secure system starting...
+
+.. note::
+
+ Some of the messages above are only visible when ``CMAKE_BUILD_TYPE`` is set
+ to ``Debug``.
+
+To run the example code on Corstone-300 Ethos-U55 Ecosystem FVP
+---------------------------------------------------------------
+FVP is available to download `here <https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps>`__
+
+#. Install the FVP
+#. Copy ``bl2.axf`` and ``tfm_s_ns_signed.bin`` files from
+ build dir to ``<FVP installation path>/models/Linux64_GCC-6.4/``
+#. Navigate to the same directory and execute the following command to start FVP::
+
+ $ ./FVP_Corstone_SSE-300_Ethos-U55 -a cpu0*="bl2.axf" --data "tfm_s_ns_signed.bin"@0x01000000
+
+#. After completing the procedure you should be able to visualize on the serial
+ port the following messages::
+
+ Trying 127.0.0.1...
+ Connected to localhost.
+ Escape character is '^]'.
+ [INF] Starting bootloader
+ [INF] Swap type: none
+ [INF] Swap type: none
+ [INF] Bootloader chainload address offset: 0x0
+ [INF] Jumping to the first image slot
+ [Sec Thread] Secure image initializing!
+ Booting TFM v1.4.0
+ [Crypto] Dummy Entropy NV Seed is not suitable for production!
+ Non-Secure system starting...
+
+.. note::
+
+ Some of the messages above are only visible when ``CMAKE_BUILD_TYPE`` is set
+ to ``Debug``.
+
+-------------
+
+*Copyright (c) 2020-2022, Arm Limited. All rights reserved.*
diff --git a/docs/platform/arm/mps3/corstone310_fvp/README.rst b/docs/platform/arm/mps3/corstone310_fvp/README.rst
new file mode 100644
index 0000000..7b9f268
--- /dev/null
+++ b/docs/platform/arm/mps3/corstone310_fvp/README.rst
@@ -0,0 +1,102 @@
+Corstone SSE-310 with Ethos-U55 Example Subsystem for Arm Virtual Hardware
+==========================================================================
+
+Introduction
+------------
+
+Corstone-310 (formerly Corstone-Polaris) is an Arm reference subsystem for
+secure System on Chips containing an Armv8.1-M Cortex-M85 processor and an
+Ethos-U55 neural network processor. It is an MPS3 based platform with the
+usual MPS3 peripherals.
+
+This platform port supports all TF-M regression tests (Secure and Non-secure)
+with Isolation Level 1 and 2.
+
+Building TF-M
+-------------
+
+Follow the instructions in :doc:`Building instructions </building/tfm_build_instruction>`.
+Build instructions with platform name: arm/mps3/corstone310_fvp
+
+``-DTFM_PLATFORM=arm/mps3/corstone310_fvp``
+
+.. note::
+
+ This platform support does not provide software for Ethos-U55 IP, only
+ contains base address and interrupt number for it.
+
+.. note::
+
+ The built binaries can be run on the Corstone-310 Arm Virtual Hardware
+ (VHT_Corstone_SSE-310). At least VHT version 11.17 is required.
+
+.. note::
+
+ For Armclang compiler v6.18 or later version is required.
+
+To run the example code on Corstone-310 Ethos-U55 Arm Virtual Hardware
+----------------------------------------------------------------------
+
+To utilize the `Arm Virtual Hardware (AVH) <https://arm-software.github.io/AVH/main/simulation/html/Using.html>`_, you will need to create an `AWS Account <https://aws.amazon.com/>`_ if you don’t already have one.
+
+Launching the instance in EC2 `(AWS on getting started) <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html>`_
+1. Go to `EC2 <https://console.aws.amazon.com/ec2/v2/>`_ in the AWS Web Console.
+2. Select **Launch Instances** which will take you to a wizard for launching the instance.
+
+ 1. **Choose an Amazon Machine Image** `(AMI) <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html>`_ In the Search box, type `Arm Virtual Hardware` then find the item called "Arm Virtual Hardware" that is by Arm, and press Select for that item.
+ This will raise a subscription page/pop-up titled, **Arm Virtual Hardware**. You will note that the subscription is free from Arm, but AWS does charge for the costs of the instances themselves according to the pricing chart provided.
+
+ You must select Continue if you want to move forward.
+
+ 2. **Choose an Instance Type** - Select one of the instance types from the list. Keep in mind that there are charges that accrue while the instance is running.
+ From here you may select **Review and Launch** to move directly to the launch page or select **Next: Configure Instance Details** if you need to set any custom settings for this instance.
+
+
+Once you complete the wizard by initiating the instance launch you will see a page that allows you to navigate directly to the new instance. You may click this link or go back to your list of instances and find the instance through that method.
+
+Whichever way you choose find your new instance and select its instance ID to open the page to manage the instance.
+
+Connecting to the instance:
+ 1. Select **Connect** to open an SSH terminal session to the instance in your browser.
+ 2. Ensure the **User name** field is set to `ubuntu`.
+ 3. Select the **Connect** button to open the session. This will put you in a browser window where you will have an SSH terminal window ready for your input.
+
+The TF-M can be cloned and built in the instance after connecting.
+To run the built binaries:
+
+#. Execute the following command to start VHT::
+
+ $ VHT_Corstone_SSE-310 -a cpu0*="<path-to-build-directory>/bl2.axf" --data "<path-to-build-directory>/tfm_s_ns_signed.bin"@0x01040000
+
+#. The serial port's output can be redirected to a file with::
+
+ $ VHT_Corstone_SSE-310 -a cpu0*="<path-to-build-directory>/bl2.axf" --data "<path-to-build-directory>/tfm_s_ns_signed.bin"@0x01040000 -C mps3_board.uart0.unbuffered_output=1 -C mps3_board.uart0.out_file="output.log"
+
+ The output should contain the following messages::
+
+ Trying 127.0.0.1...
+ Connected to localhost.
+ Escape character is '^]'.
+ [INF] Starting bootloader
+ [INF] Beginning BL2 provisioning
+ [INF] Swap type: none
+ [INF] Swap type: none
+ [INF] Bootloader chainload address offset: 0x40000
+ [INF] Jumping to the first image slot
+ [INF] Beginning TF-M provisioning
+ [Sec Thread] Secure image initializing!
+ TF-M isolation level is:0x00000001
+ Booting TF-M v1.6.0
+ Creating an empty ITS flash layout.
+ Creating an empty PS flash layout.
+ Non-Secure system starting...
+
+
+.. note::
+
+ Some of the messages above are only visible when ``CMAKE_BUILD_TYPE`` is set
+ to ``Debug``.
+
+-------------
+
+*Copyright (c) 2021-2022, Arm Limited. All rights reserved.*
diff --git a/docs/platform/arm/musca_b1/secure_enclave/readme.rst b/docs/platform/arm/musca_b1/secure_enclave/readme.rst
new file mode 100644
index 0000000..4598db3
--- /dev/null
+++ b/docs/platform/arm/musca_b1/secure_enclave/readme.rst
@@ -0,0 +1,106 @@
+#################################
+Musca-B1 Secure Enclave Specifics
+#################################
+
+************
+Introduction
+************
+
+The Musca-B1 System-on-Chip contains two subsystems:
+
+- SSE-200 subsystem to host the main application.
+- CryptoIsland-300 subsystem can be used as a Secure Enclave (mentioned as *SE*
+ in the document).
+
+If TF-M is built with default configuration to the MUSCA-B1 platform only the
+SSE-200 subsystem used. But if the ``FORWARD_PROT_MSG`` cmake flag is turned
+on, the TF-M instance running on SSE-200 will communicate with the SE.
+
+For more information you can check the
+:doc:`Secure Enclave design document </technical_references/design_docs/secure_enclave_solution>`.
+
+***********
+System boot
+***********
+
+The desired boot flow would be to start up SE first at power on as SE is the
+Root of Trust in the system, and SSE-200 should be started up by SE. But the
+current Musca-B1 DAPLink FW releases the SSE-200 subsystem from reset first,
+and it would require complex changes to modify this boot order. So an
+additional SSE-200 BL0 component was added to the system to imitate that SE is
+the subsystem started up first.
+
+.. uml::
+
+ @startuml
+
+ title Implemented boot flow
+
+ start
+ :Power On button pressed.;
+ :DAPLink Starts up SSE-200.;
+ :SSE-200 BL0 starts up the SE (through SCC), then enters wait state.;
+ :SE starts to run its MCUBoot image and authenticates all images (SE TF-M
+ image and the combined SSE-200 image). If all images are valid, control jumps
+ to SE’s TF-M image.;
+ :SE's TF-M image starts up, when initialization finishes, SSE-200 is
+ virtually released from reset by sending the start address of the combined
+ SSE-200 image over MHU;
+ :SSE-200 TF-M image starts up and synchronizes with SE over MHU;
+ :SSE-200 and SE are ready to communicate;
+ stop
+
+ @enduml
+
+.. Note::
+
+ Without the SSE-200 BL0 component, the boot flow can be treated as a valid
+ reference solution.
+
+*****
+Build
+*****
+
+To produce all the images, TF-M build needs to be executed twice:
+
+- One build needed to create the SSE-200 images (BL0 and the combined SSE-200
+ image containing TF-M and the non-secure application), target platform needs
+ to be set to ``arm/musca_b1/sse_200`` and the ``FORWARD_PROT_MSG`` cmake flag
+ also
+ needs to be set.
+- One build needed to create the SE images (MCUBoot and TF-M), target platform
+ needs to be set to ``arm/musca_b1/secure_enclave``.
+
+The order of the two builds is indifferent. The BL2 setting is mandatory for
+both builds, but MCUBoot image is only built for the SE platform. The cmake
+setup for the two builds must have the same debug profile (eg. debug, release).
+
+To create a unified hex file:
+
+- Windows::
+
+ srec_cat.exe <SE build dir>\bin\bl2.bin -Binary -offset 0x1A020000 ^
+ <SE build dir>\bin\tfm_s_signed.bin -Binary -offset 0x1A200000 ^
+ <SSE-200 build dir>\bin\bl0.bin -Binary -offset 0x1A000000 ^
+ <SSE-200 build dir>\bin\tfm_s_ns_signed.bin -Binary -offset 0x1A260000 ^
+ -o tfm_sse200_w_se.hex -Intel
+
+- Linux::
+
+ srec_cat <SE build dir>/bin/bl2.bin -Binary -offset 0x1A020000 \
+ <SE build dir>/bin/tfm_s_signed.bin -Binary -offset 0x1A200000 \
+ <SSE-200 build dir>/bin/bl0.bin -Binary -offset 0x1A000000 \
+ <SSE-200 build dir>/bin/tfm_s_ns_signed.bin -Binary -offset 0x1A260000 \
+ -o tfm_sse200_w_se.hex -Intel
+
+*****************
+Known limitations
+*****************
+- Musca-B1 Secure Enclave cannot reset the whole SoC, only itself. So if SE
+ does a system reset it will stuck in a state waiting for a handshake signal
+ from SSE-200. (It will never come, as SSE-200 is not reseted in such a
+ situation.)
+
+--------------
+
+*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/docs/platform/arm/musca_b1/sse_200/readme.rst b/docs/platform/arm/musca_b1/sse_200/readme.rst
new file mode 100644
index 0000000..e81b96e
--- /dev/null
+++ b/docs/platform/arm/musca_b1/sse_200/readme.rst
@@ -0,0 +1,30 @@
+###########################
+Musca-B1 Platform Specifics
+###########################
+
+****************
+DAPLink Firmware
+****************
+The code on Musca-B1 is running from embededed flash. Make sure that the DAPLink
+FW for eFlash is downloaded to the board. You can find on the
+`Arm Community page <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/425/musca-b1-firmware-update-qspi-boot-recovery>`__
+A short description of how to update the DAPLink FW can be found there as well.
+
+.. Note::
+ Warm reset of eFlash is not supported on Musca_B1. TF-M may not boot after
+ a warm reset. Further information on the hardware limitation can be
+ found on `Arm Community page <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/426/musca-b1-warm-reset-of-eflash>`__.
+
+********************
+Platform pin service
+********************
+
+This service is designed to perform secure pin services of the platform
+(e.g alternate function setting, pin mode setting, etc).
+The service uses the IOCTL API of TF-M's Platform Service, which allows the
+non-secure application to make pin service requests on Musca B1 based on a
+generic service request delivery mechanism.
+
+--------------
+
+*Copyright (c) 2017-2020, Arm Limited. All rights reserved.*
diff --git a/docs/platform/arm/rss/readme.rst b/docs/platform/arm/rss/readme.rst
new file mode 100644
index 0000000..413f135
--- /dev/null
+++ b/docs/platform/arm/rss/readme.rst
@@ -0,0 +1,104 @@
+Runtime Security Subsystem (RSS)
+================================
+
+Introduction
+------------
+
+Runtime Security Subsystem (RSS) is an Arm subsystem that provides a reference
+implementation of the HES Host in the
+`Arm Confidential Compute Architecture (CCA) <https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture>`_.
+It is designed to be integrated into A-profile compute subsystems that implement
+Arm CCA, where it serves as the Root of Trust.
+
+RSS initially boots from immutable code (BL1_1) in its internal ROM, before
+jumping to BL1_2, which is provisioned and hash-locked in RSS OTP. The updatable
+MCUBoot BL2 boot stage is loaded from host system flash into RSS SRAM, where it
+is authenticated. BL2 loads and authenticates the TF-M runtime into RSS SRAM
+from host flash. BL2 is also responsible for loading initial boot code into
+other subsystems within the host.
+
+This platform port currently supports all TF-M regression tests (Secure and
+Non-secure) using the IPC model with Isolation Level 1 and 2.
+
+Building TF-M
+-------------
+
+Follow the instructions in :doc:`Build instructions </building/tfm_build_instruction>`.
+Build TF-M with platform name: `arm/rss`
+
+``-DTFM_PLATFORM=arm/rss``
+
+Signing host images
+-------------------
+
+RSS BL2 can load boot images into other subsystems within the host system. It
+expects images to be signed, with the signatures attached to the images in the
+MCUBoot metadata format.
+
+The `imgtool Python package <https://pypi.org/project/imgtool/>`_ can be used to
+sign images in the required format. To sign a host image using the development
+key distributed with TF-M, use the following command::
+
+ imgtool sign \
+ -k <TF-M base directory>/bl2/ext/mcuboot/root-RSA-3072.pem \
+ --public-key-format full \
+ --max-align 8 \
+ --align 1 \
+ -v "0.0.1" \
+ -s 1 \
+ -H 0x1000 \
+ --pad-header \
+ -S 0x80000 \
+ --pad \
+ --boot-record "HOST" \
+ -L <load address> \
+ <binary infile> \
+ <signed binary outfile>
+
+The ``load address`` is the address to which BL2 will load the image. The RSS
+ATU should be configured to map this logical address to the physical address in
+the host system that the image needs to be loaded to.
+
+For more information on the ``imgtool`` parameters, see the MCUBoot
+`imgtool documentation <https://docs.mcuboot.com/imgtool.html>`_.
+
+.. warning::
+
+ The TF-M development key must never be used in production. To generate a
+ production key, follow the imgtool documentation.
+
+Running the code
+----------------
+
+To run the built images, they need to be concatenated into binaries that can be
+placed in ROM and flash. To do this, navigate to the TF-M build directory and
+run the following ``srec_cat`` commands::
+
+ srec_cat \
+ bl1_1.bin -Binary -offset 0x0 \
+ bl1_provisioning_bundle.bin -Binary -offset 0xE000 \
+ -o rom.bin -Binary
+
+ srec_cat \
+ bl2_signed.bin -Binary -offset 0x0 \
+ bl2_signed.bin -Binary -offset 0x20000 \
+ tfm_s_ns_signed.bin -Binary -offset 0x40000 \
+ tfm_s_ns_signed.bin -Binary -offset 0x140000 \
+ <Host AP BL1 image> -Binary -offset 0x240000 \
+ <SCP BL1 image> -Binary -offset 0x2C0000 \
+ <Host AP BL1 image> -Binary -offset 0x340000 \
+ <SCP BL1 image> -Binary -offset 0x3C0000 \
+ -o flash.bin -Binary
+
+For development purposes, the OTP image is included as a provisioning bundle in
+the ROM image and provisioned into OTP by BL1_1. The flash image should include
+the signed host images from the previous section. For each boot image, there is
+a primary and secondary image; if these are different then BL2 will load the one
+with the higher version number.
+
+The ROM binary should be placed in RSS ROM at ``0x11000000`` and the flash
+binary should be placed at ``0x31000000``.
+
+--------------
+
+*Copyright (c) 2022, Arm Limited. All rights reserved.*
