[U-Boot] recommended place to add some custom settings to u-boot environment?
on my target board, there is some non-linux environment info in "var=val" form that i want to drag into the current environment whenever u-boot starts up. my plan is just to import that content into a (new) hash table, then tweak it a bit before further adding it to "env_htab". the logistics seem pretty straightforward, i'm just curious as to where the *right*(?) place is to do this.
currently, we're not taking advantage of CONFIG_MISC_INIT_R, so it seems that would be a reasonable place to do that, in the board source file.
does that make sense? at that point, all of the normal environment will have been initialized, and i'll have access to "env_htab". thoughts? is there a better place to "adjust" the u-boot environment once u-boot has done its normal work? thanks.
rday
Dear Robert,
In message alpine.LFD.2.20.1609140451540.23455@localhost.localdomain you wrote:
on my target board, there is some non-linux environment info in "var=val" form that i want to drag into the current environment whenever u-boot starts up. my plan is just to import that content into a (new) hash table, then tweak it a bit before further adding it to "env_htab". the logistics seem pretty straightforward, i'm just curious as to where the *right*(?) place is to do this.
Sounds complicated...
does that make sense? at that point, all of the normal environment will have been initialized, and i'll have access to "env_htab". thoughts? is there a better place to "adjust" the u-boot environment once u-boot has done its normal work? thanks.
Why not simply putting this as text (or wrapped with an uImage header) into some storage (or even a file) and then use "env import" to load it?
Best regards,
Wolfgang Denk
On Wed, 14 Sep 2016, Wolfgang Denk wrote:
Dear Robert,
In message alpine.LFD.2.20.1609140451540.23455@localhost.localdomain you wrote:
on my target board, there is some non-linux environment info in "var=val" form that i want to drag into the current environment whenever u-boot starts up. my plan is just to import that content into a (new) hash table, then tweak it a bit before further adding it to "env_htab". the logistics seem pretty straightforward, i'm just curious as to where the *right*(?) place is to do this.
Sounds complicated...
does that make sense? at that point, all of the normal environment will have been initialized, and i'll have access to "env_htab". thoughts? is there a better place to "adjust" the u-boot environment once u-boot has done its normal work? thanks.
Why not simply putting this as text (or wrapped with an uImage header) into some storage (or even a file) and then use "env import" to load it?
the problem is that that additional "environment" info is on the target board because of a legacy non-linux OS -- it's at a well-known address in flash, and we have no freedom to change it, we can only read it, make some adjustments, then incorporate it into the current environment.
rday
Dear Robert,
In message alpine.LFD.2.20.1609140524480.27791@localhost.localdomain you wrote:
Why not simply putting this as text (or wrapped with an uImage header) into some storage (or even a file) and then use "env import" to load it?
the problem is that that additional "environment" info is on the target board because of a legacy non-linux OS -- it's at a well-known address in flash, and we have no freedom to change it, we can only read it, make some adjustments, then incorporate it into the current environment.
Which format is used? Can it not be made to work with "env import" using this well-known address? I mean, if it's plain text, it should just work. If it's some other, more exotic format, you could probably implement a custom import format?
Best regards,
Wolfgang Denk
On Wed, 14 Sep 2016, Wolfgang Denk wrote:
Dear Robert,
In message alpine.LFD.2.20.1609140524480.27791@localhost.localdomain you wrote:
Why not simply putting this as text (or wrapped with an uImage header) into some storage (or even a file) and then use "env import" to load it?
the problem is that that additional "environment" info is on the target board because of a legacy non-linux OS -- it's at a well-known address in flash, and we have no freedom to change it, we can only read it, make some adjustments, then incorporate it into the current environment.
Which format is used? Can it not be made to work with "env import" using this well-known address? I mean, if it's plain text, it should just work. If it's some other, more exotic format, you could probably implement a custom import format?
it needs to be done programatically, and i *believe* himport_r() can handle it, as the string is space-separated and null-terminated, so i'm about to test that.
rday
Dear Robert,
In message alpine.LFD.2.20.1609140902380.2267@ca624034.mitel.com you wrote:
it needs to be done programatically, and i *believe* himport_r() can handle it, as the string is space-separated and null-terminated, so i'm about to test that.
It will not realy work. "space-separated" is not good enough as a space character is a legal part of the value of an environment variable. You would need to tweak the import code.
Best regards,
Wolfgang Denk
On Wed, 14 Sep 2016, Wolfgang Denk wrote:
Dear Robert,
In message alpine.LFD.2.20.1609140902380.2267@ca624034.mitel.com you wrote:
it needs to be done programatically, and i *believe* himport_r() can handle it, as the string is space-separated and null-terminated, so i'm about to test that.
It will not realy work. "space-separated" is not good enough as a space character is a legal part of the value of an environment variable. You would need to tweak the import code.
but himport_r() explicitly takes a separator character, and i can guarantee the strings being "imported" have no embedded space characters in their values. so as long as that's the case, shouldn't himport_r() properly handle that given a separator of space?
rday
Dear Robert,
In message alpine.LFD.2.20.1609140935240.5661@ca624034.mitel.com you wrote:
It will not realy work. "space-separated" is not good enough as a space character is a legal part of the value of an environment variable. You would need to tweak the import code.
but himport_r() explicitly takes a separator character, and i can guarantee the strings being "imported" have no embedded space characters in their values. so as long as that's the case, shouldn't himport_r() properly handle that given a separator of space?
Well, yes, but it sounds a bit fragile to me. Experience tells me that very soon someone _will_ use a space in a variable.
Best regards,
Wolfgang Denk
On Wed, 14 Sep 2016, Wolfgang Denk wrote:
Dear Robert,
In message alpine.LFD.2.20.1609140935240.5661@ca624034.mitel.com you wrote:
It will not realy work. "space-separated" is not good enough as a space character is a legal part of the value of an environment variable. You would need to tweak the import code.
but himport_r() explicitly takes a separator character, and i can guarantee the strings being "imported" have no embedded space characters in their values. so as long as that's the case, shouldn't himport_r() properly handle that given a separator of space?
Well, yes, but it sounds a bit fragile to me. Experience tells me that very soon someone _will_ use a space in a variable.
in this case, no ... it's legacy info that will never, ever change at this point.
rday
participants (2)
-
Robert P. J. Day -
Wolfgang Denk