From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Mon, 11 Aug 2014 20:42:24 +0200 Subject: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd In-Reply-To: <53E905AC.9050903@wwwdotorg.org> References: <1406759836-556-1-git-send-email-swarren@wwwdotorg.org> <53E25145.2090706@wwwdotorg.org> <53E4F400.6060508@wwwdotorg.org> <53E63816.60703@redhat.com> <53E6A3FE.6080807@myspectrum.nl> <53E6E2D0.7090303@wwwdotorg.org> <53E7A3A2.80707@myspectrum.nl> <53E8F50A.1060606@wwwdotorg.org> <53E90294.7060604@myspectrum.nl> <53E905AC.9050903@wwwdotorg.org> Message-ID: <53E90E90.4020204@myspectrum.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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