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

[Mike Dunn <mikedunn@newsguy.com>]

On 10/12/2011 11:49 AM, Ivan Djelic wrote:
>
> Well, thanks to your ecc samples I have the answer now; the hardware does
> provide recv_ecc^calc_ecc, with a little twist: a parity code in inserted into
> data before performing BCH remainder computations.

Yup, you nailed it!

> I don't really know how the parity byte in step 3 is generated, or what its
> purpose is; it may be there to allow oob reading without performing a full BCH
> decode, but the code seems too small to me to protect anything in a useful way.
> The nice thing is, we don't really need this code to perform BCH decoding.

Yes, it's a hw-generated hamming code, and it's supposed to cover the 7 oob
bytes preceding it.  Yes, for reading oob only.  One of my TODOs is to check the
hamming code when reading oob only.  So I did know about that and was including
it in my tests.  What escaped me is the fact that all the page data needed to be
bit-reversed in order to get the same ecc from your code as was written in oob. 
And prior to that, the fact that the hw generates calc_ecc ^ recvd_ecc, until
you pointed that out.

> Could you try this in your driver and tell me if it matches your errorpos[]
> results ?

Done.  I left the original code in the driver when I added the new code, and
added some additional lines to verify identical results.  All's well.

Thanks again for all the help.  Nice to know what's going on, and not duplicate
your bch code needlessly.  Thanks also for the pointers to the table-based bit
reversal alg.

Mike