[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. 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 ported/modified existing code, I'd be interested in the original codebase to learn from it (especially what you had to change).
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