[RFC PATCH] Provide mechanism for build-time default env entries
This enables the building user to specify environment values to be included in the static default_environment with an image. This is useful to build multiple otherwise like configured images, varying by environment unique entries.
---
I expected something like this to already be present, but couldn't find such a mechanism. I also assumed that something similar may have been proposed previously, but also couldn't find anything via searching.
Signed-off-by: Joel Johnson mrjoel@lixil.net --- env/Kconfig | 19 +++++++++++++++---- include/env_default.h | 3 +++ 2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/env/Kconfig b/env/Kconfig index ed12609f6a..5049cb78be 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -556,14 +556,25 @@ config SYS_RELOC_GD_ENV_ADDR Relocate the early env_addr pointer so we know it is not inside the binary. Some systems need this and for the rest, it doesn't hurt.
+config USER_ENV_SETTINGS + string "User build-time additional environment entries" + help + This value is reserved for the building user to provide custom + environment entries to be added to the default environment. Care must + be taken to not break the environment, incompatible entries may cause + failure to compile, or failure of the target board to properly + initialize or boot. The format is key=value pairs, with entries + separated by C-style escaped null terminated values, such as: + "key1=valueA\0key2=valueB\0key3=valueC". + config USE_DEFAULT_ENV_FILE bool "Create default environment from file" help Normally, the default environment is automatically generated - based on the settings of various CONFIG_* options, as well - as the CONFIG_EXTRA_ENV_SETTINGS. By selecting this option, - you can instead define the entire default environment in an - external file. + based on the settings of various CONFIG_* options, combined with values + of board specific CONFIG_EXTRA_ENV_SETTINGS and user provided + CONFIG_USER_ENV_SETTINGS. By selecting this option, you can instead + define the entire default environment in an external file.
config DEFAULT_ENV_FILE string "Path to default environment file" diff --git a/include/env_default.h b/include/env_default.h index 56a8bae39a..9396a34715 100644 --- a/include/env_default.h +++ b/include/env_default.h @@ -109,6 +109,9 @@ const uchar default_environment[] = { #endif #ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS +#endif +#ifdef CONFIG_USER_ENV_SETTINGS + CONFIG_USER_ENV_SETTINGS #endif "\0" #else /* CONFIG_USE_DEFAULT_ENV_FILE */
Dear Joel,
In message 20200119073738.29189-1-mrjoel@lixil.net you wrote:
This enables the building user to specify environment values to be included in the static default_environment with an image. This is useful to build multiple otherwise like configured images, varying by environment unique entries.
I expected something like this to already be present, but couldn't find such a mechanism. I also assumed that something similar may have been proposed previously, but also couldn't find anything via searching.
...
+config USER_ENV_SETTINGS
- string "User build-time additional environment entries"
- help
This value is reserved for the building user to provide customenvironment entries to be added to the default environment. Care mustbe taken to not break the environment, incompatible entries may causefailure to compile, or failure of the target board to properlyinitialize or boot. The format is key=value pairs, with entriesseparated by C-style escaped null terminated values, such as:"key1=valueA\0key2=valueB\0key3=valueC".
Something in your descripotion must be missing, or this change makes no sense to me.
#ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS +#endif +#ifdef CONFIG_USER_ENV_SETTINGS
- CONFIG_USER_ENV_SETTINGS
#endif
What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS and CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way with CONFIG_EXTRA_ENV_SETTINGS?
Maybe it would help if you include any code that is actually using this feature?
Best regards,
Wolfgang Denk
On 2020-01-20 09:51, Wolfgang Denk wrote:
Dear Joel,
In message 20200119073738.29189-1-mrjoel@lixil.net you wrote:
This enables the building user to specify environment values to be included in the static default_environment with an image. This is useful to build multiple otherwise like configured images, varying by environment unique entries.
I expected something like this to already be present, but couldn't find such a mechanism. I also assumed that something similar may have been proposed previously, but also couldn't find anything via searching.
...
+config USER_ENV_SETTINGS
- string "User build-time additional environment entries"
- help
This value is reserved for the building user to provide customenvironment entries to be added to the default environment. Caremust
be taken to not break the environment, incompatible entries maycause
failure to compile, or failure of the target board to properlyinitialize or boot. The format is key=value pairs, with entriesseparated by C-style escaped null terminated values, such as:"key1=valueA\0key2=valueB\0key3=valueC".Something in your descripotion must be missing, or this change makes no sense to me.
#ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS +#endif +#ifdef CONFIG_USER_ENV_SETTINGS
- CONFIG_USER_ENV_SETTINGS
#endif
What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS and CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way with CONFIG_EXTRA_ENV_SETTINGS?
Maybe it would help if you include any code that is actually using this feature?
Best regards,
Wolfgang Denk
The main different to me is that many boards set/replace CONFIG_EXTRA_ENV_SETTINGS, making it unusable as a user build-time configuration value. As a result, I can actually specify values for CONFIG_USER_ENV_SETTINGS and have them included in the resulting environment instead of overridden by the board configuration.
There is intentionally no code using this feature, as meant in the description it is intended to be reserved for the building user's usage. The specific use case for which I'm using it is to ease building of multiple otherwise identical images, embedding a fixed and well known set of ethernet MAC addresses into each unique image for execution in environments with no environment storage. It is meant to be used for any other values changed or added in the default image environment though - if there is a better way to accomplish this I'd be all for it, but I couldn't find anything, thus the RFC patch.
Joel
On Mon, Jan 20, 2020 at 10:09:21AM -0700, Joel Johnson wrote:
On 2020-01-20 09:51, Wolfgang Denk wrote:
Dear Joel,
In message 20200119073738.29189-1-mrjoel@lixil.net you wrote:
This enables the building user to specify environment values to be included in the static default_environment with an image. This is useful to build multiple otherwise like configured images, varying by environment unique entries.
I expected something like this to already be present, but couldn't find such a mechanism. I also assumed that something similar may have been proposed previously, but also couldn't find anything via searching.
...
+config USER_ENV_SETTINGS
- string "User build-time additional environment entries"
- help
This value is reserved for the building user to provide customenvironment entries to be added to the default environment. Caremust
be taken to not break the environment, incompatible entries maycause
failure to compile, or failure of the target board to properlyinitialize or boot. The format is key=value pairs, with entriesseparated by C-style escaped null terminated values, such as:"key1=valueA\0key2=valueB\0key3=valueC".Something in your descripotion must be missing, or this change makes no sense to me.
#ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS +#endif +#ifdef CONFIG_USER_ENV_SETTINGS
- CONFIG_USER_ENV_SETTINGS
#endif
What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS and CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way with CONFIG_EXTRA_ENV_SETTINGS?
Maybe it would help if you include any code that is actually using this feature?
Best regards,
Wolfgang Denk
The main different to me is that many boards set/replace CONFIG_EXTRA_ENV_SETTINGS, making it unusable as a user build-time configuration value. As a result, I can actually specify values for CONFIG_USER_ENV_SETTINGS and have them included in the resulting environment instead of overridden by the board configuration.
There is intentionally no code using this feature, as meant in the description it is intended to be reserved for the building user's usage. The specific use case for which I'm using it is to ease building of multiple otherwise identical images, embedding a fixed and well known set of ethernet MAC addresses into each unique image for execution in environments with no environment storage. It is meant to be used for any other values changed or added in the default image environment though - if there is a better way to accomplish this I'd be all for it, but I couldn't find anything, thus the RFC patch.
I think part of the problem is that CONFIG_EXTRA_ENV_SETTINGS needs to be migrated to Kconfig. And that in turn shows that some amount of things need to be taken out of the CONFIG namespace and moved in to distinct headers to be included / keyed-in-to. What we have in include/environment/ti/ is a start to that but far from complete.
On January 20, 2020 5:15:37 PM UTC, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 20, 2020 at 10:09:21AM -0700, Joel Johnson wrote:
On 2020-01-20 09:51, Wolfgang Denk wrote:
Dear Joel,
In message 20200119073738.29189-1-mrjoel@lixil.net you wrote:
This enables the building user to specify environment values to
be
included in the static default_environment with an image. This is useful to build multiple otherwise like configured images,
varying
by environment unique entries.
I expected something like this to already be present, but
couldn't
find such a mechanism. I also assumed that something similar may have been proposed previously, but also couldn't find anything
via
searching.
...
+config USER_ENV_SETTINGS
- string "User build-time additional environment entries"
- help
This value is reserved for the building user to providecustom
environment entries to be added to the default environment.Care
must
be taken to not break the environment, incompatible entriesmay
cause
failure to compile, or failure of the target board toproperly
initialize or boot. The format is key=value pairs, withentries
separated by C-style escaped null terminated values, such as:"key1=valueA\0key2=valueB\0key3=valueC".Something in your descripotion must be missing, or this change
makes
no sense to me.
#ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS +#endif +#ifdef CONFIG_USER_ENV_SETTINGS
- CONFIG_USER_ENV_SETTINGS
#endif
What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS
and
CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way with CONFIG_EXTRA_ENV_SETTINGS?
Maybe it would help if you include any code that is actually using this feature?
Best regards,
Wolfgang Denk
The main different to me is that many boards set/replace CONFIG_EXTRA_ENV_SETTINGS, making it unusable as a user build-time configuration value. As a result, I can actually specify values for CONFIG_USER_ENV_SETTINGS and have them included in the resulting
environment
instead of overridden by the board configuration.
There is intentionally no code using this feature, as meant in the description it is intended to be reserved for the building user's
usage. The
specific use case for which I'm using it is to ease building of
multiple
otherwise identical images, embedding a fixed and well known set of
ethernet
MAC addresses into each unique image for execution in environments
with no
environment storage. It is meant to be used for any other values
changed or
added in the default image environment though - if there is a better
way to
accomplish this I'd be all for it, but I couldn't find anything, thus
the
RFC patch.
I think part of the problem is that CONFIG_EXTRA_ENV_SETTINGS needs to be migrated to Kconfig. And that in turn shows that some amount of things need to be taken out of the CONFIG namespace and moved in to distinct headers to be included / keyed-in-to. What we have in include/environment/ti/ is a start to that but far from complete.
That sounds like a good path indeed, but wouldn't that still result in the Kconfig value being required to contain the full extra contents? The nice thing about a separate config entry is that it can serve as an overlay of just selected overrides and/or custom entries, instead of requiring following and updating user configs for in-source changes which are unrelated, but still captured in board level EXTRA
Either way works, I'd still be in favor of a separate overlay, thus the RFC patch. If you'd like it all eventually consolidated in EXTRA then I'll just carry the patch locally.
Joel
On Mon, Jan 20, 2020 at 05:30:57PM +0000, Joel Johnson wrote:
On January 20, 2020 5:15:37 PM UTC, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 20, 2020 at 10:09:21AM -0700, Joel Johnson wrote:
On 2020-01-20 09:51, Wolfgang Denk wrote:
Dear Joel,
In message 20200119073738.29189-1-mrjoel@lixil.net you wrote:
This enables the building user to specify environment values to
be
included in the static default_environment with an image. This is useful to build multiple otherwise like configured images,
varying
by environment unique entries.
I expected something like this to already be present, but
couldn't
find such a mechanism. I also assumed that something similar may have been proposed previously, but also couldn't find anything
via
searching.
...
+config USER_ENV_SETTINGS
- string "User build-time additional environment entries"
- help
This value is reserved for the building user to providecustom
environment entries to be added to the default environment.Care
must
be taken to not break the environment, incompatible entriesmay
cause
failure to compile, or failure of the target board toproperly
initialize or boot. The format is key=value pairs, withentries
separated by C-style escaped null terminated values, such as:"key1=valueA\0key2=valueB\0key3=valueC".Something in your descripotion must be missing, or this change
makes
no sense to me.
#ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS +#endif +#ifdef CONFIG_USER_ENV_SETTINGS
- CONFIG_USER_ENV_SETTINGS
#endif
What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS
and
CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way with CONFIG_EXTRA_ENV_SETTINGS?
Maybe it would help if you include any code that is actually using this feature?
Best regards,
Wolfgang Denk
The main different to me is that many boards set/replace CONFIG_EXTRA_ENV_SETTINGS, making it unusable as a user build-time configuration value. As a result, I can actually specify values for CONFIG_USER_ENV_SETTINGS and have them included in the resulting
environment
instead of overridden by the board configuration.
There is intentionally no code using this feature, as meant in the description it is intended to be reserved for the building user's
usage. The
specific use case for which I'm using it is to ease building of
multiple
otherwise identical images, embedding a fixed and well known set of
ethernet
MAC addresses into each unique image for execution in environments
with no
environment storage. It is meant to be used for any other values
changed or
added in the default image environment though - if there is a better
way to
accomplish this I'd be all for it, but I couldn't find anything, thus
the
RFC patch.
I think part of the problem is that CONFIG_EXTRA_ENV_SETTINGS needs to be migrated to Kconfig. And that in turn shows that some amount of things need to be taken out of the CONFIG namespace and moved in to distinct headers to be included / keyed-in-to. What we have in include/environment/ti/ is a start to that but far from complete.
That sounds like a good path indeed, but wouldn't that still result in the Kconfig value being required to contain the full extra contents? The nice thing about a separate config entry is that it can serve as an overlay of just selected overrides and/or custom entries, instead of requiring following and updating user configs for in-source changes which are unrelated, but still captured in board level EXTRA
Either way works, I'd still be in favor of a separate overlay, thus the RFC patch. If you'd like it all eventually consolidated in EXTRA then I'll just carry the patch locally.
It's really hard to say how much of what's in CONFIG_EXTRA_ENV_SETTINGS today should stay that way vs being put in to a common header that can be re-used. That in fact might lead to making it easier to include an additional file of environment contents as while we can put in escape-sequenced strings via Kconfig (and do for mtdparts related stuff) it's really not user-friendly and another case of where we're encoding information via Kconfig that could be done more nicely.
Dear Joel,
In message 7cac871967a1317cea251e78d67a30ac@lixil.net you wrote:
+config USER_ENV_SETTINGS
- string "User build-time additional environment entries"
- help
This value is reserved for the building user to provide customenvironment entries to be added to the default environment. Caremust
be taken to not break the environment, incompatible entries maycause
failure to compile, or failure of the target board to properlyinitialize or boot. The format is key=value pairs, with entriesseparated by C-style escaped null terminated values, such as:"key1=valueA\0key2=valueB\0key3=valueC".Something in your descripotion must be missing, or this change makes no sense to me.
#ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS +#endif +#ifdef CONFIG_USER_ENV_SETTINGS
- CONFIG_USER_ENV_SETTINGS
#endif
What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS and CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way with CONFIG_EXTRA_ENV_SETTINGS?
...
The main different to me is that many boards set/replace CONFIG_EXTRA_ENV_SETTINGS, making it unusable as a user build-time configuration value. As a result, I can actually specify values for CONFIG_USER_ENV_SETTINGS and have them included in the resulting environment instead of overridden by the board configuration.
But what exactly is the difference between editing some include file to change CONFIG_EXTRA_ENV_SETTINGS or editing some include file to change CONFIG_USER_ENV_SETTINGS ?
To me this makes no sense.
Also, you probably cannot do what you want anyway. Assume CONFIG_EXTRA_ENV_SETTINGS has a setting of BOOTDELAY to 5 seconds, and you want to change it to 1 second only. with your code you have the same variable definition twice in your default environment. Do you know what the environment importer will do?
There is intentionally no code using this feature, as meant in the description it is intended to be reserved for the building user's usage.
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.
The specific use case for which I'm using it is to ease building of multiple otherwise identical images, embedding a fixed and well known set of ethernet MAC addresses into each unique image for execution in environments with no environment storage. It is meant to be used for any other values changed or added in the default image environment though -
Editing files and building new images seems not the right method to me. If each image is different, you will never ever be able to reproduce which image has been installed where.
if there is a better way to accomplish this I'd be all for it, but I couldn't find anything, thus the RFC patch.
There are many ways to provision code new hardware; depending on hardware features more or less. You can always import envrionment blobs from any device you can read from, including serial line and (if available) network. You may be able to boot the system over USB, you may use DFU, etc.
Changing the code and building a new image for each and every board is pretty much pessimal.
Best regards,
Wolfgang Denk
On 2020-01-20 11:59, Wolfgang Denk wrote:
Dear Joel,
In message 7cac871967a1317cea251e78d67a30ac@lixil.net you wrote:
+config USER_ENV_SETTINGS
- string "User build-time additional environment entries"
- help
This value is reserved for the building user to provide customenvironment entries to be added to the default environment. Caremust
be taken to not break the environment, incompatible entries maycause
failure to compile, or failure of the target board to properlyinitialize or boot. The format is key=value pairs, with entriesseparated by C-style escaped null terminated values, such as:"key1=valueA\0key2=valueB\0key3=valueC".Something in your descripotion must be missing, or this change makes no sense to me.
#ifdef CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_ENV_SETTINGS +#endif +#ifdef CONFIG_USER_ENV_SETTINGS
- CONFIG_USER_ENV_SETTINGS
#endif
What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS and CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way with CONFIG_EXTRA_ENV_SETTINGS?
...
The main different to me is that many boards set/replace CONFIG_EXTRA_ENV_SETTINGS, making it unusable as a user build-time configuration value. As a result, I can actually specify values for CONFIG_USER_ENV_SETTINGS and have them included in the resulting environment instead of overridden by the board configuration.
But what exactly is the difference between editing some include file to change CONFIG_EXTRA_ENV_SETTINGS or editing some include file to change CONFIG_USER_ENV_SETTINGS ?
To me this makes no sense.
The primary difference is in how we store the changes - include file changes are necessarily in-tree source changes, whereas setting the Kconfig value can be easily done by script obtaining the needed values from an external storage mechanism.
Also, you probably cannot do what you want anyway. Assume CONFIG_EXTRA_ENV_SETTINGS has a setting of BOOTDELAY to 5 seconds, and you want to change it to 1 second only. with your code you have the same variable definition twice in your default environment. Do you know what the environment importer will do?
This is a valid concern and the biggest gap in the approach. I don't have a full and proper solution for it currently, but have started looking into a couple of ideas. In the meantime, I tried to draw attention to it in the help text, essentially saying "here be dragons", be careful.
There is intentionally no code using this feature, as meant in the description it is intended to be reserved for the building user's usage.
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.
The specific use case for which I'm using it is to ease building of multiple otherwise identical images, embedding a fixed and well known set of ethernet MAC addresses into each unique image for execution in environments with no environment storage. It is meant to be used for any other values changed or added in the default image environment though
Editing files and building new images seems not the right method to me. If each image is different, you will never ever be able to reproduce which image has been installed where.
if there is a better way to accomplish this I'd be all for it, but I couldn't find anything, thus the RFC patch.
There are many ways to provision code new hardware; depending on hardware features more or less. You can always import envrionment blobs from any device you can read from, including serial line and (if available) network. You may be able to boot the system over USB, you may use DFU, etc.
Changing the code and building a new image for each and every board is pretty much pessimal.
Best regards,
Wolfgang Denk
Joel
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
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
Dear Joel,
In message da8de88ab6c98da726e3548367e09dd9@lixil.net you wrote:
Ah, I didn't catch the gist of your suggestion then since you references serial and storage.
These were examples just to demonstrate the flexibility.
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.
But as a plus, it does not require any code changes, and you can still use the same binary U-Boot image for all your boards.
Doing some "dd" + "cat" to concatenate the two files with proper alignment is trivial; this can and should be done independent from the U-Boot build as you don't have to build a new U-Boot image for each of your boards any more - you just provide a new environment blob to concat with the u-boot.bin .
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.
There is no "instead". Yes, it requires to run such an "env import" command, but this also can be added without code change but just defining such a command with CONFIG_PREBOOT. The it will automatically do that on every boot before doing anything else.
The default environment is already stored in some embedded location, so my goal would be to store the defaults in the existing environment segment.
As discussed, this is a bad idea, as this would result in board-specific images, which is a maintenance nightmare.
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
Such a deduplication is non-trivial. You would need something that extrcts the preprocessor-generated string, parses it according to the internal structure of the environment, and rewrites it. And just to do something your way, while other (much more flexible) ways exist?
My general thinking at uch things is: if you can script something or do it in other ways that don't require code changes, then it is worth having a closer look in those other ways.
Best regards,
Wolfgang Denk
participants (3)
-
Joel Johnson -
Tom Rini -
Wolfgang Denk