[Top][All Lists]

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

Re: [coreboot] [Qemu-devel] Release plan for 0.12.0

From: Stefan Reinauer
Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0
Date: Sun, 04 Oct 2009 01:03:07 +0200
User-agent: Thunderbird (Macintosh/20090812)

Jordan Justen wrote:
> On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer <address@hidden> wrote:
>> Jordan Justen wrote:
>>> On Sat, Oct 3, 2009 at 10:30, Peter Stuge <address@hidden> 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? 
>  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

>> 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?


reply via email to

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