DIET-PC PowerPC Port

By Paul A. Whittaker

Last Update: 6 January 2008

Why?

Mostly an intellectual exercise - a challenge, a learning experience, and a test of DIET-PC's flexibility. Interest in the PowerPC architecture took a nosedive when Apple abandoned it in favour of x86, and it remains to be seen whether it can regain popularity in the embedded marketplace.

Nevertheless, some sites - educational institutions in particular - may have old iMacs lying around that are too slow to run Mac OS X with acceptable performance, and may wish to recycle them as thin clients.

A few embedded appliances also use PowerPC chipsets, and while this port is aimed at Apple hardware in particular (with regard to keyboard, bootloader and filesystem support), the actual binaries should run on any PowerPC-based platform that you can build a Linux kernel for. I now own an Efika Open Client, and can therefore provide some degree of support for these units also. See the Efika page for more information about DIET-PC PPC on Efika.

Limitations

At this stage, this port of DIET-PC is really only intended for PowerPC- based Apple computers with "New World" ROMs. In layman's terms, that means G3/G4 PowerMacs, iMacs, iBooks, PowerBooks and Mac Minis. It might be possible to get DIET-PC PPC to work on Old World PPC Macs (such as the original PowerMacs) using BootX, but my build automation only knows about yaboot. The original Macintoshes with Motorola 680xx series CPUs are a completely different archiecture that I have no intention of ever supporting.

With respect to any interoperation with Mac OS (such as sharing a disk with Mac OS), DIET-PC PPC tools and documentation assume Mac OS X. Mac OS 9 and earlier are much fussier with respect to disk partitioning, and if you follow DIET-PC recipes for co-existence, Mac OS will probably be unable to boot.

The only PowerPC devices that I can guarantee that DIET-PC PPC will definitely run on (to some degree, at least) are those that I own: a G4 "Aluminium" PowerBook, and an Efika (MPC5200B) Open Client. I've made every effort to ensure that it will work on other PowerPC Macs, but can make no promises.

Downloads

A bootable ISO image for PPC Macs is available from the PowerPC download area. It includes the following packages: generic_kernel_macppc 2.6.23.12, shell 2.7, sshserver 2.5, remotefs 2.8, smbserver 2.1, storageserver 2.3, persistfs 2.3, assembler_installer 2.2, xcore 2.2, xserver_xorg 2.3, xserver_xorg_radeon 2.3, xserver_xorg_vnc 2.3, rdp 2.5, rfb 2.2, wireless 2.0pre, mmedia_xine 2.5, qvwm 2.0pre. It boots to runlevel 1 (shell only) by default, but you can use the menu to enter server details and change to runlevel 2 (X11-XDMCP), 3 (RDP), 5 (VNC), 8 (Xine) or 9 (QVWM). As always, the root password is "foobar". I encourage anyone who owns a Mac to boot this and let me know what happens. To boot a from CD, insert the CD and then hold down the c key after powering on. The bootable image will not harm your disk contents in any way.

Snapshots of my PowerPC diet-pc tree are available from the PowerPC section of the downloads area. You ought to be able to extract the tarball onto any NFS server (eg. such as your x86 Linux dev box), and then boot a Mac using the ISO mentioned above and use its assembler_installer capability to NFS-mount the diet-pc directory and construct new boot images.

Status

DIET-PC PackageEquivalent x86 VersionStatus
assembler_installer2.1Working equivalent with additional HFS/HFS+ support and support tools needed by skeleton (mac-fdisk, ofpath, nvsetenv). Incomplete documentation.
generic_kernel_586+2.6.23.12Working equivalent named generic_kernel_macppc; no splash support (requires VESA). No documentation. There is also a 2.6.23.9 kernel_efika package specifically for the EFIKA (MPC5200B).
ica-Not possible due to lack of Linux PPC ICA Client. Use of Java or MacOS X clients is theoretically possible, but impractical due to the huge runtime overheads of JRE and MOL.
mmedia_xine2.5Mostly working. ALSA's OSS emulation doesn't work on my PowerBook, so aumix and xineplug_ao_out_oss.so are useless. I have included alsamixer and xineplug_ao_out_esd.so to work around this. You may find that ALSA mixer devices default to zero volume at boot, so you have to use alsamixer to raise them, or Xine will be totally mute. Win32 codec support is obviously useless on this platform, as are RealPlayer library hooks. Other than that everything seems to work, despite the hazard of linking against a mix of static and shared libraries on this architecture (this can result in out-of-range symbol relocations).
persistfs2.3Fully ported (with additional HFS and HFS+ integrity checkers), documentation needs minor update.
qvwm2.0preFully ported.
rdp2.5Fully ported.
remotefs2.8Fully ported.
rfb2.2Fully ported.
rfbserver2.1Fully ported.
sensors2.5Fully ported.
shell2.7Fully ported, minor documentation updates needed.
skeleton2.3Working equivalent using the yaboot boot loader for network, CD and disk booting (Macintosh only, in all cases; EFIKA is not supported by Makefile targets). Network booting has special DHCP server requirements, and disk booting is limited to HFS partitons only. Needs a substantial documentation update.
smbserver2.1Fully ported.
ssh2.3Fully ported.
sshserver2.5Fully ported.
storageserver2.3Fully ported.
wireless2.0preFully ported.
xcore2.2Fully ported, minor documentation updates needed.
xserver_tinyx2.3Working equivalent (Xfbdev instead of Xvesa), no documentation.
xserver_xf32.1preWorking but somewhat buggy equivalent (XF86_FBDev instead of XF86_SVGA), no documentation. Not recommended.
xserver_xorg2.3Working equivalent (fbdev instead of vesa), incomplete documentation.
xserver_xorg_radeon2.3Fully ported. Won't work on virtual terminals pwned by the radeon framebuffer driver, due to resource conflicts (see below). Hence it is not possible to automatically fall back to fbdev if the accelerated driver does not work.
xserver_xorg_vnc2.3Fully ported.
xserver_xorg_xgi2.3prePartly working (unstable, XVideo overlay does not work). Coexists peacefully with SiS framebuffer, but as with xserver_xorg_radeon Xorg will not fall back to fbdev if the xgi driver doesn't attach.
xserver_xorg_others2.3Fully ported, for what it's worth. Many of these drivers will not be big-endian-safe, and it's likely that relevant chipset has never been used, and will never be used, on a PowerPC platform.
xserver_xvnc2.1preFully ported.

