Flash Partition Management with Trusted Firmware-M

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?

Parents
  • vytautas said:
    Can the tfm and app partition sizes change after DFU?

    While indeed we have a Static partition requirement for DFU, this requirement is for bootloader and DFU partitions. The important thing is that where MCUboot boots to and where the DFU goes into does not change.
    Since tfm and app partitions are DFUed as one package, they can change sizes in comparison to each other. But mcuboot_primary_app, which they live inside, must stay the same. So sum size app+tfm must stay the same.

    vytautas said:
    Is there any reason why the tfm (0x28200) partition is so large in the tfm_psa_template?

    TF-M partition size is set here. As you see, it varies depending on TF-M features enabled.

    vytautas said:
    When building the image it says it is only using 94 / 255 kB (37.16%) of FLASH. It seems excessive to allocate it such a partition, especially as the User & Zephyr code can grow to be quite large.

    You are free to resize TF-M by configuring CONFIG_PM_PARTITION_SIZE_TFM yourself, and make this closer to 100%.
    It is also possible to disable features for TF-M, but my experience is that minimizing TF-M size can be tricky.

Reply
  • vytautas said:
    Can the tfm and app partition sizes change after DFU?

    While indeed we have a Static partition requirement for DFU, this requirement is for bootloader and DFU partitions. The important thing is that where MCUboot boots to and where the DFU goes into does not change.
    Since tfm and app partitions are DFUed as one package, they can change sizes in comparison to each other. But mcuboot_primary_app, which they live inside, must stay the same. So sum size app+tfm must stay the same.

    vytautas said:
    Is there any reason why the tfm (0x28200) partition is so large in the tfm_psa_template?

    TF-M partition size is set here. As you see, it varies depending on TF-M features enabled.

    vytautas said:
    When building the image it says it is only using 94 / 255 kB (37.16%) of FLASH. It seems excessive to allocate it such a partition, especially as the User & Zephyr code can grow to be quite large.

    You are free to resize TF-M by configuring CONFIG_PM_PARTITION_SIZE_TFM yourself, and make this closer to 100%.
    It is also possible to disable features for TF-M, but my experience is that minimizing TF-M size can be tricky.

Children
No Data
Related