mcuboot: potential issue with default switched from swap using move to swap using offset

[etiennedm]

Describe the bug

I have a few (hobby) devices running an old MCUboot build (~1/2 years ago probably). I've been able to remotely update them fine until I tried yesterday. My understanding of the issue I face (complicated by the fact that I have no serial logs from the bootloader since I enabled serial recovery) is that this is caused by a combination of 7a76a62 and c15a53f.

• The bootloader they're running was built with the swap using move algorithm (and associated assumptions about the secondary slot layout).
• I've pushed a firmware update built with the new default swap using offset without realizing it was the new default.
• This update was swapped just fine by the bootloader (since the firmware N-1 that received it was still assuming swap using move).
• The new firmware N is now running with the assumption swap using offset is in use.
• When I upload a firmware image N+1, it will be written in the secondary slot with a 0x1000 (my flash page size) offset as expected with the swap using offset algorithm.
• The bootloader has not changed and is still expecting the firmware image to be at offset 0x0 in the secondary slot.
• Update fails.

Is that a realistic scenario? Since I don't have the bootloader logs I'm not sure. I could try to rebuild a bunch of binaries to test this.

I think I know how to recover from this, I'll either SWD flash a fresh bootloader, and use the new recommended default. Or I'll make sure to have SB_CONFIG_MCUBOOT_MODE_SWAP_USING_MOVE=y in my sysbuild.conf, and use serial recovery to flash a firmware that uses swap using move.

My question is: was it fair game to change the default like that? I realize in a professional setting QA (or a very thorough dev) would've caught the problem early.

Regression

• This is a regression.

Steps to reproduce

No response

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

No response

Additional Context

No response

[maass-hamburg]

Seems expected.

1. Old app image downloads and flashes new image to expected (from mcuboot perspective/old bootloader) position
2. reboot
3. mcuboot swaps image correct
4. new image starts
5. new image downloads and flashes newer image to the wrong position (it adds the offset)
6. reboot
7. mcuboot fails the swap, because newer image is not at the right position. (or at least it won't start correctly)

For production devices it it generally better to explicitly set SB_CONFIG_MCUBOOT_MODE_*. The defaults can always change and if you use a older bootloader, you should check if the mode in the bootloader and the application is the same.

[butok]

This is not a bug, this is the expected behavior.

[etiennedm]

Yes, I think I made that clear in my scenario :) Thanks for your input @maass-hamburg and double checking my reasoning.

Should that be added to the migration guide for 4.3?

[etiennedm]

Shared by @pdgendt on Discord, a note will be added to the migration guide or release notes. Thanks!

Closing this issue.