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@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