ralf@gnu.org
Traduction : Robert Jacolin, rjacolin@yahoo.frLinux/MIPS est un portage du tr�s r�pandu cl�ne d'UNIX, Linux, vers l'architecture MIPS. Linux/MIPS fonctionne sur un grand nombre de syst�mes, techniquement tr�s diff�rents, qui va des petits syst�mes embarqu�s et des petits serveurs jusqu'aux gros serveurs et aux grosses machines bureautiques qui, au moins � l'�poque o� ils ont �t� introduit sur le march�, �taient les meilleurs de leur classes.
Les avantages de Linux/MIPS par rapport aux autres syst�mes d'exploitation actuels sont :
Vous pouvez t�l�charger ce document dans plusieurs formats (et en anglais, NDT):
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.
Pour les MIPS, il y a la Rough Cuts Linux, anciennement Hard Hat Linux, qui est plus qu'un simple portage d'une Red Hat Linux 5.1 sur MIPS. Il est possible de l'obtenir sur ftp://oss.sgi.com/pub/hardhat.
Il est aussi empaquet� avec le support de l'architecture M68k, UltraSparc et PowerPC dans un paquetage appel� "Rough Cuts" �labor� par Red Hat, et on peut l'obtenir l� o� les produits Red Hat sont vendus. C'est une mani�re tr�s pratique de l'obtenir sans avoir � t�l�charger 280 Mo. Vous pouvez commander Rough Cuts directement chez Red Hat � l'adresse http://www.redhat.com/product.phtml/RC1000.
De plus, il existe une distribution bas� sur la Red Hat 5.2 qui a pour cible les Qubes de Cobalt ; ses binaires fonctionneront parfaitement sur d'autres architectures MIPS et sont accessibles sur ftp://intel.cleveland.lug.net/pub/Mipsel. ftp://bolug.uni-bonn.de/mips poss�de plusieurs paquetages rpm Redhat 6.0 et 6.1.
Un portage de la Debian est en cours. Les efforts actuels ont �t� amorc� en utilisant SGI/Linux comme base, et dpkg compile en natif avec peu de changements. En plus de la version SGI, des personnes ont montr� leur int�r�t pour des plateformes "little endian". Gardez un oeil sur la page du portage Debian-MIPS, http://www.debian.org/ports/mips/ pour le d�veloppement.
Cette distribution a �t� faite, jusqu'ici, uniquement pour les syst�mes "big endian". Elle est hautement exp�rimentale, pour une utilisation pour des d�veloppeurs pour tester les derni�res versions de gcc, de binutils, de la glibc et du noyau. C'est la seule distribution bas�e sur la glibc 2.2 disponible pour MIPS. Vous pouvez toujours r�cup�rer la derni�re version de cette distribution et les notes de publications qui l'accompagnent sur ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple. Un syst�me de cross-compilation est �galement disponible pour aider le d�veloppement.
Les deux serveurs FTP anonymes principaux pour Linux/MIPS sont :
Ce serveur devrait satisfaire presque tous vos d�sirs ftp sur Linux/MIPS. Vraiement.
Ce serveur n'est actuellement plus tout � fait � jour ; il est inclus ici pour �tre exhaustif et pour les gens qui sont int�ress�s par des logiciels pr�historiques.
Une autre source de binaires MIPS "little endian" se situe sur ftp://intel.cleveland.lug.net/pub/Mipsel qui contient la plupart des versions tr�s r�centes des binaires pour la Redhat avec les binaires du Cobalt.
Pour ceux qui veulent toujours rester au bord du goufre et qui veulent �viter d'avoir � t�l�charger des patches ou des archives tar compl�tes, nous avons aussi un serveur CVS anonymes. En utilisant CVS, vous pouvez rapatrier l'arbre des sources de Linux/MIPS avec les commandes suivantes :
cvs -d :pserver:cvs@oss.sgi.com:/cvs login (N�cessaire uniquement lors de la premi�re utilisation du CVS anonyme, le mot de passe est "cvs") cvs -d :pserver:cvs@oss.sgi.com:/cvs co <repository>o� vous ins�rez linux, libc, gdb ou faq � la place de <repository>. L'autre archive CVS importante de la communaut� Linux est vger.rutgers.edu o� beaucoup de code est centralis� avant d'�tre envoy� � Linus pour distribution. Bien que vger lui-m�me n'offre plus d'acc�s anonyme, il y a des sites mirroirs qui fournissent un acc�s anonyme. Pour plus de d�tails sur la mani�re d'y acc�der, voir http://cvs.on.openprojects.net/. Les modules qui ont de l'int�r�t sont "linux", "modutils", "pciutils", "netutils".
Les deux principaux serveurs web pour Linux/MIPS sont :
Ce serveur couvre la presque totallit� de Linux/MIPS ; il est plut�t centr�e sur SGI mais comme Linux/MIPS essaye d'�tre identique sur toute les plateformes, la plupart de ces informations restent int�ressantes pour tous les utilisateurs.
Ce serveur n'est actuellement plus tr�s � jour ; il est inclu ici principalement pour �tre exhaustif.
Via http://oss.sgi.com/mips/cvsweb vous avez un acc�s direct aux sources du nouveau noyau Linux/MIPS et � quelques autres projets g�r�s dans la m�me archive CVS. L'interface intuitive vous permet de suivre le d�veloppement avec des clics de souris.
Il existe trois listes de discussions sur Linux/MIPS :
Cette liste de discussions est utilis�e pour des communications de toutes sortes autres qu'� propos de SGI. Les inscriptions sont g�r�s par une personne ; envoyez votre requ�tes d'inscription � linux-mips-request@fnet.fr. Vous pouvez vous desinscrire � partir de la liste de discussions en envoyant unsubscribe <votre-adresse-mail> � la m�me adresse.
Cette liste de discussions poss�de actuellement le plus de traffic. Elle est plus ou moins centr�e sur SGI mais elle a pourtant de l'int�r�t, sp�cialement pour les d�veloppeurs puisqu'un grand nombre d'ing�nieurs de SGI sont inscrits � la liste. L'inscription � cette liste se fait par Majordomo (majordomo@oss.sgi.com) ; envoyez simplement un courrier �lectronique avec les mots subscribe linux. Pour se d�sinscrire, envoyez unsubscribe linux. Notez que vous devez vous inscrire pour pouvoir poster un courrier ; l'augmentation de spasm nous a forc� cette politique. Pour de plus amples informations, voir aussi http://oss.sgi.com/mips/email.html.
Cette liste de discussions a vraiment tr�s peu de traffic puisque la plupart des gens ont tendance � utiliser une des listes de discussions ci-dessus. Les inscriptions sont g�r�es par Majordomo (majordomo@vger.rutgers.edu) ; envoyez juste un courrier �lectronique avec les mots subscribe linux-mips. Pour se d�sinscrire envoyez un courrier avec unsubscribe linux-mips.
Il existe un canal IRC nomm� #mipslinux pour Linux/MIPS qui peut �tre trouv� sur irc.openprojects.net.
En g�n�ral, cela vient du fait que la personne a d�compress� l'archive tar sous IRIX, et pas sous Linux. Puisque la repr�sentation des fichiers des p�riph�riques � travers NFS n'est pas standardis� entre les Unices, cela �choue. Le symptome est le blocage du syst�me avec le message d'erreur "Warning: unable to open an initial console." juste apr�s le montage du syst�me de fichiers NFS.
Pour le moment, il faut utiliser un syst�me Linux (pas n�cessairement un MIPS) pour d�compresser l'archive d'installation sur un serveur NFS. Le serveur NFS lui-m�me peut �tre n'importe quel UNIX.
Lorsque je construit mon propre noyau, il plante. Sur un Indy, le message lors du plantage ressemble � ce qui suit ; le m�me probl�me appara�t aussi sur d'autres machines mais ce qui est affich� diff�re compl�tement.
Exception: <vector=UTLB Miss>
Status register: 0x300004803<CU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
Exception PC: 0x881385cc, Exception RA: 0x88002614
exception, bad address: 0x47c4
Local I/O interrupt register 1: 0x80 <VR/GIO2>
Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
arg: 7 8bfff938 8bfffc4d 880025dc
tmp: 8818c14c 8818c14c 10 881510c4 14 8bfad9e0 0 48
sve: 8bfdf3e8 8bfffc40 8bfb2720 8bfff938 a8747420 9fc56394 0 9fc56394
t8 48 t9 8bfffee66 at 1 v0 0 v1 8bfff890 k1 bad11bad
gp 881dfd90 fp 9fc4be88 sp 8bfff8b8 ra 88002614
PANIC: Unexpected exception
Ce probl�me vient d'une erreur non r�solue encore dans le module Binutils dans les versions
sup�rieures � la version 2.7. Pour le r�soudre, changez la ligne suivante dans le fichier
arch/mips/Makefile
LINKFLAGS = -static -N
en :
LINKFLAGS = -static
>> boot bootp()/vmlinux 73264+592+11520+331680+27848d+3628+5792 entry: 0x8df9a960 Setting $netaddres to 192.168.1.5 (from server deadmoon) Obtaining /vmlinux from server deadmoon Cannot load bootp()/vmlinux Illegal f_magic number 0x7f45, expected MIPSELMAGIC or MIPSEBMAGIC.Ce probl�me survient uniquement pour des Indys avec des versions tr�s anciennes de la PROM qui ne peuvent pas g�rer le format binaire ELF que Linux utilise. Une solution � ce probl�me est en cours de r�solution.
Le syst�me SNI peut tourner � la fois en modes "big endian" et "little endian". Actuellement, Linux/MIPS supporte uniquement le microcode "little endian". C'est plut�t malchanceux car SNI n'a plus mis en place ce microcode depuis un certain temps, depuis qu'ils sont pass�s en NT. Lorsqu'il tourne en mode "big endian", le microcode se comporte de fa�on similaire � un Indy SGI qui est d�j� support�, par cons�quent la r�solution du support des SNI sera relativement facile. Les hackers int�ress�s peuvent contacter Ralf Bächle (ralf@gnu.org).
collect2: ld terminated with signal 6 [Aborted]C'est un probl�me connu dans de vieilles versions de binutils. Vous devrez remettre � niveau binutils 2.8.1 plus des patches tr�s r�centes.
Votre machine r�pond aux paquets de BOOTP (vous devriez v�rifier cela en utilisant des sniffers de paquets comme tcpdump ou ethereal) mais ne t�l�charge pas le noyau � partir du serveur BOOTP. Cela arrive si votre serveur de boot tourne sous un noyau de la s�rie 2.3 ou sup�rieure. Le probl�me peut �tre contourn� en faisant un "echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc" sous compte administrateur (root) sur votre serveur de d�marrage.
Lors de l'utilisation de DHCP version 2, vous devrez voir appara�tre le probl�me suivant : Votre machine a re�u sa r�ponse de BOOTP 3 fois mais refuse de d�marrer TFTP. Vous pouvez r�soudre cela en faisant un "unsetenv netaddr" dans la console de commande de la PROM avant de booter votre syst�me. La version 3 de DHCP r�soud ce probl�me.
Milo est le chargeur de d�marrage utilis� pour d�marrer les syst�mes MIPS en mode "little endian" avec du microcode ARC, actuellement la famille Jazz et le SNI RM 200. Bien que Milo utilise le m�me nom et poss�de le m�me r�le que la version Alpha de Milo, ces deux Milo n'ont rien en commun. Ils sont d�velopp�s par des gens diff�rents, ne partagent pas de code, et travaillent sur des plateformes mat�rielles diff�rentes. Le fait d'avoir le m�me nom est simplement une sorte d'``accident'' historique.
Il est pr�vu de supprimer l'utilisation de Milo dans un futur proche.
La proc�dure de compilation de Milo est d�crite en d�tail dans les fichiers README dans le paquetage de Milo. Puisque Milo d�pend des fichiers d'en-t�te du noyau qui ont chang� plusieurs fois de suite, Milo, bien souvent, ne peut �tre compil� ais�ment ; cependant, la distribution de Milo inclus les binaires pour Milo et Pandora � la fois.
Pandora est un simple d�bugeur. Il a �t� initialement d�velop� pour analyser les syst�mes non-document�s. Pandora inclus un d�sassembleur, des fonctions de dump m�moire et bien plus. Si vous voulez simplement utiliser Linux, il est inutile d'installer Pandora. Cependant, il ne prend pas beaucoup de place.
L'utilisation des modules sous Linux/MIPS est plut�t facile ; cela devrait marcher normalement pour les personnes qui l'ont utilis� sous d'autres syst�mes Linux. Si vous d�sirez lancer un syst�me bas� sur des modules alors il vous faut au moins un noyau de version 980919 et installer modutils avec un num�ro de version plus r�cente que 2.1.121. Des versions plus anciennes ne fonctionneront pas.
La chose la plus simple pour configurer un compilateur crois� est de t�l�charger les binaires. Pour les machines Linux/i386 et les cibles "big endian", les paquetages n�cessaires sont :
binutils-mips-linux-2.8.1-1.i386.rpm egcs-c++-mips-linux-1.0.3a-1.i386.rpm egcs-g77-mips-linux-1.0.3a-1.i386.rpm egcs-libstdc++-mips-linux-2.8.0-1.i386.rpm egcs-mips-linux-1.0.3a-1.i386.rpm egcs-objc-mips-linux-1.0.3a-1.i386.rpmEt voici la liste des paquetages pour les cibles "little endian" :
binutils-mipsel-linux-2.8.1-1.i386.rpm egcs-c++-mipsel-linux-1.0.3a-1.i386.rpm egcs-g77-mipsel-linux-1.0.3a-1.i386.rpm egcs-libstdc++-mipsel-linux-2.8.0-1.i386.rpm egcs-mipsel-linux-1.0.3a-1.i386.rpm egcs-objc-mipsel-linux-1.0.3a-1.i386.rpmIl n'est pas n�cessaire de tous les installer ; la plupart des personnes peuvent oublier les compilateurs C++, Objective C et Fortran 77. Les binaires pour Intel ont �t� link� avec la GNU libc 2.1, donc vous devez l'installer aussi pour une mise � jour.
Avant toute chose, t�l�chargez les paquetages des sources et les patches :
Vous devez choisir un r�pertoire pour l'installation. Je ferais r�f�rence � ce r�pertoire par <prefix>. Pour �viter certain probl�me, il vaut mieux utiliser la m�me valeur pour <prefix> que pour le gcc natif. Par exemple, si votre gcc est install� dans /usr/bin/gcc alors choisissez /usr pour <prefix>. Vous devez utiliser la m�me valeur de <prefix> pour tous les paquetages que vous allez installer.
Pendant l'installation, il vous faudra environ 31 Mo d'espace disque pour binutils ; pour l'installation il vous faudra 7 Mo d'espace disque sur la partition contenant <prefix>. La compilation d'egcs n�cesite 71 Mo et 14 Mo pour l'installation. GNU libc n�cessite 149 Mo d'espace disque pendant la compilation et 33 Mo pour l'installation. Notez que ces quantit�s ne sont que des indications et peuvent varier significativement pour diff�rentes architectures de processeurs et de syst�mes d'exploitation.
Une des fonctionnalit�s particuli�res des architectures MIPS est que tous les processeurs sauf le R8000 peuvent �tre configur� pour tourner en mode gros ou petit boutien (big ou little endian). L'ordre des octets indique la mani�re dont le processeur stocke en m�moire les nombres sur plusieurs octets. Les machines gros boutiens stockent l'octet de poids le plus fort � l'adresse la plus basse alors que les machines petits boutiens les stockent � l'adresse la plus haute. Pensez � cela lors de l'�criture de nombres sur plusieurs octets de gauche � droite ou vice-versa.
Pour configurer correctement votre compilateur crois�, vous devez conna�tre l'ordre des octets du compilateur crois� cible. Si vous ne le savez pas d�j�, consultez la section Hardware Platforms pour l'ordre des octets des machines.
La plupart des paquetages bas�s sur autoconf supportent plusieurs architectures et syst�mes d'exploitation diff�rents. Pour diff�rencier chaque configuration, les noms sont construits selon les sch�mas <cpu>-<entreprise>-<SE> voire m�me <cpu>-<entreprise>-<noyau>-<SE>. Selon ces sch�mas, les noms de configuration de Linux/MIPS sont mips-unknown-linux-gnu pour les gros boutiens ou mipsel-unknown-linux-gnu pour les petits boutiens. Ces noms sont un peu long et il est permis de les abr�ger en mips-linux ou mipsel-linux. Vous devez utiliser les m�mes noms de configuration pour tous les paquetages qui comprennent votre environnement de compilateur crois�. Ainsi, bien que les autres noms comme mips-sni-linux ou mipsel-sni-linux sont les noms de configuration l�gaux, utilisez linux-mips ou mipsel-linux � la place ; ce sont les noms de configuration connu par les autres paquetages comme les sources du noyau Linux, autrement il devra �tre modifi� pour les compilations crois�es.
Je ferais maintenant r�f�rence au nom de configuration cible par <target>.
Ceci est la premi�re partie et la plus simple - du moins si vous essayez de faire l'installation sur un quelconque UNIX sain. Entrez simplement dans un r�pertoire avec suffisamment d'espace disque et faites ce qui suit :
gzip -cd binutils-<version>.tar.gz | tar xf - cd binutils-<version> patch -p1 < ../binutils-<version>-mips.patch ./configure --prefix=<prefix> --target=<target> make CFLAGS=-O2 make installCela fonctionne tr�s bien habituellement. Sur certaines machines qui utilise GCC 2.7.x comme compilateur, on raporte des dump core. C'est un bug connu de GCC et peut �tre r�solu en mettant GCC � niveau � la version 2.8.1 ou en mettant � niveau egcs.
Des personnes poss�dent un vieux fichier d'en-t�te assert.h install�, probablement des restes d'une ancienne installation d'un compilateur crois�. Ce fichier a pour cons�quence de faire �chouer silencieuement les scripts autoconf ; il n'est jamais n�cessaire et il a �t� uniquement install� � cause d'un bug dans des versions plus anciennes de GCC. V�rifiez si le fichier <prefix>/<target>/include/assert.h existe dans votre installation. Si c'est le cas, effacez-le : il n'aurait jamais d� �tre install� pour une quelconque version du compilateur crois� et causera des perturbations.
L'installation des sources du noyau est simple. Placez-les simplement dans un r�pertoire de votre choix et configurez-les. Leur configuration est n�cessaire pour que les fichiers qui sont g�n�r�s par la proc�dure soient install�s. Assurez-vous que vous ayez activ� CONFIG_CROSSCOMPILE vers la fin du processus de configuration. L'unique probl�me que vous pourriez rencontrer est d'avoir besoin d'installer des programmes GNU n�cessaires comme bash ou devoir �craser les versions de programmes fournies par le constructeur en pla�ant les versions GNU plus t�t dans la variables PATH.
Maintenant, allez dans le r�pertoire <prefix>/<target>/include et cr�ez deux liens symboliques nomm�s asm et linux pointant respectivement sur include/asm et include/linux dans vos sources du noyau qui viennent juste d'�tre install�s et configur�s. Ils sont n�cessaires pour que les fichiers d'en-t�tes n�cessaires soient trouv�s pendant l'�tape suivante.
Maintenant la partie la moins rigolote commence : il existe un soit-disant probl�me d'amor�age. Dans notre cas, cela signifie que le processus d'installation d'egcs n�cessite une glibc pr�c�demment install�e, mais nous ne pouvons pas compiler glibc parce que nous ne poss�dons pas encore de compilateur crois�. Heureusement, vous devrez uniquement passer par l� lorsque vous installerez un compilateur crois� pour la premi�re fois. Plus tard, lorsque vous aurez d�j� install� la glibc les choses seront plus ais�es. Mais pour l'instant faites :
gzip -cd egcs-1.0.3a.tar.gz | tar xf -
cd egcs-<version>
patch -p1 < ../egcs-1.0.3a-mips.patch
./configure --prefix=<prefix> --with-newlib --target=<target>
make SUBDIRS="libiberty texinfo gcc" ALL_TARGET_MODULES= \
CONFIGURE_TARGET_MODULES= INSTALL_TARGET_MODULES= LANGUAGES="c"
Notez que nous n'avons pas d�lib�rement compil� gcov, protoize, unprotoize et les
biblioth�ques. Gcov n'a pas de sens dans un environnement de compilateur crois� et
protoize et unprotoize �craserait carr�ment vos programmes natifs - c'est un bug dans les
makefiles de gcc. Enfin, nous ne pouvons compiler les biblioth�ques parce que nous
n'avons pas encore install� la glibc. Si tout ce passe avec succ�s, lancez l'installation
avec :
make SUBDIRS="libiberty texinfo gcc" INSTALL_TARGET_MODULES= \
LANGUAGES="c" install
Si vous d�sirez le compilateur crois� pour compiler le noyau, vous avez finis. La
compilation crois�e de la libc est maintenant n�cessaire pour pouvoir compiler les
applications utilisateurs.
Simplement pour s'assurer que ce que vous avez fait jusqu'ici fonctionne, vous devriez maintenant essayer de compiler le noyau. Entrez dans les sources du noyau MIPS et tapez "make clean; make dep; make". Si tout se d�roule bien, faites un "make clean" une fois de plus pour nettoyer les sources.
Faites :
gzip -cd glibc-2.0.6.tar.gz | tar xf -
cd glibc-2.0.6
gzip -cd glibc-crypt-2.0.6.tar.gz | tar xf -
gzip -cd glibc-localedata-2.0.6.tar.gz | tar xf -
gzip -cd glibc-linuxthreads-2.0.6.tar.gz | tar xf -
patch -p1 < ../glibc-2.0.6-mips.patch
mkdir build
cd build
CC=<target>-gcc BUILD_CC=gcc AR=<target>-ar RANLIB=<target>-ranlib \
../configure --prefix=/usr --host=<target> \
--enable-add-ons=crypt,linuxthreads,localedata --enable-profile
make
Vous avez maintenant une GNU libc compil�e qui doit encore �tre install�e. Ne
faites pas un simple make install. Cela �craserait vos fichiers syst�me de votre
machine par les fichiers sp�cifiques de Linux/MIPS avec des effets d�sastreux. A la
place, installez la GNU libc dans un autre r�pertoire choisie arbitrairement
<somedir> � partir du quel nous d�placerons dans le r�pertoire cible actuel
les parties que nous avons besoin pour la compilation crois�e :
make install_root=<somedir> installMaintenant p�n�trez dans <somedir> et installez finalement la GNU libc manuellement
cd usr/include find . -print | cpio -pumd <prefix>/<target>/include cd ../../lib find . -print | cpio -pumd <prefix>/<target>/lib cd ../usr/lib find . -print | cpio -pumd <prefix>/<target>/libLa GNU libc contient aussi une vaste documentation en ligne. Votre syst�me doit d�j� poss�der une version de cette documentation, donc si vous ne d�sirez pas installer les pages infos ce qui vous sauvera un peu moins d'un mega octets, ou si vous les avez d�j� install�s, sautez la prochaine �tape :
cd ../info gzip -9 *.info* find . -name \*.info\* -print | cpio -pumd <prefix>/infoSi vous n'avez pas de programme d'amorce, votre installation n'est pas finis
La premi�re tentative de compilation d'egcs a �t� stopp�e par l'absence de la GNU libc. Puisque nous avons maintenant la libc d'install�e, nous pouvons reconstruire egcs mais cette fois de fa�on aussi compl�te que l'installation d'un compilateur crois� puisse l'�tre :
gzip -cd egcs-<version>.tar.gz | tar xf - cd egcs-<version> patch -p1 < ../egcs-1.0.3a-mips.patch ./configure --prefix=<prefix> --target=<target> make LANGUAGES="c c++ objective-c f77"Comme vous pouvez le constater, la proc�dure est identique que la premi�re fois sauf que nous avons laiss� tomb� l'option --with-newlib. Cette option �tait n�cessaire pour enlever l'arr�t de la compilation de libgcc � cause de l'absence de la libc. Maintenant lancez l'installation avec :
make LANGUAGES="c c++ objective-c f77" installVous avez presque termin�. Si vous pensez ne pas avoir besoin des compilateurs Objective C ou F77, vous pouvez les enlever des commandes ci-dessus ; chacune vous sauvera environ 3 Mo. Ne compilez pas gcov, protoize ou unprotoize.
Origin 200 tournant sous IRIX 6.5.1 peut se planter lors d'un "make depend" dans les sources de noyau Linux. IRIX 6.5 sur un Indy et IRIX 6.5.4 sur un Origin 200 sont connus pour fonctionner correctement. Tout rapports pour aider � isoler le probl�me de configuration est la bienvenue.
Les Unix bas�s sur le standard System V comme IRIX ou Solaris ont des valeurs limites maximum sur les nombres d'argument pouvant �tre pass�s � un processus enfant qui peuvent �tre d�pass�s lors de la compilation crois�e de logiciels comme le noyau Linux ou la GNU libc. Pour les syst�mes IRIX, la taille maximum de la liste d'arguments vaut par d�faut 20 Ko alors la valeur par d�faut pour Linux est d'au moins 128 Ko. Cette taille peut �tre modifi� par la commande "systune ncargs 131072" sous root.
La compilation de GDB comme debugeur crois� a uniquement d'int�r�t pour les d�veloppeurs du noyau ; leur GDB peut leur sauver la vie. Une telle configuration de debugage distant est compos�e de deux parties : le debugeur GDB distant fonctionnant sur une machine et la machine cible faisant tourner le noyau Linux/MIPS qui doit �tre d�bugu�. Les machines sont habituellement inter-connect�es par une ligne s�rie. Le noyau de la machine cible doit �tre �quip� d'un "embryon de d�bugage" qui communique avec le GDB de la machine h�te en utilisant le protocole s�rie distant.
Suivant l'architecture cible, il vous faudra impl�menter l'embryon de d�bugage vous-m�me. En g�n�ral, vous devrez uniquement �crire des routines s�ries tr�s simple. La t�che est, de plus, simplifi�e par le fait que la plupart des machines utilisent des p�riph�riques s�ries semblables, en g�n�ral bas� sur le 8250, le 16450 ou des d�riv�s.
auteur Dominic Sweetman, publi� par Morgan Kaufmann, ISBN 1-55860-410-3. Il a �t� �crit pour �tre un guide plut�t compr�hensif pour la programmation MIPS, l� o� celui-ci diff�re de la programmation d'autres CPU 32 bits. C'est la premi�re fois que quelqu'un tente d'�crire une explication lisible et compr�hensive et qui prend en compte l'immense gamme de CPU MIPS existant, et devrait �tre tr�s utile pour toutes personnes programmant en MIPS qui n'est pas isol� par le syst�me d'exploitation de quelqu'un d'autre. Et l'auteur est un enthousiaste pro-unix-libre qui s'est inscrit � la liste de discussions de Linux/MIPS ! John Hennessey, le p�re de l'architecture MIPS, a �t� assez aimable pour �crire dans la pr�face " ... ce livre est la meilleure combinaison entre l'exhaustivit� et la lisibilit� de tout livre sur l'architecture MIPS ... " ; Il contient une partie sur les CPU RISC, une description de l'architecture et de l'ensemble d'instructions incluant les instructions du "co-processeur 0" utilis� pour le contr�le du CPU ; des sections sur les caches, les exceptions, la gestion m�moire et les virgules flottantes. Il y a un guide d�taill� sur le langage assembleur, des trucs sur le portage et des exemples de logiciels plut�t � usage industriel. Il est disponible sur :
auteurs Farquhar et Bunce, publi� par Morgan Kaufmann, ISBN 1-55860-297-6. Une introduction lisible pour la pratique de la programmation bas niveau d'un MIPS, par l'auteur de PMON. Sa qualit� : beaucoup d'exemples ; son d�faut : ne parle pas d'importantes parties de l'architecture (telle que la gestion de la m�moire, des virgules flottantes et les caches avanc�s) parce qu'ils n'ont pas �t� pr�sent dans le LSI "embarqu�s" ; ce livre a l'intention d'�tre un partenaire.
auteurs Hennessy & Patterson, publi� chez Morgan Kaufmann, ISBN 1-55860-329-8. La bible de l'architecture informatique moderne et qui se doit d'�tre lu si vous d�sirez comprendre pourquoi un programme fonctionne lentement ou rapidement. Parle-t-il du MIPS ? Eh bien, cela tourne principalement autours de chose semblable au MIPS ... Son seul d�faut est sa taille et son poids - mais � la diff�rence des gros bouquins, il le vaut � chaque page.
par Prentice Hall, publi� le 05 1991, ISBN 0-13880-170-3. Ce livre d�finit la plupart des standards techniques sp�cifiques � la technologie MIPS comme les conventions des appels, les propri�t�s ELF et bien d'autre choses utilis�es par Linux/MIPS. Malheureusement, il est en rupture de stock. Parall�lement, le site "http://www.mipsabi.org/" ne r�pond plus.