Thanks Angel, agreed that -v/--verify is useful when you already have a reference image. My proposal targets a different failure mode: *read integrity when you don't yet have a trusted reference*.
Just to clarify the motivation: this comes from a real failures I encountered. I once dumped a Winbond SPI NOR containing WiFi calibration data stored at the end of the chip. Using a cheap SOIC8 clip, the first read appeared ok. Later, using a Pomona clip, I discovered that a whole region near the end had been read incorrectly. (all 0xFF) That calibration block was factory-written and device-specific. It would not have been recoverable from another board. Format-based validation with UEFITool is helpful for typical PC UEFI images, but doesnt apply to many SPI contents (routers/modems/embedded devices, non-UEFI layouts, blobs with no structure). In those cases, repeated-read consistency is one of the few generic checks available. I will prepare a Gerrit change and open the proposal. On Sun, 1 Mar 2026, at 11:30, Angel Pons wrote: > Hi there, > > On Sun, Mar 1, 2026 at 5:47 AM Abdelkader Boudih <[email protected]> wrote: >> __ >> Hi, >> >> I would like to propose a small CLI addition: --verify-reads[=<count>]. >> >> When reading flash over an external programmer, a single successful read is >> not proof the data is correct (i learned the lesson when i lost bios >> original). >> >> This is particularly common with: >> >> - Clip-on programmers (Pomona, SOIC8 clips) where contact pressure varies >> and pins may not seat fully on all pads simultaneously >> - Budget CH341A/CH347 adapters with cheap ZIF sockets. >> - Long or unshielded SPI wiring picking up noise >> >> in these situations the programmer reports success, the read completes >> without error, but individual bytes or ranges are silently wrong due to >> marginal signal integrity. The only current mitigation is to read multiple >> times manually and compare with sha256sum. >> >> --verify-reads[=<count>] reads the flash count times (default: 3, min: 2) >> and compares consecutive reads byte-by-byte. On mismatch it reports the >> offset and the two differing read numbers. > > Note that flashrom already has a `-v` / `--verify` command, which compares > the contents of a flash chip with the provided file. In my experience I've > found it to be good enough in most cases. After all, my read integrity > problems have mostly been about reading a chip and verifying that the read > matches the chip's contents, but turns out that the read data is nonsense > (e.g. all FFs). So these days I check if the dump I've just taken looks > right; e.g. after reading a mainboard's flash chip (where UEFI is stored), I > check that UEFITool can open it. > >> Consecutive comparison is used deliberately rather than comparing all reads >> against read first read. >> >> A patch is ready. Happy to Gerrit it if the approach looks reasonable, or >> adjust based on feedback. > > Please don't hesitate and simply put it up on Gerrit. The point of Gerrit is > to review and discuss patches, after all! :-) > >> Abdelkader Boudih >> _______________________________________________ >> flashrom mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > Best regards, > Angel
_______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
