nrfconnect · NordicBuilder · Nov 29, 2025 · Nov 28, 2025 · Nov 24, 2025 · Nov 28, 2025
@@ -235,7 +235,7 @@
 /doc/nrf/releases_and_maturity/           @nrfconnect/ncs-doc-release
 /doc/nrf/releases_and_maturity/abi_compatibility.rst @FrancescoSer
 /doc/nrf/samples/amazon_sidewalk.rst      @nrfconnect/ncs-sidewalk-doc
-/doc/nrf/samples/bl.rst                   @nrfconnect/ncs-dragoon-doc
+/doc/nrf/samples/bl.rst                   @nrfconnect/ncs-doc-leads
 /doc/nrf/samples/cellular.rst             @nrfconnect/ncs-cia-doc
 /doc/nrf/samples/crypto.rst               @nrfconnect/ncs-aegir-doc
 /doc/nrf/samples/debug.rst                @nrfconnect/ncs-cia-doc
@@ -525,6 +525,8 @@
 /samples/nrf5340/empty_app_core/          @nrfconnect/ncs-si-muffin
 /samples/nrf5340/extxip_smp_svr/          @nrfconnect/ncs-eris
 /samples/nrf54h20/empty_app_core/         @nrfconnect/ncs-aurora
+/samples/nrf54h20/idle_relocated_tcm/     @nrfconnect/ncs-si-muffin
+/samples/nrf54h20/radio_loader/           @nrfconnect/ncs-si-muffin
 /samples/ironside_se/                     @nrfconnect/ncs-aurora
 /samples/nrf_compress/                    @nordicjm
 /samples/nrf_profiler/                    @nrfconnect/ncs-si-bluebagel
@@ -651,6 +653,7 @@
 /samples/net/**/*.rst                     @nrfconnect/ncs-cia-doc
 /samples/net/coap_client/*.rst            @nrfconnect/ncs-iot-oulu-tampere-doc
 /samples/nfc/**/*.rst                     @nrfconnect/ncs-si-muffin-doc
+/samples/nrf54h20/idle_relocated_tcm/*.rst @nrfconnect/ncs-si-muffin-doc
 /samples/nrf5340/empty_app_core/*.rst     @nrfconnect/ncs-si-muffin-doc
 /samples/nrf5340/extxip_smp_svr/*.rst     @nrfconnect/ncs-eris-doc
 /samples/nrf5340/netboot/*.rst            @nrfconnect/ncs-eris-doc
@@ -688,7 +691,6 @@
 /samples/zephyr/smp_svr_mini_boot/        @nrfconnect/ncs-eris
 /samples/zephyr/subsys/ipc/               @nrfconnect/ncs-low-level-test
 /samples/zephyr/subsys/mgmt/mcumgr/smp_svr/ @nrfconnect/ncs-eris
-/samples/zephyr/subsys/settings/          @nrfconnect/ncs-low-level-test
 /samples/zephyr/subsys/usb/               @nrfconnect/ncs-low-level-test
 /samples/zephyr/sysbuild/                 @nrfconnect/ncs-low-level-test
 
@@ -855,6 +857,7 @@
 /tests/bluetooth/tester/                  @carlescufi @nrfconnect/ncs-paladin
 /tests/crypto/                            @magnev
 /tests/drivers/audio/                     @nrfconnect/ncs-low-level-test
+/tests/drivers/can/                       @nrfconnect/ncs-low-level-test
 /tests/drivers/flash/flash_rpc/           @nrfconnect/ncs-eris
 /tests/drivers/flash_patch/               @nrfconnect/ncs-eris
 /tests/drivers/fprotect/                  @nrfconnect/ncs-eris
@@ -923,6 +926,7 @@
 /tests/subsys/bluetooth/enocean/          @nrfconnect/ncs-paladin
 /tests/subsys/bluetooth/fast_pair/        @nrfconnect/ncs-si-bluebagel
 /tests/subsys/bluetooth/mesh/             @nrfconnect/ncs-paladin
+/tests/subsys/bluetooth/rpc_gatt_service/  @nrfconnect/ncs-protocols-serialization
 /tests/subsys/bootloader/                 @nrfconnect/ncs-eris
 /tests/subsys/caf/                        @nrfconnect/ncs-si-muffin @nrfconnect/ncs-si-bluebagel
 /tests/subsys/debug/cpu_load/             @nordic-krch

@@ -4,14 +4,8 @@
 # SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
 #
 
-# Usually BOARD_DIR is an absolute path and sourced through '<ZEPHYR_ROOT>/boards/Kconfig'.
-# But for compliance and doc generation it's a glob and this line ensures that
-# boards in sdk-nrf are sourced properly in those occasions.
-orsource "./$(BOARD_DIR)/Kconfig.board"
-orsource "./$(BOARD_DIR)/Kconfig"
 orsource "./cmake/toolchain/$(ZEPHYR_TOOLCHAIN_VARIANT)/Kconfig.defconfig"
 
-rsource "boards/shields/*/Kconfig.shield"
 rsource "subsys/net/openthread/Kconfig.defconfig"
 
 if !TFM_PROFILE_TYPE_MINIMAL

