[flashrom] via epia cn1000eg flash failed.

[Michael Karcher]

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