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 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.

    I talked to Gerhard yesterday and he told me there is something like that on
    ONFI NAND. I think I now understand why that new register is in-place.
    Apparently, in the ONFI NAND case, there is a READY and TRUE-READY signal and
    one of those reflects that _all_ the dies have finished their operation. This is
    in my opinion seriously misdesigned as it breaks any kind of backward
    compatibility.

    > 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.

    Can these SPI flash makers screw the design even more? OT: Why don't we have a
    single standard for all the SF chips which won't need all these crappy quirks
    :-(

    Best regards,
    Marek Vasut


    \
     
     \ /
      Last update: 2014-04-09 12:41    [W:2.324 / U:1.528 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site