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

[Wolfgang Denk]

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

You just said that the data is securely written and protected.

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

Which are?

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

No. I mean, that "saveenv" has a  transaction  character:  either  it
will  succeed,  and  you  end up with the new environment, or it will
fail, and you will end up with the previous one.

Writing the new environment twice just adds flash wear.

So far, I haven't seen a situation where it would have been useful.

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

Provide a simple update command in a variable. I really  don't  think
this is generally useful. It just wasts flash life time.

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

Feel free to add this as a local extension. I  don;t  think  I  would
ever enable this on any of my boards.

Other opinions? Is there anybody who thinks this  would  improve  the
robustness of his devices?


> 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 

U-Boot never does any automatic writing to flash. This is something I
consider evil.

> diagnostic message that one environment is bad.

No, should there be  one?  Obviously  a  "saveenv"  command  did  not
complete succesfully; maybe just one millisecond eralier it would not
have been started at all.

That's what  I  mean  by  "transaction":  if  it  does  not  complete
succesfully,  then  it  did  not  take  place  at  all.  This  is not
considered a failure mode.

> How about U-Boot commands to verify environment so we can use it to do 
> the sync etc. in a script.

They are all in place. (crc, test). Just  use  them  as  needed.  But
frankly:  did  you  ever  see any corruption of NOR flash except when
erasing / writing? And if you did, are you only concerned  about  the
contents of the environment variables?

> > The CFI driver is a bit noisy, indeed.
> 
> Should I add "Protecting..." "Un-protecting..." before operations to 
> compensate for flash driver output...

Ummm... no! I said it already is too noisy,  so  adding  more  output
cannot be an improvement.

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
In English, every word can be verbed.  Would that it were  so  in our
programming languages.