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@xxxxxxxxxxxxx> wrote: > > On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: > >> Where is CorebootPkg available from? > > > > https://github.com/pgeorgi/edk2/tree/coreboot-pkg > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
