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 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.

[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

[tgoos]

Hi Hieu,

I re-tested this and the result is still the same:

If CONFIG_SECURE_BOOT=y is defined in the prj.conf file, the pristine builds for nrf5340dk_nrf5340_cpuapp_ns and nrf5340dk_nrf5340_cpuapp are fine, but builds for demo_board_cpuapp and demo_board_cpuapp_ns fail with error code: "undefined reference to `sys_clock_cycle_get_32'"

[Hieu]

Hi tgoos,

Please know that I am still around. However, I have been out of office and will only return later this week.

I was really invested in figuring it out, but I could not see why the MCUboot build steps is largely different on the custom board when enabling both MCUboot and NSIB. I asked some colleagues but there were also no leads. I will try again when I return to office.

Hieu