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?

[Charlie]

Hi,

You can find PM configuration guidance for your custom board from the following DevAcademy page.

Board files for multi-core hardware & TF-M - Nordic Developer Academy (nordicsemi.com)

Best regards,

Charlie

[vytautas]

Unfortunately, your reply doesn't answer my question. To my best understanding, our use-case would be best served by 'Static partitioning' (Ref: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/topic/multi-image-builds-and-the-partition-manager/), however the partition configuration (pm_static.yml) isn't clear for use-case where TF-M is used.

[Sigurd Hellesvik]

Hi,

I will continue to help with this ticket.

With TF-M, flash is parted into two parts: Secure flash (For TF-M) and Non-Secure flash (for app). 

EDIT: Might not be as simple. SPU is 32kB parts of the flash, so as you can see from the below report, TF-M also has stuff after the app, meaning that there are multiple parts here, not just 2 halves. Each part has to be either NSPE or SPE though.

See An Introduction to Trusted Firmware-M (TF-M) if to learn background on this.

So if you intend to use a custom flash partition in your app, just put it in the NSPE flash.

The partition manager is dynamic, so it can partition stuff for you.
The PSA Template sample is my goto "TF-M with all features" sample, so I will use that to show you:

Here is what I do:

1. Build the sample
2. Check build/partitions.yml, just to have a look
3. Create pm_static.yml:

   1. custom_partition:
        address: 0xfc000
        end_address: 0x100000
        region: flash_primary
        size: 0x4000
      

4. Delete build folder -> build sample again
5. "west build -t partition_manager_report"

6. Check build/partitions.yml again.

7. For release, copy build/parititons.yml -> pm_static.yml to freeze finished partitioning (required for DFU).

Does this make sense?

[vytautas]

Yes. Thank you:)

[vytautas]

I would like to re-open this ticket as I have a few follow-up questions.

When I run the partition_manager_report, I receive the following output:

I understand the following about the partition layout:

• B0 (0x0): This is the Nordic Secure Immutable Bootloader (NSIB).
• S0 (0x8000) and S1 (0x18000): These are MCUBoot partitions.

However, the following partitions are not entirely clear to me:

• mcuboot_primary (0x28000)
• tfm_secure (0x28000)
• app_image (0x28200)
• mcuboot_primary_app (0x28200)
• tfm (0x28200)
• tfm_nonsecure (0x68000)
• app (0x68000)
• mcuboot_secondary (0x88000)

My observation is that some of these partitions seem to overlap, which leads me to believe they might be overlaid for ease of use in code. For example, referring to app_image instead of calculating mcuboot_primary + 0x200.

Could you clarify the exact purpose of these partitions?

Additionally, I would like to understand where the code I compile will eventually reside. For example, where are pending updates stored (assume we're using swap w/ scratch)?

Finally, my assumption is that the boot sequence is as follows: NSIB loads MCUBoot, which then loads TFM, and finally, the user application is loaded. Is this assumption correct?