On Mon, 4 Aug 2014 04:13:41 -0600 Simon Glass <s...@chromium.org> wrote:
> Hi Stephen, > > On 31 July 2014 17:00, Stephen Warren <swar...@wwwdotorg.org> wrote: > > On 07/31/2014 04:03 PM, Simon Glass wrote: > >> > >> Hi Stephen, > >> > >> On 30 July 2014 23:37, Stephen Warren <swar...@wwwdotorg.org> > >> wrote: > >>> > >>> From: Dennis Gilmore <den...@ausil.us> > >>> > >>> This generic $bootcmd, and associated support macros, > >>> automatically searches a defined set of storage devices (or > >>> network protocols) for an extlinux configuration file or U-Boot > >>> boot script in various standardized locations. Distros that > >>> install such a boot config file/script in those standard > >>> locations will get easy-to-set-up booting on HW that enables this > >>> generic $bootcmd. > >>> > >>> Boards can define the set of devices from which boot is > >>> attempted, and the order in which they are attempted. Users may > >>> later customize this set/order by edting $boot_targets. > >>> > >>> Users may interrupt the boot process and boot from a specific > >>> device simply by executing e.g.: > >>> > >>> $ run bootcmd_mmc1 > >>> or: > >>> $ run bootcmd_pxe > >>> > >>> This patch was originally written by Dennis Gilmore based on > >>> Tegra and rpi_b boot scripts. I have made the following > >>> modifications since then: > >>> > >>> * Boards must define the BOOT_TARGET_DEVICES macro in order to > >>> specify the set of devices (and order) from which to attempt > >>> boot. If needed, we can define a default directly in > >>> config_distro_bootcmd.h. > >>> > >>> * Removed $env_import and related variables; nothing used them, > >>> and I think it's better for boards to pre-load an environment > >>> customization file using CONFIG_PREBOOT if they need. > >>> > >>> * Renamed a bunch of variables to suit my whims:-) > >>> > >>> Signed-off-by: Dennis Gilmore <den...@ausil.us> > >>> Signed-off-by: Stephen Warren <swar...@nvidia.com> > >> > >> > >> I do understand the desirability of getting something sorted in > >> this area. But I am not thrilled with all the macro magic. How > >> does this fit with the new Kconfig setup? It encourages a single > >> setting for each variable, and I feel that the #ifdefs are not > >> compatible with that. > > > > > > I think Kconfig would be completely unsuitable for this kind of > > detailed configuration. Kconfig is great for enabling/disabling > > features, but applying it here feels too much to me. Equally, > > Kconfig is rather new in U-Boot. It'd be better to enable the > > feature so that distros can rely on it, and then refactor it later > > if required. > > Are you saying that we can reimplement this in a nicer way and distros > will still see the same behaviour? As long as the implementation loads a extlinux.conf file yes. how things are implemented in u-boot really does not matter at all. the API between os and u-boot is the config file. > > > > I do feel that actually implementing the boot script as U-Boot > > environment variables is much preferred over hard-coding any > > algorithm into U-Boot. That way, the user can easily modify the > > scripts as they desire. If we just put e.g. $boot_targets into the > > environment or DT, but none of the other scripts in this patch, the > > user would be much more severely restricted in how they could > > reconfigure the system to act how they want. > > But that worries me. It means that it is easy for one board to deviate > from what is essentially an undocumented boot standard, and then we > will end up having to support that use case in the future. > > Or if it is documented, where is that? http://www.syslinux.org/wiki/index.php/Doc/syslinux we have added fdt and fdtdir options for dealing with dtb. we probably should have our own documentation. We have adopted a standard. > > > > > >> Would it be possible to put the settings in the device tree somehow > >> instead of CONFIGs? > > > > > > At least part of the information isn't a HW description, but rather > > user-/vendor configuration. So, I don't think it's appropriate to > > put this into DT. Equally, very few U-Boot platforms currently use > > DT, and I certainly hope it doesn't become mandatory in any way. > > So, using DT for this purpose would severely limit the platforms > > where this feature was available. > > The only platforms I see support for in your series are Tegra (which > has DT) and Raspberry PI. Adding basic DT support is not really > onerous so doesn't impose any real limits on adoption. In any case I'm > mostly just responding to what I see might become a large and > mandatory script setup in U-Boot. Would it not be better now to > document this clearly and specify that changes are not supported? Then > we might be able to refactor it later and still retain compatibility. > If we have a clear API separate from the implementation then it is > easier to live with the scripts knowing we can do things a different > way later. > > Looking at this from a driver model perspective we would probably want > to have a list of devices to try, in a certain order. Certainly driver > model would support the approach in this series, but it would be a > very ugly way of achieving the goal IMO. > > BTW in your series bootpart is always 1 - is that 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot