doc: Updated H20 arch docs

Updated H20 arch docs.
Updated references to SDFW in 54H docs

Signed-off-by: Francesco Domenico Servidio <[email protected]>

Author: FrancescoSer

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_boot.rst

@@ -1,6 +1,6 @@
 .. _ug_nrf54h20_architecture_boot:
 
-nRF54H20 Boot Sequence
+nRF54H20 boot sequence
 ######################
 
 .. contents::
@@ -28,14 +28,14 @@ If the system was active and entered the Soft Off sleep state, the system perfor
 
 During cold boot the system has no (or little application-defined) state retained in its RAM memory or hardware registers and performs full initialization.
 
-Cold Boot Sequence
+Cold boot features
 ******************
 
 The nRF54H20 boot sequence has two key features:
 
 * An immutable boot ROM provides the initial :term:`Root of Trust (RoT)`.
-  This boot ROM is responsible for verifying the secure domain firmware signature before allowing the code to be executed.
-* The secure domain acts as the boot master in the system.
+  This boot ROM is responsible for verifying the IronSide Secure Element (IronSide SE) signature before allowing the code to be executed.
+* The Secure Domain acts as the boot master in the system.
   It completes the allocation of all the global resources before any other local domain is allowed to execute.
   This order of operation is needed for robustness and security of the system.
   It ensures that global resources are allocated for other local domains before any of them has opportunity to access global resources (correct access to allocated resources, or tries of malicious access to resources owned by other domains).
@@ -59,20 +59,19 @@ See the following overview of the boot sequence, where the left-most block indic
 
 The following is a description of the boot sequence steps:
 
-1. Immediately after reset, the SysCtrl CPU starts executing code from a ROM memory in Global Domain.
-   This ROM code perform chip calibration, like trim and power-up the MRAM macro.
-   This ROM code does not affect the runtime services offered by SysCtrl firmware during the secondary boot stage.
+1. Immediately after reset, the SysCtrl CPU starts executing code from the ROM memory in the global domain.
+   This code performs essential chip-calibration tasks, such as trimming and powering up the MRAM macro, without affecting the runtime services provided by the SysCtrl firmware during the secondary boot stage.
 
-#. The SysCtrl ROM powers up the secure domain and then halts.
+#. The SysCtrl ROM powers up the Secure Domain and then halts.
 
-#. The secure domain is taken out of reset (as the first local domain), and the Cortex-M33 CPU inside the secure domain automatically starts executing code from a local ROM memory.
-   As the MRAM is now calibrated and working correctly, the secure domain ROM can perform signature verification of the secure domain firmware components installed into the MRAM.
-   The secure domain ROM also configures the device according to the current life-cycle state (LCS) and extracts silicon-unique fingerprints from the physical unclonable function (PUF) in GD , retaining this inside CRACEN.
+#. The Secure Domain is taken out of reset (as the first local domain), and the Cortex-M33 CPU inside the Secure Domain automatically starts executing code from a local ROM memory.
+   As the MRAM is now calibrated and working correctly, the Secure Domain ROM can perform signature verification of the IronSide SE components installed into the MRAM.
+   The Secure Domain ROM also configures the device according to the current life-cycle state (LCS) and extracts silicon-unique fingerprints from the physical unclonable function (PUF) in GD , retaining this inside CRACEN.
 
-#. If the secure domain firmware signature is valid, the secure domain ROM reconfigures ROM memory as non-executable and non-readable and then branches into the firmware stored in MRAM.
+#. If IronSide SE signature is valid, the Secure Domain ROM reconfigures ROM memory as non-executable and non-readable and then branches into the firmware stored in MRAM.
    This is the first step of the primary boot stage where a user-installable firmware component is executed by any CPU in the system.
 
-#. At the end of the primary boot stage, the secure domain firmware configures and restricts access to all global resources, and initiates the secondary boot stage.
+#. At the end of the primary boot stage, IronSide SE configures and restricts access to all global resources, and initiates the secondary boot stage.
 
 #. In the secondary boot stage, SysCtrl and other local domains are released from reset and in parallel start to execute their respective MRAM firmware components.
 

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_clockman.rst

