Partition Manager
Zephyr RTOS uses the device tree source (DTS) binding fixed partitions to partition memory into different slots. However, the nRF Connect SDK needs a more dynamic partition method, which is provided by Partition Manager. Partition Manager uses .yaml files at build time to define partitions and generates a partition scheme that fits the features needed by an application. You can enable Partition Manager with SB_CONFIG_PARTITION_MANAGER. It is enabled by default when sysbuild is enabled.
DTS partitioning is separate for each image. If a project uses DTS partitioning, you must ensure that the DTS files are the same for all images. If you set partitioning only in the board files, all images automatically inherit the same partitioning.
Partition Manager partitioning operates at the sysbuild level and applies to all images in the build.
Partitioning in nRF Connect SDK
The nRF Connect SDK provides three partitioning schemes. Which scheme to use depends on the SoC or SiP and the application, as explained below:
- Device tree fixed partitioning. Relies on DTS binding fixed partitions defined in device tree. This method is used for basic samples with no multi-image build, such as the Blinky and Hello World samples.
- Dynamic partitioning. A Partition Manager concept (nRF Connect SDK only, covered next). This is the default for nRF91 with TF-M, nRF53, and nRF52 with DFU or FOTA.
- Static partitioning through pm_static.yml files. A Partition Manager concept (nRF Connect SDK only, covered next). Not the default. Sample specific (for example, Matter and Thingy:53). For DFU or FOTA, you must enable static partitioning before the firmware production release.
Why is partitioning important?
When building multiple images for a single core, you must ensure that the memory addresses (partitions) are the same in configuration for all images (per core). There are several reasons for this. First, images must not overlap. Additionally, the application must be compiled for the correct address space. Finally, the bootloader and application must be configured with the same partition information. (Lesson 9 covers bootloaders and DFU in more detail.) Partition Manager ensures all images have the same partitioning information.
Working with the Partition Manager
After building a project, you can see how the partitioning was done by looking at build/partitions.yml or by using the VS Code Memory Report tool:
If you use a terminal, you can also use west build -t partition_manager_report. See Partition Manager report docs.
pm.yml files
When Partition Manager is enabled, partitions are created to fill the memory. Different partitions are created depending on which features are enabled in the application. For example, if CONFIG_NVS is enabled, an nvs partition is created. If MCUboot is enabled, the partitions mcuboot, mcuboot_primary, and mcuboot_secondary are created. These partitions are defined in pm.yml files.
You can find pm.yml files for extra images in the extra image sample folder inside the SDK, such as nrf/samples/bootloader/pm.yml.
You can find pm.yml files for other partitions in the nrf/subsys/partition_manager/ folder.
Configuring the Partition Manager
To configure Partition Manager, use Kconfig options related to each partition. For example, to configure the size of MCUboot, use CONFIG_PM_PARTITION_SIZE_MCUBOOT. To find configuration options, look at relevant pm.yml files. You can also search for CONFIG_PM_ in the Kconfig search, but keep in mind that CONFIG_PM_ can refer to both Partition Manager and Power Management. The partition size configuration goes into the image configuration for the relevant image. For example, to overlay the MCUboot partition size, set CONFIG_PM_PARTITION_SIZE_MCUBOOT in main_image/sysbuild/mcuboot.conf.
Static configuration
You can “freeze” the partitioning scheme by configuring static partitions. To do this, create a pm_static.yml file in the main application. A good starting point for pm_static.yml is to copy build/partitions.yml.
