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