En ce qui concerne le matériel, Debian n'a pas plus d'exigences que le noyau Linux et les outils GNU. Par conséquent, toute architecture ou plateforme, sur laquelle le noyau Linux, la libc, le compilateur gcc, etc. ont été portés, et pour laquelle un portage de Debian existe, peuvent faire fonctionner Debian. Reportez-vous aux pages sur les portages http://www.debian.org/ports/sparc/ pour plus de précisions concernant les systèmes d'architecture SPARC qui ont été testés avec Debian.
Plutôt que d'essayer de décrire les différentes configurations matérielles acceptées par SPARC, cette section contient des informations générales et des pointeurs vers des informations complémentaires.
Debian 5.0 fonctionne sur onze architectures principales et sur de nombreuses variantes de celles-ci, appelées « saveurs ».
| Architecture | Étiquette Debian | Sous-Architecture | Saveur |
|---|---|---|---|
| Intel x86-based | i386 | ||
| AMD64 & Intel EM64T | amd64 | ||
| DEC Alpha | alpha | ||
| ARM | arm | Netwinder et CATS | netwinder |
| armel | Versatile | versatile | |
| arm et armel | Intel IOP32x | iop32x | |
| Intel IXP4xx | ixp4xx | ||
| Marvell Orion | orion5x | ||
| HP PA-RISC | hppa | PA-RISC 1.1 | 32 |
| PA-RISC 2.0 | 64 | ||
| Intel IA-64 | ia64 | ||
| MIPS (grand boutien) | mips | SGI IP22 (Indy/Indigo 2) | r4k-ip22 |
| SGI IP32 (O2) | r5k-ip32 | ||
| MIPS Malta (32 bit) | 4kc-malta | ||
| MIPS Malta (64 bit) | 5kc-malta | ||
| Broadcom BCM91250A (SWARM) | sb1-bcm91250a | ||
| Broadcom BCM91480B (BigSur) | sb1a-bcm91480b | ||
| MIPS (petit boutien) | mipsel | Cobalt | cobalt |
| MIPS Malta (32 bit) | 4kc-malta | ||
| MIPS Malta (64 bit) | 5kc-malta | ||
| Broadcom BCM91250A (SWARM) | sb1-bcm91250a | ||
| Broadcom BCM91480B (BigSur) | sb1a-bcm91480b | ||
| IBM/Motorola PowerPC | powerpc | PowerMac | pmac |
| PReP | prep | ||
| Sun SPARC | sparc | sun4u | sparc64 |
| sun4v | |||
| IBM S/390 | s390 | IPL avec VM-reader et DASD | generic |
| IPL avec bande | bande |
Ce document décrit l'installation pour l'architecture SPARC. Des versions pour les autres architectures disponibles existent sur les pages Debian-Ports.
Le matériel Sparc comprend nombre de sous-architectures différentes, identifiées comme suit : sun4, sun4c, sun4d, sun4m, sun4u ou sun4v. La liste suivante indique les machines qui correspondent à ces architectures et dans quelle mesure elles sont gérées par Debian.
Aucune de ces sous-architectures 32 bits (sparc32)n'est gérée. La page SPARCstation de Wikipedia donne la liste de toutes les machines concernées.
Etch est la dernière version de Debian qui gère sparc32, et seulement les systèmes sun4m. Les autres sous-architectures 32 bits avaient été abandonnées lors de précédentes versions.
Cette architecture comprend toutes les machines 64 bits (sparc64) basées sur le processeur UltraSparc et ses clones. La plupart de ces machines sont bien gérées même si vous pouvez rencontrer des problèmes lors de l'amorçage à partir d'un cédérom à cause de bogues dans le firmware ou dans le programme d'amorçage (on peut contourner ce problème en amorçant sur le réseau). Utilisez les noyaux sparc64 ou sparc64-smp selon que la machine possède un ou plusieurs processeurs.
C'est la plus récente architecture de la famille Sparc. Elle comprend des machines basées sur les processeurs Niagara à plusieurs coeurs. Pour l'instant ces processeurs ne sont disponibles que sur les serveurs T1000 et T2000 de Sun. Ils sont correctement gérés. Utilisez le noyau sparc64-smp
Notez que les processeurs SPARC64 de Fujitsu utilisés dans la famille de serveurs PRIMEPOWER ne sont pas reconnus car ils ne sont pas gérés par le noyau Linux.
Debian reconnaît les interfaces graphiques dans la mesure où elles sont reconnues par le système X11 de X.Org. La plupart des cartes AGP, PCI et PCIe fonctionnent sous X.Org. Des précisions sur les bus graphiques acceptés, les cartes, les moniteurs et les souris sont disponibles sur http://xorg.freedesktop.org/. Debian 5.0 est fourni avec la version 7.3 de X.Org.
La plupart des options graphiques communes des machines basées sur Sparc sont
gérées. Les pilotes de X.org sont disponibles pour sunbw2, suncg14, suncg3, suncg6,
sunleo et suntcx framebuffers, les cartes Creator3D et Elite3D (sunffb driver),
les cartes ATI PGX24/PGX64 (ati driver), et les cartes PermediaII (glint driver).
Pour utiliser une carte Elite3D avec X.org vous devez aussi installer le paquet
afbinit et lire la documentation pour savoir comment activer
la carte.
Il n'est pas exceptionnel qu'une machine Sparc possède deux cartes graphiques en configuration normale. Il se peut alors que le noyau Linux ne dirige pas la sortie vidéo vers la carte utilisée par le microprogramme. L'absence de sortie vidéo sur la console graphique peut être confondue avec un arrêt (habituellement le dernier message vu sur la console est « Booting Linux... »). Une solution possible est d'enlever l'une des cartes vidéo. Une autre solution est de désactiver l'une des cartes avec un paramètre passé au noyau. Quand la sortie vidéo n'est pas nécessaire ou souhaitée, on peut utiliser une console série. Sur certains systèmes, on peut activer automatiquement la console série en déconnectant le clavier avant d'amorcer le système.
Toute carte réseau (NIC, network interface card) reconnue par le noyau Linux devrait aussi être reconnue par l'installateur. Les pilotes réseau sont chargés sous forme de module.
Beaucoup de cartes PCI génériques sont reconnues, ainsi que les cartes SUN suivantes :
Sun LANCE
Sun Happy Meal
Sun BigMAC
Sun QuadEthernet
MyriCOM Gigabit Ethernet
Quelques cartes réseau spéciales posent des problèmes qui méritent d'être mentionnés.
Certaines cartes PCI ont la même identité mais sont gérées par des pilotes
différents. Certaines sont gérées par le pilote tulip et d'autres
par le pilote dfme. Comme elles ont la même identité, le noyau
ne les distingue pas et peut charger le mauvais pilote.
C'est un problème connu sur les systèmes Netra avec une carte Davicom (DEC-Tulip).
Dans ce cas le pilote tulip est correct.
Pour éviter ce problème, il faut mettre le module défectueux sur liste noire.
Voyez Section 5.3.1.3, « Interdire des modules du noyau ».
Pendant l'installation, la solution est de passer sur un shell et de supprimer
le mauvais pilote (ou les deux, si les deux sont chargés) avec
modprobe -r .
Ensuite il suffit de charger le bon pilote avec
modulemodprobe .
Il se peut malgré tout que le mauvais module soit chargé quand le système
est redemarré.
module