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.

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 signalling 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 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.

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.

Line 2,271:

Line 2,271:

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 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 occured before that point.

+

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

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

gentoo-mac68K-Flameman

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

Amiga

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).

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?

Note

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 !

How can i understand the internal mechanism of mac68k booting ?

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.

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

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.

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

> 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...

/*
* 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.
*/

Ethernet

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.

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.)

Sound

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

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

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.

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.

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:

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.

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.

mobo Hack, improve the system ram

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:

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.

* 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.

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:

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

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

Description

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.

>
> 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
IIfx).

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 loose some performance on 68020-40 models, nearly optimal for 68060

b) m68020-linux will loose *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:

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).

dmesg

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

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.

Conclusions

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

stage3

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

kernel

dmesg

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

download

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

Thanks

* 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.

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 -

vi /etc/init.d/klogd

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

/etc/init.d/klogd restart

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

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

info about debian-m68k/X11 (not verified)

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

/usr/doc/xserver_common/examples/XF86FConfig.eg

and change the mouse setting to

/dev/adbmouse.

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

startx

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

video=font:VGA8x8

to

video=font:VGA8x16

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

FAQ

that's all, &info

Thanks

* 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