@@ -130,7 +130,7 @@ In such cases, developers must:
 
 1. Initialize the IPC backend.
 
-   GDFS relies on Interprocessor Communication (IPC) to exchange configuration requests and responses between the application core and the System Controller firmware (SCFW).
+   GDFS relies on :ref:`interprocessor communication (IPC) <ug_nrf54h20_architecture_ipc>` to exchange configuration requests and responses between the application core and the System Controller Firmware (SCFW) component of the IronSide Secure Element (IronSide SE).
    Before invoking GDFS functions, the application must properly initialize the underlying IPC backend.
 
 #. Initialize GDFS and configure handlers.

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_cpu.rst

@@ -1,6 +1,6 @@
 .. _ug_nrf54h20_architecture_cpu:
 
-nRF54H20 Domains
+nRF54H20 domains
 ################
 
 .. contents::
@@ -93,14 +93,14 @@ You can also leave the core running Nordic's default protocol stack software and
 
 While the Radio CPU or any peripheral in Radio's local APB2 bus (including the radio) is active, the 32 MHz crystal oscillator is enabled, and the radio itself is clocked from this clock source.
 
-Global Domain
+Global domain
 *************
 
-The Global Domain contains most of the memory and peripherals of the nRF54H20.
+The global domain contains most of the memory and peripherals of the nRF54H20.
 This offers flexibility to assign memory regions and peripherals to different cores.
 If this flexibility is not needed, it is possible to use the |NCS| defaults, where most of the memory and peripherals are assigned to the application core.
 
-The Global Domain includes two sets of power domains:
+The global domain includes two sets of power domains:
 
 * The low-leakage power domains runs at a clock speed of 16 MHz and contains the peripherals that do not need a higher clock speed than this.
 * The high-speed power domains contains the main memories (MRAM and RAM) and high-speed peripherals that have clock speeds higher than 16 MHz.
@@ -121,14 +121,15 @@ This processor is suitable for the following use cases:
 It has been optimized for using very few clock cycles to service interrupts and can start and stop quickly.
 Since the PPR is running from the same clock as the low-leakage peripherals, it does not need to implement any wait cycles to access peripheral registers.
 
+For information on how to use the PPR, see :ref:`ug_nrf54h20_ppr`.
+
 Fast Lightweight Processor (FLPR)
 =================================
 
 The Fast Lightweight Processor (FLPR, pronounced Flipper) is a VPR core running at up to 320 MHz, located in the high-speed area of the Global Domain.
 This CPU is intended to implement software-defined peripherals.
 
-.. note::
-   FLPR firmware support is not available during the customer sampling.
+For information on how to use the FLPR, see :ref:`ug_nrf54h20_flpr`.
 
 .. _ug_nrf54h20_secure_domain:
 
@@ -142,7 +143,10 @@ The Secure Domain has its own CPU, local RAM, and local peripherals to provide b
 The Secure Domain provides the initial root of trust (RoT), handles all the global resource allocation, acts as a trusted third party (TTP) between other MCU domains, and is used to secure cryptographic operations.
 Since the nRF54H platform supports global resource sharing, where memory partitions and peripherals in the global domain can be assigned to different local domains, the Secure Domain Firmware controls this partitioning while also acting as the boot master for the entire system.
 
-The Secure Domain Firmware (SDFW) exposes security-related services to the Cores in the system located in local domains (like Application and Radio).
+IronSide Secure Element (IronSide SE) is part of the nRF54H20 SoC binaries.
+It runs on the Secure Domain and exposes security-related services to the Cores in the system located in local domains (like Application and Radio).
+
+For more information on IronSide SE and the nRF54H20 SoC binaries, see :ref:`abi_compatibility` and :ref:`ug_nrf54h20_ironside`.
 
 .. _ug_nrf54h20_secure_domain_cracen:
 
