[U-Boot] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?

[Wolfgang Denk]

Dear Brian Hutchinson,

In message <3d1967ab1003180758p2006f562pc56cee3438eb2733 at mail.gmail.com> you wrote:
> (puts on flame retardant underwear) Can environment variables be
> pulled from Flash and EEPROM?

Not directly.

> Why would I want to do this?  I need to provide fail safe upgrade path
> and need to do something similar to the bootcount feature in PPC (I'm
> using ARM though).

Hm... And redundant environment is not safe enough for you?

> The goal is to not brick a device during a upgrade.  Whatever bank you
> are running out of, you upgrade by flashing the bank not being used.
> Once a bank has been upgraded, if I want to select that bank to boot
> ... I would need to modify a environment variable but if it is stored
> in flash then while that sector (a 256k sector in my case) is being
> updated ... if power is lost I just hosed myself.  If the environment
> variable I update was stored in EEPROM, then it would be closer to an
> atomic action that couldn't be interrupted with say a power failure.

EEPROM is not a bit more reliable than NOR, on contrary (read for
example doc/I2C_Edge_Conditions - unless you write-protect your EEPROm
in hardware it is actually way less reliable).

And redundant environment should cover your use case just fine.

> So what I'm asking about is a Hybrid environment were some variables
> are in flash and some are in EEPROM.  The env is read from both
> locations and saveenv writes some vars in flash and some in EEPROM.
> With the current u-boot code I have (1.1.6) the environment choices
> are mutually exclusive (flash, eeprom, nvram etc.)

This makes little sense to me.

If you really fell like it, you can of course store some script image
in EEPROM which you can then read and run (using "eeprom read" plus
"source" commands).

> Is this a sane approach or am I heading for heart ache?  This has to
> be something that others have dealt with but I didn't see any similar
> discussions in the archives.

Maybe because redundant environment is good enough for all practical
purposes?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Objects in mirror are closer than they appear.