Re: [Qemu-devel] edk2 submodule + binaries (Re: [PATCH V5 2/7] tests/acpi: add pxb/pxb-pcie tests)

[Gerd Hoffmann]

  Hi,

> >  (2) ia32 ovmf too?  Will anybody use it?
> 
> Then the next question is, what's the status of 32-bit UEFI OSes? Simple:

> [ summary: bad ]

Yep, that matches the impression I have.
Guess we don't want bother then.

> Enabling Secure Boot in the OVMF binary is orthogonal to all of the
> above, but it has a licensing impact. It embeds (a subset of) OpenSSL in
> the binary, and changes the terms from "2-clause BSDL" to "2-clause BSDL
> and OpenSSL license" ("and" in the restrictive, not permissive, sense).
> I'm unsure if QEMU is willing and able to distribute such binaries.
> 
> For the widest and simplest usability, X64 (without the SMM driver stack
> and without Secure Boot) is likely the best.

Yes (also note the smm-enabled one doesn't run on i440fx).

So the options I see are (a) build without smm or (b) build two
variants.

> Anyway, I digress. Point is, GRUB is already UEFI capable (I don't know
> uboot), so GRUB should be able to look up the DTB sysconfig table, and
> use that. The sysconfig table in question is identified by the GUID
> 
>   B1B621D5-F19C-41A5-830B-D9152C69AAE0

grub already does that on aarch64, but not on arm.
So that should be fixable without too much effort.

u-boot is out for -M virt due to missing virtio drivers.

>   $ qemu-system-(arm|aarch64) \
>       -nographic -machine virt,dumpdtb=virt-dump.dtb
>   $ dtc -I dtb -O dts <virt-dump.dtb | less
> 
> but that's not the right way to carry the DTB from QEMU to guest code

Exactly.  That just creates a reverse problem.  Instead of copying the
kernel from the image you now have to copy the dtb file to the image.

> > There is one for the
> > vexpress boards, which actually works (for v9).  But it lists only the
> > hardware physical vexpress boards have, any virtio-mmio devices you add
> > are not listed there.
> 
> Right, the generated DTB lists all the virtio-mmio transports.

But u-boot looks for dtb files in /boot/dtbs/$kernelver/ instead of
using the one provided by qemu.  So virtio isn't there (virtio-mmio @
vexpress works for a direct kernel boot).

cheers,
  Gerd