Memory optimization in TF-M enabled applications

[Jithin A]

Hi, 

We have a project where we are using TF-M application along with DFU and we observe a memory overflow in the TF-M partition when we try to reduce the TF-M partition size.

Attached the memory report.

What is b0 partition and EMPTY_X partitions are used?  How to reduce these partitions size?

We see TF-M is consuming around 270KB and how to reduce this partition at least to its half. 

We basically need the TF-M partition to be minimal to make room for application in non-secure partition.

memory-map.xlsx

[Jithin A]

Hi, 

Can anyone please take a look into this, as this is blocking our further implementation.

Thank you in advance.

[Sigurd Hellesvik]

Hi,

Jithin A said:

Can anyone please take a look into this, as this is blocking our further implementation.

We do normal working weeks, so we do not answer in the weekends. Thank you for your patience.

Which features do you have in your project?

What does your bootloader setup look like?
Which TF-M profile type do you use?

Have you tried to enable TF-M with different configurations? Do you see the same error then?
Do you see the same issue for the Hello World sample in  Zephyr, if you add bootloaders and TF-M to it?

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

I spend a bit too long looking into why NSIB and MCUboot had to be each own SPU regions, before I realized why.

First I thought that they just had to be in Secure regions.
However, they are both write-protected by the SPU as well.
And both MCUboot and NSIB write-protects their own memory.
This write-protection is why we need to align NSIB and MCUboot.
And that is what spawns the EMPTY partitions.

NSIB  is 0x8000 already, so that should fit inside 0x4000x2.
However, for MCUboot, I think the best you can do is to make it fit as best possible inside 0x4000 multiples.

Does this make sense with what you see?

[Jithin A]

Sigurd Hellesvik said:

Does this make sense with what you see?

Yes, it makes sense now.

I really appreciate your support. Thank you so much.

Can you please help with below concerns,

1. I am thinking, anyway the MCUBoot and NSIB partition are not 100% utilizing the allocated memory. Is it possible to fit the _pad partition inside the respective partition. Like, inside MCUBoot we place MCUBoot_pad partition also and align the complete partition to SPU size 0x4000?
2. Or try to reduce MCUBoot application size?
3. Disable any PSA features to reduce TFM application size.

We are really very concerned on memory consumption. Please let us know if there is any other possible way to get memory for NS application.

The same PM_STATIC is what we are currently using.

We are also trying to get support from WolfSSL to reduce their library size as much as possible.

[Sigurd Hellesvik]

Eyo, I think I found something.
Vefore we attend to your questions from the last comment, see the following:

The tfm_psa_template gets a very similar partitioning to what you have, right.

I then realize that the gap you have is to align this between 0x14200 to 0x18000.
The gap is in other words because of the 0x200 pad, which you point out.
Instead of putting the pad inside mcuboot, we can just decrease mcuboot by 0x200.

If I configure CONFIG_PM_PARTITION_SIZE_MCUBOOT=0xbe00 inside the MCUboot child image configuration for this sample, I get the following, beautiful partitioning:

I ran the sample and it did work as expected. Try this on your side as well.

[Jithin A]

Hi Sigurd,

Thank you for the great response.

I try to resize the MCUBoot partition as you mentioned, and I see unknown symbol error.

Anyway, I am modifying my pm_static file instead. Let me test and get back to you.

This is good to know it is possible to remove EMPTY slots.

Thank you so much.

[Jithin A]

Thank you so much Sigurd,

We now can completely integrate the crypto and wolfSSL lib to our application.

This resolved our memory overflow issue. Thank you.