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
=======
_______________________________________________
cross-distro mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/cross-distro
