From eLinux.org
< Flameman
Revision as of 14:01, 27 October 2011 by Peter Huewe (talk | contribs) (Spellcheck)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

For more interesting projects done by Flameman, be sure to check out his project index




gentoo on Motorola's 680x0 Processor

“Linux is NOT portable (uses 386 task switching etc.), and it probably never will support anything other than AT-hard disks, as that's all I have.” --Linus Torvalds, August 25, 1991.

In the five years since Linus wrote those words, Linux has been ported from its Intel roots to a number of other architectures: the ports to the Alpha and Sparc processors are probably the most familiar to readers of Linux Journal. In all the attention given to ports to ever more exotic hardware, it's easy to overlook the first production quality port: Linux/m68k.

The “m68k” stands for the Motorola 68000 series of processors, found at the heart of popular computers like the Apple Macintosh, the Amiga, the Atari ST and its successors (the Atari TT, Medusa and Falcon), as well as the Sun 3, NeXT, Hewlett-Packard/Apollo Domain workstations and others. The MC68020 (with the MC68851 memory management unit), MC68030, MC68040, MC68LC040 and MC68060 are the only CPUs in the 68000 family supported by Linux/m68k, because Linux (like other Unix-like operating systems) requires a memory management unit (MMU) for protected and virtual memory support. A floating point unit is optional, but recommended. Floating point emulation is not distributed in the main kernel tree, since its copyright conflicts with the GNU General Public License.

Like Linux/i386, 4MB of RAM is the absolute minimum, with 8MB being sufficient for most uses. The X Window System requires a minimum of 12MB of RAM for a usable system. A minimal installation currently requires about 55MB of hard drive space, plus at least a few MB of swap space. My personal system currently has about 830MB of hard drive space devoted to Linux (one SCSI hard drive and most of two IDE hard drives). When it comes to RAM and hard drive space, you can never have too much.

Linux/m68k started out as a port of Linux to work only on the Amiga. Hamish Macdonald and Greg Harp released their first version, which they called 0.05, to the public on July 1, 1993. This version was based on Intel Linux 0.99pl9. Soon after that release, several groups of Atari users working independently made the first efforts to adapt the port to that platform. The two ports were merged into one tree starting with 0.9 in July of 1994, with many new features like Ethernet, frame buffer and X Window System support arriving with 0.9pl5 later that year. Further efforts were made to combine some of the advances of the Linux/i386 1.0 and 1.1 series, including ELF support, into the Linux/m68k 0.9 series, culminating in 0.9pl13. Roman Hodek took over maintenance of 0.9 while Hamish started work on catching up with Linux/i386, then approaching the 1.2 release.

The adaptation of Linux/m68k to the general 1.2 kernel was a difficult process. From the first public release (1.2.10), there were 13 patch levels in 11 months (the final release was known as 1.2.13pl10). The format of ext2fs used under Linux/m68k was changed twice (once from 0.9.13 to 1.2.10, and again in 1.2.13pl4). Overall, the 1.2 series saw Linux/m68k mature into a usable system; major improvements were made in X support, and a color display was implemented on the Amiga.

By the time Linux/m68k 1.2 became stable, however, the rest of the Linux community was moving ahead at a rapid pace. Hamish again turned over a usable kernel to Roman and did some very preliminary work on the 1.3 series; Jes Degn Sòrensen adopted the 1.3 source tree in the Autumn of 1995 and began coordinating the work on it. After the initial hurdles of getting the basic code working, progress came quickly. The first working 1.3 series kernel (1.3.23) was released in late February 1996, and was brought into sync by early April (to 1.3.86, one day after the release of Linux).

The current, stable Linux/m68k version is 2.0.28. Development of Linux/m68k continues unabated, with the recent 2.1.17 development release of the main kernel integrating over several hundred kilobytes of changes from the Linux/m68k tree.

As of Linux/m68k 2.0.28, the latest release of the production 2.0 kernel, the Amiga and Atari are directly supported. Users of Motorola VMEbus systems (the MVME 162, 166 and 167) can use an earlier release, 2.0.8. Porting efforts are underway for the Sun 3 and Hewlett-Packard/Apollo Domain workstations and the Apple Macintosh. There has also been some interest in a port to the NeXT workstation.

Compatibility between Linux/m68k and Linux/i386 is very high at the source level. Almost all programs that don't use Intel-specific optimizations (like -m486), assembler code, SVGAlib or /dev/port should work “out of the box”. Notable exceptions are programs that expect the proc file system's data to be in a specific format (such as /proc/interrupts, which on Linux/m68k can contain any number of interrupts, including shared interrupts). Almost all of the GNU project's software has been tested and used successfully on Linux/m68k, as have the popular Perl, Python and Tcl programming languages and free Web browsers including Arena, Chimera, Grail, Lynx and Mosaic.

As of this writing, no commercial software available for Linux/i386 has been recompiled for Linux/m68k, nor has most other software released without source (with the notable exception of the XForms library). The primary obstacles are as follows:

  1. There is no SVGAlib support on Linux/m68k.
  2. There is no true Motif port to Linux/m68k. 

Motif 1.2 has been successfully compiled and used under Linux/m68k, but the individual who did that work doesn't have a license to sell Motif.

Unlike Linux on Intel and Alpha, there is no standard video hardware under Linux/m68k. The Amiga and Atari video chip sets are fundamentally different, as are the various graphics adapters available for both systems. Linux/m68k gets around this problem by using the Universal Framebuffer (UFB) device. This term is misleading, since it is used only on Linux/m68k at this point; but there are plans to merge it with the SparcLinux Framebuffer later. The UFB device abstracts the hardware interface to support a relatively simple, device- and system-independent programming interface. An easy-to-use user-mode library, known as oFBsis, is under development as part of the OSIS project to emulate the Atari TOS environment. One side effect of the UFB approach is virtually all Linux/m68k binaries are compatible with all Linux/m68k platforms. For example, the XFree68 server binary can operate all of the display hardware supported by Linux/m68k on both the Atari and Amiga. Even the kernel can be compiled to run on both Ataris and Amigas, and was distributed this way until the 2.0 series, when the number of devices needed for each OS made the combined kernel too large for users with only 4 MB of RAM. More programs supporting the UFB interface are forthcoming.

One of the most exciting developments in recent months is the port of the Debian distribution to Linux/m68k. Debian/m68k is currently in beta testing and will be released in tandem with the next Debian release. Most users currently install Linux/m68k manually using a number of tar files known as the Watchtower-2 file system, a fairly complicated procedure for those not familiar with Unix. There is also an older distribution, based on the 1.2 series kernels, called ALD, available for Ataris on CD-ROM. A proper distribution for both platforms, with support from Amiga and Atari CD-ROM vendors, in addition to the Linux CD vending community, would help make Linux a viable alternative operating system for serious Amiga and Atari users. At present, the only CD-ROMs available are the ALD CD-ROM and Infomagic's quarterly Linux Developer's Resource 6 CD set.

With the disappearance of the Amiga and Atari commercial developer communities over the past few years, many users have turned to the Free Software Foundation's GNU project for the tools they need. Unfortunately, the Unix heritage of the FSF tools causes problems for Amiga and Atari users who must contend with conflicting file naming formats, weak integration with the underlying OS, and memory-hogging emulation libraries. Linux and other free Unix-like operating systems can provide an environment suited for running these tools, with features like memory protection and virtual memory built-in, at minimal cost.

Substantial progress is underway to run well-behaved Amiga and Atari programs under X. The OSIS project, mentioned above, is usable for many Atari TOS applications already; AmigaOS emulation is also available but slow (via the Un*x Amiga Emulator), with faster support for programs that run within AmigaOS rules being worked on under both UAE and the AmigaOS Replacement OS (AROS). Full-speed Macintosh emulation should also be possible as it is under AmigaOS, but as yet, no one has demonstrated it. Binary compatibility with other Unix-like operating systems on Motorola platforms (similar to iBCS on Intel) is another area that could be developed further and may follow with the Sun 3 port. More emulation support is expected once Linux/m68k becomes easily accessible to Amiga and Atari users and their large freeware authoring communities.

Support for expansion devices under Linux/m68k is rather limited at present. Virtually every Ethernet card ever designed for the Amiga and Atari is supported, but only a relative handful of other devices are supported at present. However, many of them—like the Commodore A2091 and GVP SCSI controllers—are among the most common or—like the SCSI options for the Phase 5 accelerators—the most recent. The relative lack of people with hardware knowledge in the Linux/m68k community has slowed development in this area. With the wider popularity of Linux/m68k that should result after the Debian distribution is released, the dearth of technical expertise should become less of a setback as more people with hardware knowledge join in the development process.

While it is difficult to judge the popularity of other Unix-like operating systems on the Amiga and Atari (primarily NetBSD and OpenBSD), the Linux/m68k Registration Site seems to be a fairly accurate measure of Linux/m68k users. According to the site, well over 400 people use Linux/m68k at least some of the time. Our Registration Site is prominently advertised at most of the web pages devoted to Linux/m68k, and Geert Uytterhoeven, its maintainer, posts regular messages to the Linux/m68k-related newsgroups with statistics and a registration form. Registrations can be made using a Web-based form at the site, through e-mail or via snail mail. Despite these efforts, many users of Linux/m68k who only occasionally have or do not have Internet access remain unregistered. It is hoped that vendors of Linux/m68k distributions, once they become available, will help publicize the registration site.

The Web has become an increasingly important source of Linux/m68k information. Over a four-day period around Christmas, 350 visits to the primary site of the Linux/m68k Home Pages were recorded. The registration site also receives hundreds of visits per week. The Frequently Asked Questions file and installation guides for Amigas, Ataris and VME systems are available on the Web. Other Linux/m68k pages are available in French, German, Italian and Portuguese. Coupled with the very active developers' mailing list and the Linux/m68k-related newsgroups (in both English and German), users are well-supported with solid information and quick responses from the Linux/m68k user and developer communities.

As most of the developers reside in northern Europe, they have met a couple of times in person. The Linux/m68k project is in many ways a microcosm of the larger Linux project, bringing together people from across the world in pursuit of a common goal. A recent poster to comp.os.linux.m68k commented that the 68000-series processor has many years of life ahead of it. Those of us who work to promote Linux/m68k hope to keep the Motorola 68000 a viable platform for serious computing. With Linux/m68k, you can put together a complete Linux system for well under $1,000. So before you rush out and buy that $8,000 Alpha, dig through your closet, find that old processor, install Linux/m68, and have a computer with the same functionality for a lot less money.

A bit about the m68k platforms


The Amiga was the first 680x0-based computer to have Linux ported to it. The first Amiga computer was the Amiga 1000, released in mid-1985. It featured a 68000 processor running at 7.14 MHz, along with 256k of RAM.

The Amiga line has included quite a few models, including the Amiga 500, 600, 1200, 2000 (and its variants, like the 1500 and 2500), 3000 and 4000. The 3000T and 4000T are tower versions of the 3000 and 4000, respectively.

The Amiga line also includes the CDTV and CD-32 platforms, which are CD-ROM-based Amigas. More recently, clones have appeared, like the DraCo and BoXeR motherboard.

Recent Amigas can be upgraded to use PowerPC 603e and 604e processors in addition to a 680x0 processor using third-party CPU boards. Atari

The Atari 32-bit series was the second platform to receive an implementation of Linux/m68k. The Atari machines were launched with the release of the ST520 in mid-1985.

The Atari line includes the ST models, TT and Falcon. There have also been a number of Atari clones, including the Medusa and Hades. Macintosh

The Macintosh, introduced in 1984, was the first popular 680x0-based computer. There have been dozens of different 680x0-based Macintoshes.

The port of Linux/m68k to the Macintosh platform is still ongoing, though some systems are usable today with functional SCSI, IDE, Ethernet and console support.

Current gaps in support include FPU-less Macs (the FPU emulator is still a work-in-progress) and most Powerbooks (ADB is not supported yet, though code from the Linux/PPC and MkLinux projects will help greatly).

A fairly comprehensive overview may be found at the Linux/m68k on Macintosh site, http://www.mac.linux-m68k.org/. Motorola VMEbus

(written by Richard Hirst)

Motorola has released a number of single-board systems using the 680x0 processors, based on the VME bus standard. More information on these systems is available at Motorola's web site.

(More information from a later post:)

I have a VME system based on Motorola MVME boards. Follow the links from www.sleepie.demon.co.uk to find out more about the boards. The boards I use are basically single board computers, which can be plugged into a VME card cage. The interface to the VME is via a chip called the VMEchip2 which provides programmable address windows between the VME bus and the on-board bus. As part of programming the VMEchip2, you specify the AM (Address Modifier) code to use in VME bus cycles. The AM code specifies A24, A32, etc.

VME is used a lot in industrial applications, with various interface boards for digital i/o, etc, so people using Linux on these boards often want to read/write to specific addresses in the VME address space.

Before anyone asks, these boards are expensive (relative to a good PC) - I got mine from work so didn't have to pay for them. NeXT workstations

The NeXT workstations were produced by NeXT Computer, Inc., starting in the late 1980s and ending in 1994. The workstations were made in two configurations: the NeXT Cube and NeXTstation (a.k.a. "the slab").

The NeXT Cube came in 68030 and 68040-based configurations, while the slabs were produced later and came with 68040's only. 68040-based models came in 25MHz and 33MHz (Turbo) editions.

The basic NeXTs came with 4-grayscale video (black, white and two shades of gray). Color NeXTs are capable of 12-bit color, or 4096-color video output (16 levels of red, green and blue). NeXT also produced the NeXT Dimension board for the cubes, which was capable of 24-bit color.

NeXTs ran the NeXTstep operating system; however, current versions of that OS (now called OpenStep) no longer support the original ("black") m68k-based hardware; this has made a Linux port to the NeXT particularly attractive. More information can be found at the Li/NeXT web site, http://www.black.linux-m68k.org/. Other systems

Any takers?


the Debian and the gentoo m68k port seems to be pretty dead these days, the mac68k is unsupported at all in the linux community, but "I don't care if space aliens ate my mouse": this hack allows to boot linux-m68k from a floppy on a macintosh such as LC475. With it, you can create rescue disk, or remove the MacOS partition (needed by the legacy penguin booter) from your HD and install gentoo-m68k: I'm developing a full gentoo-m68k-stage3.

The main goal of this project is to port gentoo-m68k to the 68k-based Macintoshes (not PowerPc Macs) and to support as much hardware as possible. There are currently ports of the 2.6 kernel. Just about every Mac with a 68030 or better processor is usable, older 68000-based Macs 68000-based Macs (128k/512k, Plus, SE, Classic, Portable, PowerBook 100) are not supported so cannot and will never run gentoo-m68k: If you have one of these, you're pretty much out of luck, Sorry. For more information on which machines will work, see the machine status page (coming): personally I will support the LC475 that I personally own, feel free to add your mac68K machine into the status page !

feel free to contact me (see the contact below)


The Target-goal of this page is

  • install gentoo-m68k into scsi-disk
  • make the board able to boot from it
  • describe how to add a serial display
  • describe something useful with you can do with the board
  • describe other Operating Systems available for the board

People you could contact if you need help

  • flameman, i'm currently use this board for a project, email
    • msn daredevil-coder@hotmail.it
    • email flamemaniii@gmail.com
    • irc.nick flameman (channel #edev, #gentoo-ppc)
  • you ... if you want ;-)

gentoo forum


mac68k forum, 68k Debian Linux Unstable


ideas from build root



How can i understand the internal mechanism of mac68k booting ?

By reading docs, all needed documentation is available here :


You should find doc about earlier mac, so you could read about HFS bootblock: that is what your first and second boot stage need to bootstrap the kernel

What is supported in kernel &Stuff ?

Any machines in particular that we might have problems with

There is a huge variety of hardware devices across the range of supported models. Many models contain unique hardware and they tend to have their idiosyncrasies. We constantly have to rethink our drivers and interfaces to maintain the kind of device abstraction that makes Linux so portable. For more information on the status of each model, see the machine status page.

What about MODE32

As Mode32 merely fixes a ROM problem, it is not required for the general operation of Linux on the Macintosh, but being that Penguin is a MacOS application, it may be useful in some cases. See below.

What about a PMMU

In order to get the kernel to run on your older 68020 based Macintoshes, you will need to get a 68851 PMMU chip to enable the paged memory that kernel (and A/UX) requires. Of the two 68020 machines, only the Mac II supports the addition of a PMMU. The Mac LC, however does not have this capability so it is not supported.

Also, you should be aware that the 68851 steals an extra clock cycle for every instruction executed in order to do address translation, thus making an already pitifully slow machine by today's standards even slower. 10. Where can I buy a PMMU?

Since no 68020 Macs shipped with a 68851 PMMU, you'll need to buy one and install it yourself. Adam recommends Data Memory Systems (www.datamem.com) and he says that you can get it for $29 + shipping. Of course, $29 will probably buy you an '030 Mac somewhere. :) 11. How much RAM?

The gentoo-m68k port requires about the same amount of RAM as the other Linux ports: about 4 megs at the minimum. Even if Linux supports less, the recent versions of the Penguin booter do not. 4 MB is no longer enough to load a 2.2 kernel and a RAM disk. Even 5 MB is stretching it. System 7.0.1 uses less memory than the later releases; if you have a low memory machine, you might try running it. Also, Emile requires less RAM than MacOS + Penguin. If you intend to run Debian 3.0, you are looking at a more usable minimum of 32 MB. Section V: Specific Hardware Issues

What about NUbus

NuBus is a 32-bit parallel computer bus, originally developed at MIT as a part of the NuMachine workstation project. The first complete implementation of the NuBus and the NuMachine was done by Western Digital for their NuMachine, and for the Lisp Machines Inc. LMI-Lambda. The NuBus was later incorporated in products by Texas Instruments (Explorer), Apple Computer and NeXT. It is no longer widely used outside of the embedded market.

   * 1 NuBus architecture
   * 2 NuBus implementations
   * 3 See also
   * 4 External links

NuBus architecture

NuBus was a considerable step forward compared to other interfaces of the day. At the time most computer bus systems were 8-bit, as were the computers they plugged into. However NuBus decided on a 32-bit interface because it was clear the market was headed in this direction.

In addition, NuBus was agnostic about the processor itself. Most buses up to this point were basically the pins on the CPU run out onto the backplane, meaning that the cards had to conform to the signaling and data standards of the machine they were plugged into (being little endian for instance). NuBus made no such assumptions, which meant that a NuBus card could be plugged into any NuBus machine, as long as there was an appropriate device driver.

