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

[Jordan Justen]

On Sat, Oct 3, 2009 at 16:03, Stefan Reinauer <stepan at coresystems.de> wrote:
> Jordan Justen wrote:
>> On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer <stepan at coresystems.de> wrote:
>>
>>> Jordan Justen wrote:
>>>
>>>> On Sat, Oct 3, 2009 at 10:30, Peter Stuge <peter at stuge.se> 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.
>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 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.

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