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]

> CONFIG_TFM_PROFILE_TYPE_MEDIUM=y

Our TF-M implementation officially supports either CONFIG_TFM_PROFILE_TYPE_NOT_SET or CONFIG_TFM_PROFILE_TYPE_MINIMAL . See Running applications with Trusted Firmware-M.

Jithin A said:

we get error if we use TYPE_MINIMAL/TYPE_SMALL.

Which error do you get with minimal?

What is the reason for not using minimal?

Minimal is the default conifguration, so it would be good to understand how it behaves with CONFIG_TFM_PROFILE_TYPE_MINIMAL fist.

Jithin A said:

Below are our MCUBoot config setup.

Do you see the same error without CONFIG_SECURE_BOOT=y?
Do you see the same error without CONFIG_BOOTLOADER_MCUBOOT=y?

[Jithin A]

Hi Sigurd,

Sigurd Hellesvik said:

What is the reason for not using minimal?

--> The reason is we have PSA protected storage enabled in our project and I see PSA protected storage is not supported in the TYPE_MINIMAL.

--> We are now moving to Integrated Trusted Storage instead.

Sigurd Hellesvik said:

Do you see the same error without CONFIG_SECURE_BOOT=y?
Do you see the same error without CONFIG_BOOTLOADER_MCUBOOT=y?

--> No, we get memory overflow only if we enable bootloader. This is a must as we need to support DFU.

We updated the SDK to v2.5.2 and we are now working on a sample application (TF-M secure peripheral) with TYPE_MINIMAL setup and we were able to build the project successfully.

We are trying to port our project implementation without PSA protected storage. So far it is good, and we have limited TF-M partition to use only 96KB using PM CONFIG.

Thank you for the support, will let you know if this fixes our memory problem.

[Sigurd Hellesvik]

Jithin A said:

--> The reason is we have PSA protected storage enabled in our project and I see PSA protected storage is not supported in the TYPE_MINIMAL.

--> We are now moving to Integrated Trusted Storage instead.

To check if there are other ways to do what you need: What kind of data are you storing?

Are you using this from NSPE or SPE?

Jithin A said:

--> No, we get memory overflow only if we enable bootloader. This is a must as we need to support DFU.

Do you have external flash in your project?

Depending on the answers to these questions, I hope to be able to give you some advise.

[Jithin A]

Sigurd Hellesvik said:

To check if there are other ways to do what you need: What kind of data are you storing?

We have a couple of secure keys for AES operations and some secure personal data of the user which are encrypted and stored.

Sigurd Hellesvik said:

Are you using this from NSPE or SPE?

From SPE.

Sigurd Hellesvik said:

Do you have external flash in your project?

No.

[Sigurd Hellesvik]

Looking more into this, I think moving from PSA Protected Storage to PSA Internal Trusted Storage is a fair enough option if you are restricted on flash space. Our TF-M developers agree.

From some testing, it looks like that should save you approximately 30kB.

Would that be enough?

[Jithin A]

Saving 30KB should be OK for us, we may use the additional space for storing user information and stuff.

We now configuring TFM MINIMAL with ITS enabled, this give us a room for both non-secure application and ITS expansion also.

Thank you for the support.

[Jithin A]

Hi Sigurd,

We are trying to understand the partition manager configuration and we see _pad on s0, s1, mcuboot.
Can you please explain what is the use of _pad partition?

Is it mandatory to have these partitions? if not we can save further memory space for our application.

We also see 2 EMPTY_x partition which each of size around 15KB. Can't we remove this partition and replace it with the successive partitions? This save us huge memory if we can completely remove EMPTY_x partitions.

We also noticed, the TFM secure and non-secure partition should be aligned to the NRF_SPU flash region size(0x4000), so removing EMPTY partitions should help us to save around 30KB or more.

Please help us on defining a partition table without any EMPTY partitions or unused or optional partitions.

[Sigurd Hellesvik]

Jithin A said:

Can you please explain what is the use of _pad partition?

Is it mandatory to have these partitions? if not we can save further memory space for our application.

From mcuboots pm.yml, the pad partition is for header information. I think some of them may be for mcuboot trailer information as well, but I am not 100% sure.

Either way, these are mandatory and used for MCUboots metadata.

Jithin A said:

We also see 2 EMPTY_x partition which each of size around 15KB. Can't we remove this partition and replace it with the successive partitions? This save us huge memory if we can completely remove EMPTY_x partitions.

We also noticed, the TFM secure and non-secure partition should be aligned to the NRF_SPU flash region size(0x4000), so removing EMPTY partitions should help us to save around 30KB or more.

Please help us on defining a partition table without any EMPTY partitions or unused or optional partitions.

It is sometimes possible to partition so that you can get rid of the EMPTY partitons.
However as you say SPU is important here. For example, the tfm_its partition is probably together with EMPTY, as you can not put any NSPE partition in the same SPU region as it.

If you can give your partitioning report "west build -t partition_manager_report", I can maybe give you some more substantial advice?

Here are some devzone tickets on EMPTY partitions:

 west build generates large EMPTY partitions

 [nRF5340 DK] What is empty_0 and empty_1 in flash partition? Why use static partition for firmware update? 

 RE: Partition Manager not using flash efficiently 

[Jithin A]

Hi Sigurd,

We are trying to configure to each partition by defining in pm_static.yml. So far, we are good, and we are able to reduce some and keep it for application.

One thing I want to know is can we allot/resize B0 and MCUBoot such that the size is aligned to 0x4000 and less than what is set by default.

I understand that any partition size should be aligned to 0x4000. So that it does not create any empty slots for further alignment.

After looking into memory report, we get to know that these partitions are not taking the complete allocated memory so thought of using the unused memory for our application instead.

The thing is we have a lot of packages like crypto operations and TLS functionalities in our application and to which these libraries are taking a lot of memory, and we cannot have external flash due to hardware restrictions with all of this we are seeing to get space from wherever possible.

Please let me your thoughts on this.

[Sigurd Hellesvik]

I will see if I can make up some thoughts soon, but in the meantime I thought that maybe this draft PR could be useful for you to look at:

github.com/.../13812