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

[Wolfgang Denk <wd@denx.de>]

Dear Rasmus,

In message <2edc1fb5-e723-fbd6-56da-bc0dea282343@prevas.dk> you wrote:
>
> >> set CONFIG_ENV_IS_NOWHERE, I'd get what I have now. The only problem
> > 
> > Can't you see that this is not logical?  If the environment is
> > nowhere, then how can you add something to it?
>
> That's silly. Even with CONFIG_ENV_IS_NOWHERE, "env set" still works
> just fine. So of course one can add something to the (runtime)

I'm sorry, but it seems you lack basic understanding of the design of
the environment system in U-Boot.

I have explained this repeatedly in the last few weeks, so here once
more:

CONFIG_ENV_IS_* defines, where the persistent storage for the
environment is located, that is where it is initialized from at
reset, and where it is saved to when you use the "env save" command.

Of course ""env set" still works perfectly fine on the in-memory
copy of the environment, as this has nothing to do with whether you
can save this data to some persistent storage or not.


> environment, even if the source of the original runtime environment
> happened to be default_environment[] and those changes cannot be persisted.

And this is where the mis-use starts.  default_environment[] has
never been intended to be used as regular data to initialize the
in-memory copy of the environment from.  It was there to be used in
emergency cases only, like then there were I/O errors on the storage
device or the saved copy of the environment had been corrupted, so
the checksum would not macth.


> > I see no difference here.  "env import" into an empty environment
> > does just that.
>
> The problem is, by the time it's possible to do an "env import" (no
> sooner than $preboot is executed I assume?) or any other shell command,
> U-Boot may already have read a bunch variables affecting its execution
> from the environment.

You can call the C function equivalent of the "env import" shell
command right ater the initialization of the environment - i. e. at
lease as early as any of your code can be used.

> So I think that for my _current_ use cases, doing it via a preboot
> command may be enough - from reading the code, it does seem that e.g.
> bootretry is only read after the preboot command has run.

I was not talking about implementing it by scripts only.  I just
wanted to point to the existing functionality - whether you call
this from th shell or from C code is your choice.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Just think of a computer as hardware you can program."
- Nigel de la Tierre