Hi Jordan,
I have to admit that I'm not the expert for coreboot+EFI solutions. I know they exist and work, but I'll defer to other developers on the coreboot list to give you detailed answers. Please see below for what I think I know (but I'll gladly accept any corrections).
On 02.10.2009 22:57, Jordan Justen wrote:
Carl-Daniel,
Interesting. So, where can I download a QEMU bios rom to boot a UEFI OS with this solution?
Can you explain what coreboot+tianocore means? Which parts of tianocore do you use in this situation?
This mail is CC: to the coreboot list and I'm sure someone who knows more than I can respond.
The documentation about Tianocore/UEFI/EFI is not entirely clear about the names of each part of the stack, but if I understand correctly, there is a hardware init part (OVMF for Qemu) and parts which boot EFI enabled operating systems, provide EFI services to the operating system, or give users a shell to work from.
coreboot is pure hardware init (CPU, RAM, chipset, PCI), it has no drivers whatsoever. It does provide ACPI tables for the hardware and a memory map. Once coreboot finishes hardware initialization, it passes control to a payload (which has drivers, boots the OS, provides services). That payload is hardware-independent unless it explicitly wants to contain non-generic drivers. It is possible to use the exact same SeaBIOS binary as coreboot payload on Qemu, Pentium III systems with i440BX chipset, AMD Phenom systems with 690G chipset, Via Nano systems with VX800 chipset, and Intel Core 2 Duo systems with i945 chipset. Unless I'm mistaken, OVMF and coreboot have pretty much the same purpose.
If your solution can accomplish all of what you say, I'm not sure how OVMF would be able to compete against in terms of being included with QEMU. Part of the reason for starting OVMF was to help enable UEFI support within VM's such as QEMU. If OVMF was utilized by QEMU it definitely would have been a bit of a boost for our efforts, but if QEMU accomplishes UEFI support via another path, then overall we will still be happy.
Please don't get me wrong. The number of developers in the open source firmware space is small and I'm happy that you're such a developer. My main worry is splitting one task among too many projects, with the danger of frustation if only one project is accepted into Qemu. I don't have an axe to grind against EFI (which is desired by many people) or OVMF (which is purpose-built for UEFI in Qemu). That's why I want to understand your goals and hope to find a way to accomplish your goals, coreboot goals and at the same time have Qemu get the best firmware possible.
Thanks,
-Jordan
Regards, Carl-Daniel
On Fri, Oct 2, 2009 at 11:45, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 02.10.2009 18:58, Jordan Justen wrote:
On Fri, Oct 2, 2009 at 06:29, Anthony Liguori anthony@codemonkey.ws wrote:
So I think the best way forward is to hold off on UEFI in mainline until we can provide a single unified stack.
While it is true that a separate machine type could potentially be viewed as increasing the testing requirements, I am not so sure. If QEMU has a UEFI+CSM solution, wouldn't we still have to test both UEFI based OS boot and the CSM based legacy OS boot?
Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI interface), wouldn't that solve all problems in one go? You get an
-
Carl-Daniel Hailfinger