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

[Ivan Djelic <ivan.djelic@parrot.com>]

On Thu, Oct 13, 2011 at 07:58:53AM +0100, Robert Jarzmik wrote:
> Hi Ivan,
> 
> For the lonely parity byte, I can confirm it's a Hamming parity over 7
> bytes. This parity byte is generated by the hardware as well when the page is
> written :
>  - 512 bytes of data are written into the page
>  - then 7 bytes of OOB are written
>  - then the "Hamming HW register is read" => we get the ECC back
>    => this is the generation you're talking about
>  - then 1 byte of OOB is written => we write the Hamming ECC
>  - then 7 bytes of BCH ECC registers are read
>  - then 7 bytes of BCH ECC are written
>  - then 1 byte (dummy byte) is written

OK, thanks. I had missed a few comments in Mike's code about this.

I'm still a little puzzled as to how this Hamming code works.
If it was meant to correct 1 bitflip in 7 bytes + 1 parity byte, then it
should be at least 12 bits long.
If the idea is to simply detect a single bitflip, then 6 bits are enough.
Maybe the probability of having 2 bitflips in 7 oob bytes is low enough to
allow reading oob using this simple check ?
 
> The exciting part is that with Mike and your work, I know what the unexplained
> '7' now means, and that I can add the ECC checks to docg3 :)

Nice :)
And kudos to you and Mike for the reverse-engineering...

--
Ivan