[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Andre Przywara]

The UEFI spec allows an EFI system partition (ESP, with the bootloader or
kernel EFI apps on it) to reside on a disk using a "legacy" MBR
partitioning scheme.
But in contrast to actual legacy disks the ESP is not marked as
"bootable" using bit 7 in byte 0 of the legacy partition entry, but is
instead using partition *type* 0xef (in contrast to 0x0b or 0x0c for a
normal FAT partition). The EFI spec isn't 100% clear on this, but it even
seems to discourage the use of the bootable flag for ESPs.
Also it seems that some EFI implementations (EDK2?) even seem to ignore
partitions marked as bootable (probably since they believe they contain
legacy boot code).
The Debian installer [1] (*not* mini.iso), for instance, contains such an
MBR, where none of the two partitions are marked bootable, but the ESP
has clearly type 0xef.
Now U-Boot cannot find the ESP on such a disk (USB flash drive) and
fails to load the EFI grub and thus the installer.

Since it all boils down to the distro bootcmds eventually calling
"part list -bootable" to find potential boot partitions, it seems logical
to just add this "partition type is 0xef" condition to the is_bootable()
implementation.

This allows the bog standard arm64 Debian-testing installer to boot from
an USB pen drive on Allwinner A64 boards (Pine64, BananaPi-M64).
(Ubuntu and other distribution installers don't have a legacy MBR, so
U-Boot falls back to El Torito there).

[1] https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 disk/part_dos.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk/part_dos.c b/disk/part_dos.c
index 7ede15e..7aff73d 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -44,7 +44,7 @@ static inline int is_extended(int part_type)
 
 static inline int is_bootable(dos_partition_t *p)
 {
-	return p->boot_ind == 0x80;
+	return (p->sys_ind == 0xef) || (p->boot_ind == 0x80);
 }
 
 static void print_one_part(dos_partition_t *p, lbaint_t ext_part_sector,
-- 
2.9.0

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Alexander Graf]

On 07/06/2017 11:14 AM, Andre Przywara wrote:
> The UEFI spec allows an EFI system partition (ESP, with the bootloader or
> kernel EFI apps on it) to reside on a disk using a "legacy" MBR
> partitioning scheme.
> But in contrast to actual legacy disks the ESP is not marked as
> "bootable" using bit 7 in byte 0 of the legacy partition entry, but is
> instead using partition *type* 0xef (in contrast to 0x0b or 0x0c for a
> normal FAT partition). The EFI spec isn't 100% clear on this, but it even
> seems to discourage the use of the bootable flag for ESPs.
> Also it seems that some EFI implementations (EDK2?) even seem to ignore
> partitions marked as bootable (probably since they believe they contain
> legacy boot code).
> The Debian installer [1] (*not* mini.iso), for instance, contains such an
> MBR, where none of the two partitions are marked bootable, but the ESP
> has clearly type 0xef.
> Now U-Boot cannot find the ESP on such a disk (USB flash drive) and
> fails to load the EFI grub and thus the installer.
>
> Since it all boils down to the distro bootcmds eventually calling
> "part list -bootable" to find potential boot partitions, it seems logical
> to just add this "partition type is 0xef" condition to the is_bootable()
> implementation.
>
> This allows the bog standard arm64 Debian-testing installer to boot from
> an USB pen drive on Allwinner A64 boards (Pine64, BananaPi-M64).
> (Ubuntu and other distribution installers don't have a legacy MBR, so
> U-Boot falls back to El Torito there).
>
> [1] https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

I think this change is perfectly reasonable, yes.

Reviewed-by: Alexander Graf <agraf@suse.de>


Alex

> ---
>   disk/part_dos.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 7ede15e..7aff73d 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -44,7 +44,7 @@ static inline int is_extended(int part_type)
>   
>   static inline int is_bootable(dos_partition_t *p)
>   {
> -	return p->boot_ind == 0x80;
> +	return (p->sys_ind == 0xef) || (p->boot_ind == 0x80);
>   }
>   
>   static void print_one_part(dos_partition_t *p, lbaint_t ext_part_sector,

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Thomas Schmitt]

Hi,

i am the upstream developer of program xorriso which packs up Debian arm64
ISOs.

Here is my minority opinion from a discussion with Andre Przywara:

