[U-Boot] [u-boot]automatic reset of variables to defaults
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
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:
- What else might be the cause of this?
Someone (likely software, possibly hardware) is corrupting or erasing your u-boot env storage in flash.
- 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
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:
- What else might be the cause of this?
Someone (likely software, possibly hardware) is corrupting or erasing your u-boot env storage in flash.
- 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
participants (2)
-
Dennis Borgmann -
Jerry Van Baren