On 17/11/2020 00.52, Simon Glass wrote: > Hi Rasmus, > > On Thu, 12 Nov 2020 at 12:59, Wolfgang Denk <w...@denx.de> wrote: >> >> Dear Rasmus Villemoes, >> >> In message <20201110202603.20944-5-rasmus.villem...@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