To my opinion, if U-boot is used as EFI implementation, then it should
not consider as bootable any "active" MBR partitions or "Legacy BIOS
Bootable" GPT partitions (see is_bootable() in disk/part_efi.c).

While the proposed change of behavior is an undisputable improvement,
my objection is that the main boot loaders in distro ISOs are GRUB and
SYSLINUX. Both do not expect that the "active" partition gets booted by
the firmware but rather that their own MBR at the start of the ISO gets
started by BIOS or the ESP is brought up by EFI.
The MBR programs in the ISOs do not go on with booting the "active"
partition but rather hop onto the El Torito boot image programs in the ISO.

The Legacy BIOS Bootable bit of GPT is explicitely not an EFI boot
indicator. UEFI 2.4 says in table 20 : "UEFI boot manager (see chapter 3)
must ignore this bit when selecting a UEFI-compliant application".
The BootIndicator byte of MBR partitions is explicitely not for EFI.
Table 14 says: "This field shall not be used by UEFI firmware."

So if "active" partitions are present in GRUB or SYSLINUX equipped ISOs
they are under no circumstances intended for being booted.


Currently debian ISOs for arm64 have no "active" partition. But that's
an inner implementation detail. E.g. HDD bootable ISOs for x86 do have
the "active"/bootable flag on the ISO 9660 partition out of tradition to
appease mad BIOS implementations.
It is well possible to combine x86 BIOS and arm64 EFI boot equipment
in the same ISO image. So the need for an "active" partition might arise.


Have a nice day :)

Thomas

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Andre Przywara]

Hi,

On 06/07/17 11:19, Thomas Schmitt wrote:
> Hi,
> 
> i am the upstream developer of program xorriso which packs up Debian arm64
> ISOs.
> 
> Here is my minority opinion from a discussion with Andre Przywara:
> 
> To my opinion, if U-boot is used as EFI implementation, then it should
> not consider as bootable any "active" MBR partitions or "Legacy BIOS
> Bootable" GPT partitions (see is_bootable() in disk/part_efi.c).

First thing to note here is that U-Boot does not really have an
understanding yet of whether it is acting as an EFI implementation or
not. At this stage it simply looks for boot partition *candidates*,
which will then later be examined more closely to find boot scripts or
EFI apps. Adding one more partition to that list should not cause much
harm, I think.

> While the proposed change of behavior is an undisputable improvement,
> my objection is that the main boot loaders in distro ISOs are GRUB and
> SYSLINUX. Both do not expect that the "active" partition gets booted by
> the firmware but rather that their own MBR at the start of the ISO gets
> started by BIOS or the ESP is brought up by EFI.
> The MBR programs in the ISOs do not go on with booting the "active"
> partition but rather hop onto the El Torito boot image programs in the ISO.

A second thing to note is that there is some fundamental difference here
between the ARM world and x86.
For ARM U-Boot was so far just piggy-backing on the bootable MBR flag to
find /boot partition candidates. I am not sure if there is actually some
spec or standard covering this behaviour, it was just convenient and
worked quite well in the (mostly embedded) ARM world.
And on ARM U-Boot never considered the "boot code" in a boot sector
(neither on the MBR or on an active partition) - which is probably x86
code anyway.

Now I am not sure how this maps to the combination of U-Boot and x86 - I
am not very familiar with the combination of those two.
Does U-Boot actually support chain-loading boot sectors on x86? Or does
it entirely focus on loading either EFI apps or Linux kernels / U-Boot
boot scripts? Maybe Simon could shed some light on this?

Cheers,
Andre.



> 
> The Legacy BIOS Bootable bit of GPT is explicitely not an EFI boot
> indicator. UEFI 2.4 says in table 20 : "UEFI boot manager (see chapter 3)
> must ignore this bit when selecting a UEFI-compliant application".
> The BootIndicator byte of MBR partitions is explicitely not for EFI.
> Table 14 says: "This field shall not be used by UEFI firmware."
> 
> So if "active" partitions are present in GRUB or SYSLINUX equipped ISOs
> they are under no circumstances intended for being booted.
> 
> 
> Currently debian ISOs for arm64 have no "active" partition. But that's
> an inner implementation detail. E.g. HDD bootable ISOs for x86 do have
> the "active"/bootable flag on the ISO 9660 partition out of tradition to
> appease mad BIOS implementations.
> It is well possible to combine x86 BIOS and arm64 EFI boot equipment
> in the same ISO image. So the need for an "active" partition might arise.
> 
> 
> Have a nice day :)
> 
> Thomas
> 

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Alexander Graf]

On 07/06/2017 03:07 PM, Andre Przywara wrote:
> Hi,
>
> On 06/07/17 11:19, Thomas Schmitt wrote:
>> Hi,
>>
>> i am the upstream developer of program xorriso which packs up Debian arm64
>> ISOs.
>>
>> Here is my minority opinion from a discussion with Andre Przywara:
>>
>> To my opinion, if U-boot is used as EFI implementation, then it should
>> not consider as bootable any "active" MBR partitions or "Legacy BIOS
>> Bootable" GPT partitions (see is_bootable() in disk/part_efi.c).
> First thing to note here is that U-Boot does not really have an
> understanding yet of whether it is acting as an EFI implementation or
> not. At this stage it simply looks for boot partition *candidates*,
> which will then later be examined more closely to find boot scripts or
> EFI apps. Adding one more partition to that list should not cause much
> harm, I think.
>
>> While the proposed change of behavior is an undisputable improvement,
>> my objection is that the main boot loaders in distro ISOs are GRUB and
>> SYSLINUX. Both do not expect that the "active" partition gets booted by
>> the firmware but rather that their own MBR at the start of the ISO gets
>> started by BIOS or the ESP is brought up by EFI.
>> The MBR programs in the ISOs do not go on with booting the "active"
>> partition but rather hop onto the El Torito boot image programs in the ISO.
> A second thing to note is that there is some fundamental difference here
> between the ARM world and x86.
> For ARM U-Boot was so far just piggy-backing on the bootable MBR flag to
> find /boot partition candidates. I am not sure if there is actually some
> spec or standard covering this behaviour, it was just convenient and
> worked quite well in the (mostly embedded) ARM world.
> And on ARM U-Boot never considered the "boot code" in a boot sector
> (neither on the MBR or on an active partition) - which is probably x86
> code anyway.
>
> Now I am not sure how this maps to the combination of U-Boot and x86 - I
> am not very familiar with the combination of those two.
> Does U-Boot actually support chain-loading boot sectors on x86? Or does
> it entirely focus on loading either EFI apps or Linux kernels / U-Boot
> boot scripts? Maybe Simon could shed some light on this?

U-Boot on x86 does not implement BIOS callbacks, so even if you wanted 
to you couldn't execute an MBR directly.

So yes, it only loads proper payloads the same way as it does on ARM.


Alex

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Thomas Schmitt]

Hi,

Andre Przywara wrote:
> U-Boot does not really have an
> understanding yet of whether it is acting as an EFI implementation

If you use it to boot an ISO by its GRUB or SYSLINUX EFI equipment,
then you ask it to act as EFI implementation.
Maybe a compile time switch could restrict U-Boot to that role before
it gets written to the hardware where it shall be the EFI firmware ?

(Sorry, i am entirely software guy. Please don't laugh too loud about my
 idea of hardware and its relation to U-boot.)


> Does U-Boot actually support chain-loading boot sectors on x86? Or does
> it entirely focus on loading either EFI apps or Linux kernels / U-Boot
> boot scripts?

Hmm. From its use of the "active" flag of MBR partitions i maybe hastily
concluded that it would load and run what wikipedia calls the VBR of the
partition in
  https://en.wikipedia.org/wiki/Master_boot_record#System_bootstrapping

If U-Boot looks into the "active" partition's filesystem for boot-worthy
programs, then my objections and the following reasoning are possibly void.
(One would still have to investigate whether files in ISO images might
 be mistaken as boot-worthy although the ISO producer did not intend them
 for being started.)


---------------------------------------------------------------------
So only in case the "active" partition's VBR can indeed get chainloaded:

The reason why i give objections is that i want to keep the wiggle room
for bootable ISO 9660 images as wide as possible. Any further assumption
by the boot environment might block future improvements of such ISOs.


> Adding one more partition to that list should not cause much
> harm, I think.

