UEFI Adoption

As a note to myself: There is a press release of the UEFI forum available which shows which vendors already have adopted UEFI or will in the near future.

Qemu, FreeBSD and coreboot

Since my attempts at getting Qemu running on Mac OS X were unsuccessfull, I've decided to go a different route. I'm now trying to build it on FreeBSD again.

Some time ago, I took some notes on how to get Qemu running on FreeBSD and added them to the coreboot wiki. Then some time later, I tried to build Qemu per those instructions, but had to discover that the port had been updated to a newer version of Qemu and no longer works.

So I've decided so maintain my own copy of the Qemu sources. The goal is to have a working version of Qemu which can be built on FreeBSD and can run coreboot. The repository is at svn+ssh://phs.subgra.de/usr/svnroot/qemu, a web frontend is available at https://phs.subgra.de/svnweb/index.cgi/qemu. Since the repository is not (yet?) public, here is a tar-ball of the latest version.

Building Qemu for FreeBSD from "my" sources is pretty straight forward. However, it's not as straight forward as building from Linux or from a FreeBSD port, so here are the full instructions ;-)

$ export BSD_MAKE=`which make`
$ ./configure (your options here)
$ gmake
$ gmake install

Have fun.

GCC 3.3 on Mac OS X

I just tried to build Qemu on an Intel Mac. Qemu needs GCC 3.x and won't compile with GCC 4.x. The configure script for Qemu automatically detects that the GCC 3.x is installed as /usr/bin/gcc-3.3 and tries to use that. The problem is that the compiler is actually a cross-compiler for PowerPC and that it cannot produce x86 binaries. Per this post I found out that using the -arch ppc flag allows the compiler to be used on an Intel machine. Obviously the resulting binary will be a PowerPC binary, but should run under Rosetta on an Intel machine.

Note that I still don't have a solution for building Qemu on Mac OS X. This post is just a note about one aspect of the whole problem.

Leaky Abstractions

Today I came across an interesting article that sums up why abstractions still require one to know the lower levels. In essence, the author claims that abstractions are good and help us build complex systems, but are a great burden if something fails in the lower levels. I couldn't agree more, especially when I think of the TianoCore code and the UEFI software model.

Profiling Tools for Mac OS X

I came accross this page today, where Amit Singh talks about some profiling tools for Mac OS X. Particularily interesting seem to be the Computer Hardware Understanding Development (CHUD) Tools. I haven't used them yet, but will check them out soon.