From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Redundant environment expected behavior vs current
Date: Thu, 27 Apr 2006 14:45:19 -0400 [thread overview]
Message-ID: <4451113F.4030405@smiths-aerospace.com> (raw)
In-Reply-To: <200604262226.44503.sr@denx.de>
Stefan Roese wrote:
> On Wednesday, 26. April 2006 09:53, Wolfgang Denk wrote:
>>> I will have to add the code associated with this option into
>>> common/env_flash.c. If CFG_ENV_REDUND_SYNC is not defined no new code is
>> You can keep this as local extensions / patches. I don't think I'm
>> going to add this, unless at least some other people speak up here on
>> the list and say that they need this, too.
>
> I have to admit, that I was also a little astonished how the redundant
> environment works when I first used it. I would have expected (as Tolunay
> did) the 2nd totally synced version.
>
> I do see the benefit that the current implementation only erases the flash
> sectors half as much as normal (not redundant) flash environment or totally
> synced redundant environment does. But is this really a problem? Then all not
> redundant flash environment U-Boot implementations would have a problem too.
>
> I also tend to forget such things like using "saveenv" twice, so I would vote
> to let Tolunay implement this new behavior (using CFG_ENV_REDUND_SYNC) that
> the user (or developer) can choose between both versions.
>
> And if Wolfgang agrees to accept this patch then please include a short
> description on both implementations in the README. That would be very
> helpful.
>
> Best regards,
> Stefan
My 2 cents:
-----------
1c: What u-boot currently has I would label a "back up" env, not a
"redundant" env. The analogy would be a back up tape's copy of your
hard drive vs. a RAID-1's redundant copy. Both copy mechanisms are
useful, but in different ways.
2c: I've been working with "full featured" and flash EEPROMs for 20
years and have not seen any lose their contents after being successfully
programmed (and properly programmed - losing power during a program
cycle is a Bad Thing[tm] DAMHIK :-/). OTOH, I am in development and may
have missed Manufacturing's warranty repair bulletins :-/.
gvb
next prev parent reply other threads:[~2006-04-27 18:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-25 19:46 [U-Boot-Users] Redundant environment expected behavior vs current Tolunay Orkun
2006-04-25 21:46 ` Wolfgang Denk
2006-04-25 23:33 ` Tolunay Orkun
2006-04-25 23:55 ` Wolfgang Denk
2006-04-26 0:59 ` Tolunay Orkun
2006-04-26 7:53 ` Wolfgang Denk
2006-04-26 12:32 ` Randy Smith
2006-04-26 13:05 ` Wolfgang Denk
2006-04-26 13:25 ` Randy Smith
2006-04-26 15:05 ` Wolfgang Denk
2006-04-26 15:29 ` Tolunay Orkun
2006-04-26 16:12 ` Wolfgang Denk
2006-04-26 20:26 ` Stefan Roese
2006-04-27 18:45 ` Jerry Van Baren [this message]
2006-04-26 10:05 ` Wolfgang Denk
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=4451113F.4030405@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox