From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MuEOg-0001ye-OP for qemu-devel@nongnu.org; Sat, 03 Oct 2009 19:52:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MuEOa-0001yS-TX for qemu-devel@nongnu.org; Sat, 03 Oct 2009 19:52:17 -0400 Received: from [199.232.76.173] (port=48739 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MuEOa-0001yM-Ln for qemu-devel@nongnu.org; Sat, 03 Oct 2009 19:52:12 -0400 Received: from mail-yx0-f173.google.com ([209.85.210.173]:58510) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MuEOa-0005RY-6R for qemu-devel@nongnu.org; Sat, 03 Oct 2009 19:52:12 -0400 Received: by yxe3 with SMTP id 3so2021504yxe.4 for ; Sat, 03 Oct 2009 16:52:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4AC7D82B.9030405@coresystems.de> References: <4AC51DBA.7020609@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> <4AC7D82B.9030405@coresystems.de> Date: Sat, 3 Oct 2009 16:52:11 -0700 Message-ID: <2a50f7880910031652u5837f7cdx85686eddd2050f8@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 16:03, Stefan Reinauer wrote= : > Jordan Justen wrote: >> On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer wr= ote: >> >>> 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 jus= t >>>> 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 no= t >>>> 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? > No. >> =A0DUET 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. >LegacyBiosInt86 > 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? I'll refrain from making a prediction on this. But, by my view, tianocore.org is supposed to be an open source community that encourages UEFI related contributions. However, (at this time) it is going to tougher to get it included at tianocore.org if it is not BSD licensed. I would also suggest discussing the situation on the tianocore.org email lists beforehand to get somewhat of a confirmation before investing a lot into it. >>> 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 bu= t >>> 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. >> =A0Once 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. I think tianocore.org will not call these fully UEFI compatible projects, since that implies a lot. Normally these platforms are not run through the UEFI Self-Certification Tests, for example. (Although, this is something I plan to try on OVMF at some point.) Also, there is the variable situation. (see below) >> 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? Yes. Neither platform provides proper UEFI NV variables support. The NV variables can be lost depending on when the platform is shut off, and when the variable has been written to. But in addition, for DUET, I thought that accessing the NV variable services at OS runtime might not work correctly. (Perhaps cause an exception. Perhaps just always return an error.) -Jordan