On Thu, 2013-02-14 at 14:08 +0000, Ian Campbell wrote:
The chap who did our OVMF stuff has moved on to pastures new but ISTR him saying something about a build bug with GCC!=44, which had been fixed in upstream OVMF but not yet sync'd into the Xen tree.
Yes, OVMF's toolchain handling is somewhat broken. I *do* have it building with GCC 4.6 and 4.7. There's a patch in my tree at git:// and http://git.infradead.org/users/dwmw2/edk2.git which fixes that... although I suspect it might be incomplete and I'm about to blow away my local build tree and configure from scratch to retest.
But your tools/ovmf-makefile could also do with s/GCC44/GCC4?/ in the line which does cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
Awesome! (I've CCd xen-devel just for their info, it's moderated for non-subscribers but valid posters get whitelisted)
In that case I think the only context I need to add, for those who want to play along at home, is the location of my trees for OVMF and SeaBIOS. The OVMF one is above, and the SeaBIOS one is next to it: git:// or http://git.infradead.org/users/dwmw2/seabios.git
There's a README.CSM file in the SeaBIOS tree which describes how to build OVMF with CSM support. The main reason I'm pointing you at my trees rather than upstream is the patch within each one that adds the UmbStart,UmbEnd fields for negotiating between UEFI and SeaBIOS which parts of the UMB memory region should be made read-only. For Qemu with KVM that's a moot point because it doesn't get made read-only anyway, so you could just use upstream now. If you don't implement the PAM protection of those regions, I suspect the same might be true for you. Suck it and see, perhaps.
I did need to fix the VGA ROM you're shipping for Cirrus, which has the PCIR structure unaligned. That was it.
... did you mean the VGA ROM we ship in the qemu-xen branch that we include? (rather than tools/firmware/vgabios/)
Yes, the one in /usr/share/qemu-xen. You want the patch from http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html