[U-Boot-Users] auto-save environment if using default environment?

[U-Boot-Users] auto-save environment if using default environment?

[w.wegner at astro-kom.de]

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 ();

[U-Boot-Users] auto-save environment if using default environment?

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:36 Tue 25 Mar     , w.wegner at 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.

[U-Boot-Users] auto-save environment if using default environment?

[w.wegner at astro-kom.de]

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

[U-Boot-Users] auto-save environment if using default environment?

[Markus Klotzbücher]

w.wegner at 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 at denx.de

[U-Boot-Users] auto-save environment if using default environment?

[w.wegner at astro-kom.de]

On 25 Mar 2008 at 17:00, Markus Klotzb?cher wrote:

> 
> w.wegner at 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

[U-Boot-Users] auto-save environment if using default environment?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Vulcans believe peace should not depend on force.
	-- Amanda, "Journey to Babel", stardate 3842.3

[U-Boot-Users] auto-save environment if using default environment?

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Genitiv ins Wasser, weil's Dativ ist!

[U-Boot-Users] auto-save environment if using default environment?

[Wolfgang Wegner]

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

[U-Boot-Users] auto-save environment if using default environment?

[Aras Vaichas]

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 
______________________________________________________________________

[U-Boot-Users] auto-save environment if using default environment?

[Markus Klotzbücher]

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 at denx.de

[U-Boot-Users] auto-save environment if using default environment?

[Mike Frysinger]

On Tuesday 25 March 2008, w.wegner at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080326/7ff15f04/attachment.pgp 

[U-Boot-Users] auto-save environment if using default environment?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If anything can go wrong, it will."                   - Edsel Murphy

[U-Boot-Users] auto-save environment if using default environment?

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080326/ee11ad63/attachment.pgp 

[U-Boot-Users] auto-save environment if using default environment?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
An age is called Dark not because  the  light  fails  to  shine,  but
because people refuse to see it.           -- James Michener, "Space"

[U-Boot-Users] auto-save environment if using default environment?

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080330/9bf26182/attachment.pgp