Retrocomputing: PowerPC Part 1

One of my hobbies is figuring out modern things to do with older computers, like web browsing and games. You may be surprised by the amount of activity in the PowerPC ecosystem in 2021, thanks to IBM, system builders like Raptor Computing Systems, and enthusiasts, including a group that’s pooling their money to build a new open source PowerPC-based notebook.

Back in Feb. 2012, I bought a used Power Mac G5 Quad from eBay, which had been built in 2006, at the very end of Apple’s PowerPC to Intel transition. I then upgraded it to 16GB ECC RAM (the memory controller supports, but doesn’t require ECC, but I always try to build systems with ECC when I can). Thankfully, Apple switched to SATA and PCIe interfaces so it was easy for me to further upgrade it with an SSD and a newer video card (which I can only use in Linux, since the card has a PC BIOS and not an Open Firmware ROM).

My original 2012 plan was to attempt to port Google Chrome to run on PowerPC, but that was hindered by two problems: the lack of a PowerPC backend for the V8 JavaScript engine, and also I needed it to run in big-endian mode. Big-endian vs. little-endian logic will be a recurring theme in this adventure. I spent some time trying to figure out if I could write a PowerPC backend for V8 but it was a task beyond my ability.

More recently, the pandemic left me with some free time to boot up the G5 Quad and see where I could get with Gentoo Linux, since that distro gives me the ability to tweak the C compiler flags and software versions, since I’ve had to do a lot of patching of code. It currently runs the Xfce desktop without trouble, but the GNOME and KDE desktops didn’t work as well for me, and take too long to compile new versions from source code.

Another development since 2012 is that IBM has since ported the V8 engine to PowerPC (big-endian and little-endian) so that Node.js now runs on AIX and Linux on POWER. Sadly, it was crashing for me, but after spending hours digging into the code generation, I found that the G5 is missing some floating-point rounding instructions that were added in a later POWER CPU model. I’ve created a patch with better CPU detection and a few other fixes, but I need to work on getting those fixes upstreamed.

My current work-in-progress is a big project: fixing Firefox to run properly in big-endian mode. There are some very irritating graphics display problems related to big-endian vs. little-endian ordering of color components within pixels. There are even two different “little-endian” modes to worry about, with much of the rendering pipeline being optimized for Android GPUs which use an “RGBA” format instead of the usual “BGRA” pixels (which look like “ARGB” on a little-endian CPU). The confusion is that on big-endian CPUs, the X11 graphics server and everything else in the pipeline really wants to see “ARGB” ordered pixels. When reading and writing 32 bits at a time, both big-endian and little-endian CPUs will see the same “ARGB” value, but when looking at the individual bytes, the order needs to be reversed.

The main challenge I’m facing is that Firefox, as well as Chrome, Dart/Flutter, Electron, Android, and many other projects all use the same Google-provided Skia 2D graphics engine for rendering. Unfortunately, the Skia engineers simply don’t care about supporting big-endian systems. At all. So I’m left trying to plumb through the pixels in the pixel byte order that things need to be in order for the final output to look correct on my big-endian Mac. I’m assuming that Chromium itself is also filled with little-endian assumptions.

You may have heard that PowerPC is bi-endian and can also run in little-endian mode. That’s mostly true, but with big limitations. You have to pick a big-endian or little-endian Linux kernel and then the whole system has to be compiled for the same byte order. AIX is only big-endian. Linux’s new “ppc64le” target requires a POWER8 or newer, but perhaps, with a lot of effort, could I fork Debian and compile the entire system for little-endian G5?

I’ve recently read that the G5 (and G4) CPUs are apparently missing little-endian support altogether. Since Apple’s firmware only supports big-endian, the only possible way to run a normal little-endian OS kernel would be by using QEMU and the KVM “problem state” hypervisor: the G5 doesn’t have a real hypervisor like later POWER CPUs, but Linux also has a “kvm_ps” module that can run user-mode code and emulate supervisor mode, like the way early VMware worked before Intel and AMD added proper hypervisors. I believe KVM-PS is 64-bit only (too bad for 32-bit PowerMac G4 and G3 users).

It’ll take a post longer than this to explain how I was eventually able to set up the hugetlbfs pages and discover the proper flags to run QEMU with KVM-PS (hint: “pseries-2.5” is the latest guest machine type that uses the old USB controller, and the XHCI controller in 2.6 and newer crashes in IBM’s Open Firmware if you use a G5 CPU), but I did successfully install and boot Debian 10 with it, so that’s good news for testing other Linux distros for PowerPC on the G5 without installing them.

I haven’t found a path to running any little-endian PowerPC OS but perhaps I’ll figure out a little-endian FreeBSD. I tried to install big-endian FreeBSD 13.0-RC5 on QEMU+KVM on the G5, but the FreeBSD kernel immediately panics with an unexpected interrupt type. Fortunately, it installs and runs fine (but slowly) in QEMU with an emulated CPU, so I’m setting up packages on a .qcow2 disk image from QEMU on my PC. Fortunately, the screen redirects over X11 to my Mac over SSH port forwarding without much trouble at all.

With QEMU+KVM on the G5, I’m seeing one annoying GUI refresh bug on the emulated VGA card that I need to fix, where the entire screen isn’t updated properly and I have to press Ctrl-Alt-2 to switch to the monitor and then Ctrl-Alt-1 to switch back, or similar hacks, which I’d like to fix so I can use the screen. Hopefully I’ll have some time to write another post once I’ve fixed some of these bugs, and perhaps even Firefox’s big-endian graphics bugs.

Doom 3 is another game I have source code for that has some big-endian bugs that prevent me from playing it (NPCs don’t move and text doesn’t render), but is tantalizingly close to working. The NVIDIA driver has more big-endian bugs than the AMD driver, which is why I swapped graphics cards on the G5. For video and games, there’s a lot of potential for further improvements by using AltiVec in place of SSE or NEON optimizations on x86 and ARM, respectively. I’m just happy that I have the skill to backport some of the recent work that has been done for POWER9/8/7 systems to run on the G5, but it isn’t always straightforward (like the Node.js bug I had to fix).

I have a few reasons for my interest in the old Apple PowerMacs: the hardware is very elegant, there are so many of them still working and being collected, and Apple tragically abandoned software support for them over a decade ago. You can pick up a G5 Quad for relatively little money and hopefully you won’t have trouble with the liquid cooling system or other parts. Mine occasionally doesn’t see all 16GB RAM after I’ve moved it. I have to reseat all the DIMMs carefully when that happens, and eventually it sees all the RAM. For Linux, Debian should be the easiest distro to install, and the only mainstream distro remaining that supports 32-bit and 64-bit Power Macs. There are a few others that I know of that use alternate C libraries or are otherwise a little esoteric. Or you can do like I did and install Gentoo and compile it all yourself.