[U-Boot] Read-only env variables

[Wolfgang Denk]

Dear "Craig Millen",

In message <67BFAF42E016FC40ADE4EE73E07B706004668DD0 at pks00005.kanatek.com> you wrote:
> I ran into the same situation, where I needed set of environment
> variables for in house testing, and a different set for when products
> actually go out to customers. So we were erasing the flash quite often,
> but in this scenario, things like serial number and mac address stay
> with the board regardless if we replace all of the memory on the board. 
> I wrote a mirror image of the environment variable handling routines,
> but used a small serial EEPROM that could hold a 100 bytes. 

There are other boards doing similar things - see for example
board/tqc/tqm8xx/load_sernum_ethaddr.c which can pre-load the MAC
address and serial number on all TQM8xxL/TQM8xxM/TQM82xx boards from a
dedicated area in flash.

> I've added a command called "defaultenv" which comes in really handy in
> practice here.  Basically what it does is revert everything in memory to
> a default env except for certain (currently hard coded) variables such
> as ethaddr and serial#.  This means that if I rebuild and change a
> script or boot command, my people can simply load the new u-boot and run
> "defaultenv;saveenv" to get the updated scripts but not have to redefine

There has been discussion about such a feature in the past. I even
tried to define the user interface for such a command set, but
unfortunately I didn't have enough time myself and nobody else took
the bait either.

> I haven't used the editenv command, so I'll play with that a bit.  It
> sounds like it will make my concern about removal less of an issue.
> I'll try it and see how usability feels.

Yes, it will make it less an issue - as far as interactive use is
concerned. But then I still see why you want such a feature fr example
for use in scripts.

We agree that the feature is useful, but I am not convinced that the
list approach makes sense. Eventually I'd rather have a scriptable
edit command. IIRC there was a vi clone in one of the IOCCC
submissions with < 1.5k code... :-)

> > What to you mean by "runtime variable" or by "change to flash"? I 
> > don;t understand what these terms are supposed to mean.  As
> mentioned 
> > before, "editenv" seems a pretty straightforward way to edit the 
> > settings.
> 
> What I'm referring to here is being able to specify a variable as r/w
> while running in u-boot, but that that value will not be written to
> flash.  If the value was defined in flash, then the existing value in

Ah. But you have this already, when using the hush shell. It has shell
variables (which work exactly like your r/w variables), and you have
environment variables.

All you eventually need is a script / macro to initialize the shell
variables after boot.

> the case with "ipaddr" and family.  If the user wishes to change the
> static IP, then that change should be written to flash.  If the user
> wishes to use dhcp to configure all the network settings, those settings
> should not be saved to flash (and then used as though they were static

Be careful. You are defining policy here, and actually you can do all
this already now.

Use "setenv ipaddr ...; saveenv" if the user wishes to change the
static IP and write it to flash.

Use "dhcp" (without "saveenv") to use dhcp to configure all the
network settings without saving this to flash.

What else do you need?

> settings).  Currently if you use dhcp and then want to save some other
> change in the env, you save all the dhcp settings and the next time the
> board is powered, you use an address that you have no lease for and
> probably conflict with another machine.

Well, then just do the saveenv _before_ you use DHCP. Or be careful
to delete / reset the respective variables.

I agree, your vision is to make this easier, but in this specific case
I doubt the benefits justify the additional overhead.


> One thing I've noticed that I don't quite understand is how you can add
> a '$' to a variable's value from the command line.  If I escape it with
> a '\', the '\' sticks around in the value of the variable, but if I
> don't escape it, then the '$' dereferences in the setenv.  Seems like a
> bug to me.  The '\' should not end up in the value of the var when used
> in setenv to escape the '$'.

I can't parse that. Do you have an example?

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
The only way to get rid of a temptation is to yield to it.
                                                        - Oscar Wilde