From: David Brownell Sent: Tuesday, February 10, 2009 4:01 AM > > On Monday 09 February 2009, Narnakaje, Snehaprabha wrote: > > > > The syndrome based page read/write routines store ECC, and possibly > > > other "OOB" data, right after each chunk of ECC'd data. With ECC > > > chunk size of 512 bytes and a large page (2KB) NAND, the layout is: > > > > > > data-0 OOB-0 data-1 OOB-1 data-2 OOB-2 data-3 OOB-3 OOB-leftover > > > > Shouldn't this be data-0 data-1 data-2 data-3 OOB-0 OOB-1 OOB-2 OOB-3? > > Not for NAND_ECC_HW_SYNDROME; have a look at how nand_base.c > handles that. In particular, nand_write_oob_syndrome() and > its read-side sibling. If it were NAND_ECC_HW -- yes. > > A key difference between them seems to be that ECC_HW_SYNDROME > assumes that the ECC data (part of OOB-x) needs to be written > after each ecc.bytes of data is written ... its non-syndrome > cousin nand_write_page_hwecc() assumes that the ECC data can be > collected and then written at the end (in the spare area). > > Flipping that around: ECC_HW_SYNDROME presumes that the ECC > computations on *read* rely on engine state which needs to be > used after each ecc.bytes of data ... but ECC_HW presumes its > state can be saved and then used later. > > Can the DaVinci 4-bit ECC state be saved/restored? That is, > can the NAND4BITECCx registers be read after every 512 bytes > (so there are 40 bytes of saved ECC), then (in four chunks) > written, so the NAND4BITECCLOAD register can be used to fix > any errors "late" ... after several intervening data blocks > have been read, and ther ECCx state saved? Docs don't say; > but they strongly imply not. >
I don't think hardware supports saving the ECC state. The boot ROM code in DA830 device assumes the standard layout of data-0 data-1 oob-0 oob-1 while supporting 4-bit ECC. DM355 silicon errata identifies the current layout used by boot ROM as not recommended. I think this is planned to be fixed in future silicon revs. While I have not seen the OMAP-L1 ROM code, I think the standard layout is being achieved there by reading the complete OOB area before starting the read. Afterward, the read ECC bytes are being fed into the syndrome calculator along with each 512 byte data read. Similarly, on write, the ECC bytes can be cached locally before being written to spare area at once. I found this algorithm being used by DM355 flash utils here: http://sourceforge.net/project/showfiles.php?group_id=233754&package_id=283791&release_id=630108 (See Common/drivers/src/nand.c) Of course, the code in nand_base.c does not accommodate this. May be overriding the *_syndrome()functions for davinci is the only near term solution? Thanks, Sekhar > > > We used to have the "data-0 OOB-0 ..." layout in the Montavista based > > LSP releases. This layout can cause to place real data in the spare > > area and erase NAND manufacturer's meta-data -- bad block information. > > Right. Inherent in the NAND_ECC_HW_SYNDROME code in mainline too. > > I've checked around a bit, and it seems that the HW_SYNDROME mode > isn't much used (yet?) where ecc.steps is more than one. > > The $SUBJECT patch will be, I expect, only the first of several. > And that's not even considering the issue of whether the ecc.prepad > data (6 bytes OOB) is covered by the ECC ... there seems to be code > assuming that OOB data is not protected by ECC. (So it's writable > at any time.) > > > > The standard layout should be 2048 bytes data + 64 bytes OOB. 2048 bytes > > of data should still be read in 512 byte chunks. > > That's for the non-syndrome cases only; or maybe syndromes > that cover entire pages (2K, 4K, etc). > > (And I expect you're using 2K pages as I am, just as the most > common current example ... the code shouldn't disallow 4K.) > > > > Given that we have the boards with uboot and other Bootloader components > > loaded with the old legacy layout, we may still have to support both the > layouts. > > > > BTW, I am actually working on the support for standard layout! > > Good! I'd expect the current 1-bit ECC code would work just > fine for that; does it? And making the 4-bit mode fit into > that model will surely be a *lot* less hassle -- in terms of > patching NAND core code -- than using the HW_SYNDROME paths. > (More in terms of bootloader updates though.) > > On the other hand, I'd sort of hope that the first patch I > sent would work OK for small block flash. Though it might > shake out assumptions about the nonprotection of OOB data. > > You can think of patches #2 and #3 as a first pass at being > able to support the old layout. > > - Dave > > > > Thanks > > Sneha > > > > > > > > Where OOBx is (prepad, ECC, postpad). However, the current "raw" > > > routines use a traditional layout -- data OOB, disregarding the > > > prepad and postpad values -- so when they're used with that type of > > > ECC hardware, those calls mix up the data and OOB. Which means, > > > in particular, that bad block tables won't be found on startup, > > > with data corruption and related chaos ensuing. > > > > > > The current syndrome-based drivers in mainline all seem to use one > > > chunk per page; presumably they haven't noticed such bugs. > > > > > > Fix this, by adding read/write page_raw_syndrome() routines as > > > siblings of the existing non-raw routines; "raw" just means to > > > bypass the ECC computations, not change data and OOB layout. > > > > > > Signed-off-by: David Brownell <dbrown...@users.sourceforge.net> > > > --- > > > Observed when trying to get this working with the DaVinci NAND > > > driver in 4-bit ECC mode with a large page chip. > > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
