feat: raw (non-console) mcuboot serial-recovery fixture (mps2/an385)#9
Merged
Conversation
JPHutchins
commented
Jun 23, 2026
Comment on lines
+13
to
+16
| # Pinned to a zephyr main commit (post-v4.4.0) so the imported mcuboot | ||
| # carries mcu-tools/mcuboot#2755 -- the raw (non-console) SMP serial | ||
| # recovery protocol (CONFIG_BOOT_SERIAL_RAW_PROTOCOL) the serial_recovery_raw | ||
| # fixture needs. v4.4.0's mcuboot pin predates that feature. |
JPHutchins
commented
Jun 23, 2026
Comment on lines
+420
to
+422
| # Raw (non-console) variant of the do-it-all fixture: same two-loader RAM_LOAD | ||
| # scheme, but the app's transport is the raw UART protocol, so the manifest | ||
| # entry reports serial_raw while still being a serial-recovery mcuboot image. |
Collaborator
Author
There was a problem hiding this comment.
Remove or convert to docstring
JPHutchins
force-pushed
the
feat/serial-recovery-raw
branch
from
June 23, 2026 20:21
ae9b070 to
8dad4ee
Compare
Add smp_server.fixture.serial_recovery_raw.mps2_an385: the do-it-all MCUboot RAM_LOAD recovery fixture, but both MCUboot recovery and the app speak the raw SMP serial encoding (no base64/CRC/console framing) instead of SMP-over-console -- so smpclient's SMPSerialRawTransport can integration-test against a real recovery server (mcu-tools/mcuboot#2755, intercreate/smpclient#106). It mirrors the existing serial_recovery_* two-loader scheme: MCUboot's code-only hex plus the signed app dropped into slot0's RAM-backed sim-flash. transport=serial_raw, mcuboot=true, serial_recovery=true in the manifest. The raw recovery protocol (CONFIG_BOOT_SERIAL_RAW_PROTOCOL) merged into mcuboot after v4.4.0's pin, so bump zephyr to a pinned main commit (f33aa2bc, post-v4.4.0) whose imported mcuboot (0fae8920) carries it. All 34 fixtures still build under the bump. A 40-char main SHA is shortened to 12 chars for fixture names so they stay readable. Closes #8 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PSmP6esfZppSaVdaj82KZu
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #8.
Adds a raw (non-console) MCUboot serial-recovery fixture so smpclient's
SMPSerialRawTransportcan integration-test against a real recovery server (mcu-tools/mcuboot#2755, intercreate/smpclient#106).What's added
smp_server.fixture.serial_recovery_raw.mps2_an385— the do-it-all MCUboot RAM_LOAD recovery fixture, but both MCUboot recovery and the app speak the raw SMP serial encoding (no base64/CRC/console framing; packets framed by the SMP header length) instead of SMP-over-console:serial.conf→raw_serial.conf(CONFIG_UART_MCUMGR_RAW_PROTOCOL) on uart0;ramload.confstays last so it restores the uart1 console/log thatraw_serial.confturns off for single-UART targets.mcuboot_CONFIG_BOOT_SERIAL_RAW_PROTOCOL=y— the bootloader counterpart of the app's raw transport.serial_recovery_*fixtures (MCUboot code-only hex + signed app dropped into slot0's RAM-backed sim-flash).Manifest entry comes out exactly as the issue requested:
config: serial_recovery_raw,transport: serial_raw,mcuboot: true,serial_recovery: true, targetmps2_an385, every group incl. img.Target choice: built for
mps2_an385(per maintainer decision) — mirrors the existing recovery family and reuses all collector/qemu_cmdinfra. Consuming it from smpclient additionally needs a socket-backed raw transport on the client side (the currentSMPSerialRawTransportis wired for native_sim PTYs); tracked on the smpclient side.Dependency: Zephyr bump
CONFIG_BOOT_SERIAL_RAW_PROTOCOLmerged into MCUboot after v4.4.0's MCUboot pin, and it isn't in any released Zephyr yet. Per maintainer decision,west.ymlnow pins Zephyr to amaincommit (f33aa2bc, post-v4.4.0) whose imported MCUboot (0fae8920) carries #2755.unknown.build.yamlshortens a 40-charmainSHA to 12 chars for the fixture-name version label (release tags stay verbatim), so names readzephyr_f33aa2bc4a43_…rather than the full 40-char SHA. Naming policy is a judgment call — easy to switch to4.4.99or the bare SHA if preferred.Verification (local)
west twisterbuilds the new fixture and the full suite (34/34)..configconfirms raw on both sides (UART_MCUMGR_RAW_PROTOCOL,BOOT_SERIAL_RAW_PROTOCOL) with console/log preserved on uart1.ruff,ruff format,mypy --strict, 77pytest(incl. new doctest + process-test forserial_recovery_raw).Not verified locally: a full raw-SMP upload round-trip — that needs smpclient's
SMPSerialRawTransport(#106). Coverage here matches the existing recovery fixtures (build + boot + recovery-entry + manifest correctness).🤖 Generated with Claude Code
https://claude.ai/code/session_01PSmP6esfZppSaVdaj82KZu