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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
