From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] NAND and bad blocks
Date: Wed, 19 Sep 2007 07:49:14 +0200 [thread overview]
Message-ID: <200709190749.15569.sr@denx.de> (raw)
In-Reply-To: <DC8113368EDCB444B74B22F57D9D807E6E33AA@CLEOHSMB05.napa.ad.etn.com>
Hi Matthew,
On Tuesday 18 September 2007, MatthewLCreech at eaton.com wrote:
> 1. How does U-Boot handle a bad block in the area where the environment
> is stored? I can create a second environment via CFG_ENV_OFFSET_REDUND,
> but that's not very flexible (what if the primary and the backup are
> both bad blocks?) I also need to write to the environment from within
> Linux via the "fw_setenv" utility, but it doesn't seem to have any NAND
> awareness.
You could be right here. The bad block handling in the NAND environment is not
perfect. If both blocks of the environment are bad (primary & redundant) then
we really have a problem.
There was a patch sent to the list a few months ago (IIRC, from the Openmoko
project), that addressed this problem. Unfortunately I didn't find the time
till now to take a deeper look at it.
> 2. It's not obvious to me how U-Boot reacts when it encounters a bad
> block. If I'm copying a kernel image out of NAND, and a bad block is
> encountered, does it skip to the next block?
There are both option:
a) Bad blocks are not skipped and writted as 0xff in memory
b) Bad blocks are skipped upon read from NAND
I personally never used a) and always use b).
> If so, do I need to
> compensate by padding each partition with unused blocks, or how else
> does addressing work?
Yes, you have to add some reserve to your partitions size for bad blocks that
could occur.
> Similarly for writes - if I do "nand write
> <memaddr> <location> 100000", and the first block is bad, will U-Boot
> write all 0x100000 bytes _after_ that block?
Yes.
> 3. Can Linux handle bad blocks in the same manner? Specifically, I need
> to use 'nandwrite' to copy a kernel image to an MTD partition from
> within Linux, and have U-Boot read the image correctly on bootup, both
> in the presence of bad blocks and bit-flips.
Sure, this works the same way.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
prev parent reply other threads:[~2007-09-19 5:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-18 16:55 [U-Boot-Users] NAND and bad blocks MatthewLCreech at eaton.com
2007-09-18 19:21 ` Wolfgang Denk
2007-09-18 19:51 ` MatthewLCreech at eaton.com
2007-09-19 5:49 ` Stefan Roese [this message]
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=200709190749.15569.sr@denx.de \
--to=sr@denx.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.