From: Marek Vasut <marex@denx.de>
To: Matthieu CASTET <matthieu.castet@parrot.com>
Cc: Kevin Cernekee <cernekee@gmail.com>,
Brian Norris <computersforpeace@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands
Date: Mon, 18 Mar 2013 16:39:18 +0100 [thread overview]
Message-ID: <201303181639.18602.marex@denx.de> (raw)
In-Reply-To: <5147334C.3040505@parrot.com>
Dear Matthieu CASTET,
> Brian Norris a écrit :
> > Traditionally, the command set used by SPI flash only supported a 3-byte
> > address. However, large SPI flash (>= 32MB, or 256Mbit) require 4 bytes
> > to address the entire flash. Most manufacturers have supplied a mode
> > switch (via a "bank register writer", or a "enable 4-byte mode"
> > command), which tells the flash to expect 4 address cycles from now on,
> > instead of 3. This mode remains until power is cut, the reset line is
> > triggered (on packages where present), or a command is sent to reset the
> > flash or to reset the 3-byte addressing mode.
> >
> > As an alternative, some flash manufacturers have developed a new command
> > set that accept a full 4-byte address. They can be used orthogonally to
> > any of the modes; that is, they can be used when the flash is in either
> > 3-byte or 4-byte address mode.
> >
> > Now, there are a number of reasons why the "stateful" 4-byte address
> > mode switch may not be acceptable. For instance, some SoC's perform a
> > dumb boot sequence in which they only send 3-byte read commands to the
> > flash. However, if an unexpected reset occurs, the flash chip cannot be
> > guaranteed to return to its 3-byte mode. Thus, the SoC controller and
> > flash will not understand each other.
>
> What's funny is the other side work :
>
> you can have a ROM that use 4-byte mode with 3-byte or 2-byte device as
> soon as the read command is the same. [1]
Well, all of these are crap design. The SPI flash shall be power-cycled if the
platform reboots no matter what exactly to prevent having it in undefined state.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2013-03-18 15:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-10 8:41 [PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands Brian Norris
2013-03-10 8:41 ` [PATCH 2/3] mtd: m25p80: correct EN4B/EX4B comment Brian Norris
2013-03-10 8:41 ` [PATCH 3/3] mtd: nand: reword nand_chip bad block interface comments Brian Norris
2013-03-10 11:18 ` [PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands Marek Vasut
2013-03-14 5:46 ` Brian Norris
2013-03-14 9:17 ` Marek Vasut
2013-03-18 7:21 ` Artem Bityutskiy
2013-03-18 7:55 ` Brian Norris
2013-03-18 8:35 ` Peter Korsgaard
2013-03-18 15:37 ` Matthieu CASTET
2013-03-18 15:31 ` Matthieu CASTET
2013-03-18 15:39 ` Marek Vasut [this message]
2013-03-18 16:13 ` Matthieu CASTET
2013-03-18 16:40 ` 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=201303181639.18602.marex@denx.de \
--to=marex@denx.de \
--cc=cernekee@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=matthieu.castet@parrot.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).