Direct-XIP MCUboot both images have the same version

[markuckermann]

Trying to use XIP FOTA updates with nrf connect sdk and nrf52832 to get the extra flash sector (4KB) in space.

Starting with the smp_srv sample, adding bt fragment, and 

CONFIG_BOOT_BUILD_DIRECT_XIP_VARIANT=y to the proj.conf

as well as 

CONFIG_BOOT_DIRECT_XIP_REVERT=y

CONFIG_BOOT_DIRECT_XIP=y

to mcuboot.conf I find that after flashing the fw it just crashes with

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

Is that expected and what's the recommended way to avoid it? 

Is there some guide on how to do direct-XIP updates in practice?

[Hieu]

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

[markuckermann]

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.

[Hieu]

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?

markuckermann said:

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.

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.

[Hieu]

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.

[markuckermann]

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.

[markuckermann]

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 :/