[PATCH 4/5] env: allow default environment to be amended from control dtb

[Rasmus Villemoes]

On 17/11/2020 00.52, Simon Glass wrote:
> Hi Rasmus,
> 
> On Thu, 12 Nov 2020 at 12:59, Wolfgang Denk <wd at denx.de> wrote:
>>
>> Dear Rasmus Villemoes,
>>
>> In message <20201110202603.20944-5-rasmus.villemoes at prevas.dk> you wrote:
>>> It can be useful to use the same U-Boot binary for multiple purposes,
>>> say the normal one, one for developers that allow breaking into the
>>> U-Boot shell, and one for use during bootstrapping which runs a
>>> special-purpose bootcmd. To that end, allow the control dtb to contain
>>> a /config/default-enviroment property, whose value will be used to
>>> amend the default environment baked into the U-Boot binary itself.
>>
>> No, this is not what should be done.
>>
>> Please try to get used to the idea behind the so called "default
>> environment".  Only now I realize that this was a badly chosen name,
>> but last_resort_in_case_of_emergencies_environment would have had
>> other problems.
>>
>> The default environment is something which is NOT INTENDED for
>> regular use.  it is what you will fall back to in case (and ONLY in
>> that case) when your regular persistent environment cannot be used,
>> for example because it is not readable (I/O errors or such) or not
>> properly initialized or corrupted (CRC checksum error).

You seem to be ignoring the many cases where one chooses, for
simplicity, robustness and/or security, not to have a writable
environment at all.

>> It is not the intended use but still somewhat acceptable to use it
>> as initial data to populate the regular environment in other cases,
>> too.  But that's it.
>>
>> Apending data to it is not acceptable.  If you need to append data,
>> then only to the regular environment.

I'm not really doing anything other than allowing a
CONFIG_ENV_EXTRA_SETTINGS to live in .dtb rather than cooking all of it
into the U-Boot binary itself. That's where board-specific additions are
supposed to live nowadays I'd assume.

>> And please, for the sake of avoiding further confusiion, please do
>> not name this "default-environment".

Sure. So would you be ok with some /config/extra-environment node which
gets appended after the normal environment has been loaded? Then if I
set CONFIG_ENV_IS_NOWHERE, I'd get what I have now. The only problem
with that is that it might be a little weird to have static content of
the chosen control dtb override something that might have been loaded
from a writable storage location. But that's not really an intended
combination anyway, and I can probably add a knob that allows one to
choose whether the .dtb settings should be applied or not.

> Apart from what Wolfgang says here, it does seem useful.
> 
> I wonder if we should have a way to load the (whole) environment from DT?

That will be my second choice, i.e. adding a "CONFIG_ENV_IS_IN_DTB"
which obviously doesn't support saving, but has the advantages I'm after
here of using one U-Boot binary with slightly different environments.

Rasmus