Why can't TF-M RAM partition on NRF9151 be smaller than 32KB?

Using:

  • NRF9151
  • TF-M enabled
  • NCS 3.2.2

I'm trying to find more space for my heap on the nrf9151 and I'm disappointed that with a minimal implementation of TF-M I can't get the RAM footprint lower than 32KB. I'm not too fussed about the flash usage.

Docs recommend using CONFIG_PM_PARTITION_SIZE_TFM_SRAM to set the RAM size lower, but it always lands on 32KB. Is this now fixed at a minimum?

I've tried the following as a Kconfig fragment:

CONFIG_TFM_PROFILE_TYPE_MINIMAL=y

CONFIG_PM_PARTITION_SIZE_TFM_SRAM=0x6000

My minimal TF-M build compiles to this:

Memory region Used Size Region Size %age Used
FLASH:          32072 B       64 KB    48.94%
RAM:            14364 B       32 KB    43.84%
[142/146] Generating ../bin/tfm_s.hex

Parents
  • Hi Regan0,

    I found that the root cause is in this line:
    https://github.com/nrfconnect/sdk-nrf/blob/v3.2.3/modules/trusted-firmware-m/Kconfig.tfm.pm#L11

    While using CONFIG_TFM_PROFILE_TYPE_MINIMAL, CONFIG_PM_PARTITION_SIZE_TFM_SRAM doesn't have a prompt and therefore can only use the default value.

    It seems to be the idea is that the minimal profile is provided as is, without any configuration possible.

    The alternative would be to change the SDK file there. Version control of the project might get a little complicated with this approach, because you will need to fork sdk-nrf. Below are some links that will be helpful should you choose this approach.
    Application Development
    Adding your own code

    Hieu

  • Thanks, I'm not prepared to fork sdk-nrf. I've found another way around it if anyone's interested.

    In my pm_static.yml file, I've put:

    # Force TF-M secure SRAM reservation
    # This overrides CONFIG_PM_PARTITION_SIZE_TFM_SRAM defaults from Kconfig.tfm.pm
    # even when TFM minimal profile fixes that symbol to 0x8000.
    tfm_sram:
      address: 0x20000000
      size: 0x6000
      region: sram_primary
     
    This has lowered TF-M RAM allocation to 24KB. I'm still trying to get to grips with TF-M. Currently, TF-M indicates only 10KB of static RAM use at start-up. Is there a way that I can measure a high-water mark for it?  With a minimal implementation, can I get away with only 16KB of RAM set aside?

    It seems ridiculous that of a SoC promoted as having 256KB RAM available, 32KB+ disappears to the mandatory TF-M and 17KB+ disappears to modem libraries immediately. That's >16%
  • You are right. I can't believe I forgot that we can always use pm_static.yml to enforce a fixed memory partitioning.

    Regarding measuring maximum usage and how safe it is to reduce the RAM use, I have started in internal inquiry. I will keep you updated.

  • Hi Regan0,

    Thank you for your patience.

    After discussing with some colleagues, I reached the conclusion that as TF-M, at least in the minimal profile, doesn't use dynamic memory allocation. Therefore, it should not use more RAM than reported in the build log.

    Thus, you can reduce the RAM size. The only concern would be for the memory alignment requirement, which 16kB would satisfy for the nRF9151.

    On another note, a colleague also pointed out that the application can override the Kconfig definition in its own Kconfig file, so that's another alternative to reconfigure TF-M RAM size.

    However, I think using pm_static.yml is the better way, since you will eventually want to have bootloaders and DFU, for which having a static partitioning is highly recommended

Reply
  • Hi Regan0,

    Thank you for your patience.

    After discussing with some colleagues, I reached the conclusion that as TF-M, at least in the minimal profile, doesn't use dynamic memory allocation. Therefore, it should not use more RAM than reported in the build log.

    Thus, you can reduce the RAM size. The only concern would be for the memory alignment requirement, which 16kB would satisfy for the nRF9151.

    On another note, a colleague also pointed out that the application can override the Kconfig definition in its own Kconfig file, so that's another alternative to reconfigure TF-M RAM size.

    However, I think using pm_static.yml is the better way, since you will eventually want to have bootloaders and DFU, for which having a static partitioning is highly recommended

Children
No Data
Related