I am working locally on building out a test
infrastructure that uses EM100's to emulate flashchips and a bunch of different
Chromebooks to exercise flashrom more. The idea I have is to turn this into a upstream CI
bot somehow but I have to work out how that would work in practice and if it is sufficient
to use EM100's to test most things? The problem with QEMU is that only a limited
chipset range is there so I guess that would only exercise the core flashrom logic itself?
I am open to more ideas on what we need as a community setup to help catch these things
better than having breakage merged which is less than ideal!
Great to see more interest in this :-)
EM100 testing would be great to help test on all the various chipsets
you use, and save some time too. Though I'm wondering if the EM100
really helps much in your case. For one, the EM100 doesn't emulate
write protection capabilities AFAIK (maybe I'm wrong?). Also, if
you're worried about wearing down NOR flash parts, you could test
erase/writes on a small region (maybe 8 blocks at a time selected at
random, or something to that effect). And if there are flash chips in
Chromebooks that wear out faster than expected then that's probably
something you want to know ;-)
It would be nice to see dummyflasher used more. Some simple sanity
check could even be made into part of the git presubmit hooks.
I also attempted to port the ginormous test_v2.sh script to upstream a
while back, but it never made it in:
(documentation is still
). It's kind of the brute force approach and
got unwieldy, but IMO with some work it can still be useful to have
upstream especially if there's some easier to access documentation to
help users with it.
There are also some opportunities for whitebox testing since flashrom
knows all about block erasers and write protections for the
chip/programmer being used. I hacked up something a while back to
demonstrate this with NOR flash write protections:
Lots of fun and exciting things to do here for whoever has time...