MCUBoot fails to build with Internal RC enabled without multithreading NRF52840 (NCS 2.0.0)

[Curiosus]

Hi There, 

Currently running into this issue that has been discussed here, also described in this github issue here. 

Environment description:

- NCS v2.0.0

-  BLE Application. 

- NRF52840 Using internal RC low frequency clock. (Raytac Module).

Initially my application would not boot up at all, due to not having an external low frequency XTAL, However by adding the /child_image/mcuboot.conf file with the following flag it worked like a charm: 

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

Now that I want to use my own keys to sign the images to perform the OTA, I added this to the CMakeLists in order to use my custom keys instead of the default ones. 

set(mcuboot_CONF_FILE "${CMAKE_CURRENT_SOURCE_DIR}/child_image/mcuboot.conf")

The build fails as mentioned in the tickets above. 

I have got it working by enabling multithreading in the local  mcuboot.conf: 

CONFIG_MULTITHREADING=y

This adds a tremendous amount of overhead to the bootloader image, from ~24 kB to 45kB. 

I have tried adding these: 

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP=0

and these: 

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n

But so far only by enabling Multithreading do I get it to build. 

Can you guys please provide an explanation to this behavior ? 

How could I get the build to work without adding the massive overhead of Multithreading is it really necessary ? 

Cheers, 

[AHaug]

Hi,

Now that I want to use my own keys to sign the images to perform the OTA, I added this to the CMakeLists in order to use my custom keys instead of the default ones. 

(mcuboot_CONF_FILE "${CMAKE_CURRENT_SOURCE_DIR}/child_image/mcuboot.conf") will overwrite MCUboots default configs. I recommend you to have a look at this sample written by a colleague of mine for how to add custom keys: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/keys_and_signatures/mcuboot_smp_custom_key

I think that if you follow this guide you will see that you don't need to add Multithreading to make it build.

Let me know if this fixes your issues,

Kind regards,
Andreas

[Curiosus]

Hi Andreas, 

Thanks for prompt response. 

I did test your suggestion and it works, However with one caveat otherwise it would not compile in NCS 2.0.0 this Cmake command

set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE \\\"${CMAKE_CURRENT_SOURCE_DIR}/child_image/private-key.pem\\\" )

requires double level of escaping as stated here.  

It works for now, However I do want to have custom configuration for McuBoot for my application I am currently using ->? chiLd_image/mcuboot.conf how does the precedence work in this case, what overwrites what? 

Where do I find the default Mcuboot configuration file ? 

What is you recommendation for adding custom configuration for MCUBoot ? 

Thanks for your help on this. 

Cheers,

[AHaug]

Hi,

Glad to hear you got it to work!

Curiosus said:

It works for now, However I do want to have custom configuration for McuBoot for my application I am currently using ->? chiLd_image/mcuboot.conf how does the precedence work in this case, what overwrites what? 

The child_image mcuboot works as an overlay and overwrites settings in mcuboot/proj.conf. When building, you will first use any parent image such as the proj.conf (and Kconfig) for your project to generate which features that will be used. If you have any overlay files, this will be laid over the proj.configuration and either add or modify the configs you've added in the overlay file.

Curiosus said:

Where do I find the default Mcuboot configuration file ?

<NCS location>\<NCS Version>\bootloader\mcuboot\boot\zephyr

Curiosus said:

What is you recommendation for adding custom configuration for MCUBoot ? 

Typically we recommend you to use project specific overlay and configuration files when you want to add custom configurations to any part of the SDK for a single project. This way you can keep the SDK relatively pristine and allow for you to enable and disable what you need for only that project.

Of course sometimes you will have to modify the SDK files, for instance to change something in main.c in the bootloader-folder I mentioned above, which is fine. But do note your changes down somewhere so you know what you've changed if you ever need to revert back in the future to for instance test a sample that requires that change to be reverted.

Let me know if this answers your questions!

Kind regards,
Andreas