On Thu, May 30, 2013 at 09:20:42AM -0700, Jordan Justen wrote:
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dwmw2@infradead.org wrote:
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
Where is CorebootPkg available from?
Is the license on this actually BSD as the License.txt indicates?
Is this planned to be upstreamed?
Does this support UEFI variables?
Does this support UEFI IA32 / X64?
And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because helping something that competes with UEFI would be bad.
Coreboot and EDK II both provide a good infrastructure for initializing hardware. So, they compete on that point.
Coreboot then focuses on booting coreboot payloads, while EDK II focuses on UEFI support. On that point they don't compete, but the focus is different.
Of course, you can build a layer of EDK II => Coreboot payload support, or Coreboot => EDK II (CorebootPkg, I guess?), but the match will not be perfect. (That is not to say it can't work.)
I'm not sure who do you mean by "some quarters", but for some distributions Coreboot would be yet another component (package) to support, for no obvious benefit.
(Gerd said it better than I possibly could: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705.)
Yeah, but if we're shoving a lot of hardware-specific ACPI table generation into the guest's firmware, instead of just doing it on the qemu side where a number of us seem to think it belongs, then there *is* a benefit to using Coreboot. When stuff changes on the qemu side and we have to update the table generation to match, you end up having to update just the Coreboot package, and *not* having to patch both SeaBIOS and OVMF.
I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu.
Of course ACPI tables are firmware. Please note that what my patches do is simply supply templates for ACPI tables on a ROM device separate from where bios code resides. bios still tweaks them in minor ways. I am guessing this is what happens on real hardware too: most tables pre-generated in ROM, firmware shadows them and tweaks them in minor ways.
I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement.
Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu?
-Jordan
-
Michael S. Tsirkin