All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reda MIMOUNE <reda.mimoune@easii-ic.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] RE : Davinci DM365 custom design : Problem when reading uBoot environment variables
Date: Thu, 16 Sep 2010 09:42:07 +0200	[thread overview]
Message-ID: <1918F436C366B34BB245DD28389E039453ADFAAD1F@mars.easii.fr> (raw)
In-Reply-To: <20100915131514.7792c2ea@schlenkerla.am.freescale.net>

Hi Scott.
Thank you for your answer.

>You can use CONFIG_ENV_RANGE to declare a multi-block range, larger than
>the environment size, to allow bad blocks to be skipped.

>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.

Thank your for the info. I will put this flag in my board definition file. I is exactly the case.
The block I choose to be the environment block became bad so i increased the size to 2 blocks
and the second block became bad.
So in my both cases, what you said explains that the case I met. I will put this flag and check if it
is present in my 1.3.4 version.

>Or you can use the new env.oob feature to dynamically mark a known-good block as
>your environment.

I do not know this feature. To which config flag does it relate ?

>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. 

That's what I believed since they became bad only after uboot wrote to them...

>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).

For this i am ok with you.

Another question or confirmation: when using environment in NAND, must the environment size be the same than the
NAND block size, i.e 128KB in my case (which i think is too huge) ?

Thank you for answering

Reda

  reply	other threads:[~2010-09-16  7:42 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
2010-09-16  7:42   ` Reda MIMOUNE [this message]
2010-09-16 16:55     ` 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=1918F436C366B34BB245DD28389E039453ADFAAD1F@mars.easii.fr \
    --to=reda.mimoune@easii-ic.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.