On 2020-01-21 10:49, Wolfgang Denk wrote:
Dear Joel,
In message <ac347e2e978aa082fc516c789d0f9...@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
