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

[Simon Glass]

Hi Wolfgang,

On Fri, 20 Nov 2020 at 04:28, Wolfgang Denk <wd at denx.de> wrote:
>
> Dear Simon,
>
> In message <CAPnjgZ1C3TQWkUuNQc0BHOGE957s0K-nxFmW3PVO_ObOcKwv+Q at mail.gmail.com> you wrote:
> >
> > Some years ago I did a series to allow the environment to come from a
> > text file, thus avoiding the \0 stuff.
>
> "env import -t" does that, you know?

Not to derail the discussion, but I mean as a way of specifying the
default environment.

>
> > Now binman has a 'u-boot-env'
> > entry type, allowing creating an environment from a text file, with
> > suitable checksumming.
>
> "env import -b" ...

For the binman case, this is an environment area which is loaded by
U-Boot on boot, so does not need any such command.

>
> > There is some advantage to having a default environment compiled into
> > U-Boot that covers everything needed to boot. For one, the environment
> > can be clobbered from userspace, which would otherwise render the
> > device unbootable. For another, it is more secure to avoid loading
> > unsigned data (the environment) from flash. Generally, for a secure
> > boot, one would need to avoid loading the environment, at least
> > without a lot of careful filtering.
>
> One idea behind my rewrite of the environment handling (when I added
> hast table support) was that there should be more than one way to
> initialize the environment.  Until then, we always had exactly one
> fixed location for the environment, probaly with a redundant copy.
>
> The code we have now actuially allows for a much greater
> flexibility.  You can initialize the environment from a selection of
> copies, and (now, with proper driver support) also from several
> devices.  If doen correctly, we could implement things like
> "profiles", where for example each user (or use case) can select his
> specific profile, initialize the environment from that, and save
> change to that.  Ths could - for example - be used to switch between
> "development" and "production" modes. A "reset to factory defaults"
> would then just be an import from the (read-only) factory-defaults
> copy.  etc.
>
> Importing from a DT is just a logical extension as it is considered
> just another storage device / driver.  [In a Unix environment, all
> these would just be "files".]
>
> It's all there.  We just have to use it.

OK I'll let you figure this out with Rasmus.

Regards,
Simon