doc: migration guide: add Fast Pair nRF53 PM to DTS migration steps

Add a Fast Pair Locator Tag sample entry to the v3.4 migration guide
that lists the unique adjustments required when migrating the nRF53
Series DFU configuration with MCUboot in the overwrite mode from the
Partition Manager to devicetree (DTS).

The new entry refers the reader to the generic Fast Pair PM-to-DTS
migration steps from the v3.3 migration guide and supplements them
with the nRF53-specific actions:

- Enable SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE in sysbuild so
  that the application core and network core images are updated
  together through MCUboot.
- Override the external flash node (for example, mx25r64) in the
  application core overlay to host slot1_partition (image-1) and
  slot3_partition (image-3); align slot3_partition with the
  RAM-backed slot2_partition from the upstream flash_sim overlay.
  Note that, unlike on nRF52 and nRF54L Series targets, the internal
  flash (flash0) only needs slot0_partition for MCUboot.
- Define the network core (flash1) partition layout (b0n_partition,
  provision_partition aliased as bl_storage, and s0_partition) once
  in the IPC radio sysbuild overlay.
- Add a B0N sysbuild image overlay that includes the IPC radio
  cpunet overlay and chooses b0n_partition as zephyr,code-partition,
  and enable CONFIG_USE_DT_CODE_PARTITION in the B0N image
  configuration.
- Disable CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS in the MCUboot sysbuild
  image configuration, since this option relies on Partition
  Manager-only macros for the network core image slot.

In addition, append a backwards compatibility note at the end of the
section that lists the specific partition offsets and sizes (slot3,
b0n, provision, and s0 partitions) needed to keep the new DTS layout
aligned with the legacy Partition Manager layout from |NCS| v3.3.0,
so that field-deployed devices flashed with the v3.3.0 release can
still receive DFU updates after the migration.

Ref: NCSDK-38010

Signed-off-by: Kamil Piszczek <Kamil.Piszczek@nordicsemi.no>

Author: kapi-no

doc/nrf/releases_and_maturity/migration/migration_guide_3.4.rst

@@ -139,7 +139,99 @@ Samples and applications
 
 This section describes the changes related to samples and applications.
 
