[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