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