Debian does not impose hardware requirements beyond the requirements of the Linux kernel and the GNU tool-sets. Therefore, any architecture or platform to which the Linux kernel, libc, gcc, etc. have been ported, and for which a Debian port exists, can run Debian. Please refer to the Ports pages at http://www.debian.org/ports/sparc/ for more details on SPARC architecture systems which have been tested with Debian.
Rather than attempting to describe all the different hardware configurations which are supported for SPARC, this section contains general information and pointers to where additional information can be found.
Debian 3.1 supports eleven major architectures and several variations of each architecture known as “flavors”.
| Architecture | Debian Designation | Subarchitecture | Flavor |
|---|---|---|---|
| Intel x86-based | i386 | vanilla | |
| speakup | |||
| linux26 | |||
| Motorola 680x0 | m68k | Atari | atari |
| Amiga | amiga | ||
| 68k Macintosh | mac | ||
| VME | bvme6000 | ||
| mvme147 | |||
| mvme16x | |||
| DEC Alpha | alpha | ||
| Sun SPARC | sparc | sun4cdm | |
| sun4u | |||
| ARM and StrongARM | arm | netwinder | |
| riscpc | |||
| shark | |||
| lart | |||
| IBM/Motorola PowerPC | powerpc | CHRP | chrp |
| PowerMac | pmac | ||
| PReP | prep | ||
| APUS | apus | ||
| HP PA-RISC | hppa | PA-RISC 1.1 | 32 |
| PA-RISC 2.0 | 64 | ||
| Intel ia64-based | ia64 | ||
| MIPS (big endian) | mips | SGI Indy/Indigo 2 | r4k-ip22 |
| r5k-ip22 | |||
| Broadcom BCM91250A (SWARM) | sb1-swarm-bn | ||
| MIPS (little endian) | mipsel | Cobalt | cobalt |
| DECstation | r4k-kn04 | ||
| r3k-kn02 | |||
| Broadcom BCM91250A (SWARM) | sb1-swarm-bn | ||
| IBM S/390 | s390 | IPL from VM-reader and DASD | generic |
| IPL from tape | tape |
This document covers installation for the SPARC architecture. If you are looking for information on any of the other Debian-supported architectures take a look at the Debian-Ports pages.
Currently the sparc port supports several types of Sparc systems. The most common identifiers for Sparc systems are sun4, sun4c, sun4m, sun4d and sun4u. Currently we do not support very old sun4 hardware. However, the other systems are supported. Sun4d has been tested the least of these, so expect possible problems with regard to the kernel stability. Sun4c and Sun4m, the most common of the older Sparc hardware, includes such systems as SparcStation 1, 1+, IPC, IPX and the SparcStation LX, 5, 10, and 20, respectively. The UltraSPARC class systems fall under the sun4u identifier, and are supported using the sun4u set of install images. Some systems that fall under these supported identifiers are known to not be supported. Known unsupported systems are the AP1000 multicomputer and the Tadpole Sparcbook 1. See the Linux for SPARCProcessors FAQ for complete information.
Some older Sun workstations, notably the Sun IPX and Sun IPC have memory banks located at fixed locations in physical memory. Thus if the banks are not filled gaps will exist in the physical memory space. The Linux installation requires a contiguous memory block into which to load the kernel and the initial RAMdisk. If this is not available a “Data Access Exception” will result.
Thus you must configure the memory so that the lowest memory block is contiguous for at least 8Mb. In the IPX and IPC cited above, memory banks are mapped in at 16Mb boundaries. In effect this means that you must have a sufficiently large SIMM in bank zero to hold the kernel and RAMdisk. In this case 4Mb is not sufficient.
Example: In a Sun IPX you have a 16Mb SIMM and a 4Mb SIMM. There are four SIMM banks (0,1,2,3). [Bank zero is that furthest away from the SBUS connectors]. You must therefore install the 16Mb SIMM in bank 0; it is then recommended to install the 4Mb SIMM in bank 2.
Especially in the case of older Sun workstations, it is very common for there to be an onboard framebuffer which has been superseded (for example the bwtwo on a sun IPC), and an SBUS card containing a later probably accelerated buffer is then plugged in to an SBUS slot. Under Solaris/SunOS this causes no problems because both cards are initialized.
However with Linux this can cause a problem, in that the boot PROM monitor may display its output on this additional card; however the linux kernel boot messages may then be directed to the original on board framebuffer, leaving no error messages on the screen, with the machine apparently stuck loading the RAMdisk.
To avoid this problem, connect the monitor (if required) to the video card in the lowest numbered SBUS slot (on motherboard card counts as below external slots). Alternatively it is possible to use a serial console.
Debian's support for graphical interfaces is determined by the underlying support found in XFree86's X11 system. Most AGP, PCI and PCIe video cards work under XFree86. Details on supported graphics buses, cards, monitors, and pointing devices can be found at http://www.xfree86.org/. Debian 3.1 ships with XFree86 version 4.3.0.
Multi-processor support — also called “symmetric multi-processing” or SMP — is supported for this architecture. However, the standard Debian 3.1 kernel image does not support SMP. This should not prevent installation, since the standard, non-SMP kernel should boot on SMP systems; the kernel will simply use the first CPU.
In order to take advantage of multiple processors, you'll have to replace the standard Debian kernel. You can find a discussion of how to do this in Section 8.4, “Compiling a New Kernel”. At this time (kernel version 2.4.27) the way you enable SMP is to select “Symmetric multi-processing support” in the “General setup” section of the kernel config.