In order to select the proper device driver, NuBus included an ID scheme that allowed the cards to identify themselves to the host computer during startup. This meant that the user didn't have to configure the system, the bane of bus systems up to that point. For instance, with ISA the driver had to be configured not only for the card, but for any memory it required, the interrupts it used, and so on. NuBus required no such configuration, making it one of the first examples of plug-and-play architecture.

On the downside, while this flexibility made NuBus much simpler for the user and device driver authors, it made things more difficult for the designers of the cards themselves. Whereas most "simple" bus systems were easily supported with a handful of input/output chips designed to be used with that CPU in mind, with NuBus every card and computer had to convert everything in a platform-agnostic "NuBus world". Typically this meant adding a NuBus controller chip between the bus and any I/O chips on the card, increasing costs. While this is a trivial exercise today, one that all newer buses require, at the time in the 1980s NuBus was considered complex and expensive.

NuBus implementations

The NuBus became a standard in 1987 as IEEE 1196. This version used a standard 96-pin three-row connector, running the system on a 10 MHz clock for a maximum burst throughput of 40 MB/s and average speeds of 10 to 20 MB/s. A later addition, NuBus90, increased the clock rate to 20 MHz for better throughput, burst increasing to about 70 MB/s, and average to about 30 MB/s.

The NuBus was first developed commercially in the Western Digital NuMachine, and first used in a production product by their licensee, Lisp Machines, Inc., in the LMI-Lambda, a Lisp Machine. The project and the development group was sold by Western Digital to Texas Instruments in 1984. The technology was incorporated into their TI Explorer, also a Lisp Machine. In 1986, Texas Instruments used the NuBus in the S1500 multiprocessor UNIX system.

NuBus was later selected by Apple Computer for use in their Macintosh II project, where its plug-n-play nature fit well with the Mac philosophy of ease-of-use. It was used in most of their Mac line through the late 1980s and into the 1990s, and was upgraded to NuBus90 starting with the Macintosh Quadras. Early Quadras only supported the 20 MHz rate when two cards were talking to each other, since the motherboard controller was not upgraded. This was later addressed in the 660AV and 840AV models, and used on the early PowerMac models. Apple's implementation also used pin and socket connectors with thumbscrews on the back of the card rather than the often stubborn edge connectors with Phillips screws inside the case that most cards use, making it much easier to install cards. Apple's computers also supplied an always-on +5 V "trickle" power supply for tasks such as watching the phone line while the computer was turned off. This was apparently part of an unapproved NuBus standard.

NuBus was also selected by NeXT Computer for their line of machines, but used a different physical PCB layout. NuBus appears to have seen little use outside these roles, and when Apple switched to PCI in the mid 1990s, NuBus quickly disappeared.

PCI and NuBus

This section provides some background about the differences between the PCI and NuBus architectures. The PCI bus exhibits a number of fundamental differences from NuBus , the previous Macintosh bus standard. The most important of these differences are listed

Comparison of NuBus and the PCI bus

Feature                            NuBus               PCI bus
Bus clock rate                     10 MHz              33 MHz, 66 MHz
Addressing                         Geographic          Dynamic
Signal loading                     No enforced rules   One load per signal
Transaction length determination   at start            at end
Bus termination                    Resistor network    Not required
Bus control arbitration            Distributed         Centralized
Addressing spaces                  Memory only         Memory, I/O, configuration
Wait-state generators              Slave only          Slave and master
Kinds of expansion                 Cards only          Cards and ASIC chips
Timeout                            255 bus clocks      5 bus clocks
Burst capability (byte)            8, 16, 32, 64       Any number of bytes
Power allocation                   15 W per card       7.5, 15, or 25 W per card

00001 /*
00002   nubus.h: various definitions and prototypes for NuBus drivers to use.
00004   Originally written by Alan Cox.
00006   Hacked to death by C. Scott Ananian and David Huggins-Daines.
00008   Some of the constants in here are from the corresponding
00009   NetBSD/OpenBSD header file, by Allen Briggs.  We figured out the
00010   rest of them on our own. */
00012 #ifndef LINUX_NUBUS_H
00013 #define LINUX_NUBUS_H
00015 #ifdef __KERNEL__
00016 #include <asm/nubus.h>
00017 #endif
00019 enum nubus_category {
00020       NUBUS_CAT_BOARD          = 0x0001,
00021       NUBUS_CAT_DISPLAY        = 0x0003,
00022       NUBUS_CAT_NETWORK        = 0x0004,
00023       NUBUS_CAT_COMMUNICATIONS = 0x0006,
00024       NUBUS_CAT_FONT           = 0x0009,
00025       NUBUS_CAT_CPU            = 0x000A,
00026       /* For lack of a better name */
00027       NUBUS_CAT_DUODOCK        = 0x0020
00028 };
00030 enum nubus_type_network {
00031       NUBUS_TYPE_ETHERNET      = 0x0001,
00032       NUBUS_TYPE_RS232         = 0x0002
00033 };
00035 enum nubus_type_display {
00036       NUBUS_TYPE_VIDEO         = 0x0001
00037 };
00039 enum nubus_type_cpu {
00040       NUBUS_TYPE_68020         = 0x0003,
00041       NUBUS_TYPE_68030         = 0x0004,
00042       NUBUS_TYPE_68040         = 0x0005
00043 };
00045 /* Known <Cat,Type,SW,HW> tuples: (according to TattleTech and Slots)
00046  *  68030 motherboards: <10,4,0,24>
00047  *  68040 motherboards: <10,5,0,24>
00048  *  DuoDock Plus: <32,1,1,2>
00049  *
00050  *  Toby Frame Buffer card: <3,1,1,1>
00051  *  RBV built-in video (IIci): <3,1,1,24>
00052  *  Valkyrie built-in video (Q630): <3,1,1,46>
00053  *  Macintosh Display Card: <3,1,1,25>
00054  *  Sonora built-in video (P460): <3,1,1,34>
00055  *  Jet framebuffer (DuoDock Plus): <3,1,1,41>
00056  *
00057  *  SONIC comm-slot/on-board and DuoDock Ethernet: <4,1,1,272>
00058  *  SONIC LC-PDS Ethernet (Dayna, but like Apple 16-bit, sort of): <4,1,1,271>
00059  *  Apple SONIC LC-PDS Ethernet ("Apple Ethernet LC Twisted-Pair Card"): <4,1,0,281>
00060  *  Sonic Systems Ethernet A-Series Card: <4,1,268,256>
00061  *  Asante MacCon NuBus-A: <4,1,260,256> (alpha-1.0,1.1 revision)
00062  *   ROM on the above card: <2,1,0,0>
00063  *  Cabletron ethernet card: <4,1,1,265>
00064  *  Farallon ethernet card: <4,1,268,256> (identical to Sonic Systems card)
00065  *  Kinetics EtherPort IIN: <4,1,259,262>
00066  *  API Engineering EtherRun_LCa PDS enet card: <4,1,282,256>
00067  *
00068  *  Add your devices to the list!  You can obtain the "Slots" utility
00069  *  from Apple's FTP site at:
00070  *  ftp://dev.apple.com/devworld/Tool_Chest/Devices_-_Hardware/NuBus_Slot_Manager/
00071  *
00072  *  Alternately, TattleTech can be found at any Info-Mac mirror site.  
00073  *  or from its distribution site: ftp://ftp.decismkr.com/dms
00074  */
00076 /* DrSW: Uniquely identifies the software interface to a board.  This
00077    is usually the one you want to look at when writing a driver.  It's
00078    not as useful as you think, though, because as we should know by
00079    now (duh), "Apple Compatible" can mean a lot of things... */
00081 /* Add known DrSW values here */
00082 enum nubus_drsw {
00083       /* NUBUS_CAT_DISPLAY */
00084       NUBUS_DRSW_APPLE        = 0x0001,
00085       NUBUS_DRSW_APPLE_HIRES  = 0x0013, /* MacII HiRes card driver */
00087       /* NUBUS_CAT_NETWORK */
00088       NUBUS_DRSW_3COM         = 0x0000,
00089       NUBUS_DRSW_CABLETRON    = 0x0001,
00090       NUBUS_DRSW_SONIC_LC     = 0x0001,
00091       NUBUS_DRSW_KINETICS     = 0x0103,
00092       NUBUS_DRSW_ASANTE       = 0x0104,
00093       NUBUS_DRSW_TECHWORKS    = 0x0109,
00094       NUBUS_DRSW_DAYNA        = 0x010b,
00095       NUBUS_DRSW_FARALLON     = 0x010c,
00096       NUBUS_DRSW_APPLE_SN     = 0x010f,
00097       NUBUS_DRSW_DAYNA2       = 0x0115,
00098       NUBUS_DRSW_FOCUS        = 0x011a,
00099       NUBUS_DRSW_ASANTE_CS    = 0x011d, /* use asante SMC9194 driver */
00100       NUBUS_DRSW_DAYNA_LC     = 0x011e,
00102       /* NUBUS_CAT_CPU */
00103       NUBUS_DRSW_NONE         = 0x0000,
00104 };
00106 /* DrHW: Uniquely identifies the hardware interface to a board (or at
00107    least, it should...  some video cards are known to incorrectly
00108    identify themselves as Toby cards) */
00110 /* Add known DrHW values here */
00111 enum nubus_drhw {
00112       /* NUBUS_CAT_DISPLAY */
00113       NUBUS_DRHW_APPLE_TFB      = 0x0001, /* Toby frame buffer card */
00114       NUBUS_DRHW_APPLE_WVC      = 0x0006, /* Apple Workstation Video Card */
00115       NUBUS_DRHW_SIGMA_CLRMAX   = 0x0007, /* Sigma Design ColorMax */
00116       NUBUS_DRHW_APPLE_SE30     = 0x0009, /* Apple SE/30 video */
00117       NUBUS_DRHW_APPLE_HRVC     = 0x0013, /* Mac II High-Res Video Card */
00118       NUBUS_DRHW_APPLE_PVC      = 0x0017, /* Mac II Portrait Video Card */
00119       NUBUS_DRHW_APPLE_RBV1     = 0x0018, /* IIci RBV video */
00120       NUBUS_DRHW_APPLE_MDC      = 0x0019, /* Macintosh Display Card */
00121       NUBUS_DRHW_APPLE_SONORA   = 0x0022, /* Sonora built-in video */
00122       NUBUS_DRHW_APPLE_24AC     = 0x002b, /* Mac 24AC Video Card */
00123       NUBUS_DRHW_APPLE_VALKYRIE = 0x002e,
00124       NUBUS_DRHW_APPLE_JET      = 0x0029, /* Jet framebuffer (DuoDock) */
00125       NUBUS_DRHW_SMAC_GFX       = 0x0105, /* SuperMac GFX */
00126       NUBUS_DRHW_RASTER_CB264   = 0x013B, /* RasterOps ColorBoard 264 */
00127       NUBUS_DRHW_MICRON_XCEED   = 0x0146, /* Micron Exceed color */
00128       NUBUS_DRHW_RDIUS_GSC      = 0x0153, /* Radius GS/C */
00129       NUBUS_DRHW_SMAC_SPEC8     = 0x017B, /* SuperMac Spectrum/8 */
00130       NUBUS_DRHW_SMAC_SPEC24    = 0x017C, /* SuperMac Spectrum/24 */
00131       NUBUS_DRHW_RASTER_CB364   = 0x026F, /* RasterOps ColorBoard 364 */
00132       NUBUS_DRHW_RDIUS_DCGX     = 0x027C, /* Radius DirectColor/GX */
00133       NUBUS_DRHW_RDIUS_PC8      = 0x0291, /* Radius PrecisionColor 8 */
00134       NUBUS_DRHW_LAPIS_PCS8     = 0x0292, /* Lapis ProColorServer 8 */
00135       NUBUS_DRHW_RASTER_24XLI   = 0x02A0, /* RasterOps 8/24 XLi */
00136       NUBUS_DRHW_RASTER_PBPGT   = 0x02A5, /* RasterOps PaintBoard Prism GT */
00137       NUBUS_DRHW_EMACH_FSX      = 0x02AE, /* E-Machines Futura SX */
00138       NUBUS_DRHW_RASTER_24XLTV  = 0x02B7, /* RasterOps 24XLTV */
00139       NUBUS_DRHW_SMAC_THUND24   = 0x02CB, /* SuperMac Thunder/24 */
00140       NUBUS_DRHW_SMAC_THUNDLGHT = 0x03D9, /* SuperMac ThunderLight */
00141       NUBUS_DRHW_RDIUS_PC24XP   = 0x0406, /* Radius PrecisionColor 24Xp */
00142       NUBUS_DRHW_RDIUS_PC24X    = 0x040A, /* Radius PrecisionColor 24X */
00143       NUBUS_DRHW_RDIUS_PC8XJ    = 0x040B, /* Radius PrecisionColor 8XJ */
00145       /* NUBUS_CAT_NETWORK */
00146       NUBUS_DRHW_INTERLAN       = 0x0100,
00147       NUBUS_DRHW_SMC9194        = 0x0101,
00148       NUBUS_DRHW_KINETICS       = 0x0106,
00149       NUBUS_DRHW_CABLETRON      = 0x0109,
00150       NUBUS_DRHW_ASANTE_LC      = 0x010f,
00151       NUBUS_DRHW_SONIC          = 0x0110,
00152       NUBUS_DRHW_TECHWORKS      = 0x0112,
00153       NUBUS_DRHW_APPLE_SONIC_NB = 0x0118,
00154       NUBUS_DRHW_APPLE_SONIC_LC = 0x0119,
00155       NUBUS_DRHW_FOCUS          = 0x011c,
00156       NUBUS_DRHW_SONNET         = 0x011d,
00157 };
00159 /* Resource IDs: These are the identifiers for the various weird and
00160    wonderful tidbits of information that may or may not reside in the
00161    NuBus ROM directory. */
00162 enum nubus_res_id {
00163       NUBUS_RESID_TYPE         = 0x0001,
00164       NUBUS_RESID_NAME         = 0x0002,
00165       NUBUS_RESID_ICON         = 0x0003,
00166       NUBUS_RESID_DRVRDIR      = 0x0004,
00167       NUBUS_RESID_LOADREC      = 0x0005,
00168       NUBUS_RESID_BOOTREC      = 0x0006,
00169       NUBUS_RESID_FLAGS        = 0x0007,
00170       NUBUS_RESID_HWDEVID      = 0x0008,
00171       NUBUS_RESID_MINOR_BASEOS = 0x000a,
00172       NUBUS_RESID_MINOR_LENGTH = 0x000b,
00173       NUBUS_RESID_MAJOR_BASEOS = 0x000c,
00174       NUBUS_RESID_MAJOR_LENGTH = 0x000d,
00175       NUBUS_RESID_CICN         = 0x000f,
00176       NUBUS_RESID_ICL8         = 0x0010,
00177       NUBUS_RESID_ICL4         = 0x0011,
00178 };
00180 /* Category-specific resources. */
00181 enum nubus_board_res_id {
00182       NUBUS_RESID_BOARDID      = 0x0020,
00183       NUBUS_RESID_PRAMINITDATA = 0x0021,
00184       NUBUS_RESID_PRIMARYINIT  = 0x0022,
00185       NUBUS_RESID_TIMEOUTCONST = 0x0023,
00186       NUBUS_RESID_VENDORINFO   = 0x0024,
00187       NUBUS_RESID_BOARDFLAGS   = 0x0025,
00188       NUBUS_RESID_SECONDINIT   = 0x0026,
00190       /* Not sure why Apple put these next two in here */
00191       NUBUS_RESID_VIDNAMES     = 0x0041,
00192       NUBUS_RESID_VIDMODES     = 0x007e
00193 };
00195 /* Fields within the vendor info directory */
00196 enum nubus_vendor_res_id {
00197       NUBUS_RESID_VEND_ID     = 0x0001,
00198       NUBUS_RESID_VEND_SERIAL = 0x0002,
00199       NUBUS_RESID_VEND_REV    = 0x0003,
00200       NUBUS_RESID_VEND_PART   = 0x0004,
00201       NUBUS_RESID_VEND_DATE   = 0x0005
00202 };
00204 enum nubus_net_res_id {
00205       NUBUS_RESID_MAC_ADDRESS  = 0x0080
00206 };
00208 enum nubus_cpu_res_id {
00209       NUBUS_RESID_MEMINFO      = 0x0081,
00210       NUBUS_RESID_ROMINFO      = 0x0082
00211 };
00213 enum nubus_display_res_id {
00214       NUBUS_RESID_GAMMADIR    = 0x0040,
00215       NUBUS_RESID_FIRSTMODE   = 0x0080,
00216       NUBUS_RESID_SECONDMODE  = 0x0081,
00217       NUBUS_RESID_THIRDMODE   = 0x0082,
00218       NUBUS_RESID_FOURTHMODE  = 0x0083,
00219       NUBUS_RESID_FIFTHMODE   = 0x0084,
00220       NUBUS_RESID_SIXTHMODE   = 0x0085
00221 };
00223 struct nubus_dir
00224 {
00225       unsigned char *base;
00226       unsigned char *ptr;
00227       int done;
00228       int mask;
00229 };
00231 struct nubus_dirent
00232 {
00233       unsigned char *base;
00234       unsigned char type;
00235       __u32 data; /* Actually 24bits used */
00236       int mask;
00237 };
00239 struct nubus_board {
00240       struct nubus_board* next;
00241       struct nubus_dev* first_dev;
00243       /* Only 9-E actually exist, though 0-8 are also theoretically
00244          possible, and 0 is a special case which represents the
00245          motherboard and onboard peripherals (Ethernet, video) */
00246       int slot;
00247       /* For slot 0, this is bogus. */
00248       char name[64];
00250       /* Format block */
00251       unsigned char* fblock;
00252       /* Root directory (does *not* always equal fblock + doffset!) */
00253       unsigned char* directory;
00255       unsigned long slot_addr;
00256       /* Offset to root directory (sometimes) */
00257       unsigned long doffset;
00258       /* Length over which to compute the crc */
00259       unsigned long rom_length;
00260       /* Completely useless most of the time */
00261       unsigned long crc;
00262       unsigned char rev;
00263       unsigned char format;
00264       unsigned char lanes;
00265 };
00267 struct nubus_dev {
00268       /* Next link in device list */
00269       struct nubus_dev* next;
00270       /* Directory entry in /proc/bus/nubus */
00271       struct proc_dir_entry* procdir;
00273       /* The functional resource ID of this device */
00274       unsigned char resid;
00275       /* These are mostly here for convenience; we could always read
00276          them from the ROMs if we wanted to */
00277       unsigned short category;
00278       unsigned short type;
00279       unsigned short dr_sw;
00280       unsigned short dr_hw;
00281       /* This is the device's name rather than the board's.
00282          Sometimes they are different.  Usually the board name is
00283          more correct. */
00284       char name[64];
00285       /* MacOS driver (I kid you not) */
00286       unsigned char* driver;
00287       /* Actually this is an offset */
00288       unsigned long iobase;
00289       unsigned long iosize;
00290       unsigned char flags, hwdevid;
00292       /* Functional directory */
00293       unsigned char* directory;
00294       /* Much of our info comes from here */
00295       struct nubus_board* board;
00296 };
00298 /* This is all NuBus devices (used to find devices later on) */
00299 extern struct nubus_dev* nubus_devices;
00300 /* This is all NuBus cards */
00301 extern struct nubus_board* nubus_boards;
00303 /* Generic NuBus interface functions, modelled after the PCI interface */
00304 void nubus_scan_bus(void);
00305 extern void nubus_proc_init(void);
00306 int get_nubus_list(char *buf);
00307 int nubus_proc_attach_device(struct nubus_dev *dev);
00308 int nubus_proc_detach_device(struct nubus_dev *dev);
00309 /* If we need more precision we can add some more of these */
00310 struct nubus_dev* nubus_find_device(unsigned short category,
00311                             unsigned short type,
00312                             unsigned short dr_hw,
00313                             unsigned short dr_sw,
00314                             const struct nubus_dev* from);
00315 struct nubus_dev* nubus_find_type(unsigned short category,
00316                           unsigned short type,
00317                           const struct nubus_dev* from);
00318 /* Might have more than one device in a slot, you know... */
00319 struct nubus_dev* nubus_find_slot(unsigned int slot,
00320                           const struct nubus_dev* from);
00322 /* These are somewhat more NuBus-specific.  They all return 0 for
00323    success and -1 for failure, as you'd expect. */
00325 /* The root directory which contains the board and functional
00326    directories */
00327 int nubus_get_root_dir(const struct nubus_board* board,
00328                    struct nubus_dir* dir);
00329 /* The board directory */
00330 int nubus_get_board_dir(const struct nubus_board* board,
00331                   struct nubus_dir* dir);
00332 /* The functional directory */
00333 int nubus_get_func_dir(const struct nubus_dev* dev,
00334                    struct nubus_dir* dir);
00336 /* These work on any directory gotten via the above */
00337 int nubus_readdir(struct nubus_dir* dir,
00338               struct nubus_dirent* ent);
00339 int nubus_find_rsrc(struct nubus_dir* dir,
00340                 unsigned char rsrc_type,
00341                 struct nubus_dirent* ent);
00342 int nubus_rewinddir(struct nubus_dir* dir);
00344 /* Things to do with directory entries */
00345 int nubus_get_subdir(const struct nubus_dirent* ent,
00346                  struct nubus_dir* dir);
00347 void nubus_get_rsrc_mem(void* dest,
00348                   const struct nubus_dirent *dirent,
00349                   int len);
00350 void nubus_get_rsrc_str(void* dest,
00351                   const struct nubus_dirent *dirent,
00352                   int maxlen);
00354 /* We'd like to get rid of this eventually.  Only daynaport.c uses it now. */
00355 static inline void *nubus_slot_addr(int slot)
00356 {
00357       return (void *)(0xF0000000|(slot<<24));
00358 }
00360 #endif /* LINUX_NUBUS_H */

