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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide