Plusieurs machines sont utilisables avec un quantité variable d'options CPU qui ne sont pas encore toutes supportés. Veuillez vérifier que votre type de CPU est supporté dans la section Types de processeurs. C'est une liste de machines qui fonctionnent sous Linux/MIPS, de systèmes où Linux/MIPS peut être porté ou de systèmes où l'on a intérêt à faire fonctionner Linux/MIPS.
Le PICA d'Acer est dérivé de l'architecture Mips magnum 4000. Il possède un CPU R4400PC fonctionnant à 133 Mhz ou éventuellemnt à 150 Mhz plus une mémoire cache de second niveau de 512 Ko (éventuellement de 2 Mo); la carte gfx G364 du Magnum a été remplacé par une carte basée sur le S3 968. Le système est supporté à l'éxception du serveur X.
Les séries Baget comprennent plusieurs machines possédant des processeurs R3000 : le Baget 23, le Baget 63 et le Baget 83. Les Baget 23 et 63 ont des cartes mères BT23-201 ou BT23-202 avec respectivement un R3500A (qui est, à la base, un composant R3000A) à 25 Mhz et un R3081E à 50 Mhz. La carte BT23-201 possède un bus VME et des puces VIC068, VAC068 comme contrôleurs systèmes. La carte BT23-202 possède un bus PCI en interne et une bus VME en externe. Le support de la carte BT23-201 a été fait par Gleb Raiko (rajko@mech.math.msu.su) et Vladimir Roganov (vroganov@msiu.ru) avec l'aide de Serguei Zimin (zimin@msiu.ru). Le support du BT23-202 est en développement avec un Baget 23B qui est composé de 3 cartes BT23-201 avec un bus VME partagé.
Le Baget 83 est mentionné ici uniquement pour être éxhaustif. Il possède uniquement 2 Mo de RAM et il est trop petit pour faire tourner Linux. Le code du Baget/MIPS a été fusionné avec le portage des stations DEC ; le source pour ces deux plates-formes est sur http://decstation.unix-ag.org/.
Les séries de produits Qube Cobalt sont des systèmes de serveurs headless de faible coût basés sur un IDT R5230. Cobalt a développé sa propre variante de Linux/MIPS pour répondre aussi bien que possible aux besoins particuliers du Qube. Au départ, le noyau du Qube a été dérivé du noyau de Linux/MIPS 2.1.56, puis ramené à la version 2.0.30 pour la stabilité, enfin il a été optimisé. Les noyaux pour le Cobalt sont accessibles sur le site ftp de Cobalt http://www.cobaltnet.com. Le support du Qube de Cobalt n'a jamais été intégré dans les noyaux officiels 2.1.x de Linux/MIPS.
Les machines uni-processeur NEC sont des systèmes PICA d'Acer, voir cette section pour plus de détails. Les systèmes SMP sont diférents à cause du fait d'avoir plusieurs processeurs. Les développeurs de Linux/MIPS n'ont pas les documentations techniques nécessaires pour écrire un OS. Aussi longtemps qu'il n'y aura pas de changements, ce portage restera plus ou moins un bouchon remarqué faisant obstacle au portage vers les systèmes SMP de NEC.
Le projet VR Linux fait le portage de Linux vers du matériel basé sur les micro-processeurs VR41xx de NEC. La plupart de ces matériels étaient, à l'origine, destinés pour faire tourner Windows CE. Le projet a produit des noyaux qui fonctionnent avec des drivers de bases pour le Vadem Clio, la Casio E-105, l'Everex Freestyle, et bien d'autres. Pour de plus amples informations, veuillez consulter le site http://linux-vr.org/.
Semblable aux VR41xx, le matériel avec ces processeurs ont été, à l'origine, destinés pour faire tourner Windows CE. Cependant, il y a des noyaux fonctionnels avec des drivers de base pour le Sharp Mobilon et la série C de Compaq. Le support d'autre matériels est en cours. Le code fait partie du projet VR Linux et donc de plus amples informations peuvent être trouvé sur http://linux-vr.org/.
Le Netpower 100 est apparamment un PICA d'Acer déguisé. Il devrait être, par conséquence, supporté mais cela n'a pas été testé. S'il y a un problème c'est probablement lors de la détection de la machine.
La nintendo 64 est une console de jeu basé sur un R4300 avec 4 Mb de RAM. Ses puces graphiques ont été développé par Silicon Graphics pour nintendo. A l'heure actuelle, ce portage est un réve de joueur et continuera de l'être tant que Nintendo ne décidera pas de publier les informations techniques necessaires. La question qui subsiste est de savoir si c'est une bonne idée.
Cette machine est très similaire à l'Indy ; la différence est qu'elle ne possède pas de clavier ni de carte GFX mais un adaptateur basé sur un WD33C95 SCSI supplémentaire. Cet adaptateur WD33C95 n'est pas supporté pour l'instant.
Cette machine n'est mentionée que parce que certaine personne la confonde avec les Indys ou l'Indigo 2. L'Indigo posséde une architecture différente, basée sur un R3000 cependant, et n'est pas encore supporté.
Cette machine est le successeur de l'Indigo et elle est très semblable à l'Indy. Elle est maintenant supportée, bien qu'ellz péche en bien des points. Vous devrez utiliser une console série. Si vous avez une Indigo2 et si vous désirez encore y faire tourner Linux, contactez soit Florian Lohoff (flo@rfc822.org) soit Klaus Naumann (spock@mgnet.de).
L'Indy est, en ce moment, l'unique machine supporté parmi (la plupart) des machines de Silicon Graphics. La seule carte graphique supportée est la carte Newport c'est-à-dire la "XL". L'Indy existe avec un grand nombre d'options pour le CPU à des taux d'horloge variés, tous étant supportés. Il existe aussi maintenant un serveur X écrit par Guido Guenther (guido.guenther@gmx.net). Si vous pouvez utiliser la console de Newport sur votre Indy, il doit être possible aussi d'utiliser le serveur X. Il est basé sur XFree86 4.0 et il fonctionne courament à une vitesse de tortue mais semble bien fonctionner. Si vous désirez l'essayer, jetez un oeil sur http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/.
Lors du boot, le noyau de l'Indy reporte la mémoire utilisable dans un message du type :
Memory: 27976k/163372k available (1220k kernel code, 2324k data)Cette importante différence entre la première paire de nombres vient de l'existance d'une zone de 128 Mo dans l'espace adressable de la mémoire de l'Indy qui reflète les 128 premiers Mo de mémoire. La différence entre les 2 nombres sera toujours proche de 128 Mo et n'indique pas un quelconque problème. Les noyaux depuis la version 2.3.23 ne compte plus ce trou de 128 Mo.
Plusieurs personnes ont rapportés ces problèmes avec leurs machines après une mise à niveau typiquement à cause de parties en trop. Il existe plusieurs versions de PROM pour les Indys. Les machines avec de vieilles versions de leur PROM, qui ont été mis à niveau vers une variante plus récente d'un CPU comme un module R4600SC ou un R5000SC, peuvent se planter pendant l'auto-test avec un message d'erreur 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: bfc0b598Dans ce cas, vous devez mettre à niveau la PROM de votre machine vers une version plus récente ou retourner vers un version plus ancienne du CPU. En général, les modules R4000SC ou R4400SC devraient fonctionner de cette manière. Juste pour être bien clair, ceci est un problème n'ayant aucun rapport avec Linux. C'est uniquement mentionné ici parce que plusieurs utilisateurs de Linux nous ont posé la question.
Les vieilles versions de PROM ne connaissent pas le format binaire ELF que le noyau de Linux utilise, ce qui l'empêche de booter directement sur Linux. La solution préférable à cela reste évidement une mise à niveau de la PROM. Vous pouvez aussi utiliser Sash d'IRIX 5 ou une version plus récente pour charger le noyau. Sash sait comment charger les binaires ELF et ne se préoccupe pas de savoir si c'est un noyau IRIX ou Linux. Il suffit de taper simplement "Sash" à partir du moniteur de la PROM. Vous obtiendrez un autre prompt shell, celui de Sash cette fois-ci. Maintenant lancez Linux comme d'habitude.
Sash peut lire les systèmes de fichiers EFS ou XFS ou lire le noyau avec bootp / tftp. Cela veut dire que si vous avez l'intention d'utiliser Sash pour lancer le noyau à partir d'un disque local, vous devrez encore posséder une installation minimale d'IRIX sur votre système.
Lors du démarrage, le message "Memory: ..." sur un Indy indique qu'il y a 128 Mo de RAM réservé. C'est normal ; de même que l'architecture PC a un trou dans son espace d'adressage mémoire entre 640 Ko et 1024 Ko, l'Indy possède une zone de 128 Mo dans son espace mémoire où les 128 premiers Mo de sa mémoire est dupliqué. Linux le sait et ignore simplement cette zone mémoire, ce qui explique ce message.
Ralf Bächle (ralf@gnu.org) et une équipe d'employés de SGI travaillent actuellement sur un portage vers l'Origin 200. Bien qu'il soit encore que dans les étapes initiales, il fonctionne en mode mono-processeur et multi-processeurs et possède des pilotes pour la carte Ethernet IOC3 et l'adaptateur SCSI fourni avec. Le code peut être pris dans l'arbre CVS de Linux/MIPS.
L'Onyx 2 est, à la base, un Origin 2000 avec du matériel graphique supplémentaire. A partir de maintenant,le support de Linux pour le matériel graphique n'a pas été décidé. En dépit de ca, Linux devrai fonctionner aussi bien qu'une configuration headless Origin 2000.
C'estune très vieilles séries des systèmes R3000 SMP. Il n'existe pas de documentation sur le matériel de ces machines, peu d'entre elles existant encore, le matériel est bizarre. Pour faire court, les chances pour que Linux tourne un jour sur l'une d'elles sont proches de zéro. Non pas que l'on veuille décourager des volontaires ...
Assurez-vous que le noyau que vous utilisez inclus le driver approprié pour une interface série et une console série. Initialisez la variable d'environnement console ARC soit avec la valeur d1 soit avec la valeur d2 pour les Indy et les Challenge S en fonction de l'interface série que vous allez utiliser comme console.
Si vous avez le problème d'affichage de tous les messages du noyau sur la console série lors du démarrage alors que plus rien n'est affiché à partir du début de la phase d'init, alors vous avez probablement une mauvaise configuration pour votre /dev/console. Vous pourrez trouver de plus amples informations à ce sujet dans la documentation du source du noyau de Linux ; il est situé dans le répertoire /usr/src/linux/Documentation/serial-console.txt si vous avez installé le source du noyau.
A l'heure actuelle, aucune machine Silicon Graphics n'est supportée. Ceci s'applique aussi aux systèmes basés sur les très vieux Motorola 68k.
La Playstation de Sony est basée sur un R3000 dérivée et utilise un ensemble de composants graphiques dévelopé par Sony lui-même. Alors que la machine est, en théorie, capable de tourner sous Linux, un portage semble difficile, puisque Sony n'a toujours pas fourni les informations techniques nécessaires. Cela met de côté la question de l'intêret du portage. Donc, en résumé, rien ne s'est passé jusqu'ici alors que beaucoup de gens ont montré leur intérêt en essayant Linux sur une Playstation.
A l'inverse du RM200 (voir en-dessous), cette machine possède des slots EISA et PCI. Le RM200 est supporté à l'exception du controleur SCSI NCR53c810A intégré.
Si votre machine possède à la fois des slots EISA et PCI, alors c'est un RM200C ; Consultez la section précédente s'il vous plaît. A cause de légères diffèrences architecturales entre le RM200 et le RM200C, cette machine n'est pas encore supportée dans les sources officiels. Michael Engel (engel@numerik.math.uni-siegen.de) a réussi à faire fonctionner son RM200 partiellement mais les patches n'ont pas encore été inclus dans les sources de Linux/MIPS officiels.
Le RM300 est techniquement très similaire au RM200C. Il devrai être supporté par le noyau courant de Linux, mais nous n'avons encore reçu aucun signalement.
Le RM400 n'est pas supporté.
Cette machine est une variante OEM d'un SGI Indigo et, par conséquent, elle n'est pas encore supportée.
Le portage de l'Algorithmics P4032 tourne encore, lors de la redaction de ce document, sous Linux 2.1.36.
Le P5064 est, à la base, une variante 64 bits du P4032 basé sur un R5000. Un portage est en cours.
Pendant la fin des années 80 et au début des années 90, Digital (maintenant Compaq) a construit une station de travail basée sur les MIPS appelée respectivement DECStation et DECsystem. D'autres machines basées sur des x86 ou des Alphas ont été vendu sous le nom DECstation, mais ils ne sont malheureusement pas le sujet de cette FAQ. Le support des DECstations est encore en cours de développement, débuté par Paul M. Antoine. A l'heure actuelle, la plupart du travail est fait par Harald Koerfgen (Harald.Koerfgen@home.ivm.de) et par d'autres personnes. Sur Internet, des informations sur les DECstations peuvent être trouvé sur le site http://decstation.unix-ag.org/.
La famille des DECstations couvre les DECstations 2100 avec une puce R2000/R2010 à 12 MHz jusqu'au DECstation 5000/260 avec un R4400SC à 66 MHz.
Les modèles des DECstations suivants sont activement supportés :
Ces modèles de DECstations sont orphelins parce que personne ne travaille dessus, alors que leur support peut être relativement facile à finir.
Les autres machines de la famille des DECstations, à part ceux basés sur x86, devraient être considéré comme des VAXen avec un CPU remplacé par un CPU MIPS. Il n'y a aucune information existante sur ces machines et le support de ces machines est improbable à moins que le portage des VAXLinux renait de ses cendres. Ce sont les :
Ces deux machines sont presque complétement identiques. Revenons lors de l'initiative d'ACE, Olivetti a pris une license du concept Jazz et a mis sur le marché la machine avec comme système d'exploitation Windows NT. MIPS Computer Systems, Inc a acheté lui-même le concept Jazz et l'a mis sur le marché avec la série de machines MIPS Magnum 4000. Les systèmes Magnum 4000 ont été mis sur le marché avec comem système d'exploitation Windows NT et RISC/os.
Le microcode de la machine dépend du système d'exploitation qui a été installé. Linux/MIPS supporte uniquement le microcode "little endian" sur ces deux types de machines. Puisque le M700-10 n'a été mis sur le marché uniquement en tant que machine NT, toutes ces machines ont ce matériel installé. Le cas du MIPS Magnum est quelque peu plus complexe. Si votre machine a été configuré en "big endian" pour RISC/os alors vous devez recharger le microcode "little endian". Ce microcode était, à l'origine, inclus sur une disquette lors de la livraison de chaque Magnum. Si vous ne possédez plus la disquette, vous pouvez la télécharger par ftp anonymes sur le site ftp://ftp.fnet.fr.
Il est possible de reconfigurer les M700 pour des opérations headless en positionnant les variables d'environnement du matériel ConsoleIn et ConsoleOut sur mluti()serial()term(). Essayez aussi la commande listdev qui listera les périphériques ARC existants.
Dans bien des cas, comme lorsque la carte graphique G364 est absente alors que la console est encore configurée pour l'utilisation graphique normale, il sera nécessaire de modifier le cavalier de configuration JP2 sur la carte mère. Après le prochain reset, la machine redemarrera sur la console COM2.
Le Mips Magnum 4000SC est semblable au Magnum 4000 (voir ci-dessus) sauf qu'il utilise un CPU R4000SCC.
Le R2000 est le processeur MIPS original. C'est un processeur 32 Bits qui avait une fréquence de 8 MHz sortie en 85 lorsque les premiers processeurs MIPS arrivérent sur le marché. Les versions suivantes furent cadencées plus rapidement : par exemple, le 53000 est un reconception du R2000 100% compatible, juste cadencé plus rapidement. A cause de leur haute compatibilité, lorsque ce document mentionne le R3000, dans bien des cas, les mêmes faits s'appliquent aussi aux R2000. Le R3000A est, à la base, un R2000 avec un FPU R3010 et 64 K de cache cadencé jusqu'à 40 MHz et intégré dans la même puce.
Harald Koerfgen (Harald.Koerfgen@home.ivm.de) et Gleb O. Raiko (raiko@niisi.msk.ru) ont tous les deux, de façon indépendante, travaillé sur des patches pour les processeurs R3000. Leur travail a été fusionné et intégré dans les sources officiels de Linux/MIPS depuis juillet 1999. Actuellement, Linux supporte les processeurs R3000 ainsi que des variantes comme le R3081 et le TMPR3912/PR31700.
Parfois, des personnes confondent le R6000, qui est un processeur MIPS, avec le RS6000, une série de stations de travail créée par IBM. Donc, si vous lisez ces lignes en espérant trouver des informations sur l'utilisation de Linux sur des machines IBM, vous lisez le mauvais document.
Le R6000 n'est pas supporté pour l'instant. C'est un processeur MIPS 32 Bits ISA 2 et c'est un morceau de silicon plutôt intéressant et bizarre. Il a été développé et produit par une entreprise appelée BIT Technology. Plus tard, NEC repris la production des semiconducteurs. Il était construit avec la technologie ECL, la même technologie qui était et qui est encore utilisé pour construire des puces extrêmement rapide comme celles utilisées dans les ordinateurs Cray. Le processeur possède son propre TLB implémenté comme une partie des dernières paires de lignes du cache primaire externe, une technologie appelée tranche TLB (TLB slice). Ce qui signifie que son MMU est substantiellement différent de ceux de la série des R3000 ou des R4000, ce qui est aussi une des raisons pour laquelle le processeur n'est pas supporté.
Linux supporte la plupart des membres de la famille des R4000. Actuellement, ce sont le R4000PC, le R4400PC, le R4300, le R4600, le R4700, le R5000, le R5230 et le R5260. Beaucoup d'autres fonctionnent probablement aussi bien.
Ceux qui ne sont pas supportés, ce sont les CPU R4000MC et R4400MC (ce sont des systèmes multi-processeurs), de même que les système R5000 avec un cache de second niveau controlé par le CPU. Cela signifie que le cache est contrôlé par le R5000 lui-même à la différence des controleurs de cache externe. La différence est importante car, à la différence des autres systèmes, particulièrement les PCs, sur les MIPS, le cache est visible dans l'architecture et nécessite d'être contrôlé de façon logiciel.
Remerciements particuliers pour Ulf Carlsson (ulfc@engr.sgi.com) qui a fourni le module CPU pour deboguer le support du R4000SC / R4400SC.
Le R8000 n'est pas supporté, à l'heure actuelle, d'une part parce que ce processeur est relativement rare et qu'il n'a été utilisé que dans quelques machines de SGI, d'autre part parce que les développeurs de Linux/MIPS ne possèdent pas d'une machine de ce type.
Le R8000 est un morceau de silicon plutôt intéressant. A la différence des autres membres de la famille MIPS, c'est un ensemble de 7 puces. Son cache et son architecture TLB est assez différent des autres membres de la famille MIPS. Il est né d'un rapide "hack" pour que les virgules flotantes redeviennent le fer de lance des Silicon Graphics avant que le R10000 soit terminé.
Le R10000 est supporté dans le noyau mips64 qui est actuellement supporté par les IP22 (l'Indy de SGI, le Challenge S et l'Indigo 2) et l'Origin.
A cause de la très grande difficulté pour gérer la manière de fonctionner de ce processeur dans des systèmes sans cache cohèrent, cela va prendre probablement encore un certain temps avant que nous supportions ce processeur pour de tels systèmes. A partir de maintenant, ces systèmes sont les SGI O2 et Indigo.
Comme son nom l'indique, c'est une machine IBM qui est basé sur la série de processeur RS6000 et, en tant que tel, ils ne font pas partie du projet Linux/MIPS. Les gens confondent souvent l'IBM RS6000 avec l'architecture MIPS R6000. Cependant, le projet Linux/PPC doit s'en occuper. Consultez le site http://www.linuxppc.org/ pour de plus amples informations.
Comme son nom l'indique déjà, cette machine est un membre de la famille des VAX de Digital Equipment. On le mentionne ici parce qu'il est souvent confondu avec la famille des DECstation basé sur le MIPS de Digital à cause des types de numéros similaires. Malheureusement, le VaxStation, de même que la famille entière des VAX, n'est pas supporté pour l'instant.
C'est un système basé sur les x86, par conséquent, il n'est pas couvert par cette FAQ. Cependant, pour faciliter vos recherches, voici quelques infos. Ken Klingman (kck@mailbox.esd.sgi.com) posté le 17 Janvier 1999 sur la liste de discussion Linux de SGI :
Nous y travaillons. Nous terminons actuellement de mettre le support du niveau de base dans la release de la 2.2. Les logiciels uniquement basé sur X et OpenGl devrait suivre relativement rapidement, mais le matériel accéléré pour OpenGL n'est pas encore planifié. Voir www.precisioninsight.com pour des nouvelles sur le matériel accéléré pour OpenGL.Pour plus d'informations, voir la Documentation/ du noyau de Linux à partir de la version 2.2 ou supérieure. Il y a des informations supplémentaires sur le web à l'adresse http://oss.sgi.com/. Notez que le personnel de SGI/MIPS et de SGI/Intel travaille indépendemment de chacun des autres, par conséquent, les sources sur le CVS anonyme sur oss.sgi.com peut ou ne peut très bien ne pas fonctionner pour les machines Intel ; nous n'avons pas testé cela.
Ce sont de très vieilles machines, probablement agés de plus de 10 ans maintenant. Comme ces machines ne sont pas basé sur des processeurs MIPS, ce document est le mauvais endroit pour y chercher des informations. Cependant, dans le but de vous faciliter les choses, ces machines ne sont pas supportées actuellement.