What input devices are supported

Amazingly enough, we have keyboards (and mice)!

Some third-party 3 button mice are also supported. I have a Logitech MouseMan that works perfectly on the console and in X. With 2.6 kernels, use /dev/input/mice and "imps2" protocol. For older kernels, ADB mice are accessed in "cooked" mode through /dev/adbmouse using the "busmouse" protocol for gpm and X.

What about SCSI

LC475 should have a SCSI-2 fast10 of 10Mbyte/sec kernel 2.6.27 supports the macintosh scsi onbloard with cache disabled

chip: ...

kernel sym: ...

internal: 50p narrow

external: ...

measured tx rate: ...

{ text to be replaced The O2 has onboard support for SCSI devices. It has one internal and one external Ultra Wide SCSI controller. One of these controllers supports the internal disks, the other can be used via the external SCSI port. The Chipset is an Adaptec 7880. }

SCSI General

SCSI (Small Computer System Interface) was in the beginning of the 1980s one of the newly emerging standards operating at a logical level, which made it independent of the actual drives (was developed as SASI by Shugart). In 1986 SCSI became an approved ANSI standard and soon replaced most other high-bandwidth interface types. Since then several releases of the SCSI standard have been made - introducing higher bandwidth, support for more drives and along with that a variety of different cable and connector types.


Bus Standards
Industry Terminology 	Standards Terminology 	Bus speed  Bus width   Number of Devices
SCSI 1                             Fast5         5MByte/s       8bit 	      8-1
SCSI 2 (Fast SCSI)                 Fast10       10Mbyte/s 	8bit 	      8-1
SCSI 3 (Wide SCSI) 	           Fast10       20Mbyte/s      16bit 	     16-1
Ultra SCSI 	                   Fast20       20Mbyte/s 	8bit          8-1
Wide Ultra SCSI 	           Fast20 	40Mbyte/s      16bit 	     16-1
Ultra-2 SCSI 	                   Fast40       40Mbyte/s 	8bit 	      8-1
Wide Ultra-2 SCSI                  Fast40       80Mbyte/s      16bit 	     16-1
Ultra160 	                   Fast80      160Mbyte/s      16bit         16-1



Looking at the table you'll notice that 16bit SCSI is usually labelled "Wide SCSI". When talking about 8bit SCSI standards in most cases people tend to talk about "Narrow SCSI" to point out what exactly they are talking about. Electrical Standards

If the different SCSI standards mentioned above aren't confusing enough on their own there are also terms like SE, LVD or HVD floating around. These refer to the way in which the signals are put onto the SCSI wires by the controller and the attached devices.

On SE (Single Ended) SCSI, which was in the original SCSI definition by the way, each signal line is driven against ground. The SCSI standards do not specify SE beyond Ultra SCSI.

On HVD (High Voltage Differential) two lines are used for each signal with one being the inverse of the other so that the actual SCSI signal is the difference between the two lines. This makes the signal much more robust to interference and allows much higher cable length than SE SCSI. The SCSI standards do not specify SE beyond Ultra 2 SCSI.

Both SE and HVD did use 5V logic and were common up to the Ultra SCSI standard. In the design process the used voltage was changed to 3.3V for the new specification which also used a differential interface. This was called LVD (Low Voltage Differential).

Although backwards compatibility was common across the SCSI standards this has not been the case for SE, HVD and LVD specifications. It is not possible to mix HVD or LVD devices with SE devices, neither is it possible to mix HVD and LVD devices. Typical modern LVD devices are multimode and can be used on both SE and LVD SCSI.

What about serial support

shortly: kernel 2.2 supports it, kernel 2.4 & kernel 2.6 doesn't support it at all

> The real driver for the serial ports on m68k Macintosh systems got > removed from the tree a long time ago and has not been replaced as of > this time. However, we still register mac_scc_dispatch as an interrupt > handler for the line that the SCC uses. This looks like you got an > interrupt for the serial chip and the interrupt code got confused trying > to dispatch to nothing. I've never seen it happen, but it does look like > that would be the expected behavior of the current code.

Serial support is working and in the 2.2 kernel. Until recently the Quadra 900 and 950 and the Mac IIfx required that you set the serial ports to "compatible" mode in MacOS before booting. However, we've recently learned how to do this from Linux, so with the very latest kernels, this won't be necessary.

Note that serial ports speeds greater than 38400 bps are not reliable in Linux. (This limitation applies to MacOS as well, except on some high-end models.)

As a side note, obviously the Mac serial plugs won't fit into your PC's serial ports and there are some other technical incompatibilities. Fear not! You can buy an adapter for $10 or so from a catalog or a larger computer store. You can also construct a workable null-modem cable in order to use your PC for a serial console by plugging together a PC null-modem cable and a Macintosh modem cable. With the correct cable, the Mac's RS422 serial port can be made electrically compatible with a PC's RS232 serial port. 3. Output?

Yes, we have framebuffers! The Macintosh framebuffer driver was recently rewritten for Linux 2.2, and now will give at least a workable text console on all models with internal video, as well as the most common NuBus video adaptors. This does not, however, imply that the colormaps will be even vaguely correct. Read on...

The video driver has trouble changing the color map on some models. If your Mac has this problem, and you're handy with ResEdit, you can now (since Penguin-16 at least) tweak the Penguin colormap in order to get something resembling decent color in X. (FIXME: There's a web page about this somewhere, but I've lost the URL...) However, if you fix the colors in X, the console will lose.

Only with the Valkyrie chipset (used on the 580 and 630 series) does the driver support changing the video mode and colour depth on the fly (using fbset, or the X server). To enable it under older kernels, add "video=valkyriefb:" (the colon is important) to the kernel command line in Penguin, and enjoy!

Finally, the Linux 2.2 fbcon subsystem supports 16 and 24-bit truecolor modes on the text console, and the XFree68_FBDev X server also supports them. Therefore, even on machines such as the AV series Quadras where we don't support colormap setting, you can switch to one of these modes in MacOS before booting (Penguin-16 will still complain about this - click "Skip" to continue anyway), and have plenty of pretty colours.

If you're handy with MacsBug, you can also help us add support for colormap changing to the framebuffer...


00001 /*
00002  *    Macintosh interrupts
00003  *
00004  * General design:
00005  * In contrary to the Amiga and Atari platforms, the Mac hardware seems to
00006  * exclusively use the autovector interrupts (the 'generic level0-level7'
00007  * interrupts with exception vectors 0x19-0x1f). The following interrupt levels
00008  * are used:
00009  *    1     - VIA1
00010  *            - slot 0: one second interrupt (CA2)
00011  *            - slot 1: VBlank (CA1)
00012  *            - slot 2: ADB data ready (SR full)
00013  *            - slot 3: ADB data  (CB2)
00014  *            - slot 4: ADB clock (CB1)
00015  *            - slot 5: timer 2
00016  *            - slot 6: timer 1
00017  *            - slot 7: status of IRQ; signals 'any enabled int.'
00018  *
00019  *    2     - VIA2 or RBV
00020  *            - slot 0: SCSI DRQ (CA2)
00021  *            - slot 1: NUBUS IRQ (CA1) need to read port A to find which
00022  *            - slot 2: /EXP IRQ (only on IIci)
00023  *            - slot 3: SCSI IRQ (CB2)
00024  *            - slot 4: ASC IRQ (CB1)
00025  *            - slot 5: timer 2 (not on IIci)
00026  *            - slot 6: timer 1 (not on IIci)
00027  *            - slot 7: status of IRQ; signals 'any enabled int.'
00028  *
00029  *    2     - OSS (IIfx only?)
00030  *            - slot 0: SCSI interrupt
00031  *            - slot 1: Sound interrupt
00032  *
00033  * Levels 3-6 vary by machine type. For VIA or RBV Macintoshes:
00034  *
00035  *    3     - unused (?)
00036  *
00037  *    4     - SCC (slot number determined by reading RR3 on the SSC itself)
00038  *            - slot 1: SCC channel A
00039  *            - slot 2: SCC channel B
00040  *
00041  *    5     - unused (?)
00042  *            [serial errors or special conditions seem to raise level 6
00043  *            interrupts on some models (LC4xx?)]
00044  *
00045  *    6     - off switch (?)
00046  *
00047  * For OSS Macintoshes (IIfx only at this point):
00048  *
00049  *    3     - Nubus interrupt
00050  *            - slot 0: Slot $9
00051  *            - slot 1: Slot $A
00052  *            - slot 2: Slot $B
00053  *            - slot 3: Slot $C
00054  *            - slot 4: Slot $D
00055  *            - slot 5: Slot $E
00056  *
00057  *    4     - SCC IOP
00058  *            - slot 1: SCC channel A
00059  *            - slot 2: SCC channel B
00060  *
00061  *    5     - ISM IOP (ADB?)
00062  *
00063  *    6     - unused
00064  *
00065  * For PSC Macintoshes (660AV, 840AV):
00066  *
00067  *    3     - PSC level 3
00068  *            - slot 0: MACE
00069  *
00070  *    4     - PSC level 4
00071  *            - slot 1: SCC channel A interrupt
00072  *            - slot 2: SCC channel B interrupt
00073  *            - slot 3: MACE DMA
00074  *
00075  *    5     - PSC level 5
00076  *
00077  *    6     - PSC level 6
00078  *
00079  * Finally we have good 'ole level 7, the non-maskable interrupt:
00080  *
00081  *    7     - NMI (programmer's switch on the back of some Macs)
00082  *            Also RAM parity error on models which support it (IIc, IIfx?)
00083  *
00084  * The current interrupt logic looks something like this:
00085  *
00086  * - We install dispatchers for the autovector interrupts (1-7). These
00087  *   dispatchers are responsible for querying the hardware (the
00088  *   VIA/RBV/OSS/PSC chips) to determine the actual interrupt source. Using
00089  *   this information a machspec interrupt number is generated by placing the
00090  *   index of the interrupt hardware into the low three bits and the original
00091  *   autovector interrupt number in the upper 5 bits. The handlers for the
00092  *   resulting machspec interrupt are then called.
00093  *
00094  * - Nubus is a special case because its interrupts are hidden behind two
00095  *   layers of hardware. Nubus interrupts come in as index 1 on VIA #2,
00096  *   which translates to IRQ number 17. In this spot we install _another_
00097  *   dispatcher. This dispatcher finds the interrupting slot number (9-F) and
00098  *   then forms a new machspec interrupt number as above with the slot number
00099  *   minus 9 in the low three bits and the pseudo-level 7 in the upper five
00100  *   bits.  The handlers for this new machspec interrupt number are then
00101  *   called. This puts Nubus interrupts into the range 56-62.
00102  *
00103  * - The Baboon interrupts (used on some PowerBooks) are an even more special
00104  *   case. They're hidden behind the Nubus slot $C interrupt thus adding a
00105  *   third layer of indirection. Why oh why did the Apple engineers do that?
00106  *
00107  * - We support "fast" and "slow" handlers, just like the Amiga port. The
00108  *   fast handlers are called first and with all interrupts disabled. They
00109  *   are expected to execute quickly (hence the name). The slow handlers are
00110  *   called last with interrupts enabled and the interrupt level restored.
00111  *   They must therefore be reentrant.
00112  *
00113  *   TODO:
00114  *
00115  */
00117 #include <linux/module.h>
00118 #include <linux/types.h>
00119 #include <linux/kernel.h>
00120 #include <linux/sched.h>
00121 #include <linux/kernel_stat.h>
00122 #include <linux/interrupt.h> /* for intr_count */
00123 #include <linux/delay.h>
00124 #include <linux/seq_file.h>
00126 #include <asm/system.h>
00127 #include <asm/irq.h>
00128 #include <asm/traps.h>
00129 #include <asm/bootinfo.h>
00130 #include <asm/machw.h>
00131 #include <asm/macintosh.h>
00132 #include <asm/mac_via.h>
00133 #include <asm/mac_psc.h>
00134 #include <asm/hwtest.h>
00135 #include <asm/errno.h>
00136 #include <asm/macints.h>
00137 #include <asm/irq_regs.h>
00139 #define DEBUG_SPURIOUS
00140 #define SHUTUP_SONIC
00142 /* SCC interrupt mask */
00144 static int scc_mask;
00146 /*
00147  * VIA/RBV hooks
00148  */
00150 extern void via_init(void);
00151 extern void via_register_interrupts(void);
00152 extern void via_irq_enable(int);
00153 extern void via_irq_disable(int);
00154 extern void via_irq_clear(int);
00155 extern int  via_irq_pending(int);
00157 /*
00158  * OSS hooks
00159  */
00161 extern int oss_present;
00163 extern void oss_init(void);
00164 extern void oss_register_interrupts(void);
00165 extern void oss_irq_enable(int);
00166 extern void oss_irq_disable(int);
00167 extern void oss_irq_clear(int);
00168 extern int  oss_irq_pending(int);
00170 /*
00171  * PSC hooks
00172  */
00174 extern int psc_present;
00176 extern void psc_init(void);
00177 extern void psc_register_interrupts(void);
00178 extern void psc_irq_enable(int);
00179 extern void psc_irq_disable(int);
00180 extern void psc_irq_clear(int);
00181 extern int  psc_irq_pending(int);
00183 /*
00184  * IOP hooks
00185  */
00187 extern void iop_register_interrupts(void);
00189 /*
00190  * Baboon hooks
00191  */
00193 extern int baboon_present;
00195 extern void baboon_init(void);
00196 extern void baboon_register_interrupts(void);
00197 extern void baboon_irq_enable(int);
00198 extern void baboon_irq_disable(int);
00199 extern void baboon_irq_clear(int);
00200 extern int  baboon_irq_pending(int);
00202 /*
00203  * SCC interrupt routines
00204  */
00206 static void scc_irq_enable(unsigned int);
00207 static void scc_irq_disable(unsigned int);
00209 /*
00210  * console_loglevel determines NMI handler function
00211  */
00213 irqreturn_t mac_nmi_handler(int, void *);
00214 irqreturn_t mac_debug_handler(int, void *);
00216 /* #define DEBUG_MACINTS */
00218 static void mac_enable_irq(unsigned int irq);
00219 static void mac_disable_irq(unsigned int irq);
00221 static struct irq_controller mac_irq_controller = {
00222       .name       = "mac",
00223       .lock       = __SPIN_LOCK_UNLOCKED(mac_irq_controller.lock),
00224       .enable           = mac_enable_irq,
00225       .disable    = mac_disable_irq,
00226 };
00228 void __init mac_init_IRQ(void)
00229 {
00230 #ifdef DEBUG_MACINTS
00231       printk("mac_init_IRQ(): Setting things up...\n");
00232 #endif
00233       scc_mask = 0;
00235       m68k_setup_irq_controller(&mac_irq_controller, IRQ_USER,
00236                           NUM_MAC_SOURCES - IRQ_USER);
00237       /* Make sure the SONIC interrupt is cleared or things get ugly */
00238 #ifdef SHUTUP_SONIC
00239       printk("Killing onboard sonic... ");
00240       /* This address should hopefully be mapped already */
00241       if (hwreg_present((void*)(0x50f0a000))) {
00242             *(long *)(0x50f0a014) = 0x7fffL;
00243             *(long *)(0x50f0a010) = 0L;
00244       }
00245       printk("Done.\n");
00246 #endif /* SHUTUP_SONIC */
00248       /*
00249        * Now register the handlers for the master IRQ handlers
00250        * at levels 1-7. Most of the work is done elsewhere.
00251        */
00253       if (oss_present)
00254             oss_register_interrupts();
00255       else
00256             via_register_interrupts();
00257       if (psc_present)
00258             psc_register_interrupts();
00259       if (baboon_present)
00260             baboon_register_interrupts();
00261       iop_register_interrupts();
00262       request_irq(IRQ_AUTO_7, mac_nmi_handler, 0, "NMI",
00263                   mac_nmi_handler);
00264 #ifdef DEBUG_MACINTS
00265       printk("mac_init_IRQ(): Done!\n");
00266 #endif
00267 }
00269 /*
00270  *  mac_enable_irq - enable an interrupt source
00271  * mac_disable_irq - disable an interrupt source
00272  *   mac_clear_irq - clears a pending interrupt
00273  * mac_pending_irq - Returns the pending status of an IRQ (nonzero = pending)
00274  *
00275  * These routines are just dispatchers to the VIA/OSS/PSC routines.
00276  */
00278 static void mac_enable_irq(unsigned int irq)
00279 {
00280       int irq_src = IRQ_SRC(irq);
00282       switch(irq_src) {
00283       case 1:
00284             via_irq_enable(irq);
00285             break;
00286       case 2:
00287       case 7:
00288             if (oss_present)
00289                   oss_irq_enable(irq);
00290             else
00291                   via_irq_enable(irq);
00292             break;
00293       case 3:
00294       case 4:
00295       case 5:
00296       case 6:
00297             if (psc_present)
00298                   psc_irq_enable(irq);
00299             else if (oss_present)
00300                   oss_irq_enable(irq);
00301             else if (irq_src == 4)
00302                   scc_irq_enable(irq);
00303             break;
00304       case 8:
00305             if (baboon_present)
00306                   baboon_irq_enable(irq);
00307             break;
00308       }
00309 }
00311 static void mac_disable_irq(unsigned int irq)
00312 {
00313       int irq_src = IRQ_SRC(irq);
00315       switch(irq_src) {
00316       case 1:
00317             via_irq_disable(irq);
00318             break;
00319       case 2:
00320       case 7:
00321             if (oss_present)
00322                   oss_irq_disable(irq);
00323             else
00324                   via_irq_disable(irq);
00325             break;
00326       case 3:
00327       case 4:
00328       case 5:
00329       case 6:
00330             if (psc_present)
00331                   psc_irq_disable(irq);
00332             else if (oss_present)
00333                   oss_irq_disable(irq);
00334             else if (irq_src == 4)
00335                   scc_irq_disable(irq);
00336             break;
00337       case 8:
00338             if (baboon_present)
00339                   baboon_irq_disable(irq);
00340             break;
00341       }
00342 }
00344 void mac_clear_irq(unsigned int irq)
00345 {
00346       switch(IRQ_SRC(irq)) {
00347       case 1:
00348             via_irq_clear(irq);
00349             break;
00350       case 2:
00351       case 7:
00352             if (oss_present)
00353                   oss_irq_clear(irq);
00354             else
00355                   via_irq_clear(irq);
00356             break;
00357       case 3:
00358       case 4:
00359       case 5:
00360       case 6:
00361             if (psc_present)
00362                   psc_irq_clear(irq);
00363             else if (oss_present)
00364                   oss_irq_clear(irq);
00365             break;
00366       case 8:
00367             if (baboon_present)
00368                   baboon_irq_clear(irq);
00369             break;
00370       }
00371 }
00373 int mac_irq_pending(unsigned int irq)
00374 {
00375       switch(IRQ_SRC(irq)) {
00376       case 1:
00377             return via_irq_pending(irq);
00378       case 2:
00379       case 7:
00380             if (oss_present)
00381                   return oss_irq_pending(irq);
00382             else
00383                   return via_irq_pending(irq);
00384       case 3:
00385       case 4:
00386       case 5:
00387       case 6:
00388             if (psc_present)
00389                   return psc_irq_pending(irq);
00390             else if (oss_present)
00391                   return oss_irq_pending(irq);
00392       }
00393       return 0;
00394 }
00395 EXPORT_SYMBOL(mac_irq_pending);
00397 static int num_debug[8];
00399 irqreturn_t mac_debug_handler(int irq, void *dev_id)
00400 {
00401       if (num_debug[irq] < 10) {
00402             printk("DEBUG: Unexpected IRQ %d\n", irq);
00403             num_debug[irq]++;
00404       }
00405       return IRQ_HANDLED;
00406 }
00408 static int in_nmi;
00409 static volatile int nmi_hold;
00411 irqreturn_t mac_nmi_handler(int irq, void *dev_id)
00412 {
00413       int i;
00414       /*
00415        * generate debug output on NMI switch if 'debug' kernel option given
00416        * (only works with Penguin!)
00417        */
00419       in_nmi++;
00420       for (i=0; i<100; i++)
00421             udelay(1000);
00423       if (in_nmi == 1) {
00424             nmi_hold = 1;
00425             printk("... pausing, press NMI to resume ...");
00426       } else {
00427             printk(" ok!\n");
00428             nmi_hold = 0;
00429       }
00431       barrier();
00433       while (nmi_hold == 1)
00434             udelay(1000);
00436       if (console_loglevel >= 8) {
00437 #if 0
00438             struct pt_regs *fp = get_irq_regs();
00439             show_state();
00440             printk("PC: %08lx\nSR: %04x  SP: %p\n", fp->pc, fp->sr, fp);
00441             printk("d0: %08lx    d1: %08lx    d2: %08lx    d3: %08lx\n",
00442                    fp->d0, fp->d1, fp->d2, fp->d3);
00443             printk("d4: %08lx    d5: %08lx    a0: %08lx    a1: %08lx\n",
00444                    fp->d4, fp->d5, fp->a0, fp->a1);
00446             if (STACK_MAGIC != *(unsigned long *)current->kernel_stack_page)
00447                   printk("Corrupted stack page\n");
00448             printk("Process %s (pid: %d, stackpage=%08lx)\n",
00449                   current->comm, current->pid, current->kernel_stack_page);
00450             if (intr_count == 1)
00451                   dump_stack((struct frame *)fp);
00452 #else
00453             /* printk("NMI "); */
00454 #endif
00455       }
00456       in_nmi--;
00457       return IRQ_HANDLED;
00458 }
00460 /*
00461  * Simple routines for masking and unmasking
00462  * SCC interrupts in cases where this can't be
00463  * done in hardware (only the PSC can do that.)
00464  */
00466 static void scc_irq_enable(unsigned int irq)
00467 {
00468       int irq_idx = IRQ_IDX(irq);
00470       scc_mask |= (1 << irq_idx);
00471 }
00473 static void scc_irq_disable(unsigned int irq)
00474 {
00475       int irq_idx = IRQ_IDX(irq);
00477       scc_mask &= ~(1 << irq_idx);
00478 }
00480 /*
00481  * SCC master interrupt handler. We have to do a bit of magic here
00482  * to figure out what channel gave us the interrupt; putting this
00483  * here is cleaner than hacking it into drivers/char/macserial.c.
00484  */
00486 void mac_scc_dispatch(int irq, void *dev_id)
00487 {
00488       volatile unsigned char *scc = (unsigned char *) mac_bi_data.sccbase + 2;
00489       unsigned char reg;
00490       unsigned long flags;
00492       /* Read RR3 from the chip. Always do this on channel A */
00493       /* This must be an atomic operation so disable irqs.   */
00495       local_irq_save(flags);
00496       *scc = 3;
00497       reg = *scc;
00498       local_irq_restore(flags);
00500       /* Now dispatch. Bits 0-2 are for channel B and */
00501       /* bits 3-5 are for channel A. We can safely    */
00502       /* ignore the remaining bits here.              */
00503       /*                                              */
00504       /* Note that we're ignoring scc_mask for now.   */
00505       /* If we actually mask the ints then we tend to */
00506       /* get hammered by very persistent SCC irqs,    */
00507       /* and since they're autovector interrupts they */
00508       /* pretty much kill the system.                 */
00510       if (reg & 0x38)
00511             m68k_handle_int(IRQ_SCCA);
00512       if (reg & 0x07)
00513             m68k_handle_int(IRQ_SCCB);
00514 }

