• State Verified Answer
  • Replies 14 replies
  • Subscribers 74 subscribers
  • Views 773 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
    vytautas said:
    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?

    Excellent idea! I will make it public.

    vytautas said:
    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?

    Im gonna stop you on the assumption. As yoiu can see from Kconfig.tfm.pm, the size is only optimized for CONFIG_TFM_PROFILE_TYPE_MINIMAL. For all other TF-M profiles we default it to the number 0x40000. (depending on a couple of other tings such as bootloaders, but still).

    I think we just chose something that will work if we enable all features for TF-M.

    In short: We have not yet optimized non-minimal TF-M profiles, and leave optimizing partition sizes up to the user.

    vytautas said:
    For instance, if updates are saved to mcuboot_secondary (0x88000)

    MCUboot require that mcuboot_primary and mcuboot_secondary have the same size. This way, you can always fit the uptate for mcuboot_primary into mcuboot_secondary.

    vytautas said:
    The only alternative I see is that the update is staged directly to S0 or S1 partition

    S0 and S1 are slots where the mcuboot bootloader lives. They are only used for MCUboot, and for updating MCUboot.

Reply
  • 0
    vytautas said:
    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?

    Excellent idea! I will make it public.

    vytautas said:
    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?

    Im gonna stop you on the assumption. As yoiu can see from Kconfig.tfm.pm, the size is only optimized for CONFIG_TFM_PROFILE_TYPE_MINIMAL. For all other TF-M profiles we default it to the number 0x40000. (depending on a couple of other tings such as bootloaders, but still).

    I think we just chose something that will work if we enable all features for TF-M.

    In short: We have not yet optimized non-minimal TF-M profiles, and leave optimizing partition sizes up to the user.

    vytautas said:
    For instance, if updates are saved to mcuboot_secondary (0x88000)

    MCUboot require that mcuboot_primary and mcuboot_secondary have the same size. This way, you can always fit the uptate for mcuboot_primary into mcuboot_secondary.

    vytautas said:
    The only alternative I see is that the update is staged directly to S0 or S1 partition

    S0 and S1 are slots where the mcuboot bootloader lives. They are only used for MCUboot, and for updating MCUboot.

Children
Related
Terms of service