OMAP3 NAND ECC selection

[Matthieu CASTET]

Le Mon, 9 Dec 2013 04:33:51 +0000,
"Gupta, Pekon" <pekon at ti.com> a écrit :

> Hi,
> 
> >From: Thomas Petazzoni [mailto:thomas.petazzoni at 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