From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MuDHQ-00087H-Rp for qemu-devel@nongnu.org; Sat, 03 Oct 2009 18:40:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MuDHM-00085M-3C for qemu-devel@nongnu.org; Sat, 03 Oct 2009 18:40:44 -0400 Received: from [199.232.76.173] (port=35505 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MuDHL-00085J-WD for qemu-devel@nongnu.org; Sat, 03 Oct 2009 18:40:40 -0400 Received: from mail-yw0-f176.google.com ([209.85.211.176]:35181) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MuDHL-0004My-Cu for qemu-devel@nongnu.org; Sat, 03 Oct 2009 18:40:39 -0400 Received: by ywh6 with SMTP id 6so1514553ywh.4 for ; Sat, 03 Oct 2009 15:40:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4AC7CA13.1090007@coresystems.de> References: <4AC51DBA.7020609@codemonkey.ws> <4AC64A5C.6010003@gmx.net> <4AC64C32.4020509@codemonkey.ws> <4AC67326.6080603@gmx.net> <2a50f7880910021528v742c39e8sd334b318c577fb71@mail.gmail.com> <4AC6872E.6060103@gmx.net> <2a50f7880910021732k68ae1a97qc7307ac52a225371@mail.gmail.com> <20091003173006.595.qmail@stuge.se> <2a50f7880910031449k13090dcdr8440d89ccb7fcfe9@mail.gmail.com> <4AC7CA13.1090007@coresystems.de> Date: Sat, 3 Oct 2009 15:40:38 -0700 Message-ID: <2a50f7880910031540p12bcacbajc53fe2831ec6f929@mail.gmail.com> Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0 From: Jordan Justen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Reinauer Cc: ron minnich , Anthony Liguori , Coreboot , Carl-Daniel Hailfinger , qemu-devel@nongnu.org On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer wrote= : > Jordan Justen wrote: >> On Sat, Oct 3, 2009 at 10:30, Peter Stuge wrote: >> >>> Jordan Justen wrote: >>> >>>> Anyway, it sounds like a useful project might be to develop a UEFI >>>> coreboot payload based on the tianocore.org code. >>>> >>> I believe it might have been done already. >>> >>> http://www.coreboot.org/File:Tianocoreboot.png >>> >> >> That screenshot mentions DUET which is the tianocore.org UEFI emulator >> that boots on top of a legacy BIOS. =A0But, it's unclear if it was just >> DUET, or something based modified specifically for coreboot based on >> DUET. >> >> I will not dispute that DUET might be a potential solution to achieve >> UEFI compatibility for QEMU. =A0(I'm not sure, but I think DUET may not >> be able to boot UEFI OS's at this time.) =A0However, we thought a >> project such as OVMF was a more direct approach to achieve UEFI >> compatibility for QEMU. >> > > We have DUET running as a coreboot payload with a small coreboot > specific PE payload loader. Meaning you bring up a legacy BIOS compatible interface before starting DUET? DUET depends on a legacy BIOS. My point is that a tianocore.org based coreboot payload ought be able to do away with this legacy BIOS dependency. > DUET is, however, not an emulator, it is executing much of the same code > as all other TianoCore based UEFI implementations. According to the ReadMe.txt for our edk2 DuetPkg, DUET stands for Developer's UEFI Emulation. (Seems a bit of a stretch as an acronym. :) But, 'emulation' is a very squishy word at times, and this doesn't imply that it can't accomplish a lot in terms of UEFI compatibility. > It is possible to boot an OS just fine with DUET. > > Can you explain what you think would be more direct about OVMF than > about DUET? As far as I understand it's another build target of EDK2 but > besides that shares exactly the same design and even 99% of the code. DUET expects that you boot a legacy BIOS, and then you load DUET off the disk. Once DUET is loaded, there is a (mostly) UEFI compatible environment. OVMF initializes the VM hardware and at the same time brings up the (mostly) UEFI compatible environment. This is basically the same thing that would normally be done in most UEFI compatible systems. To me, this is a more direct approach to UEFI compatibility for QEMU. Both DUET and OVMF have some slight issues with providing a fully compatible UEFI variable interface. But I know OVMF can still boot a UEFI OS, and I thought DUET might have a problem in this area. But, I was fairly sure this could have been fixed in DUET, and it appears that perhaps it has been. Yes, DUET and OVMF likely share 90+% of the same code. -Jordan