diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_sdfw_sdrfw_update_flow.png b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_sdfw_sdrfw_update_flow.png new file mode 100644 index 000000000000..3cfad6797e7e Binary files /dev/null and b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/images/nrf54h20_suit_sdfw_sdrfw_update_flow.png differ diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_components.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_components.rst index 720250b07c0a..d9f5eebac1d6 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_components.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_components.rst @@ -12,6 +12,8 @@ Using and modifying the component types allows for operational, fine-tuned custo See the :ref:`component_ID` section for more information. +.. _suit_component_types: + Component types *************** diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_dfu.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_dfu.rst index 5601cb5e2ee1..32a229f48bf5 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_dfu.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_dfu.rst @@ -34,3 +34,4 @@ For a list of available SUIT samples, see the :ref:`suit_samples` page. ug_nrf54h20_suit_hierarchical_manifests ug_nrf54h20_suit_soc_binaries ug_nrf54h20_suit_recovery.rst + ug_nrf54h20_suit_sdfw_sdrfw_update.rst diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_hierarchical_manifests.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_hierarchical_manifests.rst index d7913a70d1d0..38c71e267fa4 100644 --- a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_hierarchical_manifests.rst +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_hierarchical_manifests.rst @@ -29,6 +29,8 @@ Manifest are organized in a hierarchy-tree structure consisting of a single root Hierarchical manifest topology +.. _suit_default_manifest_topology_for_the_nrf54h20_soc: + Default manifest topology for the nRF54H20 SoC ********************************************** diff --git a/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_sdfw_sdrfw_update.rst b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_sdfw_sdrfw_update.rst new file mode 100644 index 000000000000..6438565b8359 --- /dev/null +++ b/doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_sdfw_sdrfw_update.rst @@ -0,0 +1,50 @@ +.. _ug_nrf54h20_suit_sdfw_sdrfw_update: + +Secure Domain Firmware Update +############################# + +.. contents:: + :local: + :depth: 2 + + +Both the Secure Domain Firmware (SDFW) and the recovery image for the Secure Domain Firmware are launched on a core responsible for establishing the Root of Trust as a Secure Domain. +Due to security requirements, the update process for these binaries differs significantly from regular updates in local domains. + +To ensure that trusted execution can be established on the device, a valid recovery image for the Secure Domain Firmware must be present on the device before performing a Secure Domain Firmware update. +An update is initiated only if the update candidate is verified by the Secure Domain ROM using a key that matches the requested update type. + +The SUIT framework allows flexible firmware launching and updating while keeping parts of the codebase unmodifiable by end users. +A common approach is to use a platform-specific layer that maps firmware blocks to device memory ranges, simplifying updates for basic systems. +Manifests can describe actions required to launch or update each firmware block. +In the nRF54H20, this approach is used in some areas, but the SDFW and the recovery image of the SDFW require the Secure Domain ROM to handle launching and updates, rather than direct copying to a destination address. + + +Implementation +************** + +SUIT manifests use components to define executable or updatable entities. +On a given platform, components may have different characteristics that require varied approaches for launching or updating (for example, execution in place instead of copying to RAM). + +As described in :ref:`suit_component_types`, a special SUIT component type (``SOC_SPEC``) describes components that are controlled by Nordic Semiconductor. + +For the nRF54H20 SoC, there are two components of this type: one for the SDFW and the other for the SDFW recovery image. +These are identified by component IDs 1 and 2, respectively: + +* ``SOC_SPEC/1`` - Secure Domain Firmware +* ``SOC_SPEC/2`` - Secure Domain Firmware recovery image + +As shown in :ref:`suit_default_manifest_topology_for_the_nrf54h20_soc`, both components are included in a single SUIT manifest. +This manifest is managed by the ``Nordic top`` manifest, which is, in turn, controlled by the ``Root`` manifest. + +Update process +************** + +The update process begins by attempting to update the Secure Domain Firmware (SDFW) recovery image. +If this update fails, the process still proceeds with updating the SDFW. +To prevent ambiguity if one slot update fails while the other succeeds, the manifest version reflects the version of the Secure Domain Firmware. + +.. figure:: images/nrf54h20_suit_sdfw_sdrfw_update_flow.png + :alt: Secure Domain Firmware and Secure Domain Firmware Recovery update flow + + Update flow for the Secure Domain Firmware and the Secure Domain Firmware recovery image