doc: Updated 54h index page

FrancescoSer · rlubos · commit 3d1868716f30 · 2026-02-18T10:05:19.000+01:00
Updated 54h index page to clarify structure.
Updated various 54H doc pages to improve
clarity and consistency.

Signed-off-by: Francesco Domenico Servidio &lt;francesco.servidio@nordicsemi.no&gt;
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/images/nRF54H20_domains.svg b/doc/nrf/app_dev/device_guides/nrf54h/images/nRF54H20_domains.svg
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/index.rst b/doc/nrf/app_dev/device_guides/nrf54h/index.rst
@@ -3,10 +3,6 @@
 Developing with nRF54H Series
 #############################
 
-.. note::
-
-   All software for the nRF54H20 SoC is experimental, and hardware availability is restricted to the participants in the customer sampling program.
-
 .. |nrf_series| replace:: devices of the nRF54H Series
 
 .. include:: /includes/guides_complementary_to_app_dev.txt
@@ -30,23 +26,52 @@ Zephyr and the |NCS| provide support and contain board definitions for developin
 
 .. toctree::
    :maxdepth: 2
-   :caption: Subpages:
+   :caption: Get started with the nRF54H20 DK
 
    ug_nrf54h20_gs
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Understand the hardware
+
    ug_nrf54h20_architecture
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Configure the nRF54H20 SoC on your custom PCB
+
+   ug_nrf54h20_custom_pcb
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Develop and debug
+
    ug_nrf54h20_configuration
-   ug_nrf54h20_keys
    ug_nrf54h20_logging
    ug_nrf54h20_debugging
-   ug_nrf54h20_custom_pcb
-   ug_nrf54h20_ironside
    ug_nrf54h20_flpr
    ug_nrf54h20_ppr
    ug_nrf54h20_zms
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Secure your application
+
+   ug_nrf54h20_ironside
+   ug_nrf54h20_keys
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Configure bootloader for Device Firmware Update (DFU)
+
    ug_nrf54h20_mcuboot_dfu
    ug_nrf54h20_partitioning_merged
    ug_nrf54h20_mcuboot_manifest
    ug_nrf54h20_mcuboot_requests
    ug_nrf54h_ecies_x25519
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Optimize the power management of your application
+
    ug_nrf54h20_pm_optimization
-   ug_nrf54h20_architecture_pinmap
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture.rst
@@ -24,3 +24,4 @@ The following pages briefly describe topics like the responsibilities of the cor
    ug_nrf54h20_architecture_pm
    ug_nrf54h20_architecture_clockman
    ug_nrf54h20_architecture_reset
+   ug_nrf54h20_architecture_pinmap
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_boot.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_boot.rst
@@ -76,7 +76,7 @@ The following is a description of the boot sequence steps:
 #. Each of the local domains is responsible to configure its local resources partitioning.
 
 .. note::
-   To better understand the boot process and how the |ISE| works, it is strongly suggested to read the entire :ref:`ug_nrf54h20_ironside` documentation page.
+   Read the entire :ref:`ug_nrf54h20_ironside` documentation page to better understand the boot process and how the |ISE| works.
 
 Boot sequence with MCUboot
 ==========================
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_clockman.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_clockman.rst
@@ -107,7 +107,7 @@ Global HSFLL
 ============
 
 The firmware can request this clock to run at a lower frequency than its default of 320 MHz.
-It is recommended to leave this clock at its default frequency.
+Leave this clock at its default frequency.
 Note the following if the frequency is lowered:
 
 * The MRAM access latency will be increased, thus lowering overall CPU performance when running code from MRAM.
@@ -123,7 +123,7 @@ Local HSFLL
 ===========
 
 The firmware can request this clock to run at a lower frequency than its default.
-It is recommended to leave this clock at its default frequency.
+Leave this clock at its default frequency.
 If the frequency is lowered, the CPU performance will decrease.
 This results in the CPU running for longer, thus increasing power consumption.
 Furthermore, the ISR handling latency will be increased.
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_cpu.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_cpu.rst
@@ -7,18 +7,18 @@ nRF54H20 domains
    :local:
    :depth: 2
 
