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