[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