[U-Boot] Read-only env variables

[Craig Millen]

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. 

We modified the fw_env to parse the serial EEPROM as well. 

So everything that is in the serial EEPROM is accessed by a mirrored set of commands like "protected_saveenv" and "protected_printenv" that are hidden from the user in the help. 

I integrated the "protected environment" into the regular environment by looking through the protected space first before allowing any "setenv" and when a "printenv" is done, it will print the protected variables last.

Unfortunately our u-boot is heavily modified in or to make it production worthy, so we've never been able to enter it into the repository.  I can however provide you will all the code necessary if you would like. 


-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Joe Hershberger
Sent: Monday, May 10, 2010 5:34 PM
To: Wolfgang Denk
Cc: u-boot
Subject: Re: [U-Boot] Read-only env variables

On Mon, May 10, 2010 at 3:43 PM, Wolfgang Denk <wd at denx.de> wrote:
>>        l - list delimited by ';' (special behavior for setenv)
>
> Don't do this. ';' has a clear meaning. Using it for other purposes

Fair enough... ',' then.

>> That seems pretty reasonable.  I think I'd like to see the access 
>> control codes more role based than limitation based.  Such as:
>>
>>      u - unique board configuration (mac addr, ser#)... set if not 
>> set, default override
>>      s - script in env var... read only, default
>>      r - runtime variable (ip addr)... set in env, not saveable to flash.
>
> This is most probably less flexible and more cumbersome to use.  It's 
> easier  to  define  what  exactly  you  want to do (don't allow over-
> writing) that finding a role that happens to include this  behaviour.
> Think  also  about  the  end  user  who wonders why variable "foo" is 
> considered to be a "unique board configuration" when all  you  wanted 
> is to apply certain behaviour.

The primary reason for wanting this sort of comes back to the reason I wanted bitmasks in the first place.  I want to be able to mix certain access control attributes for different variables.

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 all the board unique variables like they would if they just erased their env sectors.  I'd like to specify that a variable should be preserved on reverting to default env independent of being read-only or not.  Perhaps you would prefer to have each permutation defined as a sum of attributes instead of a role.  It's the same thing with a different name.

>> > What would be your use of such list vatiables?
>>
>> Specifically for manipulating the acl and any other list that a user 
>> may need.  Because it will self reference and define its type as a 
>> list,
>
> Why would that be needed?
>
> See my example above:
>
>        setenv acl delay:d,address:a,ipaddr:i,ethaddr:mo,serial#:sr

The idea was that if you wanted to remove "ethaddr:mo" from the list for instance, you could do so without dealing with the rest of the items in the list.  See below.

> [Implementation note: the implementation should allow for and ignore 
> repeated or trailing ',' separators - i.e. something like 
> "delay:d,,,address:a,ipaddr:i,ethaddr:mo,,serial#:sr,," should work as 
> well. Reason: see below about incremental building.]

I agree.  It will be tolerant of this.

> Well, we have the editenv command, which makes editing pretty easy.
> I fear/feal that adding lists is (1) not really needed and thus most 
> likely more overhead than benefit, and (2) holds a lot of potential 
> for causing confusion and conflicts.

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.

> We don't have lists vailables in bash either (or do we?)

Not that I'm aware of.  Arrays, yes, but that's not what I'm going for here.

>> > OK, the "remove entry" function is not that easy here, but which 
>> > usage do you have in mind that needs that?  I never ran into that before.
>>
>> Consider the case where a variable is defined as a runtime variable, 
>> but the user would like to change the value and commit that change to 
>> flash.  It would be much more usable if there were a simple way to 
>> remove an element from a list.
>
> 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 flash will be retained when saveenv is called.  Again, I'm considering 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 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.

> I feel we should try to make this not overly complicated - don't add 
> bells and whistles without real need. Also keep in mind that a lot of 
> power results from being able to dynamically build such settings from 
> smaller blocks.

I also don't want it to be complicated, but I'd like it to cover the use cases that I'm up against at the moment in a relatively user friendly way.  I feel like we are close to a solution.

> I can imagine scripts that run things like
>
>        setenv acl "$acl_net,$acl_hw_id,$acl_foo,$acl_bar"

That sounds great.  I also envision making part of the acl unchangeable and part of it changeable.  That would be done by making the the acl reference itself as read-only and also contain a dereference such as:
"acl=$acl_rw,acl:sr,ipaddr:i,ethaddr:mo,serial#:sr".  You could then change the value of acl_rw at runtime but not the value of acl.

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

Best regards,
-Joe
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot