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

[Matthieu CASTET]

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.
> 
> 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.

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).



> 
> 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.


Matthieu