On Fri, 09 Nov 2012 15:39:09 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
New version, better messages.
This patch needs the following changes to be mergeable:
- layout support
- man page
- message printing cosmetics
- Make sure flashrom returns an error code if autotest failed, even if recovering the chip contents succeeded.
Autotest mode tests all usable erase functions of a flash chip with a few test patterns, then restores the original flash contents. To make sure you can recover the original flash chip contents even if the autotest run is aborted, you have to specify a filename parameter for --autotest where the flash chip contents are saved. Example usage: flashrom -p dummy:emulate=SST25VF032B --output autotest.log --autotest scratch.img Please note that autotest uses roughly 10 erase cycles per usable erase function and repeated usage will cause serious flash wear. Speed isn't really good even with dummy, and I expect a 8 Mbit SPI chip on a real fast programmer to take at least 10 minutes for autotest (10*erasefn+1 all-sectors chip write, 10*erasefn+1.all-sectors erase, 30*erasefn+2 all-sectors read).
The patch seems to work, at least during my tests with dummy.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
i have tested this on my serprog implementation attached to a W25Q32 (32Mb, 4MB) on top of r1622. the complete autotest took over 7,5 hours. i have attached the produced log after removing some serprog spam (namely all "serprog_delay used, but programmer doesn't support delays natively - emulating" strings, the original log has 58MB due to this. hm)
the non-verbose output looks like this, and i'll comment on this inline:
flashrom -p serprog:dev=/dev/ttyU2flasher:2000000 --output autotest.log --autotest /tmp/scratch.img flashrom v0.9.6.1-r1622 on Linux 3.2.0-32-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK. serprog: Programmer name is "atmegaXXu2 " Found Winbond flash chip "W25Q32" (4096 kB, SPI) on serprog. Reading flash... done. Starting autotest. Reading current flash chip contents... done.
the first read is done twice. this is unnecessary and should be fixed if possible.
Erasing and writing flash chip with pattern 0... Reading current flash chip contents... done.
"..." should be followed by done. maybe we could get rid of the unneeded read outputs and print the done only if the pattern was written and verified.
Erasing and writing flash chip with pattern 4... Reading current flash chip contents... done. Erasing and writing flash chip with pattern 2... Reading current flash chip contents... done. Erasing and writing flash chip with pattern 5... Reading current flash chip contents... done. Erasing and writing flash chip with pattern 1... Reading current flash chip contents... done. Erasing and writing flash chip with pattern 3... Reading current flash chip contents... done. Erasing and writing flash chip with pattern 8... Reading current flash chip contents... done. Erasing and writing flash chip with pattern 9... Reading current flash chip contents... done. Erasing and writing flash chip with pattern 13... Reading current flash chip contents... done. Erasing and writing flash chip with pattern 12... Reading current flash chip contents... done.
here we want a notification telling us that the first erase function has been tested successfully. also something like "testing erase function x of y" at the beginning of every loop would be nice. for bonus points one could measure and estimate the time... :)
Erasing and writing flash chip with pattern 0... […] Erasing and writing flash chip with pattern 12... Restoring original chip contents:Reading current flash chip contents... done.
missing space (at least; a "done" for the restore action would be a good idea too). and a x of y tests failed, if any...
Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED.
i havent looked at the patterns used (the order is a bit wtf from a user's perspective :) or the code... but maybe we could add different levels of thoroughness. i think one that does just write a different random image with each eraser would be enough for most cases, and slow programmers ;)