@@ -137,7 +137,7 @@ The following steps show how to add support for a new Matter device type, using
    #. Implement the body of the :c:func:`HandleRead` method to handle reading data operations for all supported attributes.
 
       The read operations for the ``Descriptor``, ``Bridged Device Basic Information`` and ``Identify`` clusters, which are common to all devices, are handled in a common bridge module.
-      The read operations for the ``Pressure Measurement`` cluster are the only ones to that need to be handled in the application.
+      The read operations for the ``Pressure Measurement`` cluster are the only ones that need to be handled in the application.
 
       To provide support for reading attributes for the Pressure Sensor device, edit the :file:`pressure_sensor.h` and :file:`pressure_sensor.cpp` files as follows:
 

@@ -69,8 +69,13 @@ void ProcessCommand(const Binding::TableEntry &aBinding, OperationalDeviceProxy
 uint8_t BleLBSDataProvider::GattNotifyCallback(bt_conn *conn, bt_gatt_subscribe_params *params, const void *data,
 					       uint16_t length)
 {
-	BleLBSDataProvider *provider = static_cast<BleLBSDataProvider *>(
-		BLEConnectivityManager::Instance().FindBLEProvider(*bt_conn_get_dst(conn)));
+	BleLBSDataProvider *provider = nullptr;
+	const bt_addr_le_t *btAddr = bt_conn_get_dst(conn);
+
+	VerifyOrExit(conn && btAddr, );
+
+	provider = static_cast<BleLBSDataProvider *>(
+		BLEConnectivityManager::Instance().FindBLEProvider(*btAddr));
 
 	VerifyOrExit(data, );
 	VerifyOrExit(provider, );

@@ -25,7 +25,7 @@ See the :file:`Kconfig.defaults` file in the :file:`nrf5340_audio` directory for
 
    The default Kconfig option values are automatically updated if configuration changes are applied directly in the configuration files.
 
-The application-specific Kconfig options mentioned on this page are listed in :ref:`nRF5340 Audio: Application-specific Kconfig options <config_audio_app_options>`.
+The application-specific Kconfig options mentioned on this page are listed in :ref:`nRF5340 Audio: Application-specific Kconfig options <nrf53_audio_app_config_audio_app_options>`.
 
 |config|
 
@@ -211,7 +211,7 @@ Configuring audio quality
 The nRF5340 Audio application provides extensive configuration options for audio quality.
 These settings affect the :ref:`nrf53_audio_app_overview_architecture_sync_module` and overall audio performance.
 
-See :ref:`config_audio_app_options` for the list of options to configure the following audio quality settings:
+See :ref:`nrf53_audio_app_config_audio_app_options` for the list of options to configure the following audio quality settings:
 
 * Frame duration (example: :option:`CONFIG_AUDIO_FRAME_DURATION_10_MS`)
 * Sample rates (example: :option:`CONFIG_AUDIO_SAMPLE_RATE_16000_HZ`)
@@ -226,7 +226,7 @@ Configuring Bluetooth LE Audio
 The nRF5340 Audio application introduces application-specific configuration options related to Bluetooth LE Audio.
 These options configure the Bluetooth stack components described in :ref:`nrf53_audio_app_overview_architecture`.
 
-See :ref:`config_audio_app_options` for options starting with ``CONFIG_BT_AUDIO``.
+See :ref:`nrf53_audio_app_config_audio_app_options` for options starting with ``CONFIG_BT_AUDIO``.
 
 .. _nrf53_audio_app_configuration_power_measurements:
 

@@ -1,4 +1,4 @@
-.. _config_audio_app_options:
+.. _nrf53_audio_app_config_audio_app_options:
 
 nRF5340 Audio: Application-specific Kconfig options
 ###################################################

@@ -32,7 +32,9 @@ CONFIG_UTF8=y
 CONFIG_BT_CONTENT_CTRL_MEDIA=y
 
 CONFIG_LC3_ENC_CHAN_MAX=2
-CONFIG_LC3_DEC_CHAN_MAX=1
+CONFIG_LC3_DEC_CHAN_MAX=2
 CONFIG_AUDIO_ENCODE_CHANNELS_MAX=2
 CONFIG_MBEDTLS_ENABLE_HEAP=y
 CONFIG_MBEDTLS_HEAP_SIZE=2048
+CONFIG_BT_AUDIO_CONCURRENT_RX_STREAMS_MAX=2
+CONFIG_AUDIO_DECODE_CHANNELS_MAX=2
@@ -176,15 +176,19 @@ Sample mouse (``nrf54lm20dk/nrf54lm20a/cpuapp``)
       * Bluetooth LE and USB High-Speed transports are enabled.
         Bluetooth LE is configured to use Nordic Semiconductor's SoftDevice Link Layer and Low Latency Packet Mode (LLPM).
         USB High-Speed is configured to use the USB next stack (:kconfig:option:`CONFIG_USB_DEVICE_STACK_NEXT`).
-        The :option:`CONFIG_DESKTOP_BLE_ADV_CTRL_ENABLE` and :option:`CONFIG_DESKTOP_BLE_ADV_CTRL_SUSPEND_ON_USB` Kconfig options are enabled in mouse configurations to improve the USB High-Speed report rate.
-      * In ``debug`` configurations, logs are provided through the UART.
+        The :option:`CONFIG_DESKTOP_BLE_ADV_CTRL_ENABLE` and :option:`CONFIG_DESKTOP_BLE_ADV_CTRL_SUSPEND_ON_USB` Kconfig options are enabled in mouse configurations to improve the HID report rate over USB.
+      * In ``debug``, ``ram_load``, and ``llvm`` configurations, logs are provided through the UART.
         For detailed information on working with the nRF54LM20 DK, see the :ref:`ug_nrf54l15_gs` documentation.
       * In ``llvm`` configurations, the partition layout is different to accommodate for the higher memory footprint of the ``llvm``  toolchain.
-      * The configurations use the MCUboot bootloader built in the direct-xip mode (``MCUBOOT+XIP``) and support firmware updates using the :ref:`nrf_desktop_dfu`.
+      * The ``debug``, ``release``, and ``llvm`` configurations use the MCUboot bootloader built in the direct-xip mode (``MCUBOOT+XIP``) and support firmware updates using the :ref:`nrf_desktop_dfu`.
         All of the configurations enable hardware cryptography for the MCUboot bootloader.
         The application image is verified using a pure ED25519 signature.
         The public key that MCUboot uses for validating the application image is securely stored in the hardware Key Management Unit (KMU).
         For more details on nRF54L Series cryptography, see :ref:`ug_nrf54l_cryptography`.
+      * The ``ram_load`` and ``release_ram_load`` configurations use the MCUboot bootloader built in the RAM load mode (``MCUBOOT``) and support firmware updates using the :ref:`nrf_desktop_dfu`.
+        Configurations in this bootloader mode use the same security features as direct-xip mode (``MCUBOOT+XIP``), including hardware cryptography, signature type, and public key storage.
+        The application code is executed from the RAM in this mode to improve the HID report rate over USB.
+        For more details on the RAM load mode, see the MCUboot :ref:`nrf_desktop_configuring_mcuboot_bootloader_ram_load` documentation section.
 
 Sample mouse or dongle (``nrf54h20dk/nrf54h20/cpuapp``)
       * The configuration uses the nRF54H20 DK.
@@ -193,14 +197,15 @@ Sample mouse or dongle (``nrf54h20dk/nrf54h20/cpuapp``)
       * Bluetooth LE and USB High-Speed transports are enabled.
         Bluetooth LE is configured to use Nordic Semiconductor's SoftDevice Link Layer and Low Latency Packet Mode (LLPM).
         USB High-Speed is configured to use the USB next stack (:kconfig:option:`CONFIG_USB_DEVICE_STACK_NEXT`).
-        The :option:`CONFIG_DESKTOP_BLE_ADV_CTRL_ENABLE` and :option:`CONFIG_DESKTOP_BLE_ADV_CTRL_SUSPEND_ON_USB` Kconfig options are enabled in mouse configurations to improve the USB High-Speed report rate.
+        The :option:`CONFIG_DESKTOP_BLE_ADV_CTRL_ENABLE` and :option:`CONFIG_DESKTOP_BLE_ADV_CTRL_SUSPEND_ON_USB` Kconfig options are enabled in mouse configurations to improve the HID report rate over USB.
       * In ``debug`` configurations, logs are provided through the UART.
         For detailed information on working with the nRF54H20 DK, see the :ref:`ug_nrf54h20_gs` documentation.
-      * The configurations use the Software Updates for Internet of Things (SUIT) and support firmware updates using the :ref:`nrf_desktop_dfu`.
+      * The configurations use the MCUboot bootloader built in the direct-xip mode (``MCUBOOT+XIP``) and support firmware updates using the :ref:`nrf_desktop_dfu`.
         Configurations acting as HID peripherals also support firmware updates using the :ref:`nrf_desktop_dfu_mcumgr`.
+        For more details on MCUboot, see :ref:`nrf_desktop_bootloader`.
 
-      .. note::
-         The nRF Desktop application does not build or run for the ``nrf54h20dk/nrf54h20/cpuapp`` board target due to the IronSide SE migration.
-         See the ``NCSDK-34299`` in the :ref:`known_issues` page for more information.
-         The :ref:`nrf_desktop` documentation may still refer to concepts that were valid before the IronSide SE migration (for example, to the SUIT solution).
-         The codebase and documentation will be updated in the future releases to address this issue.
+        All configurations enable hardware cryptography for the MCUboot bootloader.
+        The MCUboot bootloader uses the :ref:`ug_crypto_architecture_implementation_standards_ironside` for hardware cryptography.
+        The application image is verified using a pure ED25519 signature.
+        In all configurations, the MCUboot bootloader uses a merged image slot that combines both application and radio core images.
+        For more details on nRF54H Series DFU, see :ref:`ug_nrf54h20_mcuboot_dfu`.
@@ -189,6 +189,79 @@ For an example of a bootloader Kconfig configuration file defined by the applica
   Both mentioned firmware upgrade methods are not used simultaneously by any of the configurations.
   For example, the ``nrf52840dk/nrf52840`` board in ``mcuboot_smp`` file suffix uses only the background DFU and does not enable the serial recovery feature.
 
+.. _nrf_desktop_configuring_mcuboot_bootloader_ram_load:
+
+RAM load mode
+~~~~~~~~~~~~~
+
+The RAM load mode is used for the :ref:`background DFU <nrf_desktop_bootloader_background_dfu>`.
+In this mode, the MCUboot bootloader uses the same NVM partitioning as the direct-xip mode (the dual-bank DFU solution).
+Similarly to the direct-xip mode, the RAM load mode also relies on the image version to select the application image slot to be booted.
+However, instead of booting the image from the NVM slot, the bootloader in the RAM load mode copies the image from the non-volatile memory (NVM) to the RAM and boots it from there.
+The application image is always built for the RAM address space in only one variant.
+
+.. caution::
+   The RAM load mode of the MCUboot bootloader is not officially supported in |NCS|.
+   However, the mode is available in the |NCS| as the support for this feature has been developed as part of the Zephyr RTOS project.
+   This feature is only used in a limited context for the ``nrf54lm20dk/nrf54lm20a/cpuapp`` board target configuration to improve performance.
+
+You can use the RAM load mode of the MCUboot bootloader to speed up the code execution for the application image, as code execution from the RAM is generally faster than from the NVM.
+This can improve the device performance during the activities that require high CPU usage.
+As an example, the nRF Desktop application uses the RAM load mode for the ``nrf54lm20dk/nrf54lm20a/cpuapp`` board target to achieve 8 kHz report rate over USB in the ``release_ram_load`` configuration variant (the second configuration variant - ``ram_load`` - is used for debugging purposes only).
+
+To set the MCUboot mode of operations to the RAM load mode, enable the :kconfig:option:`SB_CONFIG_MCUBOOT_MODE_RAM_LOAD` Kconfig option in the sysbuild configuration.
+
+To support the RAM load mode, you must use DTS as the partitioning method, as the Partition Manager (PM) is not supported in this mode.
+To satisfy this requirement, disable explicitly the :kconfig:option:`SB_CONFIG_PARTITION_MANAGER` Kconfig option in your sysbuild configuration.
+Additionally, you must define the custom memory layout for the RAM in your target board configuration.
+Your RAM layout must define the following DTS child nodes as part of the ``cpuapp_sram`` DTS node in the address order listed below:
+
+* ``cpuapp_sram_app_rxm_region`` - This DTS node defines the hard limits for the executable ROM section (with the application image) and must be aligned with the :kconfig:option:`CONFIG_BOOT_IMAGE_EXECUTABLE_RAM_START` and the :kconfig:option:`CONFIG_BOOT_IMAGE_EXECUTABLE_RAM_SIZE` Kconfig options that are set in the MCUboot image configuration.
+  This DTS node describes the region in which the build system places the executable ROM section (code) and RAM section (data) of the application image.
+  The RAM section is located right after the ROM section - the RAM section may overflow the ``cpuapp_sram_app_rxm_region`` region and spill into the subsequent ``cpuapp_sram_mcuboot_ram_region`` region or even be entirely contained in this subsequent region.
+  The ``cpuapp_sram_mcuboot_ram_region`` region can be filled with the RAM section of the application image, as the application and bootloader code cannot run simultaneously.
+* ``cpuapp_sram_mcuboot_ram_region`` - This DTS node defines the RAM region for the MCUboot image and must be assigned to the MCUboot image as its chosen SRAM DTS node.
+
+For an example of the custom RAM layout that satisfies these requirements, see the :file:`nrf/applications/nrf_desktop/configuration/nrf54lm20dk_nrf54lm20a_cpuapp/memory_map_ram_load.dtsi` file.
+For an example of the RAM layout usage in the MCUboot bootloader image, see the :file:`nrf/applications/nrf_desktop/configuration/nrf54lm20dk_nrf54lm20a_cpuapp/images/mcuboot/app_ram_load.overlay` file.
+
+.. note::
+   The application image and the MCUboot image configuration must use the same memory layout.
+
+The RAM load mode requires using the Zephyr retention subsystem with the bootloader information sharing system.
+This subsystem is used by the MCUboot bootloader to provide image metadata to the application image.
+To enable the Zephyr retention subsystem, enable the following Kconfig options in your application image configuration and the MCUboot image configuration:
+
+* :kconfig:option:`CONFIG_RETENTION`
+* :kconfig:option:`CONFIG_RETAINED_MEM`
+* :kconfig:option:`CONFIG_RETAINED_MEM_ZEPHYR_RAM`
+
+In the application image configuration, enable the following Kconfig options:
+
+* :kconfig:option:`CONFIG_RETENTION_BOOTLOADER_INFO`
+* :kconfig:option:`CONFIG_RETENTION_BOOTLOADER_INFO_TYPE_MCUBOOT`
+* :kconfig:option:`CONFIG_RETENTION_BOOTLOADER_INFO_OUTPUT_FUNCTION`
+
+In the MCUboot image configuration, enable the following Kconfig options:
+
+* :kconfig:option:`CONFIG_BOOT_SHARE_DATA`
+* :kconfig:option:`CONFIG_BOOT_SHARE_DATA_BOOTINFO`
+* :kconfig:option:`CONFIG_BOOT_SHARE_BACKEND_RETENTION`
+
+The Zephyr retention subsystem requires the retention partition to be defined in the devicetree.
+For an example of the retention partition definition, see the :file:`nrf/applications/nrf_desktop/configuration/nrf54lm20dk_nrf54lm20a_cpuapp/memory_map_ram_load.dtsi` file.
+You must also assign the retention partition to the chosen DTS node ``zephyr,bootloader-info`` in both the application image configuration and the MCUboot image configuration.
+
+.. note::
+   If your board target uses the Key Management Unit (KMU) feature (:kconfig:option:`CONFIG_CRACEN_LIB_KMU`), you must additionally define the ``nrf_kmu_reserved_push_area`` DTS node in your custom memory layout.
+   Place this RAM section at the very beginning of the physical RAM due to the dependency on the ``nrfutil device`` tool and its KMU provisioning functionality.
+   For an example of the ``nrf_kmu_reserved_push_area`` DTS node definition, see the :file:`nrf/applications/nrf_desktop/configuration/nrf54lm20dk_nrf54lm20a_cpuapp/memory_map_ram_load.dtsi` file.
+
+   The KMU feature (:kconfig:option:`CONFIG_CRACEN_LIB_KMU`) is enabled by default for the nRF54L series.
+
+.. note::
+   The RAM load mode of the MCUboot bootloader is not yet integrated in the :ref:`nrf_desktop_dfu_mcumgr`.
+
 MCUboot bootloader on nRF54
 ---------------------------
 

@@ -8,12 +8,15 @@
  * and holds information about battery characteristic.
  */
 
+#include <helpers/nrfx_analog_common.h>
+#include <zephyr/drivers/adc.h>
+
 /* This structure enforces the header file is included only once in the build.
  * Violating this requirement triggers a multiple definition error at link time.
  */
 const struct {} battery_def_include_once;
 
-#define BATTERY_MEAS_ADC_INPUT		NRF_SAADC_INPUT_AIN3
+#define BATTERY_MEAS_ADC_INPUT		NRFX_ANALOG_EXTERNAL_AIN3
 #define BATTERY_MEAS_ADC_GAIN		ADC_GAIN_1
 #define BATTERY_MEAS_VOLTAGE_GAIN	1