Jason Wright and Mark Kettenis have spent much of their time at the c2k6 hackathon finishing up support for UltraSparc III processors on the OpenBSD/sparc64 architecture. A number of months ago Henric Jungheim put in several weeks of effort reverse engineering support for the UltraSparc III, then OpenBSD creator Theo de Raadt [interview] put more time into cleaning up the diff and comitting much of it to the source tree. Halfway through the hackathon, Jason and Mark have taken what was not-quite functional code and have it successfully booting into multi-user mode. A couple of years ago there was an unsuccessful attempt to obtain documentation for this processor from Sun [story], so this current effort has had to use the FreeBSD and Linux UltraSparc III implementations as references. Theo explained, "Sun released CPU docs, but that's useless. It is kind of like trying to fix a car engine with the owner's manual. The rest of the hardware is not documented."

Jason points out that not only does OpenBSD run on the UltraSparc III processor, but it is also "self hosting". In other words, it is possible to build an UltraSparc III kernel on an UltraSparc III, and then reboot to that new kernel. This is important, Jason explains, because GCC is very memory and CPU intensive, "it really hits a server hard". He goes on to add that for this reason all the different OpenBSD architectures are built on their own architecture, and that this policy often catches bugs that could otherwise be missed.

UltraSparc III Cache
Jason and Mark note that while the UltraSparc III is booting and working, it's running without its data cache. "It has all the performance of an original 140 MHz Ultra 1," Jason says, "and these are 900 MHz machines." When asked why the data cache isn't being used, Mark replied, "Sun screwed up in the design of the cache." The instruction cache is physically indexed, and thus works fine.

Dale Rahn helped explain the problems inherent in cache aliasing. In a virtually indexed cache, the number of bits used to locate a given cache line is larger than the page size, with one or more bits being aliased depending on the architecture. In the UltraSparc III one bit is aliased, meaning that the same physical page can be referenced in two different locations in the cache, depending on if the aliased bit is a 0 or a 1. Thus, it is possible for the two different cache lines to contain different versions of the same physical memory. This problem surfaces when two different process share the same physical page, such as when they map the same file, and can result in one process accidentally accessing a stale cache entry.

There's no efficient solution to this problem, however Dale explains that what you can do is be careful when mapping the same physical memory to make sure that all processes end up with the same aliased bit so they always access the same cache line.

Current Status
Most of the main devices are working, such as the internal disk drive, networking, audio, and the real time clock. There's no floppy support, but this is true for the entire sparc64 architecture. "It's going to stay that way as far as I'm concerned," Jason says, "I don't need it." The UltraSparc III also has an I2C Inter-Integrated Circuit serial bus providing access to temperature and fan sensors. At this time it's unused, but Mark is looking into accessing and utilizing the information from these sensors.

As a test, Jason connected a Serial Attached SCSI card to his UltraSparc III and used David Gwynne's new mpi driver [story] - also written at this hackathon - to boot the device. Jason noted that it took just one small patch, then "it just worked."

Jason is now working on cleaning up the device attachment logic. At start up the system provides a boot string that looks something like /pci@8.600000/LSILogic.sas@1.0/disk@9.0. He's cleaning up the logic that converts this string into something meaningful to OpenBSD so that it can figure out which device is the root device. He notes that this effort is further complicated by the fact that Sun likes to change the string with each firmware revision.

Mark is focused on cleaning up the diff so that it can be committed. Before the 2006 hackathon ends this year, it is likely that the -current branch of the OpenBSD/sparc64 architecture will finally support the UltraSparc III.