All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Davinci DM365 custom design : Problem when reading uBoot environment variables
Date: Wed, 15 Sep 2010 13:15:14 -0500	[thread overview]
Message-ID: <20100915131514.7792c2ea@schlenkerla.am.freescale.net> (raw)
In-Reply-To: <1918F436C366B34BB245DD28389E039453ADFAAD1E@mars.easii.fr>

On Wed, 15 Sep 2010 18:21:11 +0200
Reda MIMOUNE <reda.mimoune@easii-ic.com> wrote:


> But when I reset the board, the message is *** Warning bad CRC or NAND. the zone was set to a NAND block size of 128KB (since it is mandatory to be the same size).
> I put some debug messages to find out that the read_env function used returns an error because of my environment variables block is bad. This i cannot understand since it wrote data in the right block.

If the block is bad, then that's not the right block. :-)

You can use CONFIG_ENV_RANGE to declare a multi-block range, larger than
the environment size, to allow bad blocks to be skipped.  Or you can
use the new env.oob feature to dynamically mark a known-good block as
your environment.

> To widen the problem I choose to double the environment size to 256KB. It is still the same.

You need to use CONFIG_ENV_RANGE and keep the environment the same size
-- otherwise it thinks you really want two blocks of environment data,
and one of those blocks being bad is still fatal.

> I typed the "nand bad " at prompt and my blocks + the bad block tables were marked as bad ! is that normal that BBT are marked bad ?

Yes, the BBT blocks are marked bad so they won't be used for other
purposes.

> So for the moment i try to remove this bad character from my block by trying to erase all the nand, and using nand scrub.

Please be careful with that.  Unless you have reason to believe that
the block was accidentally marked bad by something software did, you
ought to leave bad block markers in place.  The manufacturer put that
marker there to indicate that the block is unreliable (it's normal for
NAND flash to contain a few such blocks).

-Scott

  reply	other threads:[~2010-09-15 18:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15 16:21 [U-Boot] Davinci DM365 custom design : Problem when reading uBoot environment variables Reda MIMOUNE
2010-09-15 18:15 ` Scott Wood [this message]
2010-09-16  7:42   ` [U-Boot] RE : " Reda MIMOUNE
2010-09-16 16:55     ` [U-Boot] " Scott Wood
2010-09-17  7:35       ` [U-Boot] RE : " Reda MIMOUNE
2010-09-17 12:37         ` Wolfgang Denk
2010-09-17 12:48           ` [U-Boot] RE : " Reda MIMOUNE
2010-09-17 14:32             ` Wolfgang Denk
2010-09-17 14:49               ` Reda MIMOUNE
2010-09-17 15:02                 ` Wolfgang Denk
2010-09-17 18:01               ` [U-Boot] " Scott Wood
2010-09-21 14:47                 ` [U-Boot] RE : " Reda MIMOUNE

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=20100915131514.7792c2ea@schlenkerla.am.freescale.net \
    --to=scottwood@freescale.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 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.