On 07/26/2012 12:12 PM, 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:
- even if we get the changes into upstream U-Boot and if OEMs ship it unmodified, we will have to deal with older U-Boot builds, custom configs etc. for years to come -- except if we are also providing the U-Boot binaries
- it's unlikely that we get the default bootcmd changed for all ARM boards in a consistent manner due to different maintainers having different tastes, or even due to the set of features (such as CONFIG_HUSH) which are enabled in each board's config; one possibility is to introduce a different command (e.g. "autoboot") that would emulate some kind of boot device and boot files research and that people could use in their bootcmd or not
- 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.)
Now please pardon this small diversion, but perhaps it's relevant to think about UEFI. UEFI defines the format of the partition table, expected locations of vendor extensions, a boot protocol etc. Perhaps we could leverage the UEFI boot protocol for U-Boot's implementation; for instance, U-Boot already has support for GPT partition tables, perhaps it could be extended to support an "uefiboot" command that would mimic the behavior of an UEFI firmware. This would allow using UEFI as the standard both for U-Boot's behavior and as a standard for the format/layout of bootable images and of the installed system for distros and OEMs.
While the idea sounds nice, UEFI defines a full fledged API layer that your efi programs could use to run against for device enumeration, text/graphic output etc. U-boot doesn't provide such an interface, and if it did, I would rather call it TianoCore than u-boot at that point :).
It might however be an interesting idea to have a similar split to coreboot / tianocore in the u-boot world. U-boot could still be the bit implementing the initial initialization and maybe even device i/o drivers, while a uefi capable payload could then implement all the uefi layering on top. Then we could either load Linux directly from u-boot like we do today, or bootstrap outselves into a uefi implementation that would allow for generic booting across the board.
Alex