Port bdinfo and mtdparts, both of which were dead on real captures

[Zenofex]

Engine side: 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