Direct-XIP MCUboot both images have the same version

RE: Direct-XIP MCUboot both images have the same version

Hieu — Mon, 06 Mar 2023 17:30:53 GMT

Hi markuckermann,

A quick update: I got in touch with the author of the Direct-XIP variant building feature, and they are now checking it.

RE: Direct-XIP MCUboot both images have the same version

Hieu — Wed, 01 Mar 2023 17:29:25 GMT

markuckermann It seems you have made a lot of progresses. Your findings look right to me. Let me double check them with the bootloader team tomorrow and get back to you.

RE: Direct-XIP MCUboot both images have the same version

markuckermann — Wed, 01 Mar 2023 15:56:20 GMT

I just realised that the "two versions are the same" isn't a problem at all. The way the find_slot_with_highest_version() function in MCUboot's loader.c handles the comparison it just loads the first slot. The problem really lies with the final merge command in NCS.

RE: Direct-XIP MCUboot both images have the same version

markuckermann — Wed, 01 Mar 2023 15:03:49 GMT

I think there are two solutions:

1. Flash a confirmed image (and only one slot)

So after the build:

# confirm image
C:\ncs\toolchains\v2.2.0\opt\bin\python.exe C:/ncs/v2.2.0/bootloader/mcuboot/scripts/imgtool.py sign --key C:/ncs/v2.2.0/bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 4 --version 0.0.2+33 --pad-header --slot-size 0x35000 --pad --confirm <path>/smp_svr/build/zephyr/mcuboot_primary_app.hex <path>/smp_svr/build/zephyr/app_confirmed.hex

# merge bootloader + confirmed image
C:\ncs\toolchains\v2.2.0\opt\bin\python.exe C:/ncs/v2.2.0/zephyr/scripts/build/mergehex.py -o <path>/smp_svr/build/zephyr/merged.hex --overlap=replace <path>/smp_svr/build/mcuboot/zephyr/zephyr.hex <path>/smp_svr/build/zephyr/app_confirmed.hex

# flash without rebuild
west flash --skip-rebuild

2. Flash a test image and confirm it in application

# merge bootloader + test image
C:\ncs\toolchains\v2.2.0\opt\bin\python.exe C:/ncs/v2.2.0/zephyr/scripts/build/mergehex.py -o <path>/smp_svr/build/zephyr/merged.hex --overlap=replace <path>/smp_svr/build/mcuboot/zephyr/zephyr.hex <path>/smp_svr/build/zephyr/app_test_update.hex

# flash without rebuild
west flash --skip-rebuild

# in application main.c
boot_write_img_confirmed();

If you just flash a test image it only works once.

Hieu once you confirm the above, can you ask if this will be fixed upstream? Or show me how I can change it so a Flash / Build action in VSCode results in a flashable merge.hex.

RE: Direct-XIP MCUboot both images have the same version

markuckermann — Wed, 01 Mar 2023 13:52:33 GMT

I've looked at the shell comands run by the build (using west -v build) and the last one consists of:

mergehex.py
-o <path>/smp_svr/build/zephyr/merged.hex 
--overlap=replace 
<path>/smp_svr/build/mcuboot/zephyr/zephyr.hex                 // 29952 bytes   That's the bootloader
<path>/smp_svr/build/zephyr/mcuboot_primary.hex                // 208388 bytes  Primary app (but not signed)
<path>/smp_svr/build/zephyr/mcuboot_secondary.hex              // 209236 bytes  Secondary app (but signed)
<path>/smp_svr/build/zephyr/zephyr.hex                         // 208388 bytes  Same file (same CRC) as mcuboot_primary.hex
<path>/smp_svr/build/zephyr/mcuboot_secondary_app_signed.hex   // 209236 bytes  Same file (same CRC) as mcuboot_secondary.hex
<path>/smp_svr/build/zephyr/app_signed.hex                     // 209236 bytes  Ever so slightly bigger than mcuboot_primary => Primary app signed

So that doesn't seem right at all.

I've also added lot's of statements to MCUboot and found that even when I change the logic to select any of the images it doesn't boot because the active_swap_state->magic is set to BOOT_MAGIC_UNSET instead of BOOT_MAGIC_GOOD.

So then the bootloader deletes the slots :/

RE: Direct-XIP MCUboot both images have the same version

markuckermann — Tue, 28 Feb 2023 21:57:33 GMT

Great, glad you could reproduce it. Yes, agreed, both being included is the issue I think. I don't know if MCUboot "doesn't like the image" but it certainly doesn't boot them because they both have the same version.

Well, the documentation is rather sparse. It's not so much inaccuracies, but just a lack of. https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/bootloaders_and_dfu/index.html suggests in the Table that Direct-XIP is supported. Then in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-ncs.html it also suggests that all you have to do is enable the CONFIG_BOOT_BUILD_DIRECT_XIP_VARIANT.

Then on the RE: MCUboot DIRECT_XIP ticket, the question of if MCUBOOT_DIRECT_XIP_REVERT is supported, the answer was to just look at https://github.com/nrfconnect/sdk-mcuboot/blob/main/boot/zephyr/Kconfig but no indication if presence means that I should expect it to work.

The tutorial blog: Add DFU support to your application doesn't mention XIP at all. It would be nice to have something like that for XIP

Also, it would be very good to get information on whether the SMP server can verify that the image being sent is for the right slot. I think some of that is discussed in the github issue but it seems to have just been closed without the PR being merged?

In general, I ran into Big primary image prevents FOTA (again, no mention of this in the docs but it turns out you need at least 4KB of space free. The build passes fine and the image transfers but then doesn't start) I'm looking at XIP to get the extra 4KB of space back.

RE: Direct-XIP MCUboot both images have the same version

Hieu — Tue, 28 Feb 2023 21:39:07 GMT

Update: I notice that I chose to put CONFIG_BOOT_BUILD_DIRECT_XIP_VARIANT in a Kconfig fragment instead of prj.conf, then failed to include it. I can reproduce your problem exactly now. Sorry for before.

It looks like there are two issues:
- The merged.hex includes images for both the primary and secondary slot
- MCUboot does not like the images and delete them both, one at a time

I will continue to look into it. It might take a while, but I will keep you updated every 2-3 days.

Please share the info on the documentation though. I will take care of that concurrently.

RE: Direct-XIP MCUboot both images have the same version

Hieu — Tue, 28 Feb 2023 21:08:43 GMT

Hi markuckermann,

I followed your steps and my result is a little different.

*** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting Direct-XIP bootloader
I: Primary   slot: version=0.0.0+0
I: Image 0 Secondary slot: Image not found
I: No slot to load for image 0
E: Unable to find bootable image

It still is an issue and I will continue to look into it. However, to be on the same page, could you please let me know
- What NCS version are you using? From your log, I am guessing v2.2.0?
- How in details did you flash the device? Could it be that by flashing, you meant a DFU operation?

[quote user="markuckermann"]I found an open issue on zephyr which seems to have had some nordic involvement: https://github.com/zephyrproject-rtos/zephyr/issues/27673

It's left me a bit confused about whether Direct XIP is as well-supported as the NCS documentation suggests.[/quote]

I am a bit unfamiliar with the details discussed in this GitHub issue. Let me do some research on it and feedback to you in a later reply.

By the way, which Direct-XIP documentation are you referring to here? If there are any inaccuracies in our docs, we will get to correct them.

RE: Direct-XIP MCUboot both images have the same version

markuckermann — Tue, 28 Feb 2023 19:37:40 GMT

Hi Hieu, great, looking forward to it.

I found an open issue on zephyr which seems to have had some nordic involvement: https://github.com/zephyrproject-rtos/zephyr/issues/27673

It's left me a bit confused about whether Direct XIP is as well-supported as the NCS documentation suggests.

RE: Direct-XIP MCUboot both images have the same version

Hieu — Mon, 27 Feb 2023 20:58:28 GMT

Hi markuckermann,

I will support you with this question. I will need to look into this topic a little bit before answering you.

However, I am partially out of office in the first half of this week, so my answer will be a little delayed. I will follow up latest by the end of Wednesday Mar 1.

Sorry for the inconvenience.

Hieu