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,

Please know that I am still around and is trying to get to your question. 

It is taking more time because we are facing a bit too many questions due to some unavailability in the team.
I am also partially out of office from now until the end of next week, but I will try to get to it within the next three working days.

My apology for the inconvenience. Please let me know if it is urgent.

Regards,

Hieu

[tgoos]

Thanks for the info Hieu,

This is not a showstopper for us at the moment. I can go on using the app.overlay instead of a full project device-tree configuration for now.

The lack of two stage bootloader support is more to worry. Now it would be a lot easier and cheaper to switch to another hardware solution than in a later phase of the project. However we trust that you are able to tackle that problem within the next couple of months.

[Hieu]

I understand the concern about freezing the hardware choices as early as possible. I cannot comment about schedules on DevZone. However, a Regional Sales Manager (RSM) can help you with that. May I suggest you contact your local RSM to share your concern and interest on this feature and ask if they have any estimation?

[tgoos]

We will do that, thanks!

[Hieu]

Hi tgoos,

I was able to revisit this topic today. I reproduced your issue with the board I create, except that I have the same build failure when built for the cpuapp_ns board. Could you please double check this point?

Otherwise, the board you created and the one I did are essentially the same. I involved a colleague, but we still haven't figured anything out. The compiled DTS and the Kconfig looks the same as the one in a successful nrf5340dk_nrf5340_cpuapp build...

I wonder if it is something related to the unfinished part of the two-stage bootloader solution... If it is alright with you, I would like to set this aside and retry when the two-stage bootloader solution is released for the nRF5340.

Hieu