[U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd

[Jeroen Hofstee]

Hello Stephen.

On 11-08-14 20:04, Stephen Warren wrote:
> On 08/11/2014 11:51 AM, Jeroen Hofstee wrote:
>> Hello Stephan
>>
>> On 11-08-14 18:53, Stephen Warren wrote:
>>> On 08/10/2014 10:53 AM, Jeroen Hofstee wrote:
>>>> Hello Stephan,
>>>>
>>>> On 10-08-14 05:11, Stephen Warren wrote:
>>>>> The entire point of this series is to prevent distros from having to
>>>>> install bootloader-specific boot configuration files.
>>> >
>>>> I fail to see why this is something to pursue. Since the distro knows
>>>> the boot path, why should u-boot be polling all possible options?
>>>
>>> This patch series allows U-Boot to find the OS and boot it. U-Boot is
>>> searching for some kind of boot configuration file.
>>>
>>> This part of the process is the same as the BIOS searching all known
>>> possible boot devices for a partition marked bootable, and with a
>>> valid MBR. Or, it's the same as UEFI searching all possible boot
>>> devices for whatever config file or boot binary is mandated by UEFI.
>>
>> Not in my mind, I am not against scanning the possible
>> boot devices, on the contrary, I am trying to add booting
>> the userland from usb instead of mmc for the rpi_b.
>
> The following will tell U-Boot to only search USB for extlinux.conf.
>
> setenv boot_targets usb
>
> (you can put this into /uEnv.txt on the SD card if you want to avoid 
> editing U-Boot source code to make this change; there's no persistent 
> environment storage on the Pi, at least at the moment)
>

I am going to give up soon commenting on this. It is
applied anyway. My point is that I am making an image
without an extlinux.conf, I know that, I could tell it in a
boot.scr but yet this scripts now insist on searching for
extlinux.conf. Resulting in that I am tempted not to use
the script at all. The rpi_b is a bit different, but if u-boot
was in NAND e.g. you likely endup with a u-boot not polling
for extlinux.conf at all, since the downstream board vendor
also thought it is annoying startup delay / noise. So placing
it in uEnv is in general too late, since it already polled
several boot devices for extlinux.

> > The
>> part I dislike is where it starts searching for specific files.
>> The equivalent would be your BIOS actively searching for GRUB,
>> LILO, Windows Boot manager etc. etc. and as a fallback
>> try the MBR.
> ...
>>> Once U-Boot locates extlinux.conf or boot.scr, that file encodes what
>>> files (kernel, DTB, initrd)
>>
>> This is the part I get for free now with it, I don't really like it,
>> since if we take this road it ends up looking for e.g. grub.conf,
>> ubldr.conf, vxworks.conf etc etc.
>
> No, Linux distros need to be able to install a single bootloader 
> configuration file to tell the bootloader how to boot.

Don't understand this, I though extlinux is yet another
chainloaded bootloader? I doubt there is "the bootloader".
I don't understand why it needs a single bootloader. It gets
in handy if the last bootloader is known, but I don't even see
why that is required.


> I definitely don't want to add support for a ton of other bootloader 
> configuration file formats. There needs to be a single standard that 
> distros know they can rely on.
>

Well you added the first auto polled chainloaded
bootloader, this simply paves the way for adding more.

>> Also in this case the downstream provides information back,
>> albeit tiny, it does indicate if it is bootable and a label to explain
>> what is bootable.
>
> I don't understand what that means.

As I tried to explain before, if you just add a boot.scr indicating this
is a extlinux image and how such a image should be booted, u-boot
can pick this up, instead of doing this poll for everything approach.

Regards,
Jeroen