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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
