>From: Matthieu CASTET [mailto:matthieu.castet@xxxxxxxxxx] >> From: Pekon Gupta [mailto: pekon@xxxxxx] >> >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. >> >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. > I'm afraid, the OMAP35xx TRM does give much information about BCH ecc-scheme being used by ROM code. Though it says that BCH4 ecc-scheme would be selected for booting in cases when NAND_ID2 matches a particular value. But nothing much is clear (Reference [1]). Can you please point me to any other document or link which gives more info about the same ? >> (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. > For AM33xx and newer DRA7xx platforms, allows user to explicitly select between no ECC, BCH8 or BCH16. Thus ROM code of newer OMAP devices supports BE-NAND. (refer [2]). [1] http://www.ti.com/product/omap3530 http://www.ti.com/litv/pdf/spruf98x Chapter 25: Initialization Section 25.4.7.4 NAND Table 25-34. ID2 Byte Description [2] 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 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
