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

[John Rigby <jcrigby@gmail.com>]

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
>