[U-Boot] Default environment file

[Vladimir Oltean]

On Wed, 12 Jun 2019 at 19:30, Stefano Babic <sbabic at denx.de> wrote:
>
> Hi Tom,
>
> Hi everybody,
>
> On 12/06/19 16:16, Tom Rini wrote:
> > On Wed, Jun 12, 2019 at 10:43:26AM +0200, Stefano Babic wrote:
> >> Hi Pascal,
> >>
> >> On 12/06/19 10:20, Linder Pascal wrote:
> >>> Hi everyone,
> >>>
> >>>
> >>> I am currently moving the configurations of the KM boards from header files to Kconfig. But for the customly defined environment variables I did not found a decent solution until I have come across the default environment file, which seems very interesting to me.
> >>>
> >>>
> >>> To this day, nevertheless, it appears that noone made use of the CONFIG_USE_DEFAULT_ENV_FILE configuration defined in env/Kconfig. Does anyone still have an example for this kind of environment definition or knows how to create it?
> >>>
> >>>
> >>> In my opinion, this could be highly relevant for the transition away from the header files in include/configs.
> >>>
> >>
> >> Fully agree. Rather, I do not think there is a relevant example. But the
> >> environment is something like data and should not be part of the header
> >> file as it is for histoical reason. I added some times ago a way to
> >> extract the environment from the header and make the transition easy
> >> (see make u-boot-initial-env). And if the environment is split from the
> >> header as CONFIG_USE_DEFAULT_ENV_FILE allows, it is also easier to set
> >> an own environment via OE BSP layer without pushing for each small
> >> change to U-Boot. Not only, environments often conflict, and what is
> >> good for a project becomes evil for another one.
> >
> > With the high-level goal of being able to eliminate the include/configs
> > file, we need to figure out a better solution to dealing with the
> > default environment.
>
> Right.
>
> > Shuffling things into include/environment/ has
> > been the first step I've tried but I'm absolutely not tied down to this
> > and if people are motivated to push in a new solution to this overall
> > problem I'm happy to see it happen.  This sounds like a good overall
> > idea.
>
> The default / initial environment is more a configuration data for the
> bootloader as part of it. Linking it to the rest of code was done at the
> beginning of U-Boot and it was never changed for historical reasons, but
> the environment is just configuration data.  Theoretically, we could
> have the same environment for multiple boards and we could use the same
> files.
>
> IMHO it should be more a job for binman as for the linker to put
> environment and u-boot code together. My first idea could be to drop it
> from code and appending it to the binary, letting the code (SPL /
> u-boot) know where the initial environment is found.
> CONFIG_USE_DEFAULT_ENV_FILE could be used to set which file should be
> taken by binman - the result is still a single file that can be signed
> in case of secure boot.
>
> Best regards,
> Stefano
>
> --
> =====================================================================
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

Hi guys,

Chiming in to the discussion as well, as I was looking to submit a new
board port of U-boot with the distro boot feature, and I was amazed by
the stupendous amount of code duplication in these include/configs/*.h
files.
Separating the default env from the main bootloader executable image
doesn't look to me like the main problem here - but rather how to
re-use common portions of environments in a way that scales for
hundreds of boards, and at the same time allow for customization?
Maybe this is a naive question, but what if we just throw the C
preprocessor at the CONFIG_DEFAULT_ENV_FILE before including it into
the U-boot image? I don't know enough about the Hush shell to realize
at this point whether it has any other overlap with the C preprocessor
than the comments (# in Hush, // or /* */ in C).
Then per-board CONFIG_DEFAULT_ENV_FILE files could sit just fine in
include/environment, with the advantage that they can be layered in a
nice inclusion hierarchy - this I believe should addresses some of
Tom's issues with this setting at least partly.

Regards,
-Vladimir