On 02/19/2014 01:02 PM, Eric Nelson wrote:
> 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 <den...@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.
>

Oh don't get me wrong I agree with having the scripts.

Just sayin we should not rely on the scripts being there and mandating their 
usage.
We may want to have a fall back to a known good tested configuration.

Dan

-- 
------------------
Dan Murphy

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to