[flashrom] [PATCH] AMIC A25LxxPx

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Jul 23 14:49:58 CEST 2010


On 22.07.2010 15:35, Daniel Lenski wrote:
> On Thu, Jul 22, 2010 at 7:58 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> Side note: If anyone is looking for the datasheet for the
>> not-yet-supported A25L032 family, here it is:
>> http://www.amictechnology.com/pdf/A25L032.pdf
>>     
>
> I took a look at this.  Similar to the others from AMIC but...
>
> Incredibly, the data sheet states two different device ID values on
> page 31 (it's either 0x3016 or 0x4016).  Does anyone know which is
> right?
>   

According to my datsheets, the following is true:
0x7f37 0x2025 is A25L16PT (top)
0x7f37 0x2015 is A25L16PU (bottom)
The chips above are already supported.

The chips below are all unsupported:
http://www.amictechnology.com/pdf/A25L512.pdf
http://www.amictechnology.com/pdf/A25L010.pdf
http://www.amictechnology.com/pdf/A25L020.pdf
http://www.amictechnology.com/pdf/A25L040.pdf
http://www.amictechnology.com/pdf/A25L080.pdf
http://www.amictechnology.com/pdf/A25L016.pdf
http://www.amictechnology.com/pdf/A25L032.pdf
http://www.amictechnology.com/pdf/A25LQ032.pdf
IDs:
0x37 0x3010 is A25L512 (uniform 4k sectors)
0x37 0x3011 is A25L010 (uniform 4k sectors)
0x37 0x3012 is A25L020 (uniform 4k sectors)
0x37 0x3013 is A25L040 (uniform 4k sectors)
0x37 0x3014 is A25L080 (uniform 4k sectors)
0x37 0x3015 is A25L016 (uniform 4k sectors)
0x37 0x3016 is A25L032 (uniform 4k sectors)
0x37 0x4016 is A25LQ032 (uniform 4k sectors)
Please note that the IDs of the newer chips all use AMIC_ID_NOPREFIX
instead of AMIC_ID, and that means they use probe_spi_rdid instead of
probe_spi_rdid4.


> This device has *two* status registers, with separate RDSR-1 and
> RDSR-2 commands, but a combined WRSR command.  The first has the
> standard block protect bits BP0-2, while the second has an "All
> protect" (APT) bit which overrides the BP bits.  I think the unlock
> procedure would have to be modified to account for this APT bit.
>   

You can either set .unlock=NULL or write a new unlock function. If you
decide to write a new unlock function, please note that you'll need an
audit of all SPI programmer drivers to check whether they can deal with
such writes. I can help with such an audit, but I'd be happy if I could
postpone that work a bit because my TODO list is huge. OTOH, drivers
without unlock should be mergeable quickly.

Side note: Right now we have the AMIC chips after the Atmel chips in
flashchips.c instead of placing them directly after the AMD chips. Not
sure if a move makes sense (good for consistency, but it will mess up
svn blame).

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the flashrom mailing list