config: introduce a generic $bootcmd
PATCH 1/3 config: introduce a generic $bootcmd
From: Dennis Gilmore <[email protected]>
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:-)
--- include/config_distro_bootcmd.h | 197 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 197 insertions(+) create mode 100644 include/config_distro_bootcmd.h
include/config_distro_bootcmd.h new file +197 -0
@@ -0,0 +1,197 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + +#define BOOTENV_SHARED_BLKDEV_BODY (devtypel) \ + "if " #devtypel " dev ${devnum}; then " \ + "setenv devtype " #devtypel "; " \ + "run scan_dev_for_boot; " \ + "fi\0" + +#define BOOTENV_SHARED_BLKDEV (devtypel) \ + #devtypel "_boot=" \ + BOOTENV_SHARED_BLKDEV_BODY(devtypel) + +#define BOOTENV_DEV_BLKDEV (devtypeu, devtypel, instance) \ + "bootcmd_" #devtypel #instance "=" \ + "setenv devnum " #instance "; " \ + "run " #devtypel "_boot\0" + +#define BOOTENV_DEV_NAME_BLKDEV (devtypeu, devtypel, instance) \ + #devtypel #instance " " + +#ifdef CONFIG_CMD_MMC +#define BOOTENV_SHARED_MMC BOOTENV_SHARED_BLKDEV(mmc) +#define BOOTENV_DEV_MMC BOOTENV_DEV_BLKDEV +#define BOOTENV_DEV_NAME_MMC BOOTENV_DEV_NAME_BLKDEV +#else +#define BOOTENV_SHARED_MMC +#define BOOTENV_DEV_MMC \ + BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC +#define BOOTENV_DEV_NAME_MMC \ + BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC +#endif + +#ifdef CONFIG_CMD_SATA +#define BOOTENV_SHARED_SATA BOOTENV_SHARED_BLKDEV(sata) +#define BOOTENV_DEV_SATA BOOTENV_DEV_BLKDEV +#define BOOTENV_DEV_NAME_SATA BOOTENV_DEV_NAME_BLKDEV +#else +#define BOOTENV_SHARED_SATA +#define BOOTENV_DEV_SATA \ + BOOT_TARGET_DEVICES_references_SATA_without_CONFIG_CMD_SATA +#define BOOTENV_DEV_NAME_SATA \ + BOOT_TARGET_DEVICES_references_SATA_without_CONFIG_CMD_SATA +#endif + +#ifdef CONFIG_CMD_SCSI +#define BOOTENV_SHARED_SCSI BOOTENV_SHARED_BLKDEV(scsi) +#define BOOTENV_DEV_SCSI BOOTENV_DEV_BLKDEV +#define BOOTENV_DEV_NAME_SCSI BOOTENV_DEV_NAME_BLKDEV +#else +#define BOOTENV_SHARED_SCSI +#define BOOTENV_DEV_SCSI \ + BOOT_TARGET_DEVICES_references_SCSI_without_CONFIG_CMD_SCSI +#define BOOTENV_DEV_NAME_SCSI \ + BOOT_TARGET_DEVICES_references_SCSI_without_CONFIG_CMD_SCSI +#endif + +#ifdef CONFIG_CMD_IDE +#define BOOTENV_SHARED_IDE BOOTENV_SHARED_BLKDEV(ide) +#define BOOTENV_DEV_IDE BOOTENV_DEV_BLKDEV +#define BOOTENV_DEV_NAME_IDE BOOTENV_DEV_NAME_BLKDEV +#else +#define BOOTENV_SHARED_IDE +#define BOOTENV_DEV_IDE \ + BOOT_TARGET_DEVICES_references_IDE_without_CONFIG_CMD_IDE +#define BOOTENV_DEV_NAME_IDE \ + BOOT_TARGET_DEVICES_references_IDE_without_CONFIG_CMD_IDE +#endif + +#ifdef CONFIG_CMD_USB +#define BOOTENV_RUN_USB_INIT "run usb_init; " +#define BOOTENV_SET_USB_NEED_INIT "setenv usb_need_init; " +#define BOOTENV_SHARED_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "setenv usb_need_init false; " \ + "usb start 0; " \ + "fi\0" \ + \ + "usb_boot=" \ + BOOTENV_RUN_USB_INIT \ + BOOTENV_SHARED_BLKDEV_BODY(usb) +#define BOOTENV_DEV_USB BOOTENV_DEV_BLKDEV +#define BOOTENV_DEV_NAME_USB BOOTENV_DEV_NAME_BLKDEV +#else +#define BOOTENV_RUN_USB_INIT +#define BOOTENV_SET_USB_NEED_INIT +#define BOOTENV_SHARED_USB +#define BOOTENV_DEV_USB \ + BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB +#define BOOTENV_DEV_NAME_USB \ + BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB +#endif + +#if defined(CONFIG_CMD_DHCP ) +#define BOOTENV_DEV_DHCP (devtypeu, devtypel, instance) \ + "bootcmd_dhcp=" \ + BOOTENV_RUN_USB_INIT \ + "if dhcp ${scriptaddr} boot.scr.uimg; then " \ + "source ${scriptaddr}; " \ + "fi\0" +#define BOOTENV_DEV_NAME_DHCP (devtypeu, devtypel, instance) \ + "dhcp " +#else +#define BOOTENV_DEV_DHCP \ + BOOT_TARGET_DEVICES_references_DHCP_without_CONFIG_CMD_DHCP +#define BOOTENV_DEV_NAME_DHCP \ + BOOT_TARGET_DEVICES_references_DHCP_without_CONFIG_CMD_DHCP +#endif + +#if defined(CONFIG_CMD_DHCP ) && defined(CONFIG_CMD_PXE ) +#define BOOTENV_DEV_PXE (devtypeu, devtypel, instance) \ + "bootcmd_pxe=" \ + BOOTENV_RUN_USB_INIT \ + "dhcp; " \ + "if pxe get; then " \ + "pxe boot; " \ + "fi\0" +#define BOOTENV_DEV_NAME_PXE (devtypeu, devtypel, instance) \ + "pxe " +#else +#define BOOTENV_DEV_PXE \ + BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE +#define BOOTENV_DEV_NAME_PXE \ + BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE +#endif + +#define BOOTENV_DEV_NAME (devtypeu, devtypel, instance) \ + BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance) +#define BOOTENV_BOOT_TARGETS \ + "boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0" + +#define BOOTENV_DEV (devtypeu, devtypel, instance) \ + BOOTENV_DEV_##devtypeu(devtypeu, devtypel, instance) +#define BOOTENV \ + BOOTENV_SHARED_MMC \ + BOOTENV_SHARED_USB \ + BOOTENV_SHARED_SATA \ + BOOTENV_SHARED_SCSI \ + BOOTENV_SHARED_IDE \ + "boot_prefixes=/ /boot/\0" \ + "boot_scripts=boot.scr.uimg boot.scr\0" \ + BOOTENV_BOOT_TARGETS \ + "bootpart=1\0" \ + \ + "boot_extlinux=" \ + "sysboot ${devtype} ${devnum}:${bootpart} any " \ + "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \ + \ + "scan_dev_for_extlinux=" \ + "if test -e ${devtype} ${devnum}:${bootpart} " \ + "${prefix}extlinux/extlinux.conf; then " \ + "echo Found ${prefix}extlinux/extlinux.conf; " \ + "run boot_extlinux; " \ + "echo SCRIPT FAILED: continuing...; " \ + "fi\0" \ + \ + "boot_a_script=" \ + "load ${devtype} ${devnum}:${bootpart} " \ + "${scriptaddr} ${prefix}${script}; " \ + "source ${scriptaddr}\0" \ + \ + "scan_dev_for_scripts=" \ + "for script in ${boot_scripts}; do " \ + "if test -e ${devtype} ${devnum}:${bootpart} " \ + "${prefix}${script}; then " \ + "echo Found U-Boot script " \ + "${prefix}${script}; " \ + "run boot_a_script; " \ + "echo SCRIPT FAILED: continuing...; " \ + "fi; " \ + "done\0" \ + \ + "scan_dev_for_boot=" \ + "echo Scanning ${devtype} ${devnum}...; " \ + "for prefix in ${boot_prefixes}; do " \ + "run scan_dev_for_extlinux; " \ + "run scan_dev_for_scripts; " \ + "done\0" \ + \ + BOOT_TARGET_DEVICES(BOOTENV_DEV) \ + \ + "bootcmd=" BOOTENV_SET_USB_NEED_INIT \ + "for target in ${boot_targets}; do " \ + "run bootcmd_${target}; " \ + "done\0" + +#endif /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
Signature · 1 line
1.9.1
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 8 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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.
PATCH 1/3 config: introduce a generic $bootcmd
Hi Stephen,
Quoted 12 lines · Stephen Warren
Quoted 9 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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.
Quoted 2 lines
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.
Quoted 5 lines
I assume that your acks would go a long way towards Tom applying this series.
Thanks.
Regards,
Simon
PATCH 1/3 config: introduce a generic $bootcmd
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 1 line · Simon Glass
Acked-by Simon Glass <[email protected]>
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.
PATCH 1/3 config: introduce a generic $bootcmd
Hi,
Quoted 4 lines · Stephen Warren
Quoted 1 line · Simon Glass
Acked-by Simon Glass <[email protected]>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 ?
Regards,
Hans
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 4 lines · Hans de Goede
Hi,
Quoted 1 line · Stephen Warren
On 08/07/2014 06:17 PM, Simon Glass wrote:
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Acked-by Simon Glass <[email protected]>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 <[email protected]>
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.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140809/c957ec8d/attachment.pgp>
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Hans de GoedeHi Hans,
Quoted 11 lines · Hans de Goede
Hi,
Quoted 3 lines · Stephen Warren
Quoted 1 line · Simon Glass
Acked-by Simon Glass <[email protected]>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 <[email protected]>
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
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 3 lines · Jeroen Hofstee
Quoted 2 lines · Hans de Goede
Quoted 1 line · Stephen Warren
On 08/07/2014 06:17 PM, Simon Glass wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
Acked-by Simon Glass <[email protected]>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.
Quoted 8 lines
Quoted 4 lines
I've a bunch of patches relying on this, is there anything stopping this from getting merged ?
Reviewed-by Hans de Goede <[email protected]>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.
PATCH 1/3 config: introduce a generic $bootcmd
Hello Stephan,
Quoted 2 lines · Stephen Warren
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?
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 3 lines
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
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 8 lines · Jeroen Hofstee
Hello Stephan,
Quoted 2 lines · Stephen Warren
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.
PATCH 1/3 config: introduce a generic $bootcmd
Hello Stephan
Quoted 10 lines · Stephen Warren
Quoted 8 lines · Jeroen Hofstee
Hello Stephan,
Quoted 2 lines · Stephen Warren
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?
Quoted 8 lines
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.
Quoted 5 lines
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.
Quoted 2 lines
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
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 16 lines · Jeroen Hofstee
Hello Stephan
Quoted 13 lines · Stephen Warren
Quoted 8 lines · Jeroen Hofstee
Hello Stephan,
Quoted 2 lines · Stephen Warren
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.
Quoted 8 lines
Quoted 4 lines
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)
Quoted 5 lines
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.
...
Quoted 6 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
PATCH 1/3 config: introduce a generic $bootcmd
Hello Stephen.
Quoted 26 lines · Stephen Warren
Quoted 16 lines · Jeroen Hofstee
Hello Stephan
Quoted 13 lines · Stephen Warren
Quoted 8 lines · Jeroen Hofstee
Hello Stephan,
Quoted 2 lines · Stephen Warren
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
The following will tell U-Boot to only search USB for extlinux.conf.
setenv
boot_targetsusb(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.
Quoted 9 lines
Quoted 5 lines
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....
Quoted 3 lines
Quoted 2 lines
Once U-Boot locates extlinux.conf or boot.scr, that file encodes what files (kernel, DTB, initrd)
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
Quoted 3 lines
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
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 38 lines · Jeroen Hofstee
Hello Stephen.
Quoted 26 lines · Stephen Warren
Quoted 16 lines · Jeroen Hofstee
Hello Stephan
Quoted 13 lines · Stephen Warren
Quoted 8 lines · Jeroen Hofstee
Hello Stephan,
Quoted 2 lines · Stephen Warren
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.
Quoted 8 lines
Quoted 4 lines
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.Quoted 8 lines
The following will tell U-Boot to only search USB for extlinux.conf.
setenv
boot_targetsusb(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)
Quoted 5 lines
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...).
Quoted 7 lines
Resulting in that I am tempted not to use
the script at all. Therpi_bis 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.
Quoted 13 lines
Quoted 13 lines
Quoted 5 lines
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....
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 2 lines
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
Quoted 12 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 1 line
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.
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 45 lines · Stephen Warren
Quoted 38 lines · Jeroen Hofstee
Hello Stephen.
Quoted 26 lines · Stephen Warren
Quoted 16 lines · Jeroen Hofstee
Hello Stephan
Quoted 13 lines · Stephen Warren
Quoted 8 lines · Jeroen Hofstee
Hello Stephan,
Quoted 2 lines · Stephen Warren
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.
Quoted 8 lines
Quoted 4 lines
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.Quoted 8 lines
The following will tell U-Boot to only search USB for extlinux.conf.
setenv
boot_targetsusb(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)
Quoted 5 lines
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.
Quoted 5 lines
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.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140811/4ff6dca8/attachment.pgp>
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 52 lines · Tom Rini
Quoted 45 lines · Stephen Warren
Quoted 38 lines · Jeroen Hofstee
Hello Stephen.
Quoted 26 lines · Stephen Warren
Quoted 16 lines · Jeroen Hofstee
Hello Stephan
Quoted 13 lines · Stephen Warren
Quoted 8 lines · Jeroen Hofstee
Hello Stephan,
Quoted 2 lines · Stephen Warren
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.
Quoted 8 lines
Quoted 4 lines
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.Quoted 8 lines
The following will tell U-Boot to only search USB for extlinux.conf.
setenv
boot_targetsusb(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)
Quoted 5 lines
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.
Quoted 5 lines
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...).
Quoted 7 lines
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.
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Stephen WarrenHello Stephan,
On 11-08-14 20:55, Stephen Warren wrote:
<snip>
Quoted 9 lines
Quoted 8 lines
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 9 lines
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>
Quoted 6 lines
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
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 1 line · Jeroen Hofstee
On 11-08-14 20:55, Stephen Warren wrote:
...
Quoted 5 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Jeroen HofsteeQuoted 21 lines · On Tue, 12 Aug 2014 19:29:02 +0200 Jeroen Hofstee <[email protected]> wrote:
Hello Stephan,
On 11-08-14 20:55, Stephen Warren wrote:
<snip>
Quoted 9 lines
Quoted 8 lines
Quoted 2 lines
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.
Quoted 5 lines
This is obviously where the disconnect is...
extlinux is (IIRC) a bootloader yes. However, this patch isn't about extlinux, but extlinux.conf.
Quoted 8 lines
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.
Quoted 5 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 9 lines
<snip example file>
Quoted 7 lines
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.
Quoted 4 lines
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
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Stephen WarrenQuoted 10 lines · On Wed, 06 Aug 2014 10:01:09 -0600 Stephen Warren <[email protected]> wrote:
Quoted 8 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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.
Quoted 2 lines
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
Quoted 8 lines
I assume that your acks would go a long way towards Tom applying this series.
Thanks.
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH 2/3 ARM: tegra: use new generic $bootcmd
In reply to Stephen WarrenFrom: Stephen Warren <[email protected]>
Replace the custom $bootcmd with that from <config_distro_bootcmd.h>. There should be no functional change, since the new generic $bootcmd was derived strongly from tegra-common-post.h.
--- include/configs/tegra-common-post.h | 140 +++--------------------------------- 1 file changed, 10 insertions(+), 130 deletions(-)
include/configs/tegra-common-post.h +10 -130
@@ -8,136 +8,16 @@#ifndef __TEGRA_COMMON_POST_H#define __TEGRA_COMMON_POST_H -#ifdef CONFIG_BOOTCOMMAND - -#define BOOTCMDS_COMMON "" - -#else - -#ifdef CONFIG_CMD_MMC -#define BOOTCMDS_MMC \ - "mmc_boot=" \ - "setenv devtype mmc; " \ - "if mmc dev ${devnum}; then " \ - "run scan_boot; " \ - "fi\0" \ - "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ - "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" -#define BOOT_TARGETS_MMC "mmc1 mmc0" +#ifndef CONFIG_SPL_BUILD +#define BOOT_TARGET_DEVICES (func) \ + func(MMC, mmc, 1) \ + func(MMC, mmc, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) +#include <config_distro_bootcmd.h> #else -#define BOOTCMDS_MMC "" -#define BOOT_TARGETS_MMC "" -#endif - -#ifdef CONFIG_CMD_USB -#define BOOTCMD_INIT_USB "run usb_init; " -#define BOOTCMDS_USB \ - "usb_init=" \ - "if ${usb_need_init}; then " \ - "set usb_need_init false; " \ - "usb start 0; " \ - "fi\0" \ - \ - "usb_boot=" \ - "setenv devtype usb; " \ - BOOTCMD_INIT_USB \ - "if usb dev ${devnum}; then " \ - "run scan_boot; " \ - "fi\0" \ - \ - "bootcmd_usb0=setenv devnum 0; run usb_boot;\0" -#define BOOT_TARGETS_USB "usb0" -#else -#define BOOTCMD_INIT_USB "" -#define BOOTCMDS_USB "" -#define BOOT_TARGETS_USB "" -#endif - -#ifdef CONFIG_CMD_DHCP -#define BOOTCMDS_DHCP \ - "bootcmd_dhcp=" \ - BOOTCMD_INIT_USB \ - "if dhcp ${scriptaddr} boot.scr.uimg; then "\ - "source ${scriptaddr}; " \ - "fi\0" -#define BOOT_TARGETS_DHCP "dhcp" -#else -#define BOOTCMDS_DHCP "" -#define BOOT_TARGETS_DHCP "" -#endif - -#if defined(CONFIG_CMD_DHCP ) && defined(CONFIG_CMD_PXE ) -#define BOOTCMDS_PXE \ - "bootcmd_pxe=" \ - BOOTCMD_INIT_USB \ - "dhcp; " \ - "if pxe get; then " \ - "pxe boot; " \ - "fi\0" -#define BOOT_TARGETS_PXE "pxe" -#else -#define BOOTCMDS_PXE "" -#define BOOT_TARGETS_PXE "" -#endif - -#define BOOTCMDS_COMMON \ - "rootpart=1\0" \ - \ - "do_script_boot=" \ - "load ${devtype} ${devnum}:${rootpart} " \ - "${scriptaddr} ${prefix}${script}; " \ - "source ${scriptaddr}\0" \ - \ - "script_boot=" \ - "for script in ${boot_scripts}; do " \ - "if test -e ${devtype} ${devnum}:${rootpart} " \ - "${prefix}${script}; then " \ - "echo Found U-Boot script " \ - "${prefix}${script}; " \ - "run do_script_boot; " \ - "echo SCRIPT FAILED: continuing...; " \ - "fi; " \ - "done\0" \ - \ - "do_sysboot_boot=" \ - "sysboot ${devtype} ${devnum}:${rootpart} any " \ - "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \ - \ - "sysboot_boot=" \ - "if test -e ${devtype} ${devnum}:${rootpart} " \ - "${prefix}extlinux/extlinux.conf; then " \ - "echo Found ${prefix}extlinux/extlinux.conf; " \ - "run do_sysboot_boot; " \ - "echo SCRIPT FAILED: continuing...; " \ - "fi\0" \ - \ - "scan_boot=" \ - "echo Scanning ${devtype} ${devnum}...; " \ - "for prefix in ${boot_prefixes}; do " \ - "run sysboot_boot; " \ - "run script_boot; " \ - "done\0" \ - \ - "boot_targets=" \ - BOOT_TARGETS_MMC " " \ - BOOT_TARGETS_USB " " \ - BOOT_TARGETS_PXE " " \ - BOOT_TARGETS_DHCP " " \ - "\0" \ - \ - "boot_prefixes=/ /boot/\0" \ - \ - "boot_scripts=boot.scr.uimg boot.scr\0" \ - \ - BOOTCMDS_MMC \ - BOOTCMDS_USB \ - BOOTCMDS_DHCP \ - BOOTCMDS_PXE - -#define CONFIG_BOOTCOMMAND \ - "set usb_need_init; " \ - "for target in ${boot_targets}; do run bootcmd_${target}; done" - +#define BOOTENV #endif #ifdef CONFIG_TEGRA_KEYBOARD
@@ -175,7 +55,7 @@MEM_LAYOUT_ENV_SETTINGS \"fdt_high=ffffffff\0" \"initrd_high=ffffffff\0" \ -BOOTCMDS_COMMON \ +BOOTENV \ BOARD_EXTRA_ENV_SETTINGS#if defined(CONFIG_TEGRA20_SFLASH ) || defined(CONFIG_TEGRA20_SLINK ) || defined(CONFIG_TEGRA114_SPI )
Signature · 1 line
1.9.1
PATCH 2/3 ARM: tegra: use new generic $bootcmd
Quoted 7 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Replace the custom $bootcmd with that from <
config_distro_bootcmd.h>. There should be no functional change, since the new generic $bootcmd was derived strongly fromtegra-common-post.h.Signed-off-by Stephen Warren <[email protected]>
(Resending to list)
PATCH 2/3 ARM: tegra: use new generic $bootcmd
In reply to Stephen WarrenQuoted 8 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Replace the custom $bootcmd with that from <
config_distro_bootcmd.h>. There should be no functional change, since the new generic $bootcmd was derived strongly fromtegra-common-post.h.Signed-off-by Stephen Warren <[email protected]>Acked-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140810/ec22a15d/attachment.pgp>
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Stephen WarrenQuoted 27 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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_pxeThis patch was originally written by Dennis Gilmore based on Tegra and
rpi_bboot scripts. I have made the following modifications since then:* Boards must define the
BOOT_TARGET_DEVICESmacro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly inconfig_distro_bootcmd.h.
Quoted 8 lines
* 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_PREBOOTif they need.* Renamed a bunch of variables to suit my whims:-)
Signed-off-by Dennis Gilmore <[email protected]>Signed-off-by Stephen Warren <[email protected]>
Looks nice, thanks!
Best regards,
Marek Vasut
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Stephen WarrenQuoted 8 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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.
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 12 lines · Ian Campbell
Quoted 8 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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!
Quoted 7 lines
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.
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Stephen WarrenHi Stephen,
Quoted 27 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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_pxeThis patch was originally written by Dennis Gilmore based on Tegra and
rpi_bboot scripts. I have made the following modifications since then:* Boards must define the
BOOT_TARGET_DEVICESmacro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly inconfig_distro_bootcmd.h.
Quoted 8 lines
* 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_PREBOOTif they need.* Renamed a bunch of variables to suit my whims:-)
Signed-off-by Dennis Gilmore <[email protected]>Signed-off-by Stephen Warren <[email protected]>
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
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 36 lines · Simon Glass
Hi Stephen,
Quoted 33 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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_pxeThis patch was originally written by Dennis Gilmore based on Tegra and
rpi_bboot scripts. I have made the following modifications since then:* Boards must define the
BOOT_TARGET_DEVICESmacro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly inconfig_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_PREBOOTif they need.* Renamed a bunch of variables to suit my whims:-)
Quoted 8 lines
Quoted 2 lines
Signed-off-by Dennis Gilmore <[email protected]>Signed-off-by Stephen Warren <[email protected]>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
Kconfigsetup? 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.
Quoted 2 lines
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.
Quoted 3 lines
I did send a series some time ago that aimed to improve the default environment specification in config files - it was parked while
Kconfigwas 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.
PATCH 1/3 config: introduce a generic $bootcmd
Hi Stephen,
Quoted 50 lines · Stephen Warren
Quoted 42 lines · Simon Glass
Hi Stephen,
Quoted 28 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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_pxeThis patch was originally written by Dennis Gilmore based on Tegra and
rpi_bboot scripts. I have made the following modifications since then:* Boards must define the
BOOT_TARGET_DEVICESmacro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly inconfig_distro_bootcmd.h.Quoted 8 lines
* 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_PREBOOTif they need.* Renamed a bunch of variables to suit my whims:-)
Signed-off-by Dennis Gilmore <[email protected]>Signed-off-by Stephen Warren <[email protected]>Quoted 5 lines
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
Kconfigsetup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that.
Quoted 5 lines
I think
Kconfigwould be completely unsuitable for this kind of detailed configuration.Kconfigis great for enabling/disabling features, but applying it here feels too much to me. Equally,Kconfigis 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?
Quoted 7 lines
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?
Quoted 11 lines
Quoted 4 lines
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.
Quoted 10 lines
Quoted 5 lines
I did send a series some time ago that aimed to improve the default environment specification in config files - it was parked while
Kconfigwas 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.
Yes, but the more of this sort of stuff we add to U-Boot the harder it becomes to revisit. As you may recall the tegra config files were already pretty hard to move over.
Regards,
Simon
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 64 lines · On Mon, 4 Aug 2014 04:13:41 -0600 Simon Glass <[email protected]> wrote:
Hi Stephen,
Quoted 54 lines · Stephen Warren
Quoted 46 lines · Simon Glass
Hi Stephen,
Quoted 31 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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_pxeThis patch was originally written by Dennis Gilmore based on Tegra and
rpi_bboot scripts. I have made the following modifications since then:* Boards must define the
BOOT_TARGET_DEVICESmacro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly inconfig_distro_bootcmd.h.Quoted 8 lines
* 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_PREBOOTif they need.* Renamed a bunch of variables to suit my whims:-)
Signed-off-by Dennis Gilmore <[email protected]>Signed-off-by Stephen Warren <[email protected]>Quoted 5 lines
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
Kconfigsetup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that.Quoted 6 lines
I think
Kconfigwould be completely unsuitable for this kind of detailed configuration.Kconfigis great for enabling/disabling features, but applying it here feels too much to me. Equally,Kconfigis 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.
Quoted 2 lines
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.
Quoted 9 lines
Quoted 8 lines
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.
Quoted 5 lines
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.
Quoted 24 lines
Quoted 6 lines
Quoted 4 lines
Would it be possible to put the settings in the device tree somehow instead of CONFIGs?
Quoted 6 lines
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.
Quoted 7 lines
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?
It generally is, longer term we need to look at the partition table and find the bootable partition. This is a good starting point.
Quoted 9 lines
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.
having u-boot enumerate over the connected devices in a known good boot order would be nice. Better still would be easily enabling the user to change the boot order.
having u-boot default to output on both serial and video is really needed. Think of a arm based laptop, the user should easily be able to pxe boot to install, select the kernel to run. There is plenty of room for improvement here.
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
I did send a series some time ago that aimed to improve the default environment specification in config files - it was parked while
Kconfigwas going on, but we could revisit it.
Quoted 7 lines
Quoted 3 lines
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.
Yes, but the more of this sort of stuff we add to U-Boot the harder it becomes to revisit. As you may recall the tegra config files were already pretty hard to move over.
knowing the interface we have should make it easier to improve the backend later.
Dennis
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Simon GlassQuoted 53 lines · Simon Glass
Hi Stephen,
Quoted 50 lines · Stephen Warren
Quoted 47 lines · Simon Glass
Hi Stephen,
Quoted 28 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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_pxeThis patch was originally written by Dennis Gilmore based on Tegra and
rpi_bboot scripts. I have made the following modifications since then:* Boards must define the
BOOT_TARGET_DEVICESmacro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly inconfig_distro_bootcmd.h.Quoted 8 lines
* 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_PREBOOTif they need.* Renamed a bunch of variables to suit my whims:-)
Signed-off-by Dennis Gilmore <[email protected]>Signed-off-by Stephen Warren <[email protected]>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
Kconfigsetup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that.
Quoted 8 lines
Quoted 5 lines
I think
Kconfigwould be completely unsuitable for this kind of detailed configuration.Kconfigis great for enabling/disabling features, but applying it here feels too much to me. Equally,Kconfigis 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.
Quoted 7 lines
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
Would it be possible to put the settings in the device tree somehow instead of CONFIGs?
Quoted 8 lines
Quoted 5 lines
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.
Quoted 2 lines
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 a useful thing to do for U-Boot. I believe there's plenty of disagreement with that on Tegra already, just not vocal.
Quoted 4 lines
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?
The fact that changes aren't allowed is rather implied by opting in to using the header in the first place.
Dennis has a patch that provides documentation for the concepts that he included in his series, upon which I based mine. I assume he'll respin that patch, since he received some comments on it when posted.
Quoted 5 lines
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.
That said, I'm not sure what aspect of documentation is needed. This patch doesn't introduce any new API. The patch is simply about searching for an extlinux.conf file and executing it. The important "ABI" things are implied by the definition of extlinux.conf (which already has documentation) not by this patch.
Quoted 7 lines
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?
For now yes. At some point, I did intend to enhance the scripts to use the "default" partition on the media, as defined by the partition table's bootable flag. I haven't implemented that yet. I expect that it'd work something like: unset $bootpart in order to use that "default" partition, or set it to some specific value in order to use that specific partition. IIRC, that's already how disk-oriented commands parse their command-line arguments.
Quoted 5 lines
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.
Quoted 3 lines
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 don't quite understand how the contents of autoconf.mk is relevant. The scripts that config_distro_bootcmd.h defines are self-contained, so I think you can just read that file.
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
I did send a series some time ago that aimed to improve the default environment specification in config files - it was parked while
Kconfigwas going on, but we could revisit it.
Quoted 7 lines
Quoted 3 lines
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.
Yes, but the more of this sort of stuff we add to U-Boot the harder it becomes to revisit. As you may recall the tegra config files were already pretty hard to move over.
The conversion to Kconfig didn't seem to change any of the Tegra config files.
In my opinion at least, Kconfig shouldn't seek to replace include/configs/tegra_*.h, but rather should control user-visible options rather than internal details.
PATCH 1/3 config: introduce a generic $bootcmd
Hi Stephen & Dennis,
Quoted 9 lines · Stephen Warren
Quoted 8 lines · Simon Glass
Hi Stephen,
Quoted 4 lines · Stephen Warren
Quoted 2 lines · Simon Glass
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Hi Stephen,
Quoted 3 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
Thanks for the doc pointers.
Quoted 60 lines
Quoted 56 lines
Quoted 48 lines
Quoted 40 lines
Quoted 33 lines
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_pxeThis patch was originally written by Dennis Gilmore based on Tegra and
rpi_bboot scripts. I have made the following modifications since then:* Boards must define the
BOOT_TARGET_DEVICESmacro in order to specify the set of devices (and order) from which to attempt boot. If
needed,
we can define a default directly inconfig_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 usingCONFIG_PREBOOTif they need.Quoted 4 lines
* Renamed a bunch of variables to suit my whims:-)
Signed-off-by Dennis Gilmore <[email protected]>Signed-off-by Stephen Warren <[email protected]>Quoted 5 lines
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
Kconfigsetup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that.Quoted 6 lines
I think
Kconfigwould be completely unsuitable for this kind of detailed configuration.Kconfigis great for enabling/disabling features, but applying it here feels too much to me. Equally,Kconfigis 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.Quoted 2 lines
Are you saying that we can reimplement this in a nicer way and distros will still see the same behaviour?
Quoted 7 lines
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.
Quoted 22 lines
Quoted 15 lines
Quoted 13 lines
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.Quoted 5 lines
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?
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 26 lines
Quoted 17 lines
Quoted 7 lines
Quoted 4 lines
Would it be possible to put the settings in the device tree somehow instead of CONFIGs?
Quoted 8 lines
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.Quoted 2 lines
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.
Quoted 7 lines
Quoted 2 lines
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 a useful thing to do for U-Boot. I believe there's plenty of disagreement with that on Tegra already, just not vocal.
Well that's another discussion, and fair enough you don't want to tie the two together.
Quoted 8 lines
Quoted 6 lines
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?
Quoted 6 lines
The fact that changes aren't allowed is rather implied by opting in to using the header in the first place.
Dennis has a patch that provides documentation for the concepts that he included in his series, upon which I based mine. I assume he'll respin that patch, since he received some comments on it when posted.
OK good.
Quoted 9 lines
Quoted 7 lines
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.
Quoted 5 lines
That said, I'm not sure what aspect of documentation is needed. This patch doesn't introduce any new API. The patch is simply about searching for an extlinux.conf file and executing it. The important "ABI" things are implied by the definition of extlinux.conf (which already has documentation) not by this patch.
I was referring more to things like the partitions that are searched, and other things specific to your implementation. Dennis pointed me to the syslinux stuff and that is pretty clear. I did try to bring it up at one point but got lost in a maze of U-Boot scripts. Would like to keep the U-Boot side as simple as possible.
Quoted 11 lines
Quoted 9 lines
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?
Quoted 7 lines
For now yes. At some point, I did intend to enhance the scripts to use the "default" partition on the media, as defined by the partition table's bootable flag. I haven't implemented that yet. I expect that it'd work something like: unset $bootpart in order to use that "default" partition, or set it to some specific value in order to use that specific partition. IIRC, that's already how disk-oriented commands parse their command-line arguments.
OK
Quoted 9 lines
Quoted 7 lines
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?
Quoted 3 lines
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?
Quoted 9 lines
Quoted 4 lines
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 don't quite understand how the contents of autoconf.mk is relevant. The scripts that
config_distro_bootcmd.hdefines are self-contained, so I think you can just read that file.
The macro magic makes it hard to see what is going on though.
Quoted 19 lines
Quoted 14 lines
Quoted 8 lines
Quoted 5 lines
I did send a series some time ago that aimed to improve the default environment specification in config files - it was parked while
Kconfigwas going on, but we could revisit it.Quoted 4 lines
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.Quoted 3 lines
Yes, but the more of this sort of stuff we add to U-Boot the harder it becomes to revisit. As you may recall the tegra config files were already pretty hard to move over.
Quoted 6 lines
The conversion to
Kconfigdidn't seem to change any of the Tegra config files.In my opinion at least,
Kconfigshouldn't seek to replaceinclude/configs/tegra_*.h, but rather should control user-visible options rather than internal details.
Sure but to my mind the list of bootable devices might well be something that people want to change in configuration. But really I was talking about the series to move environment variables and scripts to a text file from the config/*.h files. That's quite a tricky transition if we attempt it, and is made trickier by tricky macro stuff in specific board header files. It's just a comment, not a blocker.
Regards,
Simon
PATCH 1/3 config: introduce a generic $bootcmd
Quoted 9 lines · Simon Glass
Quoted 8 lines · Stephen Warren
Quoted 5 lines · Simon Glass
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?
Quoted 6 lines
Quoted 2 lines
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.
PATCH 3/3 ARM: rpi_b: use new generic $bootcmd
In reply to Stephen WarrenFrom: Stephen Warren <[email protected]>
Replace the custom $bootcmd with that from <config_distro_bootcmd.h>. There should be no functional change, since the new generic $bootcmd was derived strongly from tegra-common-post.h, after which this part of rpi_b.h was modelled.
The #defines to enable/disable U-Boot commands/features were moved earlier in rpi_b.h, so they are set up before config_distro_bootcmd.h is included, since it tests whether certain features should be included based on those defines.
---
Note that while I've tested the Tegra conversion, I haven't tested this one yet. I also didn't convert Wanda/Beagle/Panda, since I don't have those boards to test. If this series is accepted, hopefully Dennis can convert them, or perhaps I can try doing so blind:-)
--- include/configs/rpi_b.h | 129 ++++++++++++++---------------------------------- 1 file changed, 36 insertions(+), 93 deletions(-)
include/configs/rpi_b.h +36 -93
@@ -101,6 +101,38 @@"env import -t ${loadaddr} ${filesize}; " \"fi" +/* Shell */ +#define CONFIG_SYS_MAXARGS 8 +#define CONFIG_SYS_PROMPT "U-Boot> " +#define CONFIG_COMMAND_HISTORY + +/* Commands */ +#include <config_cmd_default.h> +#define CONFIG_CMD_GPIO +#define CONFIG_CMD_MMC +#define CONFIG_PARTITION_UUIDS +#define CONFIG_CMD_PART + +/* Device tree support */ +#define CONFIG_OF_BOARD_SETUP +/* ATAGs support for bootm/bootz */ +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_CMDLINE_TAG +#define CONFIG_INITRD_TAG + +#include <config_distro_defaults.h> + +/* Some things don't make sense on this HW or yet */ +#undef CONFIG_CMD_FPGA +#undef CONFIG_CMD_NET +#undef CONFIG_CMD_NFS +#undef CONFIG_CMD_SAVEENV +#undef CONFIG_CMD_DHCP +#undef CONFIG_CMD_MII +#undef CONFIG_CMD_NET +#undef CONFIG_CMD_PING + +/* Environment */ #define ENV_DEVICE_SETTINGS \ "stdin=serial,lcd\0" \ "stdout=serial,lcd\0" \
@@ -138,104 +170,15 @@"fdtfile=bcm2835-rpi-b.dtb\0" \ "ramdisk_addr_r=0x02100000\0" \ -#define BOOTCMDS_MMC \ - "mmc_boot=" \ - "setenv devtype mmc; " \ - "if mmc dev ${devnum}; then " \ - "run scan_boot; " \ - "fi\0" \ - "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" -#define BOOT_TARGETS_MMC "mmc0" - -#define BOOTCMDS_COMMON \ - "rootpart=1\0" \ - \ - "do_script_boot=" \ - "load ${devtype} ${devnum}:${rootpart} " \ - "${scriptaddr} ${prefix}${script}; " \ - "source ${scriptaddr}\0" \ - \ - "script_boot=" \ - "for script in ${boot_scripts}; do " \ - "if test -e ${devtype} ${devnum}:${rootpart} " \ - "${prefix}${script}; then " \ - "echo Found ${prefix}${script}; " \ - "run do_script_boot; " \ - "echo SCRIPT FAILED: continuing...; " \ - "fi; " \ - "done\0" \ - \ - "do_sysboot_boot=" \ - "sysboot ${devtype} ${devnum}:${rootpart} any " \ - "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \ - \ - "sysboot_boot=" \ - "if test -e ${devtype} ${devnum}:${rootpart} " \ - "${prefix}extlinux/extlinux.conf; then " \ - "echo Found ${prefix}extlinux/extlinux.conf; " \ - "run do_sysboot_boot; " \ - "echo SCRIPT FAILED: continuing...; " \ - "fi\0" \ - \ - "scan_boot=" \ - "echo Scanning ${devtype} ${devnum}...; " \ - "for prefix in ${boot_prefixes}; do " \ - "run sysboot_boot; " \ - "run script_boot; " \ - "done\0" \ - \ - "boot_targets=" \ - BOOT_TARGETS_MMC " " \ - "\0" \ - \ - "boot_prefixes=/\0" \ - \ - "boot_scripts=boot.scr.uimg\0" \ - \ - BOOTCMDS_MMC - -#define CONFIG_BOOTCOMMAND \ - "for target in ${boot_targets}; do run bootcmd_${target}; done" - -#define CONFIG_BOOTCOMMAND \ - "for target in ${boot_targets}; do run bootcmd_${target}; done" +#define BOOT_TARGET_DEVICES (func) \ + func(MMC, mmc, 0) +#include <config_distro_bootcmd.h> #define CONFIG_EXTRA_ENV_SETTINGS \ ENV_DEVICE_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ - BOOTCMDS_COMMON + BOOTENV#define CONFIG_BOOTDELAY 2 -/* Shell */ -#define CONFIG_SYS_MAXARGS 8 -#define CONFIG_SYS_PROMPT "U-Boot> " -#define CONFIG_COMMAND_HISTORY - -/* Commands */ -#include <config_cmd_default.h> -#define CONFIG_CMD_GPIO -#define CONFIG_CMD_MMC -#define CONFIG_PARTITION_UUIDS -#define CONFIG_CMD_PART - -/* Device tree support */ -#define CONFIG_OF_BOARD_SETUP -/* ATAGs support for bootm/bootz */ -#define CONFIG_SETUP_MEMORY_TAGS -#define CONFIG_CMDLINE_TAG -#define CONFIG_INITRD_TAG - -#include <config_distro_defaults.h> - -/* Some things don't make sense on this HW or yet */ -#undef CONFIG_CMD_FPGA -#undef CONFIG_CMD_NET -#undef CONFIG_CMD_NFS -#undef CONFIG_CMD_SAVEENV -#undef CONFIG_CMD_DHCP -#undef CONFIG_CMD_MII -#undef CONFIG_CMD_NET -#undef CONFIG_CMD_PING -#endif
Signature · 1 line
1.9.1
PATCH 3/3 ARM: rpi_b: use new generic $bootcmd
PATCH 3/3 ARM: rpi_b: use new generic $bootcmd
In reply to Stephen WarrenQuoted 7 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Replace the custom $bootcmd with that from <
config_distro_bootcmd.h>. There should be no functional change, since the new generic $bootcmd was derived strongly fromtegra-common-post.h, after which this part ofrpi_b.hwas modelled.
Quoted 7 lines
The #defines to enable/disable U-Boot commands/features were moved earlier in
rpi_b.h, so they are set up beforeconfig_distro_bootcmd.his included, since it tests whether certain features should be included based on those defines.Signed-off-by Stephen Warren <[email protected]>Acked-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140810/5140c671/attachment.pgp>
PATCH 1/3 config: introduce a generic $bootcmd
In reply to Stephen WarrenQuoted 31 lines · Stephen Warren
From: Dennis Gilmore <[email protected]>
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_pxeThis patch was originally written by Dennis Gilmore based on Tegra and
rpi_bboot scripts. I have made the following modifications since then:* Boards must define the
BOOT_TARGET_DEVICESmacro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly inconfig_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_PREBOOTif they need.
Quoted 6 lines
* Renamed a bunch of variables to suit my whims:-)
Signed-off-by Dennis Gilmore <[email protected]>Signed-off-by Stephen Warren <[email protected]>Reviewed-by Marek Vasut <[email protected]>Acked-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140810/89eb0a2a/attachment.pgp>