mac_SCC.c: has been found in 2.2.24

 * mac_SCC.c: m68k version of
 * macserial.c: Serial port driver for Power Macintoshes.
 *              Extended for the 68K mac by Alan Cox.
 *              Rewritten to m68k serial design by Michael Schmitz
 * Derived from drivers/sbus/char/sunserial.c by Paul Mackerras.
 * Copyright (C) 1996 Paul Mackerras (Paul.Mackerras@cs.anu.edu.au)
 * Copyright (C) 1995 David S. Miller (davem@caip.rutgers.edu)

 * Design note for the m68k rewrite:
 * The structure of the m68k serial code requires separation of the low-level
 * functions that talk directly to the hardware from the Linux serial driver
 * code interfacing to the tty layer. The reason for this separation is simply
 * the fact that the m68k serial hardware is, unlike the i386, based on a
 * variety of chips, and the rs_* serial routines need to be shared.
 * I've tried to make consistent use of the async_struct info populated in the
 * midlevel code, and introduced an async_private struct to hold the Macintosh
 * SCC internals (this was added to the async_struct for the PowerMac driver).
 * Exception: the console and kgdb hooks still use the zs_soft[] data, and this
 * is still filled in by the probe_sccs() routine, which provides some data
 * for mac_SCC_init as well. Interrupts are registered in mac_SCC_init, so
 * the console/kgdb stuff probably won't work before proper serial init, and
 * I have to rely on keeping info and zs_soft consistent at least for the
 * console/kgdb port.
 * Update (16-11-97): The SCC interrupt handling was suffering from the problem
 * that the autovector SCC interrupt was registered only once, hence only one
 * async_struct was passed to the interrupt function and only interrupts from
 * the corresponding channel could be handled (yes, major design flaw).
 * The autovector interrupt is now registered by the main interrupt initfunc,
 * and uses a handler that will call the registered SCC specific interrupts in
* the fact that the m68k serial hardware is, unlike the i386, based on a
 * variety of chips, and the rs_* serial routines need to be shared.
 * I've tried to make consistent use of the async_struct info populated in the
 * midlevel code, and introduced an async_private struct to hold the Macintosh
 * SCC internals (this was added to the async_struct for the PowerMac driver).
 * Exception: the console and kgdb hooks still use the zs_soft[] data, and this
 * is still filled in by the probe_sccs() routine, which provides some data
 * for mac_SCC_init as well. Interrupts are registered in mac_SCC_init, so
 * the console/kgdb stuff probably won't work before proper serial init, and
 * I have to rely on keeping info and zs_soft consistent at least for the
 * console/kgdb port.
 * Update (16-11-97): The SCC interrupt handling was suffering from the problem
 * that the autovector SCC interrupt was registered only once, hence only one
 * async_struct was passed to the interrupt function and only interrupts from
 * the corresponding channel could be handled (yes, major design flaw).
 * The autovector interrupt is now registered by the main interrupt initfunc,
 * and uses a handler that will call the registered SCC specific interrupts in
 * turn. The SCC init has to register these as machspec interrupts now, as is
 * done for the VIA interrupts elsewhere.

write kernel module




write kernel serial module



	I am writing a serial driver, and so I started investigating the
tiny_serial driver from the third edition of "Linux Device Drivers."
Original source is at the bottom of the email.  When I exercise this
module using stty, EIO is returned.  This also happens for reads and
writes.  I am running 2.6.22 PREEMPT on Powerpc.  Any help would be
greatly appreciated.

