[U-Boot] [RFC PATCH 1/2] sunxi: retrieve FEL-provided values to environment variables

[Bernhard Nortmann]

Hi Ian, hello Hans!

That's an interesting find, Ian - thank you.

Unfortunately it seems that flagging our environment vars accordingly
isn't enough (on its own) to prevent them from being written by
"saveenv". I've been testing

#define CONFIG_ENV_FLAGS_LIST_STATIC "fel_booted:bo,fel_scriptaddr:xo"

which achieves the desired flags, but doesn't alter saveenv behaviour.
Setting them to read-only ("r" access flag) doesn't help, as it won't
allow the setenv_*() calls to alter the vars in the first place.

As you have observed, this is a more general U-Boot problem - other
'volatile' information might end up in the environment (and saveenv)
as well, e.g. "ipaddr" and "serverip" retrieved by DHCP.

Regards, B. Nortmann


Am 12.09.2015 um 14:24 schrieb Hans de Goede:
> Hi,
>
> On 12-09-15 13:58, Ian Campbell wrote:
>> On Thu, 2015-09-10 at 20:34 +0200, Hans de Goede wrote:
>>> [...]
>>>
>>> What if the user interrupts auto-boot with a fel provided boot.scr
>>> and then does "saveenv" ?
>>
>> This is an interesting question which is more generic than just these
>> variable, i.e. it applies to some extent to "ipaddr" when someone does
>> "dhcp ; saveenv" too.
>>
>> Grepping around to see if there was any special handling for ipaddr I
>> came across "Vendor Parameter Protection" in the top-level README as
>> well as "CONFIG_ENV_FLAGS_LIST_DEFAULT" (and _STATIC) and various
>> default settings in include/env_flags.h.
>>
>> I think CONFIG_ENV_FLAGS_LIST_* are what we want, and we want fel* to
>> be flagged "r" for read only
>
> Ah, yes that sounds exactly what we want, thanks for figuring that
> out.
>
>> and perhaps given an appropriate type
>> (either "d" or "x" for decimal or hex respectively, I suppose).
>
> Regards,
>
> Hans