Hi all, [...] > But this is interesting: I see the latest datasheet for Spansion > s25fl064k says it supports the Block Protect bits in the Status > Register, so presumably *some* version of s25fl064k should support > write_sr(nor, 0) to unlock it at boot... > > If Felix's initial report is indeed correct, then I think we have: > (1) Spansion s25fl064k without Block Protect support (that breaks if you > try to write SR=0) > (2) Spansion s25fl064k with Block Protect support (that requires you to > unlock at boot by writing SR=0 (?)) > (3) Winbond w25q64 with Block Protect support (that requires you to > unlock at boot by writing SR=0) > > And (1)-(3) all report the same ID, and (1) is incompatible with (2) and > (3). Am I right? Are flash vendors really this insane? Should we all > just give up and go home? >
Just a general remark: maybe reading the JEDEC ID is not a so reliable mean to discover SPI flash hardware capabilities at runtime. Two weeks ago some Macronix people came to Atmel to present us next evolutions of SPI flashes. We took this opportunity to ask them some questions and one of them was about memories with different hardware capabilities sharing the very same JEDEC ID. One example is Macronix MX25L25635E vs MX25L25673G. They explained to us that for Macronix memories, the 2byte product ID is to be split into a 1byte code for the memory type and a second byte for the memory denstity. For instance: C2: Manufacturer ID, Macronix 20: Memory Type, SPI NOR flash 19: Memory density, 256Mib Hence the JEDEC ID only provides information about the memory size and all SPI NOR memories of a given size actually share the same JEDEC ID. Similar cases can also be found with other manufacturers: Micron, Winbond, Spansion... Also the Macronix engineers asked us how software applications drive the (Q)SPI memories. I answered them that Linux or u-boot use a static table indexed by the JEDEC ID, which provides the hardware capabilities. I guess they didn't expect software developers to use the JEDEC ID for this purpose. Well, it's just a feeling. Then the Macronix engineers proposed to use the Serial Flash Discoverable Parameter (SFDP) tables to make the difference between memories sharing the same JEDEC ID. This might help us in some cases. However we should be cautious when using this standard: last year, I've tried to discover hardware parameters through these tables when I was working with Spansion and Micron memories. I found out the Parameter Table Pointers inside the SFDP Header were expressed as byte offset with one memory and as dword offset with the other. So I gave up using these tables since some memories diverged from the standard, which was "work in progress" at that time. Anyway if we cannot completely rely on the SFDP tables we could still use DT properties but we should no longer expect to guess all hardware parameters from the JEDEC ID alone. Best regards, Cyrille
