
On 08/01/2013 03:53 AM, Stefano Babic wrote:
Hi Dennis,
On 01/08/2013 01:27, Robert Nelson wrote:
kernel_boot=echo Trying kernel...; ${fs}load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}vmlinuz && ${fs}load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr} script_boot=echo Trying script images...; for script in ${boot_scripts}; do ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}${script} && echo Executing ${prefix}${script}... && source ${script_addr}; done; env_boot=echo Trying environment file...; ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}uEnv.txt && Executing ${prefix}uEnv.txt... && env import -t ${script_addr} ${filesize}};
Guys, this is just silly.. Your using both uEnv.txt/boot.scr scripts by default, which you could use to "hide" all this extra stuff in a text file on the boot drive, that way mainline u-boot doesn't have to be patched for every little change. ;)
I know it's bikeshedding, but most boards can be converted to just:
#define CONFIG_BOOTCOMMAND \ "mmc dev ${mmcdev};" \ "if mmc rescan; then " \ "echo SD/MMC found on device ${mmcdev};" \ "if run loadbootenv; then " \ "run importbootenv;" \ "fi;" \ "if test -n $uenvcmd; then " \ "echo Running uenvcmd ...;" \ "run uenvcmd;" \ "fi;" \ "if run loadsomefailsafedefault; then " \ "run mmcboot;" \ "fi;" \ "fi;" #endif
That really works great on boards that don't have SD...
Right - the meaning of CONFIG_EXTRA_ENV_SETTINGS is to have a minimal default environment, allowing the user to extend it to a full blown adding whatever he wants. However, in the last times I see that the meaning is moving to *the environment*. There is something wrong, also because, as Robert says, each small change require to patch u-boot. But then, why do you need the environment at all ?
And the setup is then suitable for a strict range of applications, but not all.
You both are missing the point. This patch doesn't address the problem, but does highlight it. The distros want to get out of having to know the u-boot environment details for every single board and need some level of standardization across platforms. The distros should only have to specify "boot the kernel at path/name X on device Y." They should not need to know what address to load the kernel to, but only that $kernel_addr_r is already setup. Variables are the first step. The second step is standardizing the boot commands.
Rob