Linux for Macintosh 68K Port
The Daynaport card I had been given was very close to several PC designs. The 8390 Ethernet chip and block of RAM on it made that quite clear. There are, however, 224 possible locations for the chip and memory within each Nubus slot space.
Finding out where the device was hidden required building a collection of kernels which searched the 24 bits of address space looking for two things. First, it looked for areas of memory which could be read and written; second, it looked for areas like those which had the additional property of giving different results when read back. The 8390 chip has several control registers; by playing with these, it is possible to reliably identify the chip. (This same code is used to probe for NE2000 and WD80x3 cards in Linux for PC.) On the Macintosh, the RAM was easy to find but the 8390 did not show up.
Having played with the RAM behaviour a bit, I discovered that the memory was mapped to alternate 16 bits in its address space. That is, if you wanted to read it, you had to read two bytes, skip two bytes, read two bytes, etc. A bit of further experimentation revealed that the Ethernet controller registers occurred every fourth byte, that the RAM occurred every other pair of bytes and was 16-bits wide and that the Ethernet controller saw the 16-bit wide memory as 8-bit wide.
This sort of technique worked for mapping a large number of devices and address spaces and helped to discover the location of additional devices in the Apple I/O spaces. We still don't know enough to drive the Apple sound chip and the “Integrated Woz Machine” (floppy disk controller), but we do know where they are located.
When you need to start testing a system by booting into user space, you need a file system. The NFS root file system is extremely attractive for this and has been used for most ports. The NFS (Network File System) makes transaction requests at the level of files rather than disk blocks. This has the saving grace that errors in the new port cause transactions to get rejected. If you are trying to debug a new port and a SCSI controller driver at the same time, you will instead spend much of your time reformatting and reinstalling the disk from which you are attempting to boot. Using NFS limits the possibilities for errors and makes it easier to add and edit files as you attempt to make the machine work.
The initial installs were done with a set of tar files, known as “watchtower”, for the M68K. Watchtower is extremely outdated but is small and easy to unpack. Since the goal was to get a shell prompt, the age of the binaries was not a serious worry. Watchtower also demonstrates another strength of Linux/M68K—all the ports run the same binaries. Instead of having to cross compile and debug all the binaries for the Macintosh, I was unpacking and booting a file system set up for installation on a Commodore Amiga.
With a few modifications to the drivers and several small bug fixes to the kernel code, the applications began to run. As most of the code we needed to add for a new M68K platform was drivers and setup code, once things began to work, most applications sprang to life. It took a couple of tweaks to get floating point to always behave, but once done, I was able to boot the machine fully multi-user but without keyboard, mouse or hard disk support.
It took almost a month before anyone else got the kernel to boot on their own machine. A lot of debugging removed some rather bad assumptions that had “escaped” the code cleanup. Gradually, other MacLinux 68K machines began to pop into being. This is an extremely important step for any project, as it allows others to contribute effectively. Michael Schmitz wrote the SCSI drivers and much of the keyboard and mouse support. He is now adding IDE. Numerous others have tested and debugged code on many varieties of Macintosh and even made it work on some.
While any new port is difficult, the structure of the Linux M68K kernel tree is very well-designed and delivers on its intention to allow easy portability between M68K targets. Several sections of this code are rightfully being used cross-architecture as well as cross-platform.
Making a free software port work seems to be about having a small number of people willing to take the project the first half of the way. Once this point is reached, the project gathers momentum of its own accord, even when it is something as pointless as Linux on a Macintosh II.
Lack of documentation is only a hindrance. It will not prevent determined people from exercising their basic rights to use and operate property they bought and now own. Instead, it reflects badly on the vendor who is trying to be a nuisance. If the only documentation on the keyboard interface is entitled “Space aliens ate my mouse”, someone will still find it.
Always be the second operating system ported to an undocumented platform. The sterling work done by the OpenBSD/Macintosh team was a huge help to the Linux project. I'm also happy to say that even though half of the world may spend their time arguing on Usenet advocacy groups, the relationship between the Linux and BSD Macintosh teams has always been one of mutual co-operation. Together, we advance our detective work and knowledge of the Macintosh platforms to the good of all Macintosh users dumped and orphaned by Apple.
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems
Join editor Bill Childers and Bit9's Paul Riegle on April 27 at 12pm Central to learn how to keep your Linux systems secure.
Free to Linux Journal readers.Register Now!
- Cluetrain at Fifteen
- Getting Good Vibrations with Linux
- Embedding Python in Your C Programs
- [<Megashare>] Watch Mrs Brown's Boys Movie Online Full Movie HD 2014
- New Products
- Customizing Vim
- Security Hardening with Ansible
- Memory Ordering in Modern Microprocessors, Part I
- Tech Tip: Really Simple HTTP Server with Python
- Readers' Choice Awards 2013