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
Dear Dennis Borgmann,
Quoted 3 lines · In message <[email protected]> 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.
Quoted 4 lines
These are the steps, that I take:
[code]
setenvOS_SDRAM0x21000000
This makes no sense to me, as none of the mainline versions of U-Boot uses such a setting.
Quoted 2 lines
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?
Quoted 1 line
1. What else might be the cause of this?
We don't know your code, so how could we comment?
Quoted 1 line
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
Signature · 6 lines
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.
Quoted 27 lines
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]
setenvOS_SDRAM0x21000000
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 bootanymore(well, of course not, since I had to manually alter this value in order to make it boot my linux).
Quoted 4 lines
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?
Quoted 11 lines
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