[U-Boot] Read-only env variables

[Joe Hershberger]

On Tue, May 11, 2010 at 5:03 PM, Wolfgang Denk <wd at denx.de> wrote:
> 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.

I don't have a separate memory to use for this purpose, but it seems
like a good approach if you do.

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

Ok... if you can dig up the user interface you were thinking of, I can
compare it to what I've done and possibly tweak it.  As it is now, I
intend to use the acl to define which variables are preserved.  The
command takes no arguments and changes only the in-RAM environment.

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

Both in scripts and when called directly from other commands.

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

:)  I was going for simple(r).

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

I'll have to look into this.  I've noticed their existence, but
haven't used them so far.  I can see how that would help for
intermediate state storage (as long as they stay around through every
context such as from preboot to bootcmd), but not for variables that
need to be accessible to u-boot (such as network settings).

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

I want the acl to be the one defining this policy.

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

Works great in a vacuum.

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

In the case of dhcp, the key is that I want to be able to save some
unrelated change to the environment... I shouldn't be prevented from
doing it because I happened to configure the network already.

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

Not possible for the use case... I'm using netconsole, so dhcp must be
first to make the console accessible... so no change made to the env
could ever be saved.

> to delete / reset the respective variables.

That's tedious.  I think it should be better.  Making it better is
part of the reason for doing this.

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

All of this stems from the fact that a number of env vars are magical.
 Things like "ipaddr" and "stdin" etc. are hooked up to internals of
u-boot.  In the case of stdin and family, the behavior (without
CONFIG_SYS_CONSOLE_IS_IN_ENV) is that those variables only affect the
run-time behavior and are not written to flash.  I'm certain that the
reason for that is the same as the issue I'm having with the network
configuration.  I think there should be a simple-to-use way to
indicate that a magical env var should be only magical and not in
flash or possibly initialized from flash but not saved.  Since I'm
making an ACL, it seemed reasonable to implement that behavior
generically.  The list behavior idea was an attempt at making the acl
easier to change, since it would need to be changed (by users,
scripts, and u-boot code) for several different use cases.

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

Run this command:

setenv a "\$x";printenv a;setenv b "$x";printenv b

Neither one ends up containing "$x".  I believe that the first one should.

Best regards,
-Joe