-|no_changes_yet_note|
+Fast Pair Locator Tag sample
+----------------------------
+
+.. toggle::
+
+   The :ref:`fast_pair_locator_tag` sample on nRF53 Series board targets (``nrf5340dk/nrf5340/cpuapp`` and ``thingy53/nrf5340/cpuapp``) has been migrated from the deprecated :ref:`partition_manager` static configuration to devicetree (DTS) for the partition layout.
+   With this change, all board targets supported by the sample now use DTS for partition definitions.
+   The ``nrf5340dk/nrf5340/cpuapp/ns`` and ``thingy53/nrf5340/cpuapp/ns`` board target variants have been removed from the sample.
+
+   If your application is based on the nRF53 Series MCUboot DFU configuration of this sample, start by applying the following generic Fast Pair migration steps that are common to all supported board targets:
+
+   * The PM-to-DTS migration steps described in the *Google Fast Pair* recommended changes of the :ref:`migration_3.3` guide.
+   * The partition overlay compatible migration described in the :ref:`migration_3.4_google_fast_pair` section of this guide.
+     This step is mandatory on nRF53 Series board targets and applies to both the application core overlay (``flash0``) and the network core overlay (``flash1``).
+     Without this migration, the network core image is linked at an invalid address and the firmware does not start.
+
+   In addition to the generic steps, the nRF53 Series DFU configuration with MCUboot in the overwrite mode requires the following unique adjustments:
+
+   1. Enable the multi-image update mode in your sysbuild configuration so that the application core and network core images are updated together through MCUboot:
+
+      .. code-block:: kconfig
+
+         SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE=y
+
+      See the :file:`sysbuild/configuration/<board_target>/sysbuild.conf` file from the :ref:`fast_pair_locator_tag` sample as an example.
+
+   #. Override the external flash node in the application core overlay to define the MCUboot secondary slot partitions there.
+      In the nRF53 Series DFU configuration, the secondary slots reside in the external QSPI flash (for example, ``mx25r64`` on the ``nrf5340dk/nrf5340/cpuapp`` board target) instead of the internal flash.
+
+      Define the following partitions under the external flash node:
+
+      * ``slot1_partition`` (``image-1``) for the application core secondary slot.
+      * ``slot3_partition`` (``image-3``) for the network core secondary slot.
+
+      The size of ``slot3_partition`` must match the corresponding RAM-backed ``slot2_partition`` defined in the :file:`nrf/modules/mcuboot/flash_sim.overlay` file, which MCUboot uses to forward the network core image during DFU.
+
+      As a consequence of moving the secondary slots to external flash, the internal flash node (``flash0``) only needs to declare a single MCUboot slot partition (``slot0_partition``).
+      In the nRF52 and nRF54L Series board targets, the ``slot1_partition`` is also placed on the internal flash.
+      The remaining application core partitions (``boot_partition``, ``bt_fast_pair_partition``, and ``storage_partition``) stay on ``flash0`` as described in the generic migration steps.
+      See the :file:`configuration/boards/<board_target>.overlay` file in the sample for a complete example.
+
+   #. Define the network core partition layout under the network core flash node (``flash1``) in a sysbuild overlay shared by the network core images.
+      The layout consists of the following partitions:
+
+      * ``b0n_partition`` (``b0n``) for the secure bootloader on the network core.
+      * ``provision_partition`` (``b0-provision-data``), additionally aliased as ``bl_storage``, for the bootloader provisioning data.
+      * ``s0_partition`` (``image-0``) for the network core image slot.
+
+      Place this overlay in the :file:`sysbuild/ipc_radio/boards/<board_target>.overlay` file so that it is applied to the IPC radio image.
+      Size ``s0_partition`` so that the network core image fits within the RAM-backed ``slot2_partition`` of the :file:`nrf/modules/mcuboot/flash_sim.overlay` file.
+
+   #. Add a sysbuild image overlay for the B0N bootloader to reuse the same network core partition layout.
+      Create the :file:`sysbuild/b0n/boards/<board_target>.overlay` file that includes the IPC radio cpunet overlay and sets the ``zephyr,code-partition`` chosen node to ``b0n_partition``.
+      For example:
+
+      .. code-block:: devicetree
+
+         #include "../../ipc_radio/boards/<board_target>.overlay"
+
+         / {
+             chosen {
+                 zephyr,code-partition = &b0n_partition;
+             };
+         };
+
+      This mirrors the pattern used by the MCUboot image overlay on the application core: the layout is defined once in the application overlay and the bootloader image overlay only selects its own ``zephyr,code-partition``.
+
+      Enable the :kconfig:option:`CONFIG_USE_DT_CODE_PARTITION` Kconfig option in the B0N image configuration file (:file:`sysbuild/b0n/prj.conf`) so that the B0N bootloader links into the DTS-defined ``b0n_partition``:
+
+      .. code-block:: kconfig
+
+         CONFIG_USE_DT_CODE_PARTITION=y
+
+   #. Adjust the sysbuild image Kconfig configuration to align MCUboot with the DTS partition layout.
+      In the MCUboot sysbuild image configuration file (:file:`sysbuild/mcuboot/boards/<board_target>.conf`), disable the image address verification:
+
+      .. code-block:: kconfig
+
+         CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS=n
+
+      This option relies on Partition Manager-only macros for the network core image slot that are not available in the DTS build.
+
+   .. note::
+      If you maintain field-deployed devices flashed with the v3.3.0 |NCS| release and need them to keep receiving DFU updates after the migration, size the partitions to match the legacy Partition Manager layout from v3.3.0:
+
+      * On ``flash0``, keep ``boot_partition``, ``slot0_partition``, ``bt_fast_pair_partition``, and ``storage_partition`` aligned with the legacy ``mcuboot``, ``mcuboot_primary``, ``bt_fast_pair``, and ``settings_storage`` partitions.
+      * On the external flash (for example, ``mx25r64``), size ``slot1_partition`` and ``slot3_partition`` to match the legacy ``mcuboot_secondary`` and ``mcuboot_secondary_1`` partitions.
+        For ``slot3_partition``, this means 256 KB (``DT_SIZE_K(256)``).
+      * On ``flash1``, place ``b0n_partition`` at offset ``0x0`` with size ``0x2580``, ``provision_partition`` at offset ``0x2580`` with size ``0x280``, and ``s0_partition`` at offset ``0x2800`` with size 246 KB (``DT_SIZE_K(246)``) to match the legacy ``b0n``, ``provision``, and ``app`` partitions of the network core.
+      * No additional override is required for the RAM-backed ``slot2_partition``: starting with |NCS| v3.4.0, the default 256 KB size defined in the :file:`nrf/modules/mcuboot/flash_sim.overlay` file already matches the legacy ``mcuboot_primary_1`` partition.
+
+      The :ref:`fast_pair_locator_tag` sample uses exactly this layout on both supported nRF53 Series board targets and can be used as a reference.
+      If backwards compatibility with v3.3.0 deployments is not required, you can adjust the partition sizes to your application's needs as long as each slot pair (``slot0_partition`` / ``slot1_partition`` and ``s0_partition`` / ``slot2_partition`` / ``slot3_partition``) remains internally consistent.
 
 Libraries
 =========