Size of build image for mcuboot with serial or usb DFU enabled?

[BrianW]

Working on a nrf5340 project, and running into limits of the size of the flash to store my application image along with mcuboot bootloader.

I had a mucboot setup that fitted into 56Kb (signed images, secondary slot on external flash). This did NOT include the serial DFU however, and (of course) one of my first units out in the field got bricked during a DFU (using dfu_target lib to update the secondary slot from a file loaded on USB FAT FS mounted on the external flash... not yet got the unit to see what got corrupted...)

I expose the USB interface, so would like to enable the serial DFU functionality in mcuboot so that at least I have a method to DFU even if my main app image gets corrupted...Some questions to get this to work:

1/ The buttons on the device are via a gpio expander on the i2c interface, it seems mcuboot likes a 'dfu button' to be a direct gpio (at least if I set the alias:

mcuboot-button0 = &button2;

then it doesn't build because button2 is 

button2: button_2 {

            gpios = <&ioexp0 4 (GPIO_ACTIVE_LOW)>;    // GPA4

). Is this correct or should it work via a ioexpander?

BTW This is not a deal breaker as I see I can have a 'DFU delay' at boot to always check if the dfu is to be activated on the serial/USB

2/ serial DFU (virtual com port on USB) vs USB DFU : which is better to use? Which gives me a smaller mcuboot image?

3/ Image size : mcuboot with DFU_USB is now 76+Kb

Is this normal? Are there ways to slim this down? also, the mcuboot child_image build has its own mcuboot.conf - does this addon to the usual prj.conf, or replace it completely?

The image size is an issue because my main app uses https over wifi networking (nrf7002) and the wifi code+networking+TLS takes up a LOT of space....

thanks for any tips to get a solid mcuboot in the least flash space!

[AHaug]

Hi,

Which version of nRF Connect SDK are you using?

1/ The buttons on the device are via a gpio expander on the i2c interface, it seems mcuboot likes a 'dfu button' to be a direct gpio (at least if I set the alias:

mcuboot-button0 = &button2;

then it doesn't build because button2 is 

button2: button_2 {

            gpios = <&ioexp0 4 (GPIO_ACTIVE_LOW)>;    // GPA4

). Is this correct or should it work via a ioexpander?

I will have to look closer into this.

2/ serial DFU (virtual com port on USB) vs USB DFU : which is better to use? Which gives me a smaller mcuboot image?

Which is better to use: That depends on the design of your product. W.r.t to size you would have to build your project for either configurations and see the build results.

3/ Image size : mcuboot with DFU_USB is now 76+Kb

Is this normal?

If you've done optimizations, then that might be the default size, yes. Without DFU_USB MCUboot defaults to 48kB, but can be shrunk depending on what features you need.

Are there ways to slim this down?

The optimization page here might give you some more information w.r.t shrinking the size of the bootloader: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/test_and_optimize.html 

In addition you can have a look at the minimal mcuboot confiugration such as discussed here in the Matter applications: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/matter/end_product/bootloader.html 

also, the mcuboot child_image build has its own mcuboot.conf - does this addon to the usual prj.conf, or replace it completely?

If my understanding is correct it adds configurations that are just defined for said child image (MCUboot in this case).

The image size is an issue because my main app uses https over wifi networking (nrf7002) and the wifi code+networking+TLS takes up a LOT of space....

The optimization links as well as this https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf70/fw_patches_ext_flash.html and to use external flash for general DFU (which I assume you already do) is hopefully a good starting place, but let me know if you have any more specific questions.

Kind regards,
Andreas

[BrianW]

AHaug said:

Which version of nRF Connect SDK are you using?

2.6.x

AHaug said:

2/ serial DFU (virtual com port on USB) vs USB DFU : which is better to use? Which gives me a smaller mcuboot image?

Which is better to use: That depends on the design of your product. W.r.t to size you would have to build your project for either configurations and see the build results.

Yes, I was rather hoping for some experience rather than having to explore all the possible options myself... But hving tried the 'USB DFU' option, I have decided against, as it requires installing the WinUSB driver for the device to let dfu-util see it, but this then breaks the USB FS operation (at least on my PC)...

Trying serial DFU, but it doesn't like my dfu zip it seems: 

This is the zip created directly by the west build. Any idea what it is objecting to?

AHaug said:

In addition you can have a look at the minimal mcuboot confiugration such as discussed here in the Matter applications: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/matter/end_product/bootloader.html

This claims you can get down to 24kB. I have managed to reduce the basic mcuboot to about 40kB, but with the serial loader option it is still up at over 64kB... 

AHaug said:

The optimization links as well as this https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf70/fw_patches_ext_flash.html and to use external flash for general DFU (which I assume you already do) is hopefully a good starting place, but let me know if you have any more specific questions.

Yes, my DFU secondary slots are in the external flash already.

I will need to try to "nrf7002 firmware in external flash" option, even if it looks complex, as that will save 64kB I guess.

I have switched to tinyCrypt instead of mbedtls, which seems to save some 30kB or so. However, I haven't managed (with either) to get a TLS connection (for https) to work yet... what are the impacts of using tinyCrypt?

[BrianW]

Oh, and when I hold down the defined button during boot, it starts the USB virtual comm ports. Haven't tried to run mcumgr yet, but thats the next step!

[BrianW]

So, I applied the config to my test build using nrf70 wifi with the DFU images in the external flash... It built under multi-image system, but not with sysbuild (due to the 'hack' for the cpu-net primary slot it seems).

If you have any insights for sysbuild, the ticket is here:

 (Missing Forum Thread) 

thanks!. 

[AHaug]

Great! It sounds like we've resolved the issue with reducing the size of MCUboot in this case.

BrianW said:

I will try this now building with sysbuild...

I assume you refer to your sample with sysbuild specific, since the sample I supplied builds with sysbuild as a default, but I'm glad to hear you were able test it with the child/parent setup.

I will have a look at your other case and give you a reply there shortly

Kind regards,
Andreas

[BrianW]

AHaug said:

I assume you refer to your sample with sysbuild specific, since the sample I supplied builds with sysbuild as a default, but I'm glad to hear you were able test it with the child/parent setup.

yes, it has an issue with definition of the PRIMARY_1 slot for the CPU-NET DFU when built with sysbuild. 

[BrianW]

BrianW said:

I confirm it builds to around 56kB for me, without logs

I hate not having logs on the UART especially given trying to get the various DFUs to work.

But with CONFIG_LOG=y, its about 67kB.... even with 

CONFIG_LOG_MODE_MINIMAL=y

CONFIG_MCUBOOT_LOG_LEVEL_WRN=y

 

However, if I leave CONFIG_LOG=n, and then hack bootloader/mcuboot/boot/bootutil/include/bootutil/bootutil_log.h (way too many 'boot's in that heirarchy..) like this:

...

#ifdef MCUBOOT_HAVE_LOGGING

#include <mcuboot_config/mcuboot_logging.h>

#define BOOT_LOG_ERR(...) MCUBOOT_LOG_ERR(__VA_ARGS__)

#define BOOT_LOG_WRN(...) MCUBOOT_LOG_WRN(__VA_ARGS__)

#define BOOT_LOG_INF(...) MCUBOOT_LOG_INF(__VA_ARGS__)

#define BOOT_LOG_DBG(...) MCUBOOT_LOG_DBG(__VA_ARGS__)

#define BOOT_LOG_SIM(...) MCUBOOT_LOG_SIM(__VA_ARGS__)

#define BOOT_LOG_MODULE_DECLARE(module)  MCUBOOT_LOG_MODULE_DECLARE(module)

#define BOOT_LOG_MODULE_REGISTER(module) MCUBOOT_LOG_MODULE_REGISTER(module)

#else

// HACK: force log output using printk directly

#include <zephyr/sys/printk.h>

#define BOOT_LOG_ERR(...) printk(__VA_ARGS__);printk("\n")

#define BOOT_LOG_WRN(...) printk(__VA_ARGS__);printk("\n")

#define BOOT_LOG_INF(...) printk(__VA_ARGS__);printk("\n")

#define BOOT_LOG_DBG(...) IGNORE(__VA_ARGS__)

#define BOOT_LOG_SIM(...) IGNORE(__VA_ARGS__)

#define BOOT_LOG_MODULE_DECLARE(module)

#define BOOT_LOG_MODULE_REGISTER(module)

#endif /* MCUBOOT_HAVE_LOGGING */

I add back in the zephyr console to get printk to work, keep CONFIG_LOG as n (in child_image/mcuboot.conf)

CONFIG_CONSOLE=y

CONFIG_CONSOLE_HANDLER=n

CONFIG_SERIAL=y

CONFIG_UART_CONSOLE=y

CONFIG_STDOUT_CONSOLE=y

# turn off log to save image size

CONFIG_LOG=n

 

and voila: mcuboot error, warning, info logs :

*** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
Starting bootloader
Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Secondary image: magic=bad, swap_type=0x1, copy_done=0x2, image_ok=0x2
Boot source: none
Image index: 0, Swap type: none
Bootloader chainload address offset: 0x10000

and it builds to :

Memory region Used Size Region Size %age Used
FLASH: 61952 B 64 KB 94.53%
RAM: 299560 B 440 KB 66.49%
IDT_LIST: 0 GB 32 KB 0.00%

Pity having to hack the mcuboot source though... I had hoped the CONFIG_LOG_MODE_MINIMAL would give me the same result, but it requires 8kB more for essentially the same output....

If there is a better way to achieve this let me know...

[AHaug]

Hi,

Thank you for sharing the workaround, that resolution is very useful for me as well!

BrianW said:

If there is a better way to achieve this let me know...

I've not seen anyone using anything but either LOG_MODE_MINIMAL, or LOG_MODE=n when logging from the bootloader. The typical usecase where you can't afford logging in the bootloader while developing due to flash restrictions is to be honest relatively rare, but it does occur

BrianW said:

yes, it has an issue with definition of the PRIMARY_1 slot for the CPU-NET DFU when built with sysbuild. 

I've posted a reply in 341508 w.r.t this earlier today

Kind regards,
Andreas

[BrianW]

and if anyone can tell me why building the SAME code, with the SAME config, under sysbuild makes it 3Kb bigger (and so TOO big for the 64kB partition) then that'd be nice....

[AHaug]

Hi,

Could you specify what becomes 3kB bigger and what are the same configurations for the same code? Is it your bootloader code and configurations, is it your application code and configurations or is it the combined firmware?

Kind regards,
Andreeas

[BrianW]

mcuboot image for application processor.

Under multi-image build:

Memory region Used Size Region Size %age Used
FLASH: 62864 B 64 KB 95.92%
RAM: 371112 B 440 KB 82.37%
IDT_LIST: 0 GB 32 KB 0.00%

change the west config flag to says sysbuild:true and run same west build command:

c:/ncs/toolchains/b620d30767/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr\zephyr.elf section `usb_descriptor' will not fit in region `FLASH'
c:/ncs/toolchains/b620d30767/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `FLASH' overflowed by 308 bytes
Memory region Used Size Region Size %age Used
FLASH: 65844 B 64 KB 100.47%
RAM: 379912 B 440 KB 84.32%
IDT_LIST: 0 GB 32 KB 0.00%
collect2.exe: error: ld returned 1 exit status

3000 bytes bigger....the sysbuild/mcuboot/prj.conf and child_image/mcuboot.conf are the same (except for the keys that have to move to sysbuild.conf of course)

I'm guess that one of the options from the sysbuild.conf is responsible, maybe this:

SB_CONFIG_NETCORE_APP_UPDATE=y

Since the multi-image build did not seem to have told mcuboot about the DFUable CPU-NET slot...

I removed the INF level logs from mcuboot (CONFIG_LOG=n already, but ERR/WRN/INF were compiled in using my printk() hack) and have just managed to squeeze mcuboot into 64kB:

Memory region Used Size Region Size %age Used
FLASH: 64732 B 64 KB 98.77%
RAM: 379912 B 440 KB 84.32%
IDT_LIST: 0 GB 32 KB 0.00%

and even better, when I boot mcuboot into serial recovery mode, I get 3 slots showing as updateable:

C:\ncs\mcumgr-client-windows-x86>mcumgr-client.exe -d COM3 list
mcumgr-client 0.0.7, Copyright © 2024 Vouch.io LLC

09:18:50 [INFO] send image list request
response: {
"images": [
{
"image": 0,
"slot": 0,
"version": "0.1.13.1",
"hash": "",
"bootable": false,
"pending": false,
"confirmed": false,
"active": false,
"permanent": false
},
{
"image": 1,
"slot": 0,
"version": "0.0.0",
"hash": "",
"bootable": false,
"pending": false,
"confirmed": false,
"active": false,
"permanent": false
},
{
"image": 2,
"slot": 0,
"version": "0.1.13.1",
"hash": "",
"bootable": false,
"pending": false,
"confirmed": false,
"active": false,
"permanent": false
}
]
}

Just got to test if it actually can do DFU on each one now (using dfu_target library). 

One point that worries me in the sysbuild build : I get this log when building the app image:

-- Configuring done
-- Generating done
-- Build files have been written to: C:/work/dev/if-device-nrf53/cc1-med/build/cc1-med
CMake Warning at C:/ncs/v2.9.0/nrf/cmake/sysbuild/debug_keys.cmake:21 (message):


--------------------------------------------------------------
--- WARNING: Using generated NSIB public/private key-pair. ---
--- It should not be used for production. ---
--- See SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE ---
--------------------------------------------------------------


Call Stack (most recent call first):
C:/ncs/v2.9.0/nrf/cmake/sysbuild/provision_hex.cmake:11 (include)
C:/ncs/v2.9.0/nrf/sysbuild/CMakeLists.txt:55 (include)
C:/ncs/v2.9.0/nrf/sysbuild/CMakeLists.txt:667 (include_provision_hex)
cmake/modules/sysbuild_extensions.cmake:583 (nrf_POST_CMAKE)
cmake/modules/sysbuild_extensions.cmake:583 (cmake_language)
cmake/modules/sysbuild_images.cmake:23 (sysbuild_module_call)
cmake/modules/sysbuild_default.cmake:20 (include)
C:/ncs/v2.9.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:75 (include)
C:/ncs/v2.9.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
C:/ncs/v2.9.0/zephyr/share/sysbuild-package/cmake/SysbuildConfig.cmake:8 (include)
template/CMakeLists.txt:10 (find_package)

Despite having this in my sysbuild.conf:

SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="\${APPLICATION_CONFIG_DIR}/../keys/bootloader_priv-ecdsa256.pem"

I undetstood that SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE was used for the '2 stage bootloader allowing updateable mcuboot', but I do NOT enable SB_CONFIG_SECURE_BOOT_NETYCORE...

Any ideas what is going on here? Is my app image signed using my key file or not?

[BrianW]

SB_CONFIG_BOOT_SIGNATURE_KEY_FILE seems to be ignored now with sysbuild? So, I added this to my sysbuild.conf:

SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE="\${APPLICATION_CONFIG_DIR}/../keys/bootloader_priv-ecdsa256.pem"

 

My sysbuild.conf in full:

# MCU boot config now handled by sysbuild
SB_CONFIG_BOOTLOADER_MCUBOOT=y

# build HCI-IPC image for CPU-NET
SB_CONFIG_NETCORE_HCI_IPC=y

# we allow secure update of images, but not of mcuboot itself.
# allow update of CPU-NET? Only if SECURE_BOOT which we don't want
# Not using "secure boot" as this has 2 bootloaders...
SB_CONFIG_SECURE_BOOT=y
SB_CONFIG_SECURE_BOOT_NETCORE=y
SB_CONFIG_NETCORE_APP_UPDATE=y

#SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
#SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="\${APPLICATION_CONFIG_DIR}/../keys/bootloader_priv-ecdsa256.pem"
#SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="/work/dev/if-device-nrf53/keys/bootloader_priv-ecdsa256.pem"
#CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="/work/dev/if-device-nrf53/keys/bootloader_priv-ecdsa256.pem"

SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE="/work/dev/if-device-nrf53/keys/bootloader_priv-ecdsa256.pem"
#SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE="\${APPLICATION_CONFIG_DIR}/../keys/bootloader_priv-ecdsa256.pem"

SB_CONFIG_MCUBOOT_MODE_SWAP_WITHOUT_SCRATCH=y

# nrf7002 firmware handled by sysbuild
SB_CONFIG_WIFI_NRF70=y
SB_CONFIG_WIFI_NRF70_SYSTEM_MODE=y
SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE=y

SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=3
#SB_CONFIG_MCUBOOT_APPLICATION_IMAGE_NUMBER=0
#SB_CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER=1
#SB_CONFIG_MCUBOOT_WIFI_PATCHES_IMAGE_NUMBER=2

#SB_CONFIG_DFU_ZIP=y
#SB_CONFIG_DFU_ZIP_APP=y
#SB_CONFIG_DFU_ZIP_NET=y
#SB_CONFIG_DFU_ZIP_WIFI_FW_PATCH=y

# put application secondary slot in external flash
SB_CONFIG_PARTITION_MANAGER=y
SB_CONFIG_PM_MCUBOOT_PAD=0x200
SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y

But still, in nrf/cmake/sysbuild/debug_keys.cmake, it complains that 

SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE=""

and so it generates the debug only keys and seems to sign all the images iwth this...

Even weirder, it says SB_CONFIG_BOOT_SIGNATURE_KEY_FILE has the right path even though its commented out in my sysbuild.conf!!! (and also in the sysbuild/mcuboot/prj.conf)

log output from cmake (I added some warning logs to see what values it gets):

-- Configuring done
-- Generating done
-- Build files have been written to: C:/work/dev/if-device-nrf53/cc1-med/build/cc1-med
CMake Warning at C:/ncs/v2.9.0/nrf/cmake/sysbuild/provision_hex.cmake:10 (message):


-- provision_hex:
-- SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE =
-- SB_CONFIG_BOOT_SIGNATURE_KEY_FILE = ${APPLICATION_CONFIG_DIR}/../keys/bootloader_priv-ecdsa256.pem
-- SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256 = y


Call Stack (most recent call first):
C:/ncs/v2.9.0/nrf/sysbuild/CMakeLists.txt:55 (include)
C:/ncs/v2.9.0/nrf/sysbuild/CMakeLists.txt:667 (include_provision_hex)
cmake/modules/sysbuild_extensions.cmake:583 (nrf_POST_CMAKE)
cmake/modules/sysbuild_extensions.cmake:583 (cmake_language)
cmake/modules/sysbuild_images.cmake:23 (sysbuild_module_call)
cmake/modules/sysbuild_default.cmake:20 (include)
C:/ncs/v2.9.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:75 (include)
C:/ncs/v2.9.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
C:/ncs/v2.9.0/zephyr/share/sysbuild-package/cmake/SysbuildConfig.cmake:8 (include)
template/CMakeLists.txt:10 (find_package)


CMake Warning at C:/ncs/v2.9.0/nrf/cmake/sysbuild/debug_keys.cmake:21 (message):


--------------------------------------------------------------
--- WARNING: Using generated NSIB public/private key-pair. ---
--- It should not be used for production. ---
--- See SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE ---
--------------------------------------------------------------

What is the correct setup to get signed & validated images for mcuboot?