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 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.

Fullscreen 6607.pm_static.txt Download

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.

[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.