Carl-Daniel,
It sounds like there is a whole lot of overlap in what coreboot and tianocore are trying to enable.
The key difference is that tianocore is focused on enabling the UEFI interfaces within platforms.
OS loaders in UEFI are UEFI applications, and therefore just like in the case of the UEFI shell (which is a UEFI application), they could be embedded in the ROM. So, this is similar to the coreboot payloads concept. But, it is not quite as central of a design goal for UEFI systems as it appears to be within coreboot.
UEFI does provide runtime services that an OS can make use of, so that sounds a bit different that coreboot. (Linux does have support for these interfaces.) Essentially you can think of UEFI as a better spec'd version of what the legacy BIOS was, but with more extensibility designed into the interfaces.
Anyway, it sounds like a useful project might be to develop a UEFI coreboot payload based on the tianocore.org code. Our DUET platform would only work on top of seabios, and OVMF has some overlap in hardware initialization along with being a VM/QEMU specific solution. Of course, we are always glad to hear if people are able to make use of our code, and we like to encourage any UEFI or tianocore related contributions to tianocore.org.
Thanks,
-Jordan
On Fri, Oct 2, 2009 at 16:05, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 03.10.2009 00:28, Jordan Justen wrote:
On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Jordan, I have to admit that I'm surprised OVMF was apparently created from scratch although quite a few (established) hardware init solutions already exist for Qemu: SeaBIOS, Bochs BIOS, coreboot, and some old hobbyist projects.
The edk2 project provides an infrastructure for building complete UEFI firmware solutions. OVMF is a sample platform which demonstrates how edk2 can be used to build firmware to boot a UEFI platform.
I wish to apologize for the misunderstanding. I thought OVMF was only hardware init. Thanks for correcting me.
Aside from just this, OVMF is an effort to support VMs on edk2. (Ie, more than just QEMU.) Ideally the project, and code of OVMF could be used by any VM vendor as a sample for building UEFI compatible firmware.
How does it relate to real hardware? You mention OVMF as an effort to support VMs on edk2. Does this mean that VMs need special support or that real hardware has different needs?
Most of the code required to support QEMU was already open sourced on edk2 before OVMF was launched. At the time that we started OVMF, it did not seem like any project was targeting UEFI support on QEMU. Tristan Gingold had done a port for UEFI QEMU support, but at that time it did not seem to be functional with the current QEMU, nor actively developed.
I see.
I'd like to understand the reasons for that and fix them in coreboot (Kevin O'Connor will probably fix them in SeaBIOS).
If you want to remove any need for OVMF on QEMU, then I think all that is needed is to support booting UEFI OS's for both i386 and x86-64. Of course, we may still have some use for the OVMF project on edk2 as a sample platform.
Given that my original statement incorrectly assumed OVMF was only about hardware init, please let me try to express what I originally meant (and which came across with unintended meaning). I hope to use all EFI support code from OVMF, keep SeaBIOS, and have coreboot as common hardware init base.
If you ported/modified existing code, I'd be interested in the original codebase to learn from it (especially what you had to change).
As I mentioned above, a good portion of the code was already available in edk2.tianocore.org.
Thanks for the pointer.
Edk2 is BSD licensed, and therefore from a licensing perspective should be easy for your project to utilize.
(Speaking with my coreboot hat on.) The goal of coreboot is not to assimilate and change other projects, but to provide hardware init for any code which needs it.
After hardware init, it passes control to a payload (SeaBIOS, UEFI, GRUB2, FILO, Linux, Plan9...). There are no callbacks to coreboot, each payload is expected to talk to the hardware on its own. Except for ACPI tables (and a memory map), nothing of coreboot stays in memory after passing control to that payload. If you want some basic hardware drivers for your favourite payload, you can use the BSD-licensed libpayload library in your code, but most payloads (SeaBIOS, GRUB2, ...) have their own drivers anyway. Operating systems like Linux and Plan9 which do not need any BIOS/EFI interface can be stored in the ROM and will be booted directly by coreboot (if in ROM). Boot loaders like GRUB2 or FILO don't need BIOS/EFI either, can be stored in ROM and will then be booted directly. BIOS and EFI code can be used as a coreboot payload in ROM as well. Some people are even working on making U-Boot available as coreboot payload.
The idea is to have coreboot handle all the hardware-specific initialization and allow all other code to be mostly hardware-agnostic (unless said code wants to implement drivers). The clean interface (well, no interface, coreboot just passes control to the payload) allows payloads to do whatever they want as long as they provide a single 32-bit entry point coreboot can jump to.
Regards, Carl-Daniel