[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