Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Mon, 2015-01-12 at 12:44 -0600, Dennis Gilmore wrote: On Mon, 12 Jan 2015 10:42:27 -0700 Stephen Warren swar...@wwwdotorg.org wrote: On 01/10/2015 11:27 AM, Dennis Gilmore wrote: On Tue, 06 Jan 2015 17:43:19 -0700 Stephen Warren swar...@wwwdotorg.org 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: 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. ChromeOS seems to have adopted its own unique setup. it is not a typical configuration. Sure, However most installation guides for linux on chromeos will still tell you have the first 2 partitions as kernel ones (Which is also where you put u-boot if you want to load that without writing it to flash). In any case, this was just an example to indicate why hardcoding partition one is nasty. 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, oo), which was another reason for heading this route. I really like the idea of using the bootable flag and looking at it but if its legacy in GPT will it go away in some future partition table layout? UEFI Requires that a ESP exist. I think requiring that the bootable flag exist is acceptable. One other alternative for GPT is to invent a new partition type UUID for bootable partitions. This likely has more implications though, since any tool that looks at the partition type UUID would have to be updated. I have no idea how many such tools exist though. or perhaps use the ESP flag. though that might be totally confusing for all. That seems quite confusing indeed. Also ESP partitions are required to be vfat afaik, which is rather unconvenient. At least in the Debian world, the package management tools get rather annoyed if /boot isn't a posix compatible filesystem. Defining a new partition type UUID would be more GPT-style, there is a bit of prior art here: http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ But that doesn't really define a boot partition currently, apart from suggesting to mount the ESP on /boot. Something to take up with the systemd folks. 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. That is what happens on x86 today though. if you had a bootable cdrom/dvdrom or usb stick it will boot from that before the local install. x86 doesn't search all the partitions though, only those marked with the bootable flag. That's why I'm trying to drive the standard distro boot process (as implemented by U-Boot) to honor the bootable flag and ignore other partitions. Right, bios uses the bootable flag, UEFI uses the ESP partition which is why I guess GPT has the bootable flag as a legacy option. I'm in agreement with you on honouring the bootable flag. I was just trying to point out that if you put say a usb stick in a machine that had a live image installed on it that's what the x86 system would boot. Ok. To summarize a bit, it seems the overall consensus thusfar is that u-boot should honor the bootflag both on old msdos style partitions and GPT partitions. So basically folks don't agree with my dislike of the boot flag (ah well, such is life). So the next step for me would be to update this set adding ``part listbootable'' command, which does the same as part list, but filters on partitions which are bootable (as defined by the bootable flag). And change this particular patch to use listbootable instead of list. Dennis, Ian, should we keep
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On 01/13/2015 01:40 AM, Sjoerd Simons wrote: On Mon, 2015-01-12 at 12:44 -0600, Dennis Gilmore wrote: On Mon, 12 Jan 2015 10:42:27 -0700 Stephen Warren swar...@wwwdotorg.org wrote: On 01/10/2015 11:27 AM, Dennis Gilmore wrote: On Tue, 06 Jan 2015 17:43:19 -0700 Stephen Warren swar...@wwwdotorg.org 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: 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. ChromeOS seems to have adopted its own unique setup. it is not a typical configuration. Sure, However most installation guides for linux on chromeos will still tell you have the first 2 partitions as kernel ones (Which is also where you put u-boot if you want to load that without writing it to flash). In any case, this was just an example to indicate why hardcoding partition one is nasty. 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, oo), which was another reason for heading this route. I really like the idea of using the bootable flag and looking at it but if its legacy in GPT will it go away in some future partition table layout? UEFI Requires that a ESP exist. I think requiring that the bootable flag exist is acceptable. One other alternative for GPT is to invent a new partition type UUID for bootable partitions. This likely has more implications though, since any tool that looks at the partition type UUID would have to be updated. I have no idea how many such tools exist though. or perhaps use the ESP flag. though that might be totally confusing for all. That seems quite confusing indeed. Also ESP partitions are required to be vfat afaik, which is rather unconvenient. At least in the Debian world, the package management tools get rather annoyed if /boot isn't a posix compatible filesystem. Defining a new partition type UUID would be more GPT-style, there is a bit of prior art here: http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ But that doesn't really define a boot partition currently, apart from suggesting to mount the ESP on /boot. Something to take up with the systemd folks. One other issue is that there may be no separate /boot partition. We don't want to force the existence of a separate partition just so that it can have the bootable type UUID. 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. That is what happens on x86 today though. if you had a bootable cdrom/dvdrom or usb stick it will boot from that before the local install. x86 doesn't search all the partitions though, only those marked with the bootable flag. That's why I'm trying to drive the standard distro boot process (as implemented by U-Boot) to honor the bootable flag and ignore other partitions. Right, bios uses the bootable flag, UEFI uses the ESP partition which is why I guess GPT has the bootable flag as a legacy option. I'm in agreement with you on honouring the bootable flag. I was just trying to point out that if you put say a usb stick in a machine that had a live image installed on it that's what the x86 system would boot. Ok. To summarize a bit, it seems the overall consensus thusfar is that u-boot should honor the bootflag both on old msdos style partitions and GPT partitions. So basically folks don't agree with my dislike of the boot flag (ah well, such is life). So the next step for me would be to update this set adding ``part listbootable'' command, which does the same as part list, but filters on partitions which are bootable (as defined by the bootable flag). And change this particular
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On 01/10/2015 11:27 AM, Dennis Gilmore wrote: On Tue, 06 Jan 2015 17:43:19 -0700 Stephen Warren swar...@wwwdotorg.org 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: 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. ChromeOS seems to have adopted its own unique setup. it is not a typical configuration. 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, oo), which was another reason for heading this route. I really like the idea of using the bootable flag and looking at it but if its legacy in GPT will it go away in some future partition table layout? UEFI Requires that a ESP exist. I think requiring that the bootable flag exist is acceptable. One other alternative for GPT is to invent a new partition type UUID for bootable partitions. This likely has more implications though, since any tool that looks at the partition type UUID would have to be updated. I have no idea how many such tools exist though. 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. That is what happens on x86 today though. if you had a bootable cdrom/dvdrom or usb stick it will boot from that before the local install. x86 doesn't search all the partitions though, only those marked with the bootable flag. That's why I'm trying to drive the standard distro boot process (as implemented by U-Boot) to honor the bootable flag and ignore other partitions. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Mon, 12 Jan 2015 10:42:27 -0700 Stephen Warren swar...@wwwdotorg.org wrote: On 01/10/2015 11:27 AM, Dennis Gilmore wrote: On Tue, 06 Jan 2015 17:43:19 -0700 Stephen Warren swar...@wwwdotorg.org 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: 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. ChromeOS seems to have adopted its own unique setup. it is not a typical configuration. 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, oo), which was another reason for heading this route. I really like the idea of using the bootable flag and looking at it but if its legacy in GPT will it go away in some future partition table layout? UEFI Requires that a ESP exist. I think requiring that the bootable flag exist is acceptable. One other alternative for GPT is to invent a new partition type UUID for bootable partitions. This likely has more implications though, since any tool that looks at the partition type UUID would have to be updated. I have no idea how many such tools exist though. or perhaps use the ESP flag. though that might be totally confusing for all. 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. That is what happens on x86 today though. if you had a bootable cdrom/dvdrom or usb stick it will boot from that before the local install. x86 doesn't search all the partitions though, only those marked with the bootable flag. That's why I'm trying to drive the standard distro boot process (as implemented by U-Boot) to honor the bootable flag and ignore other partitions. Right, bios uses the bootable flag, UEFI uses the ESP partition which is why I guess GPT has the bootable flag as a legacy option. I'm in agreement with you on honouring the bootable flag. I was just trying to point out that if you put say a usb stick in a machine that had a live image installed on it that's what the x86 system would boot. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Wed, 07 Jan 2015 12:46:20 +0100 Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: 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. This is the general problem of the user doing an action but the system really being unable to devine the intention behind that action.. An external storage device can have been plugged in for a lot of reasons, not just to boot from (you might have wnated to copy/inspect/change some data on the card). I would argue that the main reason for folks to plug in external storage devices into computers is not because they'd like to boot from it and furthermore that a lot of people would be confused if leaving in a storage card/stick makes the system unbootable. I suspect this argument comes down to how you expect users to normally use the system.. Iotw as a general computing device, just like your laptop or desktop machine or as a development toy where you regularly boot from external media (I would expect the former, but that's just me). Well the intention here is for general computing devices. Where when you get a machine you would pxe install or boot from a install image provided by the os vendor. I think we should follow how x86 works and default to external media first, then internal media followed by network. All with the user being able to override the settings either permanently or in a one off fashion. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Tue, 06 Jan 2015 17:43:19 -0700 Stephen Warren swar...@wwwdotorg.org 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: 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. ChromeOS seems to have adopted its own unique setup. it is not a typical configuration. 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, oo), which was another reason for heading this route. I really like the idea of using the bootable flag and looking at it but if its legacy in GPT will it go away in some future partition table layout? UEFI Requires that a ESP exist. I think requiring that the bootable flag exist is acceptable. 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. That is what happens on x86 today though. if you had a bootable cdrom/dvdrom or usb stick it will boot from that before the local install. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Wed, 2015-01-07 at 13:22 -0700, Stephen Warren wrote: 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 +, Ian Campbell wrote: 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. Fair enough. One thing i would like to mention though that respective of the preference here, It would be nice to have some guidelines here. One thing which always irks me is that for every new ARM i get on my desk, I need to re-discover how this particular one happens to boot.. The distro bootcmd stuff goes a very long way here, but would be even nicer if the sequence was predictable as well (e.g. always external, internal, network boots unless the board has a boot selector switch). (One can wish right :p) -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
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 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. (Added Ian Cambell to the cc as he introduce the usage on exynos devices) -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
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)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Wed, 2015-01-07 at 10:22 +, 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 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)..
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.
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Wed, 2015-01-07 at 12:01 +0100, Sjoerd Simons wrote:
On Wed, 2015-01-07 at 10:22 +, 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.
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Wed, 2015-01-07 at 12:46 +0100, Sjoerd Simons wrote: On Wed, 2015-01-07 at 11:17 +, Ian Campbell wrote: On Wed, 2015-01-07 at 12:01 +0100, Sjoerd Simons wrote: On Wed, 2015-01-07 at 10:22 +, 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 prefer to treat GPT as a partition table layout seperate from EFI. In the GPT context, i tend to read legacy as Intel BIOS. But that's really opinions. Respecting bit 1 would be a nice improvement though. Wrt. the boot flag. I can be convinced that partitions with that flag should be prioritized in their scanning above others, although i'm really not sure how valuable that actually is (i don't think it is). What i'm opposed to would be *only* searching partitions with that flag as that just tends to be unnecessarily error-prone. I agree it'd be better to eventually scan everything, but I do think it'd be useful to follow any hints the partition table might offer. 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. This is the general problem of the user doing an action but the system really being unable to devine the intention behind that action.. An external storage device can have been plugged in for a lot of reasons, not just to boot from (you might have wnated to copy/inspect/change some data on the card). I would argue that the main reason for folks to plug in external storage devices into computers is not because they'd like to boot from it and furthermore that a lot of people would be confused if leaving in a storage card/stick makes the system unbootable. If the external media is present but unbootable then I'd expect it to (by default) try the internal media next, not fail to boot. I suspect this argument comes down to how you expect users to normally use the system.. Iotw as a general computing device, just like your laptop or desktop machine or as a development toy where you regularly boot from external media (I would expect the former, but that's just me). A laptop or desktop machine is typically configured (from the factory at least) to boot from the
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
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 +, 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.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On 01/07/2015 03:10 AM, 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. IIRC something more like 12-16, at least for the developer builds I have used in the past. 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. (Added Ian Cambell to the cc as he introduce the usage on exynos devices) The user can select which devices get looked at by setting $boot_targets to a list of devices names, e.g. mmc1 mmc0 usb pxe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
On Wed, 2015-01-07 at 11:17 +, Ian Campbell wrote:
On Wed, 2015-01-07 at 12:01 +0100, Sjoerd Simons wrote:
On Wed, 2015-01-07 at 10:22 +, 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 prefer to treat GPT as a partition table layout seperate from EFI. In
the GPT context, i tend to read legacy as Intel BIOS. But that's
really opinions. Respecting bit 1 would be a nice improvement though.
Wrt. the boot flag. I can be convinced that partitions with that flag
should be prioritized in their scanning above others, although i'm
really not sure how valuable that actually is (i don't think it is).
What i'm opposed to would be *only* searching partitions with that flag
as that just tends to be unnecessarily error-prone.
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.
Oh awesome, didn't see that patch yet. Thanks for the pointer.
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
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
(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, oo), 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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
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, oo), 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.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
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.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
include/config_distro_bootcmd.h | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index be616e8..68f5fcb 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -13,7 +13,7 @@
#define BOOTENV_SHARED_BLKDEV_BODY(devtypel) \
if #devtypel dev ${devnum}; then \
setenv devtype #devtypel ; \
- run scan_dev_for_boot; \
+ run scan_dev_for_boot_part; \
fi\0
#define BOOTENV_SHARED_BLKDEV(devtypel) \
@@ -163,7 +163,6 @@
boot_prefixes=/ /boot/\0 \
boot_scripts=boot.scr.uimg boot.scr\0 \
BOOTENV_BOOT_TARGETS \
- bootpart=1\0 \
\
boot_extlinux= \
sysboot ${devtype} ${devnum}:${bootpart} any\
@@ -194,12 +193,21 @@
done\0 \
\
scan_dev_for_boot= \
- echo Scanning ${devtype} ${devnum}...; \
+ echo Scanning ${devtype} ${devnum}:${bootpart}...; \
for prefix in ${boot_prefixes}; do \
run scan_dev_for_extlinux; \
run scan_dev_for_scripts; \
done\0 \
\
+ scan_dev_for_boot_part= \
+ part list ${devtype} ${devnum} devplist;\
+ for bootpart in ${devplist}; do \
+ if fstype ${devtype} ${devnum}:${bootpart} \
+ bootfstype; then\
+ run scan_dev_for_boot; \
+ fi; \
+ done\0 \
+ \
BOOT_TARGET_DEVICES(BOOTENV_DEV) \
\
bootcmd= BOOTENV_SET_USB_NEED_INIT BOOTENV_SET_SCSI_NEED_INIT \
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
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? This patch looks fine assuming this option (rather than bootable flag) is selected. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
