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

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

On Fri, Nov 04, 2011 at 02:20:26PM +0000, Mike Dunn wrote:
> On 11/03/2011 02:14 AM, Matthieu CASTET wrote:
> > Hi,
> >
> > Ivan Djelic a écrit :
> >>
> >> 1. When you program a page, before writing hwecc to oob, adjust it like this:
> >>
> >>    hwecc[i] ^= blank_read_hwecc[i]^0xff;
> >>
> >> The effect of this is that you now get 0xffs as ecc for blank pages, and bitflip
> >> correction on erased pages for free. This is transparent to your controller,
> >> because this "adjustment" cancels itself upon reading when calc_ecc^recv_ecc is
> >> computed.
> 
> 
> Not entirely transparent.  I didn't think this through.  Modifying the
> hw-generated ecc bytes causes the hw to think that there were error(s) on every
> page.  True, the driver will know better, but it will slow things down because
> ordinarily the ecc unit only has to be read when the hardware reports errors. 
> With this scheme, an error is reported and the ecc bytes read and processed on
> every page.

So you did check this with a real-life test ?
My assumption was that the HW relied entirely on recv_ecc^calc_ecc to decide that
an error had occured. This recv_ecc^calc_ecc polynomial is the _same_ whether you
apply the suggested XOR masking or not (that's the trick).

If your HW reports an error on every page when you apply the XOR masking, it
means it does itself some sort of check (which has probably nothing to do with BCH
decoding) on oob ecc bytes; this would be consistent with the HW flag Robert
mentioned (the one that seems to indicate that a page has been programmed).

BR,
--
Ivan