Your point is supported by the fact that in most x86 HDD bootable ISOs
the ISO 9660 partition is the "active" one and starts at LBA 0, thus
having the image MBR as first block. Should work therefore.

But LBA 0 as MBR partition start angers partition editors. In GPT it
is plainly illegal (although happily used). So i try to push producers of
GNU/Linux distro ISOs to have the ISO 9660 partition start at LBA 64
(counted with 512 byte blocks). At least the normal SYSLINUX isohybrid
MBR will not work if started from a partition with non-zero offset.

In any case the ISO producers are not necessarily aware that an "active"
flag might cause the start of the partition VBR.


> Now I am not sure how this maps to the combination of U-Boot and x86 - I
> am not very familiar with the combination of those two.

UEFI specs invite to have boot programs for various processor architectures
in the same ESP. Currently i only know of ISOs which combine 32-bit x86
and 64-bit x86.

But if one adds a set of ARM executable binaries to the ISO filesystem
and lets /EFI/BOOT/BOOTAA64.EFI of the ESP start up GRUB with a
separate ARM-specific grub.cfg, then one can well put together a rescue
image for DVD or USB-stick which works for x86 BIOS, for x86 EFI in both
word sizes and also for ARM (in both word sizes, if desired).


Have a nice day :)

Thomas

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Thomas Schmitt]

Hi,

Alexander Graf wrote:
> U-Boot on x86 does not implement BIOS callbacks, so even if you wanted to
> you couldn't execute an MBR directly.

Oh. Sorry for the noise, then.


> So yes, it only loads proper payloads the same way as it does on ARM.

If the payloads are unlikely to be put into an ISO for other reasons,
then my doubts are appeased.

My best wishes for U-Boot's carreer as EFI firmware on ARM.
If problems appear with the very first stage of booting an ISO 9660
image, then be invited to include me or bug-xorriso at gnu.org in the
discussion.


Have a nice day :)

Thomas

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Alexander Graf]

On 07/06/2017 04:16 PM, Thomas Schmitt wrote:
> Hi,
>
> Andre Przywara wrote:
>> U-Boot does not really have an
>> understanding yet of whether it is acting as an EFI implementation
> If you use it to boot an ISO by its GRUB or SYSLINUX EFI equipment,
> then you ask it to act as EFI implementation.
> Maybe a compile time switch could restrict U-Boot to that role before
> it gets written to the hardware where it shall be the EFI firmware ?
>
> (Sorry, i am entirely software guy. Please don't laugh too loud about my
>   idea of hardware and its relation to U-boot.)

If we really want to make it follow the EFI boot flow 100%, we probably 
need something smarter than the boot scriptlet we have today. We would 
also need to support boot from NVram stored devices for example. For 
now, I consider the boot target finding mechanism more of a best effort 
thing ;).

>
>> Does U-Boot actually support chain-loading boot sectors on x86? Or does
>> it entirely focus on loading either EFI apps or Linux kernels / U-Boot
>> boot scripts?
> Hmm. From its use of the "active" flag of MBR partitions i maybe hastily
> concluded that it would load and run what wikipedia calls the VBR of the
> partition in
>    https://en.wikipedia.org/wiki/Master_boot_record#System_bootstrapping
>
> If U-Boot looks into the "active" partition's filesystem for boot-worthy
> programs, then my objections and the following reasoning are possibly void.

Yup.

> (One would still have to investigate whether files in ISO images might
>   be mistaken as boot-worthy although the ISO producer did not intend them
>   for being started.)

Well, nothing starts ISOs. Worst case there's an EFI binary at the 
removable media location on an iso - and in that case I surely hope the 
creator did intend that to get started :).

> ---------------------------------------------------------------------
> So only in case the "active" partition's VBR can indeed get chainloaded:
>
> The reason why i give objections is that i want to keep the wiggle room
> for bootable ISO 9660 images as wide as possible. Any further assumption
> by the boot environment might block future improvements of such ISOs.

Today U-Boot really only looks for known locations of bootable files. It 
does not execute random binary code straight from partitions or raw 
block devices. So I think we're safe on that front.

