Flash Partition Management with Trusted Firmware-M

[vytautas]

Backround: We are planning to use TF-M with a two-stage bootloader (NSIB & MCUBoot) using dual-slots for secure and non-secure images. We need to support configurable fixed flash partitions (i.e. for event or configuration storage) and would like to retain the option to use an external flash in the future.

I have read through the nRF Connect SDK documentation, however it is not clear to me how the Partition Managed is used to configure fixed flash partitions for targets using TF-M. Could you please provide an example partition configuration on the nRF9160 (using internal flash) with: dual-slots for secure / non-secure images, secure storage (i.e. certificates), event storage (for telemetry) and configuration?

[Sigurd Hellesvik]

These partitions are defined in pm.yml files around the SDK.
Specifically here (subsystems), this(NSIB) and this(MCUboot).

Mark that there are differences between "span" and "placament". "Span" overlaps other partitions, while "placement" has a specific place in code. "Span" is thus mostly to describe sets of other partitions.

• app: The "app" is where the zephyr application lives. This is the default partition and is always automatically generated by the partition manager.
• app_image [span]: NSIB uses this when there is single bootloader. I don't think this one is used for dual bootloaders, but I might have missed some subtlety. For NSIB only, this is the address NSIB will boot to after the bootloader I think.
• mcuboot_pad [placement]: MCUboot needs to store some metadata per image. Size 0x200. You see 0x200 repeat in the offsets right. Could more clearly have been named "mcuboot_primary_pad" to match the below name.
• mcuboot_primary_app [span]: In your case, this overlaps with "app". But if we got direct-xip mode for MCUboot, we want two different app partitions, so then we also will have mcuboot_secondary_app. These have the address mcuboot will boot to after the bootloader.
• mcuboot_primary [span]: We want to know the whole MCUboot primary (app + pad) to be under one. The full DFU binary goes into here, cause that has both image and metadata.
• mcuboot_secondary [placement]: When updating the application, you want to swap it in. MCUboot secondary is generally for this.
• tfm [placement]: The tfm application. This is code that runs, just as the app. Must be just before tha app.
• tfm_secure [span] + tfm_nonsecure [span]: With TF-M, we want to do separation of SPE and NSPE Processing environments. So we create partitions so we know which to make S flash and which to make NS flash.
  • tfm_secure overlaps mcuboot_pad and tfm.
  • Note: Mark that tfm_nonsecure and tfm are updated by the MCUboot, os these are overlapped by mcuboot_primary

I think I got this image correct, but feel free to check up against previously mentioned pm.yml files

Regards,
Sigurd Hellesvik