SRAM usage with TF-M profile not set

[Rory]

I'm trying to test out using the protected storage API with TF-M on an nrf5340 based design. I'm on NCS 2.1.0 and I am building the samples/bluetooth/peripheral_uart project for the thingy53 board without any modifications, and all the various subimages build without error.

When I try to enable the config options from the samples/crypto/persistent_key_usage shown below, It seems that I am somehow now overflowing the SRAM usage in the mcuboot subimage by 174920 bytes.

thingy53_nrf5340_cpuapp_ns.conf:

CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y

prj.conf:

# Enable nordic security backend and PSA APIs
CONFIG_NRF_SECURITY=y
CONFIG_MBEDTLS_PSA_CRYPTO_C=y

# Enable persistent storage APIs
CONFIG_MBEDTLS_PSA_CRYPTO_STORAGE_C=y
CONFIG_PSA_NATIVE_ITS=y

CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=8192
CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y

With these added configuration options, it is failing to link the mcuboot build. If I build the samples/crypto/persistent_key_usage for the nrf5340dk, it also will build fine. It seems to be an issue when using CONFIG_TFM_PROFILE_TYPE_NOT_SET=y along with CONFIG_BOOTLOADER_MCUBOOT=y.

FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map C:/ble/nRF53/nrf/samples/bluetooth/peripheral_uart/build/mcuboot/zephyr/zephyr_pre0.map 
cmd.exe /C "cd . && C:\zephyr-sdk-0.15.0\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe   zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr\zephyr_pre0.elf  zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj  -Wl,-T  zephyr/linker_zephyr_pre0.cmd  -Wl,-Map=C:/ble/nRF53/nrf/samples/bluetooth/peripheral_uart/build/mcuboot/zephyr/zephyr_pre0.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/cmse/libarch__arm__core__aarch32__cortex_m__cmse.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/lib/posix/liblib__posix.a  zephyr/boards/boards/arm/thingy53_nrf5340_cpuapp/libboards__arm__thingy53_nrf5340.a  zephyr/drivers/usb/device/libdrivers__usb__device.a  zephyr/drivers/clock_control/libdrivers__clock_control.a  zephyr/drivers/gpio/libdrivers__gpio.a  zephyr/drivers/hwinfo/libdrivers__hwinfo.a  zephyr/drivers/regulator/libdrivers__regulator.a  zephyr/drivers/flash/libdrivers__flash.a  zephyr/drivers/serial/libdrivers__serial.a  zephyr/drivers/timer/libdrivers__timer.a  zephyr/drivers/pinctrl/libdrivers__pinctrl.a  modules/nrf/lib/fprotect/lib..__nrf__lib__fprotect.a  modules/nrf/subsys/pcd/lib..__nrf__subsys__pcd.a  modules/nrf/modules/mcuboot/hooks/lib..__nrf__modules__mcuboot__hooks.a  modules/nrf/drivers/hw_cc310/lib..__nrf__drivers__hw_cc310.a  modules/mcuboot/boot/bootutil/zephyr/libmcuboot_util.a  modules/mbedtls/libmodules__mbedtls.a  modules/hal_nordic/nrfx/libmodules__hal_nordic__nrfx.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  -L"c:/zephyr-sdk-0.15.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/thumb/v8-m.main/nofp"  -LC:/ble/nRF53/nrf/samples/bluetooth/peripheral_uart/build/mcuboot/zephyr  -lgcc  zephyr/arch/common/libisr_tables.a  -no-pie  -mcpu=cortex-m33  -mthumb  -mabi=aapcs  -mfp16-format=ieee  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn  C:/ble/nRF53/nrfxlib/crypto/nrf_cc312_platform/lib/cortex-m33/soft-float/no-interrupts/libnrf_cc312_platform_0.9.15.a && cmd.exe /C "cd /D C:\ble\nRF53\nrf\samples\bluetooth\peripheral_uart\build\mcuboot\zephyr && "C:\Program Files\CMake\bin\cmake.exe" -E echo ""
c:/zephyr-sdk-0.15.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.exe: zephyr\zephyr_pre0.elf section `bss' will not fit in region `SRAM'
c:/zephyr-sdk-0.15.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.exe: region `SRAM' overflowed by 174920 bytes

[Rory]

The partition manager report pasted below looks to be correct according to samples/bluetooth/peripheral_uart/boards/pm_static_thingy53_nrf5340_cpuapp_ns.yml

Maybe I am going about this the wrong way. I am basically trying to merge in the samples/crypto/persistent_key_usage example into to the samples/bluetooth/peripheral_uart example to experiment with the PSA crypto and protectected_storage API running on the nrf5340 with full MCUBoot and external flash.

I've looked through zephyr\samples\tfm_integration\psa_crypto and zephyr\samples\tfm_integration\psa_protected_storage but I can't find any board specific config fragments or DTS overlays for the nrf5430 that look like they would explain this problem. All of the examples I can find that use the PSA API set CONFIG_TFM_PROFILE_TYPE_NOT_SET=y, and are not using MCUBoot.

It is my understanding that the sdk-nrf default CONFIG_TFM_PROFILE_TYPE_MINIMAL is a slimmed down, feature limited version of the TF-M image that only uses 32KB of SRAM. Does this minimal image support the various cryptos and protected_storage?

west build -p auto -b thingy53_nrf5340_cpuapp_ns -d build -t partition_manager_report
...
-- west build: running target partition_manager_report
[1/1] cmd.exe /C "cd /D C:\ble\nRF53\nrf\samples\bluetoot...th/peripheral_uart/build/hci_rpmsg/partitions_CPUNET.yml"
  external_flash (0x800000 - 8192kB):
+------------------------------------------------+
| 0x0: mcuboot_secondary (0xe0000 - 896kB)       |
| 0xe0000: mcuboot_secondary_1 (0x40000 - 256kB) |
| 0x120000: external_flash (0x6e0000 - 7040kB)   |
+------------------------------------------------+

  flash_primary (0x100000 - 1024kB):
+--------------------------------------------------+
| 0x0: mcuboot (0x10000 - 64kB)                    |
+---0x10000: mcuboot_primary (0xe0000 - 896kB)-----+
+---0x10000: tfm_secure (0xc200 - 48kB)------------+
| 0x10000: mcuboot_pad (0x200 - 512B)              |
+---0x10200: mcuboot_primary_app (0xdfe00 - 895kB)-+
| 0x10200: tfm (0xc000 - 48kB)                     |
+---0x1c200: tfm_nonsecure (0xd3e00 - 847kB)-------+
| 0x1c200: app (0xcbe00 - 815kB)                   |
+---0xe8000: tfm_storage (0x8000 - 32kB)-----------+
| 0xe8000: tfm_its (0x2000 - 8kB)                  |
| 0xea000: tfm_otp_nv_counters (0x2000 - 8kB)      |
| 0xec000: tfm_ps (0x4000 - 16kB)                  |
+---0xf0000: nonsecure_storage (0x10000 - 64kB)----+
| 0xf0000: settings_storage (0x10000 - 64kB)       |
+--------------------------------------------------+

  otp (0x2fc - 764B):
+------------------------------+
| 0xff8100: otp (0x2fc - 764B) |
+------------------------------+

  ram_flash (0x40000 - 256kB):
+------------------------------------------+
| 0x0: mcuboot_primary_1 (0x40000 - 256kB) |
| 0x40000: ram_flash (0x0 - 0B)            |
+------------------------------------------+

  sram_primary (0x80000 - 512kB):
+------------------------------------------------+
| 0x20000000: pcd_sram (0x2000 - 8kB)            |
+---0x20002000: sram_secure (0x40000 - 256kB)----+
| 0x20002000: tfm_sram (0x40000 - 256kB)         |
+---0x20042000: sram_nonsecure (0x3e000 - 248kB)-+
| 0x20042000: sram_primary (0x2e000 - 184kB)     |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB)  |
+------------------------------------------------+

 CPUNET flash_primary (0x40000 - 256kB):
+--------------------------------------------+
+---0x1000000: b0n_container (0x8800 - 34kB)-+
| 0x1000000: b0n (0x8600 - 33kB)             |
| 0x1008600: provision (0x200 - 512B)        |
+---0x1008800: app (0x37800 - 222kB)---------+
| 0x1008800: hci_rpmsg (0x37800 - 222kB)     |
+--------------------------------------------+

 CPUNET sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x21000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

[Håkon Alseth]

Hi,

 

Thank you for reporting this behavior back to us!

Digging a bit deeper, I see that the problem is actually related to the way the build system sets the RAM offset for mcuboot.

Instead of providing mcuboot with the start of ram (sram_secure), it is offset with "sram_nonsecure", which is unfortunately not large enough to fully buffer the update image for the network core in RAM. The update image needs to be located in RAM when the mcuboot secondary slot is located on external flash, as the network core does not have direct access to the QSPI peripheral.

 

I have confirmed this behavior, and it has been reported internally back to the developers.

Unfortunately, I do not have a workaround for you at this time.

 

Kind regards,

Håkon

[GiulianoFranchetto]

Hi,

I have the same issue. Has it been addressed by Nordic yet?

[Håkon Alseth]

Hi,

 

This is not yet fixed, unfortunately.

 

Kind regards,

Håkon

[Rocky]

I think I ran into this issue as well. I am trying to use the persistent key storage module to save encryption keys on a nRF5340 in a design that uses mcuboot and external qspi flash for the secondary image. I am getting a RAM overflow linker error when I enable the nonsecure build (CONFIG_BUILD_WITH_TFM).

Is there a workaround or bug report regarding getting secure key storage working on the nRF5340 where the secondary mcuboot image is in qspi external flash?