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.