From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Rigby Date: Wed, 2 Sep 2009 21:17:19 -0600 Subject: [U-Boot] More davinci 4-bit hw ecc questions In-Reply-To: <4b73d43f0909022002p2da199eflab68d56fbfa19539@mail.gmail.com> References: <4b73d43f0909022002p2da199eflab68d56fbfa19539@mail.gmail.com> Message-ID: <4b73d43f0909022017n21c94f5eg4b179727f68041a1@mail.gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de It just occured to me that I might have things backward. Is your new nand code trying to avoid the interleaved oob? If so, sorry for the confusion. On Wed, Sep 2, 2009 at 9:02 PM, John Rigby wrote: > Sandeep and all interested parties: > > I am trying to understand davinci 4-bit nand options for u-boot and > linux. 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. It seems that David (author of the openocd > code) would make a different choice. 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? > > 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. > > 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. > > Thanks for any input from all informed parties. > > John >