From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Date: Wed, 7 Jan 2015 10:22:09 +0000 Subject: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files In-Reply-To: <1420625436.15910.201.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> <54AC8127.2090404@wwwdotorg.org> <1420625436.15910.201.camel@collabora.co.uk> Message-ID: <1420626129.18631.17.camel@citrix.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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...) > 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? Ian. > (Added Ian Cambell to the cc as he introduce the usage on exynos > devices) >