~ $ mknod /dev/ttty1 c 240 1
~ $ insmod tiny_serial.ko
~ $ stty -a -F /dev/ttty1
stty: /dev/ttty1: Input/output error
~ $ strace  stty -a -F /dev/ttty1
execve("/bin/stty", ["stty", "-a", "-F", "/dev/ttty1"], [/* 7 vars */])
= 0
uname({sys="Linux", node="", ...}) = 0
brk(0)                                  = 0x1018a000
= 0x30018000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
open("/etc/ld.so.cache", O_RDONLY)      = -1 ENOENT (No such file or
open("/lib/tls/ppc603/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/lib/tls/ppc603", 0x7ffff1e0)   = -1 ENOENT (No such file or
open("/lib/tls/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or
stat64("/lib/tls", 0x7ffff1e0)          = -1 ENOENT (No such file or
open("/lib/ppc603/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or
stat64("/lib/ppc603", 0x7ffff1e0)       = -1 ENOENT (No such file or
open("/lib/libcrypt.so.1", O_RDONLY)    = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\f"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=31414, ...}) = 0
3, 0) = 0xffb4000
mprotect(0xffb9000, 225036, PROT_NONE)  = 0
mmap(0xffc8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
mmap(0xffc9000, 159500, PROT_READ|PROT_WRITE|PROT_EXEC,
close(3)                                = 0
open("/lib/libm.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\242"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=566328, ...}) = 0
3, 0) = 0xff1b000
mprotect(0xff91000, 75836, PROT_NONE)   = 0
mmap(0xffa1000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x76000) = 0xffa1000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\316"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1531392, ...}) = 0
3, 0) = 0xfdc6000
mprotect(0xfeef000, 112652, PROT_NONE)  = 0
mmap(0xfefe000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x128000) = 0xfefe000
mmap(0xff08000, 10252, PROT_READ|PROT_WRITE|PROT_EXEC,
close(3)                                = 0
= 0x30019000
stat64("/etc/busybox.conf", 0x7ffffb30) = -1 ENOENT (No such file or
getuid()                                = 0
getgid()                                = 0
setgid(0)                               = 0
setuid(0)                               = 0
close(0)                                = 0
open("/dev/ttty1", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
fcntl64(0, F_GETFL)                     = 0x800 (flags
fcntl64(0, F_SETFL, O_RDONLY)           = 0
ioctl(0, TCGETS, 0x7ffff8e0)            = -1 EIO (Input/output error)
write(2, "stty: ", 6stty: )                   = 6
write(2, "/dev/ttty1", 10/dev/ttty1)              = 10
write(2, ": Input/output error\n", 21: Input/output error
)  = 21
exit_group(1)                           = ?
Process 213 detached

Full source below, apologies for mailer whitespace-damage

 * Tiny Serial driver
 * Copyright (C) 2002-2004 Greg Kroah-Hartman (greg@xxxxxxxxx)
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, version 2 of the License.
 * This driver shows how to create a minimal serial driver.  It does not
rely on
 * any backing hardware, but creates a timer that emulates data being
 * from some kind of hardware.

#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
#include <linux/serial.h>
#include <linux/serial_core.h>
#include <linux/module.h>

#define DRIVER_AUTHOR "Greg Kroah-Hartman <greg@xxxxxxxxx>"
#define DRIVER_DESC "Tiny serial driver"

/* Module information */

#define DELAY_TIME  HZ * 2 /* 2 seconds per character */

#define TINY_SERIAL_MAJOR 240 /* experimental range */
#define TINY_SERIAL_MINORS 1  /* only have one minor */
#define UART_NR   1 /* only use one port */

#define TINY_SERIAL_NAME "ttytiny"


static struct timer_list *timer;

static void tiny_stop_tx(struct uart_port *port, unsigned int tty_stop)

static void tiny_stop_rx(struct uart_port *port)

static void tiny_enable_ms(struct uart_port *port)

static void tiny_tx_chars(struct uart_port *port)
 struct circ_buf *xmit = &port->info->xmit;
 int count;

 if (port->x_char) {
  pr_debug("wrote %2x", port->x_char);
  port->x_char = 0;
 if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
  tiny_stop_tx(port, 0);

 count = port->fifosize >> 1;
 do {
  pr_debug("wrote %2x", xmit->buf[xmit->tail]);
  xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
  if (uart_circ_empty(xmit))
 } while (--count > 0);

 if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)

 if (uart_circ_empty(xmit))
  tiny_stop_tx(port, 0);

static void tiny_start_tx(struct uart_port *port, unsigned int

static void tiny_timer(unsigned long data)
 struct uart_port *port;
 struct tty_struct *tty;

 port = (struct uart_port *)data;
 if (!port)
 if (!port->info)
 tty = port->info->tty;
 if (!tty)

 /* add one character to the tty port */
 /* this doesn't actually push the data through unless tty->low_latency
is set /
 tty_insert_flip_char(tty, TINY_DATA_CHARACTER, 0);


 /* resubmit the timer again */
 timer->expires = jiffies + DELAY_TIME;

 /* see if we have any data to transmit */

static unsigned int tiny_tx_empty(struct uart_port *port)
 return 0;

static unsigned int tiny_get_mctrl(struct uart_port *port)
 return 0;

static void tiny_set_mctrl(struct uart_port *port, unsigned int mctrl)

static void tiny_break_ctl(struct uart_port *port, int break_state)

static void tiny_set_termios(struct uart_port *port,
         struct termios *new, struct termios *old)
 int baud, quot, cflag = new->c_cflag;
 /* get the byte size */
 switch (cflag & CSIZE) {
 case CS5:
  printk(KERN_DEBUG " - data bits = 5\n");
 case CS6:
  printk(KERN_DEBUG " - data bits = 6\n");
 case CS7:
  printk(KERN_DEBUG " - data bits = 7\n");
 default: // CS8
  printk(KERN_DEBUG " - data bits = 8\n");

 /* determine the parity */
 if (cflag & PARENB)
  if (cflag & PARODD)
    pr_debug(" - parity = odd\n");
    pr_debug(" - parity = even\n");
  pr_debug(" - parity = none\n");

 /* figure out the stop bits requested */
 if (cflag & CSTOPB)
  pr_debug(" - stop bits = 2\n");
  pr_debug(" - stop bits = 1\n");

 /* figure out the flow control settings */
 if (cflag & CRTSCTS)
  pr_debug(" - RTS/CTS is enabled\n");
  pr_debug(" - RTS/CTS is disabled\n");

 /* Set baud rate */
        baud = uart_get_baud_rate(port, new, old, 0, port->uartclk/16);
        quot = uart_get_divisor(port, baud);

 //UART_PUT_DIV_LO(port, (quot & 0xff));
 //UART_PUT_DIV_HI(port, ((quot & 0xf00) >> 8));

static int tiny_startup(struct uart_port *port)
 /* this is the first time this port is opened */
 /* do any hardware initialization needed here */

 /* create our timer and submit it */
 if (!timer) {
  timer = kmalloc(sizeof(*timer), GFP_KERNEL);
  if (!timer)
    return -ENOMEM;
 timer->data = (unsigned long)port;
 timer->expires = jiffies + DELAY_TIME;
 timer->function = tiny_timer;
 return 0;

static void tiny_shutdown(struct uart_port *port)
 /* The port is being closed by the last user. */
 /* Do any hardware specific stuff here */

 /* shut down our timer */

static const char *tiny_type(struct uart_port *port)
 return "tinytty";

static void tiny_release_port(struct uart_port *port)


static int tiny_request_port(struct uart_port *port)
 return 0;

static void tiny_config_port(struct uart_port *port, int flags)

static int tiny_verify_port(struct uart_port *port, struct serial_struct
 return 0;

static struct uart_ops tiny_ops = {
 .tx_empty  = tiny_tx_empty,
 .set_mctrl = tiny_set_mctrl,
 .get_mctrl = tiny_get_mctrl,
 .stop_tx   = tiny_stop_tx,
 .start_tx  = tiny_start_tx,
 .stop_rx   = tiny_stop_rx,
 .enable_ms = tiny_enable_ms,
 .break_ctl = tiny_break_ctl,
 .startup   = tiny_startup,
 .shutdown  = tiny_shutdown,
 .set_termios = tiny_set_termios,
 .type  = tiny_type,
 .release_port = tiny_release_port,
 .request_port = tiny_request_port,
 .config_port = tiny_config_port,
 .verify_port = tiny_verify_port,

static struct uart_port tiny_port = {
 .ops  = &tiny_ops,

static struct uart_driver tiny_reg = {
 .owner     = THIS_MODULE,
 .driver_name = TINY_SERIAL_NAME,
 .dev_name  = TINY_SERIAL_NAME,
 .major     = TINY_SERIAL_MAJOR,
 .minor     = TINY_SERIAL_MINORS,
 .nr  = UART_NR,

static int __init tiny_init(void)
 int result;

 printk(KERN_INFO "Tiny serial driver loaded\n");

 result = uart_register_driver(&tiny_reg);
 if (result)
  return result;

 result = uart_add_one_port(&tiny_reg, &tiny_port);
 if (result)

 return result;



Several ethernet cards based on the National Semiconductor 8390 chip (also used in many ISA ethernet cards, the NE2000 being the most well known example) are working. These include Apple cards and several clones including Daynaport, Asante, and Farallon. Not all clones are known to work "as-advertised" and adding a new driver to this list may be easy, but might also involve some clone specific bugs that will make problems rather difficult to track down. Also, the Asante MacCon CS card for the "comm-slot" on the 575, 580, and 630 models is supported, and the driver will probably be adaptable to support other cards based on the SMC91C94 and SMC91C92 chipsets.

On-board SONIC ethernet, found on most of the Quadras, is also supported, as are SONIC-based comm-slot cards. However, we haven't yet devised a reasonable scheme for autoprobing for the existence of the SONIC. On-board MACE ethernet, found on the 660AV and 840AV, also works in the 2.2.18 and later kernels.

LC PDS cards based on the 8390 chipset generally work, as does Apple's SONIC-based LC ethernet card. 5. SCSI?

As of right now, SCSI is working on nearly all machines and you can mount and play with your Mac harddrives from within Linux. If you want to set up an ext2 partition, you'll need to use the installer. (See below.)


I think that there are far better things to worry about than sound support. :) The sound chip isn't well documented and might be a pain to implement correctly. (Is there already a working driver for this?) Some (older) kernels will make a LOUD noise for debugging when you start them. Do not interpret this noise as working sound... consider it more along the lines of a debugging message that hurts.

Floppy drives

There are two main kinds of floppy controllers on the Macintosh models that we're working with: the IWM and the SWIM. A driver for most models was contributed by Laurent Vivier and merged into the linux-2_2 CVS branch.

Other devices

It depends on the device. If you want something bad enough, you could always write a driver for it. :) In general, if it is already supported by a particular Linux port, you won't have as much trouble getting it working as you would developing a driver from scratch. The Valkyrie framebuffer, SMC9194 Ethernet, and CUDA ADB drivers are examples of this, and reading them might be instructive in the sort of things you have to deal with when porting to 68k Macintosh.

MMU Cache Inhibit

The CI bit indicates whatever or not the corresponding page is cachable. If CI=1, the CLI (cache load inhibit) bit of the PMMU ks asserted to inform caches that this access should not be cached. Physical IO devices or memory shared by an other microprocessor must not be cached

serial cable

Name (V24) 	 DB25 Pin# 	 DB9 Pin# 	 MiniDIN8 Pin# 	 Direction 	 Full Name 	 Remarks
TxD 	2 	3 	3 	Out 	Transmit Data 	Data
RxD 	3 	2 	5 	In 	Receive Data 	Data
RTS 	4 	7 	6 	Out 	Request To Send 	Handshaking
CTS 	5 	8 	2 	In 	Clear To Send 	Handshaking
DTR 	20 	4 	1 	Out 	Data Terminal Ready 	Status
DSR 	6 	6 	- 	In 	Data Set Ready 	Status
RI 	22 	9 	- 	In 	Ring Indicator 	Status
DCD 	8 	1 	7 	In 	Data Carrier Detect 	Status
GND 	7 	5 	4,8 	- 	Signal ground 	Reference level
- 	1 	- 	- 	- 	Protective ground 	Don't use this one as signal ground! 

  How to connect the connectors
Null-modem Cable

This cable will allow you to hook the MiniDIN8 port directly up to a standard RS-232 port on another computer.
From 	MiniDin8 Pin 	--> 	To 	DB9 Pin 	DB25 Pin
DTR 	Data Terminal Ready 	Pin 1 	--> 	DSR 	Data Set Ready 	Pin 6 	Pin 6
CTS 	Clear To Send 	Pin 2 	--> 	RTS 	Request To Send 	Pin 7 	Pin 4
TD 	Transmit Data 	Pin 3 	--> 	RD 	Receive Data 	Pin 2 	Pin 3
SG 	Signal Ground 	Pins 4 & 8 	--> 	SG 	Signal Ground 	Pin 5 	Pin 7
RD 	Receive Data 	Pin 5 	--> 	TD 	Transmit Data 	Pin 3 	Pin 2
RTS 	Request To Send 	Pin 6 	--> 	CTS 	Clear To Send 	Pin 8 	Pin 5
DCD 	Data Carrier Detect 	Pin 7 	--> 	DTR 	Data Terminal Ready 	Pin 4 	Pin 20
Shield 	--> 	- 	Protective Ground 	- 	Pin 1

It it might be needed to have a connection between pin 20 and pin 8 on the Sub-D 25 connector to have your terminal do a carrier detect. SGI is using the same pin-pout for it's 8-pin mini-DIN connectors as Apple for it's machines. Therefor cables and adapters suitable for use with Apple system may be used.
Straight-Thru Cable

This cable will allow you to hook the MiniDIN8 port into an RS-232 device such as a modem.
From 	MiniDin8 Pin 	--> 	To 	DB9 Pin 	DB25 Pin
DTR 	Data Terminal Ready 	Pin 1 	--> 	DTR 	Data Terminal Ready 	Pin 4 	Pin 20
CTS 	Clear To Send 	Pin 2 	--> 	CTS 	Clear To Send 	Pin 8 	Pin 5
TD 	Transmit Data 	Pin 3 	--> 	TD 	Transmit Data 	Pin 3 	Pin 2
SG 	Signal Ground 	Pins 4 & 8 	--> 	SG 	Signal Ground 	Pin 5 	Pin 7
RD 	Receive Data 	Pin 5 	--> 	RD 	Receive Data 	Pin 2 	Pin 3
RTS 	Request To Send 	Pin 6 	--> 	RTS 	Request To Send 	Pin 7 	Pin 4
DCD 	Data Carrier Detect 	Pin 7 	--> 	DCD 	Data Carrier Detect 	Pin 1 	Pin 8
Shield 	--> 	- 	Protective Ground 	- 	Pin 1 


CPU m68k Hacks

You can get a 68010 for your 68000-based Mac; the '010 is pin-compatible with the 68000 and should drop right in. You CANNOT put a 68060 into a 68040-based Macintosh; the '060 is not entirely compatible with the Mac ROMs or the '040 instruction set and would require a major rewrite of a good deal of software in order to work properly. The '020 and '030 are NOT pin-compatible.

The 68882 FPU is pin-compatible with the 68881 and should be used instead where possible. Socketed 68882s are most often found on dead SE/30 and IIfx motherboards and on Daystar Digital PowerCache cards. The 68LC040, which shipped in most Performa and LC Macs with an '040 CPU, can be replaced with a full '040 without the LC designation, thus adding an FPU to the previously FPU-less Mac. A good source of these is a dead Quadra or Centris motherboard

About the board

I'm equipped with an LC475, mc68040-25Mhz, 32+4Mb ram, netboard, and SCSI hard drive

the LC475

the outside


the inside



The board

The board consists of:

  • CPU motorola mc68040@25Mhz,
  • RAM 32MB fast page 5nsec page seek + 4 Mb soldered onboard memory chip
  • LAN ??? 10 Mbit/s Fast Ethernet port supporting Auto-MDI/X
  • UART Z85c30 chip handling 2 minidin RS232C asynchronous serial port, speeds up to 230k, tested up to 115200bps
  • nuBUS one apple NuBUS populated with the ethernet card
  • SCSI support for SCSI-I harddrive (/dev/sda)
  • ROM 1Mbyte where it is stored the apple firmware
  • POWER Max 30 Watts, 0.25 Amps + RTC 3.6V lithium Battery Type
  • System PCB 12.2 cm x 15.6 cm
  • RTC the real time clock chip is missing
  • LED Power
  • Watchdog hardware watchdog timer ???

The Apple Macintosh LC 475 features a 25 MHz 68LC040 processor, 4 MB or 8 MB of RAM, and either an 80 MB, a 160 MB, or a 250 MB hard drive in a compact "pizza box" case. The consumer version of the LC 475 is the Performa 475 series, and the business version is the Quadra 605.

* Introduction Date: October 21, 1993   	 
* Discontinued Date: May 1, 1994
* Processor Type: 68LC040
* Processor Speed: 25 MHz
* System Bus Speed: 	25 MHz 	Lookaside Bus Speed: 	N/A
* ROM Size: 	1 MB 	
* Data Path: 	32-bit
* Level 1 Cache: 	8k 	Level 2 Cache: 	N/A
* RAM Type: 	80 ns 72-pin SIMM
* VRAM Type: 	80 ns VRAM SIMM
* Standard RAM: 	4 MB 	
* Maximum RAM: 	36 MB
* Motherboard RAM: 	4 MB 	
* RAM Slots: 	1
* Standard VRAM: 	512k 
* Maximum VRAM: 	1 MB
* Standard Hard Drive: 250 MB 	Int SCSI
* Standard CD-ROM: 	N/A 	
* Standard Disk: 	1.44 MB (manual)
* Standard Modem: 	N/A 	
* Standard Ethernet: 	N/A
* Case Type: 	Desktop 	
* Form Factor: Macintosh LC
* Exp. Slots: 	LC III PDS Exp. Bays (Free): 	None
* Battery Type: 3.6V Lithium 	Battery Life: 	N/A
* Built-in Display: 	N/A 
* Supported MacOS: 7.1-7.5.1, 7.5.3-8.1
* Dimensions: 	2.9 x 12.2 x 15.3 4. 
* Avg. Weight: 8.8 lbs.



uart zilog chip http://www.zilog.com/docs/serial/scc_escc_um.pdf

R422 line driver http://www.national.com/ds/DS/DS1691A.pdf

LC475 Hacks

mobo Hack to switch the m680LC40@25Mhz to a m68040@33Mhz


mobo Hack open questions

PLL=mc88920 @ 25Mhz syncing in 2.5nsec

what is the difference with MC88916DW70

--> MC88920 is rated at 50MHz (2x25MHz bus

--> MC88916DW70 is rated at 70MHz (2x35MHz bus)

--> MC88916DW80 is rated at 80MHz (2x40MHz bus)

{R301=300,R471=4.7K} ohm

question: are they connected to the PLL ?

to do: draw the PLL schematic

what exactly U17 is ? Gazelle clock generator chip, Apple p/n 343S1135 -a



R22A->U17{9} R22B->U17{5,12,16}

R21A->U17{1,4,7} R21B->U17{9}

R25B->U17{13} R25A->U17{2,12,16}

R24A->Vcc->88920{2,5,17} R24B->U17{13}


 1=/CS        20=GND         
 2=Vcc        19=2X_Q
 3=/MR        18=Q/2
 4=/RST_IN    17=VCC
 5=Vcc        16=Q2
 6=RC1        15=GND
 7=GND        14=/RST_OUT
 8=SYNC       13=PLL_EN
 9=GND        12=Q1
10=Q0         11=VCC





G2.1= G2.3=

mobo Hack to Speedup to 40MHz w/o external oscillator (experimental)

LC475: This is a modification that can be performed on a LC475 to speed it up to 33MHz.

Unlike the modifications outlined in the Mac Crystal Oscillator Speedup History File I maintain where those computers use a TTL crystal oscillator to clock the processor, the Quadra 605 uses a Clock Generator. This clock generator, Apple p/n 343S1135 -a N, is located at position U17 on the motherboard. On at least one LC475, the clock generator is Apple p/n 343S0161 -a. Depending on the surface mount resistors used, Pin 6 of this part will either put out a signal for 20, 25, 33, or 40MHz operation. There are four resistor pads used in this modification. Surface mount (SMT) resistors are placed in these pads to pull "low" or "high". The pads are on the bottom of the motherboard, and are in sets of two, so you need to have a resistor on one of the first two and one of the second two. The resistors are either 300 Ohms (301) or 4.7k Ohms (472). They are the "0805" surface mount package.

Resistor Pads

R22 (low) 	R21 (high) 	R25 (low) 	R24 (high) 	Pull            Speed
301             _               301 	        _               low, low 	20MHz
_               472 	        301 	        _               high, low 	25MHz
301             _               _               472             low, high 	33MHz
_               472             _               472             high, high 	40MHz

If you monitor Pin 6 of U17, you will get the following:

Pull 	        Pin 6           Speed
low, low 	9.982MHz 	19.964MHz
high, low 	12.377MHz 	24.754MHz
low, high 	16.425MHz 	32.85MHz
high, high 	19.964MHz 	39.928MHz

LC475: If the jumper J18 is not, it is a LC475. The system and other software know this from what is called a gestalt. The gestalt is a number that is specific to each type of Mac Apple makes. A Quadra 605 is gestalt 94 while a LC475 is gestalt 89.

There are several unassigned gestalts, and this modification will explain a few of them:

New Gestalts

Speed 	J18 Installed 	J18 Removed
20MHz 	           93 	         86
25MHz 	           94 	         89
33MHz 	           95 	         90

It makes no difference if the jumper is installed or not.

Prior to performing this modification you will need to update to system 7.5, or replace your system enabler with System Enabler 065, version 1.2.

I take it few of you will really want to drop down from 25MHz to 20MHz. At 40MHz, the Mac is unable to lock onto the frequency, and will not work. If you must try it to see it for yourself, you will need a 4.7k Ohm resistor. If you send a self addressed stamped envelope (SASE) to Output Enablers (oe@well.com) at 1678 Shattuck, Suite #247, Berkeley, CA 94709, they will send you one of these SMT resistors.

So for the rest of you who want to go from 25 to 33MHz, a 32% speedup, you just need to swap some resistors. The resistors have been glued onto the board prior to soldering, so you need to heat both sides of the SMT resistor at the same time with two soldering irons, and lift the resistor off with the irons. This will break the glue's bond to the SMT resistor. To solder on the resistor, place it on the pads (it does not matter which way it faces), hold it there with a small screw driver, and solder one side to the board at a time.

The modification:

1: remove the SMT resistor from R21, and solder it onto R24

2: remove the SMT resistor from R25, and solder it onto R22

That's it. Keep in mind however that the 25MHz 68LC040 will now be running at 33MHz. The part is not rated to run at these speeds, but my experience with other Mac's and two Quadra 605's shows that this will not be a problem. If you need the math coprocessor you may also want to replace the 68LC040 with a full 68040. I have done this, and it works fine. You may also want to place a heat sink on the 68040. You have about 0.7", so any of those heatsinks will do, but if you mount a fan on it, get the 0.250" one. There are some Speedometer 4.0 Files for a Q605 at 20, 25, and 33MHz on the Clock Chipping Home Page you may want to check out.

At 20, 25 and 33MHz I have checked the serial ports, video, floppy drive, SCSI drives, and RAM, and have observed no problems.

Just a small unrelated note... The battery in the LC475 typically lasts just 2-3 years, and since the LC475 have now been out about that amount of time there have several cases where the battery goes dead. The symptom is that the date does not hold, and the video dies. If you run into this independent of having clock chipped your machine, get a new 3.6 volt lithium battery. The battery is used to store the settings in the PRAM.

At the normal 25MHz, you can use both 640x480@67Hz and 832x624@75Hz on a 15" multiscan monitor, and 640x480@67Hz, 832x624@75Hz, 1024x768@75Hz, and 1152x870@75Hz on a 20" multiscan monitor without any problems. When you accelerate your machine by the above modification you will still be fine at 33MHz. The current clip-on modifications however for the 605/475's only allow you to use 640x480@67Hz.

mobo Hack to Speedup (experimental2)

  1. original setting
     R22=open, R21=472, R25=301, R24=open

I tried the LC475 40MHz Speedup by just swapping the resistors as outlined in the Q605 (LC475, P475, P476) Speedup (33MHz), but failed. Fortunately during the experiments, I found a successful 40MHz LC475 speedup.

Here it is:

  1. R22, R21, R25, R24 are set to the 33MHz-configurations 
     (see the previous mobo Hack to Speedup to 40MHz ...).
     ie. R22=301, R21=Open, R25=Open, R24=472
  2. Detach pin #9 of U17 (Gazelle clock generator chip, Apple p/n 343S1135 -a)
  3. Pulled up pin #9 of U17 with a 4.7k Ohm resistor to Vcc (5 volts).

Remove J18; this modification may only work in "LC475 mode"; LC475 owners can ignore this as LC475's were shipped without J18. And it looks like this might only work if you have a 68040RC25 or faster processor, so you will need to replace your 68LC040RC25 processor if you have not already done so. If you have any problems you will want to replace the PLL (MC88920) with a faster one. The MC88920 is rated at 50MHz (25MHz bus). The MC88916DW70 is rated at 70MHz (35MHz bus), and the MC88916DW80 is rated at 80MHz (40MHz bus). The MC88916DW70 is used in many of the other Centris/Quadra level machines.

That's all.

info @ http://www.applefritter.com/node/20510

mobo Hack, improve the system ram


(learn about ram http://wapedia.mobi/it/DRAM#2.)

CONIGLIO PC is available for, 64MB the size of the problem is drew CONIGLIO PC. 128MB SIMM info It would be cool to have 132MB, but up till now I've not had the bottle to order a 128MB SIMM because of only specific types working, and me not being sure which. Bugsi provided me with the info he used when he bought a 128MB SIMM for his LC475. It turns out that Data Memory Systems stock compatible memory - Part number DM36-004 ($65.00) or DM60-015 ($69.00). Either will do. The SIMMs can be double sides, but must be single banked, if you want to buy from elsewhere. I'm tempted to upgrade, but is it worth it? Probably not. Why do it then? Coz you can. :) Even more fun can be had with the info from one of the sites below.



There really isn't a whole lot you can do easily to the motherboard of this machine. There is one PDS expansion slot which can take a network card such as the one in the photo above. There is also one 72 pin simm slot and two vram simm slots which can be upgraded to a pair of 512k simms.

This machine will take one 128 mb 72 pin simm such as the one in the photo below. Beware of chips that are too tall as I have seen chips which had two vertical rows of chips and were about double the height of the one in the photo. These particular chips work just fine in the 475 and allow you to close the lid.

There was a product on the market called the SimmVerter. It came in several styles that allowed you to put multiple strips of ram into a single slot. The is a twin slot 72 pin version which is model number 72x72 and was actually designed to fit over top of a simm in the slot in front of it.

The problem with this device even if it did work is that you cannot install the cover because the chips stick up above the lowest point of the top cover. In defense of this product, it was never designed to be used in this style of Macintosh computer! Oh and I did try installing two 128 mb 72 pin simms into this device. The Mac would not boot up.

There was another version which allowed you to install four 30 pin simms into a single 72 pin slot but with the cost of ram these days I honestly can't see any reason for doing this. But for documentation purposes I included photos of these items below.

The good news is, if you only install the one strip of memory you will have 128 mb plus the 4 mb installed on the motherboard.

The LC Quadra has a limited upgrade path. Apple did ship a PowerPC upgrade card that replaced the 68040 cpu on the motherboard but this was reported to be of little value in terms of increased speed. As with all the LC series pizzaboxes there is a processor direct or PDS slot which can take several items including a network card and that is a handy option if you are setting up a server. On a slightly different note, Asante also made an ethernet adaptor which plugged into the SCSI port and was called the EN/SC. I came in serveral sytles including a very nice small unit that was used on some of the original PowerBooks.

What's that J18 jumper on my LC475/Q605 motherboard?

With the jumper in place, your Mac will register a gestalt ID corresponding with the Q605. Without the jumper, it will register one corresponding with the LC475.

Memory Locations

memory map of the board will be added as soon as possible

addr begin addr end area
... ?? ram, userspace
0x00000 ?? ram, userspace

Open questions

1) how/where is serial mapped ?

2) how/where is scsi ctrl mapped ?

3) how/where is nubus ctrl mapped ?

3) what is the bootstrap addr of the rom ?


Supported Machines

Machine Hack Date kernel support not supported
LC475 cpu replaced with a m68040@25Mhz+MMU+FPU 02-02-2009 2.6.24 is UP, 2.6.26/27/28 is under porting & testing video, adb, kb, net, scsi serial, mouse, floppy

Note: You can ignore the list of supported machines if you checked the list, and it said that your Mac wouldn't work, 'cause, Well, don't let that stop you, remember that most of the information we have is based on user reports. Your mileage may vary. Just because it didn't work for someone else doesn't mean that it won't work for you. I mean you can ignore the list if you can give your machine a shot!

May be supported

Supported models

OpenBSD/mac68k runs on a large part of the 680x0-based Macintosh computers. The kernel itself has support for the following processor combinations:

   * 68020 with 68851 PMMU and 68881 FPU
   * 68030 with 68882 FPU
   * 68040 (not including the 68LC040) 

The following Macintosh models are supported and tested. This means that at least the SCSI controller, serial console and on-board ethernet will function on these models. On some of these machines, a full 68040 CPU is required to replace the default 68LC040 CPU.

   * Classic family: SE30
   * LC family: LC, LC II, LC III, LC III+, LC475, Performa 400-430, Performa 450, Performa 460, Performa 475, Performa 476
   * Centris family: 610, 650
   * Quadra family: 605, 610, 630, 650, 660AV, 700, 800, 840AV, 900, 950 

NetBSD has this Supported system models list

   * Mac II, IIx, IIcx, SE/30
   * Mac IIci
   * Mac IIsi, IIvx, IIvi
   * Performa 400/405/410/430, 450, 460/466/467
   * LC/Performa 520, 550/560
   * Performa 600/600CD
   * MacTV
   * LC II, III, III+
   * Classic II
   * Color Classic
   * Centris 650
   * Quadra 700[1]
   * Quadra 610, 650, 800
   * Quadra/Centris 660AV
   * Quadra 840AV
   * Quadra 630
   * Centris 610[2]
   * Quadra 610 DOS[2]
   * Quadra 605[2]
   * LC 475, Performa 475/476[2]
   * LC 575, Performa 575/577/578[2]
   * LC 580, Performa 580/588[2]
   * LC 630/630 DOS, Performa 630/631/635/636/637/638[2]
   * Performa 640 DOS[2]
   * PowerBook 170
   * PowerBook 160/165/180
   * PowerBook 550c

Supported devices

   * Internal SCSI controllers and peripherals:
         o Quadra/Centris series' onboard NCR 53c96 SCSI controller (esp).
         o Macintosh II-series', Performa, and LC-series' onboard NCR 5380 SCSI controller (ncrscsi, sbc). 
         o SCSI disk drives (sd).
         o SCSI cdrom drives (cd).
         o Autochangers (ch).
         o Tape drives (st). 
   * Internal sound (asc).
   * NuBus internal expansion bus (nubus).
   * Internal video and most NuBus video cards (macfb).
   * Both internal serial ports (zsc).
   * ADB keyboards and mice (adb) (except on the IIfx, Quadra 900 and 950).
   * Ethernet cards based on the Natl. Semiconductor 8390 (Asante, Apple, and a few others) (ae).
   * Quadra/Centris AV series' onboard MACE ethernet (mc).
   * Some ethernet cards based on the SONIC chip including internal Ethernet on many of Apple's non-AV Quadras/Centrises (sn). 

Untested systems The following Macintosh models are untested and/or lack support for major subsystems. It is very likely that many of these system don't work at all.

   * Classic family: Color Classic, Classic II
   * Macintosh II family: Mac II, IIx, IIcx, IIci, IIsi, IIfx, IIvi, IIvx, Performa 600
   * 500 family: 520, 550, 575, 580, Mac TV 

Unsupported systems

   * PowerPC-based Macs. Some of these are supported in the OpenBSD/macppc port.
   * Powerbook family. Hardware capabilities limit the usability of these systems.
   * Machines based on the 68LC040 processor. Unfortunately, the chip itself contains a major bug for which there is no software workaround available in OpenBSD. 

Unsupported devices

   * Apple Communication Slot (CS) ethernet cards.
   * Any other NuBus card not listed above.
   * Floppy drive.
   * IOP ADB subsystem on the IIfx, Quadra 900 and 950.
   * IDE drives.

power feeder

+5V 	 3.75A           4.75A
-5V 	 0.075A          0.075A
+12V 	 0.78A           1.0A
INPUT 	 100-120V~1A     100-120V~1A
ApplePN  614-0003        614-0028


news updated @ 14-01-2009

kernel{2.6.24, 2.6.26, 2.6.27} are working

lc475 ~ # cat /proc/cpuinfo

CPU: 68040 MMU: 68040 FPU: 68040 Clocking: 24.4MHz BogoMips: 16.28 Calibration: 81408 loops

gentoo-m68k-stage3 is ready: proof version v0.1

serial is still unsupported: I'm working around it

Hardware Issue

issue with serial RS422

the kernel panic, the reason why is still an xfile (it should be consider a software issue)

scrubbing a notApple Hard-disk

The most thorough "easy" way would be to use dump /dev/zero over the entire contents of the hard drive, then follow the "hd patch" procedure to initialize the hard drive with macOS7.5 and his (patched) harddisk-setup tools

Software Issue

how to boot the "supported"-Machine ?

An easier way is to boot using a floppy to load emile and then emile loads the kernel from the SCSI disk. Once you have booted your kernel on your LC475, install emile, write an emile.conf and run emile to update bootblocks on your LC.

5-1-2009: unfortunately booting from the scsi hard drive is still not working. An other xfile to be investigated ...

kernel panic not syncing

gentoo-m68k boot (2.6.24) status @ 2/1/2009

The boot freezes a few seconds after start, and if I use verbose mode I can read the following error:

  • Kernel Panic - Not Syncing - No init found - Try passing init= to kernel

well, 'kernel panic - not syncing' just means that because of the errors that happened before the kernel stops work and especially doesn't write anything to disk. which is a good thing, because it would destroy you data otherwise...

the problem was, that the kernel did not find the program 'init', which is not surprising, because it got lots of errors when trying to find the system partition. as you can see before, the mount of your filesystem failed, so changing from the temporary initrd to the real root failed as well (pivot_root), and deallocation the initrd had to fail because of this (because it is still used).

The reason for the 'mount error' is still unknown, the only hint you gave us is the "error: /bin/insmod exited abnormally" message which indicates that e.g. the ext3 filesystem driver module or the disk controller module were not loaded, the really interesting event, which caused all this, must have occurred before that point.

So everything you told us are just the aftereffects (like saying 'Columbia disintegrated at reentry into the atmosphere' when to prevent further similar accidents you have to say 'insulating material from the external tank was loose'). Maybe you don't have all needed ext3 or disk controller driver modules on your initrd, the program /bin/insmod is missing on your initrd or the initrd-image is outdated or corrupt for another reason

sys-apps/baselayout-2-* incompatibility

gentoo-m68k boot (2.6.24) status 3/1/2009

kernel-2.6.24 boot, gentoo-m68k-2008-rebuild is working

sys-apps/baselayout-2.* reopen a bug

I am building sys-apps/baselayout-1.12.10-r5


PTY allocation request failed on channel 0

gentoo-m68k boot (2.6.24) status 5/1/2009

ssh --vv lc475 unable to SSH to the guest, guest without /dev/pts - no SSH

password: PTY allocation request failed on channel 0 stdin: is not a tty

I struggled with this for a while, for some reason accessing the guest’s console with xm console didn’t seem to work either.

However, I now managed to get console access to one of them using xm console domain, and found that /dev/pts wasn’t mounted - it wasn’t listed in the fstab file that had been created.

I added the following to /etc/fstab :

none /dev/pts devpts defaults 0 0

Now I can SSH to the guests.

in.telnetd in.telnetd: getpeername: Socket operation on non-socket

status @ 6/1/2009

when I run in.telnetd on console as root, I get the message:

  1. in.telnetd in.telnetd: getpeername: Socket operation on non-socket #

this happens 'cause in.telnetd is supposed to be run through xinetd: the question is "how to run telnetd standalone ?"

more Socket operation on non-socket & varia

status @ 8/1/2009

[*] nano

   has been rebuilt 'cause of termcap issue: it is now working

[*] libstdc++

   man doesn't find it, so ...
   cp /usr/lib/gcc/m68k-unknown-linux-gnu/4.2.3/libstdc++.so.6 ./

[*] syslog-ng

   error while loading shared libraries:

Socket operation on non-socket: added UNIX* into kernel.config, rebuilt it, sshd and syslog now are working

learn about ptmx and pts - pseudo-terminal master and slave


The file /dev/ptmx is a character file with major number 5 and minor number 2, usually of mode 0666 and owner.group of root.root. It is used to create a pseudo-terminal master and slave pair.

When a process opens /dev/ptmx, it gets a file descriptor for a pseudo-terminal master (PTM), and a pseudo-terminal slave (PTS) device is created in the /dev/pts directory. Each file descriptor obtained by opening /dev/ptmx is an independent PTM with its own associated PTS, whose path can be found by passing the descriptor to ptsname(3).

Before opening the pseudo-terminal slave, you must pass the master's file descriptor to grantpt(3) and unlockpt(3).

Once both the pseudo-terminal master and slave are open, the slave provides processes with an interface that is identical to that of a real terminal.

Data written to the slave is presented on the master descriptor as input. Data written to the master is presented to the slave as input.

In practice, pseudo-terminals are used for implementing terminal emulators such as xterm(1), in which data read from the pseudo-terminal master is interpreted by the application in the same way a real terminal would interpret the data, and for implementing remote-login programs such as sshd(8), in which data read from the pseudo-terminal master is sent across the network to a client program that is connected to a terminal or terminal emulator.

Pseudo-terminals can also be used to send input to programs that normally refuse to read input from pipes (such as su(8), and passwd(8)). Files /dev/ptmx, /dev/pts/* Notes The Linux support for the above (known as Unix98 pty naming) is done using the devpts filesystem, that should be mounted on /dev/pts.

Before this Unix98 scheme, master ptys were called /dev/ptyp0, ... and slave ptys /dev/ttyp0, ... and one needed lots of preallocated device nodes.

See Also getpt(3), grantpt(3), ptsname(3), unlockpt(3), pty(7) Referenced By posix_openpt(3), proc(5)

boot loader, boot from the scsi disk

8/1/2009: the sun is shining up in the snowy sky, the gentoo-m68k is ready, working, and the kernel is loaded from the hard drive

open questions:

  • what is second/m68k-linux-scsi-driver/apple_driver  ?

It allows to create a bootable CD by replacing Apple Driver from Apple with EMILE's one.

dd if=apple_driver of=/dev/sda2 (where i have my apple_driver dr43) but the bootloader stops to boot: when i switch on the LC475 i see the "?" that means "sorry, no boot media"

There is a checksum, you must use appropriate EMILE tool, Moreover it has only been tested with CDROM.

  • what is second_full ?

It is a second level which is able to read all medias (floppy, scsi) with all filesystems (block, ext2, iso9660, containers, ...)

  • about the boot process using emile:

first is copied into HFS/bootblock second is loaded from /boot/emile/m68k-second_scsi (which is stored into an ext3 partition)

  • shortly:
    • apple_firmare boots
    • searches for driver partition: load it
    • searches for HFS partition: load bootblock <--- first_scsi
    • first_scsi load second_scsi (from ext3 partition)
    • second_scsi boot kernel (from ext3 partition)

may test CFQ I/O scheduler

- A very large update to the CFQ I/O scheduler. Treat with caution, run

 benchmarks.  Remember that the I/O scheduler can be selected on a per-disk
 basis with
       echo as > /sys/block/sda/queue/scheduler
       echo deadline > /sys/block/sda/queue/scheduler
       echo cfq > /sys/block/sda/queue/scheduler 

init: timeout opening/writing control channel /dev/initctl

    * shutdown says: timeout opening/writing control channel /dev/initctl

Hmm, ok, weird, but no problem - I'll just reboot.

    * reboot says: shutdown: timeout opening/writing control channel /dev/initctl

Uh. Okay. Well I really just need it to reload inittab, so, I'll just:

    * telinit 3 says: timeout opening/writing control channel /dev/initctl

Ok. Now I'm aggrivated.

    *  kill -HUP 1

kill 1: No such process

Uh!?!?!?!?!?!? Alright, screw you anyway...

  1. unlink /dev/initctl
  2. mknod -m 0400 /dev/initctl p
  3. reboot

shutdown: timeout opening/writing control channel /dev/initctl

...riiiiiight. So. Anyway. Here's the answer:

  1. reboot -f

And for a moment there, I thought I wasn't in charge.

macserial kernel panic

unable to handle kernel NULL pointer de reference at virtual address 000004 modules linked in: m68k_handle_int+0x1c/0x36

call trace mac_scc_dispatch+0x3a/0x40 auto_irqhandler_fixup+0x4/0x6

kermel panic

M68K Serial driver version 1.01 Mac68K Z8530 serial driver version 1.01 ttyS0 at 0x50f0c022: 8350 ESCC w/o DMA ttyS1 at 0x50f0c020: 8350 ESCC w/o DMA

This is on a Quadra 650, 64MB Ram, and kernel 2.1.120 #14.

( also see ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ )

> Not sure the RTC ever worked, but the serial drivers used to.

RTC used to work in 2.2. The m68k repo tells me that it was deliberately
left in a broken state (because of ADB breakage? build failure?). I'm sure
it can be made to work on those models that have working ADB. Just needs
someone to find the time (no pun intended). Recently upstream has a new
RTC API that will probably need to be adopted too.

> I've ported the Atari SCC serial driver to 2.4 last year, and submitted
> patches to linux-m68k. The Mac serial driver is based on the same SCC
> chip, so it should be possible to use that patch as a starting point.
> What's broken with the ADB driver? Interrupts, or generic ADB comms
> trouble? I didn't follow the driver rewrites, but MacII ADB is a simple
> braindead state machine and should even work in polling mode.

I've done some investigation but haven't made a lot of progress so far.

What I found was that the two kinds of crashes were caused by either
calling an invalid call back pointer in the adb_request struct, or
dereferencing an invalid buffer pointer in the same struct. Many of these
adb_request structs are allocated on the stack. Maybe they are being used
after being freed. Maybe they are being clobbered accidentally by the
MacII driver itself. The fact CUDA ADB doesn't crash doesn't mean it
doesn't have the same problem, since the bug is timing sensitive. The
speed of the machine (Q700 vs Q650), or the presence of a few extra if
statements, can make the difference between immediate crash and waiting a
few minutes or hours. And if it doesn't crash, it does detect the mouse
and keyboard, but they don't function. So I think this could actually be
two bugs, one of which may be related to VIA timing.

I've tried a few different approaches to debugging this, like reverting
changes made to the mac68k ancestors, comparing it to the CUDA ADB driver,
adding overflow checks and tracking stack-based struct pointers, but it is
slow going. I'll probably try capturing some ADB traffic. And stare at the
code more.

It appears that there is no way to collect a crash dump on this arch :-(

I hope to do some more work on this when I get back to Melbourne in a
couple of weeks.

> Can the ADB code be modularized
> > 840av: No real time clock or serial drivers.
> > 9x0: Hard to say (I don't have any). Certainly no RTC.
> >
> > The workaround for the RTC is ntpd and tune2fs.
> ntpd/ntpdate is what I've used in q650 from day one.

It seems that the filesystem checks run before ntpdate, so you need to
disable the last-mount timestamp test that fsck does. You can find this in
the list archives, but here is the workaround again anyway:

tune2fs -i 0 /dev/sdaN

> > The 650's onboard ethernet needs the SONIC driver enabled in the
> > kernel config. Avoid ethernet cards unless SONIC (DP83932) based. Last
> > I checked SONIC was not enabled in the debian config due to build
> > problems, but it can be enabled now.
> That's good to know. If I can pull q650 off duty, I could use it to debug
> the ADB driver that way.

Personally, I'm curious to see what happens when you boot a Q9x0 with a
kernel having no IOP ADB driver. I don't have a Q9x0 to try that, and the
debian kernels all have IOP ADB (I guess that is because it works on the

About Linux

the kernel bootstrap from the floppy drive

 --- Macintosh device drivers                                                
  x x     [*]   Apple Desktop Bus (ADB) support                                       x x
  x x     [*]     Include Mac II ADB driver                                           x x
  x x     [*]     Include Mac IIsi ADB driver                                         x x
  x x     [*]     Include IOP (IIfx/Quadra 9x0) ADB driver                            x x
  x x     [*]     Include PMU (Powerbook) ADB driver                                  x x
  x x     [*]   Support for CUDA based Macs and PowerMacs                             x x
  x x     [*]   Support for ADB input devices (keyboard, mice, ...)                   x x
  x x     [*]   Support for mouse button 2+3 emulation  


  • kernel 2.4.x not tested
  • kernel 2.6.x i used kernel 2.6.24 with success, kernel 2.6.27 is under porting

kernel sources: http://www.kernel.org/pub/linux/kernel/v2.6/

then you need a properly set of patches: coming soon

patch: try this http://www.kernel.org/pub/linux/kernel/people/geert/

other idea: http://people.debian.org/~smarenka/m68k/kernel/

compile strategy

My LC475 has an mc68040 cpu that I'd like to replace with a 68060. Now, 68060 is not well supported, but this is slightly broken - cause there has never been 68000 support in kernel. too. Perhaps the autobuilders should use m68020-unknown-linux-gnu as the lowest common denominator? should it be used in make.conf ?

this would work but not very well on 68060 models though.. here are the options:

a) use m68k-*linux WITHOUT -m68000 flag. Will lose some performance on 68020-40 models, nearly optimal for 68060

b) m68020-linux will lose *lots* of performance on 68060 models.

c) compile 2 versions of the library/program for 20-40 or 60 models.

my idea is:

(a) is pretty acceptable

(b) would be probably the worst alternative.

(c) would be nice and I think it is time to use multilibs for mgentoo-68k

Installing Sysvinit

Preparing Sysvinit

Under normal circumstances, after the kernel's done loading and initializing various system components, it attempts to load a program called init which will finalize the system boot process. The program found on most Linux systems is called Sysvinit and that's the program we're going to install on our LFS system.

   * Unpack the Sysvinit archive
   * Go to the src directory
   * Edit the Makefile file
   * Somewhere in this file, but before the rule all: putt his variable: ROOT = $LFS
   * Precede every /dev on the last four lines in this file by $(ROOT)

After applying the $(ROOT) parts to the last four lines, they should look like this:

  @if [! -p $(ROOT)/dev/initctl ]; then \
  echo "Creating $(ROOT)/dev/initctl" \
  rm -f $(ROOT)/dev/initctl; \
  mknod -m 600 $(ROOT)/dev/initctl p; fi

   * Compile the package by running make LDFLAGS=-static
   * Install the package by running make install

Configuring Sysvinit

In order for Sysvinit to work, we need to create it's configuration file. Create the $LFS/etc/inittab file containing the following:

  1. Begin /etc/inittab




l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 z6:6:wait:/sbin/sulogin

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now


  1. End /etc/inittab

Copying passwd & group files

As you can see from the inittab file, when we boot the system, init will start the sulogin program and sulogin will ask you for root's password. This means we need to have at least a passwd file present on the LFS system. We'll use the passwd and group files from the current running Linux system. Since the passwords are encoded it's just easier to copy the already present file and use that, instead of retyping the encoded password. Mistakes are easily made and this way we can avoid extra hassle afterwards.

   * Copy the /etc/passwd and /etc/group files to $LFS/etc/
   * Edit the $LFS/etc/passwd file and remove every line, exceptthe line for the user root
   * Edit the $LFS/etc/group file and remove every line, except the line for the group root

4.4 Installing a root shell

When sulogin asks you for the root password and you've entered the password, a shell needs to be started. Usually this is the bash shell. Since there are no libraries installed yet, we need to link bash statically, just like we did with sysvinit.

   * Unpack the Bash archive
   * Configure the package by running configure --enable-static-link
   * Compile the package by running make
   * Copy the binary bash to $LFS/bin
   * Create a symlink that links $LFS/bin/sh to $LFS/bin/bash

Testing the system

After you've completed this section, we can test the system and see if we can logon to it. Please note that you will get errors regarding the init program not being able to start the rcS and rc scripts. We will install these scripts in a later stage.

Also note that you won't be able to shutdown the system with a program like shutdown. Although the program is present, it will give you the following error: "You don't exist. Go away." The meaning of this error is that the system isn't able to locate the password file. Although the shutdown program is statically linked against the libraries it needs, it still depends on the nss library (Name Server Switch) which is part of the GNU C Library, which also will be installed in a later stage. This NSS library passes on information where (in this case) the passwd file can be found.

For now you can reboot the system using the reboot -f command. This will bypass shutting down the system using the shutdown program and reboot immediately. Since the file system is mounted read-only this will not harm our system in any way (though you might get a warning next time you try to mount the system that it wasn't unmounted cleanly the last time and that you should run e2fsck to make sure the file system is ok).


on 02-01-2009 i was able to compile a perfectly working kernel 2.6.24, here the dmesg

kernel version 2.6.24-hairy-bilge-rat-m68k-apple-lc475-68040 (root@queen-vittoria) (gcc version 3.4.5) #22 Wed Jan 7 22:19:43 CET 2009
m68k_parse_bootinfo: unknown tag 0x800c ignored
Detected Macintosh model: 89 
 Penguin bootinfo data:
 Video: addr 0xf9001000 row 0x400 depth 8 dimensions 640 x 480
 Videological 0xf0101000 phys. 0x51901000, SCC at 0x50f0c020 
 Boottime: 0xe6e68db3 GMTBias: 0x0 
 Machine ID: 89 CPUid: 0x2 memory size: 0x24 
VIA1 at 50f00000 is a 6522 or clone
VIA2 at 50f02000 is a 6522 or clone
Apple Macintosh Performa 475
On node 0 totalpages: 9216
  DMA zone: 81 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 9135 pages, LIFO batch:1
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 9135
Kernel command line: root=/dev/sda7 init=/sbin/initmini 
Killing onboard sonic... Done.
PID hash table entries: 256 (order: 8, 1024 bytes)
Console: colour dummy device 80x25
console [tty0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 34152k/34172k available (1508k kernel code, 1104k data, 80k init)
SLUB: Genslabs=11, HWalign=16, Order=0-1, MinObjects=4, CPUs=1, Nodes=8
Calibrating delay loop... 16.23 BogoMIPS (lpj=81152)
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
NuBus: Scanning NuBus slots.
Now probing slot E at feffffff
Now probing slot E at fefffffe
Slot E:
  Board resource:
    type: [cat 0x1 type 0x0 hw 0x0 sw 0x0]
    name: EtherNet card
    board id: 0x8
    vendor info:
    revision: REV 1.1
    part: E410 NuBus/E420 LC PDS,EtherNet Adapter
  Function 0x08:
    type: [cat 0x4 type 0x1 hw 0x11e sw 0x100]
    name: Network_Ethernet_Apple_TFL
    memory offset: 0x000d0000
    MAC address: 00:a0:4b:08:db:26
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
macfb: framebuffer at 0xf9001000, mapped to 0x02800000, size 480k
macfb: mode is 640x480x8, linelength=1024
macfb: scrolling: redraw
fbcon_startup: No VBL detected, using timer based cursor.
free_irq: Removing probably wrong IRQ 9
Console: switching to colour frame buffer device 80x30
fb0: Macintosh DAFB built-in frame buffer device
r3964: Philips r3964 Driver $Revision: 1.10 $
Generic RTC Driver v1.07
mac8390.c: v0.4 2001-05-15 David Huggins-Daines <dhd@debian.org> and others
eth0: Memory length resource for slot E not found, probing
eth0: EtherNet card in slot E (type apple)
MAC 00:a0:4b:08:db:26 IRQ 61, 32 KB shared memory at 0xfeed0000,  32-bit access.
input: Macintosh mouse button emulation as /class/input/input0
Macintosh CUDA driver v0.5 for Unified ADB.
adb: starting probe task...
mac_esp: io base at 0x50f10000
esp: using quick version
esp: addr at 0x50f10000
SCSI ID 7 Clk 16MHz CCF=4 TOut 138 NCR53C9x(esp236)
mac_esp: 1 esp controllers found
scsi0 : ESP236 (NCR53C9x)
osst :I: Tape driver with OnStream support version 0.99.4
osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
Driver 'osst' needs updating - please use bus_type methods
Driver 'sd' needs updating - please use bus_type methods
SCSI Media Changer driver v0.25 
Driver 'ch' needs updating - please use bus_type methods
scsi 0:0:0:0: Direct-Access     SEAGATE  ST32550N         8607 PQ: 0 ANSI: 2
scsi1 : scsi_debug, version 1.81 [20070104], dev_size_mb=8, opts=0x0
scsi 1:0:0:0: Direct-Access     Linux    scsi_debug       0004 PQ: 0 ANSI: 5
adb devices: [2]: 2 8 [3]: 3 1
mice: PS/2 mouse device common for all mice
TCP cubic registered
ADB keyboard at 2, handler 1
Detected ADB keyboard, type ANSI.
input: ADB keyboard as /class/input/input1
NET: Registered protocol family 1
NET: Registered protocol family 17
scsi: waiting for bus probes to complete ...
ADB mouse at 3, handler set to 2
input: ADB mouse as /class/input/input2
adb: finished probe task...
sd 0:0:0:0: [sda] 4194995 512-byte hardware sectors (2148 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:0:0:0: [sda] 4194995 512-byte hardware sectors (2148 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
 sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: [sdb] 16384 512-byte hardware sectors (8 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 73 00 10 08
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
sd 1:0:0:0: [sdb] 16384 512-byte hardware sectors (8 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 73 00 10 08
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sdb: unknown partition table
sd 1:0:0:0: [sdb] Attached SCSI disk
sd 1:0:0:0: Attached scsi generic sg1 type 0
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
EXT3 FS on sda7, internal journal

More: Starting Points

There are several barriers to a Linux for Macintosh 68K port. The first of these is that Apple don't want other operating systems on their machines. Whereas you can learn almost all of the workings of a PC from books you will find almost nothing written on the Apple Macintosh. Sometimes the Macintosh specifications and tech notes fill in the blanks at other times its neccessary to apply a great deal of guesswork and experimentation to figure out the hardware.

The second barrier is a human barrier. Most Macintosh machines were not sold to the technical market, and the average Macintosh user isn't terribly interested in a 'real operating system' for their computer. There is nevertheless a sizeable technically oriented Macintosh user community and a lot of Macintosh hardware around (more probably than any other non Intel Linux platform). A further reason has been provided by Apple whose attitude to 68K machines now appears to be 'quaint, buy a new computer'.

The third barrier to a Linux port is less obvious and is hidden by the lack of documentation. Certain folks have speculated that embarrasment is the main reason for Apple Computer releasing so little documentation. The Macintosh platforms in general have positively stone age design features. For example the interrupt controllers on a Macintosh II are a pair of 6522 VIA chips, intended for use with the 8bit 6502 processor. Stupid hardware makes for poor performance unless carefully handled. The complete lack of DMA is even less helpful. Apple seem to think no DMA is a feature on most machines and actually have a technote 'I used to be a teenage DMA junkie' which attempts to justify their rather comical hardware design. Getting Started

So what do you need to get a port started. The first item is hardware. I had most of this (a 5Mbyte MacII cast off from the office as too slow for anything). Initially I felt safe in helping work out the directions for the Linux port as this system lacked an MMU and was therefore unable to run any proposed Linux port.

Rob Pelkey started on some very basic Linux work for the Macintosh but needed a boot loader to load the Linux OS and kick it off. On #linux on the LinuxNet IRC network Jes Sorensen, the keeper of Linux68K, I and several other random people got into a few discussions about the port and what would be required. After a lot of digging we managed to establish some basic information on the Macintosh68K and then fill further areas in by investigating the excellent detective work the OpenBSD/Mac team had done in getting BSD limping along on the Macintosh machines. Further information came to light from the Linux on OSF Mach port that Apple sponsored when we realised that Apple continued to use the same 8bit microcontrollers or emulations of them, and that Apple had not redesigned the systems materially for the new processor.

Everything seemed completely happy. I had a Macintosh box to laugh at (and we used it occasionally to fail to duplicate problems Macintosh users had with CymruNet), we could kick ideas around, and I had no MMU in my Macintosh so I couldn't possible help to write any code.

By this time Rob's effort had stalled badly as he lacked the time to write the boot loader needed to run Linux and was working on passing classes and other sundry items. No worry, someone would eventually take over the project or he would finish his classes. And then Frank Neuman sent me an MMU for the MacII and someone else donated a pair of ethernet cards. Whoops, sudden shortage of excuses.

Learning MacOS

Having fitted the MMU to the Macintosh without blowing it up I tried to get MacOS to run with virtual memory. This is supposed to be simple. You click on the memory tool and select 32bit, virtual memory on. Oh no, my memory control didn't have a 32bit option let alone a virtual memory one. I stared a bit, checked on a more modern mac downstairs to be sure I had the right screen. The other Mac which was running the same MacOS version had the required option, I didn't.

This is when I first learned the horrors of the Mac. While Unix says 'Im sorry you can't do that', MacOS has two error messages. It either goes 'eep?' or the box you wanted to set but couldn't is simply not there on you computer until you've installed the other 12 unidenfied items and filled in 3 apparently unrelated dialog boxes. This was an error of the latter category.

It turns out that Apple shipped the MacII with the ability to upgrade to include an MMU chip. Therefore they sensibly shipped it with a system ROM that wasn't capable of of running with the MMU enabled. Brilliant, just don't design anything mission criticial please. Fortunately Apple had concealed on their web site a small tool which patches the ROM entry points so that it can run in 32bit mode.

Ok so all you do is download the tool, install it and off you go. Not so simple. To get the program onto the machine I needed to get the ethernet to work. I ended up using kermit to transfer 700K of ethernet installer onto the Macintosh. About 4 hours of fighting with the completely alien Macintosh archiver tools I had the machine talking appletalk shares to a Linux box using netatalk and an insight into why Mac people meeting a PC for the first time look like they just discovered alien life forms.

About an hour after that I had figured out how to unpack Macbin files and the Macintosh was in 32bit mode and admitted the MMU was present and functional. Building and Booting Linux

The next stage in the operation was to figure out how to boot a Linux kernel image on the Macintosh. NetBSD and OpenBSD use a boot loader which loads a.out format executables into the memory of the Macintosh, shut the macintosh down, move them to address 0 and jumps to it. I rapidly decided I didn't want to write a boot loader. The OpenBSD loader was almost pure MacOS wizardry at a level far beyond my abilities. Not to worry, it soon became apparent that the OpenBSD loader could be persuaded to load Linux too. A true loader could wait.

The next problem was to build a Linux kernel image that would link and while probably not do anything useful at least serve as something to feed the OpenBSD booter. Linux is built using the GNU toolchain which supports the building of cross compilers. It is thus possible to compile and build 680x0 binaries on an ordinary intel based PC. It took a couple of builds to get gcc and the GNU binutils almost generating the right code. Linux-aout executables have a two byte different header to the OpenBSD ones and the the OpenBSD boot loader checked these bytes. Rather than rebuild the entire toolchain again I wrote a simple tool to fix the headers.

Most of Linux/M68K was quite content to build for a Macintosh target. I filled in everything that complained with dummy routines - for Mac keyboards, mice, display etc until it all compiled. Because of the well designed abstraction layers in the Linux/M68K kernel this is quite easy to do. I now had a completely useless do nothing Macintosh kernel that the OpenBSD loader would load, and which then promptly crashed the Macintosh as I expected.

The Linux/m68K project had faced up to the challenges of supporting multiple types of 680x0 based computer within the same port well before I got involved. As a result of the need to support both the Amiga and Atari systems there are clear layers of abstractions. Adding an additional m68k target consists mostly of filling in platform specific blank fields. A port to a completely new processor would have been far more challenging than this.

For the macintosh case I filled in various mostly blank function handlers. After finally getting the thing to link I ended up with a kernel that hardcoded for a 5Mbyte 68020 based macintosh with FPU and a display at 0xF9000000. It had no interrupt controllers, no disk controllers, no keyboard, no mouse and anything else I could find was also hard coded. But it linked and that was the important item. Having done a bit of reading up on the innards of the console drivers (and much interrogation of Jes) I wrote a fairly simplistic back end for the generic console driver on the Macintosh. As it turns out the very simplistic approach reflected the Macintosh hardware I had, which was a completely unaccelerated bitmapped display supporting 640x480 in 4bit colour. Paint It Black

A Linux 68K kernel starts with a partially shared piece of initialisation code written in 680x0 assembler and using almost all the most gothic and peculiar features of the architecture. This initialisation code also sets up the memory management and caching and touches everything nobody normally knows about. The 68020, 68851, 68881 combination of chips using in the Macintosh II is obsolete and Motorola therefore didn't carry documentation on this device. I knew two things which in theory were enough to debug and figure out what was going on. Firstly I knew the base address of the screen memory, secondly I knew the address that the code would begin executing. The very first routine I put in the startup code painted the screen a revolting blue colour. After about 15 boots and some staring at the source code I had a Macintosh that booted to a blue screen waited a short while and crashed.

In many way this was the single hardest item to get going. When you are dealing with a completely unknown system environment and have no idea what is around your code it is extremely tricky to debug. Real commercial hardware people use logical analysers. I didn't have the option. I learned several things in the process notably that the Macintosh screen memory isn't located where the hardware claims until you set up the MMU. I also made the amazing discovery that the rounded corners on the Macintosh display are drawn in software.

Over a period of the next few weeks the Macintosh went through an assortment of debugging stripes and coloured patterns as I inched a few lines at time through the initialisation assembler code, fixing it bit by bit and gradually mapping in the needed hardware. Eventually the kernel hit the magic start_kernel() function in the C code without crashing on the way. Consoling Yourself

Hitting start_kernel() is in theory the beginning of the easy road. On a PC at least you have text mode consoles instead of stripes, on a Macintosh hitting start_kernel() meant that the prospect of getting the kernel to initialise a text console and begin showing useful debugging information was close. Nothing could have been further from the truth.

After several attempts to get the console up I wrote some routines to print penguins and macs on the screen (this was easier than text). Each significant point the kernel reached added a penguin to the display and a failure point before the console came up printed a given number of burning macintosh logos. While hardly as good as print statements this was good enough to rapidly locate several bugs in the processing of options passed by the boot loader (little things like apparently having 0K of memory tend to upset the Linux memory initialisation). The code would get to the beginning of the console setup and die.

To get past this point I had to fill in support for the 4bit packed pixel displays that were used by the Apple Macintosh 'Toby' display card. The generic bitmapped console drivers for the 680x0 port supported a wide variety of pixel formats, and naturally excluded the one I needed.

Had I known at the time I could simply have switched the machine to Mono in the display preferences but at the time I didn't know the physically switched the card into a monochrome mode. Adding 4bit packed pixel wasn't too difficult. I left the somewhat scarier 2bit packed pixel support for later, in the hope someone else would have to write it not me. The console code is also very modular on the 680x0 and these console layers (abscon, fbcon) are now used by most non Intel ports. It's reasonable to assume that it will be driving all the ports by the 2.3 kernel series.

The machine still crashed mysteriously and all evidence pointed to a structure getting stamped on. I put guard values either side of it and checked they were not overwritten, I moved the structure in memory and I tried everything I could think of in order to stop it being apparently corrupted. No joy, no change. After a bit of head scratching I added code to check the values were ok at boot, and at initialisation of each subsystem. The value was wrong at the start of the C code. I checked it at the start of the assembler and it was wrong by then.

This was beginning to look worrying, it seemed that the boot loader was corrupting data, yet this made no sense as the loader would corrupt the same location, not pick on a specific helpless little variable wherever it may have been located. Eventually I used the GNU objdump tools to look at the binary I was loaded. It turned out that the GNU linker was at fault and in some places was loading a completely bogus address for a relocation.

A new linker and the magic words 'Calibrating Bogomips' appeared on the screen, followed by a hang, and there was much rejoicing. In many ways the time lost to the linker bug was not that bad. Eyeballing the code in search of the mystery bug I had fixed some twenty or thirty other serious bugs in a vain attempt to find the illusionary real bug.

I wasn't too worried the Bogomip calibration hung. It's very hard to calibrate time before the interrupt routines, especially the timer interrupt routines have been written. I commented it out and after a short while the rest of the code booted to the point of saying 'Panic:unable to mount root filesystem'. A reasonable situation as I had exactly no device support except the screen. Filling In The Blanks

Getting the machine to the point where everything appears to boot this far is actually by no means any kind of completion of the first steps of a porting project. It tends to be the point at which you finally appreciate the real problems and the scale of work remaining.

There are numerous pieces of hardware in an Apple Macintosh and while it is possible to ignore them trying to

get to the initial panic about the root filing system I was going to have to fill at least some of them in to go any further.

The most important items to fill in where those that dealt with the most basic system resources - interrupts, memory and the I/O busses. The interrupts and several I/O subsystems are handled by a pair of 6522 VIA chips, 8bit controllers from the stone age. These chips themselves are documented and their locations were known even if some of the connections to their I/O pins were a mystery. A certain amount of mapping work and other detective information showed that the VIA chips provided the all important system timer ticks, handled the keyboard at an extremely low (and at the time undeciphered) level, and provided interfaces for the external interrupts from the bus controllers.

Several other pins appear to do things like turn the Macintosh off. Even now we don't know what everything on the VIA chips does or if all the pins have a real use. It also turned out I got the easy end. The later Macintosh machines replace the second VIA with a device known as RBV (Ram Based Video) which contains a bad emulation of a VIA chip and various other components in one piece of glue logic.

Basic interrupt handling on a Macintosh is relatively clean. A great deal of attention has been paid to keeping interrupts that need a fast response at a higher priority that time consuming processes. That works well under MacOS but Linux itself tends to take rather too binary a view of interrupts especially in the drivers. Certain interrupts are wired in strange ways presumably to save components - the SCSI interrupt for example is wired through a VIA but is effectively upside down compared with the other interrupt sources. Apple saved an inverter by using the fact the VIA can handle either direction of state change as an interrupt signal.

I ended up with two layers of interrupt handling, which were mostly hard coded. Unlike a PC the Macintosh interrupts are very much hard wired. Only the Nubus (plug in) cards change positions, and they all share one interrupt which sets bits in a VIA register to indicate the real interrupt source.

Nubus proved quite entertaining. The documentation is quite weak and all written from the point of view of building a card for a Macintosh. It took about a week before the boot up code would scan and report a list of which nubus slots were occupied and the name of the devices. Once it worked the Nubus turned out to be an extremely well designed system with features much like PCI. Each slot is allocated a set of memory resources and can raise an interrupt. A ROM allows the OS to read each device for identification and driver information. The ROM also contains other "useful" data including icons for the device. At the moment these are not made visible under Linux, but the intention is to support /proc/nubus/[slot]/icon.xpm at some time. Mapping Ethernet Cards

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 2^24 possible locations for the chip and memory within each Nubus slot space.

Finding where the device was hidden required building a collection of kernels which searched the 24bits of address space looking for two things. Firstly looking for areas of memory which could be read and written, secondly looking for areas like this which had the additional property of giving different results when read back. The 8390 chip has several control registers, and by playing with these it is possible to fairly 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 every alternate 16bits 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 16bit wide and that the ethernet controller saw the 16bit wide memory as 8bit wide. Only on a Macinotsh...

These sort of techniques work 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. Rooting For NFS

When you need to start testing a system 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 you are attempting to boot from. Using NFS bounds the possibility for errors and also 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 for the m68k known as "watchtower". Watchtower is extremely outdated but is small and it was easy to unpack. Since the goal was getting 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 bugfixes to the kernel code the applications started to run. As most of the code you need to add for a new M68K platform is drivers and setup code once things started to work most applications sprang to life. It took a couple of tweaks to get floating point to always behave itself 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 clean up and gradually other MacLinux 68K machines began to pop into being. This is an extremely important step for any project as it allows other people to contribute effectively. Michael Schmitz wrote the SCSI drivers and much of the keyboard and mouse support. He is now adding IDE. Numerous other people have tested and debugged the code on the 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) now 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 50% of the way. Once you hit this point the project gathers momentum of its own accord. Even when its something is pointless as Linux on a Macintosh II.

Lack of documentation is only a hinderance. It will not stop determined people exercising basic rights to use and operate property they have bought and 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 port to an undocumented platform. The sterling work done by the OpenBSD/Mac team was a huge help to the Linux project. I'm also happy to say that while half of the world may sit on usenet advocacy groups throwing manure 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.

install gentoo on your lc475


coming soon: i need 300Mb on the web, where to put my stage3-m68k-2008.tgz still looking for a storage

boot loader

create a floppy from the rescue disk image

coming soon

change the kernel boot arguments

coming soon

create your floppy image with your kernel

coming soon

install on your SCSI disk

coming soon

boot from network

coming soon



coming soon

test your uart

dd if=test-uart-lc475.bin of=/dev/fd0

boot the LC475 with that floppy inside, it will show a sort of shell ... type help and see all the options features ... you can open a serial port, you can configure it and send a string

useful to understand if the uart is working with such a code: this code will be ported to the kernel, soon



  • lc475-68040

kernel 2.6.27 full tested and early proof working kernel-lc475.gz (not suggested for production: the uart is not working at all, fbcon works so txt console is possible, sound doesn't work, rtc is not working --> no hw rtc rc scrip are required, the net card is working)

NOTE: this is a debug version, it is stable but it has very intensive debug console logging !


that's all, &info


* Michael Schmitz
* Rob Pelkey, for starting the whole escapade and writing much of the booter.
* Frank Neumann, for dropping me in at the deep end by donating an MMU.
* Jes & Geert, for their explanations of the innards of the M68K port and consoles.
* The MacBSD team, for cracking much of the macintosh before us.
* Everyone else who contributed to the Linux/mac68K project however large or small their part. 
* Keith Baker at CymruNet whose decision to trash the MacII made all of this possible.
* Kolbjørn Barmen, for the gentoo-m68k packages
* Finn Thain, for helping in mac-serial driver

No Thanks

* Steve Jobs - For refusing to provide any Mac68K documentation
* Steve Jobs - For refusing to let anyone else pass on Mac 68K documentation
* Steve Jobs - For refusing to provide NeXT documentation to the NeXT project
* Steve Jobs - For refusing to let anyone else pass on NeXT cube documentation
* Steve Jobs - For killing the Newton
* Steve Jobs - For refusing to provide any documentation about the Newton to the Linux ARM project

About devtools

actually development tools can be inspired @







"mainline" repository in EMILE

   * Public clone url: git://gitorious.org/emile/mainline.git More info…
     You can clone this repository with the following command:
     git clone git://gitorious.org/emile/mainline.git
   * HTTP clone url: http://git.gitorious.org/emile/mainline.git More info…
     You can clone this repository with the following command:
     git clone http://git.gitorious.org/emile/mainline.git
     (note that cloning over HTTP is slightly slower, but useful if you're behind a firewall)
   * http://emile.sourceforge.net/index.php

info to be inspired

Debian m68k on a Mac LC 475 (xfile dated 4th Feb 2006, not confirmed)

I finally have an ethernet card for my LC! Time to install Linux <grin>. PDS Ethernet Card

Debian Linux took a long time to install. Not counting the time it took me to faff around with Penguin settings, Debian took over eight hours to install, not including installing the Mac OS! You will want to set aside a whole day for this one.

My LC 475 has only a single Conner 1 GB drive, so I knew I would have to partition this. When I installed System 7, I allocated a 500 MB partition, but it became apparent that 500 MB was far more than System 7 needed and far less than I would want for debian. I created a new 100 MB partition and transferred the System 7 installation to that, allocating the rest to Debian. If you don't have any unpartitioned space on your disk, you won't be able to do this juggling act and will have to reinstall System 7. Freshly installed, Debian took up 300 MB + 80 MB swap space, but you'll need more than this if you intend to install any software. System 7

Installing the ethernet card was a breeze, just pop out the blanking plate at the back and drop the card in. Tools required ; none. System 7 picked up the card right away, listing 'ethernet' as an available interface for AppleTalk in the Network control panel.

I was not able to get System 7 to talk to my OS X Tiger Macs, since it complains about an incompatible version of AppleTalk. Who'd have thought it? Fortunately, I have an FTP server I can use. Any OS X Mac can act as an FTP server.

In order to get a TCP/IP stack, I installed OpenTransport 1.1.1 (Disk 1, Disk 2, Disk 3, Disk 4). I also copied Fetch 3.0.3 over, it's an FTP client small enough to fit on an HD floppy.

Next, I downloaded the Penguin boot loader and uploaded it to my FTP server. I grabbed the Debian m68k businesscard image. The only files needed from this image are:

   * kernels/vmlinuz-2.2.25-mac
   * nativehd/initrd22.gz

so I mounted the iso in OS X and uploaded just those files to the FTP server. I used Fetch to retrieve the files in System 7.

The Penguin is a loader for Linux that is launched from within the Mac OS. There is a boot loader called EMILE that can boot Linux natively, but I did not investigate this because I already had Penguin working when I found out about it! I would love to hear form anyone who has tips for getting EMILE working. Booting the Debian Installer

Penguin is easy to configure. Choose File -> Settings, then set vmlinuz-2.2.25-mac as the kernel file and initrd22.gz as the ram disk. I set the command line to be root=/dev/ram ramdisk_size=13000. I had to increase the ramdisk size so that the installer had enough room to boot, otherwise it gave an "attempt to access beyond end of device" error. Hit cmd+b to boot the installer. The Penguin HOW-TO is useful.

The Debian installer booted and asked me to choose a language, and how packages should be retrieved (I chose http). The installer used DHCP and configured the ethernet card automatically. Then came partitioning. I told it to use the partition at /dev/sda4 as an ext3 partition mounted on root, and the /dev/sda5 partition as swap space. I was asked whether the installer could unmount the partitions in order to make changes, I answered yes.

You will have a lot of time to fill while it installs the base system! My LC took about 4 hours 30 minutes. When the base system is installed, the Mac will reboot and load the Mac OS. Booting Debian Linux

To boot Debian and complete the installation, Penguin needs to be instructed to use the Linux partition as the root device. Choose file -> Settings and choose kernel-2.2.25-mac as the kernel again, but do NOT use a RAM disk. In my case, Debian's root partition is /dev/sda4 - the fourth partition of the first disk on the SCSI bus. The command line this time is just root=/dev/sda4.

When the Mac rebooted, it asked me about my timezone, to set the root password and to create a new ordinary user, nothing too surprising. I was prompted to select my APT mirror, I chose to get packages through http from the UK debian mirror. At this point I got a lot of console messages saying Unexpected IRQ 3 on Device 00000000, but it seemed to be working so I left it to get on with things for a few hours.

About 10 minutes before it finished installing, Debian asked me to configure my Mail Transport Agent. Since I already have a mail server, I chose to use that as a smarthost, but it would be safest to accept the defaults if you're unsure. Hurrah! It welcomed me to Debian and invited me to log in.

Once I was logged in, everything seemed to be working OK, except for that damn Unexpected IRQ 3 on Device 00000000 message popping up every so often. A little Googling showed that a couple of people got around this by disabling console logging:

$ su -

  1. vi /etc/init.d/klogd

Change the KLOGD="" line to KLOGD="-c 4" and then

  1. /etc/init.d/klogd restart

to restart the kernel logging daemon. man klogd for more info. What about X?

  1. apt-get install x-window-system

This installs twm, a basic window manager and the XFree86 X server. It requires an additional 84 MB.

Some 'gotchas' I encountered: Set keyboard type to macintosh_old or the keys will be all mixed up! The mouse should be /dev/adbmouse. For everything else, you should be able to select the defaults or use common sense. startx should start twm, but for me it would segfault unless I commented out the GLcore and DRI lines in the modules section of /etc/X11/XF86config-4

If you think you made a mistake, you can reconfigure XFree86 and friends by typing

  1. dpkg-reconfigure xserver-xfree86

Still to do:

Get one of Christian T. Steigies' more recent kernels to boot.

See also Macintosh LC 475.


info about debian-m68k/X11 (not verified)

input from http://www.jagshouse.com/Linuxm68k.html

But Does It Run X Windows?


Even On the SE/30????

Sure! You'll need at least 50 megs just for X Windows, 90 for the different varieties of X Windows. It runs rediculously slow on my SE/30, but it sure is cool to show it to my PeeCee co-workers! The downside of X Windows on this particular version of Linux is that you rarely use it except to launch programs, which you can do from the command line interface anyway. Yes, you get some cool screen savers and games (Doom, Abuse to name a few) but those won't run on the SE/30 anyway. Well, they WILL run, but they will be SOOOOO SLOOOOOW that you could make a cup of coffee in between each screen redraw. I finally stopped loading X Windows on my SE/30 because I can surf the net, terminal into my Mac Plus and do text editing, and programming without X Windows.

X Windows Hidden Gotcha

In this particular version of Debian (2.1 or Slink), there are a couple of goofs on the installer. If you are trying to get X Windows going, you will find that it won't work unless you move some files around and change some settings. Because this version is m68k which means it runs on the Motorola 68xxx chip, there are many different platforms it will run on besides Macs such as Amiga, HMV, Atari and maybe a few others.

First, after reading the readme files, when you are setting up Debian after you install it, you'll need to go to


and change the mouse setting to


you'll need to know how to use vi, the Unix text editor (see the links below). This can be cumbersome to a point-and-click Mac guy. Next, you'll need to save the XF86Config.eg file in /etc/X11. This is where it's supposed to be. Now when you type


it will go into X Windows. It will go into X Windows automatically when you boot up from now on.

For more info, read the xf86 readme for Debian 2.1 (Slink).

Another tip

As you read the instructions, you'll see that you need to boot into the Mac OS first, then launch a program called Penguin (get it?) to bootstrap into Debian. Before you do, make sure your settings are correct by consulting the installation instructions. Then change the video setting from




This will make your life MUCH easier, especially if you are using the SE/30!!



that's all, &info


* Michael Schmitz, Yves, who has helped build and test the project.
* Rob Pelkey for starting the whole escapade and writing much of the booter.
* Frank Neumann for dropping me in at the deep end by donating an MMU.
* Jes & Geert for their explanations of the innards of the M68K port and consoles.
* The MacBSD team for cracking much of the macintosh before us.
* Everyone else who contributed to the Linux/mac68K project however large or small their part. 
* Keith Baker at CymruNet whose decision to trash the MacII made all of this possible.
* ...
* ... for building gentoo-m68k btgz
* ... for writing the first and second boot loader stage (aka emile)
* ... for patching the serial

No Thanks

* Steve Jobs - For refusing to provide any Mac68K documentation
* Steve Jobs - For refusing to let anyone else pass on Mac 68K documentation
* Steve Jobs - For refusing to provide NeXT documentation to the NeXT project
* Steve Jobs - For refusing to let anyone else pass on NeXT cube documentation
* Steve Jobs - For killing the Newton
* Steve Jobs - For refusing to provide any documentation about the Newton to the Linux ARM project

About devtools

actually development tools can be inspired @







"mainline" repository in EMILE

   * Public clone url: git://gitorious.org/emile/mainline.git More info…
     You can clone this repository with the following command:
     git clone git://gitorious.org/emile/mainline.git
   * HTTP clone url: http://git.gitorious.org/emile/mainline.git More info…
     You can clone this repository with the following command:
     git clone http://git.gitorious.org/emile/mainline.git
     (note that cloning over HTTP is slightly slower, but useful if you're behind a firewall)
   * http://emile.sourceforge.net/index.php