[U-Boot-Users] Redundant environment expected behavior vs current
listmember at orkun.us
Wed Apr 26 01:33:41 CEST 2006
Wolfgang Denk wrote:
>> So, at this stage if your active environment is lost/corrupted your
>> latest changes to the environment is lost as well which might be
>> important to boot your system. The idea behind redundancy (IMHO) is such
>> that if one environment is lost the backup can provide all that was in
>> active but in current implementation it is not be possible simply using
>> one saveenv command. To get truly redundant environment that is exactly
>> duplicate, you are supposed to save the environment twice.
> Corruption happens usually only because you have a power loss or
> reset or crash when writing the new environment. In this case you
> keep the old, known to be working state.
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
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
> Redundant environment implements something like an atomic
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.
>> I personally think this is not quite how redundant environment should be
>> implemented. I think once the update of one environment is completed,
>> second environment should be updated with the same. What do you think?
> 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
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?
I guess same thing is applicable when using fw_setenv from linux.
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
diagnostic message that one environment is bad.
How about U-Boot commands to verify environment so we can use it to do
the sync etc. in a script.
>> Other cosmetic issues noticed:
>> 1) Defining CFG_ENV_ADDR_REDUND or CFG_ENV_OFFSET_REDUND results in
>> definition of CFG_REDUNDAND_ENVIRONMENT. I might be nitpicking but the
>> correct spelling should have been CFG_REDUNDANT_ENVIRONMENT
> Typo. Submit a patch.
>> 2) The output of saveenv intermixed with output from flash driver is
>> looking rather untidy and confusing. For example, ". done" below is
>> coming from "driver/cfi_flash.c". We get ". done" right after "Saving
>> Environment to Flash..." message and other messages follow. However, the
>> first ". done" was really for unprotect which is reported after. I think
>> like U-Boot does for Erasing part, we should announce the operation
>> first (i.e. Un-protecting ... Protecting...) so flash driver output can
>> match the current operation properly.
> The CFI driver is a bit noisy, indeed.
Should I add "Protecting..." "Un-protecting..." before operations to
compensate for flash driver output...
More information about the U-Boot