public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] Nand dump and nand bad block disagree
Date: Wed, 29 Feb 2012 17:54:36 -0500	[thread overview]
Message-ID: <201202291754.38168.vapier@gentoo.org> (raw)
In-Reply-To: <4F4EA8AC.6040602@freescale.com>

On Wednesday 29 February 2012 17:37:32 Scott Wood wrote:
> On 02/29/2012 04:34 PM, Mike Frysinger wrote:
> > On Wednesday 29 February 2012 14:09:44 Scott Wood wrote:
> >> On 02/29/2012 01:06 PM, Mike Frysinger wrote:
> >>> On Wednesday 29 February 2012 04:02:39 jean-philippe francois wrote:
> >>>> Le 29 f?vrier 2012 00:40, Scott Wood a ?crit :
> >>>>> Is this a 16-bit NAND?  If so, the first two bytes have to be 0xffff,
> >>>>> unless the controller driver defines the bad block pattern
> >>>>> differently.
> >>>> 
> >>>> It is an 8 bit nand. The badblock patern can be redefined by the
> >>>> controller driver to be different from the one in nand_base.c ? Do you
> >>>> have an example of this ?
> >>> 
> >>> look at the Blackfin nand driver (in u-boot and linux).  we have to
> >>> override the badblock layout because our on-chip boot rom expects
> >>> something other than what linux uses.
> >> 
> >> But be careful when doing this -- it really should match what
> >> manufacturers will write.
> > 
> > yep
> > 
> > on the Blackfin side, nothing to be done now.  the rom team didn't
> > consult with the linux team before implementing things, and these roms
> > are fixed in the processor, and they can't change now without breaking
> > backwards compat.
> 
> Do you migrate the bad block markers to the new location prior to using
> a chip?

we leave that as an "exercise for the user" ;)

this OOB layout is only used when the processor is booting directly from NAND, 
so the layout already has to be adjusted in order for it to boot at all.  if 
you aren't booting from NAND, we recommend to customers to stick with the 
standard OOB layout.  so there isn't really a point in time where we could add 
code to automatically migrate layouts.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120229/950cd5a4/attachment.pgp>

  reply	other threads:[~2012-02-29 22:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28 14:34 [U-Boot] Nand dump and nand bad block disagree jean-philippe francois
2012-02-28 23:40 ` Scott Wood
2012-02-29  9:02   ` jean-philippe francois
2012-02-29 19:06     ` Mike Frysinger
2012-02-29 19:09       ` Scott Wood
2012-02-29 22:34         ` Mike Frysinger
2012-02-29 22:37           ` Scott Wood
2012-02-29 22:54             ` Mike Frysinger [this message]
2012-02-29 23:14               ` Scott Wood
2012-02-29 19:11     ` Scott Wood

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=201202291754.38168.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --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