[U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Rob Herring]

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