Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Hello Stephan, On 11-08-14 20:55, Stephen Warren wrote: snip 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. haha, right that is a funny misunderstanding. Yes, extlinux is indeed a bootloader and I was in the impression you actively searched for it to chainload it. And to make extlinux a requirement for distro support... And as I tried to explain I am not that fond of such an approach in general, and that had nothing to do, as Tom suggested, with booting FreeBSD, it is just the image I encountered searching for it in various places. It remains a badly named file though (for U-boot), but well so be it, I guess. 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. I see, so shouldn't we document then who is in charge of its format at least, before we start making a U-boot/distro specific version of it? snip example file 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. We will see if this works, I am bit skeptical, but it is at least a whole lot better then polling all possible options, where I took the patch for. (Well not all yet, but the start to do so). Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 08/12/2014 11:29 AM, Jeroen Hofstee wrote: On 11-08-14 20:55, Stephen Warren wrote: ... 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. I see, so shouldn't we document then who is in charge of its format at least, before we start making a U-boot/distro specific version of it? The content of the file is documented at: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ ... although extlinux.conf is a single file containing all the entries, rather than a separate *.conf per OS. I'm not sure where that aspect of the file is documented. Dennis, do you know where? FWIW, the concept of a single file rather than many *.conf has been embodied in U-Boot's pxe and sysboot commands for some time, and isn't anything to do with this patch set. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Tue, 12 Aug 2014 19:29:02 +0200 Jeroen Hofstee jer...@myspectrum.nl wrote: Hello Stephan, On 11-08-14 20:55, Stephen Warren wrote: snip 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. haha, right that is a funny misunderstanding. Yes, extlinux is indeed a bootloader and I was in the impression you actively searched for it to chainload it. And to make extlinux a requirement for distro support... And as I tried to explain I am not that fond of such an approach in general, and that had nothing to do, as Tom suggested, with booting FreeBSD, it is just the image I encountered searching for it in various places. It remains a badly named file though (for U-boot), but well so be it, I guess. u-boot in the pxe code has an implementation that parses the syslinux config file. though there really is nothing that says its a linux only thing, admittedly I'm a bit naive as to how things like freebsd boot but i assume you can load a kernel and pass some boot arguments just the same. We are looking for a extlinux.conf file as that's what extlinux looks for and we are mimicking the functionality. 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. I see, so shouldn't we document then who is in charge of its format at least, before we start making a U-boot/distro specific version of it? We are using the same format as is used by the syslinux project. we support a couple of optional items to specify the dtb, fdt and fdtdir, fdt is a location to a devicetree blob and fdtdir is a directory where you can find devicetree blobs. snip example file 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. We will see if this works, I am bit skeptical, but it is at least a whole lot better then polling all possible options, where I took the patch for. (Well not all yet, but the start to do so). Even with checking the different places that we can find the config file. There is no noise, u-boot doesn't print out when there is no files found only when it find them. The time to check for the existence of the file is very quick. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
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. U-Boot performs this searching before having any knowledge of the OS; there's no way for the OS to parameterize this search path, just like OSs don't configure a PC BIOS to search a specific HDD/floppy/CDROM for the MBR to boot. Once U-Boot locates extlinux.conf or boot.scr, that file encodes what files (kernel, DTB, initrd) to load to boot the OS, what kernel command-line to use, etc. This configuration file or script is written by the OS, and is where knowledge such as root filesystem identity may be encoded. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
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 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. 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. U-Boot performs this searching before having any knowledge of the OS; there's no way for the OS to parameterize this search path, just like OSs don't configure a PC BIOS to search a specific HDD/floppy/CDROM for the MBR to boot. Yup as said, this is the part I was looking for. 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. I will have a look if I can tame the script, without modifying it nor u-boot, but I guess that is not possible since boot.scr comes after extlinux not before. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
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) 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. 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. 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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
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
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Mon, Aug 11, 2014 at 12:55:43PM -0600, Stephen Warren wrote: 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...). I suspect the problem here is that you're mentally thinking ... Linux ... and Jeroen's use case is mainly ... Not Linux So this is a step in the right direction, which is why I applied it, but it may need a little tweaking to make it less noisy to support *BSD or VxWorks or ..., which are real users out there for U-Boot and we don't want to forget them. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 08/11/2014 01:19 PM, Tom Rini wrote: On Mon, Aug 11, 2014 at 12:55:43PM -0600, Stephen Warren wrote: 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...). I suspect the problem here is that you're mentally thinking ... Linux ... and Jeroen's use case is mainly ... Not Linux So this is a step in the right direction, which is why I applied it, but it may need a little tweaking to make it less noisy to support *BSD or VxWorks or ..., which are real users out there for U-Boot and we don't want to forget them. FWIW, it'd be easy enough to add an extra for loop into $scan_dev_for_boot so that rather than hard-coding scanning for extlinux first, then scanning for boot.scr, it was configurable the set and/or order it tried them. The user could then edit this in the environment. Just like $bootcmd reads the set of devices from a variable. One could even have a few more defines feed into config_distro_defaults.h that define which types to support, so you could completely remove e.g. extlinux.conf searching from some board configurations if you really wanted, although I think it'd be best to just leave all the options available everywhere, at least until the time when we add some third option that's not generally applicable. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
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? As such, relying exclusively on boot.scr wouldn't be useful. Seems like a logical thing to me, as long as the scripts itself does not have to bother about board details, but is handed those info. If we need to support other OSs, I think it'd be best to extend extlinux.conf to allow it to support booting OSs besides Linux. It is not an OS issue. FWIW, if extlinux.conf isn't found on the media, this patch does fall back to searching for boot.scr (a uImage of a U-Boot script) so it's certainly possible to make custom things happen if you want. Yes, and the order is wrong in my mind. If anything, it should fallback to extlinux, but at least use a general boot.scr first. (or /boot/u-boot.conf or whatever) Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Wed, 06 Aug 2014 10:01:09 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 07/30/2014 04:37 PM, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Simon, are you OK with these patches following the discussion? Dennis, I assume you're OK with the new version of this patch? I am okay with this version. Dennis I assume that your acks would go a long way towards Tom applying this series. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Hi, On 08/08/2014 06:00 PM, Stephen Warren wrote: On 08/07/2014 06:17 PM, Simon Glass wrote: Acked-by: Simon Glass s...@chromium.org For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. I've a bunch of patches relying on this, is there anything stopping this from getting merged ? Reviewed-by: Hans de Goede hdego...@redhat.com Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Sat, Aug 09, 2014 at 05:02:46PM +0200, Hans de Goede wrote: Hi, On 08/08/2014 06:00 PM, Stephen Warren wrote: On 08/07/2014 06:17 PM, Simon Glass wrote: Acked-by: Simon Glass s...@chromium.org For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. I've a bunch of patches relying on this, is there anything stopping this from getting merged ? Reviewed-by: Hans de Goede hdego...@redhat.com Mainly a bug I've just bisected and emailed Masahiro about that's keeping me from building PowerPC on my bigger boxes so I'm having to do it locally. I'll be pushing it all soon. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Hi Hans, On 09-08-14 17:02, Hans de Goede wrote: Hi, On 08/08/2014 06:00 PM, Stephen Warren wrote: On 08/07/2014 06:17 PM, Simon Glass wrote: Acked-by: Simon Glass s...@chromium.org For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. I've a bunch of patches relying on this, is there anything stopping this from getting merged ? Reviewed-by: Hans de Goede hdego...@redhat.com Is it not possible to have a uboot.src or something checking for extlinux. This seems to scale badly if we start to check for Grub, Ubldr, VxWorks etc. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 08/09/2014 04:43 PM, Jeroen Hofstee wrote: On 09-08-14 17:02, Hans de Goede wrote: On 08/08/2014 06:00 PM, Stephen Warren wrote: On 08/07/2014 06:17 PM, Simon Glass wrote: ... Acked-by: Simon Glass s...@chromium.org For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. I've a bunch of patches relying on this, is there anything stopping this from getting merged ? Reviewed-by: Hans de Goede hdego...@redhat.com Is it not possible to have a uboot.src or something checking for extlinux. This seems to scale badly if we start to check for Grub, Ubldr, VxWorks etc. The entire point of this series is to prevent distros from having to install bootloader-specific boot configuration files. As such, relying exclusively on boot.scr wouldn't be useful. If we need to support other OSs, I think it'd be best to extend extlinux.conf to allow it to support booting OSs besides Linux. FWIW, if extlinux.conf isn't found on the media, this patch does fall back to searching for boot.scr (a uImage of a U-Boot script) so it's certainly possible to make custom things happen if you want. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 08/07/2014 06:17 PM, Simon Glass wrote: Acked-by: Simon Glass s...@chromium.org For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 07/30/2014 04:37 PM, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Simon, are you OK with these patches following the discussion? Dennis, I assume you're OK with the new version of this patch? I assume that your acks would go a long way towards Tom applying this series. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Hi Stephen, On 6 August 2014 10:01, Stephen Warren swar...@wwwdotorg.org wrote: On 07/30/2014 04:37 PM, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Simon, are you OK with these patches following the discussion? Dennis, I assume you're OK with the new version of this patch? I looked it through fairly closely as you cleared up my doubts (i.e. we can move the implementation from scripts to a command later if we want without anyone outside U-Boot knowing/caring). I'll take another look. I assume that your acks would go a long way towards Tom applying this series. Thanks. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Hi Stephen Dennis, On 4 August 2014 12:04, Stephen Warren swar...@wwwdotorg.org wrote: On 08/04/2014 04:13 AM, Simon Glass wrote: Hi Stephen, On 31 July 2014 17:00, Stephen Warren swar...@wwwdotorg.org wrote: On 07/31/2014 04:03 PM, Simon Glass wrote: Hi Stephen, On 30 July 2014 23:37, Stephen Warren swar...@wwwdotorg.org wrote: From: Dennis Gilmore den...@ausil.us Thanks for the doc pointers. This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Boards can define the set of devices from which boot is attempted, and the order in which they are attempted. Users may later customize this set/order by edting $boot_targets. Users may interrupt the boot process and boot from a specific device simply by executing e.g.: $ run bootcmd_mmc1 or: $ run bootcmd_pxe This patch was originally written by Dennis Gilmore based on Tegra and rpi_b boot scripts. I have made the following modifications since then: * Boards must define the BOOT_TARGET_DEVICES macro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly in config_distro_bootcmd.h. * Removed $env_import and related variables; nothing used them, and I think it's better for boards to pre-load an environment customization file using CONFIG_PREBOOT if they need. * Renamed a bunch of variables to suit my whims:-) Signed-off-by: Dennis Gilmore den...@ausil.us Signed-off-by: Stephen Warren swar...@nvidia.com I do understand the desirability of getting something sorted in this area. But I am not thrilled with all the macro magic. How does this fit with the new Kconfig setup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that. I think Kconfig would be completely unsuitable for this kind of detailed configuration. Kconfig is great for enabling/disabling features, but applying it here feels too much to me. Equally, Kconfig is rather new in U-Boot. It'd be better to enable the feature so that distros can rely on it, and then refactor it later if required. Are you saying that we can reimplement this in a nicer way and distros will still see the same behaviour? I expect we could. The only thing distros should rely upon is that if they put extlinux.conf in the right directory on their media, it will get loaded and executed. There are obviously various ways that could be implemented in U-Boot, or indeed other bootloaders. OK, that makes me more comfortable. I do feel that actually implementing the boot script as U-Boot environment variables is much preferred over hard-coding any algorithm into U-Boot. That way, the user can easily modify the scripts as they desire. If we just put e.g. $boot_targets into the environment or DT, but none of the other scripts in this patch, the user would be much more severely restricted in how they could reconfigure the system to act how they want. But that worries me. It means that it is easy for one board to deviate from what is essentially an undocumented boot standard, and then we will end up having to support that use case in the future. Or if it is documented, where is that? I was talking about an end-user changing the boot process. An individual board could only change the boot scripts by either not using config_distro_bootcmd.h, or by explicitly overriding something that it does. Either of those would simply mean that the board doesn't provide the standard boot environment to distros, and as such wouldn't be expected to boot distros in the standard way. OK, so long as that is clear then all is well. I thought you meant the board author could change the scripts in order to tweak the process. Note that all we're talking about here is that U-Boot can search all (or perhaps most) attached storage devices for extlinux.conf and interpret it correctly. This patch adds the search for part; the definition of interpret it correctly is already part of the implementation of the pxe and sysboot commands in U-Boot. OK. Would it be possible to put the settings in the device tree somehow instead of CONFIGs? At least part of the information isn't a HW description, but rather user-/vendor configuration. So, I don't think it's appropriate to put this into DT. Equally, very few U-Boot platforms currently use DT, and I certainly hope it doesn't become mandatory in any way. So, using DT for this purpose would severely limit the platforms where this feature was available. The only platforms I see support for in your series are Tegra (which has DT) and Raspberry
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 08/05/2014 06:27 AM, Simon Glass wrote: On 4 August 2014 12:04, Stephen Warren swar...@wwwdotorg.org wrote: On 08/04/2014 04:13 AM, Simon Glass wrote: As to the question of HW description, I'm not sure I follow. The devices that are attached to the hardware presumably appear in the DT, the partition is fixed anyway, all you need to know is whether it is a bootable device or not. What part of the description is not related to the hardware? The concept of bootable, and the order in which bootable devices should be searched, are SW policy, not HW definition. So that is it? I wonder whether if this is the only configuration option, we might eventually write this feature in C as a new U-Boot command, with an environment variable listing the devices in order? It would certainly be possible to do that. In some ways I prefer implementing this all as user-accessible macros. That way, if the user wants to tweak them, it's as simple as editing the macro and re-saving the environment, rather than rebuilding the bootloader from source. Obviously, if someone changes something it may not work in the same way as originally intended, but it's not everybody's goal to boot a standard distro in a standard way - rather they may want to play around with their own custom ideas. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Hi Stephen, On 31 July 2014 17:00, Stephen Warren swar...@wwwdotorg.org wrote: On 07/31/2014 04:03 PM, Simon Glass wrote: Hi Stephen, On 30 July 2014 23:37, Stephen Warren swar...@wwwdotorg.org wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Boards can define the set of devices from which boot is attempted, and the order in which they are attempted. Users may later customize this set/order by edting $boot_targets. Users may interrupt the boot process and boot from a specific device simply by executing e.g.: $ run bootcmd_mmc1 or: $ run bootcmd_pxe This patch was originally written by Dennis Gilmore based on Tegra and rpi_b boot scripts. I have made the following modifications since then: * Boards must define the BOOT_TARGET_DEVICES macro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly in config_distro_bootcmd.h. * Removed $env_import and related variables; nothing used them, and I think it's better for boards to pre-load an environment customization file using CONFIG_PREBOOT if they need. * Renamed a bunch of variables to suit my whims:-) Signed-off-by: Dennis Gilmore den...@ausil.us Signed-off-by: Stephen Warren swar...@nvidia.com I do understand the desirability of getting something sorted in this area. But I am not thrilled with all the macro magic. How does this fit with the new Kconfig setup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that. I think Kconfig would be completely unsuitable for this kind of detailed configuration. Kconfig is great for enabling/disabling features, but applying it here feels too much to me. Equally, Kconfig is rather new in U-Boot. It'd be better to enable the feature so that distros can rely on it, and then refactor it later if required. Are you saying that we can reimplement this in a nicer way and distros will still see the same behaviour? I do feel that actually implementing the boot script as U-Boot environment variables is much preferred over hard-coding any algorithm into U-Boot. That way, the user can easily modify the scripts as they desire. If we just put e.g. $boot_targets into the environment or DT, but none of the other scripts in this patch, the user would be much more severely restricted in how they could reconfigure the system to act how they want. But that worries me. It means that it is easy for one board to deviate from what is essentially an undocumented boot standard, and then we will end up having to support that use case in the future. Or if it is documented, where is that? Would it be possible to put the settings in the device tree somehow instead of CONFIGs? At least part of the information isn't a HW description, but rather user-/vendor configuration. So, I don't think it's appropriate to put this into DT. Equally, very few U-Boot platforms currently use DT, and I certainly hope it doesn't become mandatory in any way. So, using DT for this purpose would severely limit the platforms where this feature was available. The only platforms I see support for in your series are Tegra (which has DT) and Raspberry PI. Adding basic DT support is not really onerous so doesn't impose any real limits on adoption. In any case I'm mostly just responding to what I see might become a large and mandatory script setup in U-Boot. Would it not be better now to document this clearly and specify that changes are not supported? Then we might be able to refactor it later and still retain compatibility. If we have a clear API separate from the implementation then it is easier to live with the scripts knowing we can do things a different way later. Looking at this from a driver model perspective we would probably want to have a list of devices to try, in a certain order. Certainly driver model would support the approach in this series, but it would be a very ugly way of achieving the goal IMO. BTW in your series bootpart is always 1 - is that always the case for all boards? As to the question of HW description, I'm not sure I follow. The devices that are attached to the hardware presumably appear in the DT, the partition is fixed anyway, all you need to know is whether it is a bootable device or not. What part of the description is not related to the hardware? In trying to figure out what was going on, I was hampered by the fact that autoconf.mk does not get the full environment (e.g. since BOOTDEV doesn't have a CONFIG_ prefix). I can see what it doesn't, I think. I did send a
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Mon, 4 Aug 2014 04:13:41 -0600 Simon Glass s...@chromium.org wrote: Hi Stephen, On 31 July 2014 17:00, Stephen Warren swar...@wwwdotorg.org wrote: On 07/31/2014 04:03 PM, Simon Glass wrote: Hi Stephen, On 30 July 2014 23:37, Stephen Warren swar...@wwwdotorg.org wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Boards can define the set of devices from which boot is attempted, and the order in which they are attempted. Users may later customize this set/order by edting $boot_targets. Users may interrupt the boot process and boot from a specific device simply by executing e.g.: $ run bootcmd_mmc1 or: $ run bootcmd_pxe This patch was originally written by Dennis Gilmore based on Tegra and rpi_b boot scripts. I have made the following modifications since then: * Boards must define the BOOT_TARGET_DEVICES macro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly in config_distro_bootcmd.h. * Removed $env_import and related variables; nothing used them, and I think it's better for boards to pre-load an environment customization file using CONFIG_PREBOOT if they need. * Renamed a bunch of variables to suit my whims:-) Signed-off-by: Dennis Gilmore den...@ausil.us Signed-off-by: Stephen Warren swar...@nvidia.com I do understand the desirability of getting something sorted in this area. But I am not thrilled with all the macro magic. How does this fit with the new Kconfig setup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that. I think Kconfig would be completely unsuitable for this kind of detailed configuration. Kconfig is great for enabling/disabling features, but applying it here feels too much to me. Equally, Kconfig is rather new in U-Boot. It'd be better to enable the feature so that distros can rely on it, and then refactor it later if required. Are you saying that we can reimplement this in a nicer way and distros will still see the same behaviour? As long as the implementation loads a extlinux.conf file yes. how things are implemented in u-boot really does not matter at all. the API between os and u-boot is the config file. I do feel that actually implementing the boot script as U-Boot environment variables is much preferred over hard-coding any algorithm into U-Boot. That way, the user can easily modify the scripts as they desire. If we just put e.g. $boot_targets into the environment or DT, but none of the other scripts in this patch, the user would be much more severely restricted in how they could reconfigure the system to act how they want. But that worries me. It means that it is easy for one board to deviate from what is essentially an undocumented boot standard, and then we will end up having to support that use case in the future. Or if it is documented, where is that? http://www.syslinux.org/wiki/index.php/Doc/syslinux we have added fdt and fdtdir options for dealing with dtb. we probably should have our own documentation. We have adopted a standard. Would it be possible to put the settings in the device tree somehow instead of CONFIGs? At least part of the information isn't a HW description, but rather user-/vendor configuration. So, I don't think it's appropriate to put this into DT. Equally, very few U-Boot platforms currently use DT, and I certainly hope it doesn't become mandatory in any way. So, using DT for this purpose would severely limit the platforms where this feature was available. The only platforms I see support for in your series are Tegra (which has DT) and Raspberry PI. Adding basic DT support is not really onerous so doesn't impose any real limits on adoption. In any case I'm mostly just responding to what I see might become a large and mandatory script setup in U-Boot. Would it not be better now to document this clearly and specify that changes are not supported? Then we might be able to refactor it later and still retain compatibility. If we have a clear API separate from the implementation then it is easier to live with the scripts knowing we can do things a different way later. Looking at this from a driver model perspective we would probably want to have a list of devices to try, in a certain order. Certainly driver model would support the approach in this series, but it would be a very ugly way of achieving the goal IMO. BTW in your series bootpart is always 1 - is that
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 08/04/2014 04:13 AM, Simon Glass wrote: Hi Stephen, On 31 July 2014 17:00, Stephen Warren swar...@wwwdotorg.org wrote: On 07/31/2014 04:03 PM, Simon Glass wrote: Hi Stephen, On 30 July 2014 23:37, Stephen Warren swar...@wwwdotorg.org wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Boards can define the set of devices from which boot is attempted, and the order in which they are attempted. Users may later customize this set/order by edting $boot_targets. Users may interrupt the boot process and boot from a specific device simply by executing e.g.: $ run bootcmd_mmc1 or: $ run bootcmd_pxe This patch was originally written by Dennis Gilmore based on Tegra and rpi_b boot scripts. I have made the following modifications since then: * Boards must define the BOOT_TARGET_DEVICES macro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly in config_distro_bootcmd.h. * Removed $env_import and related variables; nothing used them, and I think it's better for boards to pre-load an environment customization file using CONFIG_PREBOOT if they need. * Renamed a bunch of variables to suit my whims:-) Signed-off-by: Dennis Gilmore den...@ausil.us Signed-off-by: Stephen Warren swar...@nvidia.com I do understand the desirability of getting something sorted in this area. But I am not thrilled with all the macro magic. How does this fit with the new Kconfig setup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that. I think Kconfig would be completely unsuitable for this kind of detailed configuration. Kconfig is great for enabling/disabling features, but applying it here feels too much to me. Equally, Kconfig is rather new in U-Boot. It'd be better to enable the feature so that distros can rely on it, and then refactor it later if required. Are you saying that we can reimplement this in a nicer way and distros will still see the same behaviour? I expect we could. The only thing distros should rely upon is that if they put extlinux.conf in the right directory on their media, it will get loaded and executed. There are obviously various ways that could be implemented in U-Boot, or indeed other bootloaders. I do feel that actually implementing the boot script as U-Boot environment variables is much preferred over hard-coding any algorithm into U-Boot. That way, the user can easily modify the scripts as they desire. If we just put e.g. $boot_targets into the environment or DT, but none of the other scripts in this patch, the user would be much more severely restricted in how they could reconfigure the system to act how they want. But that worries me. It means that it is easy for one board to deviate from what is essentially an undocumented boot standard, and then we will end up having to support that use case in the future. Or if it is documented, where is that? I was talking about an end-user changing the boot process. An individual board could only change the boot scripts by either not using config_distro_bootcmd.h, or by explicitly overriding something that it does. Either of those would simply mean that the board doesn't provide the standard boot environment to distros, and as such wouldn't be expected to boot distros in the standard way. Note that all we're talking about here is that U-Boot can search all (or perhaps most) attached storage devices for extlinux.conf and interpret it correctly. This patch adds the search for part; the definition of interpret it correctly is already part of the implementation of the pxe and sysboot commands in U-Boot. Would it be possible to put the settings in the device tree somehow instead of CONFIGs? At least part of the information isn't a HW description, but rather user-/vendor configuration. So, I don't think it's appropriate to put this into DT. Equally, very few U-Boot platforms currently use DT, and I certainly hope it doesn't become mandatory in any way. So, using DT for this purpose would severely limit the platforms where this feature was available. The only platforms I see support for in your series are Tegra (which has DT) and Raspberry PI. Those are the only platforms I put into my patch set. In Dennis Gilmore's previous patch set, he converted 3 other platforms, and since I posted my series, someone posted a conversion for sunxi too. Adding basic DT support is not really onerous so doesn't impose any real limits on adoption. It implies that the board/SoC maintainers buy into the idea that using DT is
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Wed, 2014-07-30 at 16:37 -0600, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. From a distro PoV this is awesome, thanks! Are you planning to convert any more platforms during this merge window? Hans I would really like to see sunxi switch this time around, before it gets more widely used (since v2014.10 will support loads more platforms). I'm AFK after today but Hans has offered to try and whip something up ASAP. Cheers, Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 07/31/2014 04:47 AM, Ian Campbell wrote: On Wed, 2014-07-30 at 16:37 -0600, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. From a distro PoV this is awesome, thanks! Are you planning to convert any more platforms during this merge window? Hans I would really like to see sunxi switch this time around, before it gets more widely used (since v2014.10 will support loads more platforms). I'm AFK after today but Hans has offered to try and whip something up ASAP. It would be best if individual board/SoC owners (or at least people who have the HW) converted the config files, since they have full knowledge of the best boot order, and can test the changes. Still, if anyone needs me to take a look at specific platforms, let me know and I'll see what I can do. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Hi Stephen, On 30 July 2014 23:37, Stephen Warren swar...@wwwdotorg.org wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Boards can define the set of devices from which boot is attempted, and the order in which they are attempted. Users may later customize this set/order by edting $boot_targets. Users may interrupt the boot process and boot from a specific device simply by executing e.g.: $ run bootcmd_mmc1 or: $ run bootcmd_pxe This patch was originally written by Dennis Gilmore based on Tegra and rpi_b boot scripts. I have made the following modifications since then: * Boards must define the BOOT_TARGET_DEVICES macro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly in config_distro_bootcmd.h. * Removed $env_import and related variables; nothing used them, and I think it's better for boards to pre-load an environment customization file using CONFIG_PREBOOT if they need. * Renamed a bunch of variables to suit my whims:-) Signed-off-by: Dennis Gilmore den...@ausil.us Signed-off-by: Stephen Warren swar...@nvidia.com I do understand the desirability of getting something sorted in this area. But I am not thrilled with all the macro magic. How does this fit with the new Kconfig setup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that. Would it be possible to put the settings in the device tree somehow instead of CONFIGs? I did send a series some time ago that aimed to improve the default environment specification in config files - it was parked while Kconfig was going on, but we could revisit it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 07/31/2014 04:03 PM, Simon Glass wrote: Hi Stephen, On 30 July 2014 23:37, Stephen Warren swar...@wwwdotorg.org wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Boards can define the set of devices from which boot is attempted, and the order in which they are attempted. Users may later customize this set/order by edting $boot_targets. Users may interrupt the boot process and boot from a specific device simply by executing e.g.: $ run bootcmd_mmc1 or: $ run bootcmd_pxe This patch was originally written by Dennis Gilmore based on Tegra and rpi_b boot scripts. I have made the following modifications since then: * Boards must define the BOOT_TARGET_DEVICES macro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly in config_distro_bootcmd.h. * Removed $env_import and related variables; nothing used them, and I think it's better for boards to pre-load an environment customization file using CONFIG_PREBOOT if they need. * Renamed a bunch of variables to suit my whims:-) Signed-off-by: Dennis Gilmore den...@ausil.us Signed-off-by: Stephen Warren swar...@nvidia.com I do understand the desirability of getting something sorted in this area. But I am not thrilled with all the macro magic. How does this fit with the new Kconfig setup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that. I think Kconfig would be completely unsuitable for this kind of detailed configuration. Kconfig is great for enabling/disabling features, but applying it here feels too much to me. Equally, Kconfig is rather new in U-Boot. It'd be better to enable the feature so that distros can rely on it, and then refactor it later if required. I do feel that actually implementing the boot script as U-Boot environment variables is much preferred over hard-coding any algorithm into U-Boot. That way, the user can easily modify the scripts as they desire. If we just put e.g. $boot_targets into the environment or DT, but none of the other scripts in this patch, the user would be much more severely restricted in how they could reconfigure the system to act how they want. Would it be possible to put the settings in the device tree somehow instead of CONFIGs? At least part of the information isn't a HW description, but rather user-/vendor configuration. So, I don't think it's appropriate to put this into DT. Equally, very few U-Boot platforms currently use DT, and I certainly hope it doesn't become mandatory in any way. So, using DT for this purpose would severely limit the platforms where this feature was available. I did send a series some time ago that aimed to improve the default environment specification in config files - it was parked while Kconfig was going on, but we could revisit it. I think we'd still need to use a C pre-processor (or some other code generation/templating tool) even with that scheme in place. So, I think the two are orthogonal. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Thursday, July 31, 2014 at 12:37:14 AM, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Boards can define the set of devices from which boot is attempted, and the order in which they are attempted. Users may later customize this set/order by edting $boot_targets. Users may interrupt the boot process and boot from a specific device simply by executing e.g.: $ run bootcmd_mmc1 or: $ run bootcmd_pxe This patch was originally written by Dennis Gilmore based on Tegra and rpi_b boot scripts. I have made the following modifications since then: * Boards must define the BOOT_TARGET_DEVICES macro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly in config_distro_bootcmd.h. * Removed $env_import and related variables; nothing used them, and I think it's better for boards to pre-load an environment customization file using CONFIG_PREBOOT if they need. * Renamed a bunch of variables to suit my whims:-) Signed-off-by: Dennis Gilmore den...@ausil.us Signed-off-by: Stephen Warren swar...@nvidia.com Reviewed-by: Marek Vasut ma...@denx.de Looks nice, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
