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?

[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?

[BrianW]

Ok : with the sysbuild.conf below I have successfully managed to get a valid multi-image hex, to flash this to my device (including to the external flash for the wifi), it runs, and can be updated by dfu_target calls (my app code copies a file from the usb-fs disk to the secondary slot for this) using the zephyr.signed.bin image from a subsequent build... (which I hope means that the private key used for signing is indeed my configured one...)

And mcumgr shows 3 known slots for updates in serial recovery mode (over USB VCOM).

Haven't yet tested update of either CPU-NET or wifi-fw slots however, but its looking better.... 

# 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_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"
#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

[BrianW]

Small update : even though I can get an mcuboot with the required features to squeeze into 64kB, its within a few 10s of bytes of not fitting. Given this is the CRITICAL partition for the offsets for all the others, I'm worried that a future zephyr version or patch could push mcuboot over that size, and mean I lose build compaitiblity with older devices (so no DFU is possible...)

I have therefore added 4Kb to MCUBoot, for 'future' space (and then put back my hack for INF level logs too). 68kB for the bootloader.... 

[Sigurd Hellesvik]

Hi,

Reading over this ticket: It has gone a bit back and forth now.
Thanks for the updates on the progress!

I can not see any specific questions in your previous messages. However, I might have missed something, so:
Let me know if you need anything from me, or got any questions!

[BrianW]

Hi Sigurd

Well, I have managed to get a good serially recoverable sysbuildable project using NCS 2.9, with the required 3 images to do the application/CPU-NET/wifi fw DFUs, and my mcuboot is 'only' 68kB (albeit with either no log output, or with a hack to map the logs directly to printk).

So I will flag my post with the sysbuild that works as the answer for this issue....

I am now fighting with mcuboot about DFU and confirmation of an updated image (to stop it reverting after a dfu_target_xxx() update).

This ticket has the details.

 DFU using USB file system (not serial emulation)? 

But a CRITICAL thing I have discovered, which is not IMHO well documented, is that it is essential that your slot partitions for mcuboot (primary, secondary) are both aligned at their start address on a flash erase sector boundry AND that their size is ALSO aligned on a erase boundry (0x1000=4Kb for my flash device for example).

And that the 'mcuboot_pad' partition (for the 1st image ie the app) is the oneto align on the boundry, not the following 'app' partition (so that the 'mcuboot_primary' ends up on the boundary).

Also, its the 'mcuboot_primary' size that must be aligned, and the 'mcuboot_secondary' must be this size, not the app size....

If you don't align the start : after a mcuboot swap, the resulting primary image is unreadable for booting (presumably because it couldn't erase the start sector properly?)

If you don't align the size of the primary/secondary : the swap procedure fails to clear the mcuboot trailer (because its size is not aligned for erase?), and your 2 slots will flip-flop on reboot....

When you are trying to use every last byte of the internal flash for your app (eg because the wifi stack is taking up 3/4 of the flash....) then the temptation is to avoid any wasted space... but the alignment needs to be there as the mcuboot code doesn't cope otherwise....

[BrianW]

just to help anoyone else, here's my pm_static.yml and prj.conf for mcuboot (for sysbuild use). 

pm_static.yml

mcuboot:
    address: 0x0
    end_address: 0x11000
    region: flash_primary
    affiliation: 
        - mcuboot
    size: 0x11000

mcuboot_pad:
    # should be aligned on CONFIG_FPROTECT_BLOCK_SIZE (0x4000 on nrf5340) boundry to allow FPROTECT to be enabled
    # and AT minimum on 0x1000 sector size for erase needs (otherwise DFU (move algo) will NOT WORK)
    address: 0x11000
    end_address: 0x11200
    region: flash_primary
    affiliation: 
        - mcuboot
    size: 0x200

app:
    address: 0x11200
    end_address: 0x100000
    region: flash_primary
    size: 0xeee00

mcuboot_primary_app:
    address: 0x11200
    end_address: 0x100000
    region: flash_primary
    affiliation: 
        - mcuboot
    size: 0xeee00
    span: [app]

mcuboot_primary:
    address: 0x11000
    end_address: 0x100000
    region: flash_primary
    affiliation: 
        - mcuboot
    size: 0xef000
    span: [mcuboot_pad, app]

# define partition for fatfs disk, on the external flash storage (probably the device defined by nordic,pm-ext-flash in the DTS)
fatfs_storage:
    region: external_flash
    affiliation: 
        - disk
    extra_params: {
        disk_name: "NAND",
        disk_cache_size: 4096,
        disk_sector_size: 512,
        disk_read_only: 0
    }
    # 6Mb size, external flash is 8Mb total
    address: 0x0
    size: 0x600000

