Support for three images in sdk-nrf #12025

de-nordic · 2023-08-11T16:03:21Z

Contains:

additional MCUboot partition definitions for Partition Manager.
update to sdk-mcuboot and sdk-zephyr required for three image support.

Update 2023-08-16 14:57 UTC
The PR, and all other connected PRs, have been updated to the latest sdk-nrf main pointed revisions.
Update 2023-08-17 16:11 UTC
Zephyr PR has been updated to bring in changes from upstream PRs.
Update 2023-08-18 11:10 UTC
Fixed Zephyr PR where one commit has been missing.
Update 2023-08-18 11:16 UTC
Update from main branch to remove merge conflict.
Update 2023-08-18 18:15 UTC
Update from upstream PRs and rebase over main.
Update 2023-08-22 22:10 UTC
Rebase on sdk-nrf main, with all dependent repo changes, and bring in update to commits done upstream.

TODO:

Dependecy fix: currently when setting image dependency, for example image 0 should depend on certain version of its other part to make sure both are swapped into correct slots, the MCUboot fails to verify image even though it swaps them correctly; this requires additional reset to run updated app and makes it impossible to boot into test mode. There have been bug filled for the issue swap_move: boot_read_image_header mixes slot numbers when more than one image is swapped in multi-image configuration mcu-tools/mcuboot#1768
Modify imgtool to support hard-dependency, which is dependency on image hash rather than version.

Testing and building
The configuration has been tested with nrf52840dk using pseudo images for image 1 and 2, as the do not have to boot, although there is no problem with using real applications but without cores to run them there is no point.
As DFU method the smp_svr has been used with static partition definition
pm_static.txt
(the file needs to be copied to zephyr/samples/subsys/mgmt/mcumgr/smp_svr and renamed pm_static.yml prior to building).
The file defines two additional images (four slots) of size 65k (0x10000) where the second and third images would reside, increases MCUboot slot to 65k (that may not be needed, but I was worried that logging may require it) and does not define andy storage.

When three (or two) image configuration is used, MCUboot needs to find valid image in primary slot of every image, otherwise it will refuse to boot. That is why bogus images are created and programmed with the smp_svr sample.

The primary smp_svr is built using command:

west build -d three_smp_svr -b nrf52840dk_nrf52840 zephyr/samples/subsys/mgmt/mcumgr/smp_svr/ -DOVERLAY_CONFIG=overlay-bt.conf -Dmcuboot_CONFIG_MCUBOOT_LOG_LEVEL_DBG=y -Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=3 -DCONFIG_MCUMGR_GRP_FS=n -DCONFIG_MCUMGR_GRP_ZBASIC=n -DCONFIG_UPDATEABLE_IMAGE_NUMBER=3 -DCONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=3 -DCONFIG_MCUBOOT_IMAGE_VERSION=\"1.0.0\" -DCONFIG_MCUMGR_LOG_LEVEL_DBG=y -DCONFIG_MCUMGR_GRP_IMG_LOG_LEVEL_DBG=y -DCONFIG_LOG_MAX_LEVEL=4 -DCONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_IMAGE_ANY=y

where

-Dmcuboot_CONFIG_MCUBOOT_LOG_LEVEL_DBG=y
-DCONFIG_MCUMGR_LOG_LEVEL_DBG=y
-DCONFIG_MCUMGR_GRP_IMG_LOG_LEVEL_DBG=y
-DCONFIG_LOG_MAX_LEVEL=4

are Kconfig settings that increase logging to debug for MCUboot and MCUmgr (can be discarded if not needed),

-Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=3
-DCONFIG_UPDATEABLE_IMAGE_NUMBER=3
-DCONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=3

set support for three images in MCUboot and MCUmgr,

-DCONFIG_MCUMGR_GRP_FS=n
-DCONFIG_MCUMGR_GRP_ZBASIC=n

disable usage of storage, which is not allocated in pm_static.yml used here,

-DCONFIG_MCUBOOT_IMAGE_VERSION=\"1.0.0\"

sets version the three_smp_svr will be signed with, and

-DCONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_IMAGE_ANY=y

allows MCUmgr client to confirm slots of non-running image, which normally is not allowed to prevent confirming something that will not boot, but in this case we are confirming "other part" of image so we need to be able to do that.

When the three_smp_svr is built it can be flashed using, with MCUboot, using:

west flash -d three_smp_svr

But this will unfortunately give us

I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
W: Failed reading image headers; Image=1
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
W: Failed reading image headers; Image=2
E: Unable to find bootable image

as there is no valid application for image 1 and image 2.

For the purpose of testing the bogus applications have been generated:

