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?)