| Message ID | 1406759836-556-1-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
On Thursday, July 31, 2014 at 12:37:14 AM, Stephen Warren wrote: > From: Dennis Gilmore <dennis@ausil.us> > > This generic $bootcmd, and associated support macros, automatically > searches a defined set of storage devices (or network protocols) for an > extlinux configuration file or U-Boot boot script in various standardized > locations. Distros that install such a boot config file/script in those > standard locations will get easy-to-set-up booting on HW that enables > this generic $bootcmd. > > Boards can define the set of devices from which boot is attempted, and > the order in which they are attempted. Users may later customize this > set/order by edting $boot_targets. > > Users may interrupt the boot process and boot from a specific device > simply by executing e.g.: > > $ run bootcmd_mmc1 > or: > $ run bootcmd_pxe > > This patch was originally written by Dennis Gilmore based on Tegra and > rpi_b boot scripts. I have made the following modifications since then: > > * Boards must define the BOOT_TARGET_DEVICES macro in order to specify > the set of devices (and order) from which to attempt boot. If needed, > we can define a default directly in config_distro_bootcmd.h. > > * Removed $env_import and related variables; nothing used them, and I > think it's better for boards to pre-load an environment customization > file using CONFIG_PREBOOT if they need. > > * Renamed a bunch of variables to suit my whims:-) > > Signed-off-by: Dennis Gilmore <dennis@ausil.us> > Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Marek Vasut <marex@denx.de> Looks nice, thanks! Best regards, Marek Vasut
On Wed, 2014-07-30 at 16:37 -0600, Stephen Warren wrote: > From: Dennis Gilmore <dennis@ausil.us> > > This generic $bootcmd, and associated support macros, automatically > searches a defined set of storage devices (or network protocols) for an > extlinux configuration file or U-Boot boot script in various standardized > locations. Distros that install such a boot config file/script in those > standard locations will get easy-to-set-up booting on HW that enables > this generic $bootcmd. From a distro PoV this is awesome, thanks! Are you planning to convert any more platforms during this merge window? Hans & I would really like to see sunxi switch this time around, before it gets more widely used (since v2014.10 will support loads more platforms). I'm AFK after today but Hans has offered to try and whip something up ASAP. Cheers, Ian.
On 07/31/2014 04:47 AM, Ian Campbell wrote: > On Wed, 2014-07-30 at 16:37 -0600, Stephen Warren wrote: >> From: Dennis Gilmore <dennis@ausil.us> >> >> This generic $bootcmd, and associated support macros, automatically >> searches a defined set of storage devices (or network protocols) for an >> extlinux configuration file or U-Boot boot script in various standardized >> locations. Distros that install such a boot config file/script in those >> standard locations will get easy-to-set-up booting on HW that enables >> this generic $bootcmd. > > From a distro PoV this is awesome, thanks! > > Are you planning to convert any more platforms during this merge window? > Hans & I would really like to see sunxi switch this time around, before > it gets more widely used (since v2014.10 will support loads more > platforms). > > I'm AFK after today but Hans has offered to try and whip something up > ASAP. It would be best if individual board/SoC owners (or at least people who have the HW) converted the config files, since they have full knowledge of the best boot order, and can test the changes. Still, if anyone needs me to take a look at specific platforms, let me know and I'll see what I can do.
Hi Stephen, On 30 July 2014 23:37, Stephen Warren <swarren@wwwdotorg.org> wrote: > From: Dennis Gilmore <dennis@ausil.us> > > This generic $bootcmd, and associated support macros, automatically > searches a defined set of storage devices (or network protocols) for an > extlinux configuration file or U-Boot boot script in various standardized > locations. Distros that install such a boot config file/script in those > standard locations will get easy-to-set-up booting on HW that enables > this generic $bootcmd. > > Boards can define the set of devices from which boot is attempted, and > the order in which they are attempted. Users may later customize this > set/order by edting $boot_targets. > > Users may interrupt the boot process and boot from a specific device > simply by executing e.g.: > > $ run bootcmd_mmc1 > or: > $ run bootcmd_pxe > > This patch was originally written by Dennis Gilmore based on Tegra and > rpi_b boot scripts. I have made the following modifications since then: > > * Boards must define the BOOT_TARGET_DEVICES macro in order to specify > the set of devices (and order) from which to attempt boot. If needed, > we can define a default directly in config_distro_bootcmd.h. > > * Removed $env_import and related variables; nothing used them, and I > think it's better for boards to pre-load an environment customization > file using CONFIG_PREBOOT if they need. > > * Renamed a bunch of variables to suit my whims:-) > > Signed-off-by: Dennis Gilmore <dennis@ausil.us> > Signed-off-by: Stephen Warren <swarren@nvidia.com> I do understand the desirability of getting something sorted in this area. But I am not thrilled with all the macro magic. How does this fit with the new Kconfig setup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that. Would it be possible to put the settings in the device tree somehow instead of CONFIGs? I did send a series some time ago that aimed to improve the default environment specification in config files - it was parked while Kconfig was going on, but we could revisit it. Regards, Simon
On 07/31/2014 04:03 PM, Simon Glass wrote: > Hi Stephen, > > On 30 July 2014 23:37, Stephen Warren <swarren@wwwdotorg.org> wrote: >> From: Dennis Gilmore <dennis@ausil.us> >> >> This generic $bootcmd, and associated support macros, automatically >> searches a defined set of storage devices (or network protocols) for an >> extlinux configuration file or U-Boot boot script in various standardized >> locations. Distros that install such a boot config file/script in those >> standard locations will get easy-to-set-up booting on HW that enables >> this generic $bootcmd. >> >> Boards can define the set of devices from which boot is attempted, and >> the order in which they are attempted. Users may later customize this >> set/order by edting $boot_targets. >> >> Users may interrupt the boot process and boot from a specific device >> simply by executing e.g.: >> >> $ run bootcmd_mmc1 >> or: >> $ run bootcmd_pxe >> >> This patch was originally written by Dennis Gilmore based on Tegra and >> rpi_b boot scripts. I have made the following modifications since then: >> >> * Boards must define the BOOT_TARGET_DEVICES macro in order to specify >> the set of devices (and order) from which to attempt boot. If needed, >> we can define a default directly in config_distro_bootcmd.h. >> >> * Removed $env_import and related variables; nothing used them, and I >> think it's better for boards to pre-load an environment customization >> file using CONFIG_PREBOOT if they need. >> >> * Renamed a bunch of variables to suit my whims:-) >> >> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >> Signed-off-by: Stephen Warren <swarren@nvidia.com> > > I do understand the desirability of getting something sorted in this > area. But I am not thrilled with all the macro magic. How does this > fit with the new Kconfig setup? It encourages a single setting for > each variable, and I feel that the #ifdefs are not compatible with > that. I think Kconfig would be completely unsuitable for this kind of detailed configuration. Kconfig is great for enabling/disabling features, but applying it here feels too much to me. Equally, Kconfig is rather new in U-Boot. It'd be better to enable the feature so that distros can rely on it, and then refactor it later if required. I do feel that actually implementing the boot script as U-Boot environment variables is much preferred over hard-coding any algorithm into U-Boot. That way, the user can easily modify the scripts as they desire. If we just put e.g. $boot_targets into the environment or DT, but none of the other scripts in this patch, the user would be much more severely restricted in how they could reconfigure the system to act how they want. > Would it be possible to put the settings in the device tree somehow > instead of CONFIGs? At least part of the information isn't a HW description, but rather user-/vendor configuration. So, I don't think it's appropriate to put this into DT. Equally, very few U-Boot platforms currently use DT, and I certainly hope it doesn't become mandatory in any way. So, using DT for this purpose would severely limit the platforms where this feature was available. > I did send a series some time ago that aimed to improve the default > environment specification in config files - it was parked while > Kconfig was going on, but we could revisit it. I think we'd still need to use a C pre-processor (or some other code generation/templating tool) even with that scheme in place. So, I think the two are orthogonal.
Hi Stephen, On 31 July 2014 17:00, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/31/2014 04:03 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 30 July 2014 23:37, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> >>> From: Dennis Gilmore <dennis@ausil.us> >>> >>> This generic $bootcmd, and associated support macros, automatically >>> searches a defined set of storage devices (or network protocols) for an >>> extlinux configuration file or U-Boot boot script in various standardized >>> locations. Distros that install such a boot config file/script in those >>> standard locations will get easy-to-set-up booting on HW that enables >>> this generic $bootcmd. >>> >>> Boards can define the set of devices from which boot is attempted, and >>> the order in which they are attempted. Users may later customize this >>> set/order by edting $boot_targets. >>> >>> Users may interrupt the boot process and boot from a specific device >>> simply by executing e.g.: >>> >>> $ run bootcmd_mmc1 >>> or: >>> $ run bootcmd_pxe >>> >>> This patch was originally written by Dennis Gilmore based on Tegra and >>> rpi_b boot scripts. I have made the following modifications since then: >>> >>> * Boards must define the BOOT_TARGET_DEVICES macro in order to specify >>> the set of devices (and order) from which to attempt boot. If needed, >>> we can define a default directly in config_distro_bootcmd.h. >>> >>> * Removed $env_import and related variables; nothing used them, and I >>> think it's better for boards to pre-load an environment customization >>> file using CONFIG_PREBOOT if they need. >>> >>> * Renamed a bunch of variables to suit my whims:-) >>> >>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>> Signed-off-by: Stephen Warren <swarren@nvidia.com> >> >> >> I do understand the desirability of getting something sorted in this >> area. But I am not thrilled with all the macro magic. How does this >> fit with the new Kconfig setup? It encourages a single setting for >> each variable, and I feel that the #ifdefs are not compatible with >> that. > > > I think Kconfig would be completely unsuitable for this kind of detailed > configuration. Kconfig is great for enabling/disabling features, but > applying it here feels too much to me. Equally, Kconfig is rather new in > U-Boot. It'd be better to enable the feature so that distros can rely on it, > and then refactor it later if required. Are you saying that we can reimplement this in a nicer way and distros will still see the same behaviour? > > I do feel that actually implementing the boot script as U-Boot environment > variables is much preferred over hard-coding any algorithm into U-Boot. That > way, the user can easily modify the scripts as they desire. If we just put > e.g. $boot_targets into the environment or DT, but none of the other scripts > in this patch, the user would be much more severely restricted in how they > could reconfigure the system to act how they want. But that worries me. It means that it is easy for one board to deviate from what is essentially an undocumented boot standard, and then we will end up having to support that use case in the future. Or if it is documented, where is that? > > >> Would it be possible to put the settings in the device tree somehow >> instead of CONFIGs? > > > At least part of the information isn't a HW description, but rather > user-/vendor configuration. So, I don't think it's appropriate to put this > into DT. Equally, very few U-Boot platforms currently use DT, and I > certainly hope it doesn't become mandatory in any way. So, using DT for this > purpose would severely limit the platforms where this feature was available. The only platforms I see support for in your series are Tegra (which has DT) and Raspberry PI. Adding basic DT support is not really onerous so doesn't impose any real limits on adoption. In any case I'm mostly just responding to what I see might become a large and mandatory script setup in U-Boot. Would it not be better now to document this clearly and specify that changes are not supported? Then we might be able to refactor it later and still retain compatibility. If we have a clear API separate from the implementation then it is easier to live with the scripts knowing we can do things a different way later. Looking at this from a driver model perspective we would probably want to have a list of devices to try, in a certain order. Certainly driver model would support the approach in this series, but it would be a very ugly way of achieving the goal IMO. BTW in your series bootpart is always 1 - is that always the case for all boards? As to the question of HW description, I'm not sure I follow. The devices that are attached to the hardware presumably appear in the DT, the partition is fixed anyway, all you need to know is whether it is a bootable device or not. What part of the description is not related to the hardware? In trying to figure out what was going on, I was hampered by the fact that autoconf.mk does not get the full environment (e.g. since BOOTDEV doesn't have a CONFIG_ prefix). I can see what it doesn't, I think. > > >> I did send a series some time ago that aimed to improve the default >> environment specification in config files - it was parked while >> Kconfig was going on, but we could revisit it. > > > I think we'd still need to use a C pre-processor (or some other code > generation/templating tool) even with that scheme in place. So, I think the > two are orthogonal. 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
On Mon, 4 Aug 2014 04:13:41 -0600 Simon Glass <sjg@chromium.org> wrote: > Hi Stephen, > > On 31 July 2014 17:00, Stephen Warren <swarren@wwwdotorg.org> wrote: > > On 07/31/2014 04:03 PM, Simon Glass wrote: > >> > >> Hi Stephen, > >> > >> On 30 July 2014 23:37, Stephen Warren <swarren@wwwdotorg.org> > >> wrote: > >>> > >>> From: Dennis Gilmore <dennis@ausil.us> > >>> > >>> This generic $bootcmd, and associated support macros, > >>> automatically searches a defined set of storage devices (or > >>> network protocols) for an extlinux configuration file or U-Boot > >>> boot script in various standardized locations. Distros that > >>> install such a boot config file/script in those standard > >>> locations will get easy-to-set-up booting on HW that enables this > >>> generic $bootcmd. > >>> > >>> Boards can define the set of devices from which boot is > >>> attempted, and the order in which they are attempted. Users may > >>> later customize this set/order by edting $boot_targets. > >>> > >>> Users may interrupt the boot process and boot from a specific > >>> device simply by executing e.g.: > >>> > >>> $ run bootcmd_mmc1 > >>> or: > >>> $ run bootcmd_pxe > >>> > >>> This patch was originally written by Dennis Gilmore based on > >>> Tegra and rpi_b boot scripts. I have made the following > >>> modifications since then: > >>> > >>> * Boards must define the BOOT_TARGET_DEVICES macro in order to > >>> specify the set of devices (and order) from which to attempt > >>> boot. If needed, we can define a default directly in > >>> config_distro_bootcmd.h. > >>> > >>> * Removed $env_import and related variables; nothing used them, > >>> and I think it's better for boards to pre-load an environment > >>> customization file using CONFIG_PREBOOT if they need. > >>> > >>> * Renamed a bunch of variables to suit my whims:-) > >>> > >>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> > >>> Signed-off-by: Stephen Warren <swarren@nvidia.com> > >> > >> > >> I do understand the desirability of getting something sorted in > >> this area. But I am not thrilled with all the macro magic. How > >> does this fit with the new Kconfig setup? It encourages a single > >> setting for each variable, and I feel that the #ifdefs are not > >> compatible with that. > > > > > > I think Kconfig would be completely unsuitable for this kind of > > detailed configuration. Kconfig is great for enabling/disabling > > features, but applying it here feels too much to me. Equally, > > Kconfig is rather new in U-Boot. It'd be better to enable the > > feature so that distros can rely on it, and then refactor it later > > if required. > > Are you saying that we can reimplement this in a nicer way and distros > will still see the same behaviour? As long as the implementation loads a extlinux.conf file yes. how things are implemented in u-boot really does not matter at all. the API between os and u-boot is the config file. > > > > I do feel that actually implementing the boot script as U-Boot > > environment variables is much preferred over hard-coding any > > algorithm into U-Boot. That way, the user can easily modify the > > scripts as they desire. If we just put e.g. $boot_targets into the > > environment or DT, but none of the other scripts in this patch, the > > user would be much more severely restricted in how they could > > reconfigure the system to act how they want. > > But that worries me. It means that it is easy for one board to deviate > from what is essentially an undocumented boot standard, and then we > will end up having to support that use case in the future. > > Or if it is documented, where is that? http://www.syslinux.org/wiki/index.php/Doc/syslinux we have added fdt and fdtdir options for dealing with dtb. we probably should have our own documentation. We have adopted a standard. > > > > > >> Would it be possible to put the settings in the device tree somehow > >> instead of CONFIGs? > > > > > > At least part of the information isn't a HW description, but rather > > user-/vendor configuration. So, I don't think it's appropriate to > > put this into DT. Equally, very few U-Boot platforms currently use > > DT, and I certainly hope it doesn't become mandatory in any way. > > So, using DT for this purpose would severely limit the platforms > > where this feature was available. > > The only platforms I see support for in your series are Tegra (which > has DT) and Raspberry PI. Adding basic DT support is not really > onerous so doesn't impose any real limits on adoption. In any case I'm > mostly just responding to what I see might become a large and > mandatory script setup in U-Boot. Would it not be better now to > document this clearly and specify that changes are not supported? Then > we might be able to refactor it later and still retain compatibility. > If we have a clear API separate from the implementation then it is > easier to live with the scripts knowing we can do things a different > way later. > > Looking at this from a driver model perspective we would probably want > to have a list of devices to try, in a certain order. Certainly driver > model would support the approach in this series, but it would be a > very ugly way of achieving the goal IMO. > > BTW in your series bootpart is always 1 - is that 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. > 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. > > > > > >> I did send a series some time ago that aimed to improve the default > >> environment specification in config files - it was parked while > >> Kconfig was going on, but we could revisit it. > > > > > > I think we'd still need to use a C pre-processor (or some other code > > generation/templating tool) even with that scheme in place. So, I > > think the two are orthogonal. > > 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
On 08/04/2014 04:13 AM, Simon Glass wrote: > Hi Stephen, > > On 31 July 2014 17:00, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 07/31/2014 04:03 PM, Simon Glass wrote: >>> >>> Hi Stephen, >>> >>> On 30 July 2014 23:37, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>> >>>> From: Dennis Gilmore <dennis@ausil.us> >>>> >>>> This generic $bootcmd, and associated support macros, automatically >>>> searches a defined set of storage devices (or network protocols) for an >>>> extlinux configuration file or U-Boot boot script in various standardized >>>> locations. Distros that install such a boot config file/script in those >>>> standard locations will get easy-to-set-up booting on HW that enables >>>> this generic $bootcmd. >>>> >>>> Boards can define the set of devices from which boot is attempted, and >>>> the order in which they are attempted. Users may later customize this >>>> set/order by edting $boot_targets. >>>> >>>> Users may interrupt the boot process and boot from a specific device >>>> simply by executing e.g.: >>>> >>>> $ run bootcmd_mmc1 >>>> or: >>>> $ run bootcmd_pxe >>>> >>>> This patch was originally written by Dennis Gilmore based on Tegra and >>>> rpi_b boot scripts. I have made the following modifications since then: >>>> >>>> * Boards must define the BOOT_TARGET_DEVICES macro in order to specify >>>> the set of devices (and order) from which to attempt boot. If needed, >>>> we can define a default directly in config_distro_bootcmd.h. >>>> >>>> * Removed $env_import and related variables; nothing used them, and I >>>> think it's better for boards to pre-load an environment customization >>>> file using CONFIG_PREBOOT if they need. >>>> >>>> * Renamed a bunch of variables to suit my whims:-) >>>> >>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>> Signed-off-by: Stephen Warren <swarren@nvidia.com> >>> >>> >>> I do understand the desirability of getting something sorted in this >>> area. But I am not thrilled with all the macro magic. How does this >>> fit with the new Kconfig setup? It encourages a single setting for >>> each variable, and I feel that the #ifdefs are not compatible with >>> that. >> >> >> I think Kconfig would be completely unsuitable for this kind of detailed >> configuration. Kconfig is great for enabling/disabling features, but >> applying it here feels too much to me. Equally, Kconfig is rather new in >> U-Boot. It'd be better to enable the feature so that distros can rely on it, >> and then refactor it later if required. > > Are you saying that we can reimplement this in a nicer way and distros > will still see the same behaviour? I expect we could. The only thing distros should rely upon is that if they put extlinux.conf in the right directory on their media, it will get loaded and executed. There are obviously various ways that could be implemented in U-Boot, or indeed other bootloaders. >> I do feel that actually implementing the boot script as U-Boot environment >> variables is much preferred over hard-coding any algorithm into U-Boot. That >> way, the user can easily modify the scripts as they desire. If we just put >> e.g. $boot_targets into the environment or DT, but none of the other scripts >> in this patch, the user would be much more severely restricted in how they >> could reconfigure the system to act how they want. > > But that worries me. It means that it is easy for one board to deviate > from what is essentially an undocumented boot standard, and then we > will end up having to support that use case in the future. > > Or if it is documented, where is that? I was talking about an end-user changing the boot process. An individual board could only change the boot scripts by either not using config_distro_bootcmd.h, or by explicitly overriding something that it does. Either of those would simply mean that the board doesn't provide the standard boot environment to distros, and as such wouldn't be expected to boot distros in the standard way. Note that all we're talking about here is that U-Boot can search all (or perhaps most) attached storage devices for extlinux.conf and interpret it correctly. This patch adds the "search for" part; the definition of "interpret it correctly" is already part of the implementation of the "pxe" and "sysboot" commands in U-Boot. >>> Would it be possible to put the settings in the device tree somehow >>> instead of CONFIGs? >> >> >> At least part of the information isn't a HW description, but rather >> user-/vendor configuration. So, I don't think it's appropriate to put this >> into DT. Equally, very few U-Boot platforms currently use DT, and I >> certainly hope it doesn't become mandatory in any way. So, using DT for this >> purpose would severely limit the platforms where this feature was available. > > The only platforms I see support for in your series are Tegra (which > has DT) and Raspberry PI. Those are the only platforms I put into my patch set. In Dennis Gilmore's previous patch set, he converted 3 other platforms, and since I posted my series, someone posted a conversion for sunxi too. > Adding basic DT support is not really > onerous so doesn't impose any real limits on adoption. It implies that the board/SoC maintainers buy into the idea that using DT is a useful thing to do for U-Boot. I believe there's plenty of disagreement with that on Tegra already, just not vocal. > 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. > 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. > 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. > 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. > 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. >>> I did send a series some time ago that aimed to improve the default >>> environment specification in config files - it was parked while >>> Kconfig was going on, but we could revisit it. >> >> >> I think we'd still need to use a C pre-processor (or some other code >> generation/templating tool) even with that scheme in place. So, I think the >> two are orthogonal. > > 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.
Hi Stephen & Dennis, On 4 August 2014 12:04, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 08/04/2014 04:13 AM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 31 July 2014 17:00, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> >>> On 07/31/2014 04:03 PM, Simon Glass wrote: >>>> >>>> >>>> Hi Stephen, >>>> >>>> On 30 July 2014 23:37, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>>> >>>>> >>>>> From: Dennis Gilmore <dennis@ausil.us> Thanks for the doc pointers. >>>>> >>>>> This generic $bootcmd, and associated support macros, automatically >>>>> searches a defined set of storage devices (or network protocols) for an >>>>> extlinux configuration file or U-Boot boot script in various >>>>> standardized >>>>> locations. Distros that install such a boot config file/script in those >>>>> standard locations will get easy-to-set-up booting on HW that enables >>>>> this generic $bootcmd. >>>>> >>>>> Boards can define the set of devices from which boot is attempted, and >>>>> the order in which they are attempted. Users may later customize this >>>>> set/order by edting $boot_targets. >>>>> >>>>> Users may interrupt the boot process and boot from a specific device >>>>> simply by executing e.g.: >>>>> >>>>> $ run bootcmd_mmc1 >>>>> or: >>>>> $ run bootcmd_pxe >>>>> >>>>> This patch was originally written by Dennis Gilmore based on Tegra and >>>>> rpi_b boot scripts. I have made the following modifications since then: >>>>> >>>>> * Boards must define the BOOT_TARGET_DEVICES macro in order to specify >>>>> the set of devices (and order) from which to attempt boot. If >>>>> needed, >>>>> we can define a default directly in config_distro_bootcmd.h. >>>>> >>>>> * Removed $env_import and related variables; nothing used them, and I >>>>> think it's better for boards to pre-load an environment >>>>> customization >>>>> file using CONFIG_PREBOOT if they need. >>>>> >>>>> * Renamed a bunch of variables to suit my whims:-) >>>>> >>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>>> Signed-off-by: Stephen Warren <swarren@nvidia.com> >>>> >>>> >>>> >>>> I do understand the desirability of getting something sorted in this >>>> area. But I am not thrilled with all the macro magic. How does this >>>> fit with the new Kconfig setup? It encourages a single setting for >>>> each variable, and I feel that the #ifdefs are not compatible with >>>> that. >>> >>> >>> >>> I think Kconfig would be completely unsuitable for this kind of detailed >>> configuration. Kconfig is great for enabling/disabling features, but >>> applying it here feels too much to me. Equally, Kconfig is rather new in >>> U-Boot. It'd be better to enable the feature so that distros can rely on >>> it, >>> and then refactor it later if required. >> >> >> Are you saying that we can reimplement this in a nicer way and distros >> will still see the same behaviour? > > > I expect we could. > > The only thing distros should rely upon is that if they put extlinux.conf in > the right directory on their media, it will get loaded and executed. > > There are obviously various ways that could be implemented in U-Boot, or > indeed other bootloaders. OK, that makes me more comfortable. > > >>> I do feel that actually implementing the boot script as U-Boot >>> environment >>> variables is much preferred over hard-coding any algorithm into U-Boot. >>> That >>> way, the user can easily modify the scripts as they desire. If we just >>> put >>> e.g. $boot_targets into the environment or DT, but none of the other >>> scripts >>> in this patch, the user would be much more severely restricted in how >>> they >>> could reconfigure the system to act how they want. >> >> >> But that worries me. It means that it is easy for one board to deviate >> from what is essentially an undocumented boot standard, and then we >> will end up having to support that use case in the future. >> >> Or if it is documented, where is that? > > > I was talking about an end-user changing the boot process. > > An individual board could only change the boot scripts by either not using > config_distro_bootcmd.h, or by explicitly overriding something that it does. > Either of those would simply mean that the board doesn't provide the > standard boot environment to distros, and as such wouldn't be expected to > boot distros in the standard way. OK, so long as that is clear then all is well. I thought you meant the board author could change the scripts in order to tweak the process. > > Note that all we're talking about here is that U-Boot can search all (or > perhaps most) attached storage devices for extlinux.conf and interpret it > correctly. This patch adds the "search for" part; the definition of > "interpret it correctly" is already part of the implementation of the "pxe" > and "sysboot" commands in U-Boot. OK. > > >>>> Would it be possible to put the settings in the device tree somehow >>>> instead of CONFIGs? >>> >>> >>> >>> At least part of the information isn't a HW description, but rather >>> user-/vendor configuration. So, I don't think it's appropriate to put >>> this >>> into DT. Equally, very few U-Boot platforms currently use DT, and I >>> certainly hope it doesn't become mandatory in any way. So, using DT for >>> this >>> purpose would severely limit the platforms where this feature was >>> available. >> >> >> The only platforms I see support for in your series are Tegra (which >> has DT) and Raspberry PI. > > > Those are the only platforms I put into my patch set. In Dennis Gilmore's > previous patch set, he converted 3 other platforms, and since I posted my > series, someone posted a conversion for sunxi too. > > >> Adding basic DT support is not really >> onerous so doesn't impose any real limits on adoption. > > > It implies that the board/SoC maintainers buy into the idea that using DT is > 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. > > >> 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. OK good. > > >> 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. 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. > > >> 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. OK > > >> As to the question of HW description, I'm not sure I follow. The >> devices that are attached to the hardware presumably appear in the DT, >> the partition is fixed anyway, all you need to know is whether it is a >> bootable device or not. What part of the description is not related to >> the hardware? > > > The concept of bootable, and the order in which bootable devices should be > searched, are SW policy, not HW definition. > So that is it? I wonder whether if this is the only configuration option, we might eventually write this feature in C as a new U-Boot command, with an environment variable listing the devices in order? > >> 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. The macro magic makes it hard to see what is going on though. > > >>>> I did send a series some time ago that aimed to improve the default >>>> environment specification in config files - it was parked while >>>> Kconfig was going on, but we could revisit it. >>> >>> >>> >>> I think we'd still need to use a C pre-processor (or some other code >>> generation/templating tool) even with that scheme in place. So, I think >>> the >>> two are orthogonal. >> >> >> 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. 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
On 08/05/2014 06:27 AM, Simon Glass wrote: > On 4 August 2014 12:04, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 08/04/2014 04:13 AM, Simon Glass wrote: >>> As to the question of HW description, I'm not sure I follow. The >>> devices that are attached to the hardware presumably appear in the DT, >>> the partition is fixed anyway, all you need to know is whether it is a >>> bootable device or not. What part of the description is not related to >>> the hardware? >> >> The concept of bootable, and the order in which bootable devices should be >> searched, are SW policy, not HW definition. > > So that is it? I wonder whether if this is the only configuration > option, we might eventually write this feature in C as a new U-Boot > command, with an environment variable listing the devices in order? It would certainly be possible to do that. In some ways I prefer implementing this all as user-accessible macros. That way, if the user wants to tweak them, it's as simple as editing the macro and re-saving the environment, rather than rebuilding the bootloader from source. Obviously, if someone changes something it may not work in the same way as originally intended, but it's not everybody's goal to boot a "standard" distro in a "standard" way - rather they may want to play around with their own custom ideas.
On 07/30/2014 04:37 PM, Stephen Warren wrote: > From: Dennis Gilmore <dennis@ausil.us> > > This generic $bootcmd, and associated support macros, automatically > searches a defined set of storage devices (or network protocols) for an > extlinux configuration file or U-Boot boot script in various standardized > locations. Distros that install such a boot config file/script in those > standard locations will get easy-to-set-up booting on HW that enables > this generic $bootcmd. Simon, are you OK with these patches following the discussion? Dennis, I assume you're OK with the new version of this patch? I assume that your acks would go a long way towards Tom applying this series. Thanks.
Hi Stephen, On 6 August 2014 10:01, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/30/2014 04:37 PM, Stephen Warren wrote: >> >> From: Dennis Gilmore <dennis@ausil.us> >> >> This generic $bootcmd, and associated support macros, automatically >> searches a defined set of storage devices (or network protocols) for an >> extlinux configuration file or U-Boot boot script in various standardized >> locations. Distros that install such a boot config file/script in those >> standard locations will get easy-to-set-up booting on HW that enables >> this generic $bootcmd. > > > Simon, are you OK with these patches following the discussion? Dennis, I > assume you're OK with the new version of this patch? I looked it through fairly closely as you cleared up my doubts (i.e. we can move the implementation from scripts to a command later if we want without anyone outside U-Boot knowing/caring). I'll take another look. > > I assume that your acks would go a long way towards Tom applying this > series. > > Thanks. Regards, Simon
Acked-by: Simon Glass <sjg@chromium.org>
On 08/07/2014 06:17 PM, Simon Glass wrote:
> Acked-by: Simon Glass <sjg@chromium.org>
For the list archive's record: Simon also replied to patch 2 with the
same ack, but somehow the CC list got dropped to only myself and TomW.
Hi, On 08/08/2014 06:00 PM, Stephen Warren wrote: > On 08/07/2014 06:17 PM, Simon Glass wrote: >> Acked-by: Simon Glass <sjg@chromium.org> > > For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. I've a bunch of patches relying on this, is there anything stopping this from getting merged ? Reviewed-by: Hans de Goede <hdegoede@redhat.com> Regards, Hans
On Sat, Aug 09, 2014 at 05:02:46PM +0200, Hans de Goede wrote: > Hi, > > On 08/08/2014 06:00 PM, Stephen Warren wrote: > > On 08/07/2014 06:17 PM, Simon Glass wrote: > >> Acked-by: Simon Glass <sjg@chromium.org> > > > > For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. > > I've a bunch of patches relying on this, is there anything stopping this > from getting merged ? > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> Mainly a bug I've just bisected and emailed Masahiro about that's keeping me from building PowerPC on my bigger boxes so I'm having to do it locally. I'll be pushing it all soon.
Hi Hans, On 09-08-14 17:02, Hans de Goede wrote: > Hi, > > On 08/08/2014 06:00 PM, Stephen Warren wrote: >> On 08/07/2014 06:17 PM, Simon Glass wrote: >>> Acked-by: Simon Glass <sjg@chromium.org> >> For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. > I've a bunch of patches relying on this, is there anything stopping this > from getting merged ? > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > Is it not possible to have a uboot.src or something checking for extlinux. This seems to scale badly if we start to check for Grub, Ubldr, VxWorks etc. Regards, Jeroen
On 08/09/2014 04:43 PM, Jeroen Hofstee wrote: > On 09-08-14 17:02, Hans de Goede wrote: >> On 08/08/2014 06:00 PM, Stephen Warren wrote: >>> On 08/07/2014 06:17 PM, Simon Glass wrote: ... >>>> Acked-by: Simon Glass <sjg@chromium.org> >>> >>> For the list archive's record: Simon also replied to patch 2 with the >>> same ack, but somehow the CC list got dropped to only myself and TomW. >> >> I've a bunch of patches relying on this, is there anything stopping this >> from getting merged ? >> >> Reviewed-by: Hans de Goede <hdegoede@redhat.com> > > Is it not possible to have a uboot.src or something > checking for extlinux. This seems to scale badly if > we start to check for Grub, Ubldr, VxWorks etc. The entire point of this series is to prevent distros from having to install bootloader-specific boot configuration files. As such, relying exclusively on boot.scr wouldn't be useful. If we need to support other OSs, I think it'd be best to extend extlinux.conf to allow it to support booting OSs besides Linux. FWIW, if extlinux.conf isn't found on the media, this patch does fall back to searching for boot.scr (a uImage of a U-Boot script) so it's certainly possible to make custom things happen if you want.
Hello Stephan, On 10-08-14 05:11, Stephen Warren wrote: > The entire point of this series is to prevent distros from having to > install bootloader-specific boot configuration files. I fail to see why this is something to pursue. Since the distro knows the boot path, why should u-boot be polling all possible options? > As such, relying exclusively on boot.scr wouldn't be useful. Seems like a logical thing to me, as long as the scripts itself does not have to bother about board details, but is handed those info. > If we need to support other OSs, I think it'd be best to extend > extlinux.conf to allow it to support booting OSs besides Linux. It is not an OS issue. > FWIW, if extlinux.conf isn't found on the media, this patch does fall > back to searching for boot.scr (a uImage of a U-Boot script) so it's > certainly possible to make custom things happen if you want. Yes, and the order is wrong in my mind. If anything, it should fallback to extlinux, but at least use a general boot.scr first. (or /boot/u-boot.conf or whatever) Regards, Jeroen
On Wed, 06 Aug 2014 10:01:09 -0600 Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/30/2014 04:37 PM, Stephen Warren wrote: > > From: Dennis Gilmore <dennis@ausil.us> > > > > This generic $bootcmd, and associated support macros, automatically > > searches a defined set of storage devices (or network protocols) > > for an extlinux configuration file or U-Boot boot script in various > > standardized locations. Distros that install such a boot config > > file/script in those standard locations will get easy-to-set-up > > booting on HW that enables this generic $bootcmd. > > Simon, are you OK with these patches following the discussion? > Dennis, I assume you're OK with the new version of this patch? I am okay with this version. Dennis > I assume that your acks would go a long way towards Tom applying this > series. > > Thanks. > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
On Wed, Jul 30, 2014 at 04:37:14PM -0600, Stephen Warren wrote: > From: Dennis Gilmore <dennis@ausil.us> > > This generic $bootcmd, and associated support macros, automatically > searches a defined set of storage devices (or network protocols) for an > extlinux configuration file or U-Boot boot script in various standardized > locations. Distros that install such a boot config file/script in those > standard locations will get easy-to-set-up booting on HW that enables > this generic $bootcmd. > > Boards can define the set of devices from which boot is attempted, and > the order in which they are attempted. Users may later customize this > set/order by edting $boot_targets. > > Users may interrupt the boot process and boot from a specific device > simply by executing e.g.: > > $ run bootcmd_mmc1 > or: > $ run bootcmd_pxe > > This patch was originally written by Dennis Gilmore based on Tegra and > rpi_b boot scripts. I have made the following modifications since then: > > * Boards must define the BOOT_TARGET_DEVICES macro in order to specify > the set of devices (and order) from which to attempt boot. If needed, > we can define a default directly in config_distro_bootcmd.h. > > * Removed $env_import and related variables; nothing used them, and I > think it's better for boards to pre-load an environment customization > file using CONFIG_PREBOOT if they need. > > * Renamed a bunch of variables to suit my whims:-) > > Signed-off-by: Dennis Gilmore <dennis@ausil.us> > Signed-off-by: Stephen Warren <swarren@nvidia.com> > Reviewed-by: Marek Vasut <marex@denx.de> > Acked-by: Simon Glass <sjg@chromium.org> Applied to u-boot/master, thanks!
On 08/10/2014 10:53 AM, Jeroen Hofstee wrote: > Hello Stephan, > > On 10-08-14 05:11, Stephen Warren wrote: >> The entire point of this series is to prevent distros from having to >> install bootloader-specific boot configuration files. > > I fail to see why this is something to pursue. Since the distro knows > the boot path, why should u-boot be polling all possible options? This patch series allows U-Boot to find the OS and boot it. U-Boot is searching for some kind of boot configuration file. This part of the process is the same as the BIOS searching all known possible boot devices for a partition marked bootable, and with a valid MBR. Or, it's the same as UEFI searching all possible boot devices for whatever config file or boot binary is mandated by UEFI. U-Boot performs this searching before having any knowledge of the OS; there's no way for the OS to parameterize this search path, just like OSs don't configure a PC BIOS to search a specific HDD/floppy/CDROM for the MBR to boot. Once U-Boot locates extlinux.conf or boot.scr, that file encodes what files (kernel, DTB, initrd) to load to boot the OS, what kernel command-line to use, etc. This configuration file or script is written by the OS, and is where knowledge such as root filesystem identity may be encoded.
Hello Stephan On 11-08-14 18:53, Stephen Warren wrote: > On 08/10/2014 10:53 AM, Jeroen Hofstee wrote: >> Hello Stephan, >> >> On 10-08-14 05:11, Stephen Warren wrote: >>> The entire point of this series is to prevent distros from having to >>> install bootloader-specific boot configuration files. > > >> I fail to see why this is something to pursue. Since the distro knows >> the boot path, why should u-boot be polling all possible options? > > This patch series allows U-Boot to find the OS and boot it. U-Boot is > searching for some kind of boot configuration file. > > This part of the process is the same as the BIOS searching all known > possible boot devices for a partition marked bootable, and with a > valid MBR. Or, it's the same as UEFI searching all possible boot > devices for whatever config file or boot binary is mandated by UEFI. > Not in my mind, I am not against scanning the possible boot devices, on the contrary, I am trying to add booting the userland from usb instead of mmc for the rpi_b. The part I dislike is where it starts searching for specific files. The equivalent would be your BIOS actively searching for GRUB, LILO, Windows Boot manager etc. etc. and as a fallback try the MBR. Also in this case the downstream provides information back, albeit tiny, it does indicate if it is bootable and a label to explain what is bootable. > U-Boot performs this searching before having any knowledge of the OS; > there's no way for the OS to parameterize this search path, just like > OSs don't configure a PC BIOS to search a specific HDD/floppy/CDROM > for the MBR to boot. > Yup as said, this is the part I was looking for. > Once U-Boot locates extlinux.conf or boot.scr, that file encodes what > files (kernel, DTB, initrd) This is the part I get for free now with it, I don't really like it, since if we take this road it ends up looking for e.g. grub.conf, ubldr.conf, vxworks.conf etc etc. I will have a look if I can tame the script, without modifying it nor u-boot, but I guess that is not possible since boot.scr comes after extlinux not before. Regards, Jeroen
On 08/11/2014 11:51 AM, Jeroen Hofstee wrote: > Hello Stephan > > On 11-08-14 18:53, Stephen Warren wrote: >> On 08/10/2014 10:53 AM, Jeroen Hofstee wrote: >>> Hello Stephan, >>> >>> On 10-08-14 05:11, Stephen Warren wrote: >>>> The entire point of this series is to prevent distros from having to >>>> install bootloader-specific boot configuration files. >> > >>> I fail to see why this is something to pursue. Since the distro knows >>> the boot path, why should u-boot be polling all possible options? >> >> This patch series allows U-Boot to find the OS and boot it. U-Boot is >> searching for some kind of boot configuration file. >> >> This part of the process is the same as the BIOS searching all known >> possible boot devices for a partition marked bootable, and with a >> valid MBR. Or, it's the same as UEFI searching all possible boot >> devices for whatever config file or boot binary is mandated by UEFI. > > Not in my mind, I am not against scanning the possible > boot devices, on the contrary, I am trying to add booting > the userland from usb instead of mmc for the rpi_b. The following will tell U-Boot to only search USB for extlinux.conf. setenv boot_targets usb (you can put this into /uEnv.txt on the SD card if you want to avoid editing U-Boot source code to make this change; there's no persistent environment storage on the Pi, at least at the moment) > The > part I dislike is where it starts searching for specific files. > The equivalent would be your BIOS actively searching for GRUB, > LILO, Windows Boot manager etc. etc. and as a fallback > try the MBR. ... >> Once U-Boot locates extlinux.conf or boot.scr, that file encodes what >> files (kernel, DTB, initrd) > > This is the part I get for free now with it, I don't really like it, > since if we take this road it ends up looking for e.g. grub.conf, > ubldr.conf, vxworks.conf etc etc. No, Linux distros need to be able to install a single bootloader configuration file to tell the bootloader how to boot. I definitely don't want to add support for a ton of other bootloader configuration file formats. There needs to be a single standard that distros know they can rely on. > Also in this case the downstream provides information back, > albeit tiny, it does indicate if it is bootable and a label to explain > what is bootable. I don't understand what that means.
Hello Stephen. On 11-08-14 20:04, Stephen Warren wrote: > On 08/11/2014 11:51 AM, Jeroen Hofstee wrote: >> Hello Stephan >> >> On 11-08-14 18:53, Stephen Warren wrote: >>> On 08/10/2014 10:53 AM, Jeroen Hofstee wrote: >>>> Hello Stephan, >>>> >>>> On 10-08-14 05:11, Stephen Warren wrote: >>>>> The entire point of this series is to prevent distros from having to >>>>> install bootloader-specific boot configuration files. >>> > >>>> I fail to see why this is something to pursue. Since the distro knows >>>> the boot path, why should u-boot be polling all possible options? >>> >>> This patch series allows U-Boot to find the OS and boot it. U-Boot is >>> searching for some kind of boot configuration file. >>> >>> This part of the process is the same as the BIOS searching all known >>> possible boot devices for a partition marked bootable, and with a >>> valid MBR. Or, it's the same as UEFI searching all possible boot >>> devices for whatever config file or boot binary is mandated by UEFI. >> >> Not in my mind, I am not against scanning the possible >> boot devices, on the contrary, I am trying to add booting >> the userland from usb instead of mmc for the rpi_b. > > The following will tell U-Boot to only search USB for extlinux.conf. > > setenv boot_targets usb > > (you can put this into /uEnv.txt on the SD card if you want to avoid > editing U-Boot source code to make this change; there's no persistent > environment storage on the Pi, at least at the moment) > I am going to give up soon commenting on this. It is applied anyway. My point is that I am making an image without an extlinux.conf, I know that, I could tell it in a boot.scr but yet this scripts now insist on searching for extlinux.conf. Resulting in that I am tempted not to use the script at all. The rpi_b is a bit different, but if u-boot was in NAND e.g. you likely endup with a u-boot not polling for extlinux.conf at all, since the downstream board vendor also thought it is annoying startup delay / noise. So placing it in uEnv is in general too late, since it already polled several boot devices for extlinux. > > The >> part I dislike is where it starts searching for specific files. >> The equivalent would be your BIOS actively searching for GRUB, >> LILO, Windows Boot manager etc. etc. and as a fallback >> try the MBR. > ... >>> Once U-Boot locates extlinux.conf or boot.scr, that file encodes what >>> files (kernel, DTB, initrd) >> >> This is the part I get for free now with it, I don't really like it, >> since if we take this road it ends up looking for e.g. grub.conf, >> ubldr.conf, vxworks.conf etc etc. > > No, Linux distros need to be able to install a single bootloader > configuration file to tell the bootloader how to boot. Don't understand this, I though extlinux is yet another chainloaded bootloader? I doubt there is "the bootloader". I don't understand why it needs a single bootloader. It gets in handy if the last bootloader is known, but I don't even see why that is required. > I definitely don't want to add support for a ton of other bootloader > configuration file formats. There needs to be a single standard that > distros know they can rely on. > Well you added the first auto polled chainloaded bootloader, this simply paves the way for adding more. >> Also in this case the downstream provides information back, >> albeit tiny, it does indicate if it is bootable and a label to explain >> what is bootable. > > I don't understand what that means. As I tried to explain before, if you just add a boot.scr indicating this is a extlinux image and how such a image should be booted, u-boot can pick this up, instead of doing this poll for everything approach. Regards, Jeroen
On 08/11/2014 12:42 PM, Jeroen Hofstee wrote: > Hello Stephen. > > On 11-08-14 20:04, Stephen Warren wrote: >> On 08/11/2014 11:51 AM, Jeroen Hofstee wrote: >>> Hello Stephan >>> >>> On 11-08-14 18:53, Stephen Warren wrote: >>>> On 08/10/2014 10:53 AM, Jeroen Hofstee wrote: >>>>> Hello Stephan, >>>>> >>>>> On 10-08-14 05:11, Stephen Warren wrote: >>>>>> The entire point of this series is to prevent distros from having to >>>>>> install bootloader-specific boot configuration files. >>>> > >>>>> I fail to see why this is something to pursue. Since the distro knows >>>>> the boot path, why should u-boot be polling all possible options? >>>> >>>> This patch series allows U-Boot to find the OS and boot it. U-Boot is >>>> searching for some kind of boot configuration file. >>>> >>>> This part of the process is the same as the BIOS searching all known >>>> possible boot devices for a partition marked bootable, and with a >>>> valid MBR. Or, it's the same as UEFI searching all possible boot >>>> devices for whatever config file or boot binary is mandated by UEFI. >>> >>> Not in my mind, I am not against scanning the possible >>> boot devices, on the contrary, I am trying to add booting >>> the userland from usb instead of mmc for the rpi_b. >> >> The following will tell U-Boot to only search USB for extlinux.conf. >> >> setenv boot_targets usb >> >> (you can put this into /uEnv.txt on the SD card if you want to avoid >> editing U-Boot source code to make this change; there's no persistent >> environment storage on the Pi, at least at the moment) >> > > I am going to give up soon commenting on this. It is > applied anyway. My point is that I am making an image > without an extlinux.conf, I know that, I could tell it in a > boot.scr but yet this scripts now insist on searching for > extlinux.conf. That's because you are an individual crafting your own installation manually. The whole point of this feature is to allow distros to be completely generic, i.e. they work in the exact same way on all HW (that supports this feature, which hopefully will be most ARM boards soon...). > Resulting in that I am tempted not to use > the script at all. The rpi_b is a bit different, but if u-boot > was in NAND e.g. you likely endup with a u-boot not polling > for extlinux.conf at all, since the downstream board vendor > also thought it is annoying startup delay / noise. So placing > it in uEnv is in general too late, since it already polled > several boot devices for extlinux. I don't think the location of U-Boot (NAND or otherwise) impacts this feature. It's all about what happens after U-Boot has started, and is searching for an OS. >> > The >>> part I dislike is where it starts searching for specific files. >>> The equivalent would be your BIOS actively searching for GRUB, >>> LILO, Windows Boot manager etc. etc. and as a fallback >>> try the MBR. >> ... >>>> Once U-Boot locates extlinux.conf or boot.scr, that file encodes what >>>> files (kernel, DTB, initrd) >>> >>> This is the part I get for free now with it, I don't really like it, >>> since if we take this road it ends up looking for e.g. grub.conf, >>> ubldr.conf, vxworks.conf etc etc. >> >> No, Linux distros need to be able to install a single bootloader >> configuration file to tell the bootloader how to boot. > > Don't understand this, I though extlinux is yet another > chainloaded bootloader? I doubt there is "the bootloader". > I don't understand why it needs a single bootloader. It gets > in handy if the last bootloader is known, but I don't even see > why that is required. This is obviously where the disconnect is... extlinux is (IIRC) a bootloader yes. However, this patch isn't about extlinux, but extlinux.conf. extlinux.conf is a text file format the defines a menu of bootable OSs. It's a (de-facto I suppose) standard that's implemented by extlinux (if indeed that is a piece of SW:-) and also U-Boot and barebox and likely other bootloaders too. So, when U-Boot locates extlinux.conf on disk and processes it, it's parsing a configuration file/menu, not chain-loading/executing another bootloader. An example extlinux.conf that I use for network booting is: TIMEOUT 100 MENU TITLE TFTP boot options LABEL sdcard MENU LABEL ../zImage, root on 2GB sdcard LINUX ../zImage FDTDIR ../ APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=b2f82cda-2535-4779-b467-094a210fbae7 LABEL venice2-emmc MENU LABEL ../zImage root on Venice2 eMMC LINUX ../zImage FDTDIR ../ APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=5f71e06f-be08-48ed-b1ef-ee4800cc860f LABEL seaboard-emmc MENU LABEL ../zImage root on Seaboard eMMC LINUX ../zImage FDTDIR ../ APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=cf7b2cdf-df49-45c6-91bf-59ab82d7bfed LABEL fedora-installer-zk MENU LABEL Fedora installer w/ ../zImage LINUX ../zImage INITRD fedora-installer/initrd.img FDTDIR ../ APPEND loglevel=8 earlyprintk ip=dhcp inst.repo=http://10.20.204.51/mirrors/fedora/linux/development/rawhide/armhfp/os/ rd.shell LABEL fedora-installer-fk MENU LABEL Fedora installer w/ Fedora kernel LINUX fedora-installer/vmlinuz INITRD fedora-installer/initrd.img.orig FDTDIR fedora-installer/dtb APPEND loglevel=8 ip=dhcp inst.repo=http://10.20.204.51/mirrors/fedora/linux/development/rawhide/armhfp/os/ rd.shell cma=64M LABEL uImage MENU LABEL ../uImage, root on 2GB sdcard LINUX ../uImage FDTDIR ../ APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=b2f82cda-2535-4779-b467-094a210fbae7 >> I definitely don't want to add support for a ton of other bootloader >> configuration file formats. There needs to be a single standard that >> distros know they can rely on. >> > > Well you added the first auto polled chainloaded > bootloader, this simply paves the way for adding more. > >>> Also in this case the downstream provides information back, >>> albeit tiny, it does indicate if it is bootable and a label to explain >>> what is bootable. >> >> I don't understand what that means. > > As I tried to explain before, if you just add a boot.scr indicating this > is a extlinux image and how such a image should be booted, u-boot > can pick this up, instead of doing this poll for everything approach. That would require all Linux distros to have specific support to install boot.scr, which is a bootloader-specific format script file. Systems that boot using e.g. Barebox or other bootloaders presumably can't process boot.scr. However, if all bootloaders end up supporting extlinux.conf, the distro won't care what bootloader is on the HW.
On Mon, Aug 11, 2014 at 12:55:43PM -0600, Stephen Warren wrote: > On 08/11/2014 12:42 PM, Jeroen Hofstee wrote: > >Hello Stephen. > > > >On 11-08-14 20:04, Stephen Warren wrote: > >>On 08/11/2014 11:51 AM, Jeroen Hofstee wrote: > >>>Hello Stephan > >>> > >>>On 11-08-14 18:53, Stephen Warren wrote: > >>>>On 08/10/2014 10:53 AM, Jeroen Hofstee wrote: > >>>>>Hello Stephan, > >>>>> > >>>>>On 10-08-14 05:11, Stephen Warren wrote: > >>>>>>The entire point of this series is to prevent distros from having to > >>>>>>install bootloader-specific boot configuration files. > >>>>> > >>>>>I fail to see why this is something to pursue. Since the distro knows > >>>>>the boot path, why should u-boot be polling all possible options? > >>>> > >>>>This patch series allows U-Boot to find the OS and boot it. U-Boot is > >>>>searching for some kind of boot configuration file. > >>>> > >>>>This part of the process is the same as the BIOS searching all known > >>>>possible boot devices for a partition marked bootable, and with a > >>>>valid MBR. Or, it's the same as UEFI searching all possible boot > >>>>devices for whatever config file or boot binary is mandated by UEFI. > >>> > >>>Not in my mind, I am not against scanning the possible > >>>boot devices, on the contrary, I am trying to add booting > >>>the userland from usb instead of mmc for the rpi_b. > >> > >>The following will tell U-Boot to only search USB for extlinux.conf. > >> > >>setenv boot_targets usb > >> > >>(you can put this into /uEnv.txt on the SD card if you want to avoid > >>editing U-Boot source code to make this change; there's no persistent > >>environment storage on the Pi, at least at the moment) > >> > > > >I am going to give up soon commenting on this. It is > >applied anyway. My point is that I am making an image > >without an extlinux.conf, I know that, I could tell it in a > >boot.scr but yet this scripts now insist on searching for > >extlinux.conf. > > That's because you are an individual crafting your own installation > manually. The whole point of this feature is to allow distros to be > completely generic, i.e. they work in the exact same way on all HW > (that supports this feature, which hopefully will be most ARM boards > soon...). I suspect the problem here is that you're mentally thinking "... Linux ..." and Jeroen's use case is mainly "... Not Linux ...". So this is a step in the right direction, which is why I applied it, but it may need a little tweaking to make it less noisy to support *BSD or VxWorks or ..., which are real users out there for U-Boot and we don't want to forget them.
On 08/11/2014 01:19 PM, Tom Rini wrote: > On Mon, Aug 11, 2014 at 12:55:43PM -0600, Stephen Warren wrote: >> On 08/11/2014 12:42 PM, Jeroen Hofstee wrote: >>> Hello Stephen. >>> >>> On 11-08-14 20:04, Stephen Warren wrote: >>>> On 08/11/2014 11:51 AM, Jeroen Hofstee wrote: >>>>> Hello Stephan >>>>> >>>>> On 11-08-14 18:53, Stephen Warren wrote: >>>>>> On 08/10/2014 10:53 AM, Jeroen Hofstee wrote: >>>>>>> Hello Stephan, >>>>>>> >>>>>>> On 10-08-14 05:11, Stephen Warren wrote: >>>>>>>> The entire point of this series is to prevent distros from having to >>>>>>>> install bootloader-specific boot configuration files. >>>>>>> >>>>>>> I fail to see why this is something to pursue. Since the distro knows >>>>>>> the boot path, why should u-boot be polling all possible options? >>>>>> >>>>>> This patch series allows U-Boot to find the OS and boot it. U-Boot is >>>>>> searching for some kind of boot configuration file. >>>>>> >>>>>> This part of the process is the same as the BIOS searching all known >>>>>> possible boot devices for a partition marked bootable, and with a >>>>>> valid MBR. Or, it's the same as UEFI searching all possible boot >>>>>> devices for whatever config file or boot binary is mandated by UEFI. >>>>> >>>>> Not in my mind, I am not against scanning the possible >>>>> boot devices, on the contrary, I am trying to add booting >>>>> the userland from usb instead of mmc for the rpi_b. >>>> >>>> The following will tell U-Boot to only search USB for extlinux.conf. >>>> >>>> setenv boot_targets usb >>>> >>>> (you can put this into /uEnv.txt on the SD card if you want to avoid >>>> editing U-Boot source code to make this change; there's no persistent >>>> environment storage on the Pi, at least at the moment) >>>> >>> >>> I am going to give up soon commenting on this. It is >>> applied anyway. My point is that I am making an image >>> without an extlinux.conf, I know that, I could tell it in a >>> boot.scr but yet this scripts now insist on searching for >>> extlinux.conf. >> >> That's because you are an individual crafting your own installation >> manually. The whole point of this feature is to allow distros to be >> completely generic, i.e. they work in the exact same way on all HW >> (that supports this feature, which hopefully will be most ARM boards >> soon...). > > I suspect the problem here is that you're mentally thinking "... Linux > ..." and Jeroen's use case is mainly "... Not Linux ...". > > So this is a step in the right direction, which is why I applied it, but > it may need a little tweaking to make it less noisy to support *BSD or > VxWorks or ..., which are real users out there for U-Boot and we don't > want to forget them. FWIW, it'd be easy enough to add an extra for loop into $scan_dev_for_boot so that rather than hard-coding scanning for extlinux first, then scanning for boot.scr, it was configurable the set and/or order it tried them. The user could then edit this in the environment. Just like $bootcmd reads the set of devices from a variable. One could even have a few more defines feed into config_distro_defaults.h that define which types to support, so you could completely remove e.g. extlinux.conf searching from some board configurations if you really wanted, although I think it'd be best to just leave all the options available everywhere, at least until the time when we add some third option that's not generally applicable.
Hello Stephan, On 11-08-14 20:55, Stephen Warren wrote: <snip> >>> No, Linux distros need to be able to install a single bootloader >>> configuration file to tell the bootloader how to boot. >> >> Don't understand this, I though extlinux is yet another >> chainloaded bootloader? I doubt there is "the bootloader". >> I don't understand why it needs a single bootloader. It gets >> in handy if the last bootloader is known, but I don't even see >> why that is required. > > This is obviously where the disconnect is... > > extlinux is (IIRC) a bootloader yes. However, this patch isn't about > extlinux, but extlinux.conf. > haha, right that is a funny misunderstanding. Yes, extlinux is indeed a bootloader and I was in the impression you actively searched for it to chainload it. And to make extlinux a requirement for distro support... And as I tried to explain I am not that fond of such an approach in general, and that had nothing to do, as Tom suggested, with booting FreeBSD, it is just the image I encountered searching for it in various places. It remains a badly named file though (for U-boot), but well so be it, I guess. > extlinux.conf is a text file format the defines a menu of bootable > OSs. It's a (de-facto I suppose) standard that's implemented by > extlinux (if indeed that is a piece of SW:-) and also U-Boot and > barebox and likely other bootloaders too. > > So, when U-Boot locates extlinux.conf on disk and processes it, it's > parsing a configuration file/menu, not chain-loading/executing another > bootloader. > I see, so shouldn't we document then who is in charge of its format at least, before we start making a U-boot/distro specific version of it? <snip example file> > > That would require all Linux distros to have specific support to > install boot.scr, which is a bootloader-specific format script file. > Systems that boot using e.g. Barebox or other bootloaders presumably > can't process boot.scr. However, if all bootloaders end up supporting > extlinux.conf, the distro won't care what bootloader is on the HW. We will see if this works, I am bit skeptical, but it is at least a whole lot better then polling all possible options, where I took the patch for. (Well not all yet, but the start to do so). Regards, Jeroen
On 08/12/2014 11:29 AM, Jeroen Hofstee wrote: > On 11-08-14 20:55, Stephen Warren wrote: ... >> extlinux.conf is a text file format the defines a menu of bootable >> OSs. It's a (de-facto I suppose) standard that's implemented by >> extlinux (if indeed that is a piece of SW:-) and also U-Boot and >> barebox and likely other bootloaders too. >> >> So, when U-Boot locates extlinux.conf on disk and processes it, it's >> parsing a configuration file/menu, not chain-loading/executing another >> bootloader. >> > > I see, so shouldn't we document then who is in charge of its format > at least, before we start making a U-boot/distro specific version of it? The content of the file is documented at: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ ... although extlinux.conf is a single file containing all the entries, rather than a separate *.conf per OS. I'm not sure where that aspect of the file is documented. Dennis, do you know where? FWIW, the concept of a single file rather than many *.conf has been embodied in U-Boot's pxe and sysboot commands for some time, and isn't anything to do with this patch set.
On Tue, 12 Aug 2014 19:29:02 +0200 Jeroen Hofstee <jeroen@myspectrum.nl> wrote: > Hello Stephan, > > On 11-08-14 20:55, Stephen Warren wrote: > > <snip> > > >>> No, Linux distros need to be able to install a single bootloader > >>> configuration file to tell the bootloader how to boot. > >> > >> Don't understand this, I though extlinux is yet another > >> chainloaded bootloader? I doubt there is "the bootloader". > >> I don't understand why it needs a single bootloader. It gets > >> in handy if the last bootloader is known, but I don't even see > >> why that is required. > > > > This is obviously where the disconnect is... > > > > extlinux is (IIRC) a bootloader yes. However, this patch isn't > > about extlinux, but extlinux.conf. > > > > haha, right that is a funny misunderstanding. Yes, extlinux is > indeed a bootloader and I was in the impression you actively > searched for it to chainload it. And to make extlinux a requirement > for distro support... And as I tried to explain I am not that fond of > such an approach in general, and that had nothing to do, as Tom > suggested, with booting FreeBSD, it is just the image I encountered > searching for it in various places. It remains a badly named file > though (for U-boot), but well so be it, I guess. u-boot in the pxe code has an implementation that parses the syslinux config file. though there really is nothing that says its a linux only thing, admittedly I'm a bit naive as to how things like freebsd boot but i assume you can load a kernel and pass some boot arguments just the same. We are looking for a extlinux.conf file as that's what extlinux looks for and we are mimicking the functionality. > > extlinux.conf is a text file format the defines a menu of bootable > > OSs. It's a (de-facto I suppose) standard that's implemented by > > extlinux (if indeed that is a piece of SW:-) and also U-Boot and > > barebox and likely other bootloaders too. > > > > So, when U-Boot locates extlinux.conf on disk and processes it, > > it's parsing a configuration file/menu, not chain-loading/executing > > another bootloader. > > > > I see, so shouldn't we document then who is in charge of its format > at least, before we start making a U-boot/distro specific version of > it? We are using the same format as is used by the syslinux project. we support a couple of optional items to specify the dtb, fdt and fdtdir, fdt is a location to a devicetree blob and fdtdir is a directory where you can find devicetree blobs. > <snip example file> > > > > That would require all Linux distros to have specific support to > > install boot.scr, which is a bootloader-specific format script > > file. Systems that boot using e.g. Barebox or other bootloaders > > presumably can't process boot.scr. However, if all bootloaders end > > up supporting extlinux.conf, the distro won't care what bootloader > > is on the HW. > > We will see if this works, I am bit skeptical, but it is at least a > whole lot > better then polling all possible options, where I took the patch for. > (Well not all yet, but the start to do so). Even with checking the different places that we can find the config file. There is no noise, u-boot doesn't print out when there is no files found only when it find them. The time to check for the existence of the file is very quick. Dennis
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h new file mode 100644 index 000000000000..90d990157f63 --- /dev/null +++ b/include/config_distro_bootcmd.h @@ -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 */