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. 

[Amanda Hsieh]

Good to hear that. 

[franchan]

Hello Amanda,

Should I open a new ticket with a question regarding the "Unable to find bootable image"?

Thank you. Kind regards,
francis

[Amanda Hsieh]

No. I am looking into it. 

[Amanda Hsieh]

Are you still using pm_static.yml with removed RAM section or all generated?

[franchan]

Hello Amanda,

Sorry for coming back late ...

You are right, there is the original pm_static.yml that is reused for the "ns" target.
If I move that aside, and thereby fall-back on the generated build/partition.yml, the build fails (I guess you're seeing this as well).
At first eye-sight there are considerable differences between the resulting build/partition.yml and that original pm_static.yml for the "ns" target case.
Until now, I've not changed this pm_static.yml (e.g. removed the RAM section). I only added CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y to boards/nrf5340dk_nrf5340_cpuapp_ns.conf.

1. I try to see if I can make sense out of these two files and reconcile these.

2. I would assume that the generated build/partition.yml should not make the build fail. Might this be an issue internal to the NCS and require an internal ticket?

Kind regards,
francis