On 07/31/2014 04:03 PM, Simon Glass wrote:
Hi Stephen,
On 30 July 2014 23:37, Stephen Warren <swar...@wwwdotorg.org> wrote:
From: Dennis Gilmore <den...@ausil.us>
This generic $bootcmd, and associated support macros, automatically
searches a defined set of storage devices (or network protocols) for an
extlinux configuration file or U-Boot boot script in various standardized
locations. Distros that install such a boot config file/script in those
standard locations will get easy-to-set-up booting on HW that enables
this generic $bootcmd.
Boards can define the set of devices from which boot is attempted, and
the order in which they are attempted. Users may later customize this
set/order by edting $boot_targets.
Users may interrupt the boot process and boot from a specific device
simply by executing e.g.:
$ run bootcmd_mmc1
or:
$ run bootcmd_pxe
This patch was originally written by Dennis Gilmore based on Tegra and
rpi_b boot scripts. I have made the following modifications since then:
* Boards must define the BOOT_TARGET_DEVICES macro in order to specify
the set of devices (and order) from which to attempt boot. If needed,
we can define a default directly in config_distro_bootcmd.h.
* Removed $env_import and related variables; nothing used them, and I
think it's better for boards to pre-load an environment customization
file using CONFIG_PREBOOT if they need.
* Renamed a bunch of variables to suit my whims:-)
Signed-off-by: Dennis Gilmore <den...@ausil.us>
Signed-off-by: Stephen Warren <swar...@nvidia.com>
I do understand the desirability of getting something sorted in this
area. But I am not thrilled with all the macro magic. How does this
fit with the new Kconfig setup? It encourages a single setting for
each variable, and I feel that the #ifdefs are not compatible with
that.
I think Kconfig would be completely unsuitable for this kind of detailed
configuration. Kconfig is great for enabling/disabling features, but
applying it here feels too much to me. Equally, Kconfig is rather new in
U-Boot. It'd be better to enable the feature so that distros can rely on
it, and then refactor it later if required.
I do feel that actually implementing the boot script as U-Boot
environment variables is much preferred over hard-coding any algorithm
into U-Boot. That way, the user can easily modify the scripts as they
desire. If we just put e.g. $boot_targets into the environment or DT,
but none of the other scripts in this patch, the user would be much more
severely restricted in how they could reconfigure the system to act how
they want.
Would it be possible to put the settings in the device tree somehow
instead of CONFIGs?
At least part of the information isn't a HW description, but rather
user-/vendor configuration. So, I don't think it's appropriate to put
this into DT. Equally, very few U-Boot platforms currently use DT, and I
certainly hope it doesn't become mandatory in any way. So, using DT for
this purpose would severely limit the platforms where this feature was
available.
I did send a series some time ago that aimed to improve the default
environment specification in config files - it was parked while
Kconfig was going on, but we could revisit it.
I think we'd still need to use a C pre-processor (or some other code
generation/templating tool) even with that scheme in place. So, I think
the two are orthogonal.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
