[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type
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-... 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,
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-... 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,
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-...
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@lists.denx.de https://lists.denx.de/listinfo/u-boot
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
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
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
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@gnu.org in the discussion.
Have a nice day :)
Thomas
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
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
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
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
participants (5)
-
Alexander Graf -
Andre Przywara -
André Przywara
-
Simon Glass -
Thomas Schmitt