nRF53 Custom b0n Build

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Mon, 03 Jul 2023 07:06:35 GMT

[quote user="Joe Kane"] But you meant build separate proprietary bootloader app. separately, and build NRF application with offset from CONFIG_FLASH_LOAD_OFFSET (separately) .[/quote]

Correct

Let me know if you got any further questions.

RE: nRF53 Custom b0n Build

Joe Kane — Fri, 30 Jun 2023 18:25:52 GMT

Sigurd,

Thank you for quick answer (again!) Please enjoy your weekend.

I see now. I was still thinking in terms of the sdk tool kit building (and it only supporting either SIBS or Mcuboot) But you meant build separate proprietary bootloader app. separately, and build NRF application with offset from CONFIG_FLASH_LOAD_OFFSET (separately) .

This would be very similar to our previous process (with offsets tied to linker script and makefile targets (to know which offset to use) .

And finally maybe we can build either standalone or composite images using sysbuild with sysbuild kconfig options.

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Fri, 30 Jun 2023 14:53:03 GMT

Quick answer before I am taking the weekend now:

[quote user="Joe Kane"]Thank you for the fast response. Yes, I understand that it is possible to add another stage of custom bootloader that runs after after SIBS or mcuboot runs as long as the signing chain is honored.[/quote]

This is not what I mean. I refer to only Custom Bootloader + Applicaton.

For the case of the nRF5 Bootloader and the nRF52840Dongle, neither NSIB or MCUboot runs on the dongle with the NCS applications here.

RE: nRF53 Custom b0n Build

Joe Kane — Fri, 30 Jun 2023 14:43:14 GMT

Sigurd,

Thank you for the fast response. Yes, I understand that it is possible to add another stage of custom bootloader that runs after after SIBS or mcuboot runs as long as the signing chain is honored.

But this does add complexity and code size, and in some designs it is really required to do some custom development in the first stage boot (and there can be only one bootloader) and be as small as possible due to limited memory.

I have been running up to nrfconnect 2.3 and haven't toured 2.4 yet, and I missed sysbuild. Taking a quick look at the architecture, it can probably do the kind of things I requested.

We have accomplished this in the past with customized linker scripts and custom makefile targets for 'standalone' or 'composite' images, but sysbuild can probably handle the job.

I will take a further look.

Thank you.

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Fri, 30 Jun 2023 13:04:42 GMT

Thank you for the complements!

[quote user="Joe Kane"]Can you comment if there has been any progress on this or any plans by Nordic to support custom(ized) bootloader builds in nrf connect (without needed to modify the sdk)?[/quote]

There have not been any changes to the multi-image builds yet.

However, there are work being done on sysbuild. From these release notes:
"Sysbuild was introduced in Zephyr's v3.2.0 release, and has been adopted in the nRF Connect SDK v2.4.0. Sysbuild will gradually become the new workflow for handling multi-image build configurations and it will replace the child image mechanism, specific to the nRF Connect SDK
"

I have still not tried sysbuild myself, but from what I have heard I suspect it could make it easier to add customized bootloaders to projects.

[quote user="Joe Kane"]

On this same topic and related, Nordic should consider the case of being able to build the bootloaders as standalone projects directly in the toolchain (the documentation states that this is somewhat doable via command line).

There are numerous real world (especially in production and repair environments) where a standalone bootloader project/build (not as a child project) is required for the various workflows.

Building as child application embedded in main effort can also create design isolation challenges: some extreme security projects have separate bootloader/security development environments and don't want to share source/build with the application teams.

Having the bootloader projects as separate standalone examples would allow that customization and should be accommodated by your toolchain, in addition to composite projects that have bootloader and app.

There are some cases where products never even see an application until some post fielding OTA/download/low level upgrade that is done by bootloader.

[/quote]

In the end, a bootloader does not really care about how which binary it boots to (as long as said binary is signed).

Therefore, you can in theory add your own bootloader and boot any nRF Connect SDK application after.
As long as the bootloader is good enough at resetting states of peripherals and such, the application should not be affected by this either.

In fact, our nRF52840 Dongles run the (old) nRF5 Bootloader, which does not know anything about the nRF Connect SDK.
And this works.
You can use the Kconfig option CONFIG_FLASH_LOAD_OFFSET to make the application start at the correct offset for your bootloader.
And then if you want to do DFU, you either must have an update mechanism in the bootloader (ex. serial recovery) or one in your application which supports the custom bootloader.

Here you can see a case where I discuss using the nRF Bootloader One bootloader to rule them all .

Did this make sense to you?

Regards,
Sigurd Hellesvik

RE: nRF53 Custom b0n Build

Joe Kane — Fri, 30 Jun 2023 12:17:22 GMT

Sigurd,

I found this discussion due to a similar need. I also appreciate the honesty and candor in your response.

Can you comment if there has been any progress on this or any plans by Nordic to support custom(ized) bootloader builds in nrf connect (without needed to modify the sdk)?

Anton's use case is very common in the real world :

"This project is for a product that needs to be able to recover even under extreme circumstances so custom bootloaders are absolutely necessary."

The use of well structured, well designed, well tested, and open (in case of mcuboot) bootloaders is a good thing, but there will always be real world low level (and often proprietary/legacy methods) recovery needed directly from the lowest levels of code. It is most often the more complex and higher levels of boot which fail (later stage bootloaders, application etc). And there may also be some other low level/sensitive/proprietary customization required in the first and/or second stages of boot.

There are numerous real world (especially in production and repair environments) where a standalone bootloader project/build (not as a child project) is required for the various workflows.

There are some cases where products never even see an application until some post fielding OTA/download/low level upgrade that is done by bootloader.

Thank you for considering these inputs.

RE: nRF53 Custom b0n Build

AntonD — Fri, 13 May 2022 05:57:39 GMT

Thanks for your honesty.

This project is for a product that needs to be able to recover even under extreme circumstances so custom bootloaders are absolutely necessary. I have worked around the worst of the issues modifying the SDK by adding the following lines to the top of the application root CMakeLists.txt :

set(CONFIG_B0_CUSTOM_FOLDER "${CMAKE_SOURCE_DIR}/cpuboot")
set(CONFIG_B0N_CUSTOM_FOLDER "${CMAKE_SOURCE_DIR}/netboot")

I have then added the custom bootloaders at those subdirectories. I then copied the SDK into a new directory next to the application (so as not to polute the common SDK) and made the following changes to the samples CMakeLists.txt :

if (CONFIG_SECURE_BOOT)
  if (CONFIG_SOC_NRF5340_CPUNET)
    # Share some information which is used when generating the zip file
    # with the update binaries.
    set_shared(IMAGE net_core PROPERTY SOC ${CONFIG_SOC})
    set_shared(IMAGE net_core PROPERTY VERSION ${CONFIG_FW_INFO_FIRMWARE_VERSION})
    if (DEFINED CONFIG_B0N_CUSTOM_FOLDER)
      add_child_image(
        NAME b0n
        SOURCE_DIR ${CONFIG_B0N_CUSTOM_FOLDER}
        )
    else()
      add_child_image(
        NAME b0n
        SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/nrf5340/netboot
        )
    endif()
  else()
    if (DEFINED CONFIG_B0_CUSTOM_FOLDER)
      add_child_image(
        NAME b0
        SOURCE_DIR ${CONFIG_B0_CUSTOM_FOLDER}
        )
    else()
      add_child_image(
        NAME b0
        SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/bootloader
        )
    endif()
  endif()

This does get the job done but is still a bit of a hack; so, I am not marking this as an answer until custom bootloaders can be built using the unmodified SDK.

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Mon, 09 May 2022 13:05:02 GMT

I have tried to do custom NSIB and b0n in the samples I suggested you, and I have talked with my colleagues about it.

And I have finally found what I suspect you have tried to tell me all this time: It does not work.

As far as I can find, CONFIG_SECURE_BOOT is needed for both NSIB and b0n, and if this is set the child images are imported directly from our samples folder.
And CONFIG_SECURE_BOOT is too interconnected with the nRF Connect SDK for us to disable it without consequences.

In conclusion, the only way to have custom NSIB/b0n is to fork the nRF Connect SDK, and make changes to our SDK.
See my earlier comment for an example, and also Adding your own code.

Thank you for being thorough in getting your point across.
While this is not the solution you want right now, I hope it will suffice.
I will ask our developers about this feature, and maybe we can get it in a future version of the nRF Connect SDK.

Regards,
Sigurd Hellesvik

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Fri, 06 May 2022 08:40:25 GMT

Some of the concepts in the previous linked example are explained in https://github.com/nrfconnect/sdk-nrf/tree/main/samples/nrf5340/multicore.

Regards,
Sigurd Hellesvik

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Fri, 06 May 2022 07:16:01 GMT

Yea, I agree that it is far from ideal to make changes to the SDK.
I asked our developers about this, and here is my question and what they had to say:

"I want to make changes to the b0n child image for my application. So I copy nrf/samples/nrf5340/netboot to somewhere else(ex ~/custom_netboot).
How to I tell my application(ex. hello_world) to include custom_netboot instead of netboot? How to do this without making changes to the SDK?"

" You need to add new kconfig for selecting custom_netboot and then add some cmake code (typically in a ZEPHYR_EXTRA_MODULE which performs the conditional add_child_image. See the example: https://github.com/oivoii/rpmsg-simple-nrf5340/pull/2/files "

I will try this myself as well. Then I will have a look at your network core app problem after.

Regards,
Sigurd Hellesvik

RE: nRF53 Custom b0n Build

AntonD — Fri, 06 May 2022 06:17:38 GMT

No. This is not what I am looking for. Modifying the SDK in this way is a bad idea for several reasons but most notably:

This will break any other project I am working on using the SDK supplanting the standard bootloader with a custom one.
If I need to change SDK version it will revert any changes and if this file changes significantly may mean that I cannot replicate this behaviour.
The source code for the bootloaders ends up in the SDK instead of a logical place for development/version control etc.

Also, this doesn't really answer the network core app problem.

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Thu, 05 May 2022 11:34:26 GMT

nRF Connect SDK v1.9.1. nRF5340DK.

Here is a sample showcasing how to use custom NSIB and b0n with a hello world sample. The files I have added or changed will be listed below:

ncs/nrf/samples/CmakeLists.txt:
devzone.nordicsemi.com/.../8547.CMakeLists.txt

Any location: hello_world:
devzone.nordicsemi.com/.../2275.hello_5F00_world.zip

ncs/nrf/samples/custom_nsib:

devzone.nordicsemi.com/.../custom_5F00_nsib.zip

ncs/nrf/samples/custom_b0n:

devzone.nordicsemi.com/.../custom_5F00_b0n.zip

custom_nsib is a slightly changed copy of nrf/samples/bootloader and custom_b0n is a slightly changed sample of nrf/samples/nrf5340/netboot.
They both have a print function added to the top of main to verify the change.

Build this hello_world as such:

west build -b nrf5340dk_nrf5340_cpuapp

Is this what you needed?

Regards,
Sigurd Hellesvik

RE: nRF53 Custom b0n Build

AntonD — Thu, 05 May 2022 06:23:10 GMT

I have no problem creating the minimal example you talk about based on hello_world with unmodified b0 and b0n. The real problem is that I need to have custom bootloaders on both cores. I am not fussed about which of the two above architectures make more sense. However, they will need to be custom bootloaders, and that is where the problems come in.

The issues I have in the original email occur whether it is b0n on the cpunet or b0 on the cpuapp. I have tracked the problem to the block starting at "v1.9.1/nrf/samples/CMakeLists.txt:57" that is included in both the net core app and the app core app. If you enable "CONFIG_SECURE_BOOT" then this file will automatically include b0 or b0n into the application. If I add a custom b0 or b0n using the instructions here https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html then it includes b0/b0n twice. This is why I get the error message above (the CMakeCache.txt is created once by the nrf samples b0/b0n code and once by my b0/b0n code ... and it gets quite confused). I have attempted to fix this by (temporarily) modifying the above CMakeLists.txt in the samples folder to not include b0 or b0n when CONFIG_B0_BUILD_STRATEGY_FROM_SOURCE is enabled. This returns me to the infamous "pm_config.h" not found error.

Following the above link, I have tried to add a custom netcore app too. I have created one using the hello_world example and as advised I have added the following line to the CMakeLists.txt of the appcore app:

add_child_image(
NAME netapp
SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/netapp
DOMAIN CPUNET
)

where "netapp" was the name and subdirectory of the hello_world application code for the cpunet core.

No board specified for domain 'CPUNET'. This configuration is typically defined in C:/Users/anton/ncs/v1.9.1/zephyr/boards/arm/nrf5340dk_nrf5340/Kconfig

So, to get back to the original question, how do I set up a build that has a custom b0 and a custom b0n?

I will need both. Minimal examples are fine.

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Wed, 04 May 2022 08:33:36 GMT

Hi Anton

Since b0n and b0 is easily mixed, I will from now on refer to them as follows:

Network core bootloader: b0n

Application core nRF Secure Immutable Bootloader: NSIB

[quote user="AntonD"]I assume when you say that you are building a custom b0n for the cpuapp you mean that you are building a custom b0 for the cpuapp.[/quote]

Your assumption is wrong. I am talking about custom b0n.

[quote user="AntonD"]So for some reason the partition manager script must not be running and must not be generating the "pm_config.h" header, or it is not in the correct include path. How do I rectify that?[/quote]

I think that the reason it does not work for you is that the "application design" we intent to be used for child images is different from the one you use.

I suggest that you take a step back and look at the overall design.
Am you making two different projects: One for the APP core and one for the NET core?

Or are you making one project for the whole nRF5340, like this?

The second solution is the one I described in my previous post, and the one recommended for nRF5340.

Regards,
Sigurd Hellesvik

RE: nRF53 Custom b0n Build

AntonD — Wed, 04 May 2022 07:03:34 GMT

I have tracked it down to the file "partition_manager.cmake", which should make the "pm_config.h" file. This section of code is where it exits before actually creating the header file.

# This file is executed once per domain.

# It will be executed if one of the following criteria is true for the

# current image:

# - It's a child image, and is the dynamic partition in the domain

# - It's the root image, and a static configuration has been provided

# - It's the root image, and PM_IMAGES is populated.

# - It's the root image, and other domains exist.

# - A subsys has defined a partition and CONFIG_PM_SINGLE_IMAGE is set.

# Otherwise, return here

if (NOT (

(IMAGE_NAME AND is_dynamic_partition_in_domain) OR

(NOT IMAGE_NAME AND static_configuration) OR

(NOT IMAGE_NAME AND PM_IMAGES) OR

(NOT IMAGE_NAME AND PM_DOMAINS) OR

(PM_SUBSYS_PREPROCESSED AND CONFIG_PM_SINGLE_IMAGE)

))

return()

endif()

None of the above are true and so it doesn't create the header file. By adding CMake messages, I can see that:

For b0n the IMAGE_NAME is set to b0n and the other parameters are empty. I assume this means that b0n shouldn't build the pm_config.h (which is what I would expect.
None of the other parameters are set for the application, which seems wrong.
This seems like PM_IMAGES or PM_DOMAINS should not be blank ...

What should these parameters be? Where should they be set?

RE: nRF53 Custom b0n Build

AntonD — Wed, 04 May 2022 05:42:06 GMT

I assume when you say that you are building a custom b0n for the cpuapp you mean that you are building a custom b0 for the cpuapp.

So, I can get it to build the b0n image now. I just had to remove the "if (CONFIG_SECURE_BOOT)" and set that config to "n" in the prj.conf for the net application. It then tells me that it cannot add the child image unless "CONFIG_PARTITION_MANAGER_ENABLED" is set to "y". Fine. I do that. Then I get a build error where it cannot find "pm_config.h".

Now I have chased that down to the following link: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/scripts/partition_manager/partition_manager.html

Now that link says that:

So for some reason the partition manager script must not be running and must not be generating the "pm_config.h" header, or it is not in the correct include path. How do I rectify that?

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Fri, 29 Apr 2022 11:43:58 GMT

I explain a bunch of context. However, it might not be super-relevant for you until the red text further down.

I agree with you here, I were unspecific in my previous answer.
b0n is the bootloader for the network core.
For the application core, you can use b0 and/or MCUBoot as a bootloader.

For a typical example for use of b0n, with context:
Our Machine Learning sample has configurations for bootloader support on the nRF5340.
In this sample, MCUBoot is running on the Application Core, while b0n is running at the Network Core.
To update the firmware, the nRF5340 has to enter Serial Recovery mode or using the Simple Management Protocol over Bluetooth.
This will use the mcumgr tool to upload an image to the application core, which is then swapped to the network core using Peripheral CPU DFU (PCD).
When you now reboot, b0n will boot into the new image.

So when i sat "alongside", I really mean that it is generally not the only bootloader running on the nRF5340.

I should point out that use of the b0n is a bit weird in the sense of multi-images.
Normally, you can use overlays in your project to change the configurations of your child images.
Or you could add a custom child image to your project, to avoid making changes to the nRF Connect SDK directly.
When using the nRF5340, the code running on the network core will be built as a child image of the application.
For example, if CONFIG_BT=y when you build for your nrf5340dk_nrf5340, the child image hci_rpmsg is added to your project.

However, if you want to use the b0n, it is added as a child image of the child image running on the network core. (for example a child_image of hci_rpmsg).
There is one way to add a configuration overlay to a "recursive" child image, by nesting their names in CMake variables for child image configurations:

west build -b nrf5340dk_nrf5340_cpuapp -- -Dhci_rpmsg_b0n_CONFIG_DEBUG=y

So I think your approach is the best way to add a custom b0n: By first making an custom application for the network core. Then you can add this as a child image when you later make firmware for the network core.
To try to answer your question:

[quote user=""]If I then build the net app, the application builds, but b0n is neither built nor linked.[/quote]

I have not been able to find where in the nRF Connect SDK this is set,
but I am able to build with a custom b0n if I build hello_world for nrf52840dk_nrf52840_cpuapp with the following configurations:

CONFIG_BT=y
CONFIG_SECURE_BOOT=y
CONFIG_BOOTLOADER_MCUBOOT=y

(Hello World since it is a minimal sample)

I will continue looking into child images next week, to try to find more for you. If you are able to figure out something in the meantime, let me know.

Regards,
Sigurd Hellesvik

RE: nRF53 Custom b0n Build

AntonD — Fri, 29 Apr 2022 05:11:39 GMT

The CMakeLists.txt that I am referring to is the root level CMakeLists.txt for the application on the net core (based on nrf/samples/bluetooth/peripheral_lbs on the net core).

I think you are mistaken: b0 is the app core bootloader, b0n is the net core bootloader (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf5340/netboot/README.html). Also, as I have said, I can compile and run b0n on the net core without issue. Also, b0n isn't used alongside the bootloader, it is a bootloader. Did you mean it is often run alongside mcuboot as a set of first and second stage bootloaders?

Edited: I attempted to build the b0n/app using app core but that failed as it was unable to find "pm_config.h" ... but I don't think that is the correct path to follow anyway.

RE: nRF53 Custom b0n Build

Sigurd Hellesvik — Thu, 28 Apr 2022 11:17:32 GMT

Hi Anton

[quote user=""]I have tried adding the b0n as a child image of the application by adding the following code to CMakeLists.txt[/quote]

Can you specify which CmakeLists.txt you are referring to here?

[quote user=""]If I then build the net app[/quote]

The b0n is usually used alongside the bootloader in the application core. What happens if you build for nrf5340dk_nrf5340_cpuapp instead?

Regards,
Sigurd Hellesvik