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

[Sjoerd Simons]

On Mon, 2015-01-05 at 13:24 -0700, Stephen Warren wrote:
> On 01/05/2015 10:13 AM, Sjoerd Simons wrote:
> > Not all devices use the convention that the boot scripts are on the
> > first partition. For example on chromebooks it seems common for the
> > first two partitions to be ChromeOS kernel partitions.
> >
> > So instead of just the first partition scan all partitions on a device
> > with a filesystem u-boot can recognize.
> 
> I had planned (but obviously never got around to...) enhancing the 
> scripts to look up the (set of?) bootable partition(s) on the disk and 
> to attempt to load the boot files from there. Bootable would be defined 
> as the MBR bootable flag, or GPT legacy bootable attribute.
> 
> That would allow the code to zero in on the one specific partition that 
> it was supposed to look at, rather than searching all partitions.
> 
> Do you have any thoughts re: which option is better?

I did wonder about this as well. I do personally consider the bootable
flag as a rather obsolete/legacy thing (GPT even specifies it as a
legacy flag), so i was wary about using it.. Also i've been bitten a few
times on systems that did rely on the bootable flag (what, what, why
does it not boot, oooooohhhh), which was another reason for heading this
route.

This way does no extra work if the first partition is the partition with
the boot partition when compared to only checking partitions with the
bootable flag as both would need to list existing partitions. 

If the first few partitions have no filesystems, the extra work compared
to the bootable-flag approach would just be probing the filesystem type,
which tends to be relatively simple, so i don't see a big issue there
(it's more work to scan for a missing boot file).

If your first few partitions are ones without the bootfiles, some more
effort is wasted as it will be probing those for viable boot files..
However, in my experience, partition layouts with the bootfiles not on
the first filesystem partitions is rather uncommmon. So again, i didn't
feel that that was problematic. If you have an odd parition layout, your
boot time will be ever so slightly longer :)

The only "issue" in my mind is when multiple partitions, for whatever
reason, have bootfiles. In which case the first one will get picked with
this approach, while with the partition-boot-flag approach you'd have a
way to specify, no really just look at that one.. However, i suspect the
likelihood of forgetting to set the boot flag is higher (been there,
done that) then accidentally leaving boot files on partitions before the
intended boot partition (which also requires on uncommon layout), so
even then i suspect this approach is more friendly/less error-prone.

> This patch looks fine assuming this option (rather than bootable flag) 
> is selected.

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 :).

-- 
Sjoerd Simons <sjoerd.simons at 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/20150106/36493b70/attachment.bin>