Skip to content

Conversation

@kapi-no
Copy link
Contributor

@kapi-no kapi-no commented Nov 6, 2025

No description provided.

@kapi-no kapi-no requested review from a team as code owners November 6, 2025 13:08
@NordicBuilder NordicBuilder added the doc-required PR must not be merged without tech writer approval. label Nov 6, 2025
@NordicBuilder NordicBuilder requested a review from a team November 6, 2025 13:08
@NordicBuilder
Copy link
Contributor

NordicBuilder commented Nov 6, 2025

CI Information

To view the history of this post, click the 'edited' button above
Build number: 4

Inputs:

Sources:

sdk-nrf: PR head: 137e4d3ca3a7b8e1e1054fdb71feb258d13a6c52

more details

sdk-nrf:

PR head: 137e4d3ca3a7b8e1e1054fdb71feb258d13a6c52
merge base: 38be4e5e1d1d43cfb04b817c88c15db7ca52acbd
target head (main): b1ffd8d2c01b1e34037a4faa014b3c202a78fbe6
Diff

Github labels

Enabled Name Description
ci-disabled Disable the ci execution
ci-all-test Run all of ci, no test spec filtering will be done
ci-force-downstream Force execution of downstream even if twister fails
ci-run-twister Force run twister
ci-run-zephyr-twister Force run zephyr twister
List of changed files detected by CI (3)
applications
│  ├── nrf_desktop
│  │  ├── doc
│  │  │  ├── dfu.rst
│  │  │  │ dfu_mcumgr.rst
doc
│  ├── nrf
│  │  ├── releases_and_maturity
│  │  │  ├── releases
│  │  │  │  │ release-notes-changelog.rst

Outputs:

Toolchain

Version:
Build docker image:

Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped; ⚠️ Quarantine

  • ◻️ Toolchain
  • ◻️ Build twister
  • ◻️ Integration tests
Disabled integration tests
    • test-fw-nrfconnect-nrf_lrcs_positioning
    • desktop52_verification
    • test_ble_nrf_config
    • test-fw-nrfconnect-apps
    • test-fw-nrfconnect-ble_mesh
    • test-fw-nrfconnect-ble_samples
    • test-fw-nrfconnect-chip
    • test-fw-nrfconnect-fem
    • test-fw-nrfconnect-nfc
    • test-fw-nrfconnect-nrf-iot_libmodem-nrf
    • test-fw-nrfconnect-nrf-iot_lwm2m
    • test-fw-nrfconnect-nrf-iot_samples
    • test-fw-nrfconnect-nrf-iot_thingy91
    • test-fw-nrfconnect-nrf-iot_zephyr_lwm2m
    • test-fw-nrfconnect-nrf_crypto
    • test-fw-nrfconnect-ps-main
    • test-fw-nrfconnect-rpc
    • test-fw-nrfconnect-rs
    • test-fw-nrfconnect-tfm
    • test-fw-nrfconnect-thread-main
    • test-low-level
    • test-sdk-audio
    • test-sdk-dfu
    • test-sdk-find-my
    • test-sdk-mcuboot
    • test-sdk-wifi
    • test-secdom-samples-public

Note: This message is automatically posted and updated by the CI

@kapi-no kapi-no force-pushed the nrf_desktop_ironside_app_module_update branch from 914a872 to 357eb20 Compare November 6, 2025 13:14
@github-actions
Copy link

github-actions bot commented Nov 6, 2025

The DFU module is compatible with the memory layout defined using the Partition Manager.
This partitioning method is used by default for most board targets that are based on the nRF52, nRF53, and nRF54 Series SoCs.

Additionally, the DFU module is compatible with the memory layout defined using the Device Tree Source (DTS) when it is used with the MCUboot bootloader.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Additionally, the DFU module is compatible with the memory layout defined using the Device Tree Source (DTS) when it is used with the MCUboot bootloader.
Additionally, the DFU module is compatible with the memory layout defined using the Devicetree Source (DTS) when you use it with the MCUboot bootloader.

Isn't it Devicetree Specification?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://docs.zephyrproject.org/latest/build/dts/intro-syntax-structure.html

As the name indicates, a devicetree is a tree. The human-readable text format for this tree is called DTS (for devicetree source), and is defined in the Devicetree specification.

@@ -69,6 +69,8 @@ Make sure that the DFU lock utility is enabled if your nRF Desktop application c
You cannot use this module with the :ref:`caf_ble_smp`.
In other words, you cannot simultaneously enable the :ref:`CONFIG_DESKTOP_DFU_MCUMGR_ENABLE <config_desktop_app_options>` option and the :kconfig:option:`CONFIG_CAF_BLE_SMP` Kconfig option.

Currently, this module supports only one bootloader backend: the MCUboot bootloader backend.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Currently, this module supports only one bootloader backend: the MCUboot bootloader backend.
Currently, this module supports only one bootloader backend, the MCUboot bootloader backend.

