[U-Boot] [PATCH 1/2] mtd: vf610_nfc: mark page as dirty on block erase

[Bill Pringlemeir]

On  7 Apr 2015, scottwood at freescale.com wrote:
> On Tue, 2015-04-07 at 10:06 -0400, Bill Pringlemeir wrote:

>> In any case the document has,

>> If the NAND flash supports sub-pages, then what can be done is ECC
>> codes can be calculated on per-sub-page basis, instead of per-NAND
>> page basis. In this case it becomes possible to read and write
>> sub-pages independently.

>> Probably if we want sub-pages with this controller and hw-ecc, we
>> need to use the virtual buffer features of the chip.  The controller
>> needs an entire current buffer in the SRAM to calculate the hw-ecc to
>> write.  So even if it writes less than a full page, the entire page
>> must be read to calculate the hw-ecc to be written.

> That limitation sounds similar to the Freescale NAND controllers that
> I'm familiar with (eLBC and IFC).  For eLBC we do subpages by just
> writing 0xff, because on that controller the ECC of all 0xff is all
> 0xff so it doesn't disturb anything.  IFC has different ECC algorithms
> where that isn't the case, so we disabled subpage write on IFC.

> What is the virtual buffer feature?

>> I am pretty sure that all controllers that support hw-ecc will need
>> to do this.

> Not if they can handle doing ECC on a single subpage.

[from another thread, but the same subject].

>> The other way to handle things would to be to investigate the
>> NFC_CFG[PAGE_CNT] and NFC_SECSZ to have the virtual pages support
>> sub-pages.  I think the OOB mapping would be non-standard in such
>> cases.

> Wouldn't that mess up factory bad block markers?

All the stuff above is related (afaik).

  > What is the virtual buffer feature?

It splits programming of a flash page into separate buffers.  The
BCH-HW-ECC is then applied separately to each 'virtual-page' with
reduced strength.  Section "31.4.6 Organization of the Data in the NAND
Flash" of the Vybrid Software RM has details.

 > Wouldn't that mess up factory bad block markers?

I am unsure; certainly they can be read but they might be a data portion
of the fourth sub-page depending on the ECC strength selected.  There is
also a 'NFC_SWAP' register to switch the position of one 16bit index
(move OOB-BBT 16bit from data to OOB).  I think this can be used.  By
non-standard, I meant not fitting the current drivers idea of OOB
layout.

However, it seems like your comment that the ECC must be different
per-subpage (and what Artem said in the sub-pages documentation) makes
'virtual buffers' the most promising path for this driver and sub-page
support with hw-ecc.  As the bit strength is reduced, the amount of
corrections/error detection also seems reduced.  I think the math would
make this the same for everyone?

Your question about factory BBT is a good point.  Using the 'virtual
buffers' feature will complicate the driver code by quite a bit at least
from what I could think of and what I see in the MTD tree where I
believe similar features are used.

Fwiw,
Bill Pringlemeir.