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

[Gerd Hoffmann]

  Hi,

> > There is no integration yet with QEMU, right? Having a set of binaries
> > like with SeaBIOS
> > makes sense?
> 
> Yes, it makes sense.

Indeed.  edk2 isn't exactly small though.  Adding the submodule would
make the release tarballs noticable larger, and the prebuild binaries
are not exactly small too ...

I remember we discussed moving all the pre-built binaries to a separate
repo a while back.  Maybe we should think about that idea again?

> > Are there any licensing issues?
> 
> If QEMU can bundle 2-clause BSDL binaries, then there shouldn't be.

I think with the FatPkg issue finally solved now there shouldn't be
fundamental roadblocks any more.

Next question would be which architectures we want build edk2 for?

 (1) x64 ovmf is clear.

 (2) ia32 ovmf too?  Will anybody use it?

 (3) ArmVirtPkg for aarch64 should be built IMO.

 (4) What about ArmVirtPkg for 32bit arm?

 (5) There is ArmPlatformPkg/ArmVExpressPkg.
     Anyone tried that with qemu-system-{arm,aarch64} -M vexpress-* ?

While being at it:  Is there any way to setup a 32bit arm guest with a
bootloader, so you don't have to somehow copy the guest kernel from the
image to boot?

At least the upstream kernel doesn't support acpi @ 32bit arm, so the
guest kernel can't find and use the hardware info provided by
ArmVirtPkg.  Instead it depends on the bootloader passing a fdt.  But
the bootloaders (grub+uboot) expect a file with the fdt somewhere.
There isn't a file in the first place for -M virt.  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.  So sdcard storage is the only option.  Hmm.

Comments?

cheers,
  Gerd