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

[David Brownell]

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