public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: John Rigby <jcrigby@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] More davinci 4-bit hw ecc questions
Date: Wed, 2 Sep 2009 21:02:09 -0600	[thread overview]
Message-ID: <4b73d43f0909022002p2da199eflab68d56fbfa19539@mail.gmail.com> (raw)

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

             reply	other threads:[~2009-09-03  3:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-03  3:02 John Rigby [this message]
2009-09-03  3:17 ` [U-Boot] More davinci 4-bit hw ecc questions John Rigby
2009-09-03  4:25 ` David Brownell
2009-09-03  4:56   ` John Rigby
2009-09-03  6:11     ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b73d43f0909022002p2da199eflab68d56fbfa19539@mail.gmail.com \
    --to=jcrigby@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox