On 07/26/2012 04:12 AM, Loïc Minier wrote: > On Wed, Jul 25, 2012, David Marlin wrote: > [...] >> Other boards provide similar features, including some (e.g., >> Trim-Slice) that 'scan' through a list of devices until a boot.scr >> is found, load it, and then boot using that script, but the load >> addresses are literals. > > That's definitely a great feature which kinds of mimic the behavior of > the SoC or of a BIOS to try to boot from multiple bootable devices. > >> Does anyone else think it would be useful to include a 'standard' >> set of such definitions in U-Boot (default) that could be used to >> abstract the board/vendor specific details and provide a more >> consistent user experience? If so, could this list be used to help >> define such a set, and encourage its use across ARM systems and >> distros? > > Definitely; thanks for starting this! > > There are various difficulties along the way: ... > * there's probably not an universal boot order for devices, so that this > needs to remain configurable; it might be valid to try booting from > the network and fallback to flash for some use cases, and it might be > inappropriate in other cases, or the same story with SD/MMC vs. SATA > etc.; this is probably the hardest problem; in some cases you might > event want the end-user to be able to chose the method / boot order > interactively (e.g. by pressing a button on beagleboards or by chosing > from a menu on the serial console etc.)
The approach I took on Tegra was to have a U-Boot environment variable that defines the boot order. An example setting might be: boot_targets=dhcp mmc1 mmc0 usb0 For details, see "4878343 tegra: bootcmd enhancements" in git://git.denx.de/u-boot-tegra.git master With such a variable, one could have a completely standardized core bootcmd that iterates over boot_targets, with boot_targets being defined initially by the per-board U-Boot configuration file (to limit it to the set of devices the board has and apply default boot order policy) but which can also be over-ridden by the user by editing/saving the environment for customization. Perhaps we could even allow customization using an interactive menu system (I vaguely recall someone may have ported/been-porting barebox's menu system to U-Boot?) _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
