Partition Alignment

RE: Partition Alignment

Vidar Berg — Mon, 16 Jun 2025 12:03:47 GMT

[quote user="H.Marske"]i read the documentation-page for TF-M and in the limitations-chapter it states:
"Firmware Update service is not supported"[/quote]

The reason is that we don't use or rely this service to support DFU. Instead we use the same implementation as we would without TF-M enabled.

[quote user="H.Marske"]it has a size as well as start and end address. can i omit one of them?[/quote]

Technically you can chose to omit either "end_address" or "size". Start address must always be specified.

I generally think it's best to let the build system generate the partitions file, and then adjust it as needed as this is usually less error prone.

RE: Partition Alignment

H.Marske — Fri, 13 Jun 2025 09:36:20 GMT

i read the documentation-page for TF-M and in the limitations-chapter it states:
"Firmware Update service is not supported"

Can you please confirm that this indeed disables the availability of DFU over BLE?
If this is the case i cannot use it at all and we need to resort to the unsecure variant.

This also makes all my previous questions irrelevant.

RE: Partition Alignment

H.Marske — Thu, 12 Jun 2025 13:01:58 GMT

Dou you have any resources on what the diffrent partitions are used for and how i define them?

I have the feeling that some informations in there is duplicated wich is normal for a generated build but maybe i can omit them to make it easier to change the sizes if needed.

For example the partiton:
mcuboot_primary_app:
address: 0x14800
end_address: 0xbc000
orig_span: &id002
- app
- tfm
region: flash_primary
size: 0xa7800
span: *id002

it has a size as well as start and end address. can i omit one of them?
looking here im seeing a wildly different kind of partition.yml. What is the correct way of defining this?

I dont really care for optimal sizing as the 1.5MB is more than enough.

Also:
If we update the software in the future is it possible to change the partition sizes?

RE: Partition Alignment

Vidar Berg — Thu, 12 Jun 2025 12:54:21 GMT

That's not good. In most cases, you should be able to let the build system generate the partition for you. Then, when you're ready to lock down the memory layout before release, you can turn it into a static partitioning file by renaming it to pm_static.yml.

To work around this for now, you can adjust the current partitions.yml to ensure it meets the alignment requirements. Then, rename it to pm_static.yml, place it in the project root, and perform a clean build.

RE: Partition Alignment

H.Marske — Thu, 12 Jun 2025 12:49:50 GMT

That is what i would expect too.

In my case this is the generated partition.yml

Shame on me it warned me to create one on my own as "having the bootloader without a static_pm.yml can casue problems"

RE: Partition Alignment

Vidar Berg — Thu, 12 Jun 2025 12:28:23 GMT

Hello,

The problem is that the app start address is not aligned to a 0x1000 byte boundary like you mentioned

The non-secure start address in pm_static.yml or generated partition.yml is: 0x64600

It would have worked if the start address was 0x64000 or 0x65000 here.

But is the partitions.yml file created dynamically by the build, or did you create static partitions yourself? I would expect the build system to adhere to the alignment requirements.

Best regards,

Vidar