[PATCH] Add driver for M-sys / Sandisk diskonchip G4 nand flash

[Mike Dunn]

On 10/10/2011 11:12 AM, Ivan Djelic wrote:
>
> Hello Mike,

Hi Ivan.  Boy, I wish I had dropped you a line sooner!

> I had a quick look at how you handle BCH ecc correction. If I understood
> correctly:
> - hw generates a 56-bit polynomial remainder (56 = 14*4, m=14, t=4)

Well, m=14 and t=4, yes.  But honestly, I'm not sure what the hardware
generates, except that it is the same size as the syndrome, given m and t.

> - hw-generated polynomial terms are mapped to bits in a way not compatible with
> the BCH library

Well yes, the bit order is backwards.  But again, I'mnot sure what the hardware
gives me.  The key to my success was having a look at some other code that does
the same thing (but using static remainder tables, and preserving the reversed
bit order throughout the whole decoding).  Then I got a basic understanding of
the mechanics of the steps, and for the driver I re-wrote (using generated
remainder tables and reversing the bit order along the way) the first two steps
of the decoding (up to the syndrome calculation), then let your code handle the
rest (error locator polynomial and root-finding).

If you can enlighted me, I'd be grateful!  From what I've been able to
understand from the textbook, it looks to me that the processing normally done
on the entire code polynomial - as described in the text - is done only on the
56 bit hw ecc.  In my simplistic interpretation, it seems that the 56 bits are
some kind of distillation of the entire code vector.  The steps are all the same.

> Still, I do not understand why you go to great lengths computing syndromes in
> your code, using a mix of generated remainder tables and Galois field tables.
>
> Why don't you just reformat the hw-generated polynomial (cheap, only 56 bits
> to shuffle) and let the BCH library do the whole computation ?

Could you elaborate?  What are the 56 bits that the hardware gives me?  It's not
the syndrome, right?  (BTW, I did verify that the results are correct).

>>> +
>>> +     /* undo last step in BCH alg; currently this is a mystery to me */
> Maybe I can help here :)
> This last step exists because the BCH library represents nand data as a large
> polynomial with high order terms first (this is consistent with several hw
> generators). If N is the total bit length of array data[], then byte data[0]
> will contain polynomial terms X^(N-1) (in bit 7), X^(N-2), ... X^(N-8) (in bit
> 0). Byte data[1] will contain X^(N-9) (bit 7) ... X^(N-16) (bit 0) and so on.
>
> Thus, term X^i is located in byte data[(N-1-i)/8], in bit position
> 7-(N-1-i)%8. The last step:
>
>    errloc[i] = (errloc[i] & ~7)|(7-(errloc[i] & 7));
>
> was added just so that users can correct bit errors with byte access:
>
>    data[errloc[i]/8] ^= 1 << (errloc[i] & 7);
>
> instead of (the slightly more complicated):
>
>    data[errloc[i]/8] ^= 1 << (7-(errloc[i] & 7));
>
> And that's all there is to it, really.
>
> Looking at your code, it seems that your hw generator represents nand data[] as
> a 32-bit words array with high order terms in lower bits (assuming your machine
> is little-endian):
>
> data[0] = X^(N-32) (bit 31) ... X^(N-1) (bit 0),
> data[1] = X^(N-64) (bit 31) ... X^(N-33) (bit 0)
>
> .. and so on. In your case you don't need the modulo mirroring step.

Thanks much, Ivan!  I'll need some time to digest that.  All I knew was that the
last three bits were screwy, and by chance discovered that undoing that last
step generted the correct result.

Thanks again,
Mike