Linux: It's Not Just for Intel Anymore

More hardware-dependent device drivers are needed. The Kernel Hackers Guide needs to be updated for the 680x0 with special emphasis on memory management.

Linux/68k runs a beta-quality 680x0 Linux kernel on two makers' platforms, a number of file systems, shells, and some utilities. There is no X-windowing yet, though work on it is progressing. Full native development is possible using the specially contributed tools.

The Amiga and the Atari ports were merged so successfully that the same kernel image (the vmlinux from tsx-11) runs on both machines. Another advantage of this is that all user program binaries should work on any machine running Linux/68k if only hardware-independent devices are used. These devices include ramdisk, mem, pty, tty, vt, slip, net/inet, and general SCSI stuff. These file systems have been ported: minix, ext2, msdos, proc, isofs, nfs.

linux-alpha@vger.rutgers.edu To subscribe, send mail to: majordomo@vger.rutgers.edu

linux-axp@amt.tay1.dec.com To subscribe, send mail to: linux-axp-request@amt.tay1.dec.com

If you have an Alpha-based PC-class system running OSF/1 (e.g. DEC 2000) you can use the same system for development and test bed. Otherwise, you will need two systems.

The development system can be any system that can support the Linux/Alpha cross-development tools. The cross tools have been successfully built and tested on the following systems:

The Linux/Alpha Software Developers' Kit is the first public release of Linux operating system components for Digital's Alpha family of microprocessors.

The SDK is available via anonymous FTP [see above]. I STRONGLY suggest that you first download the files README and SDK_CONTENTS and read them before downloading anything else (hint: you do NOT need to download all 55Mb in that directory!)

The Linux/Alpha SDK is NOT a fully-functional Linux distribution. The documentation is EXTREMELY sketchy and is mainly in the form of back-of-the-envelope notes. Linux/Alpha is not self-hosting; one must cross-compile the kernel and utilities on another system using the available cross-development tools. The kernel is extremely fragile, and several important code paths have not been tested yet. Very few utilities are available; you can bring the system up to a shell prompt, but you can't do much of anything else yet. Device driver support is minimal; currently, we support console-callback device drivers, but these are EXTREMELY slow (console-callback drivers are the Alpha equivalent of BIOS drivers on Intel systems). We have ported three sample drivers so far for the DEC 2000 AXP system: keyboard, text-mode VGA, and Adaptec 1742 SCSI.

In other words, Linux/Alpha is currently in a state that only a kernel hacker could love. If that describes you, then by all means download the SDK and give it a try!

linux-mips@vger.rutgers.edu to subscribe, send mail to majordomo@vger.rutgers.edu

linux-activists channel “mips”. To subscribe, e-mail linux-activists-request@niksula.hut.fi with “X-Mn-Admin: join mips” as the first and only line.

From the FAQ:

Andy Busse comments:

Right now, I have my test box do the following: 1) Print boot-up messages, 2) Determine the machine type (sun4c, sun4m, sun4d, etc.), 3) Determine the available physical memory on the machine and other types of information, 4) Probe the OpenBoot PROM for devices that are on the machine. The PROM is a real win here.5) BogoMIPS, the most important part of the port! This SUN 4/20 gives 17.94 BogoMIPS. 6) Completely map the kernel's virtual pages. 7) Enable and flush the Virtual Address Cache.

I have a lot of the architecture-dependent include/asm-sparc files written and am able to `make config; make dep; make clean' on the tree. A lot of the file system code can be compiled. Getting it to work is another story.

The current work on the Sparc port of Linux is aimed at the sun4c machines which are based on Version 7 of the Sparc architecture. The main difference (between machine types) is that the MMU's are accessed in a different fashion in V8 and onward. Fortunately, Version 8 memory management (for sun4m) is defined by the V8 manual “The Sparc Reference MMU”. I am attempting to make sun4m support easy to just plug in later. Yes, this means multi-processor support and all that entails. Although no such machines will exist before mid `95, I am doing some of my code with the Version 9 Sparc in mind: better prepared than not.

I have been trying to coordinate my code with Linus such that we don't buck heads in the kernel tree, so to speak. Eric Youngdale and Linus have been extremely helpful in deciding how best to integrate my memory-management code into the current tree.

A documentation specialist is needed. Knowledge of the Linux Documentation Project, SGML, HTML, TeX, LaTeX, and desire to learn literate programming with “noweb” are required.

Volunteers having PC-class RS6000 machines or IBM PowerPersonal PCs are needed for boot and kernel testing and to write or port device drivers.

The Apple PowerMac porters mostly have a cross-development environment (not freeware). Access to the Mac's ADB internal bus specifications appears imminent, as Apple now seems willing to release the information under certain conditions.

With the addition to the project of some Motorola PowerStacks (on order) and their soon-to-be owners at year end, `94, the PowerStack part of the Linux/PowerPC port is beginning to come together. A GNU cross-development tool set, targeted at the PPC, has been started.

Many thanks go to Northwest Nexus (info@halcyon.com) for supporting the Linux/PowerPC Project by providing the author's net access. Thanks also to MicroApl Ltd. (London, UK (MicroAPL@microapl.demon.co.uk )), makers of PortAsm assembler source translators, for their contribution.