[RESUBMIT] [PATCH] [MTD] NAND nand_ecc.c: rewrite for improved performance
Troy Kisky
troy.kisky at boundarydevices.com
Mon Aug 18 18:10:14 EDT 2008
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
More information about the linux-mtd
mailing list