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

[Stephen Warren]

On 08/11/2014 12:42 PM, Jeroen Hofstee wrote:
> 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.

That's because you are an individual crafting your own installation 
manually. The whole point of this feature is to allow distros to be 
completely generic, i.e. they work in the exact same way on all HW (that 
supports this feature, which hopefully will be most ARM boards soon...).

> 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.

I don't think the location of U-Boot (NAND or otherwise) impacts this 
feature. It's all about what happens after U-Boot has started, and is 
searching for an OS.

>> > 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.

This is obviously where the disconnect is...

extlinux is (IIRC) a bootloader yes. However, this patch isn't about 
extlinux, but extlinux.conf.

extlinux.conf is a text file format the defines a menu of bootable OSs. 
It's a (de-facto I suppose) standard that's implemented by extlinux (if 
indeed that is a piece of SW:-) and also U-Boot and barebox and likely 
other bootloaders too.

So, when U-Boot locates extlinux.conf on disk and processes it, it's 
parsing a configuration file/menu, not chain-loading/executing another 
bootloader.

An example extlinux.conf that I use for network booting is:

TIMEOUT 100

MENU TITLE TFTP boot options

LABEL sdcard
         MENU LABEL ../zImage, root on 2GB sdcard
         LINUX ../zImage
         FDTDIR ../
         APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait 
rw earlyprintk root=PARTUUID=b2f82cda-2535-4779-b467-094a210fbae7

LABEL venice2-emmc
         MENU LABEL ../zImage root on Venice2 eMMC
         LINUX ../zImage
         FDTDIR ../
         APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait 
rw earlyprintk root=PARTUUID=5f71e06f-be08-48ed-b1ef-ee4800cc860f

LABEL seaboard-emmc
         MENU LABEL ../zImage root on Seaboard eMMC
         LINUX ../zImage
         FDTDIR ../
         APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait 
rw earlyprintk root=PARTUUID=cf7b2cdf-df49-45c6-91bf-59ab82d7bfed

LABEL fedora-installer-zk
         MENU LABEL Fedora installer w/ ../zImage
         LINUX ../zImage
         INITRD fedora-installer/initrd.img
         FDTDIR ../
         APPEND loglevel=8 earlyprintk ip=dhcp 
inst.repo=http://10.20.204.51/mirrors/fedora/linux/development/rawhide/armhfp/os/ 
rd.shell

LABEL fedora-installer-fk
         MENU LABEL Fedora installer w/ Fedora kernel
         LINUX fedora-installer/vmlinuz
         INITRD fedora-installer/initrd.img.orig
         FDTDIR fedora-installer/dtb
         APPEND loglevel=8 ip=dhcp 
inst.repo=http://10.20.204.51/mirrors/fedora/linux/development/rawhide/armhfp/os/ 
rd.shell cma=64M

LABEL uImage
         MENU LABEL ../uImage, root on 2GB sdcard
         LINUX ../uImage
         FDTDIR ../
         APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait 
rw earlyprintk root=PARTUUID=b2f82cda-2535-4779-b467-094a210fbae7

>> 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.

That would require all Linux distros to have specific support to install 
boot.scr, which is a bootloader-specific format script file. Systems 
that boot using e.g. Barebox or other bootloaders presumably can't 
process boot.scr. However, if all bootloaders end up supporting 
extlinux.conf, the distro won't care what bootloader is on the HW.