On Tue, 2015-04-07 at 09:48 -0400, Bill Pringlemeir wrote: > On 3 Apr 2015, ste...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot