What is the proper way to generate an image that is confirmed with MCUBoot

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Marte Myrvold — Fri, 28 Oct 2022 11:59:19 GMT

Hi,

That is great to hear! I will let the developers know.

Best regards,

Marte

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Oskar — Fri, 28 Oct 2022 11:26:15 GMT

The fix works, it no longer gets stuck in the reboot!

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Marte Myrvold — Fri, 28 Oct 2022 10:14:04 GMT

Hi,

The developers have made a possible fix for the issue: https://github.com/zephyrproject-rtos/zephyr/pull/51743/files. Can you try this and see if it fixes the issue?

Best regards,

Marte

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Marte Myrvold — Thu, 27 Oct 2022 12:40:13 GMT

Hi,

I agree that there seems to be some inconsistent behavior between boot_write_img_confirmed and boot_is_img_confirmed. I have asked the development team about this, and I will let get back to you when I hear back from them.

Best regards,

Marte

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Oskar — Fri, 21 Oct 2022 14:20:13 GMT

Having all the images confirmed is not very desirable as I still would like to have unconfirmed images for testing and the actual firmware update.

In my application the self-test is only run if the image is not confirmed. So when flashing the unconfirmed merged.hex image the following happens:

1. MCUBoot boots and loads the image in slot 1(which is unconfirmed and has no image trailed)

2. The application boots and checks if the running image is confirmed.

3. Since the image is not confirmed a self-test is run. The application calls boot_write_img_confirmed.

4. After the self-test is completed the application reboots.

5. MCUBoot boots back up after the reset and loads application in slot 1(which for some reason is still not confirmed).

6. Go to step 2.

I have confirmed that the image does indeed call boot_write_img_confirmed and the call does not fail.

I have found out, from the zephyr implementation, that if the image magic is unset it counts the image as already confirmed if you are trying to write the image confirmed, but when your read out the boot_is_img_confirmed, no such check is done, so an image that does not have the image trailer cannot be confirmed.

So having a way to have a confirmed image built would really help.

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Marte Myrvold — Fri, 21 Oct 2022 13:07:56 GMT

Hi,

One option that is similar to what you are doing originally is to use CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS to add --confirm as an argument. Then you do not have to change different SDK CMake files. However, you should be careful with this approach, as this will cause it to skip testing even if you are using app_update.bin, which is unsigned, later.

If the image is not confirmed, MCUboot should hang, and not reboot, so the question is what in the application is causing the reboot. Can you enable more logging, and try to debug to see where it fails?

Best regards,

Marte

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Oskar — Fri, 21 Oct 2022 07:14:30 GMT

We connect to LTE, read some data from MQTT, and call the `boot_write_img_confirmed`, when all functionality is verified.

The `boot_write_img_confirmed` call never fails, but an image without the image trailer seems to not be able to write this flag properly.

The functionality works as expected, as long as the mcuboot image trailer is present in flash.

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Marte Myrvold — Wed, 19 Oct 2022 14:03:46 GMT

Hi,

How are you confirming the image with your self test procedure? Can you share your implementation?

Best regards,

Marte

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Oskar — Wed, 19 Oct 2022 13:07:00 GMT

This is the output from MCUBoot after flashing merged.hex, then app_signed.hex:

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.226,409] <inf> mcuboot: Starting bootloader
[00:00:00.227,630] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,118] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,546] <inf> mcuboot: Boot source: none
[00:00:00.228,942] <inf> mcuboot: Swap type: none
[00:00:00.622,161] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.622,497] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.226,409] <inf> mcuboot: Starting bootloader
[00:00:00.227,630] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,118] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,546] <inf> mcuboot: Boot source: none
[00:00:00.228,942] <inf> mcuboot: Swap type: none
[00:00:00.622,100] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.622,467] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.226,379] <inf> mcuboot: Starting bootloader
[00:00:00.227,600] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,088] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,515] <inf> mcuboot: Boot source: none
[00:00:00.228,881] <inf> mcuboot: Swap type: none
[00:00:00.621,673] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.622,039] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.226,440] <inf> mcuboot: Starting bootloader
[00:00:00.227,661] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,149] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.228,576] <inf> mcuboot: Boot source: none
[00:00:00.228,942] <inf> mcuboot: Swap type: none
[00:00:00.621,673] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.622,009] <inf> mcuboot: Jumping to the first image slot

This is the output using my generated image:

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
[00:00:00.362,670] <inf> mcuboot: Starting bootloader
[00:00:00.363,891] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.364,379] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.364,807] <inf> mcuboot: Boot source: primary slot
[00:00:00.368,591] <inf> mcuboot: Swap type: none
[00:00:00.761,627] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.761,993] <inf> mcuboot: Jumping to the first image slot

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Oskar — Wed, 19 Oct 2022 13:03:50 GMT

MCUBoot does not write the image trailer either, so using the app_signed.hex still causes the same issues as I described in the original post.

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Oskar — Wed, 19 Oct 2022 13:00:45 GMT

Hmm, but the app_signed.hex is still not a confirmed image?

It is signed, yes, but the image trailer is still not included so the image is not set as confirmed by MCUBoot.

I have managed to create the confirmed image manually, using this script:

python ../bootloader/mcuboot/scripts/imgtool.py sign \
		--key path/to/signing_key.pem \
		--header-size 0x200 \
		--align 4 --version x.y.z+0 \
		--pad-header --slot-size 0x70000 --confirm \
		build/zephyr/mcuboot_primary_app.hex \
		build/zephyr/app_confirmed.hex

python ../zephyr/scripts/mergehex.py -o build/zephyr/merged_and_confirmed.hex --overlap=replace \
		build/zephyr/merged.hex build/zephyr/app_confirmed.hex

But this requires me to add additional steps to the build process, which is undesirable.

Especially since there seems to be a flag that should do this automatically.

RE: What is the proper way to generate an image that is confirmed with MCUBoot

Marte Myrvold — Wed, 19 Oct 2022 12:44:53 GMT

Hi,

When you build an application with MCUboot you will get an autogenerated signed image, app_signed.hex. So you can just program the chip with this instead of merged.hex. You can find an overview of the different files that are generated here: Using MCUboot in nRF Connect SDK.

Best regards,

Marte

RE: What is the proper way to generate an image that is confirmed with MCUBoot

HuzefaST — Tue, 18 Oct 2022 13:26:55 GMT

I have the same issue, and have tried using the `CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE` flag but the image still cannot be confirmed. It appears that the trailer magic is not set, and the `boot_write_img_confirmed()` API treats an unset magic as already confirmed.

I had filed an MCUBoot issue to resolve this, but it hasn't seen any action: github.com/.../1436

I am using v2.0.0 SDK