extxip_smp_srv fails compiling for nrf5340dk non-secure target

[franchan]

Hello,

Working on Ubuntu 22.04 with nRF Connect SDK 2.6.1 for the target nrf5340dk_nrf5340_cpuapp_ns (= with TF-M).

My application image became too large. I want to split the app image over internal and external memory. I'm using extxip_smp_svr as example. It compiles & runs for the target nrf5340dk_nrf5340_cpuapp.

When building this sample for the nrf5340dk_nrf5340_cpuapp_ns target (with TF-M), compilation fails:

In file included from /home/dev/nrf-official/v2.6.1/bootloader/mcuboot/boot/zephyr/include/sysflash/sysflash.h:10,
                 from /home/dev/nrf-official/v2.6.1/bootloader/mcuboot/boot/bootutil/src/bootutil_priv.h:33,
                 from /home/dev/nrf-official/v2.6.1/bootloader/mcuboot/boot/bootutil/src/tlv.c:24:
/home/dev/nrf-official/v2.6.1/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h: In function '__flash_area_ids_for_slot':
/home/dev/nrf-official/v2.6.1/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:49:37: error: 'PM_MCUBOOT_PRIMARY_2_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_1_ID'?
   49 | #define FLASH_AREA_IMAGE_2_SLOTS    PM_MCUBOOT_PRIMARY_2_ID, PM_MCUBOOT_SECONDARY_2_ID
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~
/home/dev/nrf-official/v2.6.1/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:59:29: note: in expansion of macro 'FLASH_AREA_IMAGE_2_SLOTS'
   59 |                             FLASH_AREA_IMAGE_2_SLOTS
      |                             ^~~~~~~~~~~~~~~~~~~~~~~~
/home/dev/nrf-official/v2.6.1/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:67:9: note: in expansion of macro 'ALL_AVAILABLE_SLOTS'
   67 |         ALL_AVAILABLE_SLOTS
      |         ^~~~~~~~~~~~~~~~~~~

What do I need to change in this sample to make it compile for the non-secure target?

(PS my current project fails compiling with the same error when trying to add support for a split application image. That's why I looked into Nordic's sample to find how that is configured differently. Unfortunately it fails too. I saw the same error in the past when experimenting with CONFIG_BOOT_UPGRADE_ONLY=n in a multi-image build)

Thank you!

Kind regards,
francis

[franchan]

Hello,

I could solve the error described above by copying the files:
- boards/nrf5340dk_nrf5340_cpuapp.overlay
- boards/nrf5340dk_nrf5340_cpuapp.conf

as
- boards/nrf5340dk_nrf5340_cpuapp_ns.overlay
- boards/nrf5340dk_nrf5340_cpuapp_ns.conf

During linking I now run into this error:
/home/dev/ncs/toolchains/2be090971e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/zephyr_pre0.elf section `bss' will not fit in region `RAM'
/home/dev/ncs/toolchains/2be090971e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: region `RAM' overflowed by 277336 bytes
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Is this due to the static pm_static.yml? Any suggestion on how to fix this?
Do _ns targets (TF-M) really need this amount (270k) of additional RAM (or is this a code segment overwriting the RAM segment by a large amount)?

- I've tried to move the entries from build/partitions.yml (there are new entries related to tfm) into the pm_static.yml. But the error is still the same; the RAM is still overflowed by the same amount of bytes (277336).

- I've checked the bss segment in the zephyr_pre0.elf; only 2831h

  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [32] bss               NOBITS          200029e8 021a38 002831 00  WA  0   0  8

Thank you!

Kind regards,
francis

[Amanda Hsieh]

Hi, 

I suggest that you start by looking at Memory optimization and try to reduce some buffers to see if the error reports a smaller overflow. Please be aware that the nrf5340dk_nrf5340_cpuapp_ns is not listed in the Requirements of the SMP Server with external XIP sample. That means it might not be supported. 

Regards,
Amanda H. 

[franchan]

Hello Amanda,

Thank you. I will reduce a buffer and check if the size of the overflow changed later this weekend.

Meanwhile, do you mean that the technique for splitting is not supported when using non-secure target (TF-M)? Such restriction is not explicitly mentioned in the Requirements though.

I took a diff between the secure and non-secure build's "ninja partition_manager_report". But that does not show anything obviously wrong (just the expected extra 8k regions related to secure RAM):

Kind regards,
francis