[U-Boot-Users] Redundant environment expected behavior vs current
Tolunay Orkun
listmember at orkun.us
Tue Apr 25 21:46:05 CEST 2006
Hi,
I have an inquiry regarding how the U-Boot environment redundancy is
supposed to work.
For the new embedded board I have decided to implement redundant u-boot
environment to make it more resilient against corruption. I had not done
this before so I did not know how it was actually implemented.
I've found that redundant environment does not really create an exact
duplicate environment (as far as environment variables are concerned).
Instead, the active environment is rotated each save and only the new
active environment copy contains the changes to the environment.
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.
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?
Am I the only one that expect complete sync of both sectors? Should I
submit a patch?
Best regards,
Tolunay
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
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.
=> saveenv
Saving Environment to Flash...
. done
Un-Protected 1 sectors
. done
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... done
. done
Protected 1 sectors
. done
Protected 1 sectors
More information about the U-Boot
mailing list