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.
On 1/23/10 6:59 PM, Uwe Hermann wrote:
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.
The T variant is usually "top bootblock" while the other one has the bootblock in the bottom.
This makes the T variants a good fit for x86 systems and the non-T variants for everything else
Stefan
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
On Sat, Jan 23, 2010 at 07:53:44PM +0100, Carl-Daniel Hailfinger wrote:
Yes, that's expected. Verbose mode will tell you that flashrom does a fallback to whole-chip erase after the sector erase fails.
Hm, that should also be printed in non-verbose then, 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.
Yeah, we talked about this on IRC, and it turns out there are various AT49* chips with the same IDs. "Luckily" they seem to have an "additional device code" field we can query which hopefully allows us to differ between the chips. See http://atmel.com/dyn/products/product_card.asp?part_id=3076, page 14 for the ID mechanism. This datasheet is also what I looked at for the chip, which has the block layout I posted in my patch.
If nobody beats me to it I'll post a patch for handling all of these chips properly.
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).
Hm, does this make more sense if looking at the datasheet I posted?
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).
Ah, yes. Makes sense, thanks!
Uwe.
On 23.01.2010 18:59, Uwe Hermann wrote:
Anyway, the attached patch is more correct than svn anyway (unless I read the datasheet wrong), so we should apply it nevertheless IMHO.
Could you please regenerate the patch with at least 17 lines of context? Otherwise it is very difficult to review without applying it (no chip name/ID in the patch).
To generate a diff with 17 lines of context in svn: svn diff -x -U17 --diff-cmd diff
Thanks!
Regards, Carl-Daniel
On 1/23/10 9:59 AM, 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 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.
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
http://atmel.com/dyn/products/product_card.asp?part_id=3076 for the AT49F002ANT http://www.atmel.com/dyn/products/product_card.asp?family_id=624&family_... for the AT49F002NT
-
Carl-Daniel Hailfinger -
Sean Nelson -
Stefan Reinauer -
Uwe Hermann