• State Verified Answer
  • Replies 14 replies
  • Subscribers 74 subscribers
  • Views 1082 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 331159
Options

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?

Parents
  • 0
    Sigurd Hellesvik said:
    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.

    Assuming the partition size isn’t chosen arbitrarily, I’m guessing the compiler excludes unused TF-M features, resulting in the low memory usage I'm seeing with this sample. Is this correct?

    Also, looking closer at the partitioning, it is not clear where pending MCUBoot updates are stored. For instance, if updates are saved to mcuboot_secondary (0x88000), it may not leave sufficient space for the primary application (app + tfm). The only alternative I see is that the update is staged directly to S0 or S1 partition, however I would assume these flash regions aren't arbitrarily accessible and are protected by TF-M. Furthermore, if they are staged directly to those partitions, how does the application determine which slot to overwrite—say, if the current bootable image is in S1? Could you clarify this?

    PS. I don't think we've shared confidential information in this ticket. I think the information shared by you would be useful to others as well. Are you okay with making this ticket Public?

Reply
  • 0
    Sigurd Hellesvik said:
    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.

    Assuming the partition size isn’t chosen arbitrarily, I’m guessing the compiler excludes unused TF-M features, resulting in the low memory usage I'm seeing with this sample. Is this correct?

    Also, looking closer at the partitioning, it is not clear where pending MCUBoot updates are stored. For instance, if updates are saved to mcuboot_secondary (0x88000), it may not leave sufficient space for the primary application (app + tfm). The only alternative I see is that the update is staged directly to S0 or S1 partition, however I would assume these flash regions aren't arbitrarily accessible and are protected by TF-M. Furthermore, if they are staged directly to those partitions, how does the application determine which slot to overwrite—say, if the current bootable image is in S1? Could you clarify this?

    PS. I don't think we've shared confidential information in this ticket. I think the information shared by you would be useful to others as well. Are you okay with making this ticket Public?

Children
No Data
Related
Terms of service