From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 06 Jan 2015 17:43:19 -0700 Subject: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files In-Reply-To: <1420564024.15910.172.camel@collabora.co.uk> References: <1420478019-18877-1-git-send-email-sjoerd.simons@collabora.co.uk> <1420478019-18877-4-git-send-email-sjoerd.simons@collabora.co.uk> <54AAF302.7020007@wwwdotorg.org> <1420564024.15910.172.camel@collabora.co.uk> Message-ID: <54AC8127.2090404@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de (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.