From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 27 Apr 2009 15:11:00 -0500 Subject: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC In-Reply-To: <200904271246.38626.david-b@pacbell.net> References: <200904261111.48584.david-b@pacbell.net> <20090426225129.052A783420E8@gemini.denx.de> <20090427185658.GA10355@ld0162-tx32.am.freescale.net> <200904271246.38626.david-b@pacbell.net> Message-ID: <49F61154.1060908@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: 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. > 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. > 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. -Scott