Partition Manager documentation of pm_static.yml regions?

[denis]

The NCS documentation refers to the Partition Manager from a few places to describe how to layout areas for MCUboot, etc.  However, I don't see any documentation there for the various partitions that seem to be required.  For example, in the generated file I see the following partitions:

app:
b0:
b0_image:
mcuboot:
mcuboot_pad:
mcuboot_primary:
mcuboot_primary_app:
mcuboot_secondary:
otp:
pcd_sram:
provision:
rpmsg_nrf53_sram:
s0:
s0_image:
s0_pad:
s1:
s1_image:
s1_pad:
spm_app:
sram_primary:

What are each of these partitions for, so that I know how to lay them out manually for my application?

I would like to statically allocate all partitions as this will be for a released product where they must be the same for firmware updating.  The firmware update images will be in external flash.

[Amanda Hsieh]

Hi Denis, 

You could build normally, with a dynamic partition allocation for the first release, and for future releases use <build_folder>/partitions.yml as your pm_static. 

-Amanda H.

[denis]

Can you answer my original question "What are each of these partitions for?"

I understand that there are ways to adjust them.  But I need documentation of what each partition is, so that I know what values to use.

BTW: The reply button on the web UI doesn't show up on the latest message, so I'm replying to this earlier message.

[Amanda Hsieh]

Hi Denis, 

We don't have documentation as you require. There are some comments in bootloader/mcuboot/boot/zephyr/pm.yml, and there are some other pm.yml files for other subsystems in nrf/subsys/partition_manager/. The SPM's pm.yml is in nrf/samples/spm/. 

denis said:

But I need documentation of what each partition is, so that I know what values to use.

The whole point of the partition manager is that it chooses appropriate sizes. It makes sense to want to change e.g. file system partitions (and the other partitions in nrf/susbsys/partition_manager), but the mcuboot partitions can (and probably should) be given whatever is left

The partitions that belong to a particular subsystem can be configured with the appropriate Kconfig option, and the option should specify the legal range (if any). For the rest of the partitions, the PM should select the smallest possible (for e.g. MCUBoot), and the mcuboot_primary and secondary slots should be whatever is left.

The typical workflow is to develop your application without considering the Partition Manager. Then, when you have made the first version, you take the partitioning scheme the Partition Manager used, and use that as the static configuration in future versions.

You might be inteststed with this post.  

-Amanda H. 

[denis]

"take the partitioning scheme the Partition Manager used" doesn't work for me.  The partition manager doesn't know how much code I plan on adding later to each image (boot loaders, etc).  So it can't know the sizes that I need.  I also need to choose locations for partitions (internal flash, which of my external flash devices, etc).