summaryrefslogtreecommitdiffstats
path: root/chipdrivers.h
diff options
context:
space:
mode:
authorCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>2010-03-22 23:47:38 +0000
committerCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>2010-03-22 23:47:38 +0000
commit12aa0be5d47d8759e27a1ee412b2f95b9906898b (patch)
treeb34d080e817b9a94809b24734a0bf64ed9c5605c /chipdrivers.h
parent12575e5bfe4292067d805404f6c6524f64a3ab86 (diff)
downloadast2050-flashrom-12aa0be5d47d8759e27a1ee412b2f95b9906898b.zip
ast2050-flashrom-12aa0be5d47d8759e27a1ee412b2f95b9906898b.tar.gz
Check 82802AB probing results for flash contents too
JEDEC ID probing checks the parity of the vendor ID and verifies that the ID differs from the flash chip contents. Add the same feature to 82802AB ID probing. This should reduce the number of lines we have to look at to determine if we're missing a chip definition or if we need a board enable. Just use grep on the log: grep -v "parity violation" To narrow it down further, try: grep -v "id1 is normal flash content, id2 is normal flash content" And of course you want to ignore the skipped probes: grep -v "skipped" The remaining lines are worth examining, and if those look bogus as well, you can bet that we just need a board enable. Corresponding to flashrom svn r971. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Diffstat (limited to 'chipdrivers.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud