[U-Boot-Users] Redundant environment expected behavior vs current

[Tolunay Orkun <listmember@orkun.us>]

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