nRF53 Custom b0n Build

RE: nRF53 Custom b0n Build

user83813 — 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

user106736 — 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

user106736 — 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

user106736 — 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

user83813 — 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

user106736 — 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:
test-devzone.nordicsemi.com/.../8547.CMakeLists.txt

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

ncs/nrf/samples/custom_nsib:

test-devzone.nordicsemi.com/.../custom_5F00_nsib.zip

ncs/nrf/samples/custom_b0n:

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

user83813 — 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

user106736 — 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

user83813 — 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

user83813 — 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

user106736 — 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

user83813 — 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

user106736 — 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