From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8F0C221AE30CC for ; Mon, 12 Jun 2017 09:39:08 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id i7so57842913ioe.1 for ; Mon, 12 Jun 2017 09:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jtrXFyoP/CIIDobitccsH0z9Ony61E88c4CNTiiuxXI=; b=D+Uw6L/0jqmDIFN4dt5rgvvFy75rW8Of5bPT0ms4CuAkGw30GUyLU0Wd5oNrjVAMj9 oOYGbjHlWzTIYUh6kQ6Y+LYaDPIhKaDu6N/qGyApNu5k01bU2/eSnvPYYR5J1qpBdpal A77hY4DZ1Ydv6Gv2URBfytR2j7TXtvoV7ylQY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jtrXFyoP/CIIDobitccsH0z9Ony61E88c4CNTiiuxXI=; b=KUGiW+xDLU12SV57sfrKHK3NoZHhIa/NM6eNXkM+DXeV/Mwm5moESQBA33koNyaEVD rFjAUZA1dLQHahyvar4W/0YBsc6hN2d2/FUHwwPISi0OZcX3x3gB+paLtl+FpR3PEH8l y6gjXWrddVX9mKTUw+rhVtOBAWkjOp1hoa4a5rdZCc1c8Tp4MkI9FcGoU0mnEeWe8/HV tf2Jf7pPNGZl+RAzKFx2T9ScA7l7x9If6TQB2bdAOlEGTvDiJ52jgWoJuvBvQ46nbEL9 rnLtRUK+AwPqPI8YjFG/np8yKcTGfEuqVt03M5LgeR2WWjDbGxbFpTy9FZOUs0GUja8l rUVw== X-Gm-Message-State: AODbwcC/zCHy5zfQCV3fkgFFLM/JET4FIsS1n9XiAGrsA0vJSkWDtn9n kI9ez91dSBC/VURjYbQ8EK4n9YJY1Bax X-Received: by 10.107.63.139 with SMTP id m133mr39380528ioa.87.1497285621541; Mon, 12 Jun 2017 09:40:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.76 with HTTP; Mon, 12 Jun 2017 09:40:21 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Mon, 12 Jun 2017 18:40:21 +0200 Message-ID: To: Laszlo Ersek Cc: Andre , "edk2-devel@lists.01.org" , "Leif Lindholm (Linaro address)" Subject: Re: Can OVMF run on an emulated QEMU ARM vexpress-a9? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 16:39:08 -0000 Content-Type: text/plain; charset="UTF-8" On 12 June 2017 at 18:28, Laszlo Ersek wrote: > CC Ard & Leif > Thanks Laszlo > On 06/12/17 08:44, Andre wrote: >> Hi, >> >> this might be a silly question, as I am learning as I go about the topic, >> but is it possible to emulate UEFI on QEMU when setting the emulated >> machine to an ARM vexpress-a9? >> No. The mach-virt UEFI firmware expects a DT description at the base of DRAM, which QEMU only provided for mach-virt. Also, 'base of DRAM' could be anything on an ARM system,. >> I was able to emulate it on QEMU's virt machine, but I don't care as much >> about the vexpress-a9, but as to know whether OVMF can only run against >> QEMU's virt machine or if it can run against some other emulated board. >> >> Are there too many differences between the virt machine to other boards >> that make providing images for different emulated boards impractical? >> Yes. The mach-virt firmware uses DT, but most ARM ports are fully hardcoded. I.e., the MMIO address of every peripheral, timer interrupts, base and size of memory etc etc are all decided at build time. >> I really don't know enough even to know if my question is sensible, so any >> pointers on the topic are really appreciated! > > Your question is fully justified and to the point. > > The answer is that, yes, there's a *whole lot* of integration between > QEMU machine type and firmware. This is reflected by several things: > > - The kinds of firmware drivers we include the firmware build follows > the QEMU machine type. Under "driver", understand both software drivers > (i.e. something that produces ACPI tables and SMBIOS tables -- because > QEMU exports those in a particular format), and hardware drivers (for > the kinds of emulated hardware that we know the targeted QEMU machine > type will, or can, provide). > > - The way we customize or control generic (= platform-independent) > firmware drivers. > > - The things we assume about hardware in the lowest-level / earliest > firmware modules (for example, what parts of the address space are known > to map to system RAM / MMIO / platform devices; what IO ports belong to > what platform devices, etc) > > There *is* a bunch of stuff we try to abstract even between QEMU and > firmware, for enabling incremental development & compat, but then again > those abstractions rest upon virtual hardware specifics (DTB pre-filled > into RAM, fw_cfg, virtio, ...). > > So, a quick summary about virtual platform support (that I know of) in edk2: > > - ArmVirtPkg/ArmVirtQemu.dsc: > > - qemu-system-arm and qemu-system-aarch64, with the "virt" machine > type (the higher-versioned "virt" machine types you use, the better > integration you get) > > - ArmVirtPkg/ArmVirtQemuKernel.dsc: > > - Not really sure about the QEMU configuration for this, but see > commit 8de84d424221 ("ArmVirtPkg: implement ArmVirtQemuKernel", > 2016-02-05) for the intended use. I think Ard can explain it better. > The standard mach-virt machine you get when using -bios boots with the firmware image exposed as an emulated XIP NOR flash. Many ARM systems that boot with ARM trusted firmware don't run UEFI in place but load it into DRAM and execute it from there. So ArmVirtQemuKernel runs from DRAM instead. It borrows the Linux kernel boot protocol to achieve this, since it was already implemented by QEMU via -kernel (and -bios/-pflash omitted) > - ArmVirtPkg/ArmVirtXen.dsc: > > - Xen, with HVM (fullvirt) guests, potentially using the XenPV block > device. Both arm/aarch64. (I'm not a Xen user myself, hence the > scant details -- I'm sorry.) > > - OvmfPkg/*dsc: > > - qemu-system-i386 and qemu-system-x86_64, with the "pc" and "q35" > machine types (the higher-versioned machine types you use, the > better integration you get) > > - Xen, with HVM (fullvirt) guests, potentially using the XenPV block > device > > There used to be ArmPlatformPkg/ArmVExpressPkg (now defunct I think?), > and there's > > as well. > We have support for a couple of ARM reference platforms, but I don't think VExpress A9 is among those anymore. > I think the latter might just give you what you want. > > You might get away running builds of existent firmware platforms (DSC > files) in non-matching environments, but the platform integration will > suffer. This ranges from "crashes without a single log message" to "some > optional UEFI protocols are missing". > In general, this is something more likely to achieve the latter on x86, given that 'x86 architecture' usually means 'PC platform', which are uniform enough to at least get some output on a serial port. On ARM, platforms are so disparate that there is really no point in trying to experiment with non-matching firmware unless you have some a priori reason to believe the platforms are sufficiently similar