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,

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

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

[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!