From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tolunay Orkun Date: Tue, 25 Apr 2006 14:46:05 -0500 Subject: [U-Boot-Users] Redundant environment expected behavior vs current Message-ID: <444E7C7D.2060106@orkun.us> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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