From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Wed, 2 Sep 2009 23:11:50 -0700 Subject: [U-Boot] More davinci 4-bit hw ecc questions In-Reply-To: <4b73d43f0909022156m74a3e122m536f3aee159c107c@mail.gmail.com> References: <4b73d43f0909022002p2da199eflab68d56fbfa19539@mail.gmail.com> <200909022125.18874.david-b@pacbell.net> <4b73d43f0909022156m74a3e122m536f3aee159c107c@mail.gmail.com> Message-ID: <200909022311.50941.david-b@pacbell.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.