[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 at 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