doc: Updated documentation with PM deprecation note.

FrancescoSer · rlubos · commit 19e6fb32b788 · 2026-04-09T14:05:05.000+02:00
Updated documentation with PM deprecation note.

Signed-off-by: Francesco Domenico Servidio &lt;francesco.servidio@nordicsemi.no&gt;
diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.rst
@@ -67,6 +67,8 @@ The |NCS| currently supports two implementations:
   .. figure:: ../images/bootloader_memory_layout.svg
      :alt: Memory layout
 
+.. include:: ../../../includes/pm_deprecation.txt
+
 By default, building an application with any bootloader configuration uses :ref:`sysbuild` to build multiple image, where the :ref:`partition_manager` manages its memory partitions.
 When building an application with :ref:`Cortex-M Security Extensions (CMSE) enabled <app_boards_spe_nspe_cpuapp_ns>`, then :ref:`Trusted Firmware-M (TF-M) <ug_tfm>` is built with the image automatically.
 From the bootloader perspective, the TF-M is part of the booted application image.
diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.rst
@@ -11,6 +11,8 @@ Partitioning device memory is a crucial aspect of managing how a device's storag
 By default, the Partition Manager in the system dynamically generates a partition map, which is suitable for most applications that do not use Device Firmware Upgrades (DFU).
 For scenarios involving DFU, read the following sections.
 
+.. include:: ../../../includes/pm_deprecation.txt
+
 .. _bootloader_partitioning_partitions_file:
 
 Partition map file
diff --git a/doc/nrf/app_dev/bootloaders_dfu/qspi_xip_split_image.rst b/doc/nrf/app_dev/bootloaders_dfu/qspi_xip_split_image.rst
@@ -52,6 +52,8 @@ The QSPI XIP split image feature supports network core image updates on nRF5340
 Create the Partition Manager static files
 *****************************************
 
+.. include:: ../../includes/pm_deprecation.txt
+
 Create the following files:
 
 * A static :ref:`partition_manager` file to set up the partitions that will be used on the device.
diff --git a/doc/nrf/app_dev/config_and_build/cmake/index.rst b/doc/nrf/app_dev/config_and_build/cmake/index.rst
@@ -56,6 +56,9 @@ The |NCS| uses the same CMake build variables as Zephyr and they are compatible
 |parameters_override_west_config|
 
 For the complete list of build variables in Zephyr and more information about them, see :ref:`zephyr:important-build-vars` in the Zephyr documentation.
+
+.. include:: ../../../includes/pm_deprecation.txt
+
 The following table lists the most common ones used in the |NCS|:
 
 .. list-table:: Common build system variables in the |NCS|
diff --git a/doc/nrf/app_dev/config_and_build/config_and_build_system.rst b/doc/nrf/app_dev/config_and_build/config_and_build_system.rst
@@ -133,6 +133,8 @@ The :ref:`Kconfig Reference <configuration_options>` provides the documentation
 Memory layout configuration
 ---------------------------
 
+.. include:: ../../includes/pm_deprecation.txt
+
 The memory layout configuration is provided by the :ref:`partition_manager` script, specific to the |NCS|.
 
 The script must be enabled to provide the memory layout configuration.
diff --git a/doc/nrf/app_dev/config_and_build/index.rst b/doc/nrf/app_dev/config_and_build/index.rst
@@ -24,6 +24,8 @@ All of them have a role in the creation of an application, from configuring the
 * Ninja (comparable to Make) uses the build files to build the program.
 * The compiler (for example, GCC) creates the executables.
 
+.. include:: ../../includes/pm_deprecation.txt
+
 For a more detailed overview, see :ref:`app_build_system`.
 
 Depending on the board you are working with, check also its :ref:`hardware guide <device_guides>`, as some nRF Series families have specific exceptions and rules to be applied on top of the general configuration procedures.
diff --git a/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_forced_options.rst b/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_forced_options.rst
@@ -7,6 +7,8 @@ Sysbuild controls some Kconfig options in images that are part of a project.
 This means that these Kconfig options can only be changed from within sysbuild itself and cannot be changed directly in an image.
 Trying to change them directly in an image will result in the new value being overwritten with the sysbuild value.
 