@@ -168,6 +172,10 @@ System Controller
 *****************
 
 System Controller is a VPR that implements system startup and power management functionalities that in the past would have been implemented in hardware.
+The System Controller Firmware (SCFW) is a component of the IronSide Secure Element (IronSide SE), and it is included in the nRF54H20 SoC binaries.
+
+For more information on the nRF54H20 SoC binaries, see :ref:`abi_compatibility`.
+
 
 Cores management
 ****************

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_ipc.rst

@@ -1,6 +1,6 @@
 .. _ug_nrf54h20_architecture_ipc:
 
-Interprocessor Communication in nRF54H20
+Interprocessor communication in nRF54H20
 ########################################
 
 .. contents::
@@ -11,7 +11,7 @@ Interprocessor communication (IPC) is the communication between different CPUs (
 The nRF54H20 includes several types of CPUs that are optimized for different types of workloads.
 This provides an asymmetric multiprocessing environment where you can freely select the CPU that is best suited to the workloads that compose your application.
 
-Interprocessor Communication is required in asymmetric multiprocessing environments to share services' requests, responses, and data between processors.
+Interprocessor communication is required in asymmetric multiprocessing environments to share services' requests, responses, and data between processors.
 
 The following sections describe the communication protocol used for IPC in |NCS| for the nRF54H20 SoC.
 They also include an overview of the connection scheme between the cores available in the system.
@@ -99,10 +99,10 @@ The following tables show signals received only by specified cores.
 
 Some of the channels in BELLBOARDs and VEVIFs are reserved for functions different from IPC.
 
-MAC, Network, Transport
+MAC, network, transport
 =======================
 
-The layers responsible for maintaining a stable full-duplex stream of data between two cores (MAC, Network, Transport) are implemented in an IPC transport library.
+The layers responsible for maintaining a stable full-duplex stream of data between two cores (MAC, network, transport) are implemented in an IPC transport library.
 The default IPC transport library for nRF54H20 is :ref:`ICMsg <zephyr:ipc_service_backend_icmsg>`.
 This lightweight library maintains the connection between a pair of cores for each IPC instance with minimal memory overhead.
 Each IPC instance between the application core and the PPR core requires an instance of the ICMsg library.
@@ -140,7 +140,7 @@ It is recommended to use the ipc_service API to perform inter-processor communic
 
 For more information, consult the :ref:`IPC service <zephyr:ipc_service>` library documentation.
 
-Presentation and Application layers
+Presentation and application layers
 ===================================
 
 The presentation and application layers are connection specific.
@@ -182,10 +182,10 @@ These services are hidden behind Zephyr APIs available in the application core,
 All services can be enabled simultaneously using separated endpoints in a shared IPC instance.
 You can implement other services running in the radio core and expose them to the application core using more endpoints from the shared IPC instance.
 
-Secure Domain core
-==================
+Secure Domain
+=============
 
-The Secure Domain core exposes security-related services to the other local cores in the system (Application, Radio).
+The Secure Domain exposes security-related services to the other local cores in the system (application, radio).
 The list of services also includes:
 
    * Key management

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_lifecycle.rst

@@ -1,23 +1,15 @@
 .. _ug_nrf54h20_architecture_lifecycle:
 
-nRF54H20 lifecycle states
-#########################
+nRF54H20 SoC lifecycle states
+#############################
 
 .. contents::
    :local:
    :depth: 2
 
-The Secure Domain ROM firmware defines the lifecycle states (LCS) for the nRF54H20 SoC.
+The Secure Domain ROM defines the lifecycle states (LCS) for the nRF54H20 SoC.
 The states are based on the Arm PSA Security Model and allow for programming and safely erasing the device assets.
 
-.. note::
-    During the customer sampling, the LCS of the nRF54H20 SoC must be set to Root of Trust (RoT).
-    If the LCS is set to ``EMPTY``, it must be transitioned to ``RoT``.
-    For more information, see :ref:`ug_nrf54h20_gs_bringup`.
-
-    However, the forward transition to LCS ``RoT`` is permanent.
-    After the transition, it is not possible to transition backward to LCS ``EMPTY``.
-
 The LCS available are the following:
 
 .. list-table:: nRF54H20 lifecycle states
@@ -49,12 +41,18 @@ See the following diagram:
 .. figure:: images/nRF54H20_lifecycle_states.svg
    :alt: nRF54H20 lifecycle states and transitions
 
-   nRF54H20 lifecycle states and transitions available on the final silicon.
+   nRF54H20 lifecycle states and transitions available on the nRF54H20 SoC.
+
+You can change the SoC lifecycle state to streamline development and testing:
+
+* During application development, set the SoC to the ``Root of Trust`` (RoT) state.
+* To validate behavior in a production environment, use the ``DEPLOYED`` state.
+
 
-This figure shows the states and transitions (both forward and backward ones) that will be available on the final silicon.
+If the device is in LCS ``EMPTY``, transition it to LCS ``RoT`` by following the :ref:`nRF54H20 DK bring-up <ug_nrf54h20_gs_bringup>` procedure.
 
-Changing the lifecycle state will be useful during development.
-Test devices in their final configuration would require the device to be in the deployed state, however, updating the Secure Domain firmware and the System Controller firmware will be easier with the device in RoT state.
+.. caution::
+   The transition from ``EMPTY`` to ``RoT`` is permanent and cannot be reversed.
 
 For more information, see the following pages:
 

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_memory.rst

@@ -1,6 +1,6 @@
 .. _ug_nrf54h20_architecture_memory:
 
-nRF54H20 Memory Layout
+nRF54H20 memory layout
 ######################
 
 .. contents::
@@ -24,9 +24,6 @@ When classifying memories by CPU association, the nRF54H20 contains the followin
 The MRAM is a global memory available to all CPUs in the system.
 Some RAM memories are, instead, tightly coupled to a specific CPU, while others are intended to be shared between multiple CPUs.
 
-.. note::
-   In the nRF54H20 initial limited sampling, TrustZone is disabled on all cores.
-
 RAM
 ***
 

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_reset.rst

@@ -54,7 +54,7 @@ The following is the reset behavior when the LCS of the nRF54H20 SoC is either i
    * - ``RESET_PIN``
      - J-Link toggles the **RESET** pin using OBD.
    * - ``RESET_VIA_SECDOM``
-     - Uses the CTRL-AP mailbox to send a local domain reset request to the Secure Domain Firmware (SDFW).
+     - Uses the CTRL-AP mailbox to send a local domain reset request to the IronSide Secure Element (IronSide SE).
 
        This command resets the entire system while keeping both the application core and the radio core in a halted state.
 
@@ -73,7 +73,7 @@ Reset your device using nRF Util
 
 To trigger a specific reset type on your nRF54H20 SoC-based device, use the ``nrfutil device reset`` command::
 
-   nrfutil device reset --serial-number <blah> --reset-kind <reset-kind>
+   nrfutil device reset --serial-number <serial_number> --reset-kind <reset_kind>
 
 For a detailed list of commands for each reset type, run the following::
 

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_logging.rst

@@ -63,7 +63,7 @@ The standalone logging mode with STM on the nRF54H20 SoC works as follows:
 #. The STMESP generates a data stream based on the register writes.
 #. The STM multiplexes the data stream with streams from other domains, and it places them in the single memory buffer provided by the ETR.
 #. The application core, acting as the ETR-designated proxy, reads the buffer and decodes the raw encoded log data.
-#. The SDFW outputs the logging data in a human-readable format over UART.
+#. The IronSide Secure Element (IronSide SE) outputs the logging data in a human-readable format over UART.
 
 Standalone logging leverages the frontend API of the Zephyr logging subsystem to select the stimulus ports and writes log messages directly to memory-mapped registers.
 This method bypasses the need for string formatting functions and peripheral drivers, as the core writes directly to the STM port.