• State Not Answered
  • Replies 8 replies
  • Subscribers 65 subscribers
  • Views 293 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328856
Options

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

Parents
  • 0

    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

  • 0 in reply to franchan

    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. 

  • 0 in reply to Amanda Hsieh

    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

  • 0 in reply to Amanda Hsieh

    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
Reply
  • 0 in reply to Amanda Hsieh

    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
Children
  • 0 in reply to franchan

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

  • 0 in reply to Amanda Hsieh

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

    Kind regards,
    francis

  • 0 in reply to franchan

    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.

  • 0 in reply to Amanda Hsieh

    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
Related