[U-Boot] [PATCH v6 2/8] lpc32xx: mtd: nand: add MLC NAND controller

[Albert ARIBAUD]

Hi Scott,

Le Mon, 23 Mar 2015 20:20:50 -0500, Scott Wood
<scottwood at freescale.com> a écrit :

> On Mon, 2015-03-23 at 09:45 +0100, Albert ARIBAUD wrote:
> > Bonjour Scott,
> > 
> > Le Fri, 20 Mar 2015 17:41:11 -0500, Scott Wood
> > <scottwood at freescale.com> a écrit :
> > 
> > > On Fri, 2015-03-20 at 10:35 +0100, Albert ARIBAUD wrote:
> > > > BTW, is there a standard way to ask a NAND chip which page(s) in a bad
> > > > block should be checked?
> > > 
> > > Yes and no:
> > > http://lists.infradead.org/pipermail/linux-mtd/2011-November/038419.html
> > 
> > ... right.
> > 
> > How about this: the driver expects a driver-specific configuration
> > option which tells it which page(s) in a block, and which byte in a
> > page's OOB area, should be scanned for bad block markers, and "my"
> > board provides a value for said option.
> 
> It looks like the common NAND code will set
> NAND_BBT_SCANLASTPAGE/NAND_BBT_SCAN2NDPAGE automatically if it sees
> certain manufacturer IDs, so I don't think drivers should be setting
> them at all (and currently, none do).

Ok.

> That still leaves the question of what to do in SPL.  For simplicity you
> could check every page as you do the normal read.

Ok. Patch series v7 to follow... as soon as I have completed it.

> > This leads me to a half-OT question: so those SPL, while too tiny to
> > handle non-raw images, still do include the whole common/spl/spl.c
> 
> No, there's no room for that.

Ok.

> > > If you want to do this, just put a comment in explaining why you're
> > > skipping in that situation.
> > 
> > Ok -- I will go with the 'option' method then, and add a (lengthy, I'm
> > afraid) comment in common/spl/spl.c explaining that skipping the raw
> > image handling is required when chainloading from NAND and the NAND
> > driver considers totally unreadable sectors bad, in order not to
> > confuse a missing image header with a raw image.
> 
> Skipping raw wouldn't be needed for all NAND drivers, only those that
> aren't guaranteed to halt on a legitimate unrecoverable ECC error.

Understood.

> -Scott

Cordialement,
Albert ARIBAUD
3ADEV