[U-Boot-Users] auto-save environment if using default environment?
Hi,
I just had the problem of fw_{print,save}env not being able to access the environment because I was using the default (builtin) environment after flashing U-Boot. I wonder if I am the only one having this problem, or is it common practice to flash the environment together with U-Boot during production?
I just made this small patch to auto-save the environment if it is not found in flash but am wondering if - I missed something and such a possibility does already exist? (I could not find a possibility to check from the command-line if the current environment comes from flash or is the built-in default environment, else it would be easier to make a script check and call saveenv before booting.) - this small change is enough? - something similar might be worth considering as a new regular feature?
Best regards, Wolfgang
diff --git a/common/env_common.c b/common/env_common.c index a494812..8acee8f 100644 --- a/common/env_common.c +++ b/common/env_common.c @@ -243,6 +243,11 @@ void env_relocate (void) #endif env_crc_update (); gd->env_valid = 1; +#ifdef CFG_ENV_AUTOSAVE + gd->env_addr = (ulong)&(env_ptr->data); + puts ("Saving environment\n"); + saveenv (); +#endif } else { env_relocate_spec ();
On 14:36 Tue 25 Mar , w.wegner@astro-kom.de wrote:
Hi,
I just had the problem of fw_{print,save}env not being able to access the environment because I was using the default (builtin) environment after flashing U-Boot. I wonder if I am the only one having this problem, or is it common practice to flash the environment together with U-Boot during production?
I just made this small patch to auto-save the environment if it is not found in flash but am wondering if
- I missed something and such a possibility does already exist? (I could not find a possibility to check from the command-line if the current environment comes from flash or is the built-in default environment, else it would be easier to make a script check and call saveenv before booting.)
- this small change is enough?
- something similar might be worth considering as a new regular feature?
Best regards, Wolfgang
diff --git a/common/env_common.c b/common/env_common.c index a494812..8acee8f 100644 --- a/common/env_common.c +++ b/common/env_common.c @@ -243,6 +243,11 @@ void env_relocate (void) #endif env_crc_update (); gd->env_valid = 1; +#ifdef CFG_ENV_AUTOSAVE
gd->env_addr = (ulong)&(env_ptr->data);puts ("Saving environment\n");saveenv ();+#endif } else { env_relocate_spec ();
I'll point some problem that could appear with some flash that need to drive some pio before write or erase the flash due to VPP protection
If you want to add an autosave you may need to add a pre-save and post-save mecanism
and I'll prefer CONFIG_ENV_AUTOSAVE than CFG_ENV_AUTOSAVE.
Best Regards, J.
Hi,
On 25 Mar 2008 at 16:24, Jean-Christophe PLAGNIOL-VILLARD wrote:
diff --git a/common/env_common.c b/common/env_common.c index a494812..8acee8f 100644 --- a/common/env_common.c +++ b/common/env_common.c @@ -243,6 +243,11 @@ void env_relocate (void) #endif env_crc_update (); gd->env_valid = 1; +#ifdef CFG_ENV_AUTOSAVE
gd->env_addr = (ulong)&(env_ptr->data);puts ("Saving environment\n");saveenv ();+#endif } else { env_relocate_spec ();
I'll point some problem that could appear with some flash that need to drive some pio before write or erase the flash due to VPP protection
that´s one of the reasons why I am asking - I only tested this with my environment being in flash (handled by env_flash.c), and here my impression was that all such mechanisms should be handled by saveenv() internally (calling flash_sect_protect() etc.).
If you want to add an autosave you may need to add a pre-save and post-save mecanism
Hmm... I just looked in cmd_nvedit.c, and there is nothing else visible when saveenv() is called. How would these pre-save and post-save things supposed to be handled from the regular command-line interface?
and I'll prefer CONFIG_ENV_AUTOSAVE than CFG_ENV_AUTOSAVE.
Sorry for that, obviously you are correct, I was confused by the CFG_REDUNDAND_ENVIRONMENT some lines above.
Best Regards, J.
Regards, Wolfgang
w.wegner@astro-kom.de writes:
I just had the problem of fw_{print,save}env not being able to access the environment because I was using the default (builtin) environment after flashing U-Boot. I wonder if I am the only one having this problem, or is it common practice to flash the environment together with U-Boot during production?
I just made this small patch to auto-save the environment if it is not found in flash but am wondering if
- I missed something and such a possibility does already exist? (I could not find a possibility to check from the command-line if the current environment comes from flash or is the built-in default environment, else it would be easier to make a script check and call saveenv before booting.)
AFAIK there is currently no way to check this from the U-Boot shell. Nevertheless I think that would be the way to go instead of hard-coding this. How about setting an environment variable like "env_default" if the default environment is used? That way scripts can be used to run saveenv but could also do more complex initialization.
Best regards
Markus Klotzbuecher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
On 25 Mar 2008 at 17:00, Markus Klotzbücher wrote:
w.wegner@astro-kom.de writes:
I just had the problem of fw_{print,save}env not being able to access the environment because I was using the default (builtin) environment after flashing U-Boot.
[...]>
AFAIK there is currently no way to check this from the U-Boot shell. Nevertheless I think that would be the way to go instead of hard-coding this. How about setting an environment variable like "env_default" if the default environment is used? That way scripts can be used to run saveenv but could also do more complex initialization.
This seems to be the cleanest solution to me - and the easiest, too, because no patching of U-Boot is required. I just did not think about the possibilty to un-set the environment variable when this initialization is run to make it a one-shot run... 8)
Best regards
Markus Klotzbuecher
Thank you and best regards, Wolfgang
In message 873aqedcak.fsf@denx.de you wrote:
AFAIK there is currently no way to check this from the U-Boot shell. Nevertheless I think that would be the way to go instead of hard-coding this. How about setting an environment variable like "env_default" if the default environment is used? That way scripts can be used to run saveenv but could also do more complex initialization.
There are certain things I recommend never to do automatically. Erasing and overwriting vital parts of the flash belong to these. Don't do it. Leave the decision when and how often to do that to something that claims to have a brain.
Best regards,
Wolfgang Denk
Hello,
in message 47E90DE8.15445.1113A3A@w.wegner.astro-kom.de you wrote:
I just had the problem of fw_{print,save}env not being able to access the environment because I was using the default (builtin) environment after flashing U-Boot. I wonder if I am the only one having this problem, or is it common practice to flash the environment together with U-Boot during production?
Quite a number of boards use an embedded environment which gets auto-installed when programming the U-Boot image. And a significant percentage of boards I know use some installation tool that will set up things like serial number, MAC addresses etc. one way or another, andin many cases this includes running "saveenv".
I just made this small patch to auto-save the environment if it is not found in flash but am wondering if
- I missed something and such a possibility does already exist?
No, and I strongly discourage it. It just makes detection of certain types of problems / hardware errors etc. more difficult or even impossible.
- something similar might be worth considering as a new regular feature?
I think I would oppose such a change because I consider it really dangerous.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Tue, Mar 25, 2008 at 09:16:13PM +0100, Wolfgang Denk wrote:
Quite a number of boards use an embedded environment which gets auto-installed when programming the U-Boot image. And a significant percentage of boards I know use some installation tool that will set up things like serial number, MAC addresses etc. one way or another, andin many cases this includes running "saveenv".
with "installation tool" you mean any kind of interaction from the U-Boot command prompt, correct? (Just for clarification on my side) In my current application there (unfortunately) there is no hardware serial number anyways, and no ethernet, so no data that would have to be set for each device seperately.
I just made this small patch to auto-save the environment if it is not found in flash but am wondering if
- I missed something and such a possibility does already exist?
No, and I strongly discourage it. It just makes detection of certain types of problems / hardware errors etc. more difficult or even impossible.
- something similar might be worth considering as a new regular feature?
I think I would oppose such a change because I consider it really dangerous.
I think I get your point here, and especially as now Markus pointed me to a possible solution just using the command shell I perfectly agree that having it built-in like in my patch is just a source of possible problems, not needed and thus not a good idea.
On the other hand (and taking into account your answer to Markus), sometimes an automatic approach might have its use, too:
On our board we have an FPGA, and for different applications a different FPGA file shall be loaded without updating the firmware. For this, the application has to set an U-Boot environment variable that specifies which FPGA file to load on next boot. But, I do not want the application to mess around with the building the complete environment, instead, it shall just modify the existing variables. So, as I trust U-Boot more than my application, I want U-Boot to always initialize the environment stored in flash, and have the application just update the single variable - but this implies that even if the application failed during updating the environment (be it because of a software fault or power failure or whatever reason), U-Boot has to re-write this on the next power-up in case it detects the flash environment is invalid.
I think there may also be different opinions about which is the best solution here, but especially because the environment holds vital data like bootcmd etc., for me this looks like the most secure solution although I do not know if U-Boot already claims to have a brain. ;-)
Best regards, Wolfgang
Wolfgang Wegner wrote:
On our board we have an FPGA, and for different applications a different FPGA file shall be loaded without updating the firmware. For this, the application has to set an U-Boot environment variable that specifies which FPGA file to load on next boot.
We use an i2c EEPROM to hold board specific information. I read the EEPROM from U-Boot and set up the MAC address and arch/mach number using the misc_init_r(void) call method. This separates the U-boot environment from the machine specific data. I also use the EEPROM to hold the SDRAM settings so the first bootloader can configure the DRAM on multiple boards without requiring multiple binaries.
I have a strange bootcmd. If U-Boot starts with a corrupted environment, it runs the default bootcmd. The default bootcmd creates a bootcmd and then runs saveenv so the next boot will run the new bootcmd..
eg. from my include/configs/board.h file
"bootcmd=setenv bootcmd '<complex bootcmd here>';saveenv;run bootcmd\0"
I then access the U-Boot environment area from Linux and do all the "smart" stuff there. If I didn't do this, then Linux would access the corrupted boot section!
Just my 0.02 euros worth.
Aras
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Aras Vaichas arasv@magtech.com.au writes:
Wolfgang Wegner wrote:
On our board we have an FPGA, and for different applications a different FPGA file shall be loaded without updating the firmware. For this, the application has to set an U-Boot environment variable that specifies which FPGA file to load on next boot.
We use an i2c EEPROM to hold board specific information. I read the EEPROM from U-Boot and set up the MAC address and arch/mach number using the misc_init_r(void) call method. This separates the U-boot environment from the machine specific data. I also use the EEPROM to hold the SDRAM settings so the first bootloader can configure the DRAM on multiple boards without requiring multiple binaries.
I have a strange bootcmd. If U-Boot starts with a corrupted environment, it runs the default bootcmd. The default bootcmd creates a bootcmd and then runs saveenv so the next boot will run the new bootcmd..
Nice :-) That does the trick without any modifications to the code. Though I have to agree with Wolfgang that this could be potentially dangerous. If for any reason U-Boot went into some kind of endless restart - saveenv loop...
Best regards
Markus Klotzbuecher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
On Tuesday 25 March 2008, w.wegner@astro-kom.de wrote:
I just had the problem of fw_{print,save}env not being able to access the environment because I was using the default (builtin) environment after flashing U-Boot.
if you're using an embedded env, then the default crc should be correct. i'd address that bug first before trying to hack around it on the board.
note: there are known problems with crc generation on the build system when it isnt the same endian/bitsize as the target. -mike
In message 200803260051.24681.vapier@gentoo.org you wrote:
note: there are known problems with crc generation on the build system when it isnt the same endian/bitsize as the target.
What sort of problems is this?
We use x86 (= LE) for build systems, and CRC generation works fine both for LE tyargets like ARM and MIP and for BE ones like Power - what exactly do you mean?
Best regards,
Wolfgang Denk
On Wednesday 26 March 2008, Wolfgang Denk wrote:
In message 200803260051.24681.vapier@gentoo.org you wrote:
note: there are known problems with crc generation on the build system when it isnt the same endian/bitsize as the target.
What sort of problems is this?
We use x86 (= LE) for build systems, and CRC generation works fine both for LE tyargets like ARM and MIP and for BE ones like Power - what exactly do you mean?
i'll have to double check the endian (istr it being broken), but bitness is most definitely broken. this issue was posted over a year and a half ago.
tools/envcrc.c does sizeof(unsigned long) using the host compiler. if the host is 64bit, that is "8". if the target is 32bit, that is "4". not going to work. -mike
In message 200803261049.47563.vapier@gentoo.org you wrote:
i'll have to double check the endian (istr it being broken), but bitness is most definitely broken. this issue was posted over a year and a half ago.
tools/envcrc.c does sizeof(unsigned long) using the host compiler. if the host is 64bit, that is "8". if the target is 32bit, that is "4". not going to work.
Agreed, that is indeed a problem. Please submit a patch :-)
But there should be no endianess issues.
Best regards,
Wolfgang Denk
On Wednesday 26 March 2008, Wolfgang Denk wrote:
In message 200803261049.47563.vapier@gentoo.org you wrote:
i'll have to double check the endian (istr it being broken), but bitness is most definitely broken. this issue was posted over a year and a half ago.
tools/envcrc.c does sizeof(unsigned long) using the host compiler. if the host is 64bit, that is "8". if the target is 32bit, that is "4". not going to work.
Agreed, that is indeed a problem. Please submit a patch :-)
posted
But there should be no endianess issues.
next time i see troubles on my ppc->blackfin, i'll investigate -mike
participants (7)
-
Aras Vaichas -
Jean-Christophe PLAGNIOL-VILLARD -
Markus Klotzbücher -
Mike Frysinger -
w.wegner＠astro-kom.de -
Wolfgang Denk -
wolfgang＠leila.ping.de