On 07/19/16 12:05, Gerd Hoffmann wrote: > Hi, > >>> (4) What about ArmVirtPkg for 32bit arm? >> >> I think this would be a good idea. > >> We should be aiming to get 'virt' to work for the 32-bit case. >> vexpress-a9/a15 is trying to model real hardware and has a >> lot of irritating constraints as a result (like no PCI, only >> SD card storage). >> >> This probably means sorting out passing through the DTB >> from QEMU into UEFI and then into the boot loader.
Yes, the piece that is missing is that the boot loader should be capable of looking up the UEFI sysconfig table with the well-known GUID that exposes the DTB. (NB: such a sysconfig table is not *required* by any means, especially not on aarch64. It is valid for the firmware to not expose any DTB to stuff that comes after it, in an "ACPI only" configuration.) ... Actually, I'm getting confused about this. I just suggested that the boot loader look up the right UEFI sysconfig table. But, if the boot loader is already UEFI capable, why does it need the DTB at all? Gerd named the virtio-mmio nodes in the DTB, but now I don't see how they are relevant -- the boot loader should just use the UEFI services to load and start the OS. Why does it need to know about virtio-mmio at all? > Looking at aarch64 it looks like the guest kernel doesn't use acpi but > got a fdt somehow. Dunno how that happened. The aarch64 upstream kernel (to my knowledge) defaults to DTB, unless it gets "acpi=force" on the command line, or ArmVirtQemu is built with -D PURE_ACPI_BOOT_ENABLE" (in which case the kernel will have no DTB to look at, only ACPI). > I guess ArmVirtPkg exports > the FDT using EFI interfaces, Yes (unless built with "-D PURE_ACPI_BOOT_ENABLE"). > then either the kernel gets it directly The DTB is installed as a UEFI sysconfig table with a well-known GUID. All guest code that can look up UEFI sysconfig tables can locate and read it. > or > grub is able to get and pass on the FDT. In any case it seems think the > same should work for 32bit without too much trouble. It should be possible, but as I said, now I'm doubting that grub should be involved in this at all. First, the DTB reaches the kernel, from the firmware, without any assitance from grub, through the sysconfig table. Second, grub should not need the DTB for its own purposes *at all* -- a boot loader on a UEFI system should use UEFI services only, for booting the OS. The DTB might be necessary for low-level hardware drivers, I guess, but in a UEFI guest, grub should not use low-level hw drivers. ... I mean, this is how grub already works in x86_64 and aarch64 UEFI guests. I think we're sitting on the horse backwards. DTB has probably been a "last resort" for 32-bit ARM GRUB, because there used to be no UEFI, hence no UEFI services, hence only the DTB allowed GRUB to do something with the hardware But now that there *is* UEFI for 32-bit ARM (guests, anyway), the bootloader should not use UEFI only as a means to fetch the DTB, and then do whatever it's been doing earlier. Instead, UEFI should be used to boot the OS. Thanks Laszlo