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

[Stephen Warren]

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

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.