[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  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