qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] edk2 submodule + binaries (Re: [PATCH V5 2/7] tests/acp


From: Peter Maydell
Subject: Re: [Qemu-devel] edk2 submodule + binaries (Re: [PATCH V5 2/7] tests/acpi: add pxb/pxb-pcie tests)
Date: Tue, 19 Jul 2016 10:30:35 +0100

On 19 July 2016 at 10:06, Gerd Hoffmann <address@hidden> wrote:
> 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?

I think this would be a good idea.

>  (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.

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.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]