On Thu, Apr 03, 2014 at 11:42:31AM +0200, Laszlo Ersek wrote: > Unless you want to do OVMF development yourself (ie. as long as you'd > like to test only), you're best off with > > (a) Gerd's packages: > > http://www.kraxel.org/repos/ > > (b) If you use a Fedora host, you can also try a (recently refreshed) > Copr build, thanks to Paolo: > > http://copr-be.cloud.fedoraproject.org/results/bonzini/ovmf/ > > Under (a) you find some short instructions, and a set of RPMs that is > automatically rebuilt twice a day (IIRC). > > Both (a) and (b) include the downstream-only SMBIOS patches. > > [...] > > You don't see SMBIOS tables in the guest because you've built upstream > OVMF. As I said before, upstream OvmfPkg doesn't include my SMBIOS > patches. Both (a) and (b) do however.
Oh, OK. Basically, I'm interested in looking at the sources (specifically, the SMBIOS code :) ) to try and develop my own sense of what might be the most agreeable way forward for my QEMU smbios patches... That way, I'd actually have a (hopefully somewhat intelligent) position of my own to support :) :) For that, ideally, I'd like to clone a git repo (and pull once every few days to stay on top of things). Looks like the top-level upstream one doesn't have your smbios code, so would there be a "mid-stream" (for the lack of a better term) git repo you have that I can clone and hack against for the smbios stuff ? I ask because yesterday was the first time I started really paying attention to edk2 and ovmf, and I don't yet have a sense of how fast the "state of the universe" would run away from me while my back is turned, i.e. how fast a point-in-time snapshot of e.g. Gerd or Paolo's RPMs would become stale... Extracting and patching source code from RPMs is OK once or twice, but I imagine will be much less fun than "git pull" once it gets repetitive :D > One further note (also mentioned in OvmfPkg/README): don't use OVMF.fd > with -bios; use it with -pflash (you need a Linux 3.7+ host for this). > This will give your guest real runtime variable services -- non-volatile > variable data will be written back to the OVMF.fd file. Good to know (-bios == read-only, -pflash == writable) :) I'm really only in it for testing smbios interactions with qemu though, at least at this stage... :) Thanks a ton, --Gabriel