Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 15 additions & 11 deletions applications/nrf_desktop/doc/dfu.rst
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ Configuration

You can use this module for the following devices:

* nRF52, nRF53, and nRF54L Series - To perform the firmware upgrade, you must enable the bootloader.
* nRF52, nRF53, and nRF54 Series - To perform the firmware upgrade, you must enable the bootloader.
You can use the DFU module with either MCUboot or B0 bootloader.
For more information on how to enable and configure a bootloader, see the :ref:`nrf_desktop_bootloader` section.

Expand Down Expand Up @@ -62,6 +62,20 @@ If the option is enabled, the DFU module reports the ``MCUBOOT+XIP`` bootloader
The option depends on enabling the MCUboot bootloader (:kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT`) and is enabled by default if the MCUboot direct-xip mode of operations is set (:kconfig:option:`CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP`).
See the :ref:`nrf_desktop_bootloader` section for more information on the MCUboot bootloader configuration.

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

The DFU module stores the update image received over the configuration channel to a dedicated memory partition.
Due to this responsibility, it uses one of the supported partitioning methods to get the information about this partition location.

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).

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 Devicetree Source (DTS) when you use it with the MCUboot bootloader.
This is the only partitioning method that is supported for board targets based on the nRF54H Series SoC.

For more details about the memory layout methods, see the :ref:`nrf_desktop_memory_layout` documentation.

Device identification information
=================================

Expand Down Expand Up @@ -135,16 +149,6 @@ fwinfo
* Version and length of the image.
* Partition ID of the currently booted image, used to specify the image placement.

Additionally, for the nRF54H Series, the following applies:

* The reported image size is set to zero.
* The booted image version is indicated by:

* Root manifest sequence number that is encoded in the build number field.
* Manifest semantic version, if supported by the SDFW (requires v0.6.2 or higher).
The semantic version is encoded in the major, minor and patch fields.
If semantic versioning is not supported, these fields are set to zero.

.. _dfu_devinfo:

devinfo
Expand Down
5 changes: 4 additions & 1 deletion applications/nrf_desktop/doc/dfu_mcumgr.rst
Original file line number Diff line number Diff line change
Expand Up @@ -69,8 +69,11 @@ 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.

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


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

.. _nrf_desktop_dfu_mcumgr_mcuboot:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -364,6 +364,9 @@ nRF5340 Audio
nRF Desktop
-----------

* Added support for the DTS-based memory layout in the :ref:`nrf_desktop_dfu`.
This layout is only supported for the MCUboot bootloader.

* Updated:

* The memory layouts for the ``nrf54lm20dk/nrf54lm20a/cpuapp`` board target to make more space for the application code.
Expand Down Expand Up @@ -408,6 +411,9 @@ nRF Desktop
* Application image configurations to explicitly specify the LED driver used by the :ref:`nrf_desktop_leds` (:kconfig:option:`CONFIG_CAF_LEDS_GPIO` or :kconfig:option:`CONFIG_CAF_LEDS_PWM`).
Also, disabled unused LED drivers enabled by default to reduce memory footprint.
* The :ref:`nrf_desktop_hid_forward` to allow using the module when configuration channel support (:ref:`CONFIG_DESKTOP_CONFIG_CHANNEL_ENABLE <config_desktop_app_options>`) is disabled in the application configuration.
* 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).

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


* 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.

nRF Machine Learning (Edge Impulse)
-----------------------------------
Expand Down