[U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files

Sjoerd Simons
2015-01-07T10:10:36Z

On Tue, 2015-01-06 at 17:43 -0700, Stephen Warren wrote:
> (CCing Dennis so he can comment from a distro perspective re: partition
> table bootable flags v.s. scanning all partitions)
>
> On 01/06/2015 10:07 AM, Sjoerd Simons wrote:
> > On Mon, 2015-01-05 at 13:24 -0700, Stephen Warren wrote:
> >> On 01/05/2015 10:13 AM, Sjoerd Simons wrote:

> > Well my thoughts on the matter are above, If folks feel strongly about
> > this approach being the wrong way I'd love to hear their arguments :).
>
> One issue with this approach is that there's no way for the user to
> short-circuit the scanning. If I put a ChromiumOS install on an SD card
> and leave it plugged into a system that's going to end up booting from
> eMMC since that's where the boot files are, there are lots of partitions
> to scan on that SD card, which will be a bit annoying.

I don't remember exactly how many partitions with fat/ext* filesystems a
ChromiumOS installation has (order of 3-5 iirc?), but indeed it means
your boot will be a bit slower due to it probing more partitions.
Wouldn't expect it to significantly slow down the total boot time
though.

I didn't think of this one my WIP is on an Odroid X2 which has a boot
selector jumper, so I have it always starting from mmc0 (which is either
SD or EMMC depending on the jumper setting).

However, it raises an interesting question. The current convention for
Exynos is to first scans external storage (SD, mmc 1) and then internal
storage (eMMC, mmc 0), which opens up a whole different can of worms. As
that means that e.g. my chromebook will try to boot from whatever random
SD i've put into it first rather the OS installed on eMMC. It would be
nice to have some general guidelines in this area so the behaviour of
various boards can be somewhat consistent in the default behaviour.
(Added Ian Cambell to the cc as he introduce the usage on exynos
devices)

--
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Collabora Ltd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150107/8b06646e/attachment.bin>