Summary
smpmgr os reset should expose the MCUmgr boot_mode field so a client can ask the device to reboot into the bootloader (MCUboot serial recovery), not just into the application.
Background
The MCUmgr OS-management reset command accepts an optional boot_mode field, gated by Zephyr's CONFIG_MCUMGR_GRP_OS_RESET_BOOT_MODE (which depends on CONFIG_RETENTION_BOOT_MODE). When set to 1 (BOOT_MODE_TYPE_BOOTLOADER), the server writes the retained boot mode and resets; an MCUboot built with CONFIG_BOOT_SERIAL_BOOT_MODE reads the flag on the next boot and stays in its serial-recovery SMP server.
- Zephyr handler:
subsys/mgmt/mcumgr/grp/os_mgmt/src/os_mgmt.c decodes a boot_mode key in the reset request.
- Zephyr Kconfig:
MCUMGR_GRP_OS_RESET_BOOT_MODE (subsys/mgmt/mcumgr/grp/os_mgmt/Kconfig).
Request
Add an option to smpmgr os reset, e.g.:
smpmgr os reset --boot-mode bootloader # or: --boot-mode 1
so the reset request carries boot_mode.
Note on the dependency chain
This likely spans the stack:
smp (v4.0.0): smp.os_management.ResetWriteRequest currently models only the force field — boot_mode would need to be added there first.smpclient: surface the field on its reset call.smpmgr: expose the CLI flag.
Use case
intercreate/smp-server-fixtures is building a single "do-it-all" emulated (mps2 / QEMU) test fixture: an MCUboot RAM_LOAD image whose running application exposes every MCUmgr command group, and which can be told to reboot into serial recovery via os reset boot_mode=1. That lets one image exercise all groups, DFU, and the bootloader's recovery path from a single connection. Driving recovery entry from integration tests / the CLI needs this field.
Summary
smpmgr os resetshould expose the MCUmgrboot_modefield so a client can ask the device to reboot into the bootloader (MCUboot serial recovery), not just into the application.Background
The MCUmgr OS-management
resetcommand accepts an optionalboot_modefield, gated by Zephyr'sCONFIG_MCUMGR_GRP_OS_RESET_BOOT_MODE(which depends onCONFIG_RETENTION_BOOT_MODE). When set to1(BOOT_MODE_TYPE_BOOTLOADER), the server writes the retained boot mode and resets; an MCUboot built withCONFIG_BOOT_SERIAL_BOOT_MODEreads the flag on the next boot and stays in its serial-recovery SMP server.subsys/mgmt/mcumgr/grp/os_mgmt/src/os_mgmt.cdecodes aboot_modekey in the reset request.MCUMGR_GRP_OS_RESET_BOOT_MODE(subsys/mgmt/mcumgr/grp/os_mgmt/Kconfig).Request
Add an option to
smpmgr os reset, e.g.:so the reset request carries
boot_mode.Note on the dependency chain
This likely spans the stack:
smp(v4.0.0):smp.os_management.ResetWriteRequestcurrently models only theforcefield —boot_modewould need to be added there first.smpclient: surface the field on its reset call.smpmgr: expose the CLI flag.Use case
intercreate/smp-server-fixturesis building a single "do-it-all" emulated (mps2 / QEMU) test fixture: an MCUboot RAM_LOAD image whose running application exposes every MCUmgr command group, and which can be told to reboot into serial recovery viaos reset boot_mode=1. That lets one image exercise all groups, DFU, and the bootloader's recovery path from a single connection. Driving recovery entry from integration tests / the CLI needs this field.