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
Agreed, but if we want such changes we have to start sometime. If users of 'legacy' devices choose, they can update U-Boot or their U-Boot environment to match any agreed upon settings.
- 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
Understood. I'm not sure how much of a 'standard' would be applied by all maintainers, but it would be nice to have a standard to reference for those who choose to implement it. Hopefully most would, if it existed. Are many of the current U-Boot maintainers involved on this list? Getting their input and agreement would be the best way to see any standard implemented.
- 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.)
Agreed, there is probably no one universal boot order for all devices, but having "a" boot order defined for each device, and as you mentioned some way for the user to select or override it, should be doable.
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.
UEFI is definitely on the radar, but I was thinking smaller in scope at this time. Just getting some standard definitions in the U-Boot environment would go a long way toward improving the user and developer experience across platforms, IMHO.
Thank you for your input,
d.marlin =======