nvs_storage:
    region: external_flash
    affiliation: 
        - nvs
    # 64kB size, its just for small stuff
    address: 0x600000
    size: 0x10000

mcuboot_secondary_1:
    region: external_flash
    affiliation: 
        - mcuboot
    # 256kb size, its for netcore flash image
    address: 0x610000
    size: 0x40000

mcuboot_secondary:
    region: external_flash
    affiliation: 
        - mcuboot
    address: 0x650000
    # MUST be same size as the 'mcuboot_primary' slot size, and share_size does not appear to work
    size: 0xef000
    #share_size: [mcuboot_primary]

# get next slot to be aligned on 0x4000
PAD1_END:
    region: external_flash
    address: 0x73f000
    size: 0x1000

# allow wifi patches to be updated by mcuboot
nrf70_wifi_fw_mcuboot_pad:
    region: external_flash
    address: 0x740000
    size: 0x200
    #device: MX25R64

nrf70_wifi_fw:
    region: external_flash
    # 128kB size for the wifi fw (-0x200 bytes, the mcuboot pad so that total is aligned on 0x1000 - and 0x4000 - to keep mcuboot happy), 
    address: 0x740200
    size: 0x1fe00

mcuboot_primary_2:
    region: external_flash
    orig_span: &id003
    - nrf70_wifi_fw_mcuboot_pad
    - nrf70_wifi_fw
    span: *id003
    address: 0x740000
    affiliation: 
        - mcuboot
    size: 0x20000
    #device: MX25R64

mcuboot_secondary_2:
    region: external_flash
    address: 0x760000
    affiliation: 
        - mcuboot
    size: 0x20000
    #device: MX25R64

# remaining external flash space starts at 0x78000

# need fake flash ram flash partition to do cpunet DFU...
mcuboot_primary_1:
    region: ram_flash
    address: 0x0
    affiliation: 
        - mcuboot
    size: 0x40000
    device: flash_ctrl
    #  end_address: 0x40000
    #  device: nordic_ram_flash_controller

ram_flash:
  address: 0x40000
  end_address: 0x40000
  region: ram_flash
  size: 0x0

# internal cuisine
#otp:
#    address: 0xff8100
#    end_address: 0xff83fc
#    region: otp
#    size: 0x2fc
#pcd_sram:
#    address: 0x20000000
#    end_address: 0x20002000
#    region: sram_primary
#    size: 0x2000
#rpmsg_nrf53_sram:
#    address: 0x20070000
#    end_address: 0x20080000
#    region: sram_primary
#    size: 0x10000
#sram_primary:
#    address: 0x20002000
#    end_address: 0x20070000
#    region: sram_primary
#    size: 0x6e000

sysbuild/mcuboot/proj.conf

CONFIG_NCS_APPLICATION_BOOT_BANNER_STRING="MCUboot"

CONFIG_FLASH=y

# Want the following functionality, but to fit in 64kB!
# Want the following functionality, but to fit in 64kB!
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_BOOT_SERIAL_NO_APPLICATION=y
CONFIG_USB_DEVICE_MANUFACTURER="Acme Ltd"
CONFIG_USB_DEVICE_PRODUCT="CC2"
# USB VID is MCS electronics, who sell individual PIDs. Cheap to get a PID...
CONFIG_USB_DEVICE_VID=0x16D0
CONFIG_USB_DEVICE_PID=0x1234
# no functional need for USB HID emulation (and its a big chunk of code)
CONFIG_USB_DEVICE_HID=n
CONFIG_USB_MASS_STORAGE=n

CONFIG_BOOT_MAX_LINE_INPUT_LEN=8192
CONFIG_BOOT_SERIAL_MAX_RECEIVE_SIZE=4096
#CONFIG_CDC_ACM_BULK_EP_MPS=512

# DFU by holding down a button at boot time (mcuboot-button0 alias in DTS)
CONFIG_BOOT_SERIAL_ENTRANCE_GPIO=y
CONFIG_MCUBOOT_INDICATION_LED=y

CONFIG_BOOT_MAX_IMG_SECTORS=256
#FPROTECT is n as current primary pad is not aligned on 0x4000 boundary
CONFIG_FPROTECT=n
CONFIG_BOOT_BOOTSTRAP=y
# want to update CPU-NET image
# not allowed with sysbuild CONFIG_NETCORE_APP_UPDATE=y

CONFIG_MAIN_STACK_SIZE=10240
# Set QSPI flash layout configuration
CONFIG_NORDIC_QSPI_NOR=y
CONFIG_NORDIC_QSPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16