-The nRF54H20 is partitioned into functional blocks, called *Domains*.
-The domains containing the user-programmable main CPUs and associated functions are called *Cores*.
+The nRF54H20 is partitioned into functional blocks, called *domains*.
+The domains containing the user-programmable main CPUs and associated functions are called *cores*.
 Most memory and peripherals can be flexibly allocated to cores at compile time.
 To make this possible, the memory and peripherals are located in a separate area called the Global Domain.
 Security functions are centralized into the Secure Domain.
 
 The following image shows the domains in the nRF54H20:
 
-.. figure:: images/nRF54H20_Domains.svg
-   :alt: nRF54H20 Domains
+.. figure:: images/nRF54H20_domains.svg
+   :alt: nRF54H20 domains
 
-   nRF54h20 Domains
+   nRF54H20 domains
 
 The CPU cores in the nRF54H20 are based on two types of CPU architectures:
 
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_ipc.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_ipc.rst
@@ -20,7 +20,7 @@ Technical solution
 ******************
 
 A single Interprocessor Communication instance used in the nRF54H20 SoC allows full-duplex communication between two cores.
-It support only unicast messages.
+It supports only unicast messages.
 
 To communicate with multiple peers, a core requires multiple IPC instances, at least as many as the number of peers.
 It is possible to create multiple IPC instances towards a single peer to separate messages with different priority levels.
@@ -116,8 +116,8 @@ Each ICMsg library instance requires the following:
 
 The ICMsg library is designed to efficiently send short messages to a peer.
 Its buffer allocation is not optimized for bulk transfer of long messages and it does not provide a zero-copy model.
