[U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC

[David Brownell]

On Monday 27 April 2009, Scott Wood wrote:
> David Brownell wrote:
> > On Monday 27 April 2009, Scott Wood wrote:
> >> It is for compatibility with a widely-deployed legacy ECC layout -- more
> >> details can be found in the list archives.
> > 
> > See my original query, which IMO disproves that assertion.
> 
> The entire mess was presented as being for compatibility in these threads:

The *non*BROKEN stuff is certainly compatible with the NAND
code in the DaVinci kernel GIT tree, which is now in mainline.

The BROKEN stuff is somewhat compatible with the MV kernels,
iff restricted to small-page support.  But ... the U-Boot with
which those kernels were shipped doesn't use 1-bit HW ECC, so
that may not be much of a concern.

(The original mainline u-boot large page support was very
broken, and wasn't MV-compatible.  So arguably there were two
separate compatibility issues:  MV, and large-page bugginess.)


> http://lists.denx.de/pipermail/u-boot/2008-June/036055.html
> http://lists.denx.de/pipermail/u-boot/2008-August/039679.html
> 
> If some portions of it aren't actually needed for compatibility, then we 
> can remove them.
> 
> Or we can remove the entire thing, if nobody cares anymore -- if anyone 
> out there does care and is using this, please speak up now.

I'm hoping for the "nobody cares any more" option...

Anyone who *does* can always use their current version
of U-Boot ... or patch it back in.  If there have been
complaints due to lack of compatibility between current
GIT kernels and the MV releases, I've not heard them.


> > What this option enables differs in two ways from what the
> > MontaVista code does.  (Speaking here of the 1-bit HW ECC.
> > The 4-bit support is another mess, which would be made far
> > worse by needing to carry the BROKEN_ECC mode.)
> 
> I see no reason why new features would have to be supported on both 
> sides of the ifdef.

I was referring to a textual mess.  One clean way to add
a broken ECC mode would be as a completely different set
of functions, instead of a pile of #ifdefs.

And 4-bit will be troublesome for other reasons.


> > Which is why I'm wondering what that original U-Boot code
> > for HW ECC was trying to be "compatible" with, since it
> > clearly wasn't MontaVista Linux ... or even the U-Boot
> > versions I've seen be distributed with it.
> 
> MV 2.6.10 was the claim.

Right.  I looked at TI's 1.20 (MV 4.0/2.6.10) and 2.0 beta
(MV 5.0/2.6.18) code, and their sibling U-Boot versions.

If that compatibilty is actually needed, the simplest way
to get it might be to define functions to mangle the the
ECC words (standard ~PQRstu <---> MV PsQRtu) and use the
current *correction* code; the OOB bit pattern changes but
not the algorithm.  I think I'll add a comment about that.

- Dave


> 
> -Scott
> 
>