From: Alexander Graf <agraf@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type
Date: Thu, 6 Jul 2017 15:21:34 +0200 [thread overview]
Message-ID: <bcafc2b3-e16b-6be9-cb8a-495fd92eab48@suse.de> (raw)
In-Reply-To: <94eb98d8-42b3-5b60-1060-83a1095d567e@arm.com>
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
next prev parent reply other threads:[~2017-07-06 13:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-06 9:14 [U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type Andre Przywara
2017-07-06 9:23 ` Alexander Graf
2017-09-18 20:45 ` André Przywara
2017-07-06 10:19 ` Thomas Schmitt
2017-07-06 13:07 ` Andre Przywara
2017-07-06 13:21 ` Alexander Graf [this message]
2017-07-06 14:28 ` Thomas Schmitt
2017-07-06 14:16 ` Thomas Schmitt
2017-07-06 14:31 ` Alexander Graf
2017-07-06 16:46 ` Andre Przywara
2017-07-07 3:57 ` Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bcafc2b3-e16b-6be9-cb8a-495fd92eab48@suse.de \
--to=agraf@suse.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox