On 08/14/2014 01:59 PM, Alexander Holler wrote:
Am 14.08.2014 21:51, schrieb Stephen Warren:
On 08/14/2014 01:38 PM, Alexander Holler wrote:
Am 14.08.2014 17:49, schrieb Stephen Warren:
On 08/14/2014 02:25 AM, Alexander Holler wrote:
As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt.
It's easily done with something like the following:
"env import -t -r $loadaddr$filesize;" \ "if test -n "$uenvcmd"; then " \ "echo "Running uenvcmd ...";" \ "run uenvcmd;" \ "fi;" \
My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts.
Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have).
For such presumably non-standard things, why can't the user simply edit $bootcmd, and pre-pend whatever they want?
Depends on when the bootcmd will be constructed. Usually that is done after having read uEnv.txt to include variables defined in uEnv.txt in bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be overwritten.
What would over-write bootcmd? None of the boards I've looked at auto-generates bootcmd. bootargs perhaps (which is a string passed to the kernel) but not bootargs (which is a U-Boot command sequence that U-Boot executes automatically at boot).
If some board does auto-generate bootcmd, I'd suggest that it not. The static bootcmd could execute some kind of user-(or uenv-)set variable and/or the auto-generation of bootcmd could happen before uenv.txt was pulled in, so that whatever was in uenv.txt would have ultimate "power".