extxip_smp_srv fails compiling for nrf5340dk non-secure target

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Sun, 04 Aug 2024 15:00:23 GMT

Hello Amanda,

I looked further into my issue.

Added logging in the MCUBoot shows the bootloader fails in boot_validate_slot() (and reports this in context_boot_go()).

The memory map with west build -t partition_manager_report -d build looks fine (see earlier message).

However looking into the GENERATED_CP_APPLICATION_merged_domains.hex image with the programmer v4.4.0 the image header section seems missing (the section which should go into 0x10000: mcuboot_pad (0x200 - 512B)).

The next section, after the MCUBoot loader section, starts at address 0x0001.0200 (which is: 0x10200: mcuboot_primary_app (0xdfe00 - 895kB) also named 0x10200: tfm (0xfe00 - 63kB)). There's nothing flashed at 0x10000 according to the image.

I assume this is the reason that the bootloader does not find a bootable image? Do you see the same? Are your colleagues back from holiday season?

PS for building the NS variant, I also added these lines to prj.conf:
CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_MINIMAL=y

Thanks

Kind regrards,
francis

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Mon, 29 Jul 2024 09:55:30 GMT

Hello Amanda,

I've tried to reconcile the pm_static.yml (the one included in the sample) with the build/partiontion.yml (after compiling for non-secure). Here is that new version:

###
### Ext. flash
###

# The app update image
mcuboot_secondary:
  address: 0x0
  device: MX25R64   # Is this better: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xe0000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xe0000    # TODO check size mcuboot_primary

# The network update image
mcuboot_secondary_1:
  address: 0xe0000
  device: MX25R64 # Is this better: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x120000
  region: external_flash
  size: 0x40000

# Since verything is aligned, do see the purpose of this EMPTY_1 partition
# EMPTY_1:
#   address: 0x114000
#   device: MX25R64
#   end_address: 0x120000
#   region: external_flash
#   size: 0xc000

mcuboot_primary_2:      # for app part running in ext. flash
  address: 0x120000
  device: MX25R64
  end_address: 0x160000
  region: external_flash
  size: 0x40000

mcuboot_secondary_2:    # for the app part in ext. flash update
  address: 0x160000
  device: MX25R64
  end_address: 0x1a0000
  region: external_flash
  size: 0x40000

external_flash:
  address: 0x1a0000
  device: MX25R64
  end_address: 0x800000
  region: external_flash
  size: 0x660000


###
### Int. flash (primary)
###

# The bootloader
mcuboot:
  address: 0x0
  end_address: 0x10000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x10000

# Everything except the bootloader & settings storage space
mcuboot_primary:
  address: 0x10000
  end_address: 0xf0000
  orig_span: &id001
  - mcuboot_pad
  - tfm
  - app
  region: flash_primary
  size: 0xe0000
  span: *id001

tfm_secure:
  address: 0x10000
  end_address: 0x20000
  orig_span: &id007
  - mcuboot_pad
  - tfm
  region: flash_primary
  size: 0x10000
  span: *id007

mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    align:
      start: 0x4000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200

mcuboot_primary_app:
  address: 0x10200
  end_address: 0xf0000
  orig_span: &id002
  - tfm
  - app
  region: flash_primary
  size: 0xdfe00
  span: *id002

tfm:
  address: 0x10200
  end_address: 0x20000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0xfe00
  
tfm_nonsecure:
  address: 0x20000
  end_address: 0xf0000
  orig_span: &id006
  - app
  region: flash_primary
  size: 0xd0000
  span: *id006

app:
  address: 0x20000
  end_address: 0xf0000   # in NCS doc ex. this does not complete uses all space (until 0xe4000)
  region: flash_primary
  size: 0xd0000

settings_storage:
  address: 0xf0000
  end_address: 0x100000
  region: flash_primary
  size: 0x10000


###
### OTP
###

otp:
  address: 0xff8100
  end_address: 0xff83fc
  region: otp
  size: 0x2fc


###
### RAM flash
###

ram_flash:
  address: 0x40000
  end_address: 0x40000
  region: ram_flash
  size: 0x0

mcuboot_primary_1:    # for the network core update
  address: 0x0
  device: nordic_ram_flash_controller
  end_address: 0x40000
  region: ram_flash
  size: 0x40000


###
### SRAM
###

