On Wed, 12 Jun 2019 at 19:30, Stefano Babic <[email protected]> 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: [email protected] > ===================================================================== > _______________________________________________ > U-Boot mailing list > [email protected] > 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
