Configuring pm_static.yml when porting from SPM to TFM

[esisk]

Hello,

I'm working on updating my copy of the nRF Connect SDK from 1.7.0 to 2.4.2. My project runs on an nRF9160 so I had SPM configured for my project and now I need to use TFM instead. To do that, I'm following these instructions: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/security/tfm.html#ug-tfm-migrate. However, I get an error during build configuration from the partition manager saying that there are gaps in my partitions:

Partition manager failed: Incorrect amount of gaps found in static configuration. There must be exactly one gap in the static configuration to support placing the dynamic partitions (such as 'app').
Gaps found (2):0x20000000-0x20010000 0x200144e8-0x20040000 The most common solution to this problem is to fill the smallest of these gaps with statically defined partition(s) until there is only one gap left.
Alternatively re-order the already defined static partitions so that only one gap remains.

I'm not finding any gaps in my file, and I'm changing over the names as instructed. Here's my new pm_static.yml file

app:
  address: 0x1c200
  end_address: 0xfa000
  region: flash_primary
  size: 0xdde00
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  # end_address: 0xc200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x0
mcuboot_primary:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id001
  - tfm
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xf2000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0xfe000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0xf1e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000
nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x200124e8
  end_address: 0x200144e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x200144e8
  orig_span: &id003
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id003
nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x200124e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
tfm:
  address: 0xc000
  end_address: 0x1c200
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x10200
tfm_secure:
  address: 0xc000
  size: 0x10000
  span: [mcuboot_pad, tfm]
tfm_nonsecure:
  address: 0x1c200
  size: 0xdde00
  span: [app]
sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id004
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id004
sram_primary:
  address: 0x200144e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x2bb18
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  orig_span: &id005
  region: sram_primary
  size: 0x10000
  span: *id005
lwm2m_carrier:
  address: 0xfa000
  size: 0x4000
  inside:
  - tfm_nonsecure
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  placement:
    before:
    - end
  region: flash_primary
  inside:
  - tfm_nonsecure
  size: 0x2000

compared to my old one:

app:
  address: 0x1c200
  end_address: 0xfa000
  region: flash_primary
  size: 0xdde00
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id001
  - spm
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xf2000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0xfe000
  orig_span: &id002
  - app
  - spm
  region: flash_primary
  size: 0xf1e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000
nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - spm_sram
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x200124e8
  end_address: 0x200144e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x200144e8
  orig_span: &id003
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id003
nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x200124e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
spm:
  address: 0xc200
  end_address: 0x1c200
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x10000
spm_sram:
  address: 0x20000000
  end_address: 0x20010000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000
sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id004
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id004
sram_primary:
  address: 0x200144e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x2bb18
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  orig_span: &id005
  - spm_sram
  region: sram_primary
  size: 0x10000
  span: *id005
lwm2m_carrier:
  address: 0xfa000
  size: 0x4000
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  placement:
    before:
    - end
  region: flash_primary
  size: 0x2000

Does anyone see anything glaringly wrong or have any tips?

[esisk]

I've gotten the project to build now, but I think that I have the partitions set up incorrectly because I receive this log from MCUBoot:

*** Booting Zephyr OS build v3.3.99-ncs1-2 ***
[00:00:00.474,884] <wrn> mcuboot: Failed reading image headers; Image=0
[00:00:00.474,914] <err> mcuboot: Unable to find bootable image

Here's my updated pm_static.yml file:

app:
  address: 0x1c200
  end_address: 0xfa000
  region: flash_primary
  size: 0xdde00
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id001
  - tfm
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xf2000
  span: *id001
mcuboot_primary_app:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0xf2000
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000
nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x200124e8
  end_address: 0x200144e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x200144e8
  orig_span: &id003
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id003
nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x200124e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
placeholder:
  address: 0xc200
  size: 0x3e00
tfm:
  address: 0x10000
  end_address: 0x18000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x8000
tfm_secure:
  address: 0xc000
  size: 0xc000
  span: [mcuboot_pad, tfm]
tfm_nonsecure:
  address: 0x18000
  end_address: 0xfa000
  size: 0xe2000
  span: [app]
