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

[Stephen Warren]

On 01/07/2015 04:17 AM, Ian Campbell wrote:
> On Wed, 2015-01-07 at 12:01 +0100, Sjoerd Simons wrote:
>> On Wed, 2015-01-07 at 10:22 +0000, Ian Campbell wrote:
>>> On Wed, 2015-01-07 at 11:10 +0100, Sjoerd Simons wrote:
>>>> 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 thought u-boot would scan that partitions which were marked bootable
>>> first, in which case you just need to set the bit correctly in the
>>> partition table. I might be wrong about that though. (and re-reading
>>> $subject, it seems like changing this is the subject of the thread...)
>>
>> Nope current u-boot just always uses the first partition. My changes
>> make it scan all the partition on the device instead to find a viable
>> set of bootfiles. As you can see in the previous mails, i do have some
>> dislike for using the legacy bootable flag for this purpose..
>
> I think when using a legacy partition table it is fine to pay attention
> to that bit, it's not legacy in that context.
>
> WRT GPT, I think "legacy" in that context can reasonably be inferred to
> mean "non-EFI", and u-boot isn't EFI so I don't think it is so very
> wrong for u-boot to pay some attention to it, or at least search those
> first.
>
> GPT defines bit 1, as "No Block IO Protocol", so if you disagree with
> treating u-boot as "not EFI", perhaps you'd instead prefer to be "EFI
> compatible" to the extent of honouring that bit.
>
>>>> 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.
>>>
>>> My understanding was that the various ${boot_*} envvars, including
>>> boot_targets, are considered to be user serviceable parts. IOW if you
>>> want to boot from mmc0 only then:
>>>          setenv boot_targets mmc0
>>>          saveenv
>>>
>>> Maybe it makes sense for the default boot order to differ depending on
>>> the specific exynos platform though?
>>
>> Sure, which is something that really should get some documentation (I've
>> had that on my mental today, together with documenting what boot scripts
>> can expect wrt. variables set)..
>
> http://patchwork.ozlabs.org/patch/425412/ covers all this, I think.
>
>> This is about the default setup though, it would be really nice to get
>> consistent behaviour. I would be inclined to say that the defaults
>> should conservatively try the internal/main storage first (assuming
>> there will be an OS is installed there) and only fallback to other
>> options later.
>
> I'm inclined the other way, which is to boot of a removable media first
> if someone has gone to the effort to plug one in. People building kiosks
> etc who want to lock it down to internal only can still do so.

Yes, I agree. This means that if you already have a (perhaps broken or 
old) distro installed on the internal media, you can place boot media 
into the external slot and boot that without having to fiddle with 
modifying the boot configuration variables. If that behaviour isn't what 
a particular user wants, they can just edit $boot_targets.

Each platform can make their own decision if they want though; the order 
of entries in BOOT_TARGET_DEVICES (part of the U-Boot config header 
file) determines the default order of entries in $boot_targets.