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

[Stefan Reinauer]

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