RE: OMAP3 NAND ECC selection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux