Docs: Add RSS platform documentation
Change-Id: I2aa051f592f6a65114c073cdf0584cf36c9266f2
Signed-off-by: Jamie Fox <jamie.fox@arm.com>
diff --git a/docs/platform/ext/platform_introduction.rst b/docs/platform/ext/platform_introduction.rst
index ae03d62..2d2eb68 100644
--- a/docs/platform/ext/platform_introduction.rst
+++ b/docs/platform/ext/platform_introduction.rst
@@ -62,5 +62,9 @@
- :doc:`Musca-B1 Secure Enclave. </platform/ext/target/arm/musca_b1/secure_enclave/readme>`
+ - Runtime Security Subsystem (RSS):
+
+ - :doc:`RSS. </platform/ext/target/arm/rss/readme>`
+
The document :doc:`Platform Deprecation and Removal </platform/ext/platform_deprecation>`
lists the deprecated platforms planned to be removed from upstream.
diff --git a/docs/platform/ext/target/arm/index.rst b/docs/platform/ext/target/arm/index.rst
index 3e71053..866d6df 100755
--- a/docs/platform/ext/target/arm/index.rst
+++ b/docs/platform/ext/target/arm/index.rst
@@ -8,6 +8,7 @@
corstone1000/index
mps3/**
musca_b1/**
+ rss/**
--------------
diff --git a/docs/platform/ext/target/arm/rss/readme.rst b/docs/platform/ext/target/arm/rss/readme.rst
new file mode 100644
index 0000000..107d7af
--- /dev/null
+++ b/docs/platform/ext/target/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 </technical_references/instructions/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.*
diff --git a/docs/technical_references/design_docs/tfm_secure_boot.rst b/docs/technical_references/design_docs/tfm_secure_boot.rst
index 675cd31..9b7c1e2 100644
--- a/docs/technical_references/design_docs/tfm_secure_boot.rst
+++ b/docs/technical_references/design_docs/tfm_secure_boot.rst
@@ -256,6 +256,8 @@
+---------------------+-----------------+---------------+----------+----------------+--------------+
| BL5340 DVK | Yes | Yes | Yes | No | No |
+---------------------+-----------------+---------------+----------+----------------+--------------+
+| RSS | No | No | No | No | Yes |
++---------------------+-----------------+---------------+----------+----------------+--------------+
.. [1] To disable BL2, please set the ``BL2`` cmake option to ``OFF``