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.
Hi,
Can anyone please take a look into this, as this is blocking our further implementation.
Thank you in advance.
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
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.
Are you using this from NSPE or SPE?
From SPE.
Do you have external flash in your project?
No.
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?
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.
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.
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:
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:
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.
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:
Hi Sigurd,
We try to get as much as memory for non-secure application while TF-M is taking 93% of allocated memory.
Attached our pm-static file, can you please look into this and help us in removing EMPTY_0 and EMPTY_1 partitions.
b0:
address: 0x0
end_address: 0x8000
placement:
after:
- start
region: flash_primary
size: 0x8000
b0_container:
address: 0x0
end_address: 0x8000
orig_span: &id002
- b0
region: flash_primary
size: 0x8000
span: *id002
s0:
address: 0x8000
end_address: 0x14200
orig_span: &id006
- s0_pad
- mcuboot
region: flash_primary
size: 0xc200
span: *id006
s0_pad:
address: 0x8000
end_address: 0x8200
placement:
after:
- b0_container
align:
start: 0x4000
region: flash_primary
share_size:
- mcuboot_pad
size: 0x200
s0_image:
address: 0x8200
end_address: 0x14200
orig_span: &id007
- mcuboot
region: flash_primary
size: 0xc000
span: *id007
mcuboot:
address: 0x8200
end_address: 0x14200
placement:
before:
- mcuboot_primary
region: flash_primary
sharers: 0x1
size: 0xc000
EMPTY_0:
address: 0x14200
end_address: 0x18000
placement:
before:
- s1_pad
region: flash_primary
size: 0x3e00
s1:
address: 0x18000
end_address: 0x24200
orig_span: &id008
- s1_pad
- s1_image
region: flash_primary
size: 0xc200
span: *id008
s1_pad:
address: 0x18000
end_address: 0x18200
placement:
after:
- s0
align:
start: 0x4000
region: flash_primary
share_size:
- mcuboot_pad
size: 0x200
s1_image:
address: 0x18200
end_address: 0x24200
placement:
after:
- s1_pad
- s0
region: flash_primary
share_size:
- mcuboot
size: 0xc000
EMPTY_1:
address: 0x24200
end_address: 0x28000
placement:
before:
- mcuboot_pad
region: flash_primary
size: 0x3e00
mcuboot_primary:
address: 0x28000
end_address: 0x94000
orig_span: &id003
- app
- tfm
- mcuboot_pad
region: flash_primary
sharers: 0x1
size: 0x6c000
span: *id003
mcuboot_pad:
address: 0x28000
end_address: 0x28200
placement:
align:
start: 0x4000
before:
- mcuboot_primary_app
region: flash_primary
sharers: 0x2
size: 0x200
mcuboot_primary_app:
address: 0x28200
end_address: 0x94000
orig_span: &id004
- app
- tfm
region: flash_primary
size: 0x6be00
span: *id004
app_image:
address: 0x28200
end_address: 0x94000
orig_span: &id001
- tfm
- app
region: flash_primary
size: 0x6be00
span: *id001
tfm_secure:
address: 0x28000
end_address: 0x54000
orig_span: &id012
- mcuboot_pad
- tfm
region: flash_primary
size: 0x2c000
span: *id012
tfm:
address: 0x28200
end_address: 0x54000
inside:
- mcuboot_primary_app
placement:
before:
- app
region: flash_primary
size: 0x2be00
tfm_nonsecure:
address: 0x54000
end_address: 0x94000
orig_span: &id011
- app
region: flash_primary
size: 0x40000
span: *id011
app:
address: 0x54000
end_address: 0x94000
region: flash_primary
size: 0x40000
mcuboot_secondary:
address: 0x94000
end_address: 0x100000
placement:
after:
- mcuboot_primary
align:
start: 0x4000
align_next: 0x4000
region: flash_primary
share_size:
- mcuboot_primary
size: 0x6c000
mcuboot_sram:
address: 0x20000000
end_address: 0x20020000
orig_span: &id005
- tfm_sram
region: sram_primary
size: 0x20000
span: *id005
sram_secure:
address: 0x20000000
end_address: 0x20020000
orig_span: &id010
- tfm_sram
region: sram_primary
size: 0x20000
span: *id010
tfm_sram:
address: 0x20000000
end_address: 0x20020000
inside:
- sram_secure
placement:
after:
- start
region: sram_primary
size: 0x20000
sram_nonsecure:
address: 0x20020000
end_address: 0x20080000
orig_span: &id009
- sram_primary
- rpmsg_nrf53_sram
region: sram_primary
size: 0x60000
span: *id009
sram_primary:
address: 0x20020000
end_address: 0x20070000
region: sram_primary
size: 0x50000
rpmsg_nrf53_sram:
address: 0x20070000
end_address: 0x20080000
placement:
before:
- end
region: sram_primary
size: 0x10000
Let me explain our problem,
We need crypto operations (SHA HMAC and AES CBC) for authentication and encryption.
We also have DFU enabled, and the main reason why we are facing memory issue is we have wolfSSL lib enabled in our project.
After many reductions in code size and disabling unwanted feature, we are now facing 28KB overflow issue in NS application from wolfSSL enabled.
So, if we can completely remove the 2 EMPTY partitions, this will solve our memory overflow problem permanently.
Please look into this as this is more like blocking for further integrations.
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?
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,
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.