DFU using USB file system (not serial emulation)?

RE: DFU using USB file system (not serial emulation)?

Hung Bui — Thu, 13 Mar 2025 15:26:07 GMT

Thanks Brian. I have forwarded the request to the team. Will keep you updated.

RE: DFU using USB file system (not serial emulation)?

BrianW — Wed, 12 Mar 2025 21:43:06 GMT

[quote userid="2121" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/526963"]Your request is to have multiple image confirm in mcuboot.c and the implementation of the same functionality in dfu_target , correct? [/quote]

Yes, thats right. It would be much more coherent to have the confirmation function the dfu_target module (given dfu_target always does the DFU as 'test', it is required to do the confirmation post DFU)

Currenrly I can do the multi-image confirm using the mcuboot.c exposed function, but there is NO boot_is_img_confirmed_multi() function available which would mean it has to be confirmed every boot by the app.. I have dealt with the issue just now by using the existing boot_is_img_confirmed() for image 0 , and the mcuboot_swap_type_multi() function to detect if the other images are confirmed:

/** check if a specific image is confirmed ok

* This should be a function in mcuboot.c/bootutil_public.c

static bool _boot_is_img_confirmed_multi(int image_index) {

// Only got a 'proper' fn to check for confirmed for image 0, otherwise we use a hack

if (image_index==0) {

return boot_is_img_confirmed();

}

// Check what mcuboot says it would do on next boot - if any action other than NONE then the image is not confirmed

return (mcuboot_swap_type_multi(image_index)==BOOT_SWAP_TYPE_NONE);

}

But this should be in mcuboot.c and check the swap image ok status properly...

RE: DFU using USB file system (not serial emulation)?

Hung Bui — Wed, 12 Mar 2025 14:00:36 GMT

Hi Brian,
Sorry for the late reply.
Your finding is correct. The slot partition has to be aligned to the page size. I don't have much insight on MCUBoot (it's not made by us) but for our bootloader in nRF5 SDK the main reason is for block/page erasing. If it's not page aligned, it's more complex to prepare the area for receiving, swapping image.

I agree that the MCUBoot documentation should be improved. It's sufficient for simple application when user just follow the default setting. But if they want to modify something or optimize the configuration they will have to study the code to find more info.

Regarding your request on dfu_target_mcuboot_is_img_confirmed_multi,dfu_target_mcuboot_img_confirm_multi . My understanding is that in the current implementation of the dfu_target we don't handle the confirmation of the image at all. And you have to do image confirmation by usuing mcuboot.c . Your request is to have multiple image confirm in mcuboot.c and the implementation of the same functionality in dfu_target , correct?

RE: DFU using USB file system (not serial emulation)?

BrianW — Tue, 11 Mar 2025 16:49:49 GMT

So.... 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).

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

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 of the particion : 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....

Here's my new pm_static.yml : note the 'app' is not an aligned size, but both mcuboot_primary and mcuboot_secondary are...

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

And with this layout that critically aligned the size of the mcuboot_secondary on a flash erase boundary, the mcuboot 'swap-using-move' procedure plus the call to boot_write_img_confirmed_multi() mean that the image no longer flip flops on each boot!

This should really be in the mcuboot/bootloader doc as its a critical point and not obvious....

by the way, it would be nice if in the dfu_target subsystem dfu_target_mcuboot.c provided the required multi-image confirmation functions

dfu_target_mcuboot_is_img_confirmed_multi(int img_num)

dfu_target_mcuboot_img_confirm_multi(int img_num)

RE: DFU using USB file system (not serial emulation)?

BrianW — Tue, 11 Mar 2025 08:43:04 GMT

[quote userid="2121" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/507937"]

If I confirm the image instead, next boot is like this:

[/quote]

Having read thru the mcuboot bootutil_public.c boot_swap_type_multi() code, which uses the boot swap tables arrayu to decide what should happen at boot time, I agree that if the secondary magic is GOOD, then it WILL be used to swap (either as test or perm). So, as after the DFU the secondary is the ex-primary, this implies the PRIMARY must have magic=UNSET (means all 0xff for empty flash) before we start DFU.

If I look at you 'post successful DFU' screenshot, I note the primary has magic=GOOD -> so if you do the DFU step again in future, the secondary will end up with good magic, and the DFU will rollback!

So.... who/where/how should the magic of the current primary be cleared? I would think this could be done when the code confirms that the new DFU target is in place in the secondary slot?

This is the call that does that

dfu_target_mcuboot.c : dfu_target_mcuboot_schedule_update(img_num);

-> calls

dfu_target_mcuboot.c : dfu_target_mcuboot_schedule_one_img(img);

-> calls

mcuboot.c : boot_request_upgrade_multi(img_num, BOOT_UPGRADE_TEST);

-> calls (as BOOT_UPGRADE_TEST=0)

bootutil_public. : boot_set_pending_multi(img, 0);

-> calls

bootutil_public. : boot_set_next(<flash area of secondary slot for img>, false, false); -> this is not the active image, and we don't confirm it

In here, if your secondary slot magic is already GOOD, it does... nothing.

As we have just updated the secondary slot with the new firmware using dfu_target, the magic should be UNSET.

In this case, it writes the good magic, and leaves image ok as unset (because its not a confirmed ie permanent move). It also writes the 'swap_type' in the trailer to TEST based on this flag.

It does NOT do anything to the primary's magic slot....

Do you agree therefore that this will work for a DFU once, but the 2nd time we have the magic=good on the primary and this will cause the flip flop for subsequent cases? Or do I miss something I should do?

RE: DFU using USB file system (not serial emulation)?

BrianW — Mon, 10 Mar 2025 17:59:47 GMT

So... I come back to this dfu issue after several weeks (months) of having fun migrating to NCS2.9, dealing with sysbuild etc....

Now, I have 3 image slots, for the app, CPU-NET (its a nrf5340) and the wifi firmware (because the wifi code is so big I needed to push the wifi fw (78kb!) out to my external flash).

First moan : the dfu_target_xx subsystem (supposed to hide the bootloader from me) lacks both a 'check if image is confirmed' and a 'confirm the primary slot of an image is good' method. So I have to go directly to the mcuboot methods to do this anyway (but we already noted the failing of the dfu_target API in the thread above...)

Second moan : the mcuboot api (exposed in include/zephyr/dfu/mcuboot.h) contains a multi-image compatible call to confirm an image (boot_write_img_confirmed_multi(image_number)), but not a function to check if the image is already confirmed (to avoid writing to the mcuboot header at every boot...): there is boot_is_img_confirmed() but not boot_is_img_confirmed_multi(imgage_number). WHY OH WHY? and there isn't even the function in bootutil.c (which mcuboot.c delegates all the multi-image stuff to...)

So I have to add my own function to bootloader/mcuboot/boot/bootutil/src/bootutil_public.c (as this is the code that has the mapping table for the image number->flash area id....). Not great for future NCS updates....

Now, with sysbuild when I flash the merged.hex, the initial state of the slots is

*** 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=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 0, Swap type: none

Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 1, Swap type: none

Primary image: magic=good, swap_type=0x0, copy_done=0x1, image_ok=0x1
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 2, Swap type: none

Bootloader chainload address offset: 0x11000

Only the primary slots for images 0 and 2 are relevant, as they have been written from the merged.hex.

Immediately we can see that the build sets the magic of the application image (0) primary slot to be UNSET, while the nrf70 wifi fw (2) primary slot has magic=good!

But lets see if updating the NCS2.9 has fixed the mcuboot 'confirmation' issue. I remove my 'break the secondary image code', and make it confirm att 3 slots as 'ok' after 30s of execution....

When I DFU the wifi fw in image 2, it all works ok :

*** 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=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 0, Swap type: none

Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 1, Swap type: none

Primary image: magic=good, swap_type=0x0, copy_done=0x1, image_ok=0x1
Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 2, Swap type: test
Starting swap using move algorithm.

applicaiton then runs, my code then confirms all images as ok using the mcuboot function aftre 30s.

on next reboot:

*** 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=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 0, Swap type: none

Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 1, Swap type: none

Primary image: magic=good, swap_type=0x0, copy_done=0x1, image_ok=0x1
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 2, Swap type: none

The image 2 secondary slot has had its magic 'unset' and the swap_type set to NONE (1). So, no reverting.

BUT: when I do exactly the same operation for the application, the 'confirmation' does not work:

*** 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=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 0, Swap type: test

Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 1, Swap type: none

Primary image: magic=good, swap_type=0x0, copy_done=0x1, image_ok=0x1
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 2, Swap type: none

Starting swap using move algorithm.
Bootloader chainload address offset: 0x11000

-> update done ok
after 30s my code confirms the images, exactly as it did for the wifi fw.
[00:00:30.417,694] <inf> app: Boot : confirmed image 0 ok to mcuboot
[00:00:30.417,816] <wrn> app: Boot : failed to confirm mcuboot image 1 as ok (-5)
[00:00:30.418,182] <inf> app: Boot : image 2 is already flagged as ok to mcuboot

reboot:

*** 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=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 0, Swap type: test

Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 1, Swap type: none

Primary image: magic=good, swap_type=0x0, copy_done=0x1, image_ok=0x1
Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
Boot source: none
Image index: 2, Swap type: none
Starting swap using move algorithm.

And we're back to flip-flop between the 2 slots at each reboot.

In the wifi case, I don't see what code has set the secondary slot's magic to unset, which is the differnce between the wifi and the app cases... I'm wondering if its actually the wifi setup firmware loader code?

Any ideas?

RE: DFU using USB file system (not serial emulation)?

BrianW — Tue, 29 Oct 2024 07:57:38 GMT

I don't think I explicitly set the magic to good anywhere... the code only does the call to say 'image ok' once it runs...

And if we have done a successful update (secondary->primary), the primary will then have a good magic (because it was a good secondary), so for the next update both primary and secondary have magic=good...

I thought the magic was just to let mcuboot know that the image is a legitimate mcuboot image, and its set by the build process?

RE: DFU using USB file system (not serial emulation)?

Hung Bui — Fri, 25 Oct 2024 12:35:28 GMT

Hi Brian,

Sorry for the late response.
I took a look at your result again. It seems that what you have:
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3

Matched with this scenario:
{
.magic_primary_slot = BOOT_MAGIC_ANY,
.magic_secondary_slot = BOOT_MAGIC_GOOD,
.image_ok_primary_slot = BOOT_FLAG_ANY,
.image_ok_secondary_slot = BOOT_FLAG_UNSET,
.copy_done_primary_slot = BOOT_FLAG_ANY,
.swap_type = BOOT_SWAP_TYPE_TEST,
},

You have magic_secondary_slot = good, image_ok_secondary =0x3 (UNSET) the rest is just any so it match and it explains why the swap type is test instead of non and it will be swapped.

Here is what I have in my test, first when I send the test image:

It matched with the scenario above => swap test.

Then if I don't do anything, it will revert:

{

.magic_primary_slot = BOOT_MAGIC_GOOD,

.magic_secondary_slot = BOOT_MAGIC_UNSET,

.image_ok_primary_slot = BOOT_FLAG_UNSET,

.image_ok_secondary_slot = BOOT_FLAG_ANY,

.copy_done_primary_slot = BOOT_FLAG_SET,

.swap_type = BOOT_SWAP_TYPE_REVERT,

},

If I confirm the image instead, next boot is like this:

So it's very important that the secondary image's magic should be unset and the primary image_ok is set.
What I noticed in my case is that at the beginning before the first test swap, the primary image's magic is unset. This is very important. The primary image magic will be come the secondary image magic after the swap (it follows the image). So if at the beginning you already set the primary image magic to set, it may result in what you observed.
The only difference in my no swap booting is the secondary magic is unset (and swaptype =0x01 but that's not important in my opinion).
Please take a look and check why you have both image magic = good.

RE: DFU using USB file system (not serial emulation)?

BrianW — Wed, 16 Oct 2024 07:38:47 GMT

[quote userid="134465" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/505941"]Hopefully fresh eyes will let you see what the corner case is that stops it doing what is expected..[/quote]

Anything on why mcuboot feels the need to revert?

[quote userid="134465" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/505976"]Did you have any idea about why the FPROTECT doesnt like my flash layout above??[/quote]

Or why FPROTECT complains now that the partition sizes are (normally) aligned as required?

RE: DFU using USB file system (not serial emulation)?

BrianW — Sat, 12 Oct 2024 09:53:28 GMT

Did you have any idea about why the FPROTECT doesnt like my flash layout above??

thanks!

RE: DFU using USB file system (not serial emulation)?

BrianW — Fri, 11 Oct 2024 15:33:34 GMT

[quote userid="2121" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/505935"]But having to erase 2nd slot doesn't sound like a best option. [/quote]

Totally agree.

[quote userid="2121" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/505935"]I would suggest to check the code where the logic for deciding reverting in MCUBoot to see why it revert. [/quote]

Well, I was hoping to avoid debugging mcuboot... especially as I am using the standard high level api calls to do the DFU (dfu_target) and mark the image as ok...

MCUBoot logic is convoluted, to say the least. I have gone through it at least twice, and my understand is that is image_ok is SET and the magic is GOOD, then it should NOT revert....

Hopefully fresh eyes will let you see what the corner case is that stops it doing what is expected...

RE: DFU using USB file system (not serial emulation)?

Hung Bui — Fri, 11 Oct 2024 15:13:03 GMT

Hi Brian,
I haven't got the time to look into this yet.
But having to erase 2nd slot doesn't sound like a best option.

I would suggest to check the code where the logic for deciding reverting in MCUBoot to see why it revert. Also try to do a normal DFU with BLE or UART for example, and see how the image _magic and image _ok are written on first boot and on the second boot.
Will try to find time to look into this next week.

RE: DFU using USB file system (not serial emulation)?

BrianW — Thu, 10 Oct 2024 08:59:17 GMT

Hi,

Yes, thats what confuses me. At boot mcuboot tells me what its found:

*** Booting nRF Connect SDK 3758bcbfa5cd ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xe000

[quote userid="2121" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/505634"]In your case if magic_primary_slot=BOOT_MAGIC_GOOD and image_ok_primary_slot= BOOT_FLAG_SET then I don't see why it would do a revert. [/quote]

And as you can see it has that, so it SHOULD NOT REVERT : and yet it does.

Work around (but not a good long term solution) : I destroy the secondary slot by running a fake dfu_target process on it with just 1 buffer of 0's (which essentially makes the image invalid) -> mcuboot is forced to stay with my new primary).

Not very satisfactory, as it means I have no rollback later....but at least it stops it flip flopping at every boot!

RE: DFU using USB file system (not serial emulation)?

Hung Bui — Wed, 09 Oct 2024 19:42:24 GMT

Hi Brian,
I was looking at this line https://github.com/mcu-tools/mcuboot/blob/main/boot/bootutil/src/bootutil_public.c#L534

But the magic of the slot was not BOOT_MAGIC_UNSET ? I assume it's BOOT_MAGIC_GOOD?

As far as I know at the first boot, the new image should already be in the primary slot and the old image should be in the secondary (test swap).

There are 3 scenarios where action (new swap) need to be taken as in here.
In your case if magic_primary_slot=BOOT_MAGIC_GOOD and image_ok_primary_slot= BOOT_FLAG_SET then I don't see why it would do a revert.

RE: DFU using USB file system (not serial emulation)?

BrianW — Wed, 09 Oct 2024 12:57:52 GMT

[quote userid="2121" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/505522"]Please make sure you give the application enough time to write to flash before reset. [/quote]

yes, I give it at least 10s and this appears ot be ok as mcuboot sees image_ok as 0x1 after the reboot.

RE: DFU using USB file system (not serial emulation)?

BrianW — Wed, 09 Oct 2024 12:32:08 GMT

[quote userid="2121" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/505522"]As far as I know you only need to call boot_write_img_confirmed() in the application at its first boot after the swap then it should be permanent. [/quote]

Yes, that was my understanding. My code calls

ret = boot_write_img_confirmed();

exactly as per the sample. However the swap_type remains as BOOT_SWAP_TYPE_TEST - as far as I can see the bootutil code for boot_set_next() just updates the image_ok flag to SET...

(inspecting the bootutil code on the mcu github)

Where do you see the swap_type being updated?

RE: DFU using USB file system (not serial emulation)?

Hung Bui — Wed, 09 Oct 2024 10:48:18 GMT

Hi Brian,

As far as I know you only need to call boot_write_img_confirmed() in the application at its first boot after the swap then it should be permanent.

You can find the call in the \nrf\samples\bluetooth\mesh\dfu\target sample. Where we call dfu_target_image_confirm() after bluetooth initialized.

From what I can see in the code swap type should be set to

swap_type = BOOT_SWAP_TYPE_PERM;

in boot_write_img_confirmed-> boot_set_next()

Could you confirm you call dfu_target_image_confirm() in the application after the first boot after swapping ?
Please make sure you give the application enough time to write to flash before reset.

RE: DFU using USB file system (not serial emulation)?

BrianW — Wed, 09 Oct 2024 09:45:28 GMT

After a look at the mcuboot bootutil code, I understand that the value 0x1 means "SET" and 0x3 means "UNSET". So at boot, copy_done=SET, image_ok=SET for primary slot.

And as I understand the algorithm of mcuboot, ths should mean that even though the swap_type=0x2 (TEST), it should NOT swap to the secondary slot (unless my code expliclty asked for this as part of DFU - which it didn't).

So, why did mcuboot swap in this case?

RE: DFU using USB file system (not serial emulation)?

BrianW — Wed, 09 Oct 2024 09:04:50 GMT

Post update : once mcuboot has sucessfully swapped the slots, it runs the new image - great.

But at the next boot, it swaps back, as it had done the swap in 'test' mode... and then next boot it swaps again...

Normally, to stop this 'revert', I understand from the mcuboot doc that the new image must make itself as 'good'. No thanks to the mcuboot doc page (which says nothing about how to do this), it seems this should be as simple as a call to

boot_write_img_confirmed();

(definition in zephyr/dfu/mcuboot.h)

So, I set a timer, and 60s after boot it pops and I call this method. return is 0, so success.

And on the next reset, mcuboot does indeed see the image_ok flag as 0x1 which (according to the doc) is OK.

But... it swaps anyway

*** Booting nRF Connect SDK 3758bcbfa5cd ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xe000

I guess this is because although primary image slot is OK, the secondard slot is also still OK, and it didn't set its flag to know ifs the old version or that the 'test' swap was really OK? ALso, image_ok=0x3 - can't find the doc that says what this value is : 0x1 or 0xFF are the only values noted....

The mcuboot doc (https://docs.nordicsemi.com/bundle/ncs-2.6.2/page/mcuboot/design.html#image_swapping) implies that mcuboot itself should set the magic of the secondary slot to None, to disable it... I would have thought this would be when I call the confirmed() function.... but clearly this has not happend.

Do I need to overwrite the secondary slot image header myself to remove the revert?

RE: DFU using USB file system (not serial emulation)?

BrianW — Mon, 07 Oct 2024 08:36:52 GMT

[quote userid="134465" url="~/f/nordic-q-a/115046/dfu-using-usb-file-system-not-serial-emulation/505001"]

but it doesn't mention having to set a buffer for mcuboot before the call to dfu_target_init()

And nowhere in dfu_target.c does it do this?!

What is the point of having a 'standard' api dfu_target to mask the different 'targets', if app has to explicitly call a target specific function to get it to work? And not described in the doc either?

[/quote]

So... I changed my code to just use the dfu_target_mscuboot_XXX API directly. This all seems to work just fine, except that after dfu_target completes (with no errors), mcuboot still refuses to update from the secondary slot : the relevant logs:

[00:00:00.544,769] <inf> base: dfu: opened app_update.bin, image type identified as mcuboot
[00:00:00.555,236] <inf> base: dfu: starting update of image for app_update.bin
Copying to secondard slot.................................................................................................................................................................................................................................. DONE
[00:00:27.828,277] <inf> dfu_target_mcuboot: MCUBoot image-0 upgrade scheduled. Reset device to apply
[00:00:27.838,562] <inf> base: dfu: no image file for net_core_app_update.bin
[00:00:27.846,130] <wrn> base: dfu : found new images, rebooting in 5s to update....see you on the other side...
Rebooting...

*** Booting nRF Connect SDK 3758bcbfa5cd ***
I: Starting bootloader
W: Cannot upgrade: not a compatible amount of sectors
I: Bootloader chainload address offset: 0xe000

After a search on this forum, I found this:

https://devzone.nordicsemi.com/f/nordic-q-a/94313/mcuboot-runtime-error-cannot-upgrade-not-a-compatible-amount-of-sectors-with-external-flash-on-nrf9160

Turns out that the size of the secondard slot MUST be exactly equal to the primary (not just bigger), and that a) this is not enforced at build time and b) the share_size directive does not work in your pm_static.yml.

[as an aside, I note that post was over 2 years ago, and the information about these 2 points was supposed to being fed back to developers.... but still no fix or even any documentation....]

Making my mcuboot_secondary partition be the same size as the mcuboot_primary_app one fixed the mcuboot log and now I get:

............................................................................................................................................................................................................................ DONE
[00:00:27.582,580] <inf> dfu_target_mcuboot: MCUBoot image-0 upgrade scheduled. Reset device to apply
[00:00:27.592,864] <inf> base: dfu: no image file for net_core_app_update.bin
[00:00:27.600,402] <inf> base: dfu :System write boot ok flag to NVM
[00:00:27.607,360] <wrn> base: dfu : found new images, rebooting in 5s to update....
[00:00:30.319,671] <inf> base: System running ok, write boot ok flag to NVM
Rebooting...see you on the other side...

*** Booting nRF Connect SDK 3758bcbfa5cd ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xe000

And miracle : a working DFU from USB filesystem!

For those also looking to do this:

the 'dfu from local file' fn (call it with the name of the file on the FS, and reboot if it returns true). You will need to implement the usb_fs_XX functions, but these are just wrappers round the FAT FS fs_XX api.

// DFU related code
static void _dfu_cb(enum dfu_target_evt_id evt_id) {
	log_info("dfu: callback says event %d", evt_id);
}

// read blocks of 4K from fle and pass to DFU updater
// Returns false if couldn't access or dfu the given file 
#define DFU_BUF_SZ	(4096)
static bool _do_dfu(char* filename, int img_num) {
	int32_t fsize = usb_fs_get_file_size(filename);
	if (fsize<0) {
		log_info("dfu: no image file for %s",filename);
		return false;
	}
	file_handle_t fh = usb_fs_open_file(filename, true);	// open in read only
	if (fh==NULL) {
		log_warn("dfu : failed to open file %s", filename);
		return false;
	}
	uint8_t* buf = Util_amalloc(DFU_BUF_SZ);
	if (buf==NULL) {
		usb_fs_close_file(fh);
		log_warn("dfu : failed to alloc buffer to read %s", filename);
		return false;
	}
	uint32_t buf_sz = 0;
	// Read first block to let dfu analyse file type
	buf_sz = usb_fs_read_file(fh, buf, DFU_BUF_SZ);
	if (buf_sz!=DFU_BUF_SZ) {
		// image file must be > 4K so if fail to read then give up
		usb_fs_close_file(fh);
		Util_afree(buf);
		log_warn("dfu : failed to read 4K from file %s, %d", filename, buf_sz);
		return false;
	}
	if (!dfu_target_mcuboot_identify(buf)) {
		usb_fs_close_file(fh);
		Util_afree(buf);
		log_warn("dfu : file %s is not an mcuboot image, cannot DFU", filename);
		return false;
	}
	log_info("dfu: opened %s, image type identified as mcuboot", filename);
	dfu_target_mcuboot_reset();	// always start from beginning as not downloading

	// Give it a scratch buffer for flash writing
	uint8_t* mcuboot_buf = Util_amalloc(DFU_BUF_SZ);
	dfu_target_mcuboot_set_buf(mcuboot_buf, DFU_BUF_SZ);

	int ret = dfu_target_mcuboot_init(fsize, img_num, _dfu_cb);
	if (ret<0) {
		usb_fs_close_file(fh);
		Util_afree(buf);
		Util_afree(mcuboot_buf);
		log_warn("dfu : init for %s image identified as type mcuboot failed code %d", filename, ret);
		return false;
	}
	log_info("dfu: starting update of image for %s", filename);
	printk("Copying to secondard slot.");
	while(buf_sz==DFU_BUF_SZ) {
		// write the block
		int wret = dfu_target_mcuboot_write(buf, buf_sz);
		if (wret==0) {
			// read the next
			buf_sz = usb_fs_read_file(fh, buf, DFU_BUF_SZ);
			printk(".");
		} else {
			buf_sz = wret;
			printk("[WRITE FAIL %d]\n", wret);
		}
	}
	if (buf_sz>0) {
		// Write the final block
		buf_sz = dfu_target_mcuboot_write(buf, buf_sz);
		printk(". DONE\n");
	}
	usb_fs_close_file(fh);
	Util_afree(buf);
	Util_afree(mcuboot_buf);
	if (buf_sz<0) {
		log_warn("dfu : failed during install of file %s, %d", filename, buf_sz);
		dfu_target_mcuboot_done(false);
		// TBD : should we delete the 'bad' bin file? or try again next boot?
		return false;
	}
	// Success! Delete the file (we don't want it hanging about and triggering dfu again next boot time!)
	usb_fs_delete_file(filename);
	int dret = dfu_target_mcuboot_done(true);
	if (dret==0) {
		dret = dfu_target_mcuboot_schedule_update(img_num);
		if (dret==0) {
			return true;
		} else {
			log_warn("dfu : schedule_update() returns error %d, dfu filed for %s", dret, filename);
		}
	} else {
		log_warn("dfu : done() returns error %d, dfu filed for %s", dret, filename);
	}
	return false;
}

And my pm_static.yml also, as this is also a pain in the neck to get right...

mcuboot:
    address: 0x0
    end_address: 0xe000
    region: flash_primary
    size: 0xe000

mcuboot_pad:
    address: 0xe000
    end_address: 0xe200
    region: flash_primary
    size: 0x200

app:
    address: 0xe200
    end_address: 0x100000
    region: flash_primary
    size: 0xf1e00

mcuboot_primary_app:
    address: 0xe200
    end_address: 0x100000
    region: flash_primary
    size: 0xf1e00
    span: [app]

mcuboot_primary:
    address: 0xe000
    end_address: 0x100000
    region: flash_primary
    size: 0xf2000
    span: [mcuboot_pad, mcuboot_primary_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 primary application slot size, and share_size does not appear to work
    size: 0xf1e00
    #share_size: [mcuboot_primary_app]

# internal cuisine
otp:
    address: 0xff8100
    end_address: 0xff83fc
    region: otp
    size: 0x2fc
pcd_sram:
    address: 0x20000000
    end_address: 0x20002000
    #placement:
    #    after:
    #    - start
    region: sram_primary
    size: 0x2000
rpmsg_nrf53_sram:
    address: 0x20070000
    end_address: 0x20080000
    #placement:
    #    before:
    #    - end
    region: sram_primary
    size: 0x10000
sram_primary:
    address: 0x20002000
    end_address: 0x20070000
    region: sram_primary
    size: 0x6e000

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

(you're welcome)

Note app_update.bin is the file generated by the build, and has the mcuboot magic number at the start...

I haven't yet tried the CPUNET update (as you can see the ram flash simulator is still commented out).

RE: DFU using USB file system (not serial emulation)?

BrianW — Fri, 04 Oct 2024 16:15:15 GMT

Still complains:

*** Booting nRF Connect SDK 3758bcbfa5cd ***
I: Starting bootloader
W: Cannot upgrade: not a compatible amount of sectors
I: Bootloader chainload address offset: 0xe000
I: Jumping to the first image slot
E: Protect mcuboot flash failed, cancel startup.

partitions.yml : insert->file "type yml still not allowed."

app:
  address: 0xe200
  end_address: 0x100000
  region: flash_primary
  size: 0xf1e00
external_flash:
  address: 0x750000
  end_address: 0x800000
  region: external_flash
  size: 0xb0000
fatfs_storage:
  address: 0x0
  affiliation:
  - disk
  end_address: 0x600000
  extra_params:
    disk_cache_size: 0x1000
    disk_name: NAND
    disk_read_only: 0x0
    disk_sector_size: 0x200
  region: external_flash
  size: 0x600000
mcuboot:
  address: 0x0
  end_address: 0xe000
  region: flash_primary
  size: 0xe000
mcuboot_pad:
  address: 0xe000
  end_address: 0xe200
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xe000
  end_address: 0x100000
  region: flash_primary
  size: 0xf2000
  span:
  - mcuboot_pad
  - mcuboot_primary_app
mcuboot_primary_app:
  address: 0xe200
  end_address: 0x100000
  region: flash_primary
  size: 0xf1e00
  span:
  - app
mcuboot_secondary:
  address: 0x650000
  affiliation:
  - mcuboot
  end_address: 0x750000
  region: external_flash
  size: 0x100000
mcuboot_secondary_1:
  address: 0x610000
  affiliation:
  - mcuboot
  end_address: 0x650000
  region: external_flash
  size: 0x40000
nvs_storage:
  address: 0x600000
  affiliation:
  - nvs
  end_address: 0x610000
  region: external_flash
  size: 0x10000
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

pm_static.yml

mcuboot:
    address: 0x0
    end_address: 0xe000
    region: flash_primary
    size: 0xe000

mcuboot_pad:
    address: 0xe000
    end_address: 0xe200
    region: flash_primary
    size: 0x200

app:
    address: 0xe200
    end_address: 0x100000
    region: flash_primary
    size: 0xf1e00

mcuboot_primary_app:
    address: 0xe200
    end_address: 0x100000
    region: flash_primary
    size: 0xf1e00
    span: [app]

mcuboot_primary:
    address: 0xe000
    end_address: 0x100000
    region: flash_primary
    size: 0xf2000
    span: [mcuboot_pad, mcuboot_primary_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
    # 1Mb size, its for an application flash image
    address: 0x650000
    size: 0x100000
    #share_size: [mcuboot_primary_app]

# internal cuisine
otp:
    address: 0xff8100
    end_address: 0xff83fc
    region: otp
    size: 0x2fc
pcd_sram:
    address: 0x20000000
    end_address: 0x20002000
    #placement:
    #    after:
    #    - start
    region: sram_primary
    size: 0x2000
rpmsg_nrf53_sram:
    address: 0x20070000
    end_address: 0x20080000
    #placement:
    #    before:
    #    - end
    region: sram_primary
    size: 0x10000
sram_primary:
    address: 0x20002000
    end_address: 0x20070000
    region: sram_primary
    size: 0x6e000

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

ie partition table for internal flash:

flash_primary (0x100000 - 1024kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xe000 - 56kB) |
+---0xe000: mcuboot_primary (0xf2000 - 968kB)-----+
| 0xe000: mcuboot_pad (0x200 - 512B) |
+---0xe200: mcuboot_primary_app (0xf1e00 - 967kB)-+
| 0xe200: app (0xf1e00 - 967kB) |
+-------------------------------------------------+

RE: DFU using USB file system (not serial emulation)?

BrianW — Fri, 04 Oct 2024 15:09:29 GMT

I chose 0xfe00 because the original problem was that mcuboot was too big for the flash size selected by PM (0xc000 = 48kB, mcuboot image is around 53kB...), so I aligned the app start partition nicely on 0x10000 -> which when you take off the 0x200 pad gives 0xfe00.

Sadly the build process and the PM didn't flag up this alignment requirement for FPROTECT...

I will change it to 0xe000 size for mcuboot and see if that lets FPROTECT be happy... with the primary partition therefore at 0xe200.

RE: DFU using USB file system (not serial emulation)?

Hung Bui — Fri, 04 Oct 2024 12:44:22 GMT

Hi again,

You can attach file by clicking Insert -> Image/Video/file

Or you can add code by Insert -> Code

Regarding the mcuboot partition, can you tell why you choose 0xfe00 ( mcuboot end address) and 0x10000 (mcuboot pad end address) ?
The problem of this address is that it doesn't allign with FPROTECT_BLOCK_SIZE ( =NRF_SPU_FLASH_REGION_SIZE = 0x4000).

Could you try again with 0xc000 and 0xc200 respectively or try 0x10000 and 0x10200 respectively.

RE: DFU using USB file system (not serial emulation)?

BrianW — Fri, 04 Oct 2024 12:33:19 GMT

So, now that mcuboot is actually bootingmy code (FPROTECT disabled) I have added

CONFIG_STREAM_FLASH=y

CONFIG_STREAM_FLASH_ERASE=y

CONFIG_DFU_TARGET_STREAM=y

CONFIG_IMG_MANAGER=y

CONFIG_DFU_TARGET_MCUBOOT=y

and using the dfu_target library to copy the contents of app_update.bin to the mcuboot_secondary partition.

However, it failed with this log

"Missing stream_buf, call '..set_buf' before '..init"

as found in dfu_target_mcuboot.c

I use the dfu_target api as described in the doc

https://docs.nordicsemi.com/bundle/ncs-2.2.0/page/nrf/libraries/dfu/dfu_target.html#c.dfu_target_init

but it doesn't mention having to set a buffer for mcuboot before the call to dfu_target_init()

And nowhere in dfu_target.c does it do this?!

RE: DFU using USB file system (not serial emulation)?

BrianW — Fri, 04 Oct 2024 10:31:38 GMT

From pm.config in the build directory:

PM_MCUBOOT_OFFSET=0x0

PM_MCUBOOT_PRIMARY_OFFSET=0xfe00

This is exactly what I expect given my pm_static.yml which starts like:

mcuboot:
    address: 0x0
    end_address: 0xfe00
    #placement:
    #  before:
    #  - mcuboot_primary
    region: flash_primary
    size: 0xfe00

mcuboot_pad:
    address: 0xfe00
    end_address: 0x10000
    #placement:
    #  align:
    #    start: 0xfe00
    #  before:
    #  - mcuboot_primary
    region: flash_primary
    size: 0x200

app:
    address: 0x10000
    end_address: 0x100000
    region: flash_primary
    size: 0xf0000

mcuboot_primary_app:
    address: 0x10000
    end_address: 0x100000
    region: flash_primary
    size: 0xf0000
    #  span: *id002
    span: [app]

mcuboot_primary:
    address: 0xfe00
    end_address: 0x100000
    region: flash_primary
    size: 0xf0200
    #  span: *id001
    span: [mcuboot_pad, mcuboot_primary_app]

I don't see how to attach files to a ticket? Simple drag-n-drop tells me the file type yml is not allowed...

partition_manager_report target gives me:

external_flash (0x800000 - 8192kB):
+-------------------------------------------------+
| 0x0: fatfs_storage (0x600000 - 6144kB) |
| 0x600000: nvs_storage (0x10000 - 64kB) |
| 0x610000: mcuboot_secondary_1 (0x40000 - 256kB) |
| 0x650000: mcuboot_secondary (0xfc000 - 1008kB) |
| 0x74c000: external_flash (0xb4000 - 720kB) |
+-------------------------------------------------+

flash_primary (0x100000 - 1024kB):
+--------------------------------------------------+
| 0x0: mcuboot (0xfe00 - 63kB) |
+---0xfe00: mcuboot_primary (0xf0200 - 960kB)------+
| 0xfe00: mcuboot_pad (0x200 - 512B) |
+---0x10000: mcuboot_primary_app (0xf0000 - 960kB)-+
| 0x10000: app (0xf0000 - 960kB) |
+--------------------------------------------------+

otp (0x2fc - 764B):
+------------------------------+
| 0xff8100: otp (0x2fc - 764B) |
+------------------------------+

sram_primary (0x80000 - 512kB):
+-----------------------------------------------+
| 0x20000000: pcd_sram (0x2000 - 8kB) |
| 0x20002000: sram_primary (0x6e000 - 440kB) |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

CPUNET flash_primary (0x40000 - 256kB):
+--------------------------------------------+
+---0x1000000: b0n_container (0x8800 - 34kB)-+
| 0x1000000: b0n (0x8580 - 33kB) |
| 0x1008580: provision (0x280 - 640B) |
+---0x1008800: app (0x37800 - 222kB)---------+
| 0x1008800: hci_ipc (0x37800 - 222kB) |
+--------------------------------------------+

CPUNET sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x21000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

which is prettier anyway...