Difference between revisions of "Flameman/mac68k"
(→download) |
Peter Huewe (talk | contribs) (Spellcheck) |
||
(5 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | For more interesting projects done by Flameman, be sure to check out his [[Flameman#master_index|project index]] | ||
+ | |||
= gentoo-mac68K-Flameman = | = gentoo-mac68K-Flameman = | ||
Line 114: | Line 116: | ||
* describe how to add a serial display | * describe how to add a serial display | ||
* describe something useful with you can do with the board | * describe something useful with you can do with the board | ||
− | * describe other Operating Systems | + | * describe other Operating Systems available for the board |
Line 192: | Line 194: | ||
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 | + | 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,268: | Line 2,270: | ||
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 | + | 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 | ||
Line 2,588: | Line 2,590: | ||
− | a) use m68k-*linux WITHOUT -m68000 flag. Will | + | a) use m68k-*linux WITHOUT -m68000 flag. Will lose some performance on 68020-40 models, nearly optimal for 68060 |
− | b) m68020-linux will | + | b) m68020-linux will lose *lots* of performance on 68060 models. |
c) compile 2 versions of the library/program for 20-40 or 60 models. | c) compile 2 versions of the library/program for 20-40 or 60 models. | ||
Line 2,959: | Line 2,961: | ||
− | + | == kernel == | |
− | + | === dmesg === | |
<pre> | <pre> | ||
Line 2,969: | Line 2,971: | ||
− | ==== download | + | === 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 | ||
+ | |||
+ | |||
+ | [[Media:test-uart-lc475.gz|test-uart-lc475.gz]] | ||
+ | |||
+ | |||
+ | |||
+ | === download === | ||
* lc475-68040 | * lc475-68040 | ||
− | kernel 2.6.27 full tested and early working [[Media:kernel-lc475.gz|kernel-lc475.gz]] | + | kernel 2.6.27 full tested and early proof working [[Media:kernel-lc475.gz|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) | (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 ! | ||
Line 3,224: | Line 3,243: | ||
(note that cloning over HTTP is slightly slower, but useful if you're behind a firewall) | (note that cloning over HTTP is slightly slower, but useful if you're behind a firewall) | ||
* http://emile.sourceforge.net/index.php | * http://emile.sourceforge.net/index.php | ||
+ | |||
+ | |||
+ | [[Category:68k]] |
Latest revision as of 15:01, 27 October 2011
For more interesting projects done by Flameman, be sure to check out his project index
Contents
- 1 gentoo-mac68K-Flameman
- 1.1 gentoo on Motorola's 680x0 Processor
- 1.2 A bit about the m68k platforms
- 1.3 Note
- 1.4 Introduction
- 1.4.1 People you could contact if you need help
- 1.4.2 How can i understand the internal mechanism of mac68k booting ?
- 1.4.3 What is supported in kernel &Stuff ?
- 1.4.3.1 What about MODE32
- 1.4.3.2 What about a PMMU
- 1.4.3.3 What about NUbus
- 1.4.3.4 What input devices are supported
- 1.4.3.5 What about SCSI
- 1.4.3.6 What about serial support
- 1.4.3.7 write kernel module
- 1.4.3.8 write kernel serial module
- 1.4.3.9 Ethernet
- 1.4.3.10 Sound
- 1.4.3.11 Floppy drives
- 1.4.3.12 Other devices
- 1.4.3.13 MMU Cache Inhibit
- 1.4.4 serial cable
- 1.4.5 CPU m68k Hacks
- 1.4.6 About the board
- 1.5 the LC475
- 1.5.1 The board
- 1.5.2 LC475 Hacks
- 1.5.2.1 mobo Hack to switch the m680LC40@25Mhz to a m68040@33Mhz
- 1.5.2.2 mobo Hack open questions
- 1.5.2.3 mobo Hack to Speedup to 40MHz w/o external oscillator (experimental)
- 1.5.2.4 mobo Hack to Speedup (experimental2)
- 1.5.2.5 mobo Hack, improve the system ram
- 1.5.2.6 What's that J18 jumper on my LC475/Q605 motherboard?
- 1.5.3 Memory Locations
- 1.5.4 Supported Machines
- 1.5.5 May be supported
- 1.6 Status
- 1.6.1 Hardware Issue
- 1.6.2 Software Issue
- 1.6.2.1 how to boot the "supported"-Machine ?
- 1.6.2.2 kernel panic not syncing
- 1.6.2.3 sys-apps/baselayout-2-* incompatibility
- 1.6.2.4 PTY allocation request failed on channel 0
- 1.6.2.5 in.telnetd in.telnetd: getpeername: Socket operation on non-socket
- 1.6.2.6 more Socket operation on non-socket & varia
- 1.6.2.7 learn about ptmx and pts - pseudo-terminal master and slave
- 1.6.2.8 boot loader, boot from the scsi disk
- 1.6.2.9 may test CFQ I/O scheduler
- 1.6.2.10 init: timeout opening/writing control channel /dev/initctl
- 1.6.2.11 macserial kernel panic
- 1.6.3 About Linux
- 2 install gentoo on your lc475
- 3 that's all, &info
- 4 that's all, &info
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).
A fairly comprehensive overview may be found at the Linux/m68k on Macintosh site, http://www.mac.linux-m68k.org/. Motorola VMEbus
(written by Richard Hirst)
Motorola has released a number of single-board systems using the 680x0 processors, based on the VME bus standard. More information on these systems is available at Motorola's web site.
(More information from a later post:)
I have a VME system based on Motorola MVME boards. Follow the links from www.sleepie.demon.co.uk to find out more about the boards. The boards I use are basically single board computers, which can be plugged into a VME card cage. The interface to the VME is via a chip called the VMEchip2 which provides programmable address windows between the VME bus and the on-board bus. As part of programming the VMEchip2, you specify the AM (Address Modifier) code to use in VME bus cycles. The AM code specifies A24, A32, etc.
VME is used a lot in industrial applications, with various interface boards for digital i/o, etc, so people using Linux on these boards often want to read/write to specific addresses in the VME address space.
Before anyone asks, these boards are expensive (relative to a good PC) - I got mine from work so didn't have to pay for them. NeXT workstations
The NeXT workstations were produced by NeXT Computer, Inc., starting in the late 1980s and ending in 1994. The workstations were made in two configurations: the NeXT Cube and NeXTstation (a.k.a. "the slab").
The NeXT Cube came in 68030 and 68040-based configurations, while the slabs were produced later and came with 68040's only. 68040-based models came in 25MHz and 33MHz (Turbo) editions.
The basic NeXTs came with 4-grayscale video (black, white and two shades of gray). Color NeXTs are capable of 12-bit color, or 4096-color video output (16 levels of red, green and blue). NeXT also produced the NeXT Dimension board for the cubes, which was capable of 24-bit color.
NeXTs ran the NeXTstep operating system; however, current versions of that OS (now called OpenStep) no longer support the original ("black") m68k-based hardware; this has made a Linux port to the NeXT particularly attractive. More information can be found at the Li/NeXT web site, http://www.black.linux-m68k.org/. Other systems
Any takers?
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 !
feel free to contact me (see the contact below)
Introduction
The Target-goal of this page is
- install gentoo-m68k into scsi-disk
- make the board able to boot from it
- describe how to add a serial display
- describe something useful with you can do with the board
- describe other Operating Systems available for the board
People you could contact if you need help
- flameman, i'm currently use this board for a project, email
- msn daredevil-coder@hotmail.it
- email flamemaniii@gmail.com
- irc.nick flameman (channel #edev, #gentoo-ppc)
- you ... if you want ;-)
gentoo forum
http://forums.gentoo.org/viewforum-f-32.html
mac68k forum, 68k Debian Linux Unstable
http://68kmla.net/forums/viewtopic.php?t=5483
ideas from build root
http://buildroot.uclibc.org/buildroot.html
+
How can i understand the internal mechanism of mac68k booting ?
By reading docs, all needed documentation is available here :
http://developer.apple.com/technicalnotes/LegacyTechnologies/index.html
You should find doc about earlier mac, so you could read about HFS bootblock: that is what your first and second boot stage need to bootstrap the kernel
What is supported in kernel &Stuff ?
Any machines in particular that we might have problems with
There is a huge variety of hardware devices across the range of supported models. Many models contain unique hardware and they tend to have their idiosyncrasies. We constantly have to rethink our drivers and interfaces to maintain the kind of device abstraction that makes Linux so portable. For more information on the status of each model, see the machine status page.
What about MODE32
As Mode32 merely fixes a ROM problem, it is not required for the general operation of Linux on the Macintosh, but being that Penguin is a MacOS application, it may be useful in some cases. See below.
What about a PMMU
In order to get the kernel to run on your older 68020 based Macintoshes, you will need to get a 68851 PMMU chip to enable the paged memory that kernel (and A/UX) requires. Of the two 68020 machines, only the Mac II supports the addition of a PMMU. The Mac LC, however does not have this capability so it is not supported.
Also, you should be aware that the 68851 steals an extra clock cycle for every instruction executed in order to do address translation, thus making an already pitifully slow machine by today's standards even slower. 10. Where can I buy a PMMU?
Since no 68020 Macs shipped with a 68851 PMMU, you'll need to buy one and install it yourself. Adam recommends Data Memory Systems (www.datamem.com) and he says that you can get it for $29 + shipping. Of course, $29 will probably buy you an '030 Mac somewhere. :) 11. How much RAM?
The gentoo-m68k port requires about the same amount of RAM as the other Linux ports: about 4 megs at the minimum. Even if Linux supports less, the recent versions of the Penguin booter do not. 4 MB is no longer enough to load a 2.2 kernel and a RAM disk. Even 5 MB is stretching it. System 7.0.1 uses less memory than the later releases; if you have a low memory machine, you might try running it. Also, Emile requires less RAM than MacOS + Penguin. If you intend to run Debian 3.0, you are looking at a more usable minimum of 32 MB. Section V: Specific Hardware Issues
What about NUbus
NuBus is a 32-bit parallel computer bus, originally developed at MIT as a part of the NuMachine workstation project. The first complete implementation of the NuBus and the NuMachine was done by Western Digital for their NuMachine, and for the Lisp Machines Inc. LMI-Lambda. The NuBus was later incorporated in products by Texas Instruments (Explorer), Apple Computer and NeXT. It is no longer widely used outside of the embedded market.
* 1 NuBus architecture * 2 NuBus implementations * 3 See also * 4 External links
NuBus architecture
NuBus was a considerable step forward compared to other interfaces of the day. At the time most computer bus systems were 8-bit, as were the computers they plugged into. However NuBus decided on a 32-bit interface because it was clear the market was headed in this direction.
In addition, NuBus was agnostic about the processor itself. Most buses up to this point were basically the pins on the CPU run out onto the backplane, meaning that the cards had to conform to the signaling and data standards of the machine they were plugged into (being little endian for instance). NuBus made no such assumptions, which meant that a NuBus card could be plugged into any NuBus machine, as long as there was an appropriate device driver.
In order to select the proper device driver, NuBus included an ID scheme that allowed the cards to identify themselves to the host computer during startup. This meant that the user didn't have to configure the system, the bane of bus systems up to that point. For instance, with ISA the driver had to be configured not only for the card, but for any memory it required, the interrupts it used, and so on. NuBus required no such configuration, making it one of the first examples of plug-and-play architecture.
On the downside, while this flexibility made NuBus much simpler for the user and device driver authors, it made things more difficult for the designers of the cards themselves. Whereas most "simple" bus systems were easily supported with a handful of input/output chips designed to be used with that CPU in mind, with NuBus every card and computer had to convert everything in a platform-agnostic "NuBus world". Typically this meant adding a NuBus controller chip between the bus and any I/O chips on the card, increasing costs. While this is a trivial exercise today, one that all newer buses require, at the time in the 1980s NuBus was considered complex and expensive.
NuBus implementations
The NuBus became a standard in 1987 as IEEE 1196. This version used a standard 96-pin three-row connector, running the system on a 10 MHz clock for a maximum burst throughput of 40 MB/s and average speeds of 10 to 20 MB/s. A later addition, NuBus90, increased the clock rate to 20 MHz for better throughput, burst increasing to about 70 MB/s, and average to about 30 MB/s.
The NuBus was first developed commercially in the Western Digital NuMachine, and first used in a production product by their licensee, Lisp Machines, Inc., in the LMI-Lambda, a Lisp Machine. The project and the development group was sold by Western Digital to Texas Instruments in 1984. The technology was incorporated into their TI Explorer, also a Lisp Machine. In 1986, Texas Instruments used the NuBus in the S1500 multiprocessor UNIX system.
NuBus was later selected by Apple Computer for use in their Macintosh II project, where its plug-n-play nature fit well with the Mac philosophy of ease-of-use. It was used in most of their Mac line through the late 1980s and into the 1990s, and was upgraded to NuBus90 starting with the Macintosh Quadras. Early Quadras only supported the 20 MHz rate when two cards were talking to each other, since the motherboard controller was not upgraded. This was later addressed in the 660AV and 840AV models, and used on the early PowerMac models. Apple's implementation also used pin and socket connectors with thumbscrews on the back of the card rather than the often stubborn edge connectors with Phillips screws inside the case that most cards use, making it much easier to install cards. Apple's computers also supplied an always-on +5 V "trickle" power supply for tasks such as watching the phone line while the computer was turned off. This was apparently part of an unapproved NuBus standard.
NuBus was also selected by NeXT Computer for their line of machines, but used a different physical PCB layout. NuBus appears to have seen little use outside these roles, and when Apple switched to PCI in the mid 1990s, NuBus quickly disappeared.
PCI and NuBus
This section provides some background about the differences between the PCI and NuBus architectures. The PCI bus exhibits a number of fundamental differences from NuBus , the previous Macintosh bus standard. The most important of these differences are listed
Comparison of NuBus and the PCI bus
Feature NuBus PCI bus ------------------------------------------------------------------------------------ Bus clock rate 10 MHz 33 MHz, 66 MHz Addressing Geographic Dynamic Signal loading No enforced rules One load per signal Transaction length determination at start at end Bus termination Resistor network Not required Bus control arbitration Distributed Centralized Addressing spaces Memory only Memory, I/O, configuration Wait-state generators Slave only Slave and master Kinds of expansion Cards only Cards and ASIC chips Timeout 255 bus clocks 5 bus clocks Burst capability (byte) 8, 16, 32, 64 Any number of bytes Power allocation 15 W per card 7.5, 15, or 25 W per card
2.6.25.4/include/nubus.h 00001 /* 00002 nubus.h: various definitions and prototypes for NuBus drivers to use. 00003 00004 Originally written by Alan Cox. 00005 00006 Hacked to death by C. Scott Ananian and David Huggins-Daines. 00007 00008 Some of the constants in here are from the corresponding 00009 NetBSD/OpenBSD header file, by Allen Briggs. We figured out the 00010 rest of them on our own. */ 00011 00012 #ifndef LINUX_NUBUS_H 00013 #define LINUX_NUBUS_H 00014 00015 #ifdef __KERNEL__ 00016 #include <asm/nubus.h> 00017 #endif 00018 00019 enum nubus_category { 00020 NUBUS_CAT_BOARD = 0x0001, 00021 NUBUS_CAT_DISPLAY = 0x0003, 00022 NUBUS_CAT_NETWORK = 0x0004, 00023 NUBUS_CAT_COMMUNICATIONS = 0x0006, 00024 NUBUS_CAT_FONT = 0x0009, 00025 NUBUS_CAT_CPU = 0x000A, 00026 /* For lack of a better name */ 00027 NUBUS_CAT_DUODOCK = 0x0020 00028 }; 00029 00030 enum nubus_type_network { 00031 NUBUS_TYPE_ETHERNET = 0x0001, 00032 NUBUS_TYPE_RS232 = 0x0002 00033 }; 00034 00035 enum nubus_type_display { 00036 NUBUS_TYPE_VIDEO = 0x0001 00037 }; 00038 00039 enum nubus_type_cpu { 00040 NUBUS_TYPE_68020 = 0x0003, 00041 NUBUS_TYPE_68030 = 0x0004, 00042 NUBUS_TYPE_68040 = 0x0005 00043 }; 00044 00045 /* Known <Cat,Type,SW,HW> tuples: (according to TattleTech and Slots) 00046 * 68030 motherboards: <10,4,0,24> 00047 * 68040 motherboards: <10,5,0,24> 00048 * DuoDock Plus: <32,1,1,2> 00049 * 00050 * Toby Frame Buffer card: <3,1,1,1> 00051 * RBV built-in video (IIci): <3,1,1,24> 00052 * Valkyrie built-in video (Q630): <3,1,1,46> 00053 * Macintosh Display Card: <3,1,1,25> 00054 * Sonora built-in video (P460): <3,1,1,34> 00055 * Jet framebuffer (DuoDock Plus): <3,1,1,41> 00056 * 00057 * SONIC comm-slot/on-board and DuoDock Ethernet: <4,1,1,272> 00058 * SONIC LC-PDS Ethernet (Dayna, but like Apple 16-bit, sort of): <4,1,1,271> 00059 * Apple SONIC LC-PDS Ethernet ("Apple Ethernet LC Twisted-Pair Card"): <4,1,0,281> 00060 * Sonic Systems Ethernet A-Series Card: <4,1,268,256> 00061 * Asante MacCon NuBus-A: <4,1,260,256> (alpha-1.0,1.1 revision) 00062 * ROM on the above card: <2,1,0,0> 00063 * Cabletron ethernet card: <4,1,1,265> 00064 * Farallon ethernet card: <4,1,268,256> (identical to Sonic Systems card) 00065 * Kinetics EtherPort IIN: <4,1,259,262> 00066 * API Engineering EtherRun_LCa PDS enet card: <4,1,282,256> 00067 * 00068 * Add your devices to the list! You can obtain the "Slots" utility 00069 * from Apple's FTP site at: 00070 * ftp://dev.apple.com/devworld/Tool_Chest/Devices_-_Hardware/NuBus_Slot_Manager/ 00071 * 00072 * Alternately, TattleTech can be found at any Info-Mac mirror site. 00073 * or from its distribution site: ftp://ftp.decismkr.com/dms 00074 */ 00075 00076 /* DrSW: Uniquely identifies the software interface to a board. This 00077 is usually the one you want to look at when writing a driver. It's 00078 not as useful as you think, though, because as we should know by 00079 now (duh), "Apple Compatible" can mean a lot of things... */ 00080 00081 /* Add known DrSW values here */ 00082 enum nubus_drsw { 00083 /* NUBUS_CAT_DISPLAY */ 00084 NUBUS_DRSW_APPLE = 0x0001, 00085 NUBUS_DRSW_APPLE_HIRES = 0x0013, /* MacII HiRes card driver */ 00086 00087 /* NUBUS_CAT_NETWORK */ 00088 NUBUS_DRSW_3COM = 0x0000, 00089 NUBUS_DRSW_CABLETRON = 0x0001, 00090 NUBUS_DRSW_SONIC_LC = 0x0001, 00091 NUBUS_DRSW_KINETICS = 0x0103, 00092 NUBUS_DRSW_ASANTE = 0x0104, 00093 NUBUS_DRSW_TECHWORKS = 0x0109, 00094 NUBUS_DRSW_DAYNA = 0x010b, 00095 NUBUS_DRSW_FARALLON = 0x010c, 00096 NUBUS_DRSW_APPLE_SN = 0x010f, 00097 NUBUS_DRSW_DAYNA2 = 0x0115, 00098 NUBUS_DRSW_FOCUS = 0x011a, 00099 NUBUS_DRSW_ASANTE_CS = 0x011d, /* use asante SMC9194 driver */ 00100 NUBUS_DRSW_DAYNA_LC = 0x011e, 00101 00102 /* NUBUS_CAT_CPU */ 00103 NUBUS_DRSW_NONE = 0x0000, 00104 }; 00105 00106 /* DrHW: Uniquely identifies the hardware interface to a board (or at 00107 least, it should... some video cards are known to incorrectly 00108 identify themselves as Toby cards) */ 00109 00110 /* Add known DrHW values here */ 00111 enum nubus_drhw { 00112 /* NUBUS_CAT_DISPLAY */ 00113 NUBUS_DRHW_APPLE_TFB = 0x0001, /* Toby frame buffer card */ 00114 NUBUS_DRHW_APPLE_WVC = 0x0006, /* Apple Workstation Video Card */ 00115 NUBUS_DRHW_SIGMA_CLRMAX = 0x0007, /* Sigma Design ColorMax */ 00116 NUBUS_DRHW_APPLE_SE30 = 0x0009, /* Apple SE/30 video */ 00117 NUBUS_DRHW_APPLE_HRVC = 0x0013, /* Mac II High-Res Video Card */ 00118 NUBUS_DRHW_APPLE_PVC = 0x0017, /* Mac II Portrait Video Card */ 00119 NUBUS_DRHW_APPLE_RBV1 = 0x0018, /* IIci RBV video */ 00120 NUBUS_DRHW_APPLE_MDC = 0x0019, /* Macintosh Display Card */ 00121 NUBUS_DRHW_APPLE_SONORA = 0x0022, /* Sonora built-in video */ 00122 NUBUS_DRHW_APPLE_24AC = 0x002b, /* Mac 24AC Video Card */ 00123 NUBUS_DRHW_APPLE_VALKYRIE = 0x002e, 00124 NUBUS_DRHW_APPLE_JET = 0x0029, /* Jet framebuffer (DuoDock) */ 00125 NUBUS_DRHW_SMAC_GFX = 0x0105, /* SuperMac GFX */ 00126 NUBUS_DRHW_RASTER_CB264 = 0x013B, /* RasterOps ColorBoard 264 */ 00127 NUBUS_DRHW_MICRON_XCEED = 0x0146, /* Micron Exceed color */ 00128 NUBUS_DRHW_RDIUS_GSC = 0x0153, /* Radius GS/C */ 00129 NUBUS_DRHW_SMAC_SPEC8 = 0x017B, /* SuperMac Spectrum/8 */ 00130 NUBUS_DRHW_SMAC_SPEC24 = 0x017C, /* SuperMac Spectrum/24 */ 00131 NUBUS_DRHW_RASTER_CB364 = 0x026F, /* RasterOps ColorBoard 364 */ 00132 NUBUS_DRHW_RDIUS_DCGX = 0x027C, /* Radius DirectColor/GX */ 00133 NUBUS_DRHW_RDIUS_PC8 = 0x0291, /* Radius PrecisionColor 8 */ 00134 NUBUS_DRHW_LAPIS_PCS8 = 0x0292, /* Lapis ProColorServer 8 */ 00135 NUBUS_DRHW_RASTER_24XLI = 0x02A0, /* RasterOps 8/24 XLi */ 00136 NUBUS_DRHW_RASTER_PBPGT = 0x02A5, /* RasterOps PaintBoard Prism GT */ 00137 NUBUS_DRHW_EMACH_FSX = 0x02AE, /* E-Machines Futura SX */ 00138 NUBUS_DRHW_RASTER_24XLTV = 0x02B7, /* RasterOps 24XLTV */ 00139 NUBUS_DRHW_SMAC_THUND24 = 0x02CB, /* SuperMac Thunder/24 */ 00140 NUBUS_DRHW_SMAC_THUNDLGHT = 0x03D9, /* SuperMac ThunderLight */ 00141 NUBUS_DRHW_RDIUS_PC24XP = 0x0406, /* Radius PrecisionColor 24Xp */ 00142 NUBUS_DRHW_RDIUS_PC24X = 0x040A, /* Radius PrecisionColor 24X */ 00143 NUBUS_DRHW_RDIUS_PC8XJ = 0x040B, /* Radius PrecisionColor 8XJ */ 00144 00145 /* NUBUS_CAT_NETWORK */ 00146 NUBUS_DRHW_INTERLAN = 0x0100, 00147 NUBUS_DRHW_SMC9194 = 0x0101, 00148 NUBUS_DRHW_KINETICS = 0x0106, 00149 NUBUS_DRHW_CABLETRON = 0x0109, 00150 NUBUS_DRHW_ASANTE_LC = 0x010f, 00151 NUBUS_DRHW_SONIC = 0x0110, 00152 NUBUS_DRHW_TECHWORKS = 0x0112, 00153 NUBUS_DRHW_APPLE_SONIC_NB = 0x0118, 00154 NUBUS_DRHW_APPLE_SONIC_LC = 0x0119, 00155 NUBUS_DRHW_FOCUS = 0x011c, 00156 NUBUS_DRHW_SONNET = 0x011d, 00157 }; 00158 00159 /* Resource IDs: These are the identifiers for the various weird and 00160 wonderful tidbits of information that may or may not reside in the 00161 NuBus ROM directory. */ 00162 enum nubus_res_id { 00163 NUBUS_RESID_TYPE = 0x0001, 00164 NUBUS_RESID_NAME = 0x0002, 00165 NUBUS_RESID_ICON = 0x0003, 00166 NUBUS_RESID_DRVRDIR = 0x0004, 00167 NUBUS_RESID_LOADREC = 0x0005, 00168 NUBUS_RESID_BOOTREC = 0x0006, 00169 NUBUS_RESID_FLAGS = 0x0007, 00170 NUBUS_RESID_HWDEVID = 0x0008, 00171 NUBUS_RESID_MINOR_BASEOS = 0x000a, 00172 NUBUS_RESID_MINOR_LENGTH = 0x000b, 00173 NUBUS_RESID_MAJOR_BASEOS = 0x000c, 00174 NUBUS_RESID_MAJOR_LENGTH = 0x000d, 00175 NUBUS_RESID_CICN = 0x000f, 00176 NUBUS_RESID_ICL8 = 0x0010, 00177 NUBUS_RESID_ICL4 = 0x0011, 00178 }; 00179 00180 /* Category-specific resources. */ 00181 enum nubus_board_res_id { 00182 NUBUS_RESID_BOARDID = 0x0020, 00183 NUBUS_RESID_PRAMINITDATA = 0x0021, 00184 NUBUS_RESID_PRIMARYINIT = 0x0022, 00185 NUBUS_RESID_TIMEOUTCONST = 0x0023, 00186 NUBUS_RESID_VENDORINFO = 0x0024, 00187 NUBUS_RESID_BOARDFLAGS = 0x0025, 00188 NUBUS_RESID_SECONDINIT = 0x0026, 00189 00190 /* Not sure why Apple put these next two in here */ 00191 NUBUS_RESID_VIDNAMES = 0x0041, 00192 NUBUS_RESID_VIDMODES = 0x007e 00193 }; 00194 00195 /* Fields within the vendor info directory */ 00196 enum nubus_vendor_res_id { 00197 NUBUS_RESID_VEND_ID = 0x0001, 00198 NUBUS_RESID_VEND_SERIAL = 0x0002, 00199 NUBUS_RESID_VEND_REV = 0x0003, 00200 NUBUS_RESID_VEND_PART = 0x0004, 00201 NUBUS_RESID_VEND_DATE = 0x0005 00202 }; 00203 00204 enum nubus_net_res_id { 00205 NUBUS_RESID_MAC_ADDRESS = 0x0080 00206 }; 00207 00208 enum nubus_cpu_res_id { 00209 NUBUS_RESID_MEMINFO = 0x0081, 00210 NUBUS_RESID_ROMINFO = 0x0082 00211 }; 00212 00213 enum nubus_display_res_id { 00214 NUBUS_RESID_GAMMADIR = 0x0040, 00215 NUBUS_RESID_FIRSTMODE = 0x0080, 00216 NUBUS_RESID_SECONDMODE = 0x0081, 00217 NUBUS_RESID_THIRDMODE = 0x0082, 00218 NUBUS_RESID_FOURTHMODE = 0x0083, 00219 NUBUS_RESID_FIFTHMODE = 0x0084, 00220 NUBUS_RESID_SIXTHMODE = 0x0085 00221 }; 00222 00223 struct nubus_dir 00224 { 00225 unsigned char *base; 00226 unsigned char *ptr; 00227 int done; 00228 int mask; 00229 }; 00230 00231 struct nubus_dirent 00232 { 00233 unsigned char *base; 00234 unsigned char type; 00235 __u32 data; /* Actually 24bits used */ 00236 int mask; 00237 }; 00238 00239 struct nubus_board { 00240 struct nubus_board* next; 00241 struct nubus_dev* first_dev; 00242 00243 /* Only 9-E actually exist, though 0-8 are also theoretically 00244 possible, and 0 is a special case which represents the 00245 motherboard and onboard peripherals (Ethernet, video) */ 00246 int slot; 00247 /* For slot 0, this is bogus. */ 00248 char name[64]; 00249 00250 /* Format block */ 00251 unsigned char* fblock; 00252 /* Root directory (does *not* always equal fblock + doffset!) */ 00253 unsigned char* directory; 00254 00255 unsigned long slot_addr; 00256 /* Offset to root directory (sometimes) */ 00257 unsigned long doffset; 00258 /* Length over which to compute the crc */ 00259 unsigned long rom_length; 00260 /* Completely useless most of the time */ 00261 unsigned long crc; 00262 unsigned char rev; 00263 unsigned char format; 00264 unsigned char lanes; 00265 }; 00266 00267 struct nubus_dev { 00268 /* Next link in device list */ 00269 struct nubus_dev* next; 00270 /* Directory entry in /proc/bus/nubus */ 00271 struct proc_dir_entry* procdir; 00272 00273 /* The functional resource ID of this device */ 00274 unsigned char resid; 00275 /* These are mostly here for convenience; we could always read 00276 them from the ROMs if we wanted to */ 00277 unsigned short category; 00278 unsigned short type; 00279 unsigned short dr_sw; 00280 unsigned short dr_hw; 00281 /* This is the device's name rather than the board's. 00282 Sometimes they are different. Usually the board name is 00283 more correct. */ 00284 char name[64]; 00285 /* MacOS driver (I kid you not) */ 00286 unsigned char* driver; 00287 /* Actually this is an offset */ 00288 unsigned long iobase; 00289 unsigned long iosize; 00290 unsigned char flags, hwdevid; 00291 00292 /* Functional directory */ 00293 unsigned char* directory; 00294 /* Much of our info comes from here */ 00295 struct nubus_board* board; 00296 }; 00297 00298 /* This is all NuBus devices (used to find devices later on) */ 00299 extern struct nubus_dev* nubus_devices; 00300 /* This is all NuBus cards */ 00301 extern struct nubus_board* nubus_boards; 00302 00303 /* Generic NuBus interface functions, modelled after the PCI interface */ 00304 void nubus_scan_bus(void); 00305 extern void nubus_proc_init(void); 00306 int get_nubus_list(char *buf); 00307 int nubus_proc_attach_device(struct nubus_dev *dev); 00308 int nubus_proc_detach_device(struct nubus_dev *dev); 00309 /* If we need more precision we can add some more of these */ 00310 struct nubus_dev* nubus_find_device(unsigned short category, 00311 unsigned short type, 00312 unsigned short dr_hw, 00313 unsigned short dr_sw, 00314 const struct nubus_dev* from); 00315 struct nubus_dev* nubus_find_type(unsigned short category, 00316 unsigned short type, 00317 const struct nubus_dev* from); 00318 /* Might have more than one device in a slot, you know... */ 00319 struct nubus_dev* nubus_find_slot(unsigned int slot, 00320 const struct nubus_dev* from); 00321 00322 /* These are somewhat more NuBus-specific. They all return 0 for 00323 success and -1 for failure, as you'd expect. */ 00324 00325 /* The root directory which contains the board and functional 00326 directories */ 00327 int nubus_get_root_dir(const struct nubus_board* board, 00328 struct nubus_dir* dir); 00329 /* The board directory */ 00330 int nubus_get_board_dir(const struct nubus_board* board, 00331 struct nubus_dir* dir); 00332 /* The functional directory */ 00333 int nubus_get_func_dir(const struct nubus_dev* dev, 00334 struct nubus_dir* dir); 00335 00336 /* These work on any directory gotten via the above */ 00337 int nubus_readdir(struct nubus_dir* dir, 00338 struct nubus_dirent* ent); 00339 int nubus_find_rsrc(struct nubus_dir* dir, 00340 unsigned char rsrc_type, 00341 struct nubus_dirent* ent); 00342 int nubus_rewinddir(struct nubus_dir* dir); 00343 00344 /* Things to do with directory entries */ 00345 int nubus_get_subdir(const struct nubus_dirent* ent, 00346 struct nubus_dir* dir); 00347 void nubus_get_rsrc_mem(void* dest, 00348 const struct nubus_dirent *dirent, 00349 int len); 00350 void nubus_get_rsrc_str(void* dest, 00351 const struct nubus_dirent *dirent, 00352 int maxlen); 00353 00354 /* We'd like to get rid of this eventually. Only daynaport.c uses it now. */ 00355 static inline void *nubus_slot_addr(int slot) 00356 { 00357 return (void *)(0xF0000000|(slot<<24)); 00358 } 00359 00360 #endif /* LINUX_NUBUS_H */
What input devices are supported
Amazingly enough, we have keyboards (and mice)!
Some third-party 3 button mice are also supported. I have a Logitech MouseMan that works perfectly on the console and in X. With 2.6 kernels, use /dev/input/mice and "imps2" protocol. For older kernels, ADB mice are accessed in "cooked" mode through /dev/adbmouse using the "busmouse" protocol for gpm and X.
What about SCSI
LC475 should have a SCSI-2 fast10 of 10Mbyte/sec kernel 2.6.27 supports the macintosh scsi onbloard with cache disabled
chip: ...
kernel sym: ...
internal: 50p narrow
external: ...
measured tx rate: ...
{ text to be replaced
The O2 has onboard support for SCSI devices. It has one internal and one external Ultra Wide SCSI controller. One of these controllers supports the internal disks, the other can be used via the external SCSI port. The Chipset is an Adaptec 7880.
}
SCSI General
SCSI (Small Computer System Interface) was in the beginning of the 1980s one of the newly emerging standards operating at a logical level, which made it independent of the actual drives (was developed as SASI by Shugart). In 1986 SCSI became an approved ANSI standard and soon replaced most other high-bandwidth interface types. Since then several releases of the SCSI standard have been made - introducing higher bandwidth, support for more drives and along with that a variety of different cable and connector types.
Overview Bus Standards Industry Terminology Standards Terminology Bus speed Bus width Number of Devices SCSI 1 Fast5 5MByte/s 8bit 8-1 SCSI 2 (Fast SCSI) Fast10 10Mbyte/s 8bit 8-1 SCSI 3 (Wide SCSI) Fast10 20Mbyte/s 16bit 16-1 Ultra SCSI Fast20 20Mbyte/s 8bit 8-1 Wide Ultra SCSI Fast20 40Mbyte/s 16bit 16-1 Ultra-2 SCSI Fast40 40Mbyte/s 8bit 8-1 Wide Ultra-2 SCSI Fast40 80Mbyte/s 16bit 16-1 Ultra160 Fast80 160Mbyte/s 16bit 16-1
http://www.ibm.com/developerworks/linux/library/l-scsi-subsystem/
Looking at the table you'll notice that 16bit SCSI is usually labelled "Wide SCSI". When talking about 8bit SCSI standards in most cases people tend to talk about "Narrow SCSI" to point out what exactly they are talking about. Electrical Standards
If the different SCSI standards mentioned above aren't confusing enough on their own there are also terms like SE, LVD or HVD floating around. These refer to the way in which the signals are put onto the SCSI wires by the controller and the attached devices.
On SE (Single Ended) SCSI, which was in the original SCSI definition by the way, each signal line is driven against ground. The SCSI standards do not specify SE beyond Ultra SCSI.
On HVD (High Voltage Differential) two lines are used for each signal with one being the inverse of the other so that the actual SCSI signal is the difference between the two lines. This makes the signal much more robust to interference and allows much higher cable length than SE SCSI. The SCSI standards do not specify SE beyond Ultra 2 SCSI.
Both SE and HVD did use 5V logic and were common up to the Ultra SCSI standard. In the design process the used voltage was changed to 3.3V for the new specification which also used a differential interface. This was called LVD (Low Voltage Differential).
Although backwards compatibility was common across the SCSI standards this has not been the case for SE, HVD and LVD specifications. It is not possible to mix HVD or LVD devices with SE devices, neither is it possible to mix HVD and LVD devices. Typical modern LVD devices are multimode and can be used on both SE and LVD SCSI.
What about serial support
shortly: kernel 2.2 supports it, kernel 2.4 & kernel 2.6 doesn't support it at all
> The real driver for the serial ports on m68k Macintosh systems got
> removed from the tree a long time ago and has not been replaced as of
> this time. However, we still register mac_scc_dispatch as an interrupt
> handler for the line that the SCC uses. This looks like you got an
> interrupt for the serial chip and the interrupt code got confused trying
> to dispatch to nothing. I've never seen it happen, but it does look like
> that would be the expected behavior of the current code.
Serial support is working and in the 2.2 kernel. Until recently the Quadra 900 and 950 and the Mac IIfx required that you set the serial ports to "compatible" mode in MacOS before booting. However, we've recently learned how to do this from Linux, so with the very latest kernels, this won't be necessary.
Note that serial ports speeds greater than 38400 bps are not reliable in Linux. (This limitation applies to MacOS as well, except on some high-end models.)
As a side note, obviously the Mac serial plugs won't fit into your PC's serial ports and there are some other technical incompatibilities. Fear not! You can buy an adapter for $10 or so from a catalog or a larger computer store. You can also construct a workable null-modem cable in order to use your PC for a serial console by plugging together a PC null-modem cable and a Macintosh modem cable. With the correct cable, the Mac's RS422 serial port can be made electrically compatible with a PC's RS232 serial port. 3. Output?
Yes, we have framebuffers! The Macintosh framebuffer driver was recently rewritten for Linux 2.2, and now will give at least a workable text console on all models with internal video, as well as the most common NuBus video adaptors. This does not, however, imply that the colormaps will be even vaguely correct. Read on...
The video driver has trouble changing the color map on some models. If your Mac has this problem, and you're handy with ResEdit, you can now (since Penguin-16 at least) tweak the Penguin colormap in order to get something resembling decent color in X. (FIXME: There's a web page about this somewhere, but I've lost the URL...) However, if you fix the colors in X, the console will lose.
Only with the Valkyrie chipset (used on the 580 and 630 series) does the driver support changing the video mode and colour depth on the fly (using fbset, or the X server). To enable it under older kernels, add "video=valkyriefb:" (the colon is important) to the kernel command line in Penguin, and enjoy!
Finally, the Linux 2.2 fbcon subsystem supports 16 and 24-bit truecolor modes on the text console, and the XFree68_FBDev X server also supports them. Therefore, even on machines such as the AV series Quadras where we don't support colormap setting, you can switch to one of these modes in MacOS before booting (Penguin-16 will still complain about this - click "Skip" to continue anyway), and have plenty of pretty colours.
If you're handy with MacsBug, you can also help us add support for colormap changing to the framebuffer...
macints.c 00001 /* 00002 * Macintosh interrupts 00003 * 00004 * General design: 00005 * In contrary to the Amiga and Atari platforms, the Mac hardware seems to 00006 * exclusively use the autovector interrupts (the 'generic level0-level7' 00007 * interrupts with exception vectors 0x19-0x1f). The following interrupt levels 00008 * are used: 00009 * 1 - VIA1 00010 * - slot 0: one second interrupt (CA2) 00011 * - slot 1: VBlank (CA1) 00012 * - slot 2: ADB data ready (SR full) 00013 * - slot 3: ADB data (CB2) 00014 * - slot 4: ADB clock (CB1) 00015 * - slot 5: timer 2 00016 * - slot 6: timer 1 00017 * - slot 7: status of IRQ; signals 'any enabled int.' 00018 * 00019 * 2 - VIA2 or RBV 00020 * - slot 0: SCSI DRQ (CA2) 00021 * - slot 1: NUBUS IRQ (CA1) need to read port A to find which 00022 * - slot 2: /EXP IRQ (only on IIci) 00023 * - slot 3: SCSI IRQ (CB2) 00024 * - slot 4: ASC IRQ (CB1) 00025 * - slot 5: timer 2 (not on IIci) 00026 * - slot 6: timer 1 (not on IIci) 00027 * - slot 7: status of IRQ; signals 'any enabled int.' 00028 * 00029 * 2 - OSS (IIfx only?) 00030 * - slot 0: SCSI interrupt 00031 * - slot 1: Sound interrupt 00032 * 00033 * Levels 3-6 vary by machine type. For VIA or RBV Macintoshes: 00034 * 00035 * 3 - unused (?) 00036 * 00037 * 4 - SCC (slot number determined by reading RR3 on the SSC itself) 00038 * - slot 1: SCC channel A 00039 * - slot 2: SCC channel B 00040 * 00041 * 5 - unused (?) 00042 * [serial errors or special conditions seem to raise level 6 00043 * interrupts on some models (LC4xx?)] 00044 * 00045 * 6 - off switch (?) 00046 * 00047 * For OSS Macintoshes (IIfx only at this point): 00048 * 00049 * 3 - Nubus interrupt 00050 * - slot 0: Slot $9 00051 * - slot 1: Slot $A 00052 * - slot 2: Slot $B 00053 * - slot 3: Slot $C 00054 * - slot 4: Slot $D 00055 * - slot 5: Slot $E 00056 * 00057 * 4 - SCC IOP 00058 * - slot 1: SCC channel A 00059 * - slot 2: SCC channel B 00060 * 00061 * 5 - ISM IOP (ADB?) 00062 * 00063 * 6 - unused 00064 * 00065 * For PSC Macintoshes (660AV, 840AV): 00066 * 00067 * 3 - PSC level 3 00068 * - slot 0: MACE 00069 * 00070 * 4 - PSC level 4 00071 * - slot 1: SCC channel A interrupt 00072 * - slot 2: SCC channel B interrupt 00073 * - slot 3: MACE DMA 00074 * 00075 * 5 - PSC level 5 00076 * 00077 * 6 - PSC level 6 00078 * 00079 * Finally we have good 'ole level 7, the non-maskable interrupt: 00080 * 00081 * 7 - NMI (programmer's switch on the back of some Macs) 00082 * Also RAM parity error on models which support it (IIc, IIfx?) 00083 * 00084 * The current interrupt logic looks something like this: 00085 * 00086 * - We install dispatchers for the autovector interrupts (1-7). These 00087 * dispatchers are responsible for querying the hardware (the 00088 * VIA/RBV/OSS/PSC chips) to determine the actual interrupt source. Using 00089 * this information a machspec interrupt number is generated by placing the 00090 * index of the interrupt hardware into the low three bits and the original 00091 * autovector interrupt number in the upper 5 bits. The handlers for the 00092 * resulting machspec interrupt are then called. 00093 * 00094 * - Nubus is a special case because its interrupts are hidden behind two 00095 * layers of hardware. Nubus interrupts come in as index 1 on VIA #2, 00096 * which translates to IRQ number 17. In this spot we install _another_ 00097 * dispatcher. This dispatcher finds the interrupting slot number (9-F) and 00098 * then forms a new machspec interrupt number as above with the slot number 00099 * minus 9 in the low three bits and the pseudo-level 7 in the upper five 00100 * bits. The handlers for this new machspec interrupt number are then 00101 * called. This puts Nubus interrupts into the range 56-62. 00102 * 00103 * - The Baboon interrupts (used on some PowerBooks) are an even more special 00104 * case. They're hidden behind the Nubus slot $C interrupt thus adding a 00105 * third layer of indirection. Why oh why did the Apple engineers do that? 00106 * 00107 * - We support "fast" and "slow" handlers, just like the Amiga port. The 00108 * fast handlers are called first and with all interrupts disabled. They 00109 * are expected to execute quickly (hence the name). The slow handlers are 00110 * called last with interrupts enabled and the interrupt level restored. 00111 * They must therefore be reentrant. 00112 * 00113 * TODO: 00114 * 00115 */ 00116 00117 #include <linux/module.h> 00118 #include <linux/types.h> 00119 #include <linux/kernel.h> 00120 #include <linux/sched.h> 00121 #include <linux/kernel_stat.h> 00122 #include <linux/interrupt.h> /* for intr_count */ 00123 #include <linux/delay.h> 00124 #include <linux/seq_file.h> 00125 00126 #include <asm/system.h> 00127 #include <asm/irq.h> 00128 #include <asm/traps.h> 00129 #include <asm/bootinfo.h> 00130 #include <asm/machw.h> 00131 #include <asm/macintosh.h> 00132 #include <asm/mac_via.h> 00133 #include <asm/mac_psc.h> 00134 #include <asm/hwtest.h> 00135 #include <asm/errno.h> 00136 #include <asm/macints.h> 00137 #include <asm/irq_regs.h> 00138 00139 #define DEBUG_SPURIOUS 00140 #define SHUTUP_SONIC 00141 00142 /* SCC interrupt mask */ 00143 00144 static int scc_mask; 00145 00146 /* 00147 * VIA/RBV hooks 00148 */ 00149 00150 extern void via_init(void); 00151 extern void via_register_interrupts(void); 00152 extern void via_irq_enable(int); 00153 extern void via_irq_disable(int); 00154 extern void via_irq_clear(int); 00155 extern int via_irq_pending(int); 00156 00157 /* 00158 * OSS hooks 00159 */ 00160 00161 extern int oss_present; 00162 00163 extern void oss_init(void); 00164 extern void oss_register_interrupts(void); 00165 extern void oss_irq_enable(int); 00166 extern void oss_irq_disable(int); 00167 extern void oss_irq_clear(int); 00168 extern int oss_irq_pending(int); 00169 00170 /* 00171 * PSC hooks 00172 */ 00173 00174 extern int psc_present; 00175 00176 extern void psc_init(void); 00177 extern void psc_register_interrupts(void); 00178 extern void psc_irq_enable(int); 00179 extern void psc_irq_disable(int); 00180 extern void psc_irq_clear(int); 00181 extern int psc_irq_pending(int); 00182 00183 /* 00184 * IOP hooks 00185 */ 00186 00187 extern void iop_register_interrupts(void); 00188 00189 /* 00190 * Baboon hooks 00191 */ 00192 00193 extern int baboon_present; 00194 00195 extern void baboon_init(void); 00196 extern void baboon_register_interrupts(void); 00197 extern void baboon_irq_enable(int); 00198 extern void baboon_irq_disable(int); 00199 extern void baboon_irq_clear(int); 00200 extern int baboon_irq_pending(int); 00201 00202 /* 00203 * SCC interrupt routines 00204 */ 00205 00206 static void scc_irq_enable(unsigned int); 00207 static void scc_irq_disable(unsigned int); 00208 00209 /* 00210 * console_loglevel determines NMI handler function 00211 */ 00212 00213 irqreturn_t mac_nmi_handler(int, void *); 00214 irqreturn_t mac_debug_handler(int, void *); 00215 00216 /* #define DEBUG_MACINTS */ 00217 00218 static void mac_enable_irq(unsigned int irq); 00219 static void mac_disable_irq(unsigned int irq); 00220 00221 static struct irq_controller mac_irq_controller = { 00222 .name = "mac", 00223 .lock = __SPIN_LOCK_UNLOCKED(mac_irq_controller.lock), 00224 .enable = mac_enable_irq, 00225 .disable = mac_disable_irq, 00226 }; 00227 00228 void __init mac_init_IRQ(void) 00229 { 00230 #ifdef DEBUG_MACINTS 00231 printk("mac_init_IRQ(): Setting things up...\n"); 00232 #endif 00233 scc_mask = 0; 00234 00235 m68k_setup_irq_controller(&mac_irq_controller, IRQ_USER, 00236 NUM_MAC_SOURCES - IRQ_USER); 00237 /* Make sure the SONIC interrupt is cleared or things get ugly */ 00238 #ifdef SHUTUP_SONIC 00239 printk("Killing onboard sonic... "); 00240 /* This address should hopefully be mapped already */ 00241 if (hwreg_present((void*)(0x50f0a000))) { 00242 *(long *)(0x50f0a014) = 0x7fffL; 00243 *(long *)(0x50f0a010) = 0L; 00244 } 00245 printk("Done.\n"); 00246 #endif /* SHUTUP_SONIC */ 00247 00248 /* 00249 * Now register the handlers for the master IRQ handlers 00250 * at levels 1-7. Most of the work is done elsewhere. 00251 */ 00252 00253 if (oss_present) 00254 oss_register_interrupts(); 00255 else 00256 via_register_interrupts(); 00257 if (psc_present) 00258 psc_register_interrupts(); 00259 if (baboon_present) 00260 baboon_register_interrupts(); 00261 iop_register_interrupts(); 00262 request_irq(IRQ_AUTO_7, mac_nmi_handler, 0, "NMI", 00263 mac_nmi_handler); 00264 #ifdef DEBUG_MACINTS 00265 printk("mac_init_IRQ(): Done!\n"); 00266 #endif 00267 } 00268 00269 /* 00270 * mac_enable_irq - enable an interrupt source 00271 * mac_disable_irq - disable an interrupt source 00272 * mac_clear_irq - clears a pending interrupt 00273 * mac_pending_irq - Returns the pending status of an IRQ (nonzero = pending) 00274 * 00275 * These routines are just dispatchers to the VIA/OSS/PSC routines. 00276 */ 00277 00278 static void mac_enable_irq(unsigned int irq) 00279 { 00280 int irq_src = IRQ_SRC(irq); 00281 00282 switch(irq_src) { 00283 case 1: 00284 via_irq_enable(irq); 00285 break; 00286 case 2: 00287 case 7: 00288 if (oss_present) 00289 oss_irq_enable(irq); 00290 else 00291 via_irq_enable(irq); 00292 break; 00293 case 3: 00294 case 4: 00295 case 5: 00296 case 6: 00297 if (psc_present) 00298 psc_irq_enable(irq); 00299 else if (oss_present) 00300 oss_irq_enable(irq); 00301 else if (irq_src == 4) 00302 scc_irq_enable(irq); 00303 break; 00304 case 8: 00305 if (baboon_present) 00306 baboon_irq_enable(irq); 00307 break; 00308 } 00309 } 00310 00311 static void mac_disable_irq(unsigned int irq) 00312 { 00313 int irq_src = IRQ_SRC(irq); 00314 00315 switch(irq_src) { 00316 case 1: 00317 via_irq_disable(irq); 00318 break; 00319 case 2: 00320 case 7: 00321 if (oss_present) 00322 oss_irq_disable(irq); 00323 else 00324 via_irq_disable(irq); 00325 break; 00326 case 3: 00327 case 4: 00328 case 5: 00329 case 6: 00330 if (psc_present) 00331 psc_irq_disable(irq); 00332 else if (oss_present) 00333 oss_irq_disable(irq); 00334 else if (irq_src == 4) 00335 scc_irq_disable(irq); 00336 break; 00337 case 8: 00338 if (baboon_present) 00339 baboon_irq_disable(irq); 00340 break; 00341 } 00342 } 00343 00344 void mac_clear_irq(unsigned int irq) 00345 { 00346 switch(IRQ_SRC(irq)) { 00347 case 1: 00348 via_irq_clear(irq); 00349 break; 00350 case 2: 00351 case 7: 00352 if (oss_present) 00353 oss_irq_clear(irq); 00354 else 00355 via_irq_clear(irq); 00356 break; 00357 case 3: 00358 case 4: 00359 case 5: 00360 case 6: 00361 if (psc_present) 00362 psc_irq_clear(irq); 00363 else if (oss_present) 00364 oss_irq_clear(irq); 00365 break; 00366 case 8: 00367 if (baboon_present) 00368 baboon_irq_clear(irq); 00369 break; 00370 } 00371 } 00372 00373 int mac_irq_pending(unsigned int irq) 00374 { 00375 switch(IRQ_SRC(irq)) { 00376 case 1: 00377 return via_irq_pending(irq); 00378 case 2: 00379 case 7: 00380 if (oss_present) 00381 return oss_irq_pending(irq); 00382 else 00383 return via_irq_pending(irq); 00384 case 3: 00385 case 4: 00386 case 5: 00387 case 6: 00388 if (psc_present) 00389 return psc_irq_pending(irq); 00390 else if (oss_present) 00391 return oss_irq_pending(irq); 00392 } 00393 return 0; 00394 } 00395 EXPORT_SYMBOL(mac_irq_pending); 00396 00397 static int num_debug[8]; 00398 00399 irqreturn_t mac_debug_handler(int irq, void *dev_id) 00400 { 00401 if (num_debug[irq] < 10) { 00402 printk("DEBUG: Unexpected IRQ %d\n", irq); 00403 num_debug[irq]++; 00404 } 00405 return IRQ_HANDLED; 00406 } 00407 00408 static int in_nmi; 00409 static volatile int nmi_hold; 00410 00411 irqreturn_t mac_nmi_handler(int irq, void *dev_id) 00412 { 00413 int i; 00414 /* 00415 * generate debug output on NMI switch if 'debug' kernel option given 00416 * (only works with Penguin!) 00417 */ 00418 00419 in_nmi++; 00420 for (i=0; i<100; i++) 00421 udelay(1000); 00422 00423 if (in_nmi == 1) { 00424 nmi_hold = 1; 00425 printk("... pausing, press NMI to resume ..."); 00426 } else { 00427 printk(" ok!\n"); 00428 nmi_hold = 0; 00429 } 00430 00431 barrier(); 00432 00433 while (nmi_hold == 1) 00434 udelay(1000); 00435 00436 if (console_loglevel >= 8) { 00437 #if 0 00438 struct pt_regs *fp = get_irq_regs(); 00439 show_state(); 00440 printk("PC: %08lx\nSR: %04x SP: %p\n", fp->pc, fp->sr, fp); 00441 printk("d0: %08lx d1: %08lx d2: %08lx d3: %08lx\n", 00442 fp->d0, fp->d1, fp->d2, fp->d3); 00443 printk("d4: %08lx d5: %08lx a0: %08lx a1: %08lx\n", 00444 fp->d4, fp->d5, fp->a0, fp->a1); 00445 00446 if (STACK_MAGIC != *(unsigned long *)current->kernel_stack_page) 00447 printk("Corrupted stack page\n"); 00448 printk("Process %s (pid: %d, stackpage=%08lx)\n", 00449 current->comm, current->pid, current->kernel_stack_page); 00450 if (intr_count == 1) 00451 dump_stack((struct frame *)fp); 00452 #else 00453 /* printk("NMI "); */ 00454 #endif 00455 } 00456 in_nmi--; 00457 return IRQ_HANDLED; 00458 } 00459 00460 /* 00461 * Simple routines for masking and unmasking 00462 * SCC interrupts in cases where this can't be 00463 * done in hardware (only the PSC can do that.) 00464 */ 00465 00466 static void scc_irq_enable(unsigned int irq) 00467 { 00468 int irq_idx = IRQ_IDX(irq); 00469 00470 scc_mask |= (1 << irq_idx); 00471 } 00472 00473 static void scc_irq_disable(unsigned int irq) 00474 { 00475 int irq_idx = IRQ_IDX(irq); 00476 00477 scc_mask &= ~(1 << irq_idx); 00478 } 00479 00480 /* 00481 * SCC master interrupt handler. We have to do a bit of magic here 00482 * to figure out what channel gave us the interrupt; putting this 00483 * here is cleaner than hacking it into drivers/char/macserial.c. 00484 */ 00485 00486 void mac_scc_dispatch(int irq, void *dev_id) 00487 { 00488 volatile unsigned char *scc = (unsigned char *) mac_bi_data.sccbase + 2; 00489 unsigned char reg; 00490 unsigned long flags; 00491 00492 /* Read RR3 from the chip. Always do this on channel A */ 00493 /* This must be an atomic operation so disable irqs. */ 00494 00495 local_irq_save(flags); 00496 *scc = 3; 00497 reg = *scc; 00498 local_irq_restore(flags); 00499 00500 /* Now dispatch. Bits 0-2 are for channel B and */ 00501 /* bits 3-5 are for channel A. We can safely */ 00502 /* ignore the remaining bits here. */ 00503 /* */ 00504 /* Note that we're ignoring scc_mask for now. */ 00505 /* If we actually mask the ints then we tend to */ 00506 /* get hammered by very persistent SCC irqs, */ 00507 /* and since they're autovector interrupts they */ 00508 /* pretty much kill the system. */ 00509 00510 if (reg & 0x38) 00511 m68k_handle_int(IRQ_SCCA); 00512 if (reg & 0x07) 00513 m68k_handle_int(IRQ_SCCB); 00514 }
mac_SCC.c: has been found in 2.2.24
/* * mac_SCC.c: m68k version of * * macserial.c: Serial port driver for Power Macintoshes. * Extended for the 68K mac by Alan Cox. * Rewritten to m68k serial design by Michael Schmitz * * Derived from drivers/sbus/char/sunserial.c by Paul Mackerras. * * Copyright (C) 1996 Paul Mackerras (Paul.Mackerras@cs.anu.edu.au) * Copyright (C) 1995 David S. Miller (davem@caip.rutgers.edu) */ /* * Design note for the m68k rewrite: * The structure of the m68k serial code requires separation of the low-level * functions that talk directly to the hardware from the Linux serial driver * code interfacing to the tty layer. The reason for this separation is simply * the fact that the m68k serial hardware is, unlike the i386, based on a * variety of chips, and the rs_* serial routines need to be shared. * * I've tried to make consistent use of the async_struct info populated in the * midlevel code, and introduced an async_private struct to hold the Macintosh * SCC internals (this was added to the async_struct for the PowerMac driver). * Exception: the console and kgdb hooks still use the zs_soft[] data, and this * is still filled in by the probe_sccs() routine, which provides some data * for mac_SCC_init as well. Interrupts are registered in mac_SCC_init, so * the console/kgdb stuff probably won't work before proper serial init, and * I have to rely on keeping info and zs_soft consistent at least for the * console/kgdb port. * * Update (16-11-97): The SCC interrupt handling was suffering from the problem * that the autovector SCC interrupt was registered only once, hence only one * async_struct was passed to the interrupt function and only interrupts from * the corresponding channel could be handled (yes, major design flaw). * The autovector interrupt is now registered by the main interrupt initfunc, * and uses a handler that will call the registered SCC specific interrupts in * the fact that the m68k serial hardware is, unlike the i386, based on a * variety of chips, and the rs_* serial routines need to be shared. * * I've tried to make consistent use of the async_struct info populated in the * midlevel code, and introduced an async_private struct to hold the Macintosh * SCC internals (this was added to the async_struct for the PowerMac driver). * Exception: the console and kgdb hooks still use the zs_soft[] data, and this * is still filled in by the probe_sccs() routine, which provides some data * for mac_SCC_init as well. Interrupts are registered in mac_SCC_init, so * the console/kgdb stuff probably won't work before proper serial init, and * I have to rely on keeping info and zs_soft consistent at least for the * console/kgdb port. * * Update (16-11-97): The SCC interrupt handling was suffering from the problem * that the autovector SCC interrupt was registered only once, hence only one * async_struct was passed to the interrupt function and only interrupts from * the corresponding channel could be handled (yes, major design flaw). * The autovector interrupt is now registered by the main interrupt initfunc, * and uses a handler that will call the registered SCC specific interrupts in * turn. The SCC init has to register these as machspec interrupts now, as is * done for the VIA interrupts elsewhere. */
write kernel module
http://kernelnewbies.org/KernelHacking
http://www.faqs.org/docs/kernel/
write kernel serial module
http://www.linux-mips.org/wiki/Serial_Driver_and_Console
http://www.linux.it/~rubini/docs/serial/serial.html
Hello, I am writing a serial driver, and so I started investigating the tiny_serial driver from the third edition of "Linux Device Drivers." Original source is at the bottom of the email. When I exercise this module using stty, EIO is returned. This also happens for reads and writes. I am running 2.6.22 PREEMPT on Powerpc. Any help would be greatly appreciated. ~ $ mknod /dev/ttty1 c 240 1 ~ $ insmod tiny_serial.ko ~ $ stty -a -F /dev/ttty1 stty: /dev/ttty1: Input/output error ~ $ strace stty -a -F /dev/ttty1 execve("/bin/stty", ["stty", "-a", "-F", "/dev/ttty1"], [/* 7 vars */]) = 0 uname({sys="Linux", node="10.100.10.83", ...}) = 0 brk(0) = 0x1018a000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30018000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/ppc603/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls/ppc603", 0x7ffff1e0) = -1 ENOENT (No such file or directory) open("/lib/tls/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls", 0x7ffff1e0) = -1 ENOENT (No such file or directory) open("/lib/ppc603/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/ppc603", 0x7ffff1e0) = -1 ENOENT (No such file or directory) open("/lib/libcrypt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\f"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=31414, ...}) = 0 mmap(0xffb4000, 245516, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffb4000 mprotect(0xffb9000, 225036, PROT_NONE) = 0 mmap(0xffc8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xffc8000 mmap(0xffc9000, 159500, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffc9000 close(3) = 0 open("/lib/libm.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\242"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=566328, ...}) = 0 mmap(0xff1b000, 559164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xff1b000 mprotect(0xff91000, 75836, PROT_NONE) = 0 mmap(0xffa1000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x76000) = 0xffa1000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\316"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1531392, ...}) = 0 mmap(0xfdc6000, 1329164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfdc6000 mprotect(0xfeef000, 112652, PROT_NONE) = 0 mmap(0xfefe000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x128000) = 0xfefe000 mmap(0xff08000, 10252, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff08000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30019000 stat64("/etc/busybox.conf", 0x7ffffb30) = -1 ENOENT (No such file or directory) getuid() = 0 getgid() = 0 setgid(0) = 0 setuid(0) = 0 close(0) = 0 open("/dev/ttty1", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0 fcntl64(0, F_GETFL) = 0x800 (flags O_RDONLY|O_NONBLOCK) fcntl64(0, F_SETFL, O_RDONLY) = 0 ioctl(0, TCGETS, 0x7ffff8e0) = -1 EIO (Input/output error) write(2, "stty: ", 6stty: ) = 6 write(2, "/dev/ttty1", 10/dev/ttty1) = 10 write(2, ": Input/output error\n", 21: Input/output error ) = 21 exit_group(1) = ? Process 213 detached Full source below, apologies for mailer whitespace-damage /* * Tiny Serial driver * * Copyright (C) 2002-2004 Greg Kroah-Hartman (greg@xxxxxxxxx) * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, version 2 of the License. * * This driver shows how to create a minimal serial driver. It does not rely on * any backing hardware, but creates a timer that emulates data being received * from some kind of hardware. */ #include <linux/kernel.h> #include <linux/errno.h> #include <linux/init.h> #include <linux/slab.h> #include <linux/tty.h> #include <linux/tty_flip.h> #include <linux/serial.h> #include <linux/serial_core.h> #include <linux/module.h> #define DRIVER_AUTHOR "Greg Kroah-Hartman <greg@xxxxxxxxx>" #define DRIVER_DESC "Tiny serial driver" /* Module information */ MODULE_AUTHOR( DRIVER_AUTHOR ); MODULE_DESCRIPTION( DRIVER_DESC ); MODULE_LICENSE("GPL"); #define DELAY_TIME HZ * 2 /* 2 seconds per character */ #define TINY_DATA_CHARACTER 't' #define TINY_SERIAL_MAJOR 240 /* experimental range */ #define TINY_SERIAL_MINORS 1 /* only have one minor */ #define UART_NR 1 /* only use one port */ #define TINY_SERIAL_NAME "ttytiny" #define MY_NAME TINY_SERIAL_NAME static struct timer_list *timer; static void tiny_stop_tx(struct uart_port *port, unsigned int tty_stop) { } static void tiny_stop_rx(struct uart_port *port) { } static void tiny_enable_ms(struct uart_port *port) { } static void tiny_tx_chars(struct uart_port *port) { struct circ_buf *xmit = &port->info->xmit; int count; if (port->x_char) { pr_debug("wrote %2x", port->x_char); port->icount.tx++; port->x_char = 0; return; } if (uart_circ_empty(xmit) || uart_tx_stopped(port)) { tiny_stop_tx(port, 0); return; } count = port->fifosize >> 1; do { pr_debug("wrote %2x", xmit->buf[xmit->tail]); xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1); port->icount.tx++; if (uart_circ_empty(xmit)) break; } while (--count > 0); if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) uart_write_wakeup(port); if (uart_circ_empty(xmit)) tiny_stop_tx(port, 0); } static void tiny_start_tx(struct uart_port *port, unsigned int tty_start) { } static void tiny_timer(unsigned long data) { struct uart_port *port; struct tty_struct *tty; port = (struct uart_port *)data; if (!port) return; if (!port->info) return; tty = port->info->tty; if (!tty) return; /* add one character to the tty port */ /* this doesn't actually push the data through unless tty->low_latency is set / tty_insert_flip_char(tty, TINY_DATA_CHARACTER, 0); tty_flip_buffer_push(tty); /* resubmit the timer again */ timer->expires = jiffies + DELAY_TIME; add_timer(timer); /* see if we have any data to transmit */ tiny_tx_chars(port); } static unsigned int tiny_tx_empty(struct uart_port *port) { return 0; } static unsigned int tiny_get_mctrl(struct uart_port *port) { return 0; } static void tiny_set_mctrl(struct uart_port *port, unsigned int mctrl) { } static void tiny_break_ctl(struct uart_port *port, int break_state) { } static void tiny_set_termios(struct uart_port *port, struct termios *new, struct termios *old) { int baud, quot, cflag = new->c_cflag; /* get the byte size */ switch (cflag & CSIZE) { case CS5: printk(KERN_DEBUG " - data bits = 5\n"); break; case CS6: printk(KERN_DEBUG " - data bits = 6\n"); break; case CS7: printk(KERN_DEBUG " - data bits = 7\n"); break; default: // CS8 printk(KERN_DEBUG " - data bits = 8\n"); break; } /* determine the parity */ if (cflag & PARENB) if (cflag & PARODD) pr_debug(" - parity = odd\n"); else pr_debug(" - parity = even\n"); else pr_debug(" - parity = none\n"); /* figure out the stop bits requested */ if (cflag & CSTOPB) pr_debug(" - stop bits = 2\n"); else pr_debug(" - stop bits = 1\n"); /* figure out the flow control settings */ if (cflag & CRTSCTS) pr_debug(" - RTS/CTS is enabled\n"); else pr_debug(" - RTS/CTS is disabled\n"); /* Set baud rate */ baud = uart_get_baud_rate(port, new, old, 0, port->uartclk/16); quot = uart_get_divisor(port, baud); //UART_PUT_DIV_LO(port, (quot & 0xff)); //UART_PUT_DIV_HI(port, ((quot & 0xf00) >> 8)); } static int tiny_startup(struct uart_port *port) { /* this is the first time this port is opened */ /* do any hardware initialization needed here */ /* create our timer and submit it */ if (!timer) { timer = kmalloc(sizeof(*timer), GFP_KERNEL); if (!timer) return -ENOMEM; } timer->data = (unsigned long)port; timer->expires = jiffies + DELAY_TIME; timer->function = tiny_timer; add_timer(timer); return 0; } static void tiny_shutdown(struct uart_port *port) { /* The port is being closed by the last user. */ /* Do any hardware specific stuff here */ /* shut down our timer */ del_timer(timer); } static const char *tiny_type(struct uart_port *port) { return "tinytty"; } static void tiny_release_port(struct uart_port *port) { } static int tiny_request_port(struct uart_port *port) { return 0; } static void tiny_config_port(struct uart_port *port, int flags) { } static int tiny_verify_port(struct uart_port *port, struct serial_struct *ser) { return 0; } static struct uart_ops tiny_ops = { .tx_empty = tiny_tx_empty, .set_mctrl = tiny_set_mctrl, .get_mctrl = tiny_get_mctrl, .stop_tx = tiny_stop_tx, .start_tx = tiny_start_tx, .stop_rx = tiny_stop_rx, .enable_ms = tiny_enable_ms, .break_ctl = tiny_break_ctl, .startup = tiny_startup, .shutdown = tiny_shutdown, .set_termios = tiny_set_termios, .type = tiny_type, .release_port = tiny_release_port, .request_port = tiny_request_port, .config_port = tiny_config_port, .verify_port = tiny_verify_port, }; static struct uart_port tiny_port = { .ops = &tiny_ops, }; static struct uart_driver tiny_reg = { .owner = THIS_MODULE, .driver_name = TINY_SERIAL_NAME, .dev_name = TINY_SERIAL_NAME, .major = TINY_SERIAL_MAJOR, .minor = TINY_SERIAL_MINORS, .nr = UART_NR, }; static int __init tiny_init(void) { int result; printk(KERN_INFO "Tiny serial driver loaded\n"); result = uart_register_driver(&tiny_reg); if (result) return result; result = uart_add_one_port(&tiny_reg, &tiny_port); if (result) uart_unregister_driver(&tiny_reg); return result; } module_init(tiny_init);
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.
LC PDS cards based on the 8390 chipset generally work, as does Apple's SONIC-based LC ethernet card. 5. SCSI?
As of right now, SCSI is working on nearly all machines and you can mount and play with your Mac harddrives from within Linux. If you want to set up an ext2 partition, you'll need to use the installer. (See below.)
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
serial cable
Name (V24) DB25 Pin# DB9 Pin# MiniDIN8 Pin# Direction Full Name Remarks TxD 2 3 3 Out Transmit Data Data RxD 3 2 5 In Receive Data Data RTS 4 7 6 Out Request To Send Handshaking CTS 5 8 2 In Clear To Send Handshaking DTR 20 4 1 Out Data Terminal Ready Status DSR 6 6 - In Data Set Ready Status RI 22 9 - In Ring Indicator Status DCD 8 1 7 In Data Carrier Detect Status GND 7 5 4,8 - Signal ground Reference level - 1 - - - Protective ground Don't use this one as signal ground! How to connect the connectors Null-modem Cable This cable will allow you to hook the MiniDIN8 port directly up to a standard RS-232 port on another computer. From MiniDin8 Pin --> To DB9 Pin DB25 Pin DTR Data Terminal Ready Pin 1 --> DSR Data Set Ready Pin 6 Pin 6 CTS Clear To Send Pin 2 --> RTS Request To Send Pin 7 Pin 4 TD Transmit Data Pin 3 --> RD Receive Data Pin 2 Pin 3 SG Signal Ground Pins 4 & 8 --> SG Signal Ground Pin 5 Pin 7 RD Receive Data Pin 5 --> TD Transmit Data Pin 3 Pin 2 RTS Request To Send Pin 6 --> CTS Clear To Send Pin 8 Pin 5 DCD Data Carrier Detect Pin 7 --> DTR Data Terminal Ready Pin 4 Pin 20 Shield --> - Protective Ground - Pin 1 It it might be needed to have a connection between pin 20 and pin 8 on the Sub-D 25 connector to have your terminal do a carrier detect. SGI is using the same pin-pout for it's 8-pin mini-DIN connectors as Apple for it's machines. Therefor cables and adapters suitable for use with Apple system may be used. Straight-Thru Cable This cable will allow you to hook the MiniDIN8 port into an RS-232 device such as a modem. From MiniDin8 Pin --> To DB9 Pin DB25 Pin DTR Data Terminal Ready Pin 1 --> DTR Data Terminal Ready Pin 4 Pin 20 CTS Clear To Send Pin 2 --> CTS Clear To Send Pin 8 Pin 5 TD Transmit Data Pin 3 --> TD Transmit Data Pin 3 Pin 2 SG Signal Ground Pins 4 & 8 --> SG Signal Ground Pin 5 Pin 7 RD Receive Data Pin 5 --> RD Receive Data Pin 2 Pin 3 RTS Request To Send Pin 6 --> RTS Request To Send Pin 7 Pin 4 DCD Data Carrier Detect Pin 7 --> DCD Data Carrier Detect Pin 1 Pin 8 Shield --> - Protective Ground - Pin 1
http://www.linux-mips.org/wiki/Serial_Cable
CPU m68k Hacks
You can get a 68010 for your 68000-based Mac; the '010 is pin-compatible with the 68000 and should drop right in. You CANNOT put a 68060 into a 68040-based Macintosh; the '060 is not entirely compatible with the Mac ROMs or the '040 instruction set and would require a major rewrite of a good deal of software in order to work properly. The '020 and '030 are NOT pin-compatible.
The 68882 FPU is pin-compatible with the 68881 and should be used instead where possible. Socketed 68882s are most often found on dead SE/30 and IIfx motherboards and on Daystar Digital PowerCache cards. The 68LC040, which shipped in most Performa and LC Macs with an '040 CPU, can be replaced with a full '040 without the LC designation, thus adding an FPU to the previously FPU-less Mac. A good source of these is a dead Quadra or Centris motherboard
About the board
I'm equipped with an LC475, mc68040-25Mhz, 32+4Mb ram, netboard, and SCSI hard drive
the LC475
the outside
the inside
The board
The board consists of:
- CPU motorola mc68040@25Mhz,
- RAM 32MB fast page 5nsec page seek + 4 Mb soldered onboard memory chip
- LAN ??? 10 Mbit/s Fast Ethernet port supporting Auto-MDI/X
- UART Z85c30 chip handling 2 minidin RS232C asynchronous serial port, speeds up to 230k, tested up to 115200bps
- nuBUS one apple NuBUS populated with the ethernet card
- SCSI support for SCSI-I harddrive (/dev/sda)
- ROM 1Mbyte where it is stored the apple firmware
- POWER Max 30 Watts, 0.25 Amps + RTC 3.6V lithium Battery Type
- System PCB 12.2 cm x 15.6 cm
- RTC the real time clock chip is missing
- LED Power
- Watchdog hardware watchdog timer ???
The Apple Macintosh LC 475 features a 25 MHz 68LC040 processor, 4 MB or 8 MB of RAM, and either an 80 MB, a 160 MB, or a 250 MB hard drive in a compact "pizza box" case. The consumer version of the LC 475 is the Performa 475 series, and the business version is the Quadra 605.
* Introduction Date: October 21, 1993 * Discontinued Date: May 1, 1994 * Processor Type: 68LC040 * Processor Speed: 25 MHz * System Bus Speed: 25 MHz Lookaside Bus Speed: N/A * ROM Size: 1 MB * Data Path: 32-bit * Level 1 Cache: 8k Level 2 Cache: N/A * RAM Type: 80 ns 72-pin SIMM * VRAM Type: 80 ns VRAM SIMM * Standard RAM: 4 MB * Maximum RAM: 36 MB * Motherboard RAM: 4 MB * RAM Slots: 1 * Standard VRAM: 512k * Maximum VRAM: 1 MB * Standard Hard Drive: 250 MB Int SCSI * Standard CD-ROM: N/A * Standard Disk: 1.44 MB (manual) * Standard Modem: N/A * Standard Ethernet: N/A * Case Type: Desktop * Form Factor: Macintosh LC * Exp. Slots: LC III PDS Exp. Bays (Free): None * Battery Type: 3.6V Lithium Battery Life: N/A * Built-in Display: N/A * Supported MacOS: 7.1-7.5.1, 7.5.3-8.1 * Dimensions: 2.9 x 12.2 x 15.3 4. * Avg. Weight: 8.8 lbs.
datasheet
http://support.apple.com/kb/SP211
uart zilog chip http://www.zilog.com/docs/serial/scc_escc_um.pdf
R422 line driver http://www.national.com/ds/DS/DS1691A.pdf
LC475 Hacks
mobo Hack to switch the m680LC40@25Mhz to a m68040@33Mhz
mobo Hack open questions
PLL=mc88920 @ 25Mhz syncing in 2.5nsec
what is the difference with MC88916DW70
--> MC88920 is rated at 50MHz (2x25MHz bus
--> MC88916DW70 is rated at 70MHz (2x35MHz bus)
--> MC88916DW80 is rated at 80MHz (2x40MHz bus)
{R301=300,R471=4.7K} ohm
question: are they connected to the PLL ?
to do: draw the PLL schematic
what exactly U17 is ? Gazelle clock generator chip, Apple p/n 343S1135 -a
connections
U17=Gazelle-Apple-343S1135-a
R22A->U17{9} R22B->U17{5,12,16}
R21A->U17{1,4,7} R21B->U17{9}
R25B->U17{13} R25A->U17{2,12,16}
R24A->Vcc->88920{2,5,17} R24B->U17{13}
U1=mc88920
1=/CS 20=GND 2=Vcc 19=2X_Q 3=/MR 18=Q/2 4=/RST_IN 17=VCC 5=Vcc 16=Q2 6=RC1 15=GND 7=GND 14=/RST_OUT 8=SYNC 13=PLL_EN 9=GND 12=Q1 10=Q0 11=VCC
U1.6->U17{6}
G2=31.3344M
G2.2->U17{5,12,16}
G2.4->U17{1,4,7}
G2.1= G2.3=
mobo Hack to Speedup to 40MHz w/o external oscillator (experimental)
LC475: This is a modification that can be performed on a LC475 to speed it up to 33MHz.
Unlike the modifications outlined in the Mac Crystal Oscillator Speedup History File I maintain where those computers use a TTL crystal oscillator to clock the processor, the Quadra 605 uses a Clock Generator. This clock generator, Apple p/n 343S1135 -a N, is located at position U17 on the motherboard. On at least one LC475, the clock generator is Apple p/n 343S0161 -a. Depending on the surface mount resistors used, Pin 6 of this part will either put out a signal for 20, 25, 33, or 40MHz operation. There are four resistor pads used in this modification. Surface mount (SMT) resistors are placed in these pads to pull "low" or "high". The pads are on the bottom of the motherboard, and are in sets of two, so you need to have a resistor on one of the first two and one of the second two. The resistors are either 300 Ohms (301) or 4.7k Ohms (472). They are the "0805" surface mount package.
Resistor Pads R22 (low) R21 (high) R25 (low) R24 (high) Pull Speed ------------------------------------------------------------------------------------- 301 _ 301 _ low, low 20MHz _ 472 301 _ high, low 25MHz 301 _ _ 472 low, high 33MHz _ 472 _ 472 high, high 40MHz
If you monitor Pin 6 of U17, you will get the following:
Pull Pin 6 Speed ------------------------------------------ low, low 9.982MHz 19.964MHz high, low 12.377MHz 24.754MHz low, high 16.425MHz 32.85MHz high, high 19.964MHz 39.928MHz
LC475: If the jumper J18 is not, it is a LC475. The system and other software know this from what is called a gestalt. The gestalt is a number that is specific to each type of Mac Apple makes. A Quadra 605 is gestalt 94 while a LC475 is gestalt 89.
There are several unassigned gestalts, and this modification will explain a few of them:
New Gestalts
Speed J18 Installed J18 Removed ------------------------------------ 20MHz 93 86 25MHz 94 89 33MHz 95 90
It makes no difference if the jumper is installed or not.
Prior to performing this modification you will need to update to system 7.5, or replace your system enabler with System Enabler 065, version 1.2.
I take it few of you will really want to drop down from 25MHz to 20MHz. At 40MHz, the Mac is unable to lock onto the frequency, and will not work. If you must try it to see it for yourself, you will need a 4.7k Ohm resistor. If you send a self addressed stamped envelope (SASE) to Output Enablers (oe@well.com) at 1678 Shattuck, Suite #247, Berkeley, CA 94709, they will send you one of these SMT resistors.
So for the rest of you who want to go from 25 to 33MHz, a 32% speedup, you just need to swap some resistors. The resistors have been glued onto the board prior to soldering, so you need to heat both sides of the SMT resistor at the same time with two soldering irons, and lift the resistor off with the irons. This will break the glue's bond to the SMT resistor. To solder on the resistor, place it on the pads (it does not matter which way it faces), hold it there with a small screw driver, and solder one side to the board at a time.
The modification:
1: remove the SMT resistor from R21, and solder it onto R24
2: remove the SMT resistor from R25, and solder it onto R22
That's it. Keep in mind however that the 25MHz 68LC040 will now be running at 33MHz. The part is not rated to run at these speeds, but my experience with other Mac's and two Quadra 605's shows that this will not be a problem. If you need the math coprocessor you may also want to replace the 68LC040 with a full 68040. I have done this, and it works fine. You may also want to place a heat sink on the 68040. You have about 0.7", so any of those heatsinks will do, but if you mount a fan on it, get the 0.250" one. There are some Speedometer 4.0 Files for a Q605 at 20, 25, and 33MHz on the Clock Chipping Home Page you may want to check out.
At 20, 25 and 33MHz I have checked the serial ports, video, floppy drive, SCSI drives, and RAM, and have observed no problems.
Just a small unrelated note... The battery in the LC475 typically lasts just 2-3 years, and since the LC475 have now been out about that amount of time there have several cases where the battery goes dead. The symptom is that the date does not hold, and the video dies. If you run into this independent of having clock chipped your machine, get a new 3.6 volt lithium battery. The battery is used to store the settings in the PRAM.
At the normal 25MHz, you can use both 640x480@67Hz and 832x624@75Hz on a 15" multiscan monitor, and 640x480@67Hz, 832x624@75Hz, 1024x768@75Hz, and 1152x870@75Hz on a 20" multiscan monitor without any problems. When you accelerate your machine by the above modification you will still be fine at 33MHz. The current clip-on modifications however for the 605/475's only allow you to use 640x480@67Hz.
mobo Hack to Speedup (experimental2)
1. original setting R22=open, R21=472, R25=301, R24=open
I tried the LC475 40MHz Speedup by just swapping the resistors as outlined in the Q605 (LC475, P475, P476) Speedup (33MHz), but failed.
Fortunately during the experiments, I found a successful 40MHz LC475 speedup.
Here it is:
1. R22, R21, R25, R24 are set to the 33MHz-configurations (see the previous mobo Hack to Speedup to 40MHz ...). ie. R22=301, R21=Open, R25=Open, R24=472 2. Detach pin #9 of U17 (Gazelle clock generator chip, Apple p/n 343S1135 -a) 3. Pulled up pin #9 of U17 with a 4.7k Ohm resistor to Vcc (5 volts).
Remove J18; this modification may only work in "LC475 mode"; LC475 owners can ignore this as LC475's were shipped without J18. And it looks like this might only work if you have a 68040RC25 or faster processor, so you will need to replace your 68LC040RC25 processor if you have not already done so. If you have any problems you will want to replace the PLL (MC88920) with a faster one. The MC88920 is rated at 50MHz (25MHz bus). The MC88916DW70 is rated at 70MHz (35MHz bus), and the MC88916DW80 is rated at 80MHz (40MHz bus). The MC88916DW70 is used in many of the other Centris/Quadra level machines.
That's all.
info @ http://www.applefritter.com/node/20510
mobo Hack, improve the system ram
(learn about ram http://wapedia.mobi/it/DRAM#2.)
CONIGLIO PC is available for, 64MB the size of the problem is drew CONIGLIO PC. 128MB SIMM info It would be cool to have 132MB, but up till now I've not had the bottle to order a 128MB SIMM because of only specific types working, and me not being sure which. Bugsi provided me with the info he used when he bought a 128MB SIMM for his LC475. It turns out that Data Memory Systems stock compatible memory - Part number DM36-004 ($65.00) or DM60-015 ($69.00). Either will do. The SIMMs can be double sides, but must be single banked, if you want to buy from elsewhere. I'm tempted to upgrade, but is it worth it? Probably not. Why do it then? Coz you can. :) Even more fun can be had with the info from one of the sites below.
..
..
There really isn't a whole lot you can do easily to the motherboard of this machine. There is one PDS expansion slot which can take a network card such as the one in the photo above. There is also one 72 pin simm slot and two vram simm slots which can be upgraded to a pair of 512k simms.
This machine will take one 128 mb 72 pin simm such as the one in the photo below. Beware of chips that are too tall as I have seen chips which had two vertical rows of chips and were about double the height of the one in the photo. These particular chips work just fine in the 475 and allow you to close the lid.
There was a product on the market called the SimmVerter. It came in several styles that allowed you to put multiple strips of ram into a single slot. The is a twin slot 72 pin version which is model number 72x72 and was actually designed to fit over top of a simm in the slot in front of it.
The problem with this device even if it did work is that you cannot install the cover because the chips stick up above the lowest point of the top cover. In defense of this product, it was never designed to be used in this style of Macintosh computer! Oh and I did try installing two 128 mb 72 pin simms into this device. The Mac would not boot up.
There was another version which allowed you to install four 30 pin simms into a single 72 pin slot but with the cost of ram these days I honestly can't see any reason for doing this. But for documentation purposes I included photos of these items below.
The good news is, if you only install the one strip of memory you will have 128 mb plus the 4 mb installed on the motherboard.
The LC Quadra has a limited upgrade path. Apple did ship a PowerPC upgrade card that replaced the 68040 cpu on the motherboard but this was reported to be of little value in terms of increased speed. As with all the LC series pizzaboxes there is a processor direct or PDS slot which can take several items including a network card and that is a handy option if you are setting up a server. On a slightly different note, Asante also made an ethernet adaptor which plugged into the SCSI port and was called the EN/SC. I came in serveral sytles including a very nice small unit that was used on some of the original PowerBooks.
What's that J18 jumper on my LC475/Q605 motherboard?
With the jumper in place, your Mac will register a gestalt ID corresponding with the Q605. Without the jumper, it will register one corresponding with the LC475.
Memory Locations
memory map of the board will be added as soon as possible
addr begin | addr end | area |
---|---|---|
... | ?? | ram, userspace |
0x00000 | ?? | ram, userspace |
Open questions
1) how/where is serial mapped ?
2) how/where is scsi ctrl mapped ?
3) how/where is nubus ctrl mapped ?
3) what is the bootstrap addr of the rom ?
...
Supported Machines
Machine | Hack | Date | kernel | support | not supported |
---|---|---|---|---|---|
LC475 | cpu replaced with a m68040@25Mhz+MMU+FPU | 02-02-2009 | 2.6.24 is UP, 2.6.26/27/28 is under porting & testing | video, adb, kb, net, scsi | serial, mouse, floppy |
Note:
You can ignore the list of supported machines if you checked the list, and it said that your Mac wouldn't work, 'cause, Well, don't let that stop you, remember that most of the information we have is based on user reports. Your mileage may vary. Just because it didn't work for someone else doesn't mean that it won't work for you. I mean you can ignore the list if you can give your machine a shot!
May be supported
Supported models
OpenBSD/mac68k runs on a large part of the 680x0-based Macintosh computers. The kernel itself has support for the following processor combinations:
* 68020 with 68851 PMMU and 68881 FPU * 68030 with 68882 FPU * 68040 (not including the 68LC040)
The following Macintosh models are supported and tested. This means that at least the SCSI controller, serial console and on-board ethernet will function on these models. On some of these machines, a full 68040 CPU is required to replace the default 68LC040 CPU.
* Classic family: SE30 * LC family: LC, LC II, LC III, LC III+, LC475, Performa 400-430, Performa 450, Performa 460, Performa 475, Performa 476 * Centris family: 610, 650 * Quadra family: 605, 610, 630, 650, 660AV, 700, 800, 840AV, 900, 950
NetBSD has this Supported system models list
* Mac II, IIx, IIcx, SE/30 * Mac IIci * Mac IIsi, IIvx, IIvi * Performa 400/405/410/430, 450, 460/466/467 * LC/Performa 520, 550/560 * Performa 600/600CD * MacTV * LC II, III, III+ * Classic II * Color Classic * Centris 650 * Quadra 700[1] * Quadra 610, 650, 800 * Quadra/Centris 660AV * Quadra 840AV * Quadra 630 * Centris 610[2] * Quadra 610 DOS[2] * Quadra 605[2] * LC 475, Performa 475/476[2] * LC 575, Performa 575/577/578[2] * LC 580, Performa 580/588[2] * LC 630/630 DOS, Performa 630/631/635/636/637/638[2] * Performa 640 DOS[2] * PowerBook 170 * PowerBook 160/165/180 * PowerBook 550c
Supported devices
* Internal SCSI controllers and peripherals: o Quadra/Centris series' onboard NCR 53c96 SCSI controller (esp). o Macintosh II-series', Performa, and LC-series' onboard NCR 5380 SCSI controller (ncrscsi, sbc). o SCSI disk drives (sd). o SCSI cdrom drives (cd). o Autochangers (ch). o Tape drives (st). * Internal sound (asc). * NuBus internal expansion bus (nubus). * Internal video and most NuBus video cards (macfb). * Both internal serial ports (zsc). * ADB keyboards and mice (adb) (except on the IIfx, Quadra 900 and 950). * Ethernet cards based on the Natl. Semiconductor 8390 (Asante, Apple, and a few others) (ae). * Quadra/Centris AV series' onboard MACE ethernet (mc). * Some ethernet cards based on the SONIC chip including internal Ethernet on many of Apple's non-AV Quadras/Centrises (sn).
Untested systems The following Macintosh models are untested and/or lack support for major subsystems. It is very likely that many of these system don't work at all.
* Classic family: Color Classic, Classic II * Macintosh II family: Mac II, IIx, IIcx, IIci, IIsi, IIfx, IIvi, IIvx, Performa 600 * 500 family: 520, 550, 575, 580, Mac TV
Unsupported systems
* PowerPC-based Macs. Some of these are supported in the OpenBSD/macppc port. * Powerbook family. Hardware capabilities limit the usability of these systems. * Machines based on the 68LC040 processor. Unfortunately, the chip itself contains a major bug for which there is no software workaround available in OpenBSD.
Unsupported devices
* Apple Communication Slot (CS) ethernet cards. * Any other NuBus card not listed above. * Floppy drive. * IOP ADB subsystem on the IIfx, Quadra 900 and 950. * IDE drives.
power feeder
ASTEC or TDK DYNA COMP INC. or ASTEC +5V 3.75A 4.75A -5V 0.075A 0.075A +12V 0.78A 1.0A INPUT 100-120V~1A 100-120V~1A ApplePN 614-0003 614-0028
Status
news updated @ 14-01-2009
kernel{2.6.24, 2.6.26, 2.6.27} are working
lc475 ~ # cat /proc/cpuinfo
CPU: 68040 MMU: 68040 FPU: 68040 Clocking: 24.4MHz BogoMips: 16.28 Calibration: 81408 loops
gentoo-m68k-stage3 is ready: proof version v0.1
serial is still unsupported: I'm working around it
Hardware Issue
issue with serial RS422
the kernel panic, the reason why is still an xfile (it should be consider a software issue)
scrubbing a notApple Hard-disk
The most thorough "easy" way would be to use dump /dev/zero over the entire contents of the hard drive, then follow the "hd patch" procedure to initialize the hard drive with macOS7.5 and his (patched) harddisk-setup tools
Software Issue
how to boot the "supported"-Machine ?
An easier way is to boot using a floppy to load emile and then emile loads the kernel from the SCSI disk. Once you have booted your kernel on your LC475, install emile, write an emile.conf and run emile to update bootblocks on your LC.
5-1-2009: unfortunately booting from the scsi hard drive is still not working. An other xfile to be investigated ...
kernel panic not syncing
gentoo-m68k boot (2.6.24) status @ 2/1/2009
The boot freezes a few seconds after start, and if I use verbose mode I can read the following error:
- Kernel Panic - Not Syncing - No init found - Try passing init= to kernel
well, 'kernel panic - not syncing' just means that because of the errors that happened before the kernel stops work and especially doesn't write anything to disk. which is a good thing, because it would destroy you data otherwise...
the problem was, that the kernel did not find the program 'init', which is not surprising, because it got lots of errors when trying to find the system partition. as you can see before, the mount of your filesystem failed, so changing from the temporary initrd to the real root failed as well (pivot_root), and deallocation the initrd had to fail because of this (because it is still used).
The reason for the 'mount error' is still unknown, the only hint you gave us is the "error: /bin/insmod exited abnormally" message which indicates that e.g. the ext3 filesystem driver module or the disk controller module were not loaded, the really interesting event, which caused all this, must have occurred before that point.
So everything you told us are just the aftereffects (like saying 'Columbia disintegrated at reentry into the atmosphere' when to prevent further similar accidents you have to say 'insulating material from the external tank was loose'). Maybe you don't have all needed ext3 or disk controller driver modules on your initrd, the program /bin/insmod is missing on your initrd or the initrd-image is outdated or corrupt for another reason
sys-apps/baselayout-2-* incompatibility
gentoo-m68k boot (2.6.24) status 3/1/2009
kernel-2.6.24 boot, gentoo-m68k-2008-rebuild is working
sys-apps/baselayout-2.* reopen a bug
I am building sys-apps/baselayout-1.12.10-r5
http://bugs.gentoo.org/show_bug.cgi?id=203906
PTY allocation request failed on channel 0
gentoo-m68k boot (2.6.24) status 5/1/2009
ssh --vv lc475 unable to SSH to the guest, guest without /dev/pts - no SSH
password: PTY allocation request failed on channel 0 stdin: is not a tty
I struggled with this for a while, for some reason accessing the guest’s console with xm console didn’t seem to work either.
However, I now managed to get console access to one of them using xm console domain, and found that /dev/pts wasn’t mounted - it wasn’t listed in the fstab file that had been created.
I added the following to /etc/fstab :
none /dev/pts devpts defaults 0 0
Now I can SSH to the guests.
in.telnetd in.telnetd: getpeername: Socket operation on non-socket
status @ 6/1/2009
when I run in.telnetd on console as root, I get the message:
- in.telnetd in.telnetd: getpeername: Socket operation on non-socket #
this happens 'cause in.telnetd is supposed to be run through xinetd: the question is "how to run telnetd standalone ?"
more Socket operation on non-socket & varia
status @ 8/1/2009
[*] nano
has been rebuilt 'cause of termcap issue: it is now working
[*] libstdc++
man doesn't find it, so ... cp /usr/lib/gcc/m68k-unknown-linux-gnu/4.2.3/libstdc++.so.6 ./
[*] syslog-ng
error while loading shared libraries: libglib-2.0.so.0 libevtlog.so.0
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.
See Also getpt(3), grantpt(3), ptsname(3), unlockpt(3), pty(7) Referenced By posix_openpt(3), proc(5)
boot loader, boot from the scsi disk
8/1/2009: the sun is shining up in the snowy sky, the gentoo-m68k is ready, working, and the kernel is loaded from the hard drive
open questions:
- what is second/m68k-linux-scsi-driver/apple_driver ?
It allows to create a bootable CD by replacing Apple Driver from Apple with EMILE's one.
dd if=apple_driver of=/dev/sda2 (where i have my apple_driver dr43) but the bootloader stops to boot: when i switch on the LC475 i see the "?" that means "sorry, no boot media"
There is a checksum, you must use appropriate EMILE tool, Moreover it has only been tested with CDROM.
- what is second_full ?
It is a second level which is able to read all medias (floppy, scsi) with all filesystems (block, ext2, iso9660, containers, ...)
- about the boot process using emile:
first is copied into HFS/bootblock second is loaded from /boot/emile/m68k-second_scsi (which is stored into an ext3 partition)
- shortly:
- apple_firmare boots
- searches for driver partition: load it
- searches for HFS partition: load bootblock <--- first_scsi
- first_scsi load second_scsi (from ext3 partition)
- second_scsi boot kernel (from ext3 partition)
may test CFQ I/O scheduler
- A very large update to the CFQ I/O scheduler. Treat with caution, run
benchmarks. Remember that the I/O scheduler can be selected on a per-disk basis with
echo as > /sys/block/sda/queue/scheduler echo deadline > /sys/block/sda/queue/scheduler echo cfq > /sys/block/sda/queue/scheduler
init: timeout opening/writing control channel /dev/initctl
* shutdown says: timeout opening/writing control channel /dev/initctl
Hmm, ok, weird, but no problem - I'll just reboot.
* reboot says: shutdown: timeout opening/writing control channel /dev/initctl
Uh. Okay. Well I really just need it to reload inittab, so, I'll just:
* telinit 3 says: timeout opening/writing control channel /dev/initctl
Ok. Now I'm aggrivated.
* kill -HUP 1
kill 1: No such process
Uh!?!?!?!?!?!? Alright, screw you anyway...
- unlink /dev/initctl
- mknod -m 0400 /dev/initctl p
- reboot
shutdown: timeout opening/writing control channel /dev/initctl
...riiiiiight. So. Anyway. Here's the answer:
- reboot -f
And for a moment there, I thought I wasn't in charge.
macserial kernel panic
unable to handle kernel NULL pointer de reference at virtual address 000004 modules linked in: m68k_handle_int+0x1c/0x36
call trace mac_scc_dispatch+0x3a/0x40 auto_irqhandler_fixup+0x4/0x6
kermel panic
M68K Serial driver version 1.01
Mac68K Z8530 serial driver version 1.01
ttyS0 at 0x50f0c022: 8350 ESCC w/o DMA
ttyS1 at 0x50f0c020: 8350 ESCC w/o DMA
This is on a Quadra 650, 64MB Ram, and kernel 2.1.120 #14.
( also see ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ )
> > Not sure the RTC ever worked, but the serial drivers used to. RTC used to work in 2.2. The m68k repo tells me that it was deliberately left in a broken state (because of ADB breakage? build failure?). I'm sure it can be made to work on those models that have working ADB. Just needs someone to find the time (no pun intended). Recently upstream has a new RTC API that will probably need to be adopted too. > I've ported the Atari SCC serial driver to 2.4 last year, and submitted > patches to linux-m68k. The Mac serial driver is based on the same SCC > chip, so it should be possible to use that patch as a starting point. > > What's broken with the ADB driver? Interrupts, or generic ADB comms > trouble? I didn't follow the driver rewrites, but MacII ADB is a simple > braindead state machine and should even work in polling mode. I've done some investigation but haven't made a lot of progress so far. What I found was that the two kinds of crashes were caused by either calling an invalid call back pointer in the adb_request struct, or dereferencing an invalid buffer pointer in the same struct. Many of these adb_request structs are allocated on the stack. Maybe they are being used after being freed. Maybe they are being clobbered accidentally by the MacII driver itself. The fact CUDA ADB doesn't crash doesn't mean it doesn't have the same problem, since the bug is timing sensitive. The speed of the machine (Q700 vs Q650), or the presence of a few extra if statements, can make the difference between immediate crash and waiting a few minutes or hours. And if it doesn't crash, it does detect the mouse and keyboard, but they don't function. So I think this could actually be two bugs, one of which may be related to VIA timing. I've tried a few different approaches to debugging this, like reverting changes made to the mac68k ancestors, comparing it to the CUDA ADB driver, adding overflow checks and tracking stack-based struct pointers, but it is slow going. I'll probably try capturing some ADB traffic. And stare at the code more. It appears that there is no way to collect a crash dump on this arch :-( I hope to do some more work on this when I get back to Melbourne in a couple of weeks. > Can the ADB code be modularized > > > 840av: No real time clock or serial drivers. > > 9x0: Hard to say (I don't have any). Certainly no RTC. > > > > The workaround for the RTC is ntpd and tune2fs. > > ntpd/ntpdate is what I've used in q650 from day one. It seems that the filesystem checks run before ntpdate, so you need to disable the last-mount timestamp test that fsck does. You can find this in the list archives, but here is the workaround again anyway: tune2fs -i 0 /dev/sdaN > > The 650's onboard ethernet needs the SONIC driver enabled in the > > kernel config. Avoid ethernet cards unless SONIC (DP83932) based. Last > > I checked SONIC was not enabled in the debian config due to build > > problems, but it can be enabled now. > > That's good to know. If I can pull q650 off duty, I could use it to debug > the ADB driver that way. Personally, I'm curious to see what happens when you boot a Q9x0 with a kernel having no IOP ADB driver. I don't have a Q9x0 to try that, and the debian kernels all have IOP ADB (I guess that is because it works on the IIfx).
About Linux
the kernel bootstrap from the floppy drive
--- Macintosh device drivers x x [*] Apple Desktop Bus (ADB) support x x x x [*] Include Mac II ADB driver x x x x [*] Include Mac IIsi ADB driver x x x x [*] Include IOP (IIfx/Quadra 9x0) ADB driver x x x x [*] Include PMU (Powerbook) ADB driver x x x x [*] Support for CUDA based Macs and PowerMacs x x x x [*] Support for ADB input devices (keyboard, mice, ...) x x x x [*] Support for mouse button 2+3 emulation
what/where
- kernel 2.4.x not tested
- kernel 2.6.x i used kernel 2.6.24 with success, kernel 2.6.27 is under porting
kernel sources: http://www.kernel.org/pub/linux/kernel/v2.6/
then you need a properly set of patches: coming soon
patch: try this http://www.kernel.org/pub/linux/kernel/people/geert/
other idea: http://people.debian.org/~smarenka/m68k/kernel/
compile strategy
My LC475 has an mc68040 cpu that I'd like to replace with a 68060. Now, 68060 is not well supported, but this is slightly broken - cause there has never been 68000 support in kernel. too. Perhaps the autobuilders should use m68020-unknown-linux-gnu as the lowest common denominator? should it be used in make.conf ?
this would work but not very well on 68060 models though.. here are the options:
a) use m68k-*linux WITHOUT -m68000 flag. Will lose some performance on 68020-40 models, nearly optimal for 68060
b) m68020-linux will lose *lots* of performance on 68060 models.
c) compile 2 versions of the library/program for 20-40 or 60 models.
my idea is:
(a) is pretty acceptable
(b) would be probably the worst alternative.
(c) would be nice and I think it is time to use multilibs for mgentoo-68k
Installing Sysvinit
Preparing Sysvinit
Under normal circumstances, after the kernel's done loading and initializing various system components, it attempts to load a program called init which will finalize the system boot process. The program found on most Linux systems is called Sysvinit and that's the program we're going to install on our LFS system.
* Unpack the Sysvinit archive * Go to the src directory * Edit the Makefile file * Somewhere in this file, but before the rule all: putt his variable: ROOT = $LFS * Precede every /dev on the last four lines in this file by $(ROOT)
After applying the $(ROOT) parts to the last four lines, they should look like this:
@if [! -p $(ROOT)/dev/initctl ]; then \ echo "Creating $(ROOT)/dev/initctl" \ rm -f $(ROOT)/dev/initctl; \ mknod -m 600 $(ROOT)/dev/initctl p; fi
* Compile the package by running make LDFLAGS=-static * Install the package by running make install
Configuring Sysvinit
In order for Sysvinit to work, we need to create it's configuration file. Create the $LFS/etc/inittab file containing the following:
- Begin /etc/inittab
id:2:initdefault:
si::sysinit:/etc/init.d/rcS
~~:S:wait:/sbin/sulogin
l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 z6:6:wait:/sbin/sulogin
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
1:2345:respawn:/sbin/sulogin
- End /etc/inittab
Copying passwd & group files
As you can see from the inittab file, when we boot the system, init will start the sulogin program and sulogin will ask you for root's password. This means we need to have at least a passwd file present on the LFS system. We'll use the passwd and group files from the current running Linux system. Since the passwords are encoded it's just easier to copy the already present file and use that, instead of retyping the encoded password. Mistakes are easily made and this way we can avoid extra hassle afterwards.
* Copy the /etc/passwd and /etc/group files to $LFS/etc/ * Edit the $LFS/etc/passwd file and remove every line, exceptthe line for the user root * Edit the $LFS/etc/group file and remove every line, except the line for the group root
4.4 Installing a root shell
When sulogin asks you for the root password and you've entered the password, a shell needs to be started. Usually this is the bash shell. Since there are no libraries installed yet, we need to link bash statically, just like we did with sysvinit.
* Unpack the Bash archive * Configure the package by running configure --enable-static-link * Compile the package by running make * Copy the binary bash to $LFS/bin * Create a symlink that links $LFS/bin/sh to $LFS/bin/bash
Testing the system
After you've completed this section, we can test the system and see if we can logon to it. Please note that you will get errors regarding the init program not being able to start the rcS and rc scripts. We will install these scripts in a later stage.
Also note that you won't be able to shutdown the system with a program like shutdown. Although the program is present, it will give you the following error: "You don't exist. Go away." The meaning of this error is that the system isn't able to locate the password file. Although the shutdown program is statically linked against the libraries it needs, it still depends on the nss library (Name Server Switch) which is part of the GNU C Library, which also will be installed in a later stage. This NSS library passes on information where (in this case) the passwd file can be found.
For now you can reboot the system using the reboot -f command. This will bypass shutting down the system using the shutdown program and reboot immediately. Since the file system is mounted read-only this will not harm our system in any way (though you might get a warning next time you try to mount the system that it wasn't unmounted cleanly the last time and that you should run e2fsck to make sure the file system is ok).
dmesg
on 02-01-2009 i was able to compile a perfectly working kernel 2.6.24, here the dmesg
kernel version 2.6.24-hairy-bilge-rat-m68k-apple-lc475-68040 (root@queen-vittoria) (gcc version 3.4.5) #22 Wed Jan 7 22:19:43 CET 2009 m68k_parse_bootinfo: unknown tag 0x800c ignored Detected Macintosh model: 89 Penguin bootinfo data: Video: addr 0xf9001000 row 0x400 depth 8 dimensions 640 x 480 Videological 0xf0101000 phys. 0x51901000, SCC at 0x50f0c020 Boottime: 0xe6e68db3 GMTBias: 0x0 Machine ID: 89 CPUid: 0x2 memory size: 0x24 VIA1 at 50f00000 is a 6522 or clone VIA2 at 50f02000 is a 6522 or clone Apple Macintosh Performa 475 On node 0 totalpages: 9216 DMA zone: 81 pages used for memmap DMA zone: 0 pages reserved DMA zone: 9135 pages, LIFO batch:1 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 9135 Kernel command line: root=/dev/sda7 init=/sbin/initmini Killing onboard sonic... Done. PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x25 console [tty0] enabled Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 34152k/34172k available (1508k kernel code, 1104k data, 80k init) SLUB: Genslabs=11, HWalign=16, Order=0-1, MinObjects=4, CPUs=1, Nodes=8 Calibrating delay loop... 16.23 BogoMIPS (lpj=81152) Mount-cache hash table entries: 512 net_namespace: 64 bytes NET: Registered protocol family 16 NuBus: Scanning NuBus slots. Now probing slot E at feffffff Now probing slot E at fefffffe Slot E: Board resource: type: [cat 0x1 type 0x0 hw 0x0 sw 0x0] name: EtherNet card board id: 0x8 vendor info: ID: TFL LAN INC. revision: REV 1.1 part: E410 NuBus/E420 LC PDS,EtherNet Adapter Function 0x08: type: [cat 0x4 type 0x1 hw 0x11e sw 0x100] name: Network_Ethernet_Apple_TFL memory offset: 0x000d0000 MAC address: 00:a0:4b:08:db:26 SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) macfb: framebuffer at 0xf9001000, mapped to 0x02800000, size 480k macfb: mode is 640x480x8, linelength=1024 macfb: scrolling: redraw fbcon_startup: No VBL detected, using timer based cursor. free_irq: Removing probably wrong IRQ 9 Console: switching to colour frame buffer device 80x30 fb0: Macintosh DAFB built-in frame buffer device r3964: Philips r3964 Driver $Revision: 1.10 $ Generic RTC Driver v1.07 mac8390.c: v0.4 2001-05-15 David Huggins-Daines <dhd@debian.org> and others eth0: Memory length resource for slot E not found, probing eth0: EtherNet card in slot E (type apple) MAC 00:a0:4b:08:db:26 IRQ 61, 32 KB shared memory at 0xfeed0000, 32-bit access. input: Macintosh mouse button emulation as /class/input/input0 Macintosh CUDA driver v0.5 for Unified ADB. adb: starting probe task... mac_esp: io base at 0x50f10000 esp: using quick version esp: addr at 0x50f10000 SCSI ID 7 Clk 16MHz CCF=4 TOut 138 NCR53C9x(esp236) mac_esp: 1 esp controllers found scsi0 : ESP236 (NCR53C9x) osst :I: Tape driver with OnStream support version 0.99.4 osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $ Driver 'osst' needs updating - please use bus_type methods Driver 'sd' needs updating - please use bus_type methods SCSI Media Changer driver v0.25 Driver 'ch' needs updating - please use bus_type methods scsi 0:0:0:0: Direct-Access SEAGATE ST32550N 8607 PQ: 0 ANSI: 2 scsi1 : scsi_debug, version 1.81 [20070104], dev_size_mb=8, opts=0x0 scsi 1:0:0:0: Direct-Access Linux scsi_debug 0004 PQ: 0 ANSI: 5 adb devices: [2]: 2 8 [3]: 3 1 mice: PS/2 mouse device common for all mice TCP cubic registered ADB keyboard at 2, handler 1 Detected ADB keyboard, type ANSI. input: ADB keyboard as /class/input/input1 NET: Registered protocol family 1 NET: Registered protocol family 17 scsi: waiting for bus probes to complete ... ADB mouse at 3, handler set to 2 input: ADB mouse as /class/input/input2 adb: finished probe task... sd 0:0:0:0: [sda] 4194995 512-byte hardware sectors (2148 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08 sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA sd 0:0:0:0: [sda] 4194995 512-byte hardware sectors (2148 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08 sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 1:0:0:0: [sdb] 16384 512-byte hardware sectors (8 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 73 00 10 08 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA sd 1:0:0:0: [sdb] 16384 512-byte hardware sectors (8 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 73 00 10 08 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA sdb: unknown partition table sd 1:0:0:0: [sdb] Attached SCSI disk sd 1:0:0:0: Attached scsi generic sg1 type 0 kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. EXT3 FS on sda7, internal journal
More: Starting Points
There are several barriers to a Linux for Macintosh 68K port. The first of these is that Apple don't want other operating systems on their machines. Whereas you can learn almost all of the workings of a PC from books you will find almost nothing written on the Apple Macintosh. Sometimes the Macintosh specifications and tech notes fill in the blanks at other times its neccessary to apply a great deal of guesswork and experimentation to figure out the hardware.
The second barrier is a human barrier. Most Macintosh machines were not sold to the technical market, and the average Macintosh user isn't terribly interested in a 'real operating system' for their computer. There is nevertheless a sizeable technically oriented Macintosh user community and a lot of Macintosh hardware around (more probably than any other non Intel Linux platform). A further reason has been provided by Apple whose attitude to 68K machines now appears to be 'quaint, buy a new computer'.
The third barrier to a Linux port is less obvious and is hidden by the lack of documentation. Certain folks have speculated that embarrasment is the main reason for Apple Computer releasing so little documentation. The Macintosh platforms in general have positively stone age design features. For example the interrupt controllers on a Macintosh II are a pair of 6522 VIA chips, intended for use with the 8bit 6502 processor. Stupid hardware makes for poor performance unless carefully handled. The complete lack of DMA is even less helpful. Apple seem to think no DMA is a feature on most machines and actually have a technote 'I used to be a teenage DMA junkie' which attempts to justify their rather comical hardware design. Getting Started
So what do you need to get a port started. The first item is hardware. I had most of this (a 5Mbyte MacII cast off from the office as too slow for anything). Initially I felt safe in helping work out the directions for the Linux port as this system lacked an MMU and was therefore unable to run any proposed Linux port.
Rob Pelkey started on some very basic Linux work for the Macintosh but needed a boot loader to load the Linux OS and kick it off. On #linux on the LinuxNet IRC network Jes Sorensen, the keeper of Linux68K, I and several other random people got into a few discussions about the port and what would be required. After a lot of digging we managed to establish some basic information on the Macintosh68K and then fill further areas in by investigating the excellent detective work the OpenBSD/Mac team had done in getting BSD limping along on the Macintosh machines. Further information came to light from the Linux on OSF Mach port that Apple sponsored when we realised that Apple continued to use the same 8bit microcontrollers or emulations of them, and that Apple had not redesigned the systems materially for the new processor.
Everything seemed completely happy. I had a Macintosh box to laugh at (and we used it occasionally to fail to duplicate problems Macintosh users had with CymruNet), we could kick ideas around, and I had no MMU in my Macintosh so I couldn't possible help to write any code.
By this time Rob's effort had stalled badly as he lacked the time to write the boot loader needed to run Linux and was working on passing classes and other sundry items. No worry, someone would eventually take over the project or he would finish his classes. And then Frank Neuman sent me an MMU for the MacII and someone else donated a pair of ethernet cards. Whoops, sudden shortage of excuses.
Learning MacOS
Having fitted the MMU to the Macintosh without blowing it up I tried to get MacOS to run with virtual memory. This is supposed to be simple. You click on the memory tool and select 32bit, virtual memory on. Oh no, my memory control didn't have a 32bit option let alone a virtual memory one. I stared a bit, checked on a more modern mac downstairs to be sure I had the right screen. The other Mac which was running the same MacOS version had the required option, I didn't.
This is when I first learned the horrors of the Mac. While Unix says 'Im sorry you can't do that', MacOS has two error messages. It either goes 'eep?' or the box you wanted to set but couldn't is simply not there on you computer until you've installed the other 12 unidenfied items and filled in 3 apparently unrelated dialog boxes. This was an error of the latter category.
It turns out that Apple shipped the MacII with the ability to upgrade to include an MMU chip. Therefore they sensibly shipped it with a system ROM that wasn't capable of of running with the MMU enabled. Brilliant, just don't design anything mission criticial please. Fortunately Apple had concealed on their web site a small tool which patches the ROM entry points so that it can run in 32bit mode.
Ok so all you do is download the tool, install it and off you go. Not so simple. To get the program onto the machine I needed to get the ethernet to work. I ended up using kermit to transfer 700K of ethernet installer onto the Macintosh. About 4 hours of fighting with the completely alien Macintosh archiver tools I had the machine talking appletalk shares to a Linux box using netatalk and an insight into why Mac people meeting a PC for the first time look like they just discovered alien life forms.
About an hour after that I had figured out how to unpack Macbin files and the Macintosh was in 32bit mode and admitted the MMU was present and functional. Building and Booting Linux
The next stage in the operation was to figure out how to boot a Linux kernel image on the Macintosh. NetBSD and OpenBSD use a boot loader which loads a.out format executables into the memory of the Macintosh, shut the macintosh down, move them to address 0 and jumps to it. I rapidly decided I didn't want to write a boot loader. The OpenBSD loader was almost pure MacOS wizardry at a level far beyond my abilities. Not to worry, it soon became apparent that the OpenBSD loader could be persuaded to load Linux too. A true loader could wait.
The next problem was to build a Linux kernel image that would link and while probably not do anything useful at least serve as something to feed the OpenBSD booter. Linux is built using the GNU toolchain which supports the building of cross compilers. It is thus possible to compile and build 680x0 binaries on an ordinary intel based PC. It took a couple of builds to get gcc and the GNU binutils almost generating the right code. Linux-aout executables have a two byte different header to the OpenBSD ones and the the OpenBSD boot loader checked these bytes. Rather than rebuild the entire toolchain again I wrote a simple tool to fix the headers.
Most of Linux/M68K was quite content to build for a Macintosh target. I filled in everything that complained with dummy routines - for Mac keyboards, mice, display etc until it all compiled. Because of the well designed abstraction layers in the Linux/M68K kernel this is quite easy to do. I now had a completely useless do nothing Macintosh kernel that the OpenBSD loader would load, and which then promptly crashed the Macintosh as I expected.
The Linux/m68K project had faced up to the challenges of supporting multiple types of 680x0 based computer within the same port well before I got involved. As a result of the need to support both the Amiga and Atari systems there are clear layers of abstractions. Adding an additional m68k target consists mostly of filling in platform specific blank fields. A port to a completely new processor would have been far more challenging than this.
For the macintosh case I filled in various mostly blank function handlers. After finally getting the thing to link I ended up with a kernel that hardcoded for a 5Mbyte 68020 based macintosh with FPU and a display at 0xF9000000. It had no interrupt controllers, no disk controllers, no keyboard, no mouse and anything else I could find was also hard coded. But it linked and that was the important item. Having done a bit of reading up on the innards of the console drivers (and much interrogation of Jes) I wrote a fairly simplistic back end for the generic console driver on the Macintosh. As it turns out the very simplistic approach reflected the Macintosh hardware I had, which was a completely unaccelerated bitmapped display supporting 640x480 in 4bit colour. Paint It Black
A Linux 68K kernel starts with a partially shared piece of initialisation code written in 680x0 assembler and using almost all the most gothic and peculiar features of the architecture. This initialisation code also sets up the memory management and caching and touches everything nobody normally knows about. The 68020, 68851, 68881 combination of chips using in the Macintosh II is obsolete and Motorola therefore didn't carry documentation on this device. I knew two things which in theory were enough to debug and figure out what was going on. Firstly I knew the base address of the screen memory, secondly I knew the address that the code would begin executing. The very first routine I put in the startup code painted the screen a revolting blue colour. After about 15 boots and some staring at the source code I had a Macintosh that booted to a blue screen waited a short while and crashed.
In many way this was the single hardest item to get going. When you are dealing with a completely unknown system environment and have no idea what is around your code it is extremely tricky to debug. Real commercial hardware people use logical analysers. I didn't have the option. I learned several things in the process notably that the Macintosh screen memory isn't located where the hardware claims until you set up the MMU. I also made the amazing discovery that the rounded corners on the Macintosh display are drawn in software.
Over a period of the next few weeks the Macintosh went through an assortment of debugging stripes and coloured patterns as I inched a few lines at time through the initialisation assembler code, fixing it bit by bit and gradually mapping in the needed hardware. Eventually the kernel hit the magic start_kernel() function in the C code without crashing on the way. Consoling Yourself
Hitting start_kernel() is in theory the beginning of the easy road. On a PC at least you have text mode consoles instead of stripes, on a Macintosh hitting start_kernel() meant that the prospect of getting the kernel to initialise a text console and begin showing useful debugging information was close. Nothing could have been further from the truth.
After several attempts to get the console up I wrote some routines to print penguins and macs on the screen (this was easier than text). Each significant point the kernel reached added a penguin to the display and a failure point before the console came up printed a given number of burning macintosh logos. While hardly as good as print statements this was good enough to rapidly locate several bugs in the processing of options passed by the boot loader (little things like apparently having 0K of memory tend to upset the Linux memory initialisation). The code would get to the beginning of the console setup and die.
To get past this point I had to fill in support for the 4bit packed pixel displays that were used by the Apple Macintosh 'Toby' display card. The generic bitmapped console drivers for the 680x0 port supported a wide variety of pixel formats, and naturally excluded the one I needed.
Had I known at the time I could simply have switched the machine to Mono in the display preferences but at the time I didn't know the physically switched the card into a monochrome mode. Adding 4bit packed pixel wasn't too difficult. I left the somewhat scarier 2bit packed pixel support for later, in the hope someone else would have to write it not me. The console code is also very modular on the 680x0 and these console layers (abscon, fbcon) are now used by most non Intel ports. It's reasonable to assume that it will be driving all the ports by the 2.3 kernel series.
The machine still crashed mysteriously and all evidence pointed to a structure getting stamped on. I put guard values either side of it and checked they were not overwritten, I moved the structure in memory and I tried everything I could think of in order to stop it being apparently corrupted. No joy, no change. After a bit of head scratching I added code to check the values were ok at boot, and at initialisation of each subsystem. The value was wrong at the start of the C code. I checked it at the start of the assembler and it was wrong by then.
This was beginning to look worrying, it seemed that the boot loader was corrupting data, yet this made no sense as the loader would corrupt the same location, not pick on a specific helpless little variable wherever it may have been located. Eventually I used the GNU objdump tools to look at the binary I was loaded. It turned out that the GNU linker was at fault and in some places was loading a completely bogus address for a relocation.
A new linker and the magic words 'Calibrating Bogomips' appeared on the screen, followed by a hang, and there was much rejoicing. In many ways the time lost to the linker bug was not that bad. Eyeballing the code in search of the mystery bug I had fixed some twenty or thirty other serious bugs in a vain attempt to find the illusionary real bug.
I wasn't too worried the Bogomip calibration hung. It's very hard to calibrate time before the interrupt routines, especially the timer interrupt routines have been written. I commented it out and after a short while the rest of the code booted to the point of saying 'Panic:unable to mount root filesystem'. A reasonable situation as I had exactly no device support except the screen. Filling In The Blanks
Getting the machine to the point where everything appears to boot this far is actually by no means any kind of completion of the first steps of a porting project. It tends to be the point at which you finally appreciate the real problems and the scale of work remaining.
There are numerous pieces of hardware in an Apple Macintosh and while it is possible to ignore them trying to
get to the initial panic about the root filing system I was going to have to fill at least some of them in to go any further.
The most important items to fill in where those that dealt with the most basic system resources - interrupts, memory and the I/O busses. The interrupts and several I/O subsystems are handled by a pair of 6522 VIA chips, 8bit controllers from the stone age. These chips themselves are documented and their locations were known even if some of the connections to their I/O pins were a mystery. A certain amount of mapping work and other detective information showed that the VIA chips provided the all important system timer ticks, handled the keyboard at an extremely low (and at the time undeciphered) level, and provided interfaces for the external interrupts from the bus controllers.
Several other pins appear to do things like turn the Macintosh off. Even now we don't know what everything on the VIA chips does or if all the pins have a real use. It also turned out I got the easy end. The later Macintosh machines replace the second VIA with a device known as RBV (Ram Based Video) which contains a bad emulation of a VIA chip and various other components in one piece of glue logic.
Basic interrupt handling on a Macintosh is relatively clean. A great deal of attention has been paid to keeping interrupts that need a fast response at a higher priority that time consuming processes. That works well under MacOS but Linux itself tends to take rather too binary a view of interrupts especially in the drivers. Certain interrupts are wired in strange ways presumably to save components - the SCSI interrupt for example is wired through a VIA but is effectively upside down compared with the other interrupt sources. Apple saved an inverter by using the fact the VIA can handle either direction of state change as an interrupt signal.
I ended up with two layers of interrupt handling, which were mostly hard coded. Unlike a PC the Macintosh interrupts are very much hard wired. Only the Nubus (plug in) cards change positions, and they all share one interrupt which sets bits in a VIA register to indicate the real interrupt source.
Nubus proved quite entertaining. The documentation is quite weak and all written from the point of view of building a card for a Macintosh. It took about a week before the boot up code would scan and report a list of which nubus slots were occupied and the name of the devices. Once it worked the Nubus turned out to be an extremely well designed system with features much like PCI. Each slot is allocated a set of memory resources and can raise an interrupt. A ROM allows the OS to read each device for identification and driver information. The ROM also contains other "useful" data including icons for the device. At the moment these are not made visible under Linux, but the intention is to support /proc/nubus/[slot]/icon.xpm at some time. Mapping Ethernet Cards
The Daynaport card I had been given was very close to several PC designs. The 8390 ethernet chip and block of RAM on it made that quite clear. There are however 2^24 possible locations for the chip and memory within each Nubus slot space.
Finding where the device was hidden required building a collection of kernels which searched the 24bits of address space looking for two things. Firstly looking for areas of memory which could be read and written, secondly looking for areas like this which had the additional property of giving different results when read back. The 8390 chip has several control registers, and by playing with these it is possible to fairly reliably identify the chip (this same code is used to probe for NE2000 and WD80x3 cards in Linux for PC). On the Macintosh the RAM was easy to find but the 8390 did not show up.
Having played with the RAM behaviour a bit I discovered that the memory was mapped to every alternate 16bits in its address space. That is if you wanted to read it you had to read two bytes, skip two bytes, read two bytes etc. A bit of further experimentation revealed that the Ethernet controller registers occurred every fourth byte, that the RAM occurred every other pair of bytes and was 16bit wide and that the ethernet controller saw the 16bit wide memory as 8bit wide. Only on a Macinotsh...
These sort of techniques work for mapping a large number of devices and address spaces, and helped to discover the location of additional devices in the Apple I/O spaces. We still don't know enough to drive the Apple sound chip and the "Integrated Woz Machine" (floppy disk controller), but we do know where they are located. Rooting For NFS
When you need to start testing a system booting into user space you need a file system. The NFS root file system is extremely attractive for this and has been used for most ports. The NFS (Network File System) makes transaction requests at the level of files rather than disk blocks. This has the saving grace that errors in the new port cause transactions to get rejected. If you are trying to debug a new port and a SCSI controller driver at the same time you will instead spend much of your time reformatting and reinstalling the disk you are attempting to boot from. Using NFS bounds the possibility for errors and also makes it easier to add and edit files as you attempt to make the machine work.
The initial installs were done with a set of tar files for the m68k known as "watchtower". Watchtower is extremely outdated but is small and it was easy to unpack. Since the goal was getting a shell prompt the age of the binaries was not a serious worry. Watchtower also demonstrates another strength of Linux/m68k. All the ports run the same binaries. Instead of having to cross compile and debug all the binaries for the Macintosh I was unpacking and booting a file system set up for installation on a Commodore Amiga.
With a few modifications to the drivers and several small bugfixes to the kernel code the applications started to run. As most of the code you need to add for a new M68K platform is drivers and setup code once things started to work most applications sprang to life. It took a couple of tweaks to get floating point to always behave itself but once done I was able to boot the machine fully multi-user, but without keyboard, mouse or hard disk support.
It took almost a month before anyone else got the kernel to boot on their own machine. A lot of debugging removed some rather bad assumptions that had 'escaped' the code clean up and gradually other MacLinux 68K machines began to pop into being. This is an extremely important step for any project as it allows other people to contribute effectively. Michael Schmitz wrote the SCSI drivers and much of the keyboard and mouse support. He is now adding IDE. Numerous other people have tested and debugged the code on the many varieties of Macintosh, and even made it work on some.
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.
* Kolbjørn Barmen, for the gentoo-m68k packages * Finn Thain, for helping in mac-serial driver
No Thanks
* Steve Jobs - For refusing to provide any Mac68K documentation * Steve Jobs - For refusing to let anyone else pass on Mac 68K documentation * Steve Jobs - For refusing to provide NeXT documentation to the NeXT project * Steve Jobs - For refusing to let anyone else pass on NeXT cube documentation * Steve Jobs - For killing the Newton * Steve Jobs - For refusing to provide any documentation about the Newton to the Linux ARM project
About devtools
actually development tools can be inspired @
http://www.busybox.net/downloads/BusyBox.html
http://www.netbsd.org/ports/mac68k/
http://www.openbsd.org/mac68k.html
http://tinderbox.dev.gentoo.org/default-linux/m68k/
http://patch-tracking.debian.net/package/emile/0.10-1
http://amiga.nvg.org/mirrors/www.mac.linux-m68k.org/
"mainline" repository in EMILE
* Public clone url: git://gitorious.org/emile/mainline.git More info… You can clone this repository with the following command: git clone git://gitorious.org/emile/mainline.git * HTTP clone url: http://git.gitorious.org/emile/mainline.git More info… You can clone this repository with the following command: git clone http://git.gitorious.org/emile/mainline.git (note that cloning over HTTP is slightly slower, but useful if you're behind a firewall) * http://emile.sourceforge.net/index.php
info to be inspired
Debian m68k on a Mac LC 475 (xfile dated 4th Feb 2006, not confirmed)
I finally have an ethernet card for my LC! Time to install Linux <grin>. PDS Ethernet Card
Debian Linux took a long time to install. Not counting the time it took me to faff around with Penguin settings, Debian took over eight hours to install, not including installing the Mac OS! You will want to set aside a whole day for this one.
My LC 475 has only a single Conner 1 GB drive, so I knew I would have to partition this. When I installed System 7, I allocated a 500 MB partition, but it became apparent that 500 MB was far more than System 7 needed and far less than I would want for debian. I created a new 100 MB partition and transferred the System 7 installation to that, allocating the rest to Debian. If you don't have any unpartitioned space on your disk, you won't be able to do this juggling act and will have to reinstall System 7. Freshly installed, Debian took up 300 MB + 80 MB swap space, but you'll need more than this if you intend to install any software. System 7
Installing the ethernet card was a breeze, just pop out the blanking plate at the back and drop the card in. Tools required ; none. System 7 picked up the card right away, listing 'ethernet' as an available interface for AppleTalk in the Network control panel.
I was not able to get System 7 to talk to my OS X Tiger Macs, since it complains about an incompatible version of AppleTalk. Who'd have thought it? Fortunately, I have an FTP server I can use. Any OS X Mac can act as an FTP server.
In order to get a TCP/IP stack, I installed OpenTransport 1.1.1 (Disk 1, Disk 2, Disk 3, Disk 4). I also copied Fetch 3.0.3 over, it's an FTP client small enough to fit on an HD floppy.
Next, I downloaded the Penguin boot loader and uploaded it to my FTP server. I grabbed the Debian m68k businesscard image. The only files needed from this image are:
* kernels/vmlinuz-2.2.25-mac * nativehd/initrd22.gz
so I mounted the iso in OS X and uploaded just those files to the FTP server. I used Fetch to retrieve the files in System 7.
The Penguin is a loader for Linux that is launched from within the Mac OS. There is a boot loader called EMILE that can boot Linux natively, but I did not investigate this because I already had Penguin working when I found out about it! I would love to hear form anyone who has tips for getting EMILE working. Booting the Debian Installer
Penguin is easy to configure. Choose File -> Settings, then set vmlinuz-2.2.25-mac as the kernel file and initrd22.gz as the ram disk. I set the command line to be root=/dev/ram ramdisk_size=13000. I had to increase the ramdisk size so that the installer had enough room to boot, otherwise it gave an "attempt to access beyond end of device" error. Hit cmd+b to boot the installer. The Penguin HOW-TO is useful.
The Debian installer booted and asked me to choose a language, and how packages should be retrieved (I chose http). The installer used DHCP and configured the ethernet card automatically. Then came partitioning. I told it to use the partition at /dev/sda4 as an ext3 partition mounted on root, and the /dev/sda5 partition as swap space. I was asked whether the installer could unmount the partitions in order to make changes, I answered yes.
You will have a lot of time to fill while it installs the base system! My LC took about 4 hours 30 minutes. When the base system is installed, the Mac will reboot and load the Mac OS. Booting Debian Linux
To boot Debian and complete the installation, Penguin needs to be instructed to use the Linux partition as the root device. Choose file -> Settings and choose kernel-2.2.25-mac as the kernel again, but do NOT use a RAM disk. In my case, Debian's root partition is /dev/sda4 - the fourth partition of the first disk on the SCSI bus. The command line this time is just root=/dev/sda4.
When the Mac rebooted, it asked me about my timezone, to set the root password and to create a new ordinary user, nothing too surprising. I was prompted to select my APT mirror, I chose to get packages through http from the UK debian mirror. At this point I got a lot of console messages saying Unexpected IRQ 3 on Device 00000000, but it seemed to be working so I left it to get on with things for a few hours.
About 10 minutes before it finished installing, Debian asked me to configure my Mail Transport Agent. Since I already have a mail server, I chose to use that as a smarthost, but it would be safest to accept the defaults if you're unsure. Hurrah! It welcomed me to Debian and invited me to log in.
Once I was logged in, everything seemed to be working OK, except for that damn Unexpected IRQ 3 on Device 00000000 message popping up every so often. A little Googling showed that a couple of people got around this by disabling console logging:
$ su -
- 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
- dpkg-reconfigure xserver-xfree86
Still to do:
Get one of Christian T. Steigies' more recent kernels to boot.
See also Macintosh LC 475.
info about debian-m68k/X11 (not verified)
input from http://www.jagshouse.com/Linuxm68k.html
But Does It Run X Windows?
Sure!
Even On the SE/30????
Sure! You'll need at least 50 megs just for X Windows, 90 for the different varieties of X Windows. It runs rediculously slow on my SE/30, but it sure is cool to show it to my PeeCee co-workers! The downside of X Windows on this particular version of Linux is that you rarely use it except to launch programs, which you can do from the command line interface anyway. Yes, you get some cool screen savers and games (Doom, Abuse to name a few) but those won't run on the SE/30 anyway. Well, they WILL run, but they will be SOOOOO SLOOOOOW that you could make a cup of coffee in between each screen redraw. I finally stopped loading X Windows on my SE/30 because I can surf the net, terminal into my Mac Plus and do text editing, and programming without X Windows.
X Windows Hidden Gotcha
In this particular version of Debian (2.1 or Slink), there are a couple of goofs on the installer. If you are trying to get X Windows going, you will find that it won't work unless you move some files around and change some settings. Because this version is m68k which means it runs on the Motorola 68xxx chip, there are many different platforms it will run on besides Macs such as Amiga, HMV, Atari and maybe a few others.
First, after reading the readme files, when you are setting up Debian after you install it, you'll need to go to
/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
http://www.jagshouse.com/68kfaq.html
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
About devtools
actually development tools can be inspired @
http://www.busybox.net/downloads/BusyBox.html
http://www.netbsd.org/ports/mac68k/
http://www.openbsd.org/mac68k.html
http://tinderbox.dev.gentoo.org/default-linux/m68k/
http://patch-tracking.debian.net/package/emile/0.10-1
http://amiga.nvg.org/mirrors/www.mac.linux-m68k.org/
"mainline" repository in EMILE
* Public clone url: git://gitorious.org/emile/mainline.git More info… You can clone this repository with the following command: git clone git://gitorious.org/emile/mainline.git * HTTP clone url: http://git.gitorious.org/emile/mainline.git More info… You can clone this repository with the following command: git clone http://git.gitorious.org/emile/mainline.git (note that cloning over HTTP is slightly slower, but useful if you're behind a firewall) * http://emile.sourceforge.net/index.php