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.