# placeholder2:
#   address: 0x1c000
#   size: 0x200
#   region: flash_primary
sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id004
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id004
sram_primary:
  address: 0x200144e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x2bb18
  inside:
    - sram_nonsecure
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  region: sram_primary
  size: 0x10000
tfm_sram:
  address: 0x20000000
  end_address: 0x20010000
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000
lwm2m_carrier:
  address: 0xfa000
  size: 0x4000
  inside:
  - nonsecure_storage
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  placement:
    before:
    - end
  region: flash_primary
  inside:
  - nonsecure_storage
  size: 0x2000
nonsecure_storage:
  address: 0xfa000
  end_address: 0x100000
  region: flash_primary
  size: 0x6000

And here's the generated partitions.yml

app:
  address: 0x18000
  end_address: 0xfa000
  region: flash_primary
  size: 0xe2000
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
lwm2m_carrier:
  address: 0xfa000
  end_address: 0xfe000
  inside:
  - nonsecure_storage
  region: flash_primary
  size: 0x4000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id001
  - tfm
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xf2000
  span: *id001
mcuboot_primary_app:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0xf2000
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000
nonsecure_storage:
  address: 0xfa000
  end_address: 0x100000
  region: flash_primary
  size: 0x6000
nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x200124e8
  end_address: 0x200144e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x200144e8
  orig_span: &id003
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id003
nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x200124e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
placeholder:
  address: 0xc200
  end_address: 0x10000
  region: flash_primary
  size: 0x3e00
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  inside:
  - nonsecure_storage
  placement:
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id004
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id004
sram_primary:
  address: 0x200144e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x2bb18
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  region: sram_primary
  size: 0x10000
tfm:
  address: 0x10000
  end_address: 0x18000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x8000
tfm_nonsecure:
  address: 0x18000
  end_address: 0xfa000
  region: flash_primary
  size: 0xe2000
  span:
  - app
tfm_secure:
  address: 0xc000
  end_address: 0x18000
  region: flash_primary
  size: 0xc000
  span:
  - mcuboot_pad
  - tfm
tfm_sram:
  address: 0x20000000
  end_address: 0x20010000
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000

There's some discrepancy between the addresses but not sure why that would be?

[Hieu]

Hi esisk,

Does this mean that you have resolved the original "Incorrect amount of gaps found in static configuration" issue?

Could you please try compiling without pm_static.yml, test, and share with us the result and the generated partitions.yml file?

When you mention updating your copy of NCS from 1.7.1 to 2.4.2, what do you mean? Did you checkout a new west manifest and run west update, or did you install a new copy of the SDK?

Hieu

[esisk]

/home/ethan/build_keys/cell_priv.pemYes I followed the instructions for command line installation found here https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/installation/install_ncs.html. I did not update my old version of the SDK, just made a completely new copy and checked out v2.4.2 from GitHub. Is there a PR on GitHub where I can reference the partition manager fix you mentioned? Maybe I could try to patch my issue locally based on that

Thanks for confirming that the application address offset must be the same. I tried to simplify pm_static.yml as much as possible and got:

mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_primary: # mcuboot primary contains the updatable apps (tfm and main app) and mcuboot pad
  address: 0xc000
  end_address: 0xfa000
  span: [tfm, mcuboot_pad, app]
  region: flash_primary
  size: 0xf2000
mcuboot_primary_app: # mcuboot primary contains the updatable apps (tfm and main app)
  address: 0xc200
  end_address: 0xfa000
  span: [tfm, app]
  region: flash_primary
  size: 0xf1e00
tfm_nonsecure:
  address: 0x1c200
  end_address: 0xfa000
  span: [app]
  region: flash_primary
  size: 0xdde00
tfm_secure:
  address: 0xc000
  end_address: 0x1c200
  span: [mcuboot_pad, tfm]
  region: flash_primary
  size: 0x10200
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  region: flash_primary
  size: 0x200
tfm:
  address: 0xc200
  size: 0x10000
  region: flash_primary
app:
  address: 0x1c200
  end_address: 0xfa000
  region: flash_primary
  size: 0xdde00
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000

I received an error while building saying:

!!!Partition alignment error!!!
The non-secure start address in pm_static.yml or generated partition.yml is: 0x1c200
which is not aligned with the SPU region size.
Refer to the documentation section 'TF-M partition alignment requirements'
for more information.

   '
   16 | #pragma message "\n\n!!!Partition alignment error!!!"\
      |         ^~~~~~~
