Add --confirm option to upgrade

[JPHutchins]

Like image state write, upgrade should be allowed to confirm, default to false, and provide warnings to the user about potential bricking when using the confirm option during, rather than after, an upgrade.

https://github.com/intercreate/smpmgr/blob/main/smpmgr/main.py#L145-L151

[RubenIxorigue]

Hi there! Hope you’re doing well.
Do you have any ETA on this change? Being able to use --confirm directly during upgrade would reduce our production upgrade time by more than half, which would be a significant improvement for our workflow.

[Ruffus-ixo]

Currently, smpmgr upgrade always performs a test upgrade:

the image is uploaded to the secondary slot,

it is marked as pending,

a reset is requested,

and the image must later be confirmed (either by reconnecting or by the application itself).

However, MCUboot supports a permanent upgrade mode, where the image in the secondary slot is marked as pending + permanent before reboot, so that:

the next reboot performs a permanent swap (not test),

the new image becomes active + confirmed,

no post-reboot reconnection or explicit confirm command is required.

This is the behavior exposed by nRF Connect, which allows performing a “confirmed upgrade in one go”.

Current limitation

Although the SMP protocol (ImageUploadWrite) supports an upgrade=true flag (used to arm a permanent upgrade), the smpmgr CLI does not expose any option to set this flag.

As a result:

there is no way to perform a permanent upgrade from smpmgr,

users must rely on workarounds such as image state-write after upload,

production workflows that cannot reliably wait for the reset/reconnect step (e.g. batch DFU) are fragile.

Proposed change

Extend smpmgr upgrade with an explicit option to request a permanent upgrade, for example:

smpmgr upgrade <image.bin> --slot 1 --permanent

Expected behavior:

Upload image to secondary slot.

Mark the image as pending + permanent (either by:

passing upgrade=true in ImageUploadWrite, or

performing an equivalent image state-write using the image hash).

Request reset (best-effort).

Exit without requiring post-reboot reconnection.

If the reset is missed, the device is still safely armed:

the next reboot will perform the permanent swap,

the new image will be active + confirmed.

Why this matters

Matches nRF Connect behavior.

Eliminates the need for a second BLE connection.

Enables robust batch/production DFU workflows.

Uses a documented MCUboot feature (permanent swap), not a hack.

Keeps backward compatibility: default behavior remains test upgrade.

Notes

This option is intentionally opt-in, as permanent upgrades remove the automatic revert safety of test upgrades. This is already clearly documented in MCUboot and Zephyr.

Summary

smpmgr currently lacks a way to request a permanent upgrade even though the protocol supports it. Exposing this capability would significantly improve reliability and bring the CLI in line with nRF Connect and MCUboot’s intended upgrade model.

[JPHutchins]

I think that the option we want is "--confirm". Because "upgrade" is used to control version checking behavior. Technically, I'm confused by that, since I thought that was baked into MCUBoot and had nothing to do with the SMP server: https://docs.zephyrproject.org/latest/services/device_mgmt/smp_groups/smp_group_1.html#image-upload-request

"""
optional flag that states that only upgrade should be allowed, so if the version of uploaded software is not higher then already on a device, the image upload will be rejected. Zephyr compares major, minor and revision (x.y.z) by default unless CONFIG_MCUMGR_GRP_IMG_VERSION_CMP_USE_BUILD_NUMBER is set, whereby it will compare build numbers too. Should only be present when “off” is 0.
"""

This is the behavior exposed by nRF Connect, which allows performing a “confirmed upgrade in one go”.

For reference, I am obliged to clarify that this "default" behavior of confirming an unbooted upgrade image, while convenient, is not the correct practice for devices that are in customer's hands, and can result in unrecoverable devices in the field - bricked - that need to be sent back to the factory for repair.

For factory, I agree it's a great feature, and will be really nice when we add concurrent upgrades - e.g. batch mode - where smpmgr completes 10s or 100s of upgrades at once, depending on transport capability of course.