Message-ID: <56FBCAF4.5060801@atmel.com>
Date:	Wed, 30 Mar 2016 14:47:48 +0200
From:	Cyrille Pitchen <cyrille.pitchen@...el.com>
To:	Brian Norris <computersforpeace@...il.com>,
	Matthias Schiffer <mschiffer@...verse-factory.net>
CC:	Marek Vasut <marex@...x.de>,
	Gernot Hoyler <Gernot.Hoyler@...nsion.com>,
	Felix Fietkau <nbd@...nwrt.org>,
	Rafał Miłecki <zajec5@...il.com>,
	Milton Chiang (江明晏) 
	<Milton.Chiang@...iatek.com>, <linux-kernel@...r.kernel.org>,
	Bayi Cheng <bayi.cheng@...iatek.com>,
	<linux-mtd@...ts.infradead.org>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Eddie Huang (黃智傑) 
	<eddie.huang@...iatek.com>,
	"Nicolas.FERRE@...el.com" <Nicolas.FERRE@...el.com>
Subject: Re: [PATCH for-4.4 1/2] mtd: spi-nor: fix Spansion regressions
 (aliased with Winbond)

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

Powered by blists - more mailing lists