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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthieu CASTET Subject: Re: OMAP3 NAND ECC selection Date: Mon, 9 Dec 2013 12:06:09 +0100 Message-ID: <20131209120609.08e62b40@parrot.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 Return-path: In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA52ADF@DBDE04.ent.ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org@lists.infradead.org To: "Gupta, Pekon" 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-omap@vger.kernel.org Le Mon, 9 Dec 2013 04:33:51 +0000, "Gupta, Pekon" a =E9crit : > Hi, > = > >From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] > >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: > [...] > = > >> 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. = 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. > = > (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/ > = 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 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/