[U-Boot] [PATCH 4/4] mtd: vf610_nfc: support subpage write

Scott Wood scottwood at freescale.com
Tue Apr 7 18:21:15 CEST 2015


On Tue, 2015-04-07 at 09:48 -0400, Bill Pringlemeir wrote:
> On  3 Apr 2015, stefan at agner.ch wrote:
> 
> > I will remove the page read on NAND_CMD_SEQIN, since we memcpy the
> > full page anyway. I also just realized that the page read actually
> > happens always and hence slows down even full page writes...
> 
> Yes, I remove this in Linux (4.0) and it corrupted things when writing.
> I think your previous conclusion about we never use 'write caching' was
> wrong.
> 
> This one is for writes,
> 
> 	case NAND_CMD_SEQIN: /* Pre-read for partial writes. */
> 
> This one is for reads,
> 
> 	case NAND_CMD_READ0:
> 
> The interface between 'nand_base' and the MTD driver is hard to
> decipher.  Does Scott (or anyone) know if there is any documentation on
> this?

It's an awkward interface for drivers that expose a higher-level
programming model.  Basically you have to behave as if nand_base could
send commands directly to the chip.

> Stefan is completely correct that if a full page is being written, then
> the 'SEQIN' should not read a page.  However, I only see 'column' being
> passed.  How is 'SEQIN' and 'PAGEPROG' to detect if a full page is being
> written or not?

At SEQIN time, you can't.  You'll know based on how much data is written
into the buffer.  Or, you can skip this low-level interface and replace
nand_write_page (which is what I wish we'd done in the eLBC/IFC
drivers).

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

-Scott




More information about the U-Boot mailing list