/home/ethan/ncs/nrf/modules/tfm/tfm/boards/common/assert.c:22:2: error: #error "TF-M non-secure start address is not aligned on SPU region size"
   22 | #error "TF-M non-secure start address is not aligned on SPU region size"

Is configuring this impossible? I've tried a few different set ups where the non-secure region is aligned with the SPU region size and my project will build. However, MCUBoot will run and print out something like

*** Booting Zephyr OS build v3.3.99-ncs1-2 ***
[00:00:00.494,262] <inf> mcuboot: Starting bootloader
[00:00:00.494,903] <wrn> mcuboot: Cannot upgrade: not a compatible amount of sectors
[00:00:00.535,491] <err> mcuboot: Image in the primary slot is not valid!
[00:00:00.535,522] <err> mcuboot: Unable to find bootable image

Thanks for looking into this Hieu

Edit:

I believe I've gotten pm_static.yml into a state that satisfies my requirements as well as the build system's: my app is in the same address as what's in the field and T-FM is aligned correctly. I'd appreciate you confirming that there shouldn't be any problems with this set up based on the original pm_static.yml file I shared in my original post.

mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_primary: # mcuboot primary contains the updatable apps (tfm and main app) and mcuboot pad
  address: 0xc000
  end_address: 0xfa000
  span: [tfm, mcuboot_pad, app]
  region: flash_primary
  size: 0xf2000
mcuboot_primary_app: # mcuboot primary contains the updatable apps (tfm and main app)
  address: 0xc200
  end_address: 0xfa000
  span: [tfm, app]
  region: flash_primary
  size: 0xf1e00
tfm_nonsecure:
  address: 0x18000
  end_address: 0xfa000
  span: [app]
  region: flash_primary
  size: 0xe2000
tfm_secure:
  address: 0xc000
  end_address: 0x18000
  span: [mcuboot_pad, tfm]
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  region: flash_primary
  size: 0x200
tfm:
  address: 0xc200
  end_address: 0x18000
  size: 0xbe00
  region: flash_primary
app:
  address: 0x1c200
  end_address: 0xfa000
  region: flash_primary
  size: 0xdde00
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000

My project builds. When running I get output from MCUBoot which seems like it's functioning correctly, but my application never boots. Here's the log output:

[00:00:00.518,890] <inf> mcuboot: Starting bootloader
[00:00:00.519,622] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.519,958] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.519,958] <inf> mcuboot: Boot source: none
[00:00:00.520,385] <inf> mcuboot: Swap type: none

Any insights as to what could be wrong? Also, is there a way to route T-FM logs via RTT? It'd be great to see if MCUBoot is booting into T-FM and there's some error there.

Edit 2:

After more debugging, I've found that MCUBoot is getting hung in the function boot_validate_slot in the file loader.c. This leads me to believe that MCUBoot cannot validate the images that are programmed in flash on my board. I looked in autoconf.h and found:

#define CONFIG_TFM_KEY_FILE_S "/home/ethan/ncs/modules/tee/tf-m/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem"
#define CONFIG_TFM_KEY_FILE_NS "/home/ethan/ncs/modules/tee/tf-m/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072_1.pem"

which is different than the path of my actual signing key which is /home/ethan/build_keys/cell_priv.pem. I made sure that I set:

CONFIG_TFM_KEY_FILE_S="/home/ethan/build_keys/cell_priv.pem"
CONFIG_TFM_KEY_FILE_NS="/home/ethan/build_keys/cell_priv.pem"

in my application prj.conf and setting:

CONFIG_BOOT_SIGNATURE_KEY_FILE="/home/ethan/build_keys/cell_priv.pem"

in child_images/mcuboot/prj.conf

However after making those changes, the application still isn't running. Any thoughts after these findings?

Edit 3:

Found a function where there are no more function calls and MCUBoot is getting stuck:

/*
 * Check that a memory area consists of a given value.
 */
