On Aug 24, 2012, at 10:01 AM, Rob Herring robherring2@gmail.com wrote:
On 08/22/2012 06:12 PM, Stephen Warren wrote:
On 08/22/2012 01:11 PM, Rob Herring wrote:
On 08/21/2012 10:58 PM, Stephen Warren wrote:
On 08/08/2012 12:30 PM, Rob Herring wrote: ...
Making u-boot more intelligent discovering things also helps here. For example, booting from the disk partition with the bootable flag set. I've submitted patches for this a while back.
That sounds like these:
http://www.mail-archive.com/u-boot@lists.denx.de/msg79100.html
Is it likely these will make it into U-Boot? Nobody seems to have replied to your patches.
Not likely, they've bit-rotted and there's at least one issue I've fixed. I need to repost the series, but the overwhelming response on the first posting doesn't motivate me.
Do you want me to pick them up (i.e. do the rebase, etc.)?
I just recently proposed a "partuuid" command to extract a partition's UUID, but I've since re-written it to be a "part" command with a "uuid" sub-command. Adding a "get-bootable" sub-command to retrieve the flag your patch sets would be a good idea. Should I pull your patches into my series to do this?
Your series only implements bootable flag retrieval for MSDOS/MBR partitions. I wonder what flag one should key off for EFI/GPT partition tables? Looking at parted/gparted, the following options exist:
A parted flag called "boot", which sets the partition's type UUID. This appears to have been supported since before parted was in git (i.e. 2006 some time).
A parted flag called "legacy_boot", which actually sets a single bit in the partition attributes. This feature is available in parted v2.4 and later, which isn't even in Ubuntu Quantal yet, although it was released a while ago. This seems to be the more correct option, although not very available to users.
Perhaps either case should trigger U-Boot to consider the partition bootable?
I only briefly looked at EFI partitioning. My conclusion was some EFI variable gets set to point to the boot loader, but if there's bootable flags that's better for u-boot. I haven't worried about it because I can't even get debian installer to use EFI partitions. It's partitioning config basically says if the arch is arm, use DOS partitions.
I'm more talking about pure EFI/GPT partitions on a disk here, rather than a full EFI environment. In other words, U-Boot is the entirety of the firmware, and it's reading the partition table directly.
Right. But I'm just wondering how typical the boot or legacy boot flags are. If those are not used in a "standard" boot process, then it's probably not worth getting u-boot to use them
It would be nice to be able to have U-Boot tell what the bootable partition is (saves searching for boot.scr on multiple partitions and drives) but for legacy that search will have to happen anyway.
I don't think the process of going over 3 or 4 partitions per drive looking for a file takes all that long; here it's not noticeable on Efika or Beagle.
I've also got a tiny problem with defaulting to EFI partitioning; i.MX booting from SD card or SATA requires the boot loader at 1024 bytes and that won't be possible since EFI needs at least 17KiB (with 512 byte blocks) for the partition table. It doesn't affect Efika but it would affect most of the MX53/MX6 boards if set to boot from SD with a Linaro-provided U-Boot.