From: Chuck Peplinski <chuck@mds.com>
To: Marek Vasut <marex@denx.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] Check flag status register for Micron n25q512a
Date: Tue, 04 Mar 2014 15:45:46 -0600 [thread overview]
Message-ID: <5316498A.8080200@mds.com> (raw)
In-Reply-To: <201403040129.12504.marex@denx.de>
On 3/3/2014 6:29 PM, Marek Vasut wrote:
>> FSR can apparently toggle without SR.
> Is that documented anywhere ? How can that be ?
I'm looking at the data sheet for the part, n25q_512mb_1ce3v_65nm.pdf,
from the Micron web site at
http://www.micron.com/products/nor-flash/serial-nor-flash#fullPart&236=10.
The comment that led us in this direction is on page 62:
"ERASE Operations
When the operation is in progress, the program or erase controller bit
of the flag status
register is set to 0. The flag status register must be polled for the
operation status. When
the operation completes, that bit is cleared to 1.
Note that the flag status register must be polled even if operation
times out."
> Hmmmm , I have a feeling that if you actually added wait_till_ready()
> call at the end of _erase() and _write(), you would get the same
> effect. This would in turn mean you are instead missing
> wait_till_ready() somewhere else. Can you try using wait_till_ready()
> at the end of _erase() and _write() please ?
That would be the standard code, right? That's where we started and it
did not work.
At some point I'll try some more tests. I'm not blocked on this now, so
it's not totally critical.
One thing I notice: The web site notes that this part stacks two 256M
dies. Maybe that's why it is non-standard?
Sure would be nice to hear from someone at Micron...
next prev parent reply other threads:[~2014-03-04 21:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 5:21 [PATCH] Check flag status register for Micron n25q512a Insop Song
2014-01-06 5:21 ` Insop Song
2014-02-27 7:33 ` Brian Norris
2014-02-27 7:33 ` Brian Norris
2014-02-27 20:01 ` Marek Vasut
2014-02-27 20:01 ` Marek Vasut
2014-03-01 2:44 ` Insop Song
2014-03-01 2:44 ` Insop Song
2014-03-01 14:48 ` Chuck Peplinski
2014-03-01 19:01 ` Marek Vasut
2014-03-01 19:22 ` Marek Vasut
2014-03-01 19:22 ` Marek Vasut
2014-03-02 5:28 ` Chuck Peplinski
2014-03-02 14:42 ` Marek Vasut
2014-03-03 16:52 ` Chuck Peplinski
2014-03-04 0:29 ` Marek Vasut
2014-03-04 21:45 ` Chuck Peplinski [this message]
2014-03-06 9:25 ` Jagan Teki
2014-03-06 10:03 ` Harini Katakam
2014-03-06 11:53 ` Marek Vasut
2014-03-01 2:00 ` Insop Song
2014-03-01 2:00 ` Insop Song
2014-03-01 19:04 ` Marek Vasut
2014-03-01 19:04 ` Marek Vasut
2014-04-18 15:07 ` Yves Deweerdt
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=5316498A.8080200@mds.com \
--to=chuck@mds.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.