Adding the nRF Secure Bootloader in custom board with nRF5340

[tgoos]

Hi all,

I'm developing a project on top of nRF5340. Thus I created a custom board definition in my project area:

boards/arm/demo_board/
├── board.cmake
├── CMakeLists.txt
├── demo_board_cpuapp_defconfig
├── demo_board_cpuapp.dts
├── demo_board_cpuapp_ns_defconfig
├── demo_board_cpuapp_ns.dts
├── demo_board_cpuapp_ns.yaml
├── demo_board_cpuapp.yaml
├── demo_board_cpunet_defconfig
├── demo_board_cpunet.dts
├── demo_board_cpunet-pinctrl.dtsi
├── demo_board_cpunet.yaml
├── Kconfig
├── Kconfig.board
├── Kconfig.defconfig
├── nrf5340_cpuapp_common.dts
├── nrf5340_cpuapp_common-pinctrl.dtsi
├── nrf5340_cpuapp_partition_conf.dts
├── nrf5340_cpunet_reset.c
├── nrf5340_shared_sram_planning_conf.dts
└── pre_dt_board.cmake

That is a direct copy of ncs/zephyr/boards/arm/nrf5340dk_nrf5340/ -folder. Just renamed case sensitively all instances of "nrf5340dk_nrf5340" to "demo_board" to get a starting point for my custom HW definition.

west build -b demo_board_cpuapp_ns

builds nicely and seems to output correct logging in the nRF5340DK environment.

It also seems that I am able to add the MCUboot in the system (CONFIG_BOOTLOADER_MCUBOOT=y), but the problems arise, when I try adding the nRF Secure Bootloader (CONFIG_SECURE_BOOT=y).

Still everything is ok, when building for the nrf5340dk_nrf5340_cpuapp_ns target, but the west build -b demo_board_cpuapp_ns results in a compilation error:

ncs/zephyr/include/zephyr/arch/arm/aarch32/misc.h:26: undefined reference to `sys_clock_cycle_get_32'

I don't understand why this happens. The board definition is an exact copy of the devkit board definition. Just renamed and replaced under the project folder and before adding the secure nRF bootloader everything has been working fine.

I compared the build folders of the successful and failure builds and noticed differences (other than renaming) in the build/b0/zephyr/include/generated/autoconf.h file. The failed version had these additional lines that are missing from the successful build:

#define CONFIG_HW_CC3XX 1
#define CONFIG_NRF_CC3XX_PLATFORM 1
#define CONFIG_CC3XX_MUTEX_LOCK 1

I don't know if these have anything to do with my problem. But it also seems that I'm not able to undefine those. They are still there after build folder delete and:

west build -b demo_board_cpuapp_ns -d build_demo -- -Db0CONFIG_HW_CC3XX=n -Db0CONFIG_NRF_CC3XX_PLATFORM=n -Db0CONFIG_CC3XX_MUTEX_LOCK=n

My environment:

    Ubuntu 22.04.2 LTS

    Zephyr version: 3.2.99

    zephyr-sdk-0.15.2

    nRF Connect SDK: 2.3.0

Any ideas what I'm missing in the custom board definition or Secure Bootloader addition?

[Hieu]

Hi tgoos,

Unfortunately, the two-stage bootloader solution doesn't work on the nRF5340 at the moment.

I am however a little concern about your custom board setup. Do you have the exact same error messages when compiling for a normal nrf5340dk_nrf5340_cpuapp_ns board?
If you don't, that is a sign of an underlying issue.

Hieu

[tgoos]

Hi Hieu,

Thanks for your fast response.

Compiling for nrf5340dk_nrf5340_cpuapp_ns does not cause any errors. I'm able to build and the log from the devkit shows successful two-stage boot:

*** Booting Zephyr OS build v3.2.99-ncs2 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Verifying signature against key 0.
Hash: 0xa3...f1
Firmware signature verified.
Firmware version 1
Setting monotonic counter (version: 1, slot: 0)
*** Booting Zephyr OS build v3.2.99-ncs2 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0x28000
*** Booting Zephyr OS build v3.2.99-ncs2 ***
[00:00:00.000,427] <inf> MAIN: built for nrf5340dk_nrf5340_cpuapp!

Here both Secure Bootloader & MCUboot are enabled.

I have checked and double checked the differences between the board configuration folders, but there still might be some illegal configurations. I have more experience with the old nRF SDK and I'm new to the Zephyr & nRF Connect SDK environment.

[Hieu]

Hi tgoos,

While the two-stage bootloader can build and boot successfully, it won't be able to perform MCUboot DFU. This is what I meant by the setup not working.

The fact that your custom board and the nrf5340dk_nrf5340_cpu.* builds differently is not good. As you have just begun to create it and everything still have a pretty generic name, do you mind uploading it here so I can debug it a little?

[Rantanplan]

Hello,

I tried the following project:

https://github.com/simon-iversen/ncs_samples/tree/master/update_mcuboot_app_and_netcore

and it did not run into the "undefined reference to `sys_clock_cycle" error discussed above. The MCUboot image was uploaded, but still the old MCUboot has been booted.

Furthermore, I cannot see any meaningful log messages from the network core. The output gets stuck at

*** *** Booting Zephyr OS build v3.2.99-ncs2 ***
*** ing (0x1008800).

I would be thankful for every suggestion how get more log information from the network core.

Many thanks in advance.

Kind regards,

Christian

[Hieu]

Hi Christian,

As I explained in my previous reply. The two-stage bootloader, aka NSIB + MCUboot, does not work correctly on the nRF5340 at the moment. A fix will come, but right now, with NCS v2.3.0, update does not work. The corruption you see with the network core is likely a result of that.

Are you working with tgoos on the same project? If so, please understand that I did not ask for the board file to help you get the two-stage bootloader to work. It is to look into why there are differences between building with the custom board definition and with the nrf5340dk_nrf5340_cpuapp_* definition.

Best regards,

Hieu