static inline bool
boot_data_is_set_to(uint8_t val, void *data, size_t len)
{
    uint8_t i;
    uint8_t *p = (uint8_t *)data;
    for (i = 0; i < len; i++) {
        BOOT_LOG_ERR("boot_data_is_set_to i: %u, p: %p val: %u", i, p, val);
        if (val != p[i]) {
            BOOT_LOG_ERR("false");
            return false;
        }
    }
    BOOT_LOG_ERR("done");
    return true;
}

In the console, "false" is getting printed so I know that the function should return it just doesn't. Which makes me realize that I had to reduce CONFIG_MAIN_STACK_SIZE to 5000 in order to build the project with logging, so the stack must have overflowed at some point. However, setting it back to CONFIG_MAIN_STACK_SIZE=10240 overflows the RAM allocated for MCUBoot by 600ish bytes when building. Setting the stack size to anything lower than 10240 results in my app not running and I can't build the project now with the original stack size.

I'm assuming because more features/code have been added to MCUBoot since my previous SDK version. Could you give me guidance as to where I should go from here? I'm thinking of defining RAM partitions in my pm_static.yml that are the same as I had in my original pm_static.yml. I'm leaving work for today but would appreciate any feedback you have regarding this.

[Hieu]

Hi esisk,

It seems you have made lots of progress. That's great.

Regarding the partition configuration, if you still have concern, can you share the partition manager report from the original 1.7.1 setup and the current setup? It helps make it easier to check if everything is correct.

esisk said:

In the console, "false" is getting printed so I know that the function should return it just doesn't. Which makes me realize that I had to reduce CONFIG_MAIN_STACK_SIZE to 5000 in order to build the project with logging, so the stack must have overflowed at some point. However, setting it back to CONFIG_MAIN_STACK_SIZE=10240 overflows the RAM allocated for MCUBoot by 600ish bytes when building. Setting the stack size to anything lower than 10240 results in my app not running and I can't build the project now with the original stack size.

In a setting with secure domain, MCUboot is limited to the secure RAM region. If the logging is only for debugging, you can use CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM to help give it more RAM to work. Once we figure out the issue, CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM can be disabled again.

[esisk]

After doing some further debugging, it seems that available RAM is not the issue. I've now tracked the stall down to bootutil_img_hash called in bootutil_img_validate. Maybe there is something that's changed in terms of MCUBoot performing crypto calls in NCS 2.x.x. Also, did the public key used to verify images change when the SDK was updated, or do I need to somehow link the public key to the private signing key that I'm using when re-installing the SDK? I'll include all my configuration files for clarity.

curr_cfg.zip

Edit:

Tried building with the default signing key provided with the SDK and I run into the same stall, so the key is most likely not the issue.

Edit 2:

Interesting find... I programmed the board using the configuration setup included in the zip file I attached here and ran into the same stall. However, if I do a pin reset of the board, I see that my application starts up just fine. Any ideas as to why that could be?

Edit 3:

After doing more debugging, I discovered that for some reason, logging stopped working after a bit in MCUBoot. So the program was never actually getting stuck. I just replaced calls to BOOT_LOG_INF with printf and I got more info:

00> Here[00:00:00.489,593] <inf> mcuboot: Starting bootloader
00> [00:00:00.490,325] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> [00:00:00.490,661] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> [00:00:00.490,661] <inf> mcuboot: Boot source: none
00> [00:00:00.491,149] <inf> mcuboot: Swap type: none
00> here12here14Bootloader chainload address offset: 0xc000Jumping to the first image slot

MCUBoot is attempting to boot into the image. However, I'm still seeing nothing being logged by my application. That leads me to believe that either the address it's booting into is incorrect or TFM is getting stuck. The address it's booting into is 0xc000 which corresponds to mcuboot_pad as outlined in my pm_static.yml. Shouldn't it be using 0xc200 as the address? And is there a way to log TFM output via RTT?

[Hieu]

The public key is regenerated from the private key whenever you build the application. However, that should not be an issue as long as the private key remain the same.

esisk said:

MCUBoot is attempting to boot into the image. However, I'm still seeing nothing being logged by my application. That leads me to believe that either the address it's booting into is incorrect or TFM is getting stuck. The address it's booting into is 0xc000 which corresponds to mcuboot_pad as outlined in my pm_static.yml. Shouldn't it be using 0xc200 as the address? And is there a way to log TFM output via RTT?

