OMAP3 NAND ECC selection

[Gupta, Pekon]

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. 
Reference:
	http://www.ti.com/product/am3359
	http://www.ti.com/litv/pdf/spruh73i 
	Chapter 26: Initialization  
	Section: 26.1.7.4  Memory Booting > NAND
  	Table 26-17. NAND Geometry Information on I2C EEPROM

(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/

However, I also support user space tool approach rather than having
this included in NAND driver.


with regards, pekon