On 20/11/2020 11.13, Wolfgang Denk wrote: > Dear Rasmus, > > In message <76615995-6700-1b3e-b598-4913e9882...@prevas.dk> you wrote: >> >> 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 > > In principle yes, I see that this is a nice and useful feature. > > Just the notation of "append" seems wrong to me. We already have > "env import" which can import additional / new environmane settings > in different formats. What I think should be done is extending this > by support for a new format (you may call it driver if you want) > to import environment settings from a DTB. > >> 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) environment, even if the source of the original runtime environment happened to be default_environment[] and those changes cannot be persisted. >>> 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. > > 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. 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'll see if I can come up with something else. Rasmus