This is good progress. Given your finding, I agree with your conclusion.

Adding logging from TF-M is possible, but only via UART. Please refer to this page: Running applications with Trusted Firmware-M (nordicsemi.com).

I think it might be worth it to try this with a very minimal setup. Perhaps use the Hello World sample, and adding just MCUboot, the MCUboot relevant Kconfig, and the current pm_static.yml. If this setup works, then it would indicate the issue is with the application.

Following a similar logic, please also try compiling the application without MCUboot to see if it has any issue running.

[esisk]

Hieu said:

The public key is regenerated from the private key whenever you build the application. However, that should not be an issue as long as the private key remain the same.

Good to know, I won't consider this as a possible problem.

Hieu said:

I think it might be worth it to try this with a very minimal setup. Perhaps use the Hello World sample, and adding just MCUboot, the MCUboot relevant Kconfig, and the current pm_static.yml. If this setup works, then it would indicate the issue is with the application.

I've already made it to where my application is just an infinite while loop printing "Here" every 5 seconds once entering into main, so I doubt it'd be my application. But I will try a minimal setup with an out of the box sample and see if that works. I will also try running both my app and a sample app without MCUBoot. I'll work on this today and update you on my progress

[esisk]

Hey Hieu,

Sorry for the delay, I've gotten sidetracked with other priorities. I just tried running my app without MCUBoot, and I'm not seeing anything being printed to the console. The app is an infinite while loop that prints "Hello World" every five seconds. I will try to build the application without TFM as well and see how that affects it.

Edit 1:

When trying to build a the hello_world sample from zephyr/samples, I get this error:

/home/ethan/fw-dev/v2.4.2/nrf/lib/nrf_modem_lib/nrf_modem_lib.c:17:10: fatal error: pm_config.h: No such file or directory
   17 | #include <pm_config.h>

Any ideas on how to fix this? I'm trying to just run something with only tfm and an app that prints hello world to the console with nothing else configured.

Edit 2:

When looking at some samples I see this config variable CONFIG_TFM_BL2, could you explain more what this does?

[Hieu]

Hi esisk,

Sorry for the delay from me too. We had a high-loading period, and I am still recovering from it.

esisk said:

Edit 1:

When trying to build a the hello_world sample from zephyr/samples, I get this error:

Are you building a secure target (without _ns)?

esisk said:

Edit 2:

When looking at some samples I see this config variable CONFIG_TFM_BL2, could you explain more what this does?

TFM has a two-stage bootloader solution. However, that is not supported in NCS.

[esisk]

Hey Hieu,

Sorry for the delayed response, this is a side quest that I'm working on alongside other priorities. Something interesting to note, I finally got the project to build and run by disabling MCUBoot in the build. I have TFM enabled and my program is just printing Hello World. So the problem must lie with MCUBoot or how I've configured it. I will try building without a pm_static.yml file and see how that goes. Any other suggestions you could provide would be helpful.

Edit 1: My current hunch is that the regulator powering my external flash is not getting initialized correctly. MCUBoot needs to be able to access the external flash in order to determine which image to boot into. I think this is the issue because my app is hanging whenever I am initializing the application NVS file systems on the external flash, so I figure that the same thing would happen in MCUBoot. I'm able to get the regulator device handle correctly and call regulator_enable by passing in the handle, but this doesn't seem to be doing anything because trying to get the external flash device handle results in NULL. Has anything changed in how the regulator is powered upon boot or how to get the external flash device handle? The overlay that I sent in the zip folder above works fine in my project built with NCS 1.7.0

Edit 2: I have further confirmed the problem seems to be with MCUBoot. I built my hello world application with NCS 2.4.2 and sent an update to a device running an MCUBoot, SPM, and an application all built with NCS 1.7.0. The update was successful. So that implies to me that MCUBoot is the issue since the MCUBoot on the updated device is the same version that was on it previously

[Hieu]

Hi Ethan,

I also apologize for the late response. I have been out of office.

To rule out the external flash initialization issue, could you please configure your setup to work without external flash and see if the issue can still be reproduced?

Also, are you working on a custom board? If so, may I know what external flash device you are using, and what the configuration is?

Hieu