Thanks David, I'm less confused now. I think part of my misunderstanding is this comment about the new nand_read_page_hwecc_oob_first function in nand_base.c:
* Hardware ECC for large page chips, require OOB to be read first. * For this ECC mode, the write_page method is re-used from ECC_HW. * These methods read/write ECC from the OOB area, unlike the * ECC_HW_SYNDROME support with multiple ECC steps, follows the * "infix ECC" scheme and reads/writes ECC from the data area, by * overwriting the NAND manufacturer bad block markings. I had a hard time parsing everything past "unlike". From what you have said I gather that ECC_HW_SYNDROME does the bad "infix ECC" and the new OOB_NAND_ECC_HW_OOB_FIRST method does not. I think different wording would help here. We will be using mainline linux and u-boot. The first version of the board will likely by 2K slc so looks like we are fine with 1-bit hw ecc. We may just plan on using OpenOCD to write UBL and U-Boot if the RBL in the silicon needs infix 4-bit ecc. We need to check once more how UBL is written on the 365 based dev boards we have right now. Of course TI could change to non-infix between now and when we start manufacturing so we just need to be ready for either. Thanks John On Wed, Sep 2, 2009 at 10:25 PM, David Brownell <davi...@pacbell.net> wrote: > On Wednesday 02 September 2009, John Rigby wrote: > > Sandeep and all interested parties: > > > > I am trying to understand davinci 4-bit nand options for u-boot and > > linux. > > In flux just now. The techinical issue is an ECC engine that's a > bit rough to work with except on small page chips. Summary of what > OpenOCD calls "hwecc4" ECC handling: > > - Small (512 byte) page support: been in Linux for a few releases > now, and in the current OpenOCD code. No U-Boot support at all > (small page being increasingly rare). > > - Large (2KB) page support: Linux patches are in the MM tree > finally; recently pulled into mainline U-Boot; handled by > the current OpenOCD code. > > - 4KB large page support (e.g. for MLC chips): nothing in > the queue for Linux or U-Boot, their NAND frameworks aren't > able to deal with that much ECC data. Basic OpenOCD support > in the current version. > > In short, the integration isn't quite complete yet; but everyone > is working to make it work with that mode. (I'm not sure the > state of the "UBL" code on DaVinci -- the second stage loader > invoked by the ROM boot loader, which sets up DRAM and then > load U-Boot.) > > > Whereas the current OpenOCD release supports that *and* a mode > it calls "hwecc4_infix", primarily to support interop with the ROM > boot loader on various chips (like current DM355): > > > I did some searching and found this comment in the davinci > > nand driver for openocd: > > > > /* > > * "Infix" OOB ... like Linux ECC_HW_SYNDROME. Avoided because it > trashes > > * manufacturer bad block markers, except on small page chips. Once you > > * write to a page using this scheme, you need specialized code to update > > * it (code which ignores now-invalid bad block markers). > > * > > * This is needed *only* to support older firmware. Older ROM Boot > Loaders > > * need it to read their second stage loader (UBL) into SRAM, but from > then > > * on the whole system can use the cleaner non-infix layouts. Systems > with > > * older second stage loaders (ABL/U-Boot, etc) or other system software > > * (MVL 4.x/5.x kernels, filesystems, etc) may need it more generally. > > */ > > > > This appears to be the ecc mode that Sandeep is trying to establish as > > the norm going forward. > > Don't think so ... > > > > It seems that David (author of the openocd > > code) would make a different choice. > > There was discussion on the DaVinci list a while back wherein > it was stated that TI's direction moving forward is to move away > from this "infix" OOB layout. This involves new ROM code on the > various chip supporting the 4-bit ECC hardware (DM355, DM365, > OMAP-L13X, more). > > That's why TI (Sneha mostly, but Sandeep most recently) defined > a new "OOBFIRST" HW_ECC mode in the Linux-MTD stack, and updated > the NAND framework to take an extra "page" parameter as input > to some lowlevel calls (needed to implement that HW_ECC mode). > > > > So what is the "right" thing to > > do? We are starting development of a new board and need to make a > > decision. What are the pros and cons of the two 4-bit alternatives? > > What kernel are you using? If it's from MontaVista (based on > 2.6.10 or 2.6.18) you'll likely want the "hwecc4_infix" mode. > > But all the mainline versions of U-Boot and Linux are aiming > at the non-infix code. > > > > Here is my two cents (maybe three cents) from my own experience: > > > > On the one hand, you can mitigate the trashed bad block marker problem > > by using an in flash bad block table that you create on first boot. > > Theoretically you never need the manufactuer markers after that. > > But in the Real World (tm) that's less certain. Speaking purely > as a developer, I assure you I've needed to regen the BBT tables. > Theory doesn't quite match reality. > > > > On the other hand, I know that Control4 (where I work now) had > > difficulty getting nand chips pre-programmed for an i.MX31 platform > > that had interleaved ecc like this. I believe the workaround involved > > post processing an image to "fool" the nand programmer that assumed a > > conventional oob layout. > > > > At Freescale I worked on a nand driver for the MPC5121 that had > > similar issues and it was disliked so much that the driver that > > finally made it into u-boot has software ecc only. > > Thankfully TI is helping make sure the 4-bit ECC hardware can be > used properly. :) > > However, *today* the most interoperable solution uses 1-bit ECC > hardware. And the 4-bit stuff isn't sorted out yet; the code is > queued though, which seems like overdue progress. > > - Dave > > > > Thanks for any input from all informed parties. > > > > John > > > > > > >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
