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

Joel Johnson mrjoel at lixil.net
Tue Jan 21 22:35:45 CET 2020


On 2020-01-21 10:49, Wolfgang Denk wrote:
> Dear Joel,
> 
> In message <ac347e2e978aa082fc516c789d0f9048 at lixil.net> you wrote:
>> 
>> > I think you are following a wrong approach.  Such user specific
>> > settings should IMHO loaded separately, either over serial like
>> > (should be fast enough for a few hundred bytes) or from external
>> > storage. "env import" is your friend.
>> 
>> I'm intentionally trying to have no persistent environment separate 
>> from
>> boot image.
> 
> In which way does this prevent you from following my suggestion?
> such a separate environment block (in any format, either as plain
> ASCII text, or binary, or as checksummed blob) can easily be
> attached to the U-Boot image and handled as a combined unit.  Then
> you just import the additional environment from this well-known
> address.  This gives you all the possibilities you have for handling
> the environment, conflict free.
> 
> Best regards,
> 
> Wolfgang Denk

Ah, I didn't catch the gist of your suggestion then since you references 
serial and storage.

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. 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. 
The default environment is already stored in some embedded location, so 
my goal would be to store the defaults in the existing environment 
segment. 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 
provided.

Joel


More information about the U-Boot mailing list