On 7 Apr 2015, scottw...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
