On Wednesday 02 September 2009, John Rigby wrote: > 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.
Yes; not the clearest English. > 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. That ought to work for you. I've go an OpenOCD pach in the works to speed that up a bunch too. > 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. ISTR docs on '365 don't cover the OOB layout as used by the RBL well ... a third layout seems to be implied. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
