You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 4fb7e03
Browse filesBrowse the repository at this point in the historyBrowse files
Port bdinfo and mtdparts, both of which were dead on real captures (#27)
Engine side:
[BootIntel.com@ca2bd80e](BootIntel/BootIntel.com@ca2bd80e).
This port started by measuring what it was porting. Across all 31 public
corpus logs the engine's `bdinfo` and `mtdparts` parsers produced
**nothing** — zero board info, zero devices, zero partitions — while two
of those logs contain a full bdinfo dump.
```
U-Boot session in verified-image.log
evidence Environment size: 1650/4091 bytes
10 variables, environment 1650/4091 bytes
board info 9 fields
image check uImage CRC (passed)
4 partitions on nor0
u-boot 0x00020000 @ 0x00000000 read-only
kernel 0x00100000 @ 0x00020000
rootfs 0x006c0000 @ 0x00120000
art 0x00010000 @ 0x007f0000 read-only
```
The read-only column is the operationally interesting one: it says which
partitions an operator at that prompt can rewrite.
## Why they were dead
Both blocks were parsed only once the prompt regex had matched the line
where the command was typed. `bootintel-20` prints its dump after
`Boot-> bdinfo`, and `Boot->` is not U-Boot's default prompt, so the
gate never opened. They are now recognised by their own shape, which is
how the environment has always worked and why the environment was never
affected.
bdinfo needs a discriminator against the environment, since `baudrate`
and `ethaddr` appear in both. It is the whitespace around the `=` —
`printenv` emits `baudrate=115200`, bdinfo pads to a column and emits
`baudrate = 115200 bps`. Tested in both directions.
## Two bugs fixed rather than faithfully reproduced
- **`size` and `start` are not board-info keys.** `bootintel-5` prints
an MTD table in a vendor format whose rows are exactly `size =
0x180000`, and `size` in the allowlist recorded that as board info. A
live false positive on a real log.
- **The device pattern never matched U-Boot's output.** It required
`#parts` with no space and no bracketed chip id, while U-Boot prints
`device nor0 <spi0.0>, # parts = 4`. The partition rows parsed; the
device they belong to did not.
No corpus log contains an mtdparts dump, which is exactly why that
second one survived — so the new `mtdparts.log` fixture is labelled
**SYNTHETIC** in the generator, and it is the only one that is. A
fixture nobody has seen in the wild is weaker evidence than one that
came off a board.
## Parity
The expectation renders bdinfo, the device and the partitions,
restricted to `source == "uboot_mtdparts"`: `mtd_partitions` also
carries rows from the kernel-log and vendor-format detectors that this
crate does not implement, and rendering all of them would compare two
different things and call the difference drift.
Nine fixtures now, eight of them real captures, reproduced byte for byte
by both implementations.
## Verification
- `cargo test --workspace`: 364 passed, 0 failed
- `clippy --workspace --all-targets -- -D warnings` and `fmt --all
--check`: clean
- Engine side: 437 passed in `ci-api-regression`, baseline-diffed with
no new failures, deployed
- Ran the built binary against both fixtures
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments