See patch.
According to my datasheet these erase-blocks are incorrect. I tested an AT49F002(N)T chip and "./flashrom -E" did indeed fail:
ERASE FAILED at 0x0003c000! Expected 0xff, Read=0x44, failed byte count from 0x0003c000-0x0003ffff: 0x3fc0
The failing location is always 0x3fc0 if the chip contains a certain image of random bytes. If I program another image the failing place is reproducibly always 0x3ef4. So it likely differs per image that is programmed on the chip before the erase is done.
However, a read after an -E operation results in an image will all-0xff nonetheless. Interestingly, doing -E a second time will also report SUCCESS.
My attached patch also reports the same error, still. As 0x3c000-0x03ffff is the 16KB boot block, the write-protection mechanism for that boot block seems to interfere. AFAIK we don't yet implement that mechanism (I might post a patch later).
Anyway, the attached patch is more correct than svn anyway (unless I read the datasheet wrong), so we should apply it nevertheless IMHO.
Oh, one question -- is the order of erase-blocks as specified in flashchips.c relevant? AT49F002(N) and AT49F002(N)T have different orders right now.
Uwe.