+.. include:: ../../../includes/pm_deprecation.txt
+
 +-------------------------------------------------------------------------+---------------------------------------------------------------------------+-------------------------+
 | Kconfig                                                                 | Sysbuild Kconfig                                                          | Images                  |
 +=========================================================================+===========================================================================+=========================+
diff --git a/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_images.rst b/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_images.rst
@@ -65,6 +65,8 @@ These options specify the image for the firmware loader:
 Adding custom images
 ********************
 
+.. include:: ../../../includes/pm_deprecation.txt
+
 Custom images can be added directly to a project (or board) or to a Zephyr module, making them accessible to multiple projects.
 
 .. _sysbuild_images_adding_to_single_project:
diff --git a/doc/nrf/app_dev/data_storage.rst b/doc/nrf/app_dev/data_storage.rst
@@ -98,6 +98,8 @@ See the following sections for descriptions of the storage features from the tab
 Partitioning
 ------------
 
+.. include:: ../includes/pm_deprecation.txt
+
 Partitioning prevents storage subsystems from overwriting each other's data by giving them ownership over different non-volatile memory regions.
 In the |NCS|, you can use either :ref:`Devicetree fixed flash partitions <zephyr:flash_map_api>` or the :ref:`Partition Manager <partition_manager>` to manage non-volatile memory partitions.
 
diff --git a/doc/nrf/app_dev/device_guides/nrf53/qspi_xip_guide_nrf5340.rst b/doc/nrf/app_dev/device_guides/nrf53/qspi_xip_guide_nrf5340.rst
@@ -108,6 +108,8 @@ Add the following to the DTS overlay for your board:
 Setting up static partition manager
 ***********************************
 
+.. include:: ../../../includes/pm_deprecation.txt
+
 You need to complete the setup in order to use a static partitioning in your project.
 The configuration must have 3 images with 2 slots each:
 
diff --git a/doc/nrf/app_dev/device_guides/nrf54l/nrf54l_signing_with_payload.rst b/doc/nrf/app_dev/device_guides/nrf54l/nrf54l_signing_with_payload.rst
@@ -28,6 +28,8 @@ Note that the DTS file for the CPUAPP application must reserve a required area f
 Using Partition Manager
 =======================
 
+.. include:: ../../../includes/pm_deprecation.txt
+
 For :ref:`partition_manager`, applications can only use static definitions.
 In the current version of the |NCS|, the CPUAPP application and the FLPR application use different partitioning definitions.
 The CPUAPP application follows the Partition Manager's scheme, while FLPR relies on DTS partitioning and disregards the Partition Manager scheme.
diff --git a/doc/nrf/libraries/dfu/dfu_extra.rst b/doc/nrf/libraries/dfu/dfu_extra.rst
@@ -51,6 +51,8 @@ Add extra binaries in your application's :file:`sysbuild.cmake` file:
        )
    endif()
 
+.. include:: ../../includes/pm_deprecation.txt
+
 If an additional binary needs to be handled by MCUboot as updatable slots, adjust the :kconfig:option:`SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES` Kconfig option, and make sure MCUboot partitions are defined correctly.
 
 To automatically include the extra binary in the final :file:`merged.hex` output, define a partition with the same name as provided in the ``NAME`` parameter within your partition manager configuration.
diff --git a/doc/nrf/libraries/dfu/dfu_target.rst b/doc/nrf/libraries/dfu/dfu_target.rst
@@ -150,6 +150,8 @@ Enable the following options:
 
 The MCUboot target will then use the :ref:`zephyr:settings_api` subsystem in Zephyr to store the current progress used by the :c:func:`dfu_target_write` function across power failures and device resets.
 
+.. include:: ../../includes/pm_deprecation.txt
+
 Using a dedicated partition for full modem upgrades
 ===================================================
 
diff --git a/scripts/partition_manager/partition_manager.rst b/scripts/partition_manager/partition_manager.rst
@@ -7,6 +7,8 @@ Partition Manager
    :local:
    :depth: 2
 
+.. include:: ../../doc/nrf/includes/pm_deprecation.txt
+
 The Partition Manager is a Python script that sets the start address and size of all the flash and RAM partitions in a multi-image build context.
 When creating an application that requires other images, like a bootloader, you can configure the Partition Manager to control where each image should be placed in memory, and how the RAM should be shared.
 
