[U-Boot-Users] Redundant environment expected behavior vs current
wd at denx.de
Wed Apr 26 01:55:26 CEST 2006
In message <444EB1D5.1000804 at orkun.us> you wrote:
> I agree but once you have written the one copy of the environment and
> protect it (if you have hardware support), one copy is already securely
> written you can go ahead and write the second environment. We changed
You just said that the data is securely written and protected.
> the environment because the old one was not right so keeping the old
> environment after one copy is written might not save us in certain
> I know it only writes over the flag byte in old environment by writing
> 00 (can always transform from 1s to 0 in nor flash without erasing). I
> guess you are referring to this as atomic transaction.
No. I mean, that "saveenv" has a transaction character: either it
will succeed, and you end up with the new environment, or it will
fail, and you will end up with the previous one.
Writing the new environment twice just adds flash wear.
So far, I haven't seen a situation where it would have been useful.
> > If you want this behaviour, then just use it. All you need to do is
> > typing "saveenv;saveenv". Next question, please.
> It depends on a user doing this which might not be true. Heck, I even
Provide a simple update command in a variable. I really don't think
this is generally useful. It just wasts flash life time.
> forget to do this sort of stuff after some time. It would be great if
> the sync is provided as an option. How about CFG_ENV_REDUND_SYNC (or
> something like this) that runs the save command twice internally or
> something like that to that effect?
Feel free to add this as a local extension. I don;t think I would
ever enable this on any of my boards.
Other opinions? Is there anybody who thinks this would improve the
robustness of his devices?
> The current scheme also does not sync environment from the good one if
> one environment detected bad during boot. Should U-Boot fix the bad one
> from the good one automatically? Currently, I think there is not even a
U-Boot never does any automatic writing to flash. This is something I
> diagnostic message that one environment is bad.
No, should there be one? Obviously a "saveenv" command did not
complete succesfully; maybe just one millisecond eralier it would not
have been started at all.
That's what I mean by "transaction": if it does not complete
succesfully, then it did not take place at all. This is not
considered a failure mode.
> How about U-Boot commands to verify environment so we can use it to do
> the sync etc. in a script.
They are all in place. (crc, test). Just use them as needed. But
frankly: did you ever see any corruption of NOR flash except when
erasing / writing? And if you did, are you only concerned about the
contents of the environment variables?
> > The CFI driver is a bit noisy, indeed.
> Should I add "Protecting..." "Un-protecting..." before operations to
> compensate for flash driver output...
Ummm... no! I said it already is too noisy, so adding more output
cannot be an improvement.
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In English, every word can be verbed. Would that it were so in our
More information about the U-Boot