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