[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Tuesday, September 13, 2011 01:24:22 AM Scott Wood wrote:
> On 09/12/2011 02:42 PM, Marek Vasut wrote:
> > On Monday, September 12, 2011 09:36:49 PM Scott Wood wrote:
> >> On 09/12/2011 02:28 PM, Marek Vasut wrote:
> >>> On Monday, September 12, 2011 09:19:06 PM Scott Wood wrote:
> >>>> What's it doing with them?  Migrating them is something that should
> >>>> only happen on the first use, as there will later be data in the
> >>>> factory bad block area, right?  So it shouldn't be "always". 
> >>>> Migration should be an explicitly requested option.  Like scrub. :-)
> >>>> 
> >>>> Where is the code that does this?  Which driver?
> >>> 
> >>> The BCH accelerator does this.
> >> 
> >> In hardware?  What chip is this, and where is the code that drives this
> >> chip?
> > 
> > I think it does something to it, yes. i.MX287, see the patchset [PATCH
> > 00/15 V2] Support for the DENX M28 SoM, [PATCH 09/15] iMX28: Add GPMI
> > NAND driver .
> 
> I looked at the code and the datasheet, and without getting into it too
> deeply, I don't see how BCH is involved in an erase operation.  What
> specifically are you seeing happen?
> 
> The "Raw NAND Boot Mode" section (12.12 in my copy of the i.MX28 manual)
> says that it uses BCH for ECC -- is this not the case?  Is it some
> special configuration of BCH?
> 
> I tried reading the "Bad Block Handling in the ROM" section and got a
> headache.

12.12.1.8 is exactly it. See fig. 12-11. Also section 12.12.1.9 is interesting 
(at least for the block 0 problem).

For the other problem, you should read chapter 15 and 16. Though they are not 
completely beefed with information on that matter either.

I got most of these information from the source code FSL provided in their MX28 
BSP. The usual flow is the driver uses DMA to send the commands/data to the GPMI 
NAND driver. The GPMI NAND controller diverts the data to the BCH, which does 
the bit obscurisation. Then the data are taken from the BCH and written to NAND.

And the other way in the read process ... GPMI NAND controller reads data back 
from NAND, pushes them through the BCH and then presents them to the user.

The problem with erase here is that the block's ECC is updated on erase. But we 
want to write a block in our own format, so we need to scrub (wipe the block 
completely).

> 
> I work for the PowerPC side of Freescale, in case you're wondering why
> I'm unfamiliar with this. :-)

Interesting ... does everyone work for the PowerPC side of Freescale or is there 
some other reason why I never met anyone working for the ARM side of Freescale ? 
;-)
> 
> -Scott

Cheers