Hi, >From: Thomas Petazzoni [mailto:thomas.petazzoni@xxxxxxxxxxxxxxxxxx] >>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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
