From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.aswsp.com ([193.34.35.150]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Vpyfj-0002lE-Dw for linux-mtd@lists.infradead.org; Mon, 09 Dec 2013 11:06:44 +0000 Date: Mon, 9 Dec 2013 12:06:09 +0100 From: Matthieu CASTET To: "Gupta, Pekon" Subject: Re: OMAP3 NAND ECC selection Message-ID: <20131209120609.08e62b40@parrot.com> In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA52ADF@DBDE04.ent.ti.com> References: <52A04E75.3010609@corscience.de> <20131205171326.GA26766@atomide.com> <20131205182628.GF2345@localhost> <20980858CB6D3A4BAE95CA194937D5E73EA5222E@DBDE04.ent.ti.com> <20131205200618.19b33ee2@skate> <20131205203237.047cfbb9@skate> <20980858CB6D3A4BAE95CA194937D5E73EA52ADF@DBDE04.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Cc: Thomas Petazzoni , "linux-omap@vger.kernel.org" , Mike Dunn , Ezequiel Garcia , Tony Lindgren , Enric Balletbo Serra , "linux-mtd@lists.infradead.org" , Peter Meerwald , Javier Martinez Canillas , Brian Norris , Andreas =?ISO-8859-15?Q?Bie=DFmann?= List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Le Mon, 9 Dec 2013 04:33:51 +0000, "Gupta, Pekon" a =E9crit : > Hi, >=20 > >From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] > >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: > [...] >=20 > >> 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. > > > Just to highlight few more points: > (1) ROM code on newer OMAP platforms like AM33xx do have the ability > to select ECC scheme by reading a specific location from EEPROM > connected to I2C0.=20 AFAIK on omap3, the rom code first try to read data with bch and if it doesn't work it fallback on haming 1 bit ecc. >=20 > (2) And going forward, ECC based NAND devices may be phased out, > and BE-NAND (Built-in) NAND devices are becoming popular. As both > cost and density wise they are same to SLC NANDs today. Thus issue > of un-compatibility of ecc-scheme with ROM code, will not hold true. > We already have some BE-NAND support in our generic driver. > http://patchwork.ozlabs.org/patch/222186/ >=20 Yes but these flash are not always compatible with the ROM. If the rom is expecting some ECC and the internal controller expect other ecc you are stuck. Matthieu