[RESUBMIT] [PATCH] [MTD] NAND nand_ecc.c: rewrite for improved performance

[Frans Meulenbroeks]

@David:

I have no need for access to a big-endian system as I have the NSLU2

@Troy:

I'll look into this tonight (I'm about to leave to work now).
I already saw that the 11 bits count would go wrong if either of the
two lower bits were to flip by accident, so as a minimum these should
be masked off before counting.
But I will dig further into this & will follow up on this.

Best regards, Frans.



2008/8/19 Troy Kisky <troy.kisky at boundarydevices.com>:
> Troy Kisky wrote:
>> Frans Meulenbroeks wrote:
>> (ignoring inversions)
>> Example: You have a block of all zeros.
>>
>> The ecc stored in the spare bytes of this is also 0.
>> Now, upon reading this block of zeroes, a two bit ecc occurs. The bits that happen to be
>> read incorrectly are bit # 0 & bit # 0x3f of the block
>> The hardware calculated ecc will be
>> 0:0 ^ 0:fff = 0:fff after bit 0
>> 0:fff ^ 3f:fc00 = 3f:3f after bit 3f
>>
>> Now, when your algorithm counts bits you get 12, and decide
>> it is a single bit ecc error.
>>
>> The old way however will xor the high and low 12 bits 3f ^ 3f = 0, 0 != fff and
>> decide it is multi bit ecc error and give an error.
>>
>> Note, that both approaches would have decide it was a single bit error, if the second
>> error wouldn't have happened.
>>
>>
>> So, try a block of zeroes and flip bits 0 and 0x3f.
>>
>> Troy
>>
>
> Whoops, that's a 512 bytes ecc example (as that's what I'm used to).
>
> The 256 byte ecc may be harder. How about
> bit 0, 0x3f, and the 1st bit of the ecc
>
>  0:0 ^ 0:7ff = 0:7ff after bit 0
>  0:7ff ^ 3f:7c00 = 3f:3f after bit 3f
>  3f:3f ^ 0:1 = 3f:3e
>
>
>
> This is 11 bits but 3f^3e = 1, 1 !=7ff and the old algorithm will refuse to correct.
> So the new behavior is different.
>
> Any extra detection is worth it to me.
>
> Troy
>
>