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

[Tolunay Orkun]

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

> Redundant   environment   implements   something   like   an   atomic
> transaction.
>   
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.
>   

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

Best regards,
Tolunay