From: James Cameron <quozl@laptop.org>
To: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Cc: "Brian Norris" <computersforpeace@gmail.com>,
"Matthias Schiffer" <mschiffer@universe-factory.net>,
"Marek Vasut" <marex@denx.de>,
"Gernot Hoyler" <Gernot.Hoyler@spansion.com>,
"Felix Fietkau" <nbd@openwrt.org>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Milton Chiang (江明晏)" <Milton.Chiang@mediatek.com>,
linux-kernel@vger.kernel.org,
"Bayi Cheng" <bayi.cheng@mediatek.com>,
linux-mtd@lists.infradead.org,
"Daniel Kurtz" <djkurtz@chromium.org>,
"Eddie Huang (黃智傑)" <eddie.huang@mediatek.com>,
"Nicolas.FERRE@atmel.com" <Nicolas.FERRE@atmel.com>
Subject: Re: [PATCH for-4.4 1/2] mtd: spi-nor: fix Spansion regressions (aliased with Winbond)
Date: Fri, 1 Apr 2016 14:05:04 +1100 [thread overview]
Message-ID: <20160401030504.GG726@us.netrek.org> (raw)
In-Reply-To: <56FBCAF4.5060801@atmel.com>
On Wed, Mar 30, 2016 at 02:47:48PM +0200, Cyrille Pitchen wrote:
> 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.
Yes, that's true.
(Reference: Open Firmware SPI Flash driver used at OLPC.)
>
> 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.
Yes, I too was unable to use SFDP; some devices didn't have them, some
didn't seem to be good data.
>
> 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.
We solved this problem by not using our SPI Flash from the kernel, but
that's not the best outcome. ;-)
>
> Best regards,
>
> Cyrille
--
James Cameron
http://quozl.netrek.org/
next prev parent reply other threads:[~2016-04-01 3:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-15 18:48 [PATCH for-4.4 1/2] mtd: spi-nor: fix Spansion regressions (aliased with Winbond) Brian Norris
2015-12-15 18:48 ` [PATCH for-4.4 2/2] mtd: spi-nor: fix stm_is_locked_sr() parameters Brian Norris
2016-01-05 2:30 ` Brian Norris
2016-01-05 2:29 ` [PATCH for-4.4 1/2] mtd: spi-nor: fix Spansion regressions (aliased with Winbond) Brian Norris
2016-01-06 0:02 ` Brian Norris
2016-01-06 0:03 ` Felix Fietkau
2016-01-06 2:07 ` bayi cheng
2016-03-26 18:57 ` Matthias Schiffer
2016-03-27 22:52 ` Matthias Schiffer
2016-03-28 20:56 ` Brian Norris
2016-03-29 19:14 ` Matthias Schiffer
2016-03-30 12:47 ` Cyrille Pitchen
2016-04-01 3:05 ` James Cameron [this message]
2016-04-01 20:27 ` Brian Norris
2016-04-04 15:33 ` Cyrille Pitchen
2016-04-26 5:54 ` Brian Norris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160401030504.GG726@us.netrek.org \
--to=quozl@laptop.org \
--cc=Gernot.Hoyler@spansion.com \
--cc=Milton.Chiang@mediatek.com \
--cc=Nicolas.FERRE@atmel.com \
--cc=bayi.cheng@mediatek.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@atmel.com \
--cc=djkurtz@chromium.org \
--cc=eddie.huang@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=mschiffer@universe-factory.net \
--cc=nbd@openwrt.org \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).