Major Platform Differences/Challenges

No VGA/VESA
Mac hardware does not use these standards. That means no VGA console device, and no X11 vesa driver. Instead, we must use kernel framebuffer drivers and an X driver which can use them (xfbdev). If you attempt to use any other driver, it will compete with the framebuffer driver for access to graphics resources, resulting in a mangled display, unless you prevent the framebuffer console from associating itself with the virtual terminal that you are starting Xorg on (e.g. using a kernel parameter such as fbcon=vc:1-2). The framebuffer must be compiled into the kernel, or you won't see anything during the early stages of the boot process, which makes troubleshooting almost impossible. Unfortunately the framebuffer has very little support for 2D hardware acceleration (and no 3D acceleration at all). Many framebuffer drivers are not big-endian safe, and will mangle colours on PowerPC platforms.
No PXE
Macs use OpenFirmware instead of anything resembling a PC BIOS, and don't support PXE, which is an x86-only protocol, for network booting. OpenFirmware does support DHCP (or BOOTP) and TFTP. However, Apple's OpenFirmware DHCP (actually BOOTP) implementation does not conform to Internet RFCs and will not work with stock DHCP servers (except OS X Server's DHCP server, naturally!). The ISC 3.x DHCP server can be tweaked to work around the Apple brain damage (see the Links section below), or alternatively there is a patch for ISC DHCP server (versions 2 and 3) that does the same thing, but AFAIK there is no Mac-friendly Windows DHCP implementation.
Filesystem-[Un]aware BIOS
OpenFirmware is not filesystem-agnostic like the PC BIOS. Macs have a built-in boot loader that can only boot HFS and HFS+; they can't boot "pure" ISO9660, nor can they boot Ext2/3 directly. Efikas, fortunately, can boot ISO9660 and Ext2/3, although there are some limitations (see the Efika page). To boot Macs to Linux from disk, you have to set up an HFS[+] partition (typically a dedicated minimum size (800k) partition) containing the yaboot secondary boot loader, which understands Ext2/3. There is a lot of disinformation circulating about this, mostly relating to more restrictive Old World boot ROMs and Mac OS 9 or earlier. The only way you can boot a CD is to use disk emulation or a Hybrid ISO9660/HFS image. Fortunately the problem of how to create hybrid images using cdrtools has been solved, but the mkisofs documentation is very misleading. Ignore everything that it says about the need to use apple_driver to extract the proprietary Apple driver from an existing CD - this ceased to be necessary years ago!
Different Endianness
80x86 is little-endian, and PowerPC is big-endian. This means that any code that makes assumptions about byte ordering is unlikely to work properly on PowerPC. Fortunately most open source programmers know how to write portable code, so this isn't a major problem, but it does pop up on occasion (eg. framebuffer and Xorg drivers).
Non-standard keyboard
Macs have keyboards with layouts and scancodes that are different from the commonplace PC-10x standards. You can of course throw out the Apple keyboard and use a PC-10x USB keyboard instead, unless (like me) you're using an Apple laptop with and integral keyboard. By default, though, the DIET-PC PPC port will assume an Apple keyboard (which means that shell/files/lib/kbd/kmaps/default.bkmap and xcore/files/usr/X11R6/lib/X11/xkb/compiled/default.xkm are compiled from different source data than the x86 versions). Efikas, on the other hand, need the standard PC keyboard keymap.
Single-button mouse
A single-button mouse is an absolute curse in a UNIX environment. In fact, it's an absolute curse in any environment - why do Apple persist with this insanity? Throw out the Apple mouse and get a decent one. If (again like me) you have an integral mouse, there is a kernel hack known as pbmousehack that now comes standard with the Linux kernel which can be used to map keyboard keys to buttons 2 and 3. The doco for this hack used to be at http://aio.nocrew.org/projects/pbmousehack/ but it seems to have gone missing.
Alternative Disk Partitioning
Apple uses a different disk partitioning scheme than Microsoft. Microsoft (DOS) partitioning isn't any better or more open than Apple's - in fact it's technically inferior - but it's highly prevalent in the PC universe and hence something of a de facto standard. In practical terms, this means that you can't use fdisk/cfdisk on Mac disks. You have to use mac-fdisk (formerly pdisk) or GNU parted instead.
Lack of Third-Party Software
Many vendors provide Linux software these days, but they use the term Linux as a synonym for x86 Linux (and often only 32-bit x86 Linux). There are practically no commercial or OEM binaries available for PowerPC Linux. If they don't provide full source code that you can compile yourself, then you're out of luck. The biggest problem area in this respect is Citrix ICA Client. There's a client for Mac OS X, but Mac OS X is Aqua/BSD/Mach-based, not X11/GNU/Linux-based, and Linux can't run OS X binaries natively. There's a (slightly less functional) Java-based ICA Client that could be used, but the Java Runtime Environment is really too big for embedded use. In fact, sourcing a working JRE with a browser plugin is a struggle in itself (you'll need the IBM 32-bit iSeries/pSeries J2SE 5.0 - read this HowTo).

Links