[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren <swarren@wwwdotorg.org>]

On 02/19/2014 11:52 AM, Dan Murphy wrote:
> On 02/19/2014 12:48 PM, Stephen Warren wrote:
>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>> +#ifdef CONFIG_CMD_USB
>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>>> +#define BOOTCMDS_USB \
>>>> +	"usb_init=" \
>>>> +		"if ${usb_need_init}; then " \
>>>> +			"set usb_need_init false; " \
>>>> +			"usb start 0; " \
>>>> +		"fi\0" \
>>>> +	\
>>>> +	"usb_boot=" \
>>>> +		"setenv devtype usb; " \
>>>> +		BOOTCMD_INIT_USB \
>>>> +		"if usb dev ${devnum}; then " \
>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
>> They would be set in boot.scr or extlinux.cfg on the disk that the
>> system boots from; the kernel cmdline is part of the OS that's installed
>> there, not part of U-Boot. This is why these boot scripts load a
>> script/config-file from the disk which in turn defines which
>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
>> DTB. This approach should even be suitable for booting a non-Linux-OS,
>> with suitable commands in boot.scr.
> 
> But shouldn't the config file just be an override?
> 
> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
> 
> If no config file exists should we not try to default to a known good default tested case?

I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.

Now, specific U-Boot board configs can always add extra stuff on the end
(or start?) of bootcmd in order to do some custom fallbacks or
backwards-compatibility if they want, but I'm certainly not planning on
doing anything like that for Tegra or Raspberry Pi, for example.