From: Peter Barada <peter.barada@logicpd.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Question regarding NAND environment
Date: Fri, 27 Jan 2012 17:08:01 -0500 [thread overview]
Message-ID: <4F232041.6080801@logicpd.com> (raw)
In-Reply-To: <4F231B1F.7010008@freescale.com>
On 01/27/2012 04:46 PM, Scott Wood wrote:
> On 01/26/2012 11:34 AM, Peter Barada wrote:
>> On 01/26/2012 12:27 PM, Scott Wood wrote:
>>> Why are two copies insufficient for that?
>> Two copies are sufficient, if none of the blocks ever go bad.
>>
>> To simplify things, suppose the environment is the same size as a block
>> and you have only two blocks (and two copies) to hold the environment.
>> If one block goes bad then there is a window between when the one
>> remaining block is erased and written with the environment that if power
>> fails then there is no environment in NAND.
> It seems unlikely, but possible I guess. Currently I don't think we
> dynamically mark blocks bad at all in U-Boot, except in things like ubi
> and yaffs.
I'm probalby being paranoid, but from what I've seen, if it can fail,
odds are it will.
I can add code to mark the blocks bad if the erase/write fails.
>> To solve this I can crank up the number of blocks to three which allows
>> one block to go bad and still at all times have one good copy of the
>> environment in NAND. But looking at writeenv(), it stops as soon as
>> either nand_write fails, or one copy of the environment is written. So
>> it could make sense to modify writeenv to write as many copies of the
>> environment that fit into CONFIG_ENV_RANGE, and have readenv read out
>> copies and verify them until it finds one good one.
> This isn't what CONFIG_ENV_RANGE is about. I think it would make more
> sense to change REDUND to support more than two copies (each with their
> own range).
Its somewhere in the middle. REDUND give you two copies. ENV_RANGE
gives you one copy but allows it to
live in the first good block. Modifying either way is going to affect
units in the field. But I'll give it a whirl.
> Probably better to never update the environment in the field -- source a
> script in an ubi partition instead.
Proper planning will save one from having to update the environment in
the field, but I'm sure it happens. I just figured I'd try to make sure
that nothing bad happens when people do...
--
Peter Barada
peter.barada at logicpd.com
next prev parent reply other threads:[~2012-01-27 22:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-26 17:05 [U-Boot] Question regarding NAND environment Peter Barada
2012-01-26 17:27 ` Scott Wood
2012-01-26 17:34 ` Peter Barada
2012-01-27 21:46 ` Scott Wood
2012-01-27 22:08 ` Peter Barada [this message]
2012-01-27 22:25 ` Tom Rini
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=4F232041.6080801@logicpd.com \
--to=peter.barada@logicpd.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.