Hello Abdelkader, Nice to meet you! This sounds like a reasonable idea, I understand this can be useful. I see you pushed patches in Gerrit, that's a good idea too because yes all development needs to go through Gerrit.
I will definitely do a review later, will add comments to the patch. My first thought was that maybe you can recommend the most sensible #times for repeated reads and use this count always, make an option just --verify-reads. But I will look closely at all the patches later. Thank you for the contribution! On Sun, Mar 1, 2026 at 4:47 PM 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. > > 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. > > Abdelkader Boudih > _______________________________________________ > flashrom mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Anastasia. _______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
