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?

[Rantanplan]

Hi Hieu,

many thanks for the explanation.

No, it is not the tgoos' project, I just ran into the same "undefined reference to `sys_clock_cycle" error, if SECURE_BOOT was enabled.

Therefore I took a NRF5340DK board and the default nrf5340dk_nrf5340_cpuapp definition, where I realized that the MCUboot was not updated and the net core logging was not working.

I'm now wondering how the correct configuration for main application and network core update, but not MCUboot update, should look like.

Kind regards,

Christian

[tgoos]

Hi Hieu,

Yes, I can share my boards-folder. Do you have a file sharing server to suggest?

But you can repeat my actions rather easily too (~15 min work). Take a copy of the ./ncs/zephyr/boards/arm/nrf5340dk_nrf5340 -folder to somewhere like: /home/user/test/boards/arm/demo_board and rename all nrf5340dk_nrf5340 to something else (I had demo_board).

Then go to ./ncs/zephyr/samples/hello_world and try building these:

west build -b demo_board_cpuapp_ns -d build_demo -- -DBOARD_ROOT=/home/user/test
west build -b demo_board_cpuapp_ns -d build_demo_sec -- -DBOARD_ROOT=/home/user/test -DCONFIG_SECURE_BOOT=y
west build -b nrf5340dk_nrf5340_cpuapp_ns -d build_nrf5340_sec -- -DBOARD_ROOT=/home/user/test -DCONFIG_SECURE_BOOT=y

You should see the first and last ones be successful and the middle one to fail.

[Hieu]

Hi Christian,

Rantanplan said:

I'm now wondering how the correct configuration for main application and network core update, but not MCUboot update, should look like.

There is a guide on that here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/bootloaders_and_dfu/index.html.

If you have a difficulty with setting that up, please consider opening a new DevZone question depends on whether the issue is relevant to the topic of this current DevZone thread or not.

Best regards,

Hieu

[Hieu]

Hi tgoos,

You can upload the files right here with this interface:

If the board is still just a renamed copy like that, I will take an attempt at it and get back to you.

By the way, the current recommended way to add a board is to do it in your own application folder. So, I will try it like that. I also prefer not to make modifications to my SDK except when it is necessary, in order to prevent future confusion.

Refer:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/board_support/index.html#custom-boards
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/develop/application/index.html#custom-board-definition

Best regards,

Hieu

[tgoos]

Hi Hieu,

Thanks for your patience and guidance.

Here is my boards folder zipped. Just in case you have a different result in your testing, you can compare.

demoBoard.zip

I have my project definition and source in a separate folder as suggested in the references you posted above. But I wanted to be sure that the problems are not related to my environment (other than the boards-folder), so I tried building the Zephyr samples and used that also in my last post to minimize the differences between our environments.