# Now in sysbuild.conf
#CONFIG_BOOTLOADER_MCUBOOT=y
#CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
#CONFIG_BOOT_SIGNATURE_KEY_FILE="/work/dev/if-device-nrf53/keys/bootloader_priv-ecdsa256.pem"
#CONFIG_BOOT_SWAP_USING_MOVE=y

# allow update of CPU-NET image (image 1)
#CONFIG_NRF53_MCUBOOT_PRIMARY_1_RAM_FLASH=y
#CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
#CONFIG_ADD_MCUBOOT_MEDIATE_SIM_FLASH_DTS=y
# The network core cannot access external flash directly. The flash simulator must be used to
# provide a memory region that is used to forward the new firmware to the network core.
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n

CONFIG_MCUBOOT_SHELL=n

CONFIG_DEBUG_COREDUMP=n
CONFIG_DEBUG_COREDUMP_BACKEND_LOGGING=n
CONFIG_DEBUG_COREDUMP_MEMORY_DUMP_MIN=n

# Use minimal C library instead of the Picolib
CONFIG_MINIMAL_LIBC=y
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=n

#CONFIG_BOOT_ECDSA_TINYCRYPT=y

CONFIG_DEBUG=n
CONFIG_DEBUG_INFO=n

CONFIG_THREAD_NAME=n
CONFIG_THREAD_ANALYZER=n
CONFIG_SYS_HEAP_RUNTIME_STATS=n
CONFIG_INIT_STACKS=n
CONFIG_ASSERT=n
CONFIG_ASSERT_VERBOSE=n
CONFIG_ASSERT_NO_MSG_INFO=y
CONFIG_ASSERT_NO_COND_INFO=y
CONFIG_ASSERT_NO_FILE_INFO=y
CONFIG_STACK_SENTINEL=n
CONFIG_RESET_ON_FATAL_ERROR=y
CONFIG_REBOOT=y

# could turn off serial and uart console to save space when no logging required... but need them on to get printk()
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
CONFIG_LOG_MODE_MINIMAL=n
# BUT hack in bootloader/mcuboot/boot/bootutil/include/bootutil/bootutil_log.h to send logs to printk() directly

#CONFIG_LOG_MODE_IMMEDIATE=y
#CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_DEFAULT_LEVEL=3
CONFIG_LOG_PRINTK=n
CONFIG_SHELL=n
CONFIG_SHELL_MINIMAL=n

CONFIG_SHELL_LOG_BACKEND=n
CONFIG_NCS_SAMPLES_DEFAULTS=n
CONFIG_NO_RUNTIME_CHECKS=y

CONFIG_MBEDTLS_LOG_LEVEL_ERR=y
CONFIG_KERNEL_LOG_LEVEL_ERR=y
CONFIG_I2C_LOG_LEVEL_ERR=y
CONFIG_GPIO_LOG_LEVEL_ERR=y
CONFIG_UART_LOG_LEVEL_ERR=y
CONFIG_PINCTRL_LOG_LEVEL_ERR=y
CONFIG_FLASH_LOG_LEVEL_ERR=y
# only enable error level logs for usb, as lots of warnings....
CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y

CONFIG_GPIO=y
CONFIG_I2C=y
CONFIG_GPIO_MCP230XX=y

CONFIG_BT=n
CONFIG_WIFI=n
CONFIG_NFC_T2T_NRFXLIB=n
CONFIG_NFC_T4T_NRFXLIB=n
CONFIG_NFC_T4T_ISODEP=n
CONFIG_NFC_NDEF=n
CONFIG_USE_SEGGER_RTT=n
CONFIG_SPI=n
CONFIG_I2S=n
CONFIG_PWM=n
CONFIG_CJSON_LIB=n
CONFIG_JSON_LIBRARY=n
CONFIG_APP_EVENT_MANAGER=n
CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=0

CONFIG_BOOT_BANNER=n
CONFIG_TICKLESS_KERNEL=n
CONFIG_TIMEOUT_64BIT=n
CONFIG_NRF_ENABLE_ICACHE=n

# Enable LTO
CONFIG_ISR_TABLES_LOCAL_DECLARATION=y
CONFIG_LTO=y

and the sysbuild.conf for completeness

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

# build of dfu packages
#SB_CONFIG_SUPPORT_NETCORE=y
#SB_CONFIG_SECURE_BOOT=y
#SB_CONFIG_SECURE_BOOT_NETCORE=y

#SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_BUILD=y
#SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_APP=y
#SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_NET=y
#SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_WIFI_FW_PATCH=y

#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