dd bs=512 if=/dev/zero of=header.bin
dd bs=4096 count=2 if=/dev/urandom of=body1.bin
dd bs=4096 count=2 if=/dev/urandom of=body2.bin
cat header.bin body1.bin > bogus_app_1.bin
cat header.bin body2.bin > bogus_app_2.bin
imgtool sign --align 4 --version "1.0.0" -H 0x200 -S 0x10000 --key bootloader/mcuboot/root-ec-p256.pem bogus_app_1.bin bogus_app_1_1.0.0.signed.bin
imgtool sign --align 4 --version "1.0.0" -H 0x200 -S 0x10000 --key bootloader/mcuboot/root-ec-p256.pem bogus_app_2.bin bogus_app_2_1.0.0.signed.bin
objcopy --change-address 0x90000 -I binary -O ihex bogus_app_1_1.0.0.signed.bin bogus_app_1_1.0.0.signed.moved.hex
objcopy --change-address 0xb0000 -I binary -O ihex bogus_app_2_1.0.0.signed.bin bogus_app_2_1.0.0.signed.moved.hex

Note that both apps have the same slot size, 0x10000, as defined by pm_static.yml, but haxes have different start address as according to pm_static.yml primary slot of image 1 starts at 0x90000 and primary slot of image 2 starts at 0xb0000.
The key used with imgtool is here the default key, as used with building the smp_svr and MCUboot.
Images are programmed with:

nrfjprog --program bogus_app_1_1.0.0.signed.moved.hex --sectorerase --verify
nrfjprog --program bogus_app_2_1.0.0.signed.moved.hex --sectorerase --verify

and after reset we can see:

*** Booting Zephyr OS build v3.4.0-rc3-755-g3692b8989784 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot 

[00:00:00.007,415] <inf> smp_bt_sample: Advertising successfully started
[00:00:00.007,446] <inf> smp_sample: build time: Aug 11 2023 16:26:52
uart:~$

Using the mcumgr-cli image list command, for example:

sudo ~/go/bin/mcumgr -t 1200 --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image list

we will get output for three images

Images:
 image=0 slot=0
    version: 1.0.0
    flags: active confirmed
    hash: 0af547151a433783b2664216c49e80e530bbab3217e6e4989592ccaab0cd73eb
 image=1 slot=0
    version: 1.0.0
    flags: active confirmed
    hash: 7d651232d8661d7257608a6d5dc6c83a633a6c12779a97c53b80c56f8f64f0b9
 image=2 slot=0
    version: 1.0.0
    flags: active confirmed
    hash: 03283f55e4c6ac58116797b4fe7077ffb834220699514702b7ba29e6321f4476
Split status: N/A (0)

hashes will of course be different.

Now it is possible to upload additional images to slots, for example additional smp_svr with different version can be built for slot 0, and uploaded using mcumgr-cli:

mcumgr-cli ... image upload -e -n 0 <alt_smp_svr_singed_bin>

the -e is important as it means that mcumgr-cli should not send separate erase command and -n 0 selects image 0 as target for upload; -n 1 would select image one and so on.

To have a test payload for other images, they can be generated in similar way the hex have been generated:

dd bs=4096 count=1 if=/dev/urandom of=body1a.bin
cat header.bin body1a.bin > bogus_app_1a.bin
imgtool sign --align 4 --version `"1.0.1"` -H 0x200 -S 0x10000 --key bootloader/mcuboot/root-ec-p256.pem bogus_app_1a.bin bogus_app_1_1.0.1.signed.bin

there is no need to generate hex.

NordicBuilder · 2023-08-11T16:03:52Z

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
mcuboot	nrfconnect/sdk-mcuboot@`54319b4`	nrfconnect/sdk-mcuboot#270	nrfconnect/sdk-mcuboot#270/files
zephyr	nrfconnect/sdk-zephyr@`0295622`	nrfconnect/sdk-zephyr#1276	nrfconnect/sdk-zephyr#1276/files

Note: This message is automatically posted and updated by the Manifest GitHub Action.

NordicBuilder · 2023-08-11T16:05:17Z

Test specification

CI/Jenkins/NRF

Integration Platforms

CI/Jenkins/integration

Test Module	File based changes	Manually selected	West overwrite
desktop52_verification	X
test-ci-nrfconnect-boot-fw-update	X
test-fw-nrfconnect-chip	X
test-fw-nrfconnect-fem	X
test-fw-nrfconnect-nfc	X
test-fw-nrfconnect-nrf-iot_cloud	X
test-fw-nrfconnect-nrf-iot_thingy91	X
test-fw-nrfconnect-nrf_crypto	X
test-fw-nrfconnect-rpc	X
test-fw-nrfconnect-rs	X
test-fw-nrfconnect-tfm	X
test-fw-nrfconnect-thread	X
test-fw-nrfconnect-zigbee	X
test-sdk-find-my	X
test-sdk-homekit	X
test-sdk-sidewalk	X

test-ci-nrfconnect-boot-fw-update: added because there was no .github/test-spec.yml in 'mcuboot'

Detailed information of selected test modules

Note: This message is automatically posted and updated by the CI

NordicBuilder · 2023-08-11T16:39:21Z

You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds.

Note: This comment is automatically posted by the Documentation Publishing GitHub Action.

doublemis1 · 2023-08-18T12:50:44Z

Matter plans failed due to issue with mcumgr:
issue while confirming image:

mcumgr --conntype ble -i 1 --connstring peer_name='MatterLock' image confirm d1b94f9cd81bd42690f270920fd723d044ceca71fecbec9f1bb29908424764b5 
output: Error: 3

de-nordic · 2023-08-18T14:30:51Z

