The nRF Secure Immutable Bootloader fails to start the application with board nrf5340dk_nrf5340_cpuapp_ns

[RnD_Tek]

I'm using the nRF Connect SDK v2.5.1

I copied the the sample "nrf/samples/bluetooth/peripheral_lbs" from the 2.5.1 SDK and created a build configuration using the board "nrf5340dk_nrf5340_cpuapp_ns" and no other changes to the build configuration.

I did a pristine build and flashed it to a nRF5340-DK board (PCA10095 2.0.1) and it responds as expected

*** Booting nRF Connect SDK v2.5.1 ***
Starting Bluetooth Peripheral LBS example
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, fd0
I: data wra: 0, 1c
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF53x (0x0003)
I: Firmware: Standard Bluetooth controller (0x00) Version 197.47763 Build 2370639017
I: No ID address. App must call settings_load()
Bluetooth initialized
I: Identity: E0:F4:2C:C1:70:D4 (random)
I: HCI: version 5.4 (0x0d) revision 0x2102, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x2102
Advertising successfully started

I can connect to the board, read the button and turn on and off the LED.

I then started to follow the instructions from https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.1/nrf/config_and_build/bootloaders_and_dfu/bootloader_adding.html (which appear to be the same as https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/config_and_build/bootloaders/bootloader_adding.html

The only change I made was to the prj.conf file added one line:

CONFIG_SECURE_BOOT=y

and then I perform a pristine build. When I flash this build I get:

*** Booting nRF Connect SDK v2.5.1 ***
Attempting to boot slot 0.
No fw_info struct found.
Attempting to boot slot 1.
No fw_info struct found.
No bootable image found. Aborting boot.

If I redo all of the above but change the board to nrf5340dk_nrf5340_cpuapp when I flash I get:

*** Booting nRF Connect SDK v2.5.1 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8000.
Verifying signature against key 0.
Hash: 0xfc...73
Firmware signature verified.
Firmware version 1
Setting monotonic counter (version: 1, slot: 0)
*** Booting nRF Connect SDK v2.5.1 ***
Starting Bluetooth Peripheral LBS example
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, fe8
I: data wra: 0, 0
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF53x (0x0003)
I: Firmware: Standard Bluetooth controller (0x00) Version 197.47763 Build 2370639017
I: No ID address. App must call settings_load()
Bluetooth initialized
I: Identity: E0:F4:2C:C1:70:D4 (random)
I: HCI: version 5.4 (0x0d) revision 0x2102, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x2102
Advertising successfully started

And I can connect and the application works.

So does the nRF Secure Immutable Bootloader not work with the TFM code and the ARM trustzone?

Thanks!

[Amanda Hsieh]

Hi, 

I would suggest you start with the TF-M: PSA template which uses Trusted Firmware-M, nRF Secure Immutable bootloader, and MCUboot to demonstrate how to implement the best practices that comply with the Arm PSA requirements.

Regards,
Amanda H.

[RnD_Tek]

Thank you for the hint. It might make sense to add a link to the PSA template sample in the Adding a bootloader chain page.

Also I found that the PSA template would not successfully update the application unless the first build of the code included the signing keys. In other words I followed the instructions of the sample, but when I got to the upload of app_update.bin, it updated (showed up in slot 1 when I performed the mcumgr image list. But after image test on the new hash (after which slot 1 had a "pending" flag) the subsequent reset showed the original image was still active (as shown in the output on the devices COM port).

So I erased the flash and started over with the provisioning image and this time, the first build of the tfm_psa_template included the security keys. Then the subsequent build and app_update worked and when reset the updated app was moved to slot 0 and the new application ran as expected.

What I didn't expect was the application to be moved. I assume the bootloader sees that slot 1 has a newer version of application so it moves THAT application to slot 0 then clears something in slot 1 and then starts the application from slot 0. Is that correct?  It would be nice if the sample readme would explain what is going on.

For instance, why did I have to create 2 private keys? Is the mcuboot signed with the nsib_priv.pem key and the application signed by the mcuboot_priv.pem key? Can these be the same? What's the advantage to having 2 different private keys?

I'm still learning how to create secure updatable firmware and I'm struggling with the documentation. For instance when I build the tfm_psa_template I get warnings that make me nervous:

warning: Experimental symbol TFM_EXPERIMENTAL is enabled.

Is that a problem? Will this be ok in production? It's unclear what about the TFM is experimental.

Then there is:

CMake Warning at C:/ncs/v2.5.1/nrf/cmake/partition_manager.cmake:79 (message):


          ---------------------------------------------------------------------
          --- WARNING: Using a bootloader without pm_static.yml.            ---
          --- There are cases where a deployed product can consist of       ---
          --- multiple images, and only a subset of these images can be     ---
          --- upgraded through a firmware update mechanism. In such cases,  ---
          --- the upgradable images must have partitions that are static    ---
          --- and are matching the partition map used by the bootloader     ---
          --- programmed onto the device.                                   ---
          ---------------------------------------------------------------------

I've been looking for an example that tells me how to properly create pm_static.yml. And I'd like to be able to reserve a flash sector for application storage, how do I do that?

I don't expect all of my questions to be answered in this ticket, they are way too broad. But some pointers would be appreciated.