Hi,
For the rescue SD Jason is working on we need to find a way to ignore the env in NAND. We can up with two options:
1) have rescue uboot always ignore env
2) have rescue uboot only ignore env if user button is pressed
So, what do you all think?
regards,
Koen
2010/7/23 Koen Kooi <koen@beagleboard.org>
Hi,
For the rescue SD Jason is working on we need to find a way to ignore the env in NAND. We can up with two options:
- have rescue uboot always ignore env
- have rescue uboot only ignore env if user button is pressed
So, what do you all think?
I am leaning towards 1)
alternate could be:
3) have rescude u-boot ignore env if user button is not pressed (so ignore is the default)
Frans
I like the suggested 3)
As a newbie user who mangled his NAND and took a day to sort it I think the most fullproof rescuse system is the one what does not need user input 
Marc
The trouble with 3 is that people are most likely booting into rescue mode by holding down the userbutton. So to go into ignore mode using the on card uboot they would need to push the user button for like 0.1 seconds, which isn't likely going to work. I would fail that test before my first coffee in the morning
regards,
Koen
2010/7/23 Koen Kooi <koen@beagleboard.org>
2010/7/23 Koen Kooi <koen@beagleboard.org>
Hi,For the rescue SD Jason is working on we need to find a way to ignore the env in NAND. We can up with two options:
- have rescue uboot always ignore env
- have rescue uboot only ignore env if user button is pressed
So, what do you all think?
I am leaning towards 1)
alternate could be:
3) have rescude u-boot ignore env if user button is not pressed (so ignore is the default)The trouble with 3 is that people are most likely booting into rescue mode by holding down the userbutton. So to go into ignore mode using the on card uboot they would need to push the user button for like 0.1 seconds, which isn’t likely going to work. I would fail that test before my first coffee in the morning
Ah ok, didn’t realise that. Indeed not a good plan.
But I settled for 1 already 
maybe we should convince Wolfgang to add a readenv command to u-boot, so one can get into u-boot then read the env from the cmd line
Frans
I like the last idea of reading the environment, but it would require changing all the default environments.
The comment about doing nothing is good, but we built the boards to read from NAND flash by default and there is no good way to avoid that than holding the button.
What about going in reverse and adding a command to reset the in
RAM copy of the environment to defaults? This would be less
troubling then finding a version of U-boot in the while that
ignores the environment. Ignoring it is as bad as those versions
floating around with the broken saveenv.
We have to remember how easy it is for new people to get confused. we need a way to get predictable behavior despite whatever is on the NAND flash. your method would still require people to execute commands at the uboot prompt, no?
We have to remember how easy it is for new people to get
confused. we need a way to get predictable behavior despite
whatever is on the NAND flash. your method would still
require people to execute commands at the uboot prompt, no?
No, such a command would let you write a script to do what you
were asking. Instead of it ignoring it, you have the script -
load defaults
save out defaults
and proceed to do what you need.
Then all you need to do is make sure U-boot can run a script if
it is present. WIth this the u-boot can be the same one that is
used for normal use. In addition, it'd give people a simple way
to restore the default config.
We’d need to change all the default boot commands to have them continue working, right? is that something we want to try to take on? shall we call out for comment on the uboot list?
We'd need to change all the default boot commands to have them
continue working, right? is that something we want to try to
take on? shall we call out for comment on the uboot list?
Why would the default boot commands have to be changed so that
there can be a rescue SD card? Part of what I am assuming is
there will also be an addition to make U-boot run an script
unconditionally if it is present. This way, the rescue SDs can
co-exists with the existing SDs.
The same binaries can then also be used for those of us who
prefer to use U-boot in the more traditional way. This way we
won't have a ton of different U-boot's floating around.
We'd need to change all the default boot commands to have them
continue working, right? is that something we want to try to
take on? shall we call out for comment on the uboot list?Why would the default boot commands have to be changed so that
there can be a rescue SD card? Part of what I am assuming is
there will also be an addition to make U-boot run an script
unconditionally if it is present. This way, the rescue SDs can
co-exists with the existing SDs.
I'm just thinking the easiest way to get the script to run is to
change the default boot command to both search for a boot script as
well as checking the NAND flash environment. I guess you could put
that code in the operation outside of the default boot command, but it
sounds a lot more difficult to me. Do you have a suggestion where to
do a patch that does not require changes to the default boot command
and how?
The same binaries can then also be used for those of us who
prefer to use U-boot in the more traditional way. This way we
won't have a ton of different U-boot's floating around.
Agreed.