Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Click or drag files to this area to upload. You can upload up to 2 files.

Sysbuild – Partition Manager

Partition Manager

Zephyr RTOS uses the DTS binding fixed partitions to partition the memory into different slots. However, since the nRF Connect SDK needs a more dynamic partition method, we have the Partition Manager. The Partition Manager uses .yaml files, at build time, to define partitions and generates a partition scheme to fit with features needed by an application. The partition manager can be enabled with SB_CONFIG_PARTITION_MANAGER, and it is enabled by default when Sysbuild is enabled.

DTS Partitioning is separate for each image, so if a project uses DTS Partitioning, it must ensure that the DTS files are the same for all images. If partitioning is set only in the board files, all images will automatically inherit the same partitioning.

Partition Manager partitioning is on the Sysbuild level and will apply to all images in the build.

Partitioning in nRF Connect SDK

In nRF Connect SDK, there are three partitioning schemes. Which one to utilize is dependent on the SoC/SiP and the application as explained below:

  1. Devicetree Fixed Partitioning (relies on DTS binding fixed partitions defined in devicetree). This is used for basic samples with no multi-image build, such as the Blinky & Hello World sample
  2. Dynamic partitioning. A concept by the Partition Manager (nRF Connect SDK only, covered next). Default for nRF91 with TF-M, nRF53, nRF52+DFU/FOTA
  3. Static partitioning through pm_static.yml files. A concept by the Partition Manager (nRF Connect SDK only, covered next). Not default. Samples specific (Ex: Matter, Thingy:53). For DFU/FOTA, developers must enable static partitioning before the firmware production release.

Why is partitioning important?

When building multiple images for a single core, we must make sure that the memory addresses (partitions) are the same in configuration for all images (per core). There are several reasons for this. Firstly, images must not overlap. Additionally, the application must be compiled for the correct address space. And lastly, the bootloader and application must be configured with the same partition information. (Read more about bootloaders and DFU in Lesson 9). The Partition Manager is responsible for giving all images the same partitioning information.

Working with the Partition Manager

When we have built a project, we 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 the Partition Manager is enabled, partitions will be created to fill up the memory. Different partitions are created depending on which features are enabled in the application. For example, if CONFIG_NVS is enabled, a nvs partition is created, or if MCUboot is enabled, the partitions mcuboot, mcuboot_primary and mcuboot_secondary are created. These partitions are defined in pm.yml files.

pm.yml files for extra images can be found in the extra image sample folder inside the SDK, such as nrf/samples/bootloader/pm.yml.

pm.yml files for other partitions can be found in the nrf/subsys/partition_manager/ folder.

Configuring the Partition Manager

To configure the Partition Manager, we can use Kconfig options related to each partition. For example, to configure the size of MCUboot, we can use CONFIG_PM_PARTITION_SIZE_MCUBOOT. I recommend looking at relevant pm.yml files to find configuration options. It is also possible to search for CONFIG_PM_ in our Kconfig search, but keep in mind that CONFIG_PM_ can refer to both Partition Manager and Power Management here. The partition size configuration goes into the image configuration for the relevant image. For example, to overlay MCUboot partition size, set CONFIG_PM_PARTITION_SIZE_MCUBOOT in main_image/sysbuild/mcuboot.conf.

Static configuration

It is possible to “freeze” the partitioning scheme by configuring static partitions, which is done by creating a pm_static.yml file in the main application. A good starting point for pm_static.yml is to copy build/partitions.yml. Static partitioning is relevant for DFU, and will be explained in “Lesson 9 – Bootloaders and DFU/FOTA”.

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.