[U-Boot] Composing multiple envs
I'm trying to set up a configuration where I've largely got a hardcoded environment (ENV_IS_NOWHERE) with a very small list of variables that come from a loadable environment (ENV_IS_IN_FAT for my use case) - things like serial# and regulatory region. Even then I want them largely set once in the factory and not really written again.
I could've sworn I'd seen patches that implemented this kind of thing around the time of the environment rework, but I'm failing to find them either merged or pending.
Am I imagining it and should just go and code it up? Feels like most of the pieces I'd need are there.
-- Alex Kiernan
Dear Alex,
In message CAO5Uq5Tvbc_YumNXrFC8YHkRiADzEzKjr4bYb_Q=UsVST1CWEQ@mail.gmail.com you wrote:
I'm trying to set up a configuration where I've largely got a hardcoded environment (ENV_IS_NOWHERE) with a very small list of variables that come from a loadable environment (ENV_IS_IN_FAT for my use case) - things like serial# and regulatory region. Even then I want them largely set once in the factory and not really written again.
I could've sworn I'd seen patches that implemented this kind of thing around the time of the environment rework, but I'm failing to find them either merged or pending.
Why do you need code to do that? Why can't you just "env import" these additional fragments as part of your hard coded startup sequence?
Best regards,
Wolfgang Denk
On Sun, Mar 25, 2018 at 11:50 AM, Wolfgang Denk wd@denx.de wrote:
Dear Alex,
In message CAO5Uq5Tvbc_YumNXrFC8YHkRiADzEzKjr4bYb_Q=UsVST1CWEQ@mail.gmail.com you wrote:
I'm trying to set up a configuration where I've largely got a hardcoded environment (ENV_IS_NOWHERE) with a very small list of variables that come from a loadable environment (ENV_IS_IN_FAT for my use case) - things like serial# and regulatory region. Even then I want them largely set once in the factory and not really written again.
I could've sworn I'd seen patches that implemented this kind of thing around the time of the environment rework, but I'm failing to find them either merged or pending.
Why do you need code to do that?
I don't... just thinking about it the wrong way!
Why can't you just "env import" these additional fragments as part of your hard coded startup sequence?
Other than wanting to filter the variables that can come in that way, it does everything I need. In fact with sufficient care I probably don't even need to filter it.
Thanks for the pointer!
Dear Alex,
In message CAO5Uq5TK7_Z-pXH47zW+5w61OWzywewg+QMT6eXdhnyU36oKBQ@mail.gmail.com you wrote:
Why can't you just "env import" these additional fragments as part of your hard coded startup sequence?
Other than wanting to filter the variables that can come in that way, it does everything I need. In fact with sufficient care I probably don't even need to filter it.
Hm... env import could be extended to accept a list of variables (or maybe even RE) which it imports, ignoring the rest...
Best regards,
Wolfgang Denk
On Sun, Mar 25, 2018 at 3:34 PM, Wolfgang Denk wd@denx.de wrote:
Dear Alex,
In message CAO5Uq5TK7_Z-pXH47zW+5w61OWzywewg+QMT6eXdhnyU36oKBQ@mail.gmail.com you wrote:
Why can't you just "env import" these additional fragments as part of your hard coded startup sequence?
Other than wanting to filter the variables that can come in that way, it does everything I need. In fact with sufficient care I probably don't even need to filter it.
Hm... env import could be extended to accept a list of variables (or maybe even RE) which it imports, ignoring the rest...
I was just looking at exactly that option - on the face of it, we already have everything we need in place to support a simple list of variables passed through to env import. I'll look at coding up an RFC along those lines.
participants (2)
-
Alex Kiernan -
Wolfgang Denk