NAND ECC capabilities

Steve deRosier derosier at gmail.com
Wed Jan 7 22:22:48 PST 2015


Thanks Ezequiel!

On Wed, Jan 7, 2015 at 8:17 PM, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> On 01/08/2015 12:10 AM, Steve deRosier wrote:
>> So, doing further experiments and I wondered if someone could confirm
>> this finding.
>>
>> With atmel_nand, we're setup for 4-bit ECC on 512 sectors with a 2k
>> page.  I was thinking about this a bit and realized that there's 4 of
>> these sectors per page, and this implies then that we can detect and
>> correct 4 bad bits _per_ each sector.  Assuming that they're evenly
>> spread, that's up to 16 bad bits per page.  Obviously in practice,
>> that assumption wouldn't hold...
>>
>
> Not sure why you say that woulnd't hold.
>

Ah, simple.  We have a 2048 byte page (2112 if you count the OOB).  4
bits per 512.  Which means 16 per page _assuming_ they're evenly
spread.  That means 4 in the first 512, 4 in the next etc...   But if
all 16 bit flips were in the first 512, boom, we're done (actually,
only need 5 in that first one). There's no reason to believe that the
bitflips would be evenly over the page (in fact, the opposite is often
true, they seem to cluster in my experience).

This NAND doesn't have subpages, it's a 2K page. The ECC hardware can
do the calculations in 1024 or 512 byte chunks. But those are all for
the one page which acts as a single entity.

It's fair to say we can only do 4 bit-flips per page in this case
because the worst case scenario is all the bits in question would be
in the same 512 sector.


Thanks for your reply!

- Steve



More information about the linux-mtd mailing list