[RFC PATCH] Provide mechanism for build-time default env entries

[Wolfgang Denk]

Dear Joel,

In message <da8de88ab6c98da726e3548367e09dd9 at lixil.net> you wrote:
>
> Ah, I didn't catch the gist of your suggestion then since you references 
> serial and storage.

These were examples just to demonstrate the flexibility.

> Doing something like you suggest sounds like it would be a reasonable 
> option, but as far as I'm aware there isn't anything currently built-in 
> to provide such a separate capability.

But as a plus, it does not require any code changes, and you can
still use the same binary U-Boot image for all your boards.

Doing some "dd" + "cat" to concatenate the two files with proper
alignment is trivial; this can and should be done independent from
the U-Boot build as you don't have to build a new U-Boot image for
each of your boards any more - you just provide a new environment
blob to concat with the u-boot.bin .

> Plus, if I'm understanding your 
> suggestion, it would still require an execution of "env import" to load 
> from the separate block instead of being seeded automatically on boot. 

There is no "instead".  Yes, it requires to run such an "env import"
command, but this also can be added without code change but just
defining such a command with CONFIG_PREBOOT.  The it will
automatically do that on every boot before doing anything else.

> The default environment is already stored in some embedded location, so 
> my goal would be to store the defaults in the existing environment 
> segment.

As discussed, this is a bad idea, as this would result in
board-specific images, which is a maintenance nightmare.

> Ideally that would have a compile-time processing check to 
> deduplicate entries based on specified precedence, but the simple fix 
> for my use case worked as was better than what I could find already 

Such a deduplication is non-trivial.  You would need something that
extrcts the preprocessor-generated string, parses it according to the
internal structure of the environment, and rewrites it.  And just to
do something your way, while other (much more flexible) ways exist?

My general thinking at uch things is: if you can script something or
do it in other ways that don't require code changes, then it is
worth having a closer look in those other ways.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"No proper program contains  an  indication  which  as  an  operator-
applied  occurrence  identifies an operator-defining occurrence which
as an indication-applied occurrence identifies an indication-defining
occurrence different from the one identified by the given  indication
as an indication-applied occurrence."               - ALGOL 68 Report