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

Wolfgang Denk wd at denx.de
Tue Apr 25 23:46:02 CEST 2006

In message <444E7C7D.2060106 at orkun.us> you wrote:
> 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.

Correct. That's how it is supposed to work.

> 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.

Redundant   environment   implements   something   like   an   atomic

> 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.

> Am I the only one that expect complete sync of both sectors? Should I 
> submit a patch?

No. Nothing is broken.

> 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.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I can have honesty, it's easier to overlook mistakes.
	-- Kirk, "Space Seed", stardate 3141.9

More information about the U-Boot mailing list