Developer Blog - gwk@: OpenBSD on old-world Macs

bios0: MICRO-STAR INTERNATIONAL CO., LTD MS-6501

Which makes working with dmesgs from users much easier. However, the subject of this blog is my unhealthy obsession with old-world macs.

My obsession with the old world macs began last November when, as a birthday present, I received a Power Macintosh 9500MP and a 9600MP purchased from ebay for $150 USD. What a score! My first exposure to computers was the old world Macintosh computers in my elementary school computer lab. Spending as much time as possible there using them, at the time I dreamed of having my very own at home to use, but a regular macintosh was quite beyond my family's means, never mind something as fantastically expensive as a 9500MP. So I was stoked to receive these machines for a tiny fraction of their original price, even eleven years later and after United Parcel Smashers kicked two holes in the box and somehow managed to make it round, all while trying to claim 50% of the cost of the machines and shipping ($120!!!) on "brokerage fees".

While attending the hackathon in Calgary earlier this year, in between hunting bugs in the since-replaced AML parser with canacar@, and porting kernel mode virtual 8086 mode for the eventual vesabios that will alow aperature-less X usage, I peppered people with questions about supporting the old world macs. The responses were less than enthusiastic: while more than a few people confessed that such support would be a nice thing to have, they pointed out that these machines have buggy firmware, and that while we had some drivers in the tree for hardware such as the SCSI controllers, they were in an atrocious state of bit rot. All in all, "it's probably a waste of time" seemed to be the consensus, but it didn't deter me that much.

First I should thank Mark Kettenis and Dale Rahn for putting up with my constant barrage of questions about low level things; I can be quite a pain sometimes.

I began in earnest by looking at NetBSD. The lineage of their macppc port was not too distinct from our own. The first thing I attempted was to get a working boot loader. These old world machines load an XCOFF formatted boot loader, versus new-world machines' ELF. This took about two months or so, working on it a few hours a week, finally resulting in an enormous 6 line change to the bootloader to create a new stack, as the one setup by OFW 1.0.5 was brain dead. It was a huge high to see the loader finally loading a kernel over the network, however it panic-ed very early during boot when probing the PCI busses.

There were two problems: it turns out that while a configuration mechanism was defined for the bandit chip, it was the wrong one, resulting in the PCI code looking at the wrong registers. The second problem was more annoying: unlike the new world macs, bandit would define two non-contiguous regions of memory from which to access PCI I/O memory. For the new world machines, the last address in the address cell property of the open firmware node wins, or if there are two and they are contiguous the PCI I/O memory extent would be created to encompass both.

So, when the PCI code attempted to fix any screwups made by the firmware in programming the PCI registers, it would get addresses that were outside the range of the extent, causing a panic. An early hack I came up with was to force the extent to encompass as much of the space as the address cell defined; unfortunately this broke some new world machines and had to be backed out. An alternative workaround for the time being was simply to skip the pci_addr_fixup step in mpcpcibus.c. Now, after these changes, the machine was probing the PCI bus correctly and even booting a ramdisk image!

The next big hurdle was device drivers. The tsunami architecture, on which both the 9500 and 9600 are based, used the mesh device for on-board SCSI, and mc or mace for the on-board Ethernet, neither of which had functioning macppc drivers. There was a driver for mace in OpenBSD/mac68k but DMA on the two architectures is very different. So I began to port these two drivers from NetBSD, in the process learning a bit about macppc's descriptor-based DMA and the SCSI and Ethernet device frameworks. It has been a very good learning experience. Finally, after lots of assistance from brad@ and dlg@ with the ethernet and SCSI drivers respectively, I had the two drivers working and was able to install OpenBSD to the local disk and boot multiuser.

I began to put various pieces in the tree about a month and half ago. During OpenCon, a menacing Austrian fellow, martin@, kept twisting my arm about putting the final bits in: the boot loader and enabling the new device drivers in GENERIC. After this, much remains to be done. There is a driver for the NCR 53c90 external SCSI controller to be ported (the esp device on OpenBSD/sparc and mac68k), the kernel handling of boot paths supplied by open firmware must be tweaked to handle the subtle differences between OFW 1.0.5 and latter versions, for old-world machines with IDE controllers some tweaks are no doubt necessary to wdc obio as well. Also, as both of my machines are SMP beasts I would love to get SMP working on OpenBSD/macppc, but this is another big undertaking and, as you can see, there is still much to be done (I also would need a faster new-world macppc machine with dual processors, as SMP support is limited to the few people with functioning old-world MP machines, and those with an interest in running OpenBSD on them is probably a small group :)

Finally, there is also a nasty UVM bug still remaining which alas prevents these machines from even building a kernel -- in fact, checking out a source tree can take multiple tries, with CVS aborting sporadically. In part 2, I will provide some brief instructions on how to play with the effort so far, and maybe answer some questions about what exactly an old-world mac is.