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

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

[John Rigby]

Sandeep and all interested parties:

I am trying to understand davinci 4-bit nand options for u-boot and
linux.? 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.?? It seems that David (author of the openocd
code) would make a different choice.? 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?

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.

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.

Thanks for any input from all informed parties.

John

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

[John Rigby]

It just occured to me that I might have things backward.  Is your new nand
code trying to avoid the interleaved oob?  If so, sorry for the confusion.

On Wed, Sep 2, 2009 at 9:02 PM, John Rigby <jcrigby@gmail.com> wrote:

> Sandeep and all interested parties:
>
> I am trying to understand davinci 4-bit nand options for u-boot and
> linux.  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.   It seems that David (author of the openocd
> code) would make a different choice.  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?
>
> 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.
>
> 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.
>
> Thanks for any input from all informed parties.
>
> John
>

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

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

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

[David Brownell]

On Wednesday 02 September 2009, John Rigby wrote:
> 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.

Yes; not the clearest English.


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

That ought to work for you.  I've go an OpenOCD pach in the
works to speed that up a bunch too.


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

ISTR docs on '365 don't cover the OOB layout as used by the
RBL well ... a third layout seems to be implied.