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
