[U-Boot] More davinci 4-bit hw ecc questions

[John Rigby]

Thanks David, I'm less confused now.  I think part of my misunderstanding is
this comment about the new nand_read_page_hwecc_oob_first function in
nand_base.c:

 * Hardware ECC for large page chips, require OOB to be read first.
 * For this ECC mode, the write_page method is re-used from ECC_HW.
 * These methods read/write ECC from the OOB area, unlike the
 * ECC_HW_SYNDROME support with multiple ECC steps, follows the
 * "infix ECC" scheme and reads/writes ECC from the data area, by
 * overwriting the NAND manufacturer bad block markings.

I had a hard time parsing everything past "unlike".  From what you have said
I gather that ECC_HW_SYNDROME does the bad "infix ECC" and the new
OOB_NAND_ECC_HW_OOB_FIRST method does not.  I think different wording would
help here.

We will be using mainline linux and u-boot.  The first version of the board
will likely by 2K slc so looks like we are fine with 1-bit hw ecc.  We may
just plan on using OpenOCD to write UBL and U-Boot if the RBL in the silicon
needs infix 4-bit ecc.  We need to check once more how UBL is written on the
365 based dev boards we have right now.  Of course TI could change to
non-infix between now and when we start manufacturing so we just need to be
ready for either.

Thanks
John

On Wed, Sep 2, 2009 at 10:25 PM, David Brownell <david-b at pacbell.net> wrote:

> On Wednesday 02 September 2009, John Rigby wrote:
> > Sandeep and all interested parties:
> >
> > I am trying to understand davinci 4-bit nand options for u-boot and
> > linux.
>
> In flux just now.  The techinical issue is an ECC engine that's a
> bit rough to work with except on small page chips.  Summary of what
> OpenOCD calls "hwecc4" ECC handling:
>
>  - Small (512 byte) page support:  been in Linux for a few releases
>   now, and in the current OpenOCD code.  No U-Boot support at all
>   (small page being increasingly rare).
>
>  - Large (2KB) page support:  Linux patches are in the MM tree
>   finally; recently pulled into mainline U-Boot; handled by
>   the current OpenOCD code.
>
>  - 4KB large page support (e.g. for MLC chips):  nothing in
>   the queue for Linux or U-Boot, their NAND frameworks aren't
>   able to deal with that much ECC data.  Basic OpenOCD support
>   in the current version.
>
> In short, the integration isn't quite complete yet; but everyone
> is working to make it work with that mode.  (I'm not sure the
> state of the "UBL" code on DaVinci -- the second stage loader
> invoked by the ROM boot loader, which sets up DRAM and then
> load U-Boot.)
>
>
> Whereas the current OpenOCD release supports that *and* a mode
> it calls "hwecc4_infix", primarily to support interop with the ROM
> boot loader on various chips (like current DM355):
>
> > I did some searching and found this comment in the davinci
> > nand driver for openocd:
> >
> > /*
> >  * "Infix" OOB ... like Linux ECC_HW_SYNDROME.  Avoided because it
> trashes
> >  * manufacturer bad block markers, except on small page chips.  Once you
> >  * write to a page using this scheme, you need specialized code to update
> >  * it (code which ignores now-invalid bad block markers).
> >  *
> >  * This is needed *only* to support older firmware.  Older ROM Boot
> Loaders
> >  * need it to read their second stage loader (UBL) into SRAM, but from
> then
> >  * on the whole system can use the cleaner non-infix layouts.  Systems
> with
> >  * older second stage loaders (ABL/U-Boot, etc) or other system software
> >  * (MVL 4.x/5.x kernels, filesystems, etc) may need it more generally.
> >  */
> >
> > This appears to be the ecc mode that Sandeep is trying to establish as
> > the norm going forward.
>
> Don't think so ...
>
>
> > It seems that David (author of the openocd
> > code) would make a different choice.
>
> There was discussion on the DaVinci list a while back wherein
> it was stated that TI's direction moving forward is to move away
> from this "infix" OOB layout.  This involves new ROM code on the
> various chip supporting the 4-bit ECC hardware (DM355, DM365,
> OMAP-L13X, more).
>
> That's why TI (Sneha mostly, but Sandeep most recently) defined
> a new "OOBFIRST" HW_ECC mode in the Linux-MTD stack, and updated
> the NAND framework to take an extra "page" parameter as input
> to some lowlevel calls (needed to implement that HW_ECC mode).
>
>
> > So what is the "right" thing to
> > do?  We are starting development of a new board and need to make a
> > decision.  What are the pros and cons of the two 4-bit alternatives?
>
> What kernel are you using?  If it's from MontaVista (based on
> 2.6.10 or 2.6.18) you'll likely want the "hwecc4_infix" mode.
>
> But all the mainline versions of U-Boot and Linux are aiming
> at the non-infix code.
>
>
> > Here is my two cents (maybe three cents) from my own experience:
> >
> > On the one hand, you can mitigate the trashed bad block marker problem
> > by using an in flash bad block table that you create on first boot.
> > Theoretically you never need the manufactuer markers after that.
>
> But in the Real World (tm) that's less certain.  Speaking purely
> as a developer, I assure you I've needed to regen the BBT tables.
> Theory doesn't quite match reality.
>
>
> > On the other hand, I know that Control4 (where I work now) had
> > difficulty getting nand chips pre-programmed for an i.MX31 platform
> > that had interleaved ecc like this.  I believe the workaround involved
> > post processing an image to "fool" the nand programmer that assumed a
> > conventional oob layout.
> >
> > At Freescale I worked on a nand driver for the MPC5121 that had
> > similar issues and it was disliked so much that the driver that
> > finally made it into u-boot has software ecc only.
>
> Thankfully TI is helping make sure the 4-bit ECC hardware can be
> used properly.  :)
>
> However, *today* the most interoperable solution uses 1-bit ECC
> hardware.  And the 4-bit stuff isn't sorted out yet; the code is
> queued though, which seems like overdue progress.
>
> - Dave
>
>
> > Thanks for any input from all informed parties.
> >
> > John
> >
> >
>
>
>