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

Simon Glass sjg at chromium.org
Tue Nov 17 00:52:56 CET 2020


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).
>
> 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.
>
>
> And please, for the sake of avoiding further confusiion, please do
> not name this "default-environment".

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?

Regards,
Simon


More information about the U-Boot mailing list