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

[Scott Wood <scottwood@freescale.com>]

On Tue, 2015-04-07 at 13:54 -0400, Bill Pringlemeir wrote:
> 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.

That would be bad.  Even if you somehow get the MTD code to read markers
in the main area on first use, you wouldn't be able to reconstruct the
BBT after you start writing data.  If you must do this, I suggest
migrating the bad block markers to the new OOB before usage (see
http://patchwork.ozlabs.org/patch/168855/ for an example).

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

Flash chips usually specify the required ECC on a subpage basis.

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

Which gets back to the question of whether subpages are worth it with
this controller.  Or, if subpage writes are infrequent enough, stick
with the read/modify/write approach but delay the read until you know
that it's going to be a subpage write.

-Scott