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

Eric Nelson eric.nelson at boundarydevices.com
Wed Feb 19 20:02:22 CET 2014


On 02/19/2014 11:57 AM, Stephen Warren wrote:
> 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 at 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.

+1

Scripts have the benefit of putting everything into a relatively
easy-to-read form that only uses documented U-Boot commands, not
board-specific constructs.



More information about the U-Boot mailing list