Flash partitioning

Question

The MCUboot, Slot0, and Slot1 flash partitions are defined in the board file. E.g., nrf52840dk_nrf52840.dts has boot_partition at 0 with length 0xC000, slot0_partition at 0xC000 with length 0x76000, slot1_partition at 0x82000 with length 0x76000, and storage_partition picking up at 0xF8000, right after Slot1. 
 In a Sigurd Hellesvik git repo, I learned about partition_manager_report; "west build -t partition_manager_report", which seems to say that Slot 0, for the primary image, is at 0xC000 with a length of 0x7A000 (starting with a 0x200 "pad") and Slot 1, for the secondary image, is at 0x86000 with a length of 0x7A000. It would seem the partition manager is free to allocate flash0 in nrf52840_qiaa.dtsi however it likes. Is the stuff in the DTS just a suggestion? This would seem to conflict with CONFIG_USE_DT_CODE_PARTITION=y in the prj.conf. 
 If I put stuff like USB in MCUboot and have to grow the partition to fit it by setting CONFIG_PM_PARTITION_SIZE_MCUBOOT, it reworks Slot0 and Slot1 lengths to fit in the 1Mbyte flash. 
 If I set CONFIG_NVS=y, partition_manager_report now has a nvs_storage block, not starting at 0xF8000 per the DTS file, but actually CONFIG_PM_PARTITION_SIZE_NVS_STORAGE from the end. So we really can't use the DTS macros to determine where a user-defined constant in flash might be. 
 The application I'm working on currently reserves some memory at the very end, to be loaded with a device serial number via nrfjprog. I'm "reserving" it in a DTS overlay and giving it a symbol that can be recovered with a DT macro. But if partition manager isn't really paying attention to the partition allocations in DT, how would I tell partition manager to reserve the space and not potentially overwrite it with a DFU or some NVS operation?

Sigurd Hellesvik · Accepted Answer

Hi again, 
 We hade some national holidays here, so things became a bit delayed. 
 I see that you found a solution, and if that works for you, no need to change it. But I will try to explain it all from the bottom up, in case you are interested. 
 Zephyr vs nRF Connect SDK 
 Some years ago, we only had the nRF5 SDK. But to keep up with the times, we needed an RTOS. For this, we chose the Zephyr RTOS. However, we needed some leeway, so we created the nRF Connect SDK, which is basically the Zephyr RTOS with our own stuff on top. Some info on this can be found in nRF Connect SDK and nRF5 SDK statement . 
 I will refer to only Zephyr (without the nRF Connect SDK) as Vanilla Zephyr. 
 Zephyr DTS and Partition Manager 
 Zephyr use DeviceTree (DTS) to configure the hardware. Among this DTS config there are partition information. However, for the nRF Connect SDK we needed something more dynamic than DTS partitioning. So for the nRF Connect SDK we created the Partition Manager. This means that the Partition Manager is only in the nRF Connect SDK and not in Vanilla Zephyr. And the nRF Connect SDK uses Zephyr but not vice versa. So you can use DTS partitioning in the nRF Connect SDK but not the Partition Manager in Vanilla Zephyr. 
 This means that in the nRF Connect SDK, you have two alternatives for partitioning: DTS partitioning or Partition Manager. To complicate things a bit: The build system still uses DTS partitioning, so the partition manager technically generates DTS partitioning I think. But from a user perspective, you have must use only one to configure your project. => You can not configure partitions with DTS partitioning and the Partition Manager at the same time. If you do, DTS partitioning will be ignored and the Parititon Manager will "win". 
 How can you know if your project uses DTS partitioning or the Partition Manager? If the Parititon Manager is enabled, that is used. If not, DTS partitioning is used. You can check CONFIG_PARTITION_MANAGER_ENABLED to see which one is used. 
 How to work with static partitioning 
 Okay, so the whole point of the Partition Manager is that it is dynamic. Then why even allow for static partitioning? The reason is twofold: 
 
 MCUboot requires that partitioning remain the same between DFUs 
 To create custom partitions 
 
 While you technically can use pm_static.yml in your project at any time, i would argue that you should only do it for one or both of the above reasons. The reason for this is mostly that working with pm_static.yml is hard, because we need to apply our feeble human brains to align hex values manually, instead of making the build system do this automatically for you. 
 How to do static partitioning for MCUboot 
 
 Backup your whole build folder from your release build. This is generally a good idea. 
 Copy build/partitions.yml to pm_static.yml for your project. This will make sure that project partitioning never changes as long as pm_static.yml stays the same. 
 
 As you can see, this does not require you to edit pm_static.yml manually. 
 How to create a custom partition 
 
 Create a pm_static.yml file 
 Add only your custom partition 
 The partition manager should now dynamically add partitions around your custom partition 
 
 Here, you can see that you only need to add custom partitions in pm_static.yml, so you do need minimal editing of pm_static.yml 
 Where are Partition Manager partitions defined 
 These are defined in one of two places: 
 
 ncs/nrf/subsys/partition_manager , see pm.yml files 
 Child image samples with pm.yml files.
 
 Examples:
 
 mcuboot 
 netboot (b0n) 
 NSIB (b0)

You should not change these, but they are good to know about for debugging sometimes. 
 NVS, Settings, and general file systems 
 So NVS, Settings and file systems are kinda corner cases. 
 Firstly, if you enable for example NVS in your project, the partition manager will automatically add a partition named nvs_storage . 
 This means that our internal uses of NVS will use nvs_storage automatically. You can still use nvs_storage from your application. However, if you use NVS in your application, you can also point your app's instance of NVS to another partition, usually a custom NVS partition. The reason to use a custom partition is related to flash_map_pm.h, explained below. 
 Then we also have nrf/include/flash_map_pm.h you can see that we define a partition named "storage_partitions" for multiple different file sysstems. Because of this, if you add both NVS and littlefs to a project, these may end up using the same partition. I must admit that I am a bit unsure to how this will work in practice.

Flash partitioning

Top Replies