Am Mittwoch, den 27.01.2010, 00:38 +0100 schrieb Idwer Vollering:
Using flashrom r883, probing, reading and writing your chip works; erasing is work in progress (Sean ?).
Luc: the chip itself doesn't appear to be broken because writing a 512KB file created with dd from /dev/zero and reading it back, then comparing the empty and readout file with md5sum shows that the files are identical (ergo empty) -- yes, I saved the original content. ( http://www.flashrom.org/pipermail/flashrom/2009-October/000777.html )
So, summary: The original problem was a destroyed byte at 0x5555 in the chip. It contains the magic 0xAA instead of the required 0xFF. This is a sign of a magic write instruction mistaken as data write instruction. If the image to write did not have the bits set that get cleared by the wrong 0xAA write, this location verifies for obvious reasons.
But then you get some clue by looking at further details. If the 5555 location passes, you get verify errors at 2a000. The total count of failed bytes is 0x16fd, or probably, if we "fix" the 5555 location it is 0x16fc, approximately 1.4 pages of 4KB. The readout you posted to the channel contained this:
00029ff0 95 04 41 39 2c 41 09 82 e3 a1 17 f4 d0 e2 e1 4a |..A9,A.........J| 0002a000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
It shows that the whole area above 0x2a000 is unprogrammed. As we can exclude a broken chip (it worked on your machine), I suspect a broken machine flashrom was used on. My current (and quite plausible) working hypothesis is that the page table entry on yuri's original machine that should point to 0xfffaa000 (where the flash chip address 2a000) gets mapped was wrong and didn't really point to 0xfffaa000, but some unused memory location that always reads as 0xff (making his verify fail with expected=0xff) and ignores writes (so the chip stays in armed-for-write mode over the missing access to 0x2a000 and writes the 0xaa to 0x5555) when sending the write enable instruction again to retry flahsing of this byte.
It would be interesting to check whether this ffff-area that starts at 2a000 ends at 2afff, which would indicate exactly one machine page missing (staying deleted from the block erase). As the failed byte count is more than 0x1000, namely 0x16fd, I suspect a second page to be broken.
yuri: Please run memtest86 on your machine. You might have memory problems that cause silent data corruption.
Regads, Michael Karcher