On Wed, 12 Jun 2019 at 19:30, Stefano Babic sbabic@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@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@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