Hi Jordan,
thanks for the detailed explanation. It certainly helped me understand some parts of the tianocore umbrealla better.
On 02.10.2009 07:37, Jordan Justen wrote:
I work for Intel on the edk2.tianocore.org project. (Compared to the original edk) edk2 may be of interest to those on this list since it supports building on several OS's with several different toolchains. In other words, it also supports building under Linux and OS X with the GNU compiler and binutils.
Neat. I remember the toolchain issues Linux-based developers had in the past, so I think this is a good thing.
Within our edk2 tree, we have two projects that relate to QEMU.
The DUET platform is a UEFI emulator that boots like a legacy OS on top of a legacy BIOS. It contains various hardware initialization drivers for several legacy hardware devices, but it also will call into the legacy BIOS and make use of certain items from the legacy BIOS. DUET can boot from the QEMU legacy BIOS, but it does require a disk to be setup to have the DUET image on it. I am not sure if all of DUET's code is currently safe for a UEFI OS to be able to access UEFI runtime services.
By the way, SeaBIOS can boot virtual floppy images stored in the ROM (at least when SeaBIOS runs as coreboot payload), so if you can fit DUET into a floppy image (or if Kevin adds support for virtual harddisk images), you can have a coreboot+SeaBIOS+DUET ROM right now.
The OVMF platform is a project to build a (mostly) UEFI compatible firmware for virtual machines. QEMU support is one of the main goals for OVMF. The OVMF rom image completely replaces QEMU's standard bios.bin, and therefore we must have hardware drivers for any hardware within the QEMU VM that we want to make use of. The project also has the goal to support UEFI OS's at runtime.
So OVMF is not just hardware init, but a complete package of hardware init and UEFI interface?
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger