Mark images in slot 0 for test

[julien-he]

smpmgr/smpmgr/main.py

Line 236 in e24da6e

if slot != 0 or confirm:

Is there a reason why images in slot 0 are not marked for test when updating via upgrade option? I'm wondering because in my project, I now need to manually mark my images for test (0 is the default slot).

[JPHutchins]

There's a whole history see here: #3

In your case, I suspect that --slot 2 is what you want. --slot 0 means default upload destination, which would usually be the secondary. There's a bug in the upgrade command where it doesn't mark for swap on every upload slot - I think it might be safe to just always mark the latest uploaded image for swap, even when it's a no-op, e.g. in a single slot config.

My latest thinking on the subject would be to remove the --slot argument from the upgrade command entirely since it's so confusing. Move away from being 1:1 with SMP and define a nice abstraction like --destination = auto, primary, secondary, image2-primary, image2-secondary, etc.

Upload could keep the --slot arg since those commands are more intended for FW development troubleshooting.

Feel free to weigh in!

[JPHutchins]

Shorter answer: --slot 0 doesn't mean slot 0, it means "default". --slot 1 means slot 0 🤦‍♀️. That's the spec, as far as I can understand it!

[julien-he]

Thanks for the quick reply and your support. I updated using the --slot 1 option and that did the job for me.

I'm still not fully getting why --slot 1 actually means slot 0, but maybe tomorrow with a fresh mind, I might get it. 😉 So yes, for me not having the --slot option in upgrade and always marking the latest image for swap would have confused me less. 🙂

FYI: I'm using a PineTime together with a current Zephyr version. There are two slots on the external flash and one application loaded to the nRF52832.

Before the update, SW from slot 0 was loaded and active (output from image state-read):

ImageState(
    slot=0,
    version='0.0.0',
    image=None,
    hash=HashBytes('65F7A4418A4361ED1CE1A1118DADC0F0F4224554B4630757520FAF5A33C2D3BD'),
    bootable=True,
    pending=False,
    confirmed=True,
    active=True,
    permanent=False
)
ImageState(
    slot=1,
    version='1.0.0',
    image=None,
    hash=HashBytes('86ED581F865C56B8273459621FCE802FF679E4DCF9CF08424A8A33D899CFB79D'),
    bootable=True,
    pending=False,
    confirmed=False,
    active=False,
    permanent=False
)

I then updated via:
smpmgr --ble ADDRESS upgrade --slot 1 /path/to/my/firmware.bin

after the update update, output of image state-read:

ImageState(
    slot=0,
    version='0.0.0',
    image=None,
    hash=HashBytes('8125BCC582500C600F2B1FB56CCDD160C40F26EF3A64D5DCC7D2995061BDB204'),
    bootable=True,
    pending=False,
    confirmed=True,
    active=True,
    permanent=False
)
ImageState(
    slot=1,
    version='0.0.0',
    image=None,
    hash=HashBytes('65F7A4418A4361ED1CE1A1118DADC0F0F4224554B4630757520FAF5A33C2D3BD'),
    bootable=True,
    pending=False,
    confirmed=False,
    active=False,
    permanent=False
)

So old firmware is now in slot 1, new firmware is in slot 0. Everything works as expected.

[JPHutchins]

I'm still not fully getting why --slot 1 actually means slot 0, but maybe tomorrow with a fresh mind, I might get it.

There's not a good reason other than "because that's the way it is" 😢 :

https://github.com/mcu-tools/mcuboot/blob/adeac9fdcebef274e98312276b5a8618e940bbeb/boot/zephyr/Kconfig.serial_recovery#L49-L63

It's not 100% clear to me that MCUboot and Zephyr's SMP servers agree on it.

https://github.com/zephyrproject-rtos/zephyr/blob/4679fa170be451cc2f163c21e8f0251b14db92a8/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt.c#L589-L601

I'm almost certain in fact. How does Zephyr behave when you say slot 0? It can't actually write to slot 0 since that's the running image, whereas mcuboot can write to slot 0 from the bootloader.

A lot going on here: https://github.com/zephyrproject-rtos/zephyr/blob/4679fa170be451cc2f163c21e8f0251b14db92a8/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt.c#L66-L127

Probably should throw an LLM at the source code of both SMP server impls.

[JPHutchins]

PineTime, nice!

https://pine64.org/devices/pinetime/

[julien-he]

I'm almost certain in fact. How does Zephyr behave when you say slot 0?

Do you mean explicitly or just leave out the option? When I did the upgrade without --slot 1, new firmware was loaded to the secondary slot, but not marked for test, then reboot happened and the old application was loading again.

PineTime, nice!

I like the project. Hardware is a bit old and resources are very limited, but still fun to play around with it. 🙂

Thanks again for your great support!