Failing to build using sysbuild/NCS2.9.0 with MCUboot for DFU enabled for app/CPU-NET/Wifi fw

[BrianW]

Situation : custom nrf5340/nrf7002 board (very close to production...). Main image is overflowing available internal flash (with a MCUboot 64kB partition).

Secondary slots etc are on 8Mb external flash (QSPI connected)

Up to now, using the 'multi-image build' process (migrated from 2.6->2.8->2.9 in search of stable wifi/networking operation).

I want to move the wifi fw patches (approx 80kB) to the external flash also (CONFIG_WIFI_PATCHES_EXT_FLASH_STORE=y). This forces me to move to sysbuild as the mechanism to generate the required .hex files is not supported in the old mutli-image CMakefiles. This successfully puts the wifi bin file (nrf70.bin) in the external flash... 

The build was working, but then when flashed to the board mcuboot refused to run the app. No error or explanation. I tried updating the partition sizes to let it have 64kB so I could also enable serial download over USB.... and now I cannot get the build to complete.

It fails building mcuboot, with an error indicating that 'PM_MCUBOOT_PRIMARY_1_ID' is not defined.

...

oot/bootutil/src/bootutil_public.c
In file included from C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/sysflash.h:12,
from C:/ncs/v2.9.0/bootloader/mcuboot/boot/bootutil/src/bootutil_public.c:43:
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h: In function '__flash_area_ids_for_slot':
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:20:37: error: 'PM_MCUBOOT_PRIMARY_1_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_2_ID'?
20 | #define FLASH_AREA_IMAGE_1_SLOTS PM_MCUBOOT_PRIMARY_1_ID, PM_MCUBOOT_SECONDARY_1_ID,
| ^~~~~~~~~~~~~~~~~~~~~~~

This is the id for the 'ram-flash' partition that simulates the primary partition for the CPU-NET DFU operation (as explained in the tutorials about DFU). The pm_sysflash.h is I think looking for 2 image slots, instead of the 3 it should expect (app, cpu-net, wifi fw).

The generated pm_config.h indeed does not contain this id, despite it being defined in my pm_static.yml:

# 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

I have the dts controller defined as:

/ {

    soc {

        /* Add a flash controller which has the compatible

         * 'zephyr,sim-flash'. This will ensure that the flash

         * simulator can use it. None of the other properties in this

         * node is used for anything.

         */

        nordic_ram_flash_controller: nordic_ram-flash-controller@0 {

            compatible = "zephyr,sim-flash";

            reg = <0x00000000 DT_SIZE_K(40)>;

            #address-cells = <1>;

            #size-cells = <1>;

            erase-value = <0xff>;

            /* This node label must match that used in the flash

             * simulator.

             */

            flash_sim0: flash_sim@0 {

                status = "okay";

                compatible = "soc-nv-flash";

                erase-block-size = <4096>;

                write-block-size = <4>;

                reg = <0x00000000 DT_SIZE_K(256)>;

                partitions {

                    compatible = "fixed-partitions";

                    #address-cells = <1>;

                    #size-cells = <1>;

                    /* This partition must be defined for

                     * MCUboot to find the partition ID

                     * of the primary slot for image 1,

                     * which is stored in this partition.

                     */

                    slot2_partition: partition@0 {

                        label = "image-2";

                        reg = <0x00000000 0x00000A000>;

                    };

                };

            };

        };

    };

};

(copied from nrf/modules/mcuboot/flash_sim.overlay)

and the entries in the sysbuild/mcuboot/prj.conf to enable the simulator from the nrf5340_exip_image.conf in the same place:

# 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

Why doesn't sysbuild generate the PM defines for the priimary_1 partition? What dependancy did I break?

[AHaug]

Hi,

So, w.r.t this I've stumbled into quite the pitfall that has blocked me.

I've not been able to generate firmware that can handle both appcore, netcore, xip-split and wifi fw patch offloading.

Status: I've based my sample on a very simple wifi sample that offloads the wifi patch to external flash using the XIP-approach. The reason for this is due to the note at https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/app_dev/device_guides/nrf70/nrf70_fw_patch_update.html (which should definetly be placed on the first page as well) stating 

"Currently, you cannot build an example with the both SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE and CONFIG..._XIP_SPLIT_IMAGE Kconfig options enabled. To enable XIP support use the SB_CONFIG_WIFI_PATCHES_EXT_FLASH_XIP Kconfig option instead of the SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE Kconfig option."

From here I've merged this basic sample with the nrf5340/xip_smp_svr sample.

Successful

1. Basic wifi app with fw patch in both internal and external flash
2. Basic 5340_xip_smp app with app, net and xip-dfu support (3 images)
3. Basic wifi + 5340_xip_smp app with fw patch in internal memory with app, net and xip-dfu support (3 images)

Blocked:

1. Basic wifi + 5340_xip_smp app with fw patch in external memory with app, net and xip-dfu support (4 images) both with SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE and SB_CONFIG_WIFI_PATCHES_EXT_FLASH_XIP 

The Issue: As of now it is hardcoded that the maximum amount of updatable images that you can have is 3 images in MCUMGR. Previously it was 2, but to add proper XIP support for the nRF5340 a third image was needed. Now when we have WiFi and WiFi FW patch image added to the mix, MCUMGR detects that we have 4 images and throws the following build warning that throws a build cancellation error

Fullscreen

1

warning: user value 4 on the int symbol UPDATEABLE_IMAGE_NUMBER (defined at C:/ncs/sdk/nrf\samples\common\mcumgr_bt_ota_dfu/Kconfig:89, subsys/dfu/Kconfig:95) ignored due to being outside the active range ([1, 3])

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

warning: user value 4 on the int symbol UPDATEABLE_IMAGE_NUMBER (defined at C:/ncs/sdk/nrf\samples\common\mcumgr_bt_ota_dfu/Kconfig:89, subsys/dfu/Kconfig:95) ignored due to being outside the active range ([1, 3])

It fails building mcuboot, with an error indicating that 'PM_MCUBOOT_PRIMARY_1_ID' is not defined.

I've found that this error comes when you don't have both the configuration to update netcore (SB_CONFIG_SECURE_BOOT_NETCORE=y) as shown here https://github.com/nrfconnect/sdk-nrf/blob/main/samples/nrf5340/extxip_smp_svr/sysbuild.conf, as well as defined the b0n and netcore partitions in pm_static. Or rather, I've found that the error is not thrown when I'm building my sample with the default prj.conf

Goal: If I understand everything here correct, then the following should be possible (and what I'm trying to set up)

1. With SB_CONFIG_WIFI_PATCHES_EXT_FLASH_XIP, the wifi fw patch image should be built as a part of the application itself, and it should be a blob that can be placed within mcuboot_primary_2 (great name), i.e the xip partition on the external flash and simply offloaded to 7002 RAM from there.
2. This means that we reduce the number of updatable images from 4 to 3 and thus satisfy the hard-limit that MCUMGR has on 3 images and thus we can have both app, netcore and xip dfu support

I will share another update tomorrow w.r.t how this is going, and after this I will be on business travel for the coming week

Kind regards,
Andreas