>
>
>> Adding one more partition to that list should not cause much
>> harm, I think.
> Your point is supported by the fact that in most x86 HDD bootable ISOs
> the ISO 9660 partition is the "active" one and starts at LBA 0, thus
> having the image MBR as first block. Should work therefore.
>
> But LBA 0 as MBR partition start angers partition editors. In GPT it
> is plainly illegal (although happily used). So i try to push producers of
> GNU/Linux distro ISOs to have the ISO 9660 partition start at LBA 64
> (counted with 512 byte blocks). At least the normal SYSLINUX isohybrid
> MBR will not work if started from a partition with non-zero offset.
>
> In any case the ISO producers are not necessarily aware that an "active"
> flag might cause the start of the partition VBR.

It shouldn't, I agree. The only thing that happens based on the active 
flag here is that U-Boot tries to identify the file system on said 
partition and then tries to load hard coded file names from it.

>
>> Now I am not sure how this maps to the combination of U-Boot and x86 - I
>> am not very familiar with the combination of those two.
> UEFI specs invite to have boot programs for various processor architectures
> in the same ESP. Currently i only know of ISOs which combine 32-bit x86
> and 64-bit x86.
>
> But if one adds a set of ARM executable binaries to the ISO filesystem
> and lets /EFI/BOOT/BOOTAA64.EFI of the ESP start up GRUB with a
> separate ARM-specific grub.cfg, then one can well put together a rescue
> image for DVD or USB-stick which works for x86 BIOS, for x86 EFI in both
> word sizes and also for ARM (in both word sizes, if desired).

I'm fairly sure we can easily put together a disc that can be booted by 
BIOS x86, BIOS x86_64, UEFI x86(_64), edk2 based UEFI on ARM(64) and 
U-Boot based UEFI on ARM(64).


Alex

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Andre Przywara]

Hi,

On 06/07/17 15:31, Alexander Graf wrote:
> On 07/06/2017 04:16 PM, Thomas Schmitt wrote:
>> Hi,
>>
>> Andre Przywara wrote:
>>> U-Boot does not really have an
>>> understanding yet of whether it is acting as an EFI implementation
>> If you use it to boot an ISO by its GRUB or SYSLINUX EFI equipment,
>> then you ask it to act as EFI implementation.
>> Maybe a compile time switch could restrict U-Boot to that role before
>> it gets written to the hardware where it shall be the EFI firmware ?
>>
>> (Sorry, i am entirely software guy. Please don't laugh too loud about my
>>   idea of hardware and its relation to U-boot.)
> 
> If we really want to make it follow the EFI boot flow 100%, we probably
> need something smarter than the boot scriptlet we have today. We would
> also need to support boot from NVram stored devices for example. For
> now, I consider the boot target finding mechanism more of a best effort
> thing ;).

I totally agree. The U-Boot code itself does not really impose a boot
policy, that is at the moment just covered by the *default* boot
scripts, which implement some heuristic Do-what-I-mean(TM) policy.

Anyone with a desperate wish for being 100% EFI compliant is always
welcome to just change this boot script for their platform or even
build. One could even implement a menu with the typical PC BIOS choice
of "UEFI only, UEFI first, then legacy, legacy only", if one really
feels like.
However all of those policies would probably base their actions on the
"part list -bootable" result, which is what this patch extends to make
it actually possible to implement properly.

>>> Does U-Boot actually support chain-loading boot sectors on x86? Or does
>>> it entirely focus on loading either EFI apps or Linux kernels / U-Boot
>>> boot scripts?
>> Hmm. From its use of the "active" flag of MBR partitions i maybe hastily
>> concluded that it would load and run what wikipedia calls the VBR of the
>> partition in
>>    https://en.wikipedia.org/wiki/Master_boot_record#System_bootstrapping
>>
>> If U-Boot looks into the "active" partition's filesystem for boot-worthy
>> programs, then my objections and the following reasoning are possibly
>> void.
> 
> Yup.
> 
>> (One would still have to investigate whether files in ISO images might
>>   be mistaken as boot-worthy although the ISO producer did not intend
>> them
>>   for being started.)
> 
> Well, nothing starts ISOs. Worst case there's an EFI binary at the
> removable media location on an iso - and in that case I surely hope the
> creator did intend that to get started :).

I agree that "efi/boot/bootaa64.efi" leaves little room for
interpretation ;-)

Cheers,
Andre.

>> ---------------------------------------------------------------------
>> So only in case the "active" partition's VBR can indeed get chainloaded:
>>
>> The reason why i give objections is that i want to keep the wiggle room
>> for bootable ISO 9660 images as wide as possible. Any further assumption
>> by the boot environment might block future improvements of such ISOs.
> 
> Today U-Boot really only looks for known locations of bootable files. It
> does not execute random binary code straight from partitions or raw
> block devices. So I think we're safe on that front.
> 
>>
>>
>>> Adding one more partition to that list should not cause much
>>> harm, I think.
>> Your point is supported by the fact that in most x86 HDD bootable ISOs
>> the ISO 9660 partition is the "active" one and starts at LBA 0, thus
>> having the image MBR as first block. Should work therefore.
>>
>> But LBA 0 as MBR partition start angers partition editors. In GPT it
>> is plainly illegal (although happily used). So i try to push producers of
>> GNU/Linux distro ISOs to have the ISO 9660 partition start at LBA 64
>> (counted with 512 byte blocks). At least the normal SYSLINUX isohybrid
>> MBR will not work if started from a partition with non-zero offset.
>>
>> In any case the ISO producers are not necessarily aware that an "active"
>> flag might cause the start of the partition VBR.
> 
> It shouldn't, I agree. The only thing that happens based on the active
> flag here is that U-Boot tries to identify the file system on said
> partition and then tries to load hard coded file names from it.
> 
>>
>>> Now I am not sure how this maps to the combination of U-Boot and x86 - I
>>> am not very familiar with the combination of those two.
>> UEFI specs invite to have boot programs for various processor
>> architectures
>> in the same ESP. Currently i only know of ISOs which combine 32-bit x86
>> and 64-bit x86.
>>
>> But if one adds a set of ARM executable binaries to the ISO filesystem
>> and lets /EFI/BOOT/BOOTAA64.EFI of the ESP start up GRUB with a
>> separate ARM-specific grub.cfg, then one can well put together a rescue
>> image for DVD or USB-stick which works for x86 BIOS, for x86 EFI in both
>> word sizes and also for ARM (in both word sizes, if desired).
> 
> I'm fairly sure we can easily put together a disc that can be booted by
> BIOS x86, BIOS x86_64, UEFI x86(_64), edk2 based UEFI on ARM(64) and
> U-Boot based UEFI on ARM(64).
> 
> 
> Alex
> 

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Simon Glass]

Hi Andre,

On 6 July 2017 at 07:07, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 06/07/17 11:19, Thomas Schmitt wrote:
>> Hi,
>>
>> i am the upstream developer of program xorriso which packs up Debian arm64
>> ISOs.
>>
>> Here is my minority opinion from a discussion with Andre Przywara:
>>
>> To my opinion, if U-boot is used as EFI implementation, then it should
>> not consider as bootable any "active" MBR partitions or "Legacy BIOS
>> Bootable" GPT partitions (see is_bootable() in disk/part_efi.c).
>
> First thing to note here is that U-Boot does not really have an
> understanding yet of whether it is acting as an EFI implementation or
> not. At this stage it simply looks for boot partition *candidates*,
> which will then later be examined more closely to find boot scripts or
> EFI apps. Adding one more partition to that list should not cause much
> harm, I think.
>
>> While the proposed change of behavior is an undisputable improvement,
>> my objection is that the main boot loaders in distro ISOs are GRUB and
>> SYSLINUX. Both do not expect that the "active" partition gets booted by
>> the firmware but rather that their own MBR at the start of the ISO gets
>> started by BIOS or the ESP is brought up by EFI.
>> The MBR programs in the ISOs do not go on with booting the "active"
>> partition but rather hop onto the El Torito boot image programs in the ISO.
>
> A second thing to note is that there is some fundamental difference here
> between the ARM world and x86.
> For ARM U-Boot was so far just piggy-backing on the bootable MBR flag to
> find /boot partition candidates. I am not sure if there is actually some
> spec or standard covering this behaviour, it was just convenient and
> worked quite well in the (mostly embedded) ARM world.
> And on ARM U-Boot never considered the "boot code" in a boot sector
> (neither on the MBR or on an active partition) - which is probably x86
> code anyway.
>
> Now I am not sure how this maps to the combination of U-Boot and x86 - I
> am not very familiar with the combination of those two.
> Does U-Boot actually support chain-loading boot sectors on x86? Or does
> it entirely focus on loading either EFI apps or Linux kernels / U-Boot
> boot scripts? Maybe Simon could shed some light on this?

