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.
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
