Patchwork Fix erase-blocks specification for the Atmel AT49F002(N)(T)

login
register
about
Submitter Uwe Hermann
Date 2010-01-23 17:59:34
Message ID <20100123175934.GB16543@greenwood>
Download mbox | patch
Permalink /patch/833/
State Bitrotted
Headers show

Comments

Uwe Hermann - 2010-01-23 17:59:34
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.
Stefan Reinauer - 2010-01-23 18:43:42
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
Carl-Daniel Hailfinger - 2010-01-23 18:53:44
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
Carl-Daniel Hailfinger - 2010-01-23 18:57:48
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
Uwe Hermann - 2010-01-23 22:03:49
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.
Sean Nelson - 2010-01-23 22:21:27
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_name=Parallel+Flash&part_id=1815 
for the AT49F002NT

Patch

Fix erase-blocks specification for the Atmel AT49F002(N)(T).

Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>

Index: flashchips.c
===================================================================
--- flashchips.c	(Revision 881)
+++ flashchips.c	(Arbeitskopie)
@@ -1111,8 +1111,8 @@ 
 				.eraseblocks = {
 					{16 * 1024, 1},
 					{8 * 1024, 2},
-					{96 * 1024, 1},
-					{128 * 1024, 1},
+					{32 * 1024, 1},
+					{64 * 1024, 3},
 				},
 				.block_erase = erase_sector_jedec,
 			}, {
@@ -1140,8 +1140,8 @@ 
 		{
 			{
 				.eraseblocks = {
-					{128 * 1024, 1},
-					{96 * 1024, 1},
+					{64 * 1024, 3},
+					{32 * 1024, 1},
 					{8 * 1024, 2},
 					{16 * 1024, 1},
 				},