[U-Boot-Users] [PATCH RFC] ARM: Davinci: NAND fix for large page ECC and linux compatibility

Scott Wood scottwood at freescale.com
Mon Jun 30 17:26:35 CEST 2008


On Sat, Jun 28, 2008 at 11:31:18AM +0800, Bernard Blackham wrote:
> > It seems odd that backwards compatibility requires turning *off* an  
> > option with "compatible" in the name...  I'd invert the sense of the  
> > ifdef, and have it be something like CFG_BROKEN_ECC_COMPATIBILITY.
> 
> The concern with this is people that use their own custom config
> files will need to add this #define when they upgrade. How about
> just changing the name to CFG_NEW_NAND_ECC_FORMAT then?

How about having both, and #erroring if one or the other isn't defined
(similar to what you suggest below, but for both small and large page)?

Also, both should probably be CFG_DAVINCI_xxx rather than CFG_xxx, to make
clear that it's not a general NAND issue.

> > If the old way of doing small page ECC was valid, should we preserve  
> > that (and change Linux back)?
> 
> That's a little controversial. Basically, the old OOB layout didn't
> match any other layout used (except by the MV kernel), the actual
> ECC layout meant that the method for correction was overly complex
> (with 170 non-obvious lines of code), and allegedly broken:
>    http://article.gmane.org/gmane.comp.boot-loaders.u-boot/32035
> 
> The new code is about 30 lines, really simple, and I can even prove
> it's correctness (which I couldn't even begin to with the old code).

OK -- was just making sure that it wasn't a gratuitous change.

> > We should probably default to doing it the right way, not the  
> > broken-but-compatible way for large pages, though.
> 
> It depends if you put backwards compatibility over reliability
> though.

In the long term, I value the latter -- compatibility should be possible,
but it shouldn't cause new users to continue to generate bad ECC indefinetly
(both causing them reliability problems and expanding the number of people
that would be affected if the default were to change down the road).

> This forces the user to make a choice - they'll probably curse while
> they're doing it, but they can't plead ignorance when they find
> their large page NAND isn't detecting ECC errors.

Or when they end up getting lots of ECC errors when using non-MV Linux.

> I really do believe it should be a clean switch from one format to
> the other, for both small and large page NAND, with no run-time
> backwards compatibility. But that's just my POV.

Agreed, that's the simplest route if it can be managed without surprise
breakage.

-Scott




More information about the U-Boot mailing list