Interrupt autoboot by being early, not by being clever

[Zenofex]

What

bootintel analyze <port> --interrupt-autoboot takes the U-Boot prompt, pulls the environment, prints the boot-chain verdict, and hands the terminal back. This closes the loop #17 opened: capture to verdict with no typing and no byte leaving the machine.

[bootintel] ▸  hammering space now: POWER-CYCLE THE BOARD. The key has to be waiting in
               the UART before U-Boot looks, so this only works if the reset happens
               after this line.
[bootintel] ▸  prompt reached: "=>". Autoboot was interrupted.
[bootintel] ▸  typing `printenv`
[bootintel] ▸  environment captured. The prompt is yours; the verdict is below.

  exposed    Image verification
      verify is disabled, so U-Boot will not check image checksums before booting.
      read from verify=no

Why it is not "watch for the countdown, then send a key"

That is the obvious design and it does not work. The autoboot delay is a loop around tstc(), and bootdelay=0 means the check happens once. Boards ship that way. By the time the countdown has crossed the wire, been read by this process and been recognised, the window is gone: at 115200 a character is already ~87us of wire time, and the read is scheduled by the OS, not by us.

What works is that the byte is already in the UART's receive register when the board looks. So this hammers from the instant the port opens and asks the operator to power-cycle after that starts. There is nothing to detect, which is the point. --reset-line dtr|rts removes human timing entirely, where the adapter is wired to the board's reset.

Split by requirement, not by layer

Part	Requirement	Where
The hammer	must be FAST	a thread that writes one byte string on a timer and holds no logic at all
The decisions	must be RIGHT	src/term/autoboot.rs: a pure state machine over received bytes, no clock, no I/O

Which is what makes the timing claim testable. timing_tests simulates a board whose check fires once, at seven instants from 1ms to 900ms: caught every time. The contrast test arms the hammer only after the countdown is visible (the design this replaces) and misses.

Safety, on a client's only sample of a device

• The hammer never sends CR or LF. Refused when the key is parsed, asserted in tests: hammered bytes accumulate in U-Boot's line buffer and a newline would execute whatever they spell.
• Default key is a space; default commands are read-only (printenv, bdinfo, mtdparts). --at-prompt replaces that set entirely, so the operator decides exactly what is typed.
• A bare CR flushes the accumulated bytes before anything is typed.
• Every byte the tool sends is announced, so a client transcript shows which bytes were the tool's.
• Tuning flags without --interrupt-autoboot are refused rather than ignored: someone who passed --interrupt-key stop and got a plain terminal would reasonably think the tool tried.

Two false-positive guards

• A # prompt after the kernel handoff is a Linux shell. It is ignored and hammering continues until a fresh bootloader banner clears the latch. Typing printenv into a root shell would have produced a confident, wrong verdict.
• A prompt that does not answer re-arms rather than abandoning the attempt. Loading: # mid-transfer and a board that resets under us are both cheaper to retry than to give up on.

Verification

• cargo test --workspace: 349 passed, 0 failed (was 324). clippy -D warnings and fmt --check clean.
• End-to-end against a socat PTY pair and a simulated bootdelay=0 board: caught the single check, ran all three commands, printed the verdict. The board saw only those three commands despite 594 buffered spaces and a stray 0x04 from the harness, which is the CR flush doing its job.
• The missed-window path was verified too, by getting the harness ordering wrong first: it reported the miss with the four things worth checking and never implied success.

Not wired into --tui yet; that combination is refused rather than silently ignored. No version bump.

🤖 Generated with Claude Code