[PATCH v2] mtd: nand: support BENAND (Built-in ECC NAND)

[Gupta, Pekon]

> Ricard Wanderlof a écrit :
> > On Mon, 25 Feb 2013, Gupta, Pekon wrote:
> >
> >> But assuming there is no file-system OOB metadata | cleanmarker to be
> stored (like in UBIFS)
> >> Do we still need to transfer OOB data from Host processor to NAND
> device ?
> >> If yes, then ECC calculation & correction which at times is main bottle-neck
> in NAND accesses,
> >> may be best done at Host-processor side..
> >>
> >> Also, In-case there is some file-system metadata to be stored in
> OOB|spare area along with ECC,
> >> how do we ensure that layout of metadata does not overlap with ECC
> syndrome in BENAND ?
> >> Is the BENAND capable of re-adjusting its ECC layout ?
> >
> > BENAND uses a separate non-addressable area for its on-chip ECC. Thus,
> > the complete OOB area is available for the user (except bad block marker
> > bytes).
> There are 2 generations of BENAND :
> - old generation that use oob for its on-chip ECC
> - new generation that use a separate non-addressable area
> 
> I believe the patch is for the old generation because it create a special layout
> :
> 
> +
> +static struct nand_ecclayout benand_oob_128 = {
> +       .oobfree = {
> +               {.offset = 2, .length = 3},
> +               {.offset = 18, .length = 3},
> +               {.offset = 34, .length = 3},
> +               {.offset = 50, .length = 3},
> +               {.offset = 66, .length = 3},
> +               {.offset = 82, .length = 3},
> +               {.offset = 98, .length = 3},
> +               {.offset = 114, .length = 3},
> +       }
> +};
> 
> 
> >
> > IIUC, however, BENAND has a restriction on how data can written to the
> > flash. For instance, for a BENAND with 2k pages and 64 bytes OOB per page,
> > each 512 byte area is paired with 16 bytes of the OOB. When writing using
> > the on-chip ECC, one must write the 512 area of the main page followed by
> > the paired 16 bytes in the OOB area, without writing a new column address
> > to the flash. It is also possible just to write the main area, but then
> > the paired OOB bytes cannot be written at a later date, as that will cause
> > overwriting of the on-chip ECC, causing read errors during subsequent
> > read.
> >
Thanks much.. This was a nice information. 
This probably also means that on-die ECC would also cover the meta-data 
present in OOB area, that is why BENAND require 16bytes of OOB to be input 
along with 512bytes main-area data.

> > I don't know if it's possible to write the whole 2k page in one go,
> > followed immediately by the 64 byte OOB. I think not, but the
> > documentation is not clear on this point IMHO, and I have not tested it.
> >
> I think it is possible : on our test we didn't deactivate the soc nand
> controller ecc : it wrote 2K of data + OOB with its ecc. And it was working.
> 
However, above test shows that OOB area is not covered in on-die ECC calculation.
You can check if OOB area was also covered in on-die ECC calculation, 
by purposely introducing a bit-flip in OOB area.


> I believe it is what they wanted when using a separate non-addressable area.
> They wanted to provide new generation nand flash that require more ecc
> correction, but that is transparent for the host (very little software
> modification : check status bit in read).
> 
But having separate ECC checks:
- One by Host-Processor (stored in OOB),
- And another on-die ECC (stored in non-accessible area)
May not actually help in finding more number of bit-flips, because both 
algorithms may be just duplicating each. 
(example: Calculating BCH8 twice does not increase its capability to 
detect more number of errors, because both checks are on same main-data).

> 
> 
> >
> > The most efficient use of BENAND is probably to avoid using the OOB if
> > possible, and just use the main area. This does require that the driver be
> > configured accordingly which is a pity in a production environment where
> > one wants to have as wide a range of chips to choose from during the
> > production run.
> 
> Yes using OOB is asking for trouble with new nand.
>
In such case, is it correct to assume both JFFS2 and YAFFS2 (with out-of-band tags), 
cannot be used with Old-type BENAND, (which use oob-data for its on-die ECC) ?
because both JFFS2 and YAFFS2 save some metadata in OOB.


with regards, pekon 
> 
> Matthieu