On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
[Adding the coreboot list to CC. Please ignore the moderation messages, your addresses will be whitelisted ASAP.]
On 02.10.2009 20:53, Anthony Liguori wrote:
Carl-Daniel Hailfinger wrote:
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 unified stack and don't have to mess around with different firmware files because coreboot can read in a Qemu machine config option (or NVRAM/CMOS) and select the interface based on that.
If you want to to work seamlessly, you need to check for the EFI system partition to see whether it's an EFI capable OS and then fallback gracefully to SeaBIOS boot.
Hm. Wouldn't that be a layering violation (hw init != reading the disk) and also cause problems if you want to boot an EFI capable OS from SeaBIOS? I can think of someone having an EFI bootable disk image who wants to boot that disk image with EFI and BIOS without having to repartition.
The hardware init part would be identical for all variants, only the interface would differ. coreboot works now and has the benefit of supporting real hardware as well, so the difference between a setup inside Qemu and a setup on real hardware is minimal.
Tianocore's OVMF project should provide all the required initialization for EFI on QEMU.
Yes, but then we'd have two sets of hardware init: OVMF for EFI, SeaBIOS for SeaBIOS. That also means each hw init codebase has to support the new Q35 chipset proposed for Qemu.
It's not any better if SeaBIOS gets changed into a CSM for EFI. Then you have SeaBIOS on top of EFI on top of OVMF. As I understand it, OVMF had less testing than the Bochs BIOS or SeaBIOS on Qemu.
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.
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.
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'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.
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. Edk2 is BSD licensed, and therefore from a licensing perspective should be easy for your project to utilize.
The coreboot solution would also avoid converting SeaBIOS because SeaBIOS already works as coreboot payload (that's how coreboot developers call the CSM).
I'll bite, what's the advantage of doing coreboot + SeaBIOS vs. SeaBIOS alone? Forget about EFI for the moment, should be considering switching to coreboot + SeaBIOS for 0.12?
Advantages:
- Code coverage increase: SeaBIOS is used with coreboot on real
hardware, so the BIOS interface part of SeaBIOS gets a lot more testing than the Qemu hardware init part of SeaBIOS.
- coreboot supports real 440BX hardware besides Qemu, so the coreboot
init code is exercised more (and there is still a sizable number of such machines around (clusters), many of them running coreboot).
- Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into
the ROM image and SeaBIOS will automatically load it from there. Same for network card ROMs (with gPXE etc.).
- coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS)
are archives and can be listed/edited with cbfstool if you want to know what's in there.
- coreboot ROMs use compression, so you can stuff more code (and PCI
option ROMs) into smaller ROMs.
- coreboot has pretty verbose hardware init messages (if you want that)
and can be totally silent as well. The messages end up in a log buffer which can be read by the OS (experimental feature, not available by default).
There are a lot more advantages, but I want to give other coreboot developers a chance to chime in. If you add EFI to the mix, the synergies increase.
Regards, Carl-Daniel