Plusieurs machines sont utilisables avec un nombre différent d'options CPU dont pas tous sont actuellement supporté. S'il vous plait, regardez la section "Type de processeurs" pour être sur que votre type de CPU soit supporté. C'est une liste de machines qui font fonctionner Linux/MIPS, des systèmes où Linux/MIPS peut être porté ou bien des systèmes que les gens ont intérêt à faire fonctionner avec Linux/MIPS.
L'Acer PICA est dérivé de l'architecture Mips Magnum 4000. Il a un CPU R4400PC fonctionnant à 133 Mhz ou optionnellement à 150 Mhz, plus une mémoire cache de second niveau de 512 Kb (optionnellement 2 Mb) ; la carte gfx G364 du Magnum a été remplacé par une carte S3 968 basée sur celui-ci. Le système est supporté à l'exception du serveur X.
Les séries Baget incluent plusieurs boîtes qui possèdent des processeurs R3000 : Baget 23, Baget 63 et Baget 83. Les Baget 23 et 63 ont une carte mère BT23-201 ou BT23-202 avec respectivement un R3500A (qui est un composant R3000A simplifié) à 25 MHz et un R3081E à 50 MHz.
La carte BT23-201 a un bus VME et comporte les puces VIC068, VAC068 comme contrôleurs systèmes. La carte BT23-202 a un bus interne PCI et un bus externe VME. Le support pour la carte BT23-201 a été faite par Gleb Raiko ( rajko@mech.math.msu.su) et Vladimir Roganov ( vroganov@msiu.ru) avec un petite aide de Serguei Zimin ( zimin@msiu.ru). Le support pour la BT23-202 est en train d'être développé avec le Baget 23B qui est composé de 3 cartes BT23-201 avec un bus VME partagé.
Le Baget 83 est mentionné ici uniquement pour être complet. Il a seulement 2 Mb de RAM et c'est trop peu pour faire fonctionner Linux. Le code du Baget/MIPS a été fusionné avec le port DECstation ; les sources pour les deux plates-formes sont à l'adresse decstation.unix-arg.org.
Les séries de produits Cobalt Qube sont des systèmes de serveur de faible coût basés sur un IDT R5230. Cobalt a développé sa propre variante de Linux/MIPS pour s'adapter aussi bien que possible aux besoins particuliers de Qube. Au départ le noyau Qube a été dérivé à partir de Linux/MIPS 2.1.56, reporté ensuite vers la version 2.0.30 par égard à la stabilité, puis optimisé. Les noyaux Cobalt sont téléchargeable à partir du site ftp www.cobaltnet.com. Le support Cobalt Qube n'a jamais été intégré dans les noyaux officiels Linux/MIPS 2.1.x.
Le Netpower 100 est apparemment un Acer PICA déguisé. Il devrait, par conséquent, être supporté mais ce n'a pas été testé. Si un problème apparaît alors, c'est probablement la détection de la machine.
La Nintendo 64 est une console de jeux basée sur le R4300 avec 4 Mb de RAM. Ses puces graphiques ont été développé par Silicon Graphics pour Nintendo. En ce moment, ce portage est encore un rêve et il continuera de l'être jusqu'à ce que Nintendo décide de publier les informations techniques nécessaires. La question qui reste est de savoir si c'est une bonne idée.
L'indy est (principalement), en ce moment, la seule machine de Silicon Graphics supporté. L'unique carte graphique supportée est la carte Newport aka "XL" graphique. L'indy existe avec un grand nombre d'options de CPU à des taux d'horloge variables, tous sont supportés. Il n' y a, pour l'instant, aucun serveur X possible pour l'indy ; Alan Cox ( alan@lxorguk.ukuu.org.uk) est en train de travailler sur l'une d'entre elles.
Au démarrage, le noyau sur l'Indy rapportera la mémoire possible avec un message du type :
27976k/163372k available (1220k kernel code, 2324k data)
La grosse différence entre la première paire de nombres est du à l'aire de 128 Mb dans l'espace d'adressage de la mémoire de l'Indy qui reflète les 128 premiers Mb de la mémoire. La différence entre les 2 nombres sera toujours proche de 128 Mb et n'indique pas un quelconque problème.
Plusieurs personnes ont rapporté l'existence de ces problèmes avec leur machine après les avoir mis à jour typiquement à partir de parts en excédent. Il y a plusieurs versions possibles de PROM pour l'Indy. Les machines, dotées d'une version d'une vieille PROM, et qui ont été mis à jour vers une variante d'un très récent CPU comme un module R4600SC ou R5000SC peuvent se cracher pendant l'auto_test avec un message du type :
Exception: < vector=Normal>
Status register: 0x30004803< CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x4000< CE=0,IP7,EXC=INT>
Exception PC: 0xbfc0b598
Interrupt exception
CPU Parity Error Interrupt
Local I/O interrupt register 1: 0x80 < VR/GIO2>
CPU parity error register: 0x80b< B0,B1,B3,SYSAD_PAR>
CPU parity error: address: 0x1fc0b598
NESTED EXCEPTION #1 at EPC: 9fc3df00; first exception at PC: bfc0b598
Dans ce cas, vous devrait mettre à jour votre PROM de la machine vers une version plus récente ou retourner vers un version du CPU plus vieille. Habituellement les modules R4000SC ou R4400SC devrait fonctionner dans ce cas-là. Juste pour être bien clair, ceci est un problème qui n'a pas de rapport avec Linux. Ceci est mentionné ici uniquement parce que plusieurs utilisateurs de Linux ont posé des questions à propos de ça.
Les vieilles versions de PROM ne reconnaissent pas le format binaire ELF utilisé par le noyau de Linux, ce qui empêche de booter directement sur Linux. La solution préférable pour ça, est, évidemment, une mise à jour de la PROM. Une autre possibilité est d'utiliser Sash d'IRIX 5 ou une version plus récente pour booter le noyau. Sash sait comment charger les binaires ELF et ne fait pas attention si c'est un noyau IRIX ou Linux. Tapez simplement ``Sash'' sur l'écran de la prom. Vous devriez obtenir un autre prompt shell, cette fois à partir de Sash. Maintenant lancer Linux comme d'habitude.
Sash peut lire les systèmes de fichiers EFS et XFS, ou lire le noyau à partir du bootp / tftp. Ce qui veut dire que si vous tentez d'utiliser Sash pour booter le noyau d'un disque local, vous devrez encore avoir une installation minimal d'IRIX sur votre système.
Au démarrage, le message `Memory: ...' sur un Indy dit qu'il y a 128 Mb de RAM réservé. Ceci est ok ; exactement comme l'architecture PC qui possède un interval dans son espace de mémoire de 640 Kb à 1024 Kb, l'Indy posséde une aire de taille 128 Mb dans sa place mémoire où les 128 premiers Mb de sa mémoire sont reflétés. Linux connaît ce problème et donc ignore cette partie de mémoire, ainsi que le message.
Cette machine est très similaire à l'Indy ; la différence est qu'il n'a pas de clavier et de carte GFX mais possède un adaptateur SCSI additionnelle basé sur le WD33C95. Cet adaptateur hôte n'est pas encore supporté.
Cette machine est uniquement mentionné ici car, occasionnellement, des gens le confonde avec un Indy. La série Indigo a pourtant une architecture différente et par conséquent n'est pas encore implémenté. Andrew R. Baker ( andrewb@uab.edu) a annoncé un projet universitaire pour porter Linux vers l'Indigo à partir du 2 janvier 1999.
Vérifiez que le noyau que vous êtes en train d'utiliser inclus le driver approprié pour une interface et une console série. Mettez la variable d'environnement de la console ARC soit à la valeur d1 soit à d2 pour l'Indy et le Challenge S par rapport à l'interface série que vous utilisez comme console.
Si vous avez le problème qui affiche tous les messages du noyau sur la console série lors du démarrage alors que tout est manquant lorsque l'initialisation débute, alors vous avez probablement le mauvais setup pour /dev/console. Vous pouvez trouver plus d'informations à propos de cela dans la documentation du source du noyau Linux ; il est dans /usr/src/linux/Documentation/serial-console.txt. Si le source du noyau est installé.
Il y a de très vieilles machines, sûrement de plus de 10 ans à l'heure qu'il est. Comme ces machines ne sont pas basées sur les processeurs MIPS, ce document n'est pas le meilleur moyen pour chercher des informations. Cependant, dans le but de rendre les choses plus simples, ces machines ne sont pas courrament supporté.
Celui-ci est actuellement un système basé sur l'architecture x86, par conséquent pas couvert par cette FAQ. Mais pour fournir des réponses simples à votre recherche, voila : Ken Klingman ( kck@mailbox.esd.sgi.com) a posté le 17 janvier 1999 dans la liste électronique Linux de SGI :
Nous somme en train de travailler dessus. Nous sommes actuellement tout près de fournir un support système de bas niveau dans la release 2.2. Les logiciels uniquement sous X et OpenGl devrait suivre relativement vite, mais le matériel accéléré pour OpenGL est encore remis. Allez à www.precisioninsight.com pour des nouvelles à propos du matériel accéléré pour OpenGL.
Pour plus d'informations, lisez la documentation du noyau Linux à partir des versions 2.2.0. Il y a des informations additionnelles possibles sur le web à www.linux.sgi.com/intel/. Notez que les gens de SGI/MIPS et SGI/Intel travaille indépendamment les uns des autres, par conséquent les sources dans le CVS anonyme sur linux.linux.sgi.com peut ou ne peut pas fonctionner sur les machines Intel ; nous ne testons pas ça.
Aujourd'hui, aucune autre machine de Silicon Graphics n'est supporté. Ceci s'applique aussi aux très vieux système basés sur le Motorola 68k.
La station de jeux Sony est basé sur un R3000 dérivé et utilise un ensemble de composants graphiques développé par Sony lui-même. Alors que la machine, en théorie, devrait être capable de faire fonctionner Linux, un portage est difficile puisque jusqu'ici Sony n'a pas fournis les informations technique nécessaire. Ceci laisse encore la question de l'utilité d'un portage sans réponses. Donc, pour résumer, rien n'a encore été ajouté bien que, jusqu'ici, énormément de personne aient montré leur intérêt pour l'utilisation de Linux sur une station de jeux.
A l'opposé du RM200 (voir plu bas), cette machine possède des slots EISA et PCI. Le RM200 est supporté à l'exception de la possibilité du contrôleur SCSI sur carte NCR53c810A.
Si votre machine possède à la fois les slots EISA et PCI, alors c'est un RM200C ; s'il vous plaît voyez juste au-dessus. A cause des légères différences architecturales, cette machine n'est pas supporté en ce moment dans les sources officiels. Michael Engel ( engel@numerik.math.uni-siegen.de) s'est débrouillé pour rendre son RM200 utilisable partiellement mais les patches ne sont pas encore inclues dans les sources officiels du Linux/MIPS.
Le RM300 est techniquement très similaire au RM200C. Il devrait être supporté par le noyau Linux courant, mais nous n'avons reçus aucun rapport.
Le RM400 n'est pas supporté.
Le port P4032 fonctionne toujours, au moment de l'écriture de ce manuel, avec le noyau Linux 2.1.36.
Le P5064 est simplement une variante 64 bits du P4032 basé sur le R5000. Il n'est pas encore supporté mais un port Linux sera prêt bientôt.
Le support pour les stations DEC est en cours de développement, Paul M. Antoine l'ayant débuté. Aujourd'hui la plus part du travail est fait par Harald Koerfgen ( harald.koergfgen@netcologne.de) et d'autres personnes. Sur l'InterNet, des informations en rapport aux stations DEC peuvent être trouvé à http://decstation.unix-ag.org/. Le but est de supporter tous les différents parfums des stations DEC qui existent.
Voici la liste des modèles des stations DEC que nous connaissons :
Le 2100 possède un processeur R2000A/R2010A à 12 MHz, le 5000/240 un processeur à 40 MHz (Qu'est-ce-qu'avait le 5k/260 ?) et le 5100 un processeur R3000A à 20 MHz. Les autres 5000 mentionné ont un processeur R3000A/R3010A à 20, 25, ou 33 MHz. Le MAXine et le 3MIN ont le processeur et le cache sur une carte fille séparé qui peuvent être échangé avec un processeur R4000 à 50 MHz.
Au moment de cette rédaction, les drivers des matériels séries et Ethernet pour les IC qui sont sur la carte ont été développé, la 3MIN boot en simple utilisateur.
Ces deux machines sont presque complètement identique. Revenons sur l'initiative d'ACE, Olivetti a breveté le projet Jazz et distribué la machine avec Windows NT comme OS. MIPS Computers Systems, Inc. ont acheté eux-mêmes le projet Jazz et l'ont distribué en tant que séries de machine MIPS Magnum 4000. Les systèmes Magnum 4000 sont distribués avec les systèmes d'exploitation Windows NT et RISC/OS.
Les caractéristiques matériels de la machine dépendait du systèmes d'exploitation qui était installé. Linux/MIPS supporte uniquement la caractéristique "little endian" sur ces deux types de machines. Depuis que le M700-10 est uniquement distribué comme une machine NT, tous les machines M700-10 ont cette caractéristiques d'installées. Le cas du MIPS Magnum est quelque peu plus complexe. Si votre machine a été configuré en "big endian" pour RISC/OS alors vous avez besoin de recharger la caractéristique "little endian". Cette caractéristique a été à l'origine incluse sur une disquette avec chaque Magnum. Si vous n'avez pas la moindre disquette, vous pouvez la télécharger via le ftp anonyme à ftp.fnet.fr.
Il est possible de reconfigurer le M700 pour des opérations en positionnant les variables d'environnement "ConsoleIn" et "ConsoleOut" du matériel à multi()serial(0)term(). Puis essayez la commande "listdev" qui montrera les matériels ARC possibles.
Dans bien des cas, comme lorsque la carte graphique G364 est manquante mais où la console est toujours configuré pour utiliser un mode graphique normal, il sera nécessaire de configurer le jumper JP2 sur la carte. Après le prochain reset, la machine rebootera avec la console sur le COM2.
Le MIPS Magnum 4000SC est le même que le Magnum 4000 (voir plus bas) à l'exception qu'il utilise un CPU R4000SC.
Comme le nom l'indique déjà, cette machine est un membre de la famille VAX de Digital Equipment. Il est mentionné ici car beaucoup de personne le confonde souvent avec les MIPS de Digital basé sur la famille des stations DEC à cause de leur numérotation semblable. Ces deux familles d'architecture partagent de petites similitudes techniques. Malheureusement, la VaxStation, comme toutes la famille des VAX, n'est pas supporté.
Le R2000 est le processeur MIPS originel. C'est un processeur 32 bits qui avait une horloge à 8 MHz dans les années 85 quand le premier processeur MIPS arriva sur le marché. Plusieurs versions possèdent une vitesse d'horloge plus rapide : par exemple, le R3000 est un modèle 100% compatible du R2000, il est juste plus rapide. A cause de leur importante compatibilité, quand ce document parle du R3000, dans bien des cas, il se passe la même chose pour le R2000.
Le R3000 est simplement un R2000 plus un FPU R3010 et 64k de mémoire cache fonctionnant à plus de 40MHz et tous cela intégré sur la même carte. Le support du processeur R3000 est mis au point en ce moment par de nombreuses personnes. Harald Koerfgen ( harald.koerfgen@netcologne.de) et Gleb O. Raiko ( raiko@niisi.msk.ru)ont tous les deux travaillé indépendamment sur des patches qui ne sont pas encore intégré dans les sources officiels de Linux/MIPS.
Quelques fois des gens confonde le R6000, un processeur MIPS, avec le RS6000, une séries de stations de travail vendu par IBM. Donc si vous avez lu ce document dans l'espoir de trouver plus d'informations de Linux sur les machines IBM, vous avez lu le mauvais document.
Le R6000 n'est pas encore supporté en ce moment. C'est un processeur MIPS 32 bits ISA 2 et un morceau de silicone plutôt intéressant et bizarre. Il a été développé et produit par une compagnie appelé BIT Technology. Plus tard, NEC pris la suite de la production de semi-conducteur. Il était construit avec la technologie ECL, la même technologie que l'on utilisait et que l'on utilise encore pour construire des composants extrêmement rapide comme ceux utilisés dans les ordinateurs Cray. Le processeur avait ses TLB implémenté comme une partie du dernier couple de lignes de la mémoire cache primaire externe, une technologie appelé TLB slice. Ceci veut dire que sa MMU est substantiellement différent de celles de la série R3000 ou R4000, ce qui est encore une des raisons qui explique pourquoi le processeur n'est pas supporté.
Linux supporte la plus part des membres de la famille des R4000. En ce moment, il y a les R4000PC, R4400PC, R4300, R4600, R4700, R5000, R5230, R5260. Plusieurs autre fonctionnent probablement assez bien.
Ceux qui ne sont pas supporté sont les CPU R4000MC et R4400MC (ce sont des systèmes multiprocesseurs) ainsi que les systèmes R5000 avec une mémoire cache de second niveau contrôlé par CPU. Ce qui veut dire que le cache est contrôlé par le R5000 lui même par opposition aux contrôleurs de mémoire cache de second niveau externe. La différence est importante car, contrairement aux autres systèmes, spécialement les PC, sur les MIPS, le cache est visible sur l'architecture et nécessite d'être contrôlé par software.
spécial remerciement à Ulf Carlsson ( grim@zigzegv.ml.org) qui a amélioré le module CPU en débugant le support R4000SC / R4400SC.
Le R8000 n'est toujours pas supporté en partie à cause de son processeur qui est relativement rare et est uniquement utilisé dans quelques machines SGI, en partie à cause des développeurs de Linux/MIPS qui n'ont pas de tels machines.
Le R8000 est un morceau de silicone plutôt intéressante. A la différence des autres membres de la famille MIPS, c'est un ensemble de 7 composants. Son cache et son architecture TLB est plutôt différent des autres membres de la famille MIPS. Il est né dans le but de permettre que le point flottant récompense Silicon Graphics avant que le R10000 soit fini.
LE R10000 est n'est pas encore supporté à cause des développeurs de Linux/MIPS qui n'ont de machine R10000.