Copy link
Contributor

@MarekPieta MarekPieta Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider combining this sentence with the note below to highlight it (this is the same information):

.. note::
    Currently, this module supports only one bootloader backend, the MCUboot bootloader backend.
    B0 bootloader is not integrated with MCUmgr.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence is an introduction to the subsequent section about the MCUboot backend. I would then duplicate this information.

@@ -313,6 +316,9 @@ nRF Desktop
* The documentation of the :ref:`nrf_desktop_hid_state` and default HID report providers to simplify getting started with updating HID input reports used by the application or introducing support for a new HID input report.
* The default value of the :kconfig:option:`CONFIG_SOC_FLASH_NRF_RADIO_SYNC_MPSL_NORMAL_PRIORITY_TIMEOUT_US` Kconfig option to ``0``.
This is done to start using high MPSL timeslot priority quicker and speed up non-volatile memory operations.
* The :ref:`nrf_desktop_dfu` and the :ref:`nrf_desktop_dfu_mcumgr` to handle the ``nrf54h20dk/nrf54h20/cpuapp`` board target with the IronSide SE architecture and the MCUboot bootloader.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the doc pages be updated with the IronSide SE details?
We have document about IronSide SE here : https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_ironside.html

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. This is the documentation of the IronSide component, which we do not change.

I think we should just document the nRF Desktop integration with IronSide (or in other words: how we use IronSide in our application).

@@ -313,6 +316,9 @@ nRF Desktop
* The documentation of the :ref:`nrf_desktop_hid_state` and default HID report providers to simplify getting started with updating HID input reports used by the application or introducing support for a new HID input report.
* The default value of the :kconfig:option:`CONFIG_SOC_FLASH_NRF_RADIO_SYNC_MPSL_NORMAL_PRIORITY_TIMEOUT_US` Kconfig option to ``0``.
This is done to start using high MPSL timeslot priority quicker and speed up non-volatile memory operations.
* The :ref:`nrf_desktop_dfu` and the :ref:`nrf_desktop_dfu_mcumgr` to handle the ``nrf54h20dk/nrf54h20/cpuapp`` board target with the IronSide SE architecture and the MCUboot bootloader.

* Removed the SUIT support from the :ref:`nrf_desktop_dfu` and the :ref:`nrf_desktop_dfu_mcumgr`.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have mention about suit in the Board configuration docs here : https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/applications/nrf_desktop/board_configuration.html#nrf_desktop_board_configuration_files. Could remove those line as well? Also, the note about IronSide SE migration at the end of the page.

Copy link
Contributor Author

@kapi-no kapi-no Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be done in a follow-up PR. This PR focuses only on the application modules from the nRF Desktop app.

@@ -313,6 +316,9 @@ nRF Desktop
* The documentation of the :ref:`nrf_desktop_hid_state` and default HID report providers to simplify getting started with updating HID input reports used by the application or introducing support for a new HID input report.
* The default value of the :kconfig:option:`CONFIG_SOC_FLASH_NRF_RADIO_SYNC_MPSL_NORMAL_PRIORITY_TIMEOUT_US` Kconfig option to ``0``.
This is done to start using high MPSL timeslot priority quicker and speed up non-volatile memory operations.
* The :ref:`nrf_desktop_dfu` and the :ref:`nrf_desktop_dfu_mcumgr` to handle the ``nrf54h20dk/nrf54h20/cpuapp`` board target with the IronSide SE architecture and the MCUboot bootloader.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was a plan to update the migration guide as well. Will that be done as part of this PR or a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this PR is one of many for the related JIRA ticket. I plan to contribute the nRF Desktop migration guide at the very end

@@ -69,6 +69,8 @@ Make sure that the DFU lock utility is enabled if your nRF Desktop application c
You cannot use this module with the :ref:`caf_ble_smp`.
In other words, you cannot simultaneously enable the :ref:`CONFIG_DESKTOP_DFU_MCUMGR_ENABLE <config_desktop_app_options>` option and the :kconfig:option:`CONFIG_CAF_BLE_SMP` Kconfig option.

Currently, this module supports only one bootloader backend: the MCUboot bootloader backend.
Copy link
Contributor

@MarekPieta MarekPieta Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider combining this sentence with the note below to highlight it (this is the same information):

.. note::
    Currently, this module supports only one bootloader backend, the MCUboot bootloader backend.
    B0 bootloader is not integrated with MCUmgr.

