From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.newsguy.com ([74.209.136.69]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VplTW-0006jQ-TG for linux-mtd@lists.infradead.org; Sun, 08 Dec 2013 21:01:15 +0000 Message-ID: <52A4DDCF.60400@newsguy.com> Date: Sun, 08 Dec 2013 12:59:59 -0800 From: Mike Dunn MIME-Version: 1.0 To: Tony Lindgren Subject: Re: OMAP3 NAND ECC selection References: <52A04E75.3010609@corscience.de> <20131205171326.GA26766@atomide.com> <20131205182628.GF2345@localhost> <20980858CB6D3A4BAE95CA194937D5E73EA5222E@DBDE04.ent.ti.com> <20131205200618.19b33ee2@skate> <20131205203237.047cfbb9@skate> <20131205193834.GJ26766@atomide.com> In-Reply-To: <20131205193834.GJ26766@atomide.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Petazzoni , Brian Norris , Ezequiel Garcia , Enric Balletbo Serra , "linux-mtd@lists.infradead.org" , "Gupta, Pekon" , Peter Meerwald , Javier Martinez Canillas , "linux-omap@vger.kernel.org" , =?ISO-8859-1?Q?Andreas_Bie?= =?ISO-8859-1?Q?=DFmann?= List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 12/05/2013 11:38 AM, Tony Lindgren wrote: > * Thomas Petazzoni [131205 11:33]: >> Dear Brian Norris, >> >> On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: >> >>>> The long term benefits is simply to properly handle the hardware >>>> constraints. We have hardware platforms were parts of the NAND *MUST* >>>> use 1-bit ECC to be compatible with the ROM code, and other parts of >>>> the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the >>>> NAND requirements. >>> >>> Using 1-bit ECC on NAND is not a long-term solution. Given that fact, >>> I think your ROM code is what may need to change, not the entire MTD >>> subsystem. >> >> As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC >> supported by ROM code vs. 4 or 8 bits required by NAND. But we can very >> well imagine that tomorrow ROM code will support BCH4 (and the NAND >> will ensure block 0 is OK for use with BCH4) but the rest of the NAND >> will require BCH16 or something like that. >> >> I'm not designing ROM code, and the fact that they today have this >> limitation, should be an indication that Linux should be capable of >> handling different ECC schemes to handle those hardware constraints. > > Yeah and it seems that for the bootloader partition we need to be able > to specify the ECC scheme in the .dts file to avoid having people trash > their system unless they really want to do it. > > /me at least has rebooted and reflashed way too many times unnecessarily > while trying to update MLO or u-boot from the kernel. The M-Sys/Sandisk docg4 flash chip has a similiar issue, but is even more esoteric than merely a different ecc scheme for the SPL/u-boot partition. Not only is a different ecc scheme used for the SPL (actually it uses no ecc at all), but the flash controller must be placed into a special (proprietary) mode ("reliable mode") before the SPL is written. Like the omap2 solution, the docg4 driver can be loaded with a special module parameter that enables writing the SPL partition in this mode. The docg4 is kind of a special case, though, because it is a nand flash wrapped inside a proprietary non-standard flash controller. Mike