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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
