From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 5 Mar 2012 11:58:35 -0700 Subject: [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard) In-Reply-To: <4F4E9201.60502@freescale.com> References: <4F4E1622.1080807@flatfrog.com> <4F4E9201.60502@freescale.com> Message-ID: <20120305185835.GG18051@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Feb 29, 2012 at 03:00:49PM -0600, Scott Wood wrote: > On 02/29/2012 06:12 AM, Orjan Friberg wrote: > > For the beagleboard, ecc.size is not explicitly set when doing 'nandecc > > sw'. If it's not set for the NAND_ECC_SOFT case in nand_scan_tail, it's > > set to 256 bytes. > > > > When doing 'nandecc hw', ecc.size is set to 512 bytes. Hence, when > > changing back to 'nandecc sw' ecc.size remains at 512 bytes and suddenly > > the format has changed. > > > > > > It seems the current nandecc command needs to set this explicitly, but > > also needs to be augmented to be able to select the newly added 4/8-bit > > BCH ECC. > > Yes, that looks like a bug in omap_nand_switch_ecc(). Correct. And wrt using the new 4/8/16-bit BCH library, that's what I was starting on when I found the nand dump issue :) > > But it also seems like nandecc selection should be more generic than for > > omap3 (currently it lives in arch/arm/cpu/armv7/omap3/board.c). > > ECC mode is normally not something that you want to be runtime > switchable, as changing it usually changes the on-flash format. It also > requires driver cooperation -- the actual implementation (as opposed to > the command-line wrapper) is in drivers/mtd/nand/omap_gpmc.c. There is unfortunately a long-running saga here and what we have now is what we have for a number of existing platforms. Moving forward, things are better and there's an argument at least for not making ECC mode switching a run-time command. -- Tom