Hi, > gets. It sounds like there will soon be need for a more generic PCI > resource allocator, which is another thing that coreboot already has.
--verbose please. >>> 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems >>> wildly schizophrenic without bringing any significant benefits, >>> compared to factoring all of that out into a codebase which *already >>> does many of the needed things*. >> >> It's a tradeoff. On one hand letting coreboot handle hardware >> initialialization would reduce the amout of code in seabios we have to >> maintain. On the other hand adding coreboot as middle man between qemu >> and seabios would add some complexity to the whole mix. > > What complexities have you run into? You have three pieces of software now which must correctly work hand in hand instead of just two. > coreboot can of course be improved further, but as you may know > SeaBIOS gets built by default by the coreboot build process already, > so using coreboot wouldn't even add extra steps for a manual build. I'm more concerned about development and debugging than about the build process. The build process isn't that great IMHO (although that is probably fixable without too much effort). coreboot fetching seabios as git submodule might be convenient for developers. For package building it sucks big time, you certainly don't want your package builder clone seabios.git each time coreboot is built. And if you flip CONFIG_SEABIOS to "no" to fix that (then add prebuilt seabios.elf via cbfstool once the build is finished) suddenly a bunch of config options get different default values ... >> I'm not convinced using coreboot is a clear win, especially with EFI >> coming. Can coreboot run tianocore as payload? > > Work is ongoing to make edk2 a good coreboot payload. It already > works for some values of works, but more work is needed. Progress > has been fast the last month or so, thanks to efforts by David and > Patrick Georgi. I'll have a look. payloads/tianocoreboot/README hints that this works for Ia32 only atm. Is that true or just an incomplete README? Can tianocore grab acpi tables from coreboot? >> ACPI not working at all in linux guests when using coreboot with >> seabios payload doesn't exactly encourage exploring that option btw. > > Then the way the QEMU mainboard does ACPI in coreboot needs fixing, > which is quite possible because I don't know if someone has actually > implemented ACPI at all for QEMU, and if so it is not likely using > the more modern facilities but likely to have static ASL. The point > is not what is already there, the point is that adding this stuff > into SeaBIOS or QEMU for that matter would mean re-inventing > *yet another* wheel which is *already* finished in coreboot. Yes, the infrastructure is there. Which helps of course. But qemu support certainly isn't finished. It is broken. >>> but I'm afraid I will not stop >>> complaining as long as SeaBIOS grows with more and more stuff that >>> has nothing to do with a BIOS environment but has to do with lower >>> level platform init. >> >> Well, *this* discussion is about moving stuff *out* of seabios. > > Good point, but it seems to be about moving stuff into each > respective hypervisor, when in fact much of that code could > probably be common in coreboot without significant effort. When moving into qemu it will be shared too as both opensource hypervisors (xen+kvm) use qemu, so there isn't duplication. Generating the tables in qemu will kill the pain point of having to pass the relevant configuration information from qemu to seabios/tianocore/coreboot/whatever. It will also make sure the acpi tables are in sync with qemu's virtual hardware. cheers, Gerd _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
