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