-To transfer bigger amount of data (like network packets) between two cores, ICMsg can be used as control plane.
-However, you must use as data plane memory allocation mechanisms optimized for bigger data and supporting flexible memory allocation and a zero-copy model (like Zephyr's :ref:`zephyr:net_buf_interface`).
+To transfer larger amounts of data (like network packets) between two cores, use ICMsg as the control plane.
+For the data plane, use a memory allocation mechanism that supports flexible allocation and a zero-copy model, such as Zephyr's :ref:`zephyr:net_buf_interface`.
 
 .. note::
    The memory allocation mechanism for the data plane is a single-core memory allocation working on shared memory buffers.
@@ -136,7 +136,7 @@ This library provides a unified API for IPC transports and it integrates specifi
 ICMsg is integrated as one of the available IPC service backends.
 The library is responsible for creating IPC instances based on the system configuration described in the devicetree.
 
-It is recommended to use the ipc_service API to perform inter-processor communication in the nRF54H20 SoC.
+Use the ipc_service API to perform interprocessor communication in the nRF54H20 SoC.
 
 For more information, consult the :ref:`IPC service <zephyr:ipc_service>` library documentation.
 
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_memory.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_memory.rst
@@ -34,7 +34,7 @@ There is also a large part of the RAM in the global domain to be shared between
 Local RAM
 =========
 
-Local RAM is present in each of local domains
+Local RAM is present in each of the local domains
 
 Application core RAM
 --------------------
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_pm.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_pm.rst
@@ -28,7 +28,7 @@ The ARM Cortex CPUs of the nRF54H20 SoC currently support the following software
 Each CPU in the nRF54H20 SoC tries to preserve as much power as possible, independently from other CPUs.
 The power management subsystem, operating independently within each CPU, continuously selects the most optimal power state based on the current conditions of the CPU.
 
-The following sections describes the details of each of the software power states available on the nRF54H20 SoC.
+The following sections describe the details of each of the software power states available on the nRF54H20 SoC.
 
 Active
 ======
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_custom_pcb.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_custom_pcb.rst
@@ -14,7 +14,7 @@ Prepare your PCB
 
 First, you need to create your PCB for the nRF54H20 SoC.
 
-It is highly recommended to use the PCB layouts and component values provided by Nordic Semiconductor, especially for clock and power sources, considering the following limitations:
+Use the PCB layouts and component values provided by Nordic Semiconductor, especially for clock and power sources, considering the following limitations:
 
 * The DC/DC inductor must be present on the PCB for any of the supported power schemes.
   Use one of the following power supply options:
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_gs.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_gs.rst
@@ -10,8 +10,8 @@ Getting started with the nRF54H20 DK
 .. note::
    If you are migrating from an earlier version of the |NCS|, see :ref:`migration_guides`.
 
-This document will get you started with your new nRF54H20 Development Kit (DK) using the |NCS| for the first time.
-It will guide you through the following:
+This guide gets you started with your new nRF54H20 Development Kit (DK) using the |NCS| for the first time.
+It guides you through the following:
 
 1. Installing the |NCS| and other required software and tools.
 #. Preparing the nRF54H20 DK for first use:
@@ -162,7 +162,7 @@ To program the nRF54H20 IronSide SE binaries to the nRF54H20 DK, do the followin
 
       nrfutil device x-provision-nrf54h --firmware <path-to_bundle_zip_file> --serial-number <serial_number>
 
-.. _ug_nrf54h20_gs_bringup_trasition:
+.. _ug_nrf54h20_gs_bringup_transition:
 
 .. rst-class:: numbered-step
 
@@ -172,7 +172,7 @@ Bring-up step: Transitioning the nRF54H20 SoC to RoT
 The current nRF54H20 DK comes with its lifecycle state (LCS) set to ``EMPTY``.
 To operate correctly, you must transition its lifecycle state to Root of Trust (``RoT``).
 
-.. note::
+.. caution::
    The forward transition to LCS ``RoT`` is permanent.
    After the transition, it is impossible to transition backward to LCS ``EMPTY``.
 
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_keys.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_keys.rst
@@ -44,7 +44,7 @@ These are the standard persistent keys conforming to the :ref:`supported version
 * Minimum ID: ``0x00000001`` (``PSA_KEY_ID_USER_MIN``)
 * Maximum ID: ``0x3FFFFFFF`` (``PSA_KEY_ID_USER_MAX``)
 
-In order to successfully provision user keys, you must first configure cryptographic partitions in your :ref:`ug_nrf54h20_ironside_uicr_securestorage` configuration.
+To successfully provision user keys, you must first configure cryptographic partitions in your :ref:`ug_nrf54h20_ironside_uicr_securestorage` configuration.
 
 Revocable keys
 --------------
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_mcuboot_requests.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_mcuboot_requests.rst
@@ -18,7 +18,7 @@ The bootloader requests module provides APIs for the following:
 
 * Confirm an image after a successful update.
 
-  This functionality is used to mark an updated image as valid from the bootloader context, allowing to set the whole application partition as non-updatable before executing.
+  This functionality marks an updated image as valid from the bootloader context, allowing you to set the whole application partition as non-updatable before executing.
   In such case, the application simply requests the bootloader to confirm the image during the next boot instead of modifying the active image partition directly.
   The bootloader handles these requests before entering the main boot logic, ensuring that the image selection and update logic acts as if the image was confirmed by the application itself.
   The bootloader always erases the confirm requests after processing them, ensuring that the image is confirmed only once.
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h_ecies_x25519.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h_ecies_x25519.rst
@@ -18,7 +18,7 @@ Limitations
 
 The current implementation has the following limitations:
 
-* On the nRF54H20 SoC,ECIES-X25519 key exchange requires the ED25519 signature algorithm (default).
+* On the nRF54H20 SoC, ECIES-X25519 key exchange requires the ED25519 signature algorithm (default).
 * Encryption is not supported when using MCUboot in direct-xip mode.
 * HMAC and HKDF tools currently use the SHA-256 hash algorithm.
 
