#141: flashrom: Warn the user when trying to read/write chips which are bigger than what the chipset can decode
#141: flashrom: Warn the user when trying to read/write chips which are bigger than what the chipset can decode ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Component: flashrom | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ We should make a table in the flashrom code which tells it how much a given (detected/supported) southbridge can decode. Then, if the user tries to read/write/erase/verify a chip which is _bigger_ (e.g. 512 KB) than what the southbridge can decode (e.g. 256 KB as on the AMD CS5530A for example) flashrom should at the very least warn the user, probably even bail out with an error. I've stumbled upon exactly this problem, trying to make a backup of a 512KB chip in an CS5530A system. I ended up with only one half of the contents (but duplicated) and it _did_ verify OK. That's because I did 'flashrom -r bak.bin' on the box (which effectively got me two equal, broken 256KB halves instead of one correct 512KB image). Then I did 'flashrom -wv bak.bin' onto the other 512KB chip, which also got the incorrect contents, _but_ flashrom said it verified fine (which is actually true) because both the bak.bin _and_ the written contents are crap. I only noticed what was going on after lots of debugging. I finally did a 'dd if=/dev/urandom of=rnd.dd bs=1024c count=512', then 'flashrom -wv rnd.dd' which then FAILED, because here the two 256KB-halves of the image were _not_ the same as in the above case. Then I compared 'hexdump -Cv rnd.dd' and 'flashrom -r readback.dd; hexdump -Cv readback.dd' outputs and noticed that bytes 0x0..0x40000 (256 KB) were _not_ the same, but the other 256 KB _were_ the same. Anyway, this is a nice way for data loss, so we should fix it by throwing an error in such cases. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/141> coreboot <http://www.coreboot.org/>
#141: flashrom: Warn the user when trying to read/write chips which are bigger than what the chipset can decode ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Component: flashrom | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ Comment(by hailfinger): It is even worse: This stuff not only depends on the chipset, it also depends on chipset settings. And to top it off, on recent Intel stuff (ICH7 and later) it not only depends on the chipset and the chipset settings, but also on the flash bus. So we need a way to store a per-bustype size limit. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/141#comment:1> coreboot <http://www.coreboot.org/>
#141: flashrom: Warn the user when trying to read/write chips which are bigger than what the chipset can decode -------------------------+-------------------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: closed Priority: critical | Milestone: Component: flashrom | Version: Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch has been committed -------------------------+-------------------------------------------------- Changes (by hailfinger): * status: new => closed * patchstatus: there is no patch => patch has been committed * resolution: => fixed Comment: Fixed a few revisions ago. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/141#comment:2> coreboot <http://www.coreboot.org/>
participants (1)
-
coreboot