Flash Partition Management with Trusted Firmware-M

RE: Flash Partition Management with Trusted Firmware-M

vytautas — Tue, 25 Nov 2025 09:22:23 GMT

Hi,

This can be closed.

Thank you for the information.

RE: Flash Partition Management with Trusted Firmware-M

Sigurd Hellesvik — Mon, 20 Jan 2025 10:15:05 GMT

[quote user="vytautas.virvicius"]We've decided we want to use MCUBoot's Serial Recovery for wired (UART) upgrades. Is there any way to add a MCUMgr command to read out the active slot without having to fork the bootloader implementation?[/quote]

No, I do not know of any Hook feature in the Serial Recovery SMP implementation

RE: Flash Partition Management with Trusted Firmware-M

vytautas — Wed, 15 Jan 2025 11:37:50 GMT

We've decided we want to use MCUBoot's Serial Recovery for wired (UART) upgrades. Is there any way to add a MCUMgr command to read out the active slot without having to fork the bootloader implementation?

RE: Flash Partition Management with Trusted Firmware-M

Sigurd Hellesvik — Thu, 31 Oct 2024 09:26:37 GMT

[quote user="vytautas.virvicius"]but surely it can't function the same way for MCUBoot, given that you would be overwriting code you are currently executing.[/quote]

First, MCUboot runs from S0.
Then you upload update to S1, with newer version.
Then reboot. MCUboot will now boot from newest version: S1.
Then you upload update to S0, with newer version.
Then reboot. MCUboot will now boot from newest version: S0.
Etc.

[quote user="vytautas.virvicius"]Who determines which (S0 or S1) partition the MCUBoot update (of MCUBoot itself!) should go to?[/quote]

You "simply" have to upload to the slot MCUboot does not run from.
I had to ask devs for how to read this. They say " https://github.com/nrfconnect/sdk-nrf/blob/main/samples/tfm/tfm_psa_template/src/main.c#L92 shows how to do it in TF-M"

I am not yet sure how to do it without TF-M, but I think you should be able to use the FW Info lib.

RE: Flash Partition Management with Trusted Firmware-M

vytautas — Mon, 28 Oct 2024 05:05:42 GMT

[quote userid="106736" url="~/f/nordic-q-a/115835/flash-partition-management-with-trusted-firmware-m/507915"]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.[/quote]

By looking at the NSIB (Nordic Secure Immutable Bootloader) design we can see that it is capable of booting into the S0 or S1 partitions unlike MCUBoot, which will always boot into the mcuboot_primary partition.

I understand how the swap mechanism works for the primary and secondary application (app) partitions, but surely it can't function the same way for MCUBoot, given that you would be overwriting code you are currently executing.

Who determines which (S0 or S1) partition the MCUBoot update (of MCUBoot itself!) should go to?

RE: Flash Partition Management with Trusted Firmware-M

Sigurd Hellesvik — Fri, 25 Oct 2024 11:00:12 GMT

[quote user="vytautas.virvicius"]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?[/quote]

Excellent idea! I will make it public.

[quote user="vytautas.virvicius"]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?[/quote]

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.

[quote user="vytautas.virvicius"]For instance, if updates are saved to mcuboot_secondary (0x88000)[/quote]

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.

[quote user="vytautas.virvicius"]The only alternative I see is that the update is staged directly to S0 or S1 partition[/quote]

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

RE: Flash Partition Management with Trusted Firmware-M

vytautas — Fri, 25 Oct 2024 09:52:53 GMT

[quote user="Sigurd Hellesvik"]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.[/quote]

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?

RE: Flash Partition Management with Trusted Firmware-M

Sigurd Hellesvik — Fri, 25 Oct 2024 06:46:36 GMT

[quote user="vytautas.virvicius"]Can the tfm and app partition sizes change after DFU?[/quote]

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.

[quote user="vytautas.virvicius"]Is there any reason why the tfm (0x28200) partition is so large in the tfm_psa_template?[/quote]

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

[quote user="vytautas.virvicius"]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.[/quote]

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.

RE: Flash Partition Management with Trusted Firmware-M

vytautas — Thu, 24 Oct 2024 14:48:01 GMT

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

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.

Can the tfm and app partition sizes change after DFU?

RE: Flash Partition Management with Trusted Firmware-M

Sigurd Hellesvik — Thu, 24 Oct 2024 14:35:58 GMT

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

RE: Flash Partition Management with Trusted Firmware-M

vytautas — Thu, 24 Oct 2024 12:40:27 GMT

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?

RE: Flash Partition Management with Trusted Firmware-M

vytautas — Thu, 05 Sep 2024 14:11:20 GMT

Yes. Thank you:)

RE: Flash Partition Management with Trusted Firmware-M

Sigurd Hellesvik — Mon, 12 Aug 2024 13:44:33 GMT

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:

Build the sample
Check build/partitions.yml, just to have a look

Create pm_static.yml:

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

Delete build folder -> build sample again
"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?

RE: Flash Partition Management with Trusted Firmware-M

vytautas — Tue, 06 Aug 2024 11:13:54 GMT

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.

RE: Flash Partition Management with Trusted Firmware-M

Charlie — Tue, 06 Aug 2024 11:06:27 GMT

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