The recommended way is to load FIT with containing a 32-bit or 64-bit
vanilla kernel binary (which U-Boot can execute directly), and a
setup.bin file (for legacy reasons the kernel requires this). Verified
boot can be enabled if required.

See doc/uImage.FIT/x86-fit-boot.txt for details.

Regards,
Simon

>
> Cheers,
> Andre.
>
>
>
>>
>> The Legacy BIOS Bootable bit of GPT is explicitely not an EFI boot
>> indicator. UEFI 2.4 says in table 20 : "UEFI boot manager (see chapter 3)
>> must ignore this bit when selecting a UEFI-compliant application".
>> The BootIndicator byte of MBR partitions is explicitely not for EFI.
>> Table 14 says: "This field shall not be used by UEFI firmware."
>>
>> So if "active" partitions are present in GRUB or SYSLINUX equipped ISOs
>> they are under no circumstances intended for being booted.
>>
>>
>> Currently debian ISOs for arm64 have no "active" partition. But that's
>> an inner implementation detail. E.g. HDD bootable ISOs for x86 do have
>> the "active"/bootable flag on the ISO 9660 partition out of tradition to
>> appease mad BIOS implementations.
>> It is well possible to combine x86 BIOS and arm64 EFI boot equipment
>> in the same ISO image. So the need for an "active" partition might arise.

The recommended

[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[André Przywara]

On 06/07/17 10:23, Alexander Graf wrote:

Hi,

> On 07/06/2017 11:14 AM, Andre Przywara wrote:
>> The UEFI spec allows an EFI system partition (ESP, with the bootloader or
>> kernel EFI apps on it) to reside on a disk using a "legacy" MBR
>> partitioning scheme.
>> But in contrast to actual legacy disks the ESP is not marked as
>> "bootable" using bit 7 in byte 0 of the legacy partition entry, but is
>> instead using partition *type* 0xef (in contrast to 0x0b or 0x0c for a
>> normal FAT partition). The EFI spec isn't 100% clear on this, but it even
>> seems to discourage the use of the bootable flag for ESPs.
>> Also it seems that some EFI implementations (EDK2?) even seem to ignore
>> partitions marked as bootable (probably since they believe they contain
>> legacy boot code).
>> The Debian installer [1] (*not* mini.iso), for instance, contains such an
>> MBR, where none of the two partitions are marked bootable, but the ESP
>> has clearly type 0xef.
>> Now U-Boot cannot find the ESP on such a disk (USB flash drive) and
>> fails to load the EFI grub and thus the installer.
>>
>> Since it all boils down to the distro bootcmds eventually calling
>> "part list -bootable" to find potential boot partitions, it seems logical
>> to just add this "partition type is 0xef" condition to the is_bootable()
>> implementation.
>>
>> This allows the bog standard arm64 Debian-testing installer to boot from
>> an USB pen drive on Allwinner A64 boards (Pine64, BananaPi-M64).
>> (Ubuntu and other distribution installers don't have a legacy MBR, so
>> U-Boot falls back to El Torito there).
>>
>> [1]
>> https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> 
> I think this change is perfectly reasonable, yes.
> 
> Reviewed-by: Alexander Graf <agraf@suse.de>

so browsing through the whole thread again my understanding is that the
concerns have been cleared.
So are there any objections to this patch?
Who would be the person I should send this to?

Cheers
Andre.

> 
> 
> Alex
> 
>> ---
>>   disk/part_dos.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/disk/part_dos.c b/disk/part_dos.c
>> index 7ede15e..7aff73d 100644
>> --- a/disk/part_dos.c
>> +++ b/disk/part_dos.c
>> @@ -44,7 +44,7 @@ static inline int is_extended(int part_type)
>>     static inline int is_bootable(dos_partition_t *p)
>>   {
>> -    return p->boot_ind == 0x80;
>> +    return (p->sys_ind == 0xef) || (p->boot_ind == 0x80);
>>   }
>>     static void print_one_part(dos_partition_t *p, lbaint_t
>> ext_part_sector,
> 
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot