[U-Boot] [u-boot]automatic reset of variables to defaults

[U-Boot] [u-boot]automatic reset of variables to defaults

[Dennis Borgmann]

Hello u-boot users list,

I am experiencing a problem concerning variables being set and later 
getting lost.

In order to boot a Linux on a quite small plattform (Eddy CPU: 
http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I 
have to reset the variable "OS_SDRAM" from its initial value of 
"0x20000000" to "0x21000000". If I don't do so, the bootloader reports 
problems extracting my kernel. This must be due to my kernel being 
bigger than expected by u-boot.

These are the steps, that I take:

[code]
setenv OS_SDRAM 0x21000000
saveenv
reset
[/code]

Anyway, this way, it works fine.

Sometimes, the bootloader looses this configuration and resets its 
variable "OS_SDRAM" back to its default value. Once, the bootloader has 
reset this value, it cannot boot anymore(well, of course not, since I 
had to manually alter this value in order to make it boot my linux).

Annoyingly, I cannot surely reproduce this error. I tried rebooting it 
over 3 days in 2-minute-steps and the error won't occur. In addition, I 
tried giving random input to the console of u-boot for 3 days (again in 
2-minute-steps) and still the error won't come up.

Two questions:

1. What else might be the cause of this?

2. How could I prevent u-boot from resetting to its default value?

I'd be happy for any kind of help.

Best regards,
Dennis

[U-Boot] [u-boot]automatic reset of variables to defaults

[Jerry Van Baren]

On 11/17/2011 10:46 AM, Dennis Borgmann wrote:
> Hello u-boot users list,
>
> I am experiencing a problem concerning variables being set and later
> getting lost.

This sounds like your environment variables in flash got erased or 
corrupted.  The question is why.

Where is your u-boot env being saved?  Normal flash?  I2C-attached 
flash?  Other?  (I2C flash is inherently less robust than we like due to 
weaknesses in the protocol.)

I am assuming normal flash...
* Do you have flash write protection enabled (prevents inadvertent flash 
scribbling, especially a problem if your linux or programs are not stable).

* Do you understand your flash memory layout (can you draw a diagram of 
it)?  Is something like a flash file system inadvertently overlayed on 
top of the u-boot env?  If you have a flash file system inadvertently 
configured to use the same memory space as your u-boot env, it will 
"randomly" overwrite it based on file activity.

* Do you use linux utilities to read/write your u-boot env?

When the failure occurs, what does the memory dump of the actual u-boot 
flash storage area look like?  Quite often the overwrite pattern leaves 
valuable clues as to who did it.

* If it is all 0xFF, someone just erased it.

* If some bits are set to zero that should be ones, someone probably did 
an inadvertent write to the memory (writing a '0' to a '1' bit turns it 
to a '0', writing a '0' or '1' to a '0' bit doesn't change it).

* Does it look like file data?

[snip]

> Annoyingly, I cannot surely reproduce this error. I tried rebooting it
> over 3 days in 2-minute-steps and the error won't occur. In addition, I
> tried giving random input to the console of u-boot for 3 days (again in
> 2-minute-steps) and still the error won't come up.

We've all been there and feel your pain. :-(

> Two questions:
>
> 1. What else might be the cause of this?

Someone (likely software, possibly hardware) is corrupting or erasing 
your u-boot env storage in flash.

> 2. How could I prevent u-boot from resetting to its default value?

Fix whoever is doing the scribbling.  There is no other way.

> I'd be happy for any kind of help.
>
> Best regards,
> Dennis

Good luck,
gvb

[U-Boot] [u-boot]automatic reset of variables to defaults

[Dennis Borgmann]

Hello Wolfgang, Marek and Jerry!
Hello u-boot list!

I will try to answer all of your questions.

The version that is present on the board is:

U-Boot> version
U-Boot 2008.10-rc3 (Sep  3 2009 - 18:30:12)

The CPU is a AT91SAM9260 built on an "Eddy-Board" from a company named 
SystemBase: 
http://eng.sysbas.com/e-Products/default3.asp?sNum=4&oNum=55&uNum=80

The error occurrs on both the Eddy V2.1(AT91SAM9260) and the Eddy 
V2.5(AT91SAM9G20).

Regarding your question, what the exact circumstances are - well, we 
don't know. As I said before, we can't reproduce the problem. We sold 
the device as part of a product and every now and then we get some 
systems returned. The error message upon booting is:

Hit any key to stop autoboot:  1 \b\b\b 0
Error: inflate() returned -3
GUNZIP: uncompress or overwrite error - must RESET board to recovery

This is the very same error, that I get, if I don't set the variable 
"OS_SDRAM" to "0x21000000", but leave it as default to "0x20000000" - 
which is, what happens to thos device not booting anymore - they simply 
have this variable being reset to default and are not booting because of 
this reason.

The Flash memory is an ATMEL AT45db642d, check this datasheet: 
http://www.atmel.com/dyn/resources/prod_documents/doc3542.pdf

If the flash is protected, I have to answer "no" as this info seems to 
state this:

U-Boot> flinfo
DataFlash:AT45DB642
Nb pages:   8192
Page Size:   1056
Size= 8650752 bytes
Logical address: 0xD0000000
Area 0:            D0000000 to D0001FFF      Bootstrap
Area 1:            D0002000 to D0002FFF      Environment
Area 2:            D0003000 to D003FFFF      U-Boot
Area 3:            D0040000 to D027FFFF      Kernel
Area 4:            D0280000 to D06FFFFF      FS
Area 5:            D0700000 to D083FFFF      CF
U-Boot>

I do not have any detailed idea about the setup of the flash memory 
layout. To be honest, we purchased this board and used it. After 
installing our own version of Linux(we had to adapt several things from 
the original one given by the manufacturer of the board), the only way 
to make the system boot was to reset the variable OS_SDRAM from 
"0x20000000" to "0x21000000". As Wolfgang already stated, this does not 
seem to be a mainline u-boot - which we were not aware of. We honestly 
did not really care about u-boot so far, we just used it and it was 
running the way we wanted it. I cannot get into detail of every software 
that I use, and since it worked after adapting the environment variable, 
I did not care anymore. And anyway - it basically runs. After three 
months, we had the first problem, so this problem is not occurring that 
often - but it happens. So since it passed our tests, there was no point 
for me to get into deep details of u-boot :-) But sadly, this seems to 
be something, that I need to get into...

We are not using any Linux utils to write to the u-boot env. We are just 
flashing the device via tftp, setting the environment variable mentioned 
above via a serial terminal and that's it. this is the way, we set the 
variable:

U-Boot> setenv OS_SDRAM 0x21000000
U-Boot> saveenv
U-Boot> reset

Concerning a memory dump - well, first of all, I don't even know how to 
produce such a dump and secondly, I actually don't have a malfunctioning 
device here, so I cannot perform a dump right now. As soon as I get the 
problem being reproduced, I could of course supply this list with a 
dump, but as I said before - so far I was not able to reproduce the error...

I hope, this answers all the important questions needed to get on with 
solving my problem. I really appreciate your help!

Thanks very much in advance,
Dennis





Am 17.11.2011 19:26, schrieb Jerry Van Baren:
> On 11/17/2011 10:46 AM, Dennis Borgmann wrote:
>> Hello u-boot users list,
>>
>> I am experiencing a problem concerning variables being set and later
>> getting lost.
>
> This sounds like your environment variables in flash got erased or 
> corrupted.  The question is why.
>
> Where is your u-boot env being saved?  Normal flash?  I2C-attached 
> flash?  Other?  (I2C flash is inherently less robust than we like due 
> to weaknesses in the protocol.)
>
> I am assuming normal flash...
> * Do you have flash write protection enabled (prevents inadvertent 
> flash scribbling, especially a problem if your linux or programs are 
> not stable).
>
> * Do you understand your flash memory layout (can you draw a diagram 
> of it)?  Is something like a flash file system inadvertently overlayed 
> on top of the u-boot env?  If you have a flash file system 
> inadvertently configured to use the same memory space as your u-boot 
> env, it will "randomly" overwrite it based on file activity.
>
> * Do you use linux utilities to read/write your u-boot env?
>
> When the failure occurs, what does the memory dump of the actual 
> u-boot flash storage area look like?  Quite often the overwrite 
> pattern leaves valuable clues as to who did it.
>
> * If it is all 0xFF, someone just erased it.
>
> * If some bits are set to zero that should be ones, someone probably 
> did an inadvertent write to the memory (writing a '0' to a '1' bit 
> turns it to a '0', writing a '0' or '1' to a '0' bit doesn't change it).
>
> * Does it look like file data?
>
> [snip]
>
>> Annoyingly, I cannot surely reproduce this error. I tried rebooting it
>> over 3 days in 2-minute-steps and the error won't occur. In addition, I
>> tried giving random input to the console of u-boot for 3 days (again in
>> 2-minute-steps) and still the error won't come up.
>
> We've all been there and feel your pain. :-(
>
>> Two questions:
>>
>> 1. What else might be the cause of this?
>
> Someone (likely software, possibly hardware) is corrupting or erasing 
> your u-boot env storage in flash.
>
>> 2. How could I prevent u-boot from resetting to its default value?
>
> Fix whoever is doing the scribbling.  There is no other way.
>
>> I'd be happy for any kind of help.
>>
>> Best regards,
>> Dennis
>
> Good luck,
> gvb

[U-Boot] [u-boot]automatic reset of variables to defaults

[Dennis Borgmann]

Hello u-boot users list,

I am experiencing a problem concerning variables being set and later 
getting lost.

In order to boot a Linux on a quite small plattform (Eddy CPU: 
http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I 
have to reset the variable "OS_SDRAM" from its initial value of 
"0x20000000" to "0x21000000". If I don't do so, the bootloader reports 
problems extracting my kernel. This must be due to my kernel being 
bigger than expected by u-boot.

These are the steps, that I take:

[code]
setenv OS_SDRAM 0x21000000
saveenv
reset
[/code]

Anyway, this way, it works fine.

Sometimes, the bootloader looses this configuration and resets its 
variable "OS_SDRAM" back to its default value. Once, the bootloader has 
reset this value, it cannot boot anymore(well, of course not, since I 
had to manually alter this value in order to make it boot my linux).

Annoyingly, I cannot surely reproduce this error. I tried rebooting it 
over 3 days in 2-minute-steps and the error won't occur. In addition, I 
tried giving random input to the console of u-boot for 3 days (again in 
2-minute-steps) and still the error won't come up.

Two questions:

1. What else might be the cause of this?

2. How could I prevent u-boot from resetting to its default value?

I'd be happy for any kind of help.

Best regards,
Dennis

[U-Boot] [u-boot]automatic reset of variables to defaults

[Wolfgang Denk]

Dear Dennis Borgmann,

In message <4EC52BD7.2090202@googlemail.com> you wrote:
> 
> I am experiencing a problem concerning variables being set and later 
> getting lost.

It is impossible to comment on this without knowing _anything_ about
your system - which exact version of U-boot you are running
(well, obviously it is an ot-of-tree port, so it's twice impossible to
help), which CPU / SoC tthis is, which board, etc.

> These are the steps, that I take:
> 
> [code]
> setenv OS_SDRAM 0x21000000

This makes no sense to me, as none of the mainline versions of U-Boot
uses such a setting.

> Sometimes, the bootloader looses this configuration and resets its 
> variable "OS_SDRAM" back to its default value. Once, the bootloader has 

What are the exact circumstances and especially the exct error
messages when this happens?

Where is the environment stored on your board? [In NOR or NAND flash
or ... ?]

Are you using redundant environment?

> 1. What else might be the cause of this?

We don't know your code, so how could we comment?

> 2. How could I prevent u-boot from resetting to its default value?

We don;t understand the nature of the problem, so how could we
recommend a cure?

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
HANDLE WITH EXTREME CARE:  This Product Contains  Minute Electrically
Charged  Particles  Moving  at  Velocities  in Excess of Five Hundred
Million Miles Per Hour.

[U-Boot] [u-boot]automatic reset of variables to defaults

[Marek Vasut]

> Hello u-boot users list,
> 
> I am experiencing a problem concerning variables being set and later
> getting lost.
> 
> In order to boot a Linux on a quite small plattform (Eddy CPU:
> http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I
> have to reset the variable "OS_SDRAM" from its initial value of
> "0x20000000" to "0x21000000". If I don't do so, the bootloader reports
> problems extracting my kernel. This must be due to my kernel being
> bigger than expected by u-boot.
> 
> These are the steps, that I take:
> 
> [code]
> setenv OS_SDRAM 0x21000000
> saveenv
> reset
> [/code]
> 
> Anyway, this way, it works fine.
> 
> Sometimes, the bootloader looses this configuration and resets its
> variable "OS_SDRAM" back to its default value. Once, the bootloader has
> reset this value, it cannot boot anymore(well, of course not, since I
> had to manually alter this value in order to make it boot my linux).
> 
> Annoyingly, I cannot surely reproduce this error. I tried rebooting it
> over 3 days in 2-minute-steps and the error won't occur. In addition, I
> tried giving random input to the console of u-boot for 3 days (again in
> 2-minute-steps) and still the error won't come up.

Probably something's overwriting your uboot in ram. Anyway, is the board 
supported mainline?

> 
> Two questions:
> 
> 1. What else might be the cause of this?
> 
> 2. How could I prevent u-boot from resetting to its default value?
> 
> I'd be happy for any kind of help.
> 
> Best regards,
> Dennis

Try getting mainline support for the board, that way you'll have the latest 
fixes.

M