Hi Allred, We are using a custom board having DM355 and NAND - MT29F16G08DAA - page size = 4096.
We are booting the board from SD. SD card is carrying binaries for: a. UBL_SD - RBL will fetch from SD Card and load UBOOT_SD in SD BOOT Mode b. UBOOT _SD - UBL_SD will load in SD BOOT Mode, will support burning UBL_NAND and UBOOT_NAND in NAND c. UBL_NAND - in NAND Mode, will load from NAND by RBL d. UBOOT_NAND - in NAND Mode, will load from NAND by UBL_NAND 3. We are burning UBL_NAND, UBOOT_NAND in NAND from UBOOT_SD's command prompt: Case-1 (Using JTAG programmer and NAND_programmer.pjt): NAND_Programmer.pjt is modified to support NAND with 4K page size. Due to modification, NAND_programmer.pjt detects NAND with page size of 4K but treats it same way as if NAND is having Page size equal to 2K. Result: we are able to burn UBL_NAND and UBOOT_NAND. In NAND boot mode, UBL_NAND and UBOOT_NAND works as expected. Case-2 (Using SD boot and UBL_SD/UBOOT_SD): UBOOT_SD is having support of writing UBL_NAND and UBOOT_NAND from SD to NAND. We have ported NAND driver part of NAND_programmer.pjt to burn UBL_NAND and UBOOT_NAND. Result: we are unable to burn UBL_NAND and UBOOT_NAND. Using ported NAND driver of NAND_programmer.pjt, after writing we are failing while reading back data. ECC_STATE of NAND FSR register is found 1 for entire NAND which means errors cannot be corrected. Using JTAG programmer we read ARM internal memory (0x7ffc-0x8000), but it does not show expected address. We are writing in the same manner as described in your last mail. But we are not able to boot the board. Hope above clarifies the issue. Any help/suggestion is appreciated. Regards, Jitendra -----Original Message----- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Allred, Daniel Sent: Wednesday, February 11, 2009 10:57 PM To: Nori, Sekhar; David Brownell; Narnakaje, Snehaprabha Cc: DaVinci Subject: RE: [patch davinci-git 2/3] NAND: Fix "raw" reads with ECC syndromelayouts I'm not sure I followed all the discussion here, but I can speak to what we are doing with the layouts, at least from the perspective of the ROM boot loader (though I think the intention was to use the same format from ROM through up to the linux MTD). Revision to DM355, current OMAP-L1x7, and upcoming OMAP-L1x8, upcoming DM365, will all use same layout. All data will be stored in data portion of page (2K page device will have four 512-byte "chunks", 4K page device will have eight 512-byte chunks, etc.). All ECC info (syndrome data) will be stored in the OOB/spare region. The 4-bit ECC HW requires 10 bytes of ECC data for every 512-byte data chunk so the spare layout will consist of N (4 for 2K-page device, 8 for 4K-page device, etc.) 16 byte regions, one region for each 512-byte data chunk in the main data page. The first six bytes of this region are open/free. The last 10 bytes of this region are the bytes ECC data that correspond to the data chunk. When reading, all of the spare bytes data must first be read from the spare region and into local memory. The ECC info in these spare bytes will (must) be used, as appropriate, after the read of each 512-byte data chunk. When writing, all the ECC data must be read from the HW and stored locally after each 512 byte chunk read. Then that ECC data will be formatted as specified above and written to the OOB/spare region altogether after all data pages have been written. Does that clarify anything here? Daniel J. Allred High Performance DSP/SoC Catalog DSP / Emerging End Equipment -----Original Message----- From: Nori, Sekhar Sent: Wednesday, February 11, 2009 10:35 AM To: David Brownell; Narnakaje, Snehaprabha Cc: DaVinci; Allred, Daniel Subject: RE: [patch davinci-git 2/3] NAND: Fix "raw" reads with ECC syndrome layouts 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 _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