mcuboot_sram:
  address: 0x20000000
  end_address: 0x20080000
  orig_span: &id003
  - pcd_sram
  - tfm_sram
  - sram_primary
  - rpmsg_nrf53_sram
  region: sram_primary
  size: 0x80000
  span: *id003

sram_secure:
  address: 0x20000000
  end_address: 0x2000a000
  orig_span: &id005
  - pcd_sram
  - tfm_sram
  region: sram_primary
  size: 0xa000
  span: *id005
pcd_sram:
  address: 0x20000000
  end_address: 0x20002000
  placement:
    before:
    - tfm_sram
  region: sram_primary
  size: 0x2000
tfm_sram:
  address: 0x20002000
  end_address: 0x2000a000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x8000

sram_nonsecure:
  address: 0x2000a000
  end_address: 0x20080000
  orig_span: &id004
  - sram_primary
  - rpmsg_nrf53_sram
  region: sram_primary
  size: 0x76000
  span: *id004
sram_primary:
  address: 0x2000a000
  end_address: 0x20070000
  region: sram_primary
  size: 0x66000
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000

The linker_arm_extxip.ld is not changed as the offset in ext. flash did not change. The resulting memory report:

  external_flash (0x800000 - 8192kB): 
+-------------------------------------------------+
| 0x0: mcuboot_secondary (0xe0000 - 896kB)        |
| 0xe0000: mcuboot_secondary_1 (0x40000 - 256kB)  |
| 0x120000: mcuboot_primary_2 (0x40000 - 256kB)   |
| 0x160000: mcuboot_secondary_2 (0x40000 - 256kB) |
| 0x1a0000: external_flash (0x660000 - 6528kB)    |
+-------------------------------------------------+

  flash_primary (0x100000 - 1024kB): 
+--------------------------------------------------+
| 0x0: mcuboot (0x10000 - 64kB)                    |
+---0x10000: mcuboot_primary (0xe0000 - 896kB)-----+
+---0x10000: tfm_secure (0x10000 - 64kB)-----------+
| 0x10000: mcuboot_pad (0x200 - 512B)              |
+---0x10200: mcuboot_primary_app (0xdfe00 - 895kB)-+
| 0x10200: tfm (0xfe00 - 63kB)                     |
+---0x20000: tfm_nonsecure (0xd0000 - 832kB)-------+
| 0x20000: app (0xd0000 - 832kB)                   |
+--------------------------------------------------+
| 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: mcuboot_sram (0x80000 - 512kB)---+
+---0x20000000: sram_secure (0xa000 - 40kB)------+
| 0x20000000: pcd_sram (0x2000 - 8kB)            |
| 0x20002000: tfm_sram (0x8000 - 32kB)           |
+---0x2000a000: sram_nonsecure (0x76000 - 472kB)-+
| 0x2000a000: sram_primary (0x66000 - 408kB)     |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB)  |
+------------------------------------------------+

 CPUNET flash_primary (0x40000 - 256kB): 
+--------------------------------------------+
+---0x1000000: b0n_container (0x8800 - 34kB)-+
| 0x1000000: b0n (0x8580 - 33kB)             |
| 0x1008580: provision (0x280 - 640B)        |
+---0x1008800: app (0x37800 - 222kB)---------+
| 0x1008800: hci_ipc (0x37800 - 222kB)       |
+--------------------------------------------+

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

Unfortunately I still end up with the mcuboot error:

*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
I: MCUBOOT main!
I: Starting bootloader ...
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
I: Image index: 2, Swap type: none
E: Unable to find bootable image

Could you have a look what might be wrongly configured? Thank you.

For bothe the secure and non-secure variants, I have a question on the app image that goes on the external flash. Is this the qspi_flash.hex? When I open this with the desktop programmer, it only shows 9232 bytes while the pm_static.yml seems to reserve 256k. Is there something wrong? (the programmer is showing the correct address 0x1012.0200)

Kind regards,
francis

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Sat, 27 Jul 2024 10:10:44 GMT

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

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

Amanda Hsieh — Thu, 25 Jul 2024 15:42:33 GMT

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

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

Amanda Hsieh — Tue, 23 Jul 2024 19:15:52 GMT

No. I am looking into it.

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Tue, 23 Jul 2024 18:34:11 GMT

Hello Amanda,

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

Thank you. Kind regards,
francis

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

Amanda Hsieh — Tue, 23 Jul 2024 16:53:00 GMT

Good to hear that.

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Sat, 20 Jul 2024 11:51:19 GMT

