Adding the nRF Secure Bootloader in custom board with nRF5340

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Tue, 02 Jul 2024 14:30:29 GMT

Hi Danny,

This case is really old now, and it seems your question does not really relate to the topic being discussed. Therefore, I would like to ask you to open a new DevZone case for the question.

Best regards,

Hieu

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

danny0007 — Mon, 01 Jul 2024 20:40:14 GMT

Hi tgoos,

could you please share, how did you manage to flash the bootloader in a blank nRF5340?

Best regards

Danny

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Wed, 10 May 2023 12:22:11 GMT

Hi tgoos,

We found the issue yesterday and know the fix. But before we begin, I would like to reiterate that right now, as of NCS v2.3.0, the two-stage bootloader solution is not working.

Below I will explain why the custom board build is different from the built-in-SDK nRF5340 DK board and how to fix it; this thus relieve us of the concern that there is some undiscovered bug in the board definition.

There is a Kconfig fragment file that is included in b0 child image build for the nrf5340dk_nrf5340_cpuapp and _ns boards.

However, because your custom board is named differently, the build process will not pick up this fragment file.

The solution is, via one of many ways, include the necessary configurations into your b0 child image build.

Here are a couple of options:

Copy that file over as <your project root>/child_image/b0.conf
The downside is that all builds for non nRF5340 boards will also be affected
Copy that file over to your project root folder, and include it in the build as a Kconfig fragment for b0 via
-Db0_OVERLAY_CONFIG=<Full path to the fragment file>

I am in dialogues with our internal team to investigate a better way to handle the Kconfig configuration for nRF5340 builds.

References:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/multi_image/index.html
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/zephyr/develop/application/index.html#important-build-system-variables

Hieu

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Mon, 08 May 2023 10:52:23 GMT

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

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

tgoos — Wed, 03 May 2023 10:14:08 GMT

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'"

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Fri, 28 Apr 2023 07:23:05 GMT

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

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

tgoos — Thu, 20 Apr 2023 07:42:58 GMT

We will do that, thanks!

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Thu, 20 Apr 2023 07:39:57 GMT

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?

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

tgoos — Thu, 20 Apr 2023 07:36:16 GMT

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.

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Wed, 19 Apr 2023 21:35:09 GMT

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

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

tgoos — Mon, 17 Apr 2023 13:08:37 GMT

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.

devzone.nordicsemi.com/.../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.

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Mon, 17 Apr 2023 10:16:11 GMT

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

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Mon, 17 Apr 2023 10:10:05 GMT

Hi Christian,

[quote user="Rantanplan"]I'm now wondering how the correct configuration for main application and network core update, but not MCUboot update, should look like.[/quote]

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

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

tgoos — Mon, 17 Apr 2023 08:59:59 GMT

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.

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Rantanplan — Mon, 17 Apr 2023 07:59:10 GMT

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

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Mon, 17 Apr 2023 07:19:21 GMT

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

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Rantanplan — Sun, 16 Apr 2023 21:52:19 GMT

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

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Fri, 14 Apr 2023 06:36:15 GMT

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?

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

tgoos — Thu, 13 Apr 2023 11:18:09 GMT

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.

RE: Adding the nRF Secure Bootloader in custom board with nRF5340

Hieu — Thu, 13 Apr 2023 10:23:50 GMT

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