lkml.org 
[lkml]   [2014]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Add support for flag status register on Micron chips
Date
On Wednesday, April 09, 2014 at 08:14:49 PM, Graham Moore wrote:
> On Wed, Apr 9, 2014 at 6:09 AM, Gerhard Sittig <gsi@denx.de> wrote:
> > On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote:
> >> On Tuesday, April 08, 2014 at 06:12:49 PM, grmoore@altera.com wrote:
> >> > From: Graham Moore <grmoore@altera.com>
> >> >
> >> > This is a slightly different version of the patch that Insop Song
> >> > submitted
> >> > (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de).
> >> >
> >> > I talked to Insop, and he agreed I should submit this patch as a
> >> > follow-on to his.
> >> >
> >> > This patch uses a flag in the m25p_ids[] array to determine which
> >> > chips need to use the FSR (Flag Status Register).
> >> >
> >> > Rationale for using the FSR:
> >> >
> >> > The Micron data sheets say we have to do this, at least for the
> >> > multi-die 512M and 1G parts (n25q512 and n25q00). In practice, if we
> >> > don't check the FSR for program/erase status, and we rely solely on
> >> > the status register (SR), then we get corrupted data in the flash.
>
> [...]
>
> >> > Micron told us (Altera) that for multi-die chips based on the 65nm
> >> > 256MB die, we need to check the SR first, then check the FSR, which
> >> > is why the wait_for_fsr_ready function does that. Future chips based
> >> > on 45 nm 512MB die will use the FSR only.
> >
> > This sounds to me similar to polling the NAND's R/B pin until the
> > operation has completed, to then fetch the STATUS byte to
> > determine the execution's result. Does this sound plausible?
> > For NOR, do you poll for the "busy" condition to deassert, and
> > check for success then?
>
> Sounds plausible to me. We poll the SR until not busy, then poll the
> FSR until it's not busy. Success is when FSR busy is deasserted
> within the timeout.
>
> Micron said we have to read the FSR "at least once", so we don't
> read it once for every die or anything like that. I ran a quick
> test, and for both the 2-die and 4-die parts, the FSR shows not busy
> on the first read after SR not busy.

I'd love to know how this FSR-not-busy is exactly related to SR-not-busy, but I
guess only Micron can tell :-/

Best regards,
Marek Vasut


\
 
 \ /
  Last update: 2014-04-10 07:01    [W:0.592 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site