Hello Amanda,

I got one step further making compilation now succeed. I added to boards/nrf5340dk_nrf5340_cpuapp_ns.conf:
CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y

However after flashing, I see an error message from the MCUBOOT:
*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
I: Starting bootloader
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
I: Image index: 2, Swap type: none
E: Unable to find bootable image

As a reference, when compiling without TF-M, I see the following:
I: Starting bootloader
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
I: Image index: 2, Swap type: none
I: Bootloader chainload address offset: 0x10000
*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***

uart:~$ [00:00:00.017,639] <inf> smp_sample: build time: Jul 20 2024 13:43:51
[00:00:00.029,449] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.029,449] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.029,479] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 54.58864 Build 1214809870
[00:00:00.031,066] <inf> bt_hci_core: Identity: E2:F6:D5:70:CD:18 (random)
[00:00:00.031,097] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x218f, manufacturer 0x0059
[00:00:00.031,127] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x218f
[00:00:00.033,020] <inf> smp_bt_sample: Advertising successfully started
[00:00:00.017,639] <inf> smp_sample: build time: Jul 20 2024 13:43:51
[00:00:00.029,449] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.029,449] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.029,479] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 54.58864 Build 1214809870
[00:00:00.031,066] <inf> bt_hci_core: Identity: E2:F6:D5:70:CD:18 (random)
[00:00:00.031,097] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x218f, manufacturer 0x0059
[00:00:00.031,127] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x218f
[00:00:00.033,020] <inf> smp_bt_sample: Advertising successfully started

Kind regards,
francis

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

Amanda Hsieh — Mon, 08 Jul 2024 13:25:02 GMT

We are currently understaffed due to the summer vacation period, so delayed replies must be expected. I am sorry about any inconvenience this might cause.

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Sun, 07 Jul 2024 14:43:56 GMT

Hello Amanda,
Did you or a colleague have time to further investigate this issue? Thank you!

Kind regards,
francis

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

Amanda Hsieh — Wed, 26 Jun 2024 14:30:59 GMT

Let me check with the team and back to you when I collect enough information.

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Sun, 23 Jun 2024 10:44:19 GMT

Hello Amanda,

I have found a possible cause but dont know a workaround. Maybe you know or can ask an engineer?
The prj.conf is kept as is. Only the boards/nrf5340dk_nrf5340_cpuapp.conf and boards/nrf5340dk_nrf5340_cpuapp.overlay were duplicated in order to create a non-secure (with TF-M) target (as described above).

There is a difference in the generated linker script when building for secure compared and non-secure which explains the overflow (here's the diff):
diff build/mcuboot/zephyr/linker_zephyr_pre0.cmd build_1/mcuboot/zephyr/linker_zephyr_pre0.cmd
2c2
< _region_min_align = 32;
---
> _region_min_align = 4;
6c6
<     RAM (wx) : ORIGIN = 0x20002000, LENGTH = 0x6e000
---
>     RAM (wx) : ORIGIN = 0x20002000, LENGTH = 0x8000
234c234
<     __kernel_ram_end = 0x20002000 + 0x6e000;
---
>     __kernel_ram_end = 0x20002000 + 0x8000;

Build_1, for the nrf5340dk_nrf5340_cpuapp_ns has a much smaller RAM size. Further from the map file (build_1/mcuboot/zephyr/zephyr_pre0.map) the overflowing with 277336 bytes can be explained:

0x0000000020002000 _image_ram_start = .

... [ removed lines related to .bss and .noinit ] ...

0x000000002004db58 _image_ram_end = .

0x000000000004bb58 _image_ram_size = (_image_ram_end - _image_ram_start)

Substracting from this, the RAM size foreseen by the linker script (0x8000):
277336d = 0x46658 = 0x4bb58 - 0x8000

(Might it be related to the flash simulator?)

Apart from the wrong size, I'm also worried about the _region_min_align difference. When compiling for non-secure it is set to only "4". While the default Nordic sample has set this to 32. Can you find some clarification for this difference as well?

Kind regards,

francis

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Fri, 21 Jun 2024 21:04:12 GMT

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

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

Amanda Hsieh — Fri, 21 Jun 2024 19:59:27 GMT

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.

RE: extxip_smp_srv fails compiling for nrf5340dk non-secure target

franchan — Fri, 21 Jun 2024 10:14:36 GMT

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