Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP

[pekon <pekon@pek-sem.com>]

Hi,

On Thursday 13 November 2014 04:59 PM, Roger Quadros wrote:
[...]
>
> What about performance impact? OMAP3 doesn't have ELM module. So error location
> for BCH8 has to be done in software.
>

Performance impact happens only when there are bit-flips in an page.
- For BCH8_HW ECC schemes
ELM comes in the picture only when during reads there is an ECC 
mis-match, if there is no ECC mis-match GPMC engine alone handles all 
the decoding part.

- For BCH8_SW ECC schemes
Same-way, lib/bch.8: decode_bch() path is taken only when ECC mismatch 
is detected on the read path, for normal read/write GPMC engine handles 
everything.

Yes, you may argue that with aging of the NAND the occurrence of 
bit-flips is common. That's true, but for new devices especially for SLC 
NAND the occurrence is usually rare on fresh parts. Also considering 
that most SLC are now manufactured in matured technologies.

Also, if you are using UBIFS on top of NAND, then it will scrub the data 
on first detection of bit-flips, thereby reducing the accumulation of 
bit-flips and thereby conserving read performance.


>>
>>
[...]
>> Right no objections to using BCH8 for rootfs, except it stopped working
>> over past year or so.
>
> This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine.
> So it seems nobody has used/tested BCH8-sw.
>
I have tested BCH8_SW on both AM335x and later SoC, and checked its 
compatibility with various combinations of u-boot. [1] should give you 
some indications of various combinations users can try ..


with regards, pekon

[1]
http://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide#ECC_schemes_support


------------------------
Powered by BigRock.com