Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to supportlarge-page Nand chip

[LiuShuo]

ä 2011å12æ15æ 04:15, Scott Wood åé:
> On 12/14/2011 02:41 AM, LiuShuo wrote:
> > ä 2011å12æ13æ 10:46, LiuShuo åé:
> > > ä 2011å12æ13æ 05:30, Scott Wood åé:
> > > > On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
> > > > > On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
> > > > > > NAND chips come from the factory with bad blocks marked at a certain
> > > > > > offset into each page.  This offset is normally in the OOB area, but
> > > > > > since we change the layout from "4k data, 128 byte oob" to "2k
> > > > > > data, 64
> > > > > > byte oob, 2k data, 64 byte oob" the marker is no longer in the
> > > > > > oob.  On
> > > > > > first use we need to migrate the markers so that they are still in
> > > > > > the oob.
> > > > > Ah, I see, thanks. Are you planning to implement in-kernel migration or
> > > > > use a user-space tool?
> > > > That's the kind of answer I was hoping to get from Shuo. :-)
> > > OK, I try to do this. Wait for a couple of days.
> > >
> > > -LiuShuo
> > I found it's too complex to do the migration in Linux driver.
> >
> > Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is
> > enough.
> Any reason not to do it automatically on the first U-Boot bad block
> scan, if the flash isn't marked as already migrated?
>
> Further discussion on the details of how to do it in U-Boot should move
> to the U-Boot list.
>
> > And let user ensure it been completed before linux use the Nand flash chip.
> I don't want to trust the user here.  It's too easy to skip it, and
> things will appear to work, but have subtle problems.
>
> > Even if we don't do the migration, the bad block also can be marked as bad
> > by wearing. So, do we really need to take much time to implement it ?
> > (code looks too complex.)
> It is not acceptable to ignore factory bad block markers just because
> some methods of using the flash may eventually detect an error (possibly
> after data is lost -- no guarantee that the badness is ECC-correctable)
> and mark the block bad again.
>
> If you don't feel up to the task, I can look at it, but won't have time
> until January.
hi Scott,
It's really hard to me and I have much other works to do now. Thanks for 
your help.

hi Artem,
Could this patch be applied now and we make a independent patch for  bad 
block information
migration later?

-LiuShuo

> -Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/