From: Brian Norris <computersforpeace@gmail.com>
To: Marek Vasut <marex@denx.de>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: N25Q256A 13E40
Date: Wed, 9 Oct 2013 14:44:01 -0700 [thread overview]
Message-ID: <20131009214401.GD23337@ld-irv-0074.broadcom.com> (raw)
In-Reply-To: <201310091214.02740.marex@denx.de>
Hi,
On Wed, Oct 09, 2013 at 12:14:02PM +0200, Marek Vasut wrote:
> > On Mon, Oct 7, 2013 at 9:24 AM, Marek Vasut <marex@denx.de> wrote:
> > > Let's talk about our favourite chip :) I just got my hands on N25Q256A .
> > > Since there was quite a flurry of patches for this and similar chips and
> > > I got it working on a different chip with exactly the same IDs and type,
> > > I'd would expect linux to work with this one too. Guess what ... ;-)
> > >
> > > This particular incarnation of N25Q256A completely ignores the 4-byte
> > > ERASE (0xdc) command. Apparently, if I look closely, it's N25Q256A 13E40
> > > variant and seeing the Note #14 (datasheet page 30 / below Table 18.
> > > Command set), quoting:
> > >
> > > 14.This command is only for part numbers N25Q256A83ESF40x and
> > > N25Q256A83E1240x.
> >
> > This note also applies to PAGE_PROGRAM_4B (0x12) as well, right?
>
> Yeah, both ERASE_4B and PP_4B or whatever they're called there. Interestingly
> enough, READ_4B works ;-/
Well, the READ_4B consistency is (unintentionally?) helpful for my
systems, as we have begun implementing a jumper switch so that the boot
ROM will know whether to use FAST_READ or FAST_READ_4B. Since
essentially all large SPI flash at *least* support the READ_4B command
(as you noted), we can reliably boot from the flash, no matter what mode
it is left in. After booting, we can choose the appropriate mode for
programming/erasing.
> > [Now that I went back to look at some more code:] Wait, but we don't
> > even try to use the 4-byte dedicated commands like 0xdc on Micron
> > flash, so why are you having this problem? The code currently stands
> > as:
>
> The JEDEC_MFR for this flash Micron N25Q256A is CFI_MFR_ST (I wonder why).
Probably some series of acquisitions?
But you didn't quite answer my question. Are you having problems with
this Micron/ST/something-that's-not-AMD-or-Spansion flash using the
current mainline? Or did you only have trouble when you tried modifying
the code to use the dedicated 4-byte addressing commands?
> > if (JEDEC_MFR(info->jedec_id) == CFI_MFR_AMD) {
> > /* Dedicated 4-byte command set */
> > ...
Brian
next prev parent reply other threads:[~2013-10-09 21:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-07 16:24 N25Q256A 13E40 Marek Vasut
2013-10-09 1:05 ` Brian Norris
2013-10-09 10:14 ` Marek Vasut
2013-10-09 21:44 ` Brian Norris [this message]
2013-10-12 1:17 ` Marek Vasut
2013-10-15 17:22 ` 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=20131009214401.GD23337@ld-irv-0074.broadcom.com \
--to=computersforpeace@gmail.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.