@@ -313,6 +313,9 @@ nRF Desktop
* The documentation of the :ref:`nrf_desktop_hid_state` and default HID report providers to simplify getting started with updating HID input reports used by the application or introducing support for a new HID input report.
* The default value of the :kconfig:option:`CONFIG_SOC_FLASH_NRF_RADIO_SYNC_MPSL_NORMAL_PRIORITY_TIMEOUT_US` Kconfig option to ``0``.
This is done to start using high MPSL timeslot priority quicker and speed up non-volatile memory operations.
* The :ref:`nrf_desktop_dfu_mcumgr` to handle the ``nrf54h20dk/nrf54h20/cpuapp`` board target with the IronSide SE architecture and the MCUboot bootloader.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could add one note informing that we added support for the nrf54h20dk/nrf54h20/cpuapp board target with the IronSide SE architecture and the MCUboot bootloader (and SUIT support was removed)? Then we might briefly describe supported features (maybe even as a bullet point sublist)?

We might also add it at the top (to highlight it)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This note will be added together with the update of the board configuration from the nRF Desktop documentation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then, I think we could skip adding release notes for now (add add one general note later on). I think it might not be worth to go into details here

Partitioning methods
====================

The DFU module is compatible with the memory layout defined using the Partition Manager.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to provide a bit more context why partitioning is relevant for this module. I would also suggest to remove some duplication. Maybe we could use something similar to:

The DFU module stores the update image received over the configuration channel to a dedicated memory partition (image slot that is currently not in use).
The module is compatible with memory layout defined in either Partition Manager or DTS.
Make sure to properly configure the memory layout in configuration.
For more details about the memory layout, see the :ref:`nrf_desktop_memory_layout` documentation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe we could even skip this section as the information is covered in line 42:

.. important::
   The received update image chunks are stored on the dedicated non-volatile memory partition when the current version of the device firmware is running.
   For this reason, make sure that you use configuration with a dedicated update image partition.
   For more information on configuring the memory layout in the application, see the :ref:`nrf_desktop_memory_layout` documentation.

You could just add information that The module is compatible with memory layout defined in either Partition Manager or DTS.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section would probably be extended if we proceed with the RAM load mode of MCUboot in the context of LM20. Due to this, I would desist from removing this section.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add an introductory sentence, as I think it is a good improvement

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section would probably be extended if we proceed with the RAM load mode of MCUboot in the context of LM20. Due to this, I would desist from removing this section.

That's another reason why we should avoid duplicating information. Maybe we could remove the "generic information" from this doc page and update the nrf_desktop_memory_layout doc page (we need to do it anyway).

@kapi-no kapi-no force-pushed the nrf_desktop_ironside_app_module_update branch from 357eb20 to 75d4b5b Compare November 25, 2025 13:35
@kapi-no
Copy link
Contributor Author

kapi-no commented Nov 25, 2025

Force push to address the comments

Updated the DFU MCUmgr application module that is part of the
nRF Desktop application to align with the IronSide SE architecture
for the nRF54H20 SoC.

Ref: NCSDK-35488

Signed-off-by: Kamil Piszczek <[email protected]>
Updated the DFU application module that is part of the nRF Desktop
application to align with the IronSide SE architecture for the nRF54H20
SoC.

Ref: NCSDK-35488

Signed-off-by: Kamil Piszczek <[email protected]>
@kapi-no kapi-no force-pushed the nrf_desktop_ironside_app_module_update branch from 75d4b5b to 137e4d3 Compare November 25, 2025 14:04
@kapi-no
Copy link
Contributor Author

kapi-no commented Nov 25, 2025

Force push to rebase and resolve conflicts.

You cannot use this module with the :ref:`caf_ble_smp`.
In other words, you cannot simultaneously enable the :ref:`CONFIG_DESKTOP_DFU_MCUMGR_ENABLE <config_desktop_app_options>` option and the :kconfig:option:`CONFIG_CAF_BLE_SMP` Kconfig option.

Currently, this module supports only one bootloader backend, the MCUboot bootloader backend.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would skip this sentence as it's already part of the note below

@@ -313,6 +313,9 @@ nRF Desktop
* The documentation of the :ref:`nrf_desktop_hid_state` and default HID report providers to simplify getting started with updating HID input reports used by the application or introducing support for a new HID input report.
* The default value of the :kconfig:option:`CONFIG_SOC_FLASH_NRF_RADIO_SYNC_MPSL_NORMAL_PRIORITY_TIMEOUT_US` Kconfig option to ``0``.
This is done to start using high MPSL timeslot priority quicker and speed up non-volatile memory operations.
* The :ref:`nrf_desktop_dfu_mcumgr` to handle the ``nrf54h20dk/nrf54h20/cpuapp`` board target with the IronSide SE architecture and the MCUboot bootloader.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then, I think we could skip adding release notes for now (add add one general note later on). I think it might not be worth to go into details here

Partitioning methods
====================

The DFU module is compatible with the memory layout defined using the Partition Manager.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section would probably be extended if we proceed with the RAM load mode of MCUboot in the context of LM20. Due to this, I would desist from removing this section.

That's another reason why we should avoid duplicating information. Maybe we could remove the "generic information" from this doc page and update the nrf_desktop_memory_layout doc page (we need to do it anyway).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

doc only doc-required PR must not be merged without tech writer approval.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants