OpenBSD Journal

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

Contributed by deanna on from the happy-openbsd/mac dept.

This is my first developer blog, so for those who don't know me, my name is Gordon Willem Klok. I am relatively new to the OpenBSD project, getting my account on CVS early in April of this year. I have worked on a few things you might be familiar with: I ported support for AMD's frequency and voltage scaling technology (Powernow!) from FreeBSD and have worked quite a bit with other hw.setperf mechanisms. I also was responsible for the smbios vendor/product information reporting that you might have noticed with 4.0, for example:


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.

(Comments are closed)

  1. By Anonymous Coward ( on

    Seriously interesting. Good stuff, thanks for the blog.

    1. By Anonymous Coward ( on

      >Owner of 8100, happy to hear about OpenBSD development for powermac.
      Hack most interested in, is ability to use new HD storage, or flash memory.
      Have 1Gig drive SCSI, but saving it, drives then had low hours MTBF,
      was $1500 in 1995!
      Have other macs, but again, drives are small and old! If a drive hack, existed
      perhaps more mac users of OpenBSD?

      1. By Tyler ( on

        I'm afraid that your 8100 will likely not be supported; the architechture of the first (NuBus-based) PowerMacs is *very* different from the {7,8,9}500 and above machines. Even "the most portable OS in the world" NetBSD doesn't support the 8100.

        There is an experimental linux port (that's been around for 5+ years without getting rolled into mainline, if it tells you anything), but that's about it for *NIX on the 8100. The linux for 8100 is pretty good, if you have the patience to get it working. I ran a server on an 8100 with a G3 card for more than a year with no appreciable downtime.

        There's also MkLinux, but it was outdated back in 2000!

        As far as a hack to use modern drives in the 8100, there are a lot of options: a NuBus F/W SCSI card will let you use even the newest 68-pin SCSI drives, and an IDE-SCSI bridge board will let you use any PATA drive.

        Modern drives are even easier on the PCI machines this Dev Blog is talking about: Ultra160 SCSI interfaces are available (and likely supported by arch-agnostic drivers) as are IDE and SATA cards. Pick the card for the kind of drive you want and plug it in!

        1. By Anonymous Coward ( on

          8100 Hack enquirer; happy to keep macs going with HD info.
          Have MKlinux on 8100, would prefer OpenBSD. Old macs had some nice
          software, with file operations. Slow "nic" of 384k? really is lame though.
          There is an emulator for 8100 types, to run on i386 though, haven't used.
          Point is VM for old stuff, might really be the answer...
          But, the VM runs on windows....GRR...can't have everything, unless
          maybe bochs is hacked up. Anyway, all my time goes to i386/OpenBSD.
          Progress, simply put IS good. But I still look to my old mac for a target
          for easy interface and use.

  2. By Anonymous Coward ( on

    Enjoyable to read about your experiences, thanks for sharing.

  3. By Tyler ( on

    Wow! That's very exciting.

    I'd posted on the list a few months back offering use of my 7500/460 for anybody who had the interest to work on a port, but there were many more leechers than seeders, if I can borrow the metaphor.

    Thank you so much for taking on these machines! Now get SMP working so I can have a reason to buy a Genesis MP 800. :-)

  4. By Jason ( on

    Yay! My 8600 nfs server stuffed with cheap ata drives thanks you. I'll be among the first to test and play with new commits.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]