Matter plans failed due to issue with mcumgr: issue while confirming image:
mcumgr --conntype ble -i 1 --connstring peer_name='MatterLock' image confirm d1b94f9cd81bd42690f270920fd723d044ceca71fecbec9f1bb29908424764b5 
output: Error: 3

Does this try to confirm running slot?

doublemis1 · 2023-08-18T14:32:17Z

Matter plans failed due to issue with mcumgr: issue while confirming image:
mcumgr --conntype ble -i 1 --connstring peer_name='MatterLock' image confirm d1b94f9cd81bd42690f270920fd723d044ceca71fecbec9f1bb29908424764b5 
output: Error: 3
Does this try to confirm running slot?

Before confirmation the image list looks as follow:

Images:
image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: e7bfb6d23b298eb03f05a724f2d61b8a369edc383fe3a419e8bbfecb0b4d6f2e
image=1 slot=1
    version: 0.0.0
    bootable: true
    flags: 
    hash: d1b94f9cd81bd42690f270920fd723d044ceca71fecbec9f1bb29908424764b5
Split status: N/A (0)

It is only a one image (APP core) in following test steps we do upload another image (NET core) and then we would also confirm the second image.

de-nordic · 2023-08-18T14:40:13Z

Matter plans failed due to issue with mcumgr: issue while confirming image:
mcumgr --conntype ble -i 1 --connstring peer_name='MatterLock' image confirm d1b94f9cd81bd42690f270920fd723d044ceca71fecbec9f1bb29908424764b5 
output: Error: 3
Does this try to confirm running slot?
Before confirmation the image list looks as follow:
Images:
image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: e7bfb6d23b298eb03f05a724f2d61b8a369edc383fe3a419e8bbfecb0b4d6f2e
image=1 slot=1
    version: 0.0.0
    bootable: true
    flags: 
    hash: d1b94f9cd81bd42690f270920fd723d044ceca71fecbec9f1bb29908424764b5
Split status: N/A (0)
It is only a one image (APP core) in following test steps we do upload another image (NET core) and then we would also confirm the second image.

OK, so this must be some bug around CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_IMAGE_SECONDARY=y which is supposed to be y by default.
It was working previously because there was a bug that allowed it and now there is Kconfig, default y, that should make it work as previously.
I will check once more, I am quite sure it worked on my side. Need to check again.

Third image partition names. Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>

Update sdk-mcuboot and sdk-zephyr revisions to bring in changes required for support of three images. Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>

de-nordic · 2023-10-03T15:28:47Z

Changes already in main.

de-nordic added the DNM label Aug 11, 2023

de-nordic requested review from anangl, rlubos, carlescufi and tejlmand as code owners August 11, 2023 16:03

github-actions bot added changelog-entry-required Update changelog before merge. Remove label if entry is not needed or already added. manifest labels Aug 11, 2023

NordicBuilder added manifest-mcuboot manifest-zephyr labels Aug 11, 2023

de-nordic force-pushed the three-images branch 2 times, most recently from 35940fa to 91bf297 Compare August 18, 2023 11:15

de-nordic force-pushed the three-images branch 7 times, most recently from e3f159d to ddcb202 Compare August 24, 2023 16:55

de-nordic added 2 commits September 14, 2023 18:06

flash_map/pm: Add definitions for third image

4d71450

Third image partition names. Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>

manifest: MCUboot and Zephyr changes required for three images

c6b299a

Update sdk-mcuboot and sdk-zephyr revisions to bring in changes required for support of three images. Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>

de-nordic force-pushed the three-images branch from ddcb202 to c6b299a Compare September 14, 2023 18:09

de-nordic closed this Oct 3, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for three images in sdk-nrf #12025

Support for three images in sdk-nrf #12025

de-nordic commented Aug 11, 2023 •

edited

Loading

NordicBuilder commented Aug 11, 2023 •

edited

Loading

NordicBuilder commented Aug 11, 2023 •

edited

Loading

NordicBuilder commented Aug 11, 2023

doublemis1 commented Aug 18, 2023

de-nordic commented Aug 18, 2023

doublemis1 commented Aug 18, 2023 •

edited

Loading

de-nordic commented Aug 18, 2023

de-nordic commented Oct 3, 2023

Support for three images in sdk-nrf #12025

Support for three images in sdk-nrf #12025

Conversation

de-nordic commented Aug 11, 2023 • edited Loading

NordicBuilder commented Aug 11, 2023 • edited Loading

NordicBuilder commented Aug 11, 2023 • edited Loading

Test specification

CI/Jenkins/NRF

CI/Jenkins/integration

NordicBuilder commented Aug 11, 2023

doublemis1 commented Aug 18, 2023

de-nordic commented Aug 18, 2023

doublemis1 commented Aug 18, 2023 • edited Loading

de-nordic commented Aug 18, 2023

de-nordic commented Oct 3, 2023

de-nordic commented Aug 11, 2023 •

edited

Loading

NordicBuilder commented Aug 11, 2023 •

edited

Loading

NordicBuilder commented Aug 11, 2023 •

edited

Loading

doublemis1 commented Aug 18, 2023 •

edited

Loading