On 23.01.2010 18:59, Uwe Hermann wrote:
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
0x3fc0 is the failed byte count, not an address.
if the chip contains a certain image of random bytes. If I program another image the failing place is reproducibly always 0x3ef4.
Same for 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.
Yes, that's expected. Verbose mode will tell you that flashrom does a fallback to whole-chip erase after the sector erase fails.
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.
From my datasheet:
SA = sector addresses: For the AT49F002(N): SA = 00000 to 03FFF for BOOT BLOCK Nothing will happen and the device goes back to the read mode in 100 ns SA = 04000 to 05FFF for PARAMETER BLOCK 1 SA = 06000 to 07FFF for PARAMETER BLOCK 2 SA = 08000 to 1FFFF for MAIN MEMORY ARRAY BLOCK 1 This command will erase - PB1, PB2 and MMB1 SA = 20000 to 3FFFF for MAIN MEMORY ARRAY BLOCK 2
That looks like a 16k, 8k, 8k, 96k, 128k layout (starting at lowest address). Can you tell us where you saw 64k eraseblocks in the datasheet? I looked at http://www.atmel.com/dyn/resources/prod_documents/DOC1017.PDF and didn't see any 64k eraseblocks in there.
Then again, this chip is crazy anyway. It seems that if you erase the Main Memory Array Block 1 it affects the Parameter Blocks as well. If that is true, we have a big problem because the address of the erase command does not correspond with the erased block anymore and we should tar and feather the hw designer. Put differently, if you do a block-by-block erase/write, a later erase (MMB1) will kill earlier writes (PB1/PB2).
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.
Yes, the eraseblocks are listed as starting from the lowest address. A top boot block device will therefore start with big eraseblocks (bottom of flash) and end with small eraseblocks (top of flash).
Regards, Carl-Daniel