From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MuDdK-0001Qm-Ly for qemu-devel@nongnu.org; Sat, 03 Oct 2009 19:03:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MuDdG-0001Qa-6S for qemu-devel@nongnu.org; Sat, 03 Oct 2009 19:03:22 -0400 Received: from [199.232.76.173] (port=47608 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MuDdG-0001QX-0P for qemu-devel@nongnu.org; Sat, 03 Oct 2009 19:03:18 -0400 Received: from ra.coresystems.de ([80.81.252.129]:37980) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MuDdF-0007sE-A2 for qemu-devel@nongnu.org; Sat, 03 Oct 2009 19:03:17 -0400 Message-ID: <4AC7D82B.9030405@coresystems.de> Date: Sun, 04 Oct 2009 01:03:07 +0200 From: Stefan Reinauer MIME-Version: 1.0 Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0 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> <2a50f7880910031540p12bcacbajc53fe2831ec6f929@mail.gmail.com> In-Reply-To: <2a50f7880910031540p12bcacbajc53fe2831ec6f929@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: ron minnich , Anthony Liguori , Coreboot , Carl-Daniel Hailfinger , qemu-devel@nongnu.org Jordan Justen wrote: > 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. But, 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. (I'm not sure, but I think DUET may not >>> be able to boot UEFI OS's at this time.) However, 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? No. > DUET depends on a legacy BIOS. It did not for us, except for the loader which was replaced. We might have been lucky though... > My point is that a tianocore.org based coreboot payload ought be able to do away with > this legacy BIOS dependency. > Absolutely agreed. At some point it might make sense to have a coreboot specific target next to OVMF and DUET, some corebootPkg with specific adaptions and the loader integrated. The requirements for a coreboot target are very similar to those of OVMF and/or Duet, I guess. No hardware specific code is required, but in addition to what OVMF provides, we feature an in-flash filesystem and we export a coreboot table which contains memory information, cmos layout among other things... What are the chances to get something like this integrated upstream TianoCore.org? >> 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. It does expect a few tables, but does not seem to make any 16bit calls once loaded. > Once DUET is loaded, there is a (mostly) UEFI compatible > environment. > I'm curious on the "mostly" here... what's missing? We certainly want to make sure what we do is fully UEFI compatible. > Both DUET and OVMF have some slight issues with providing a fully > compatible UEFI variable interface. Is that about saving settings in an NVRAM/flash memory? Stefan