Hi Andre, On 6 July 2017 at 07:07, Andre Przywara <[email protected]> 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 mailing list [email protected] https://lists.denx.de/listinfo/u-boot
