/usr/share/doc/HOWTO/fr-html/MIPS-HOWTO.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>Manuel de Linux/MIPS</title>
</head>
<body>
<h1>Manuel de Linux/MIPS</h1>
<h2>Ralf Bächle, <code>ralf@gnu.org</code> Traduction : Robert
Jacolin, <code>rjacolin@yahoo.fr</code></h2>
24 juin 2000
<hr>
<em>Cette FAQ décrit le portage vers l'architecture MIPS du système
d'exploitation Linux, ainsi que des problèmes courants et propose
des solutions, des possibilités (voire plus). Il tente aussi d'être
un peu utile pour les autres personnes qui lirait cette FAQ dans
l'espoir de trouver des informations qui, en fait, pourraient être
détaillées ailleurs.</em>
<hr>
<h2><a name="s1">1. Qu'est-ce-que Linux/MIPS ?</a></h2>
<p>Linux/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.</p>
<p>Les avantages de Linux/MIPS par rapport aux autres systèmes
d'exploitation actuels sont :</p>
<ul>
<li>Le système Linux complet se compose uniquement de Logiciels
Libres,</li>
<li>L'excellent rapport Prix/Performance,</li>
<li>L'existance d'une grande quantité de logiciels dont, encore un
fois, une large part sont des Logiciels Libres,</li>
<li>Une compatibilité binaire entre un nombre croissant de
plates-formes,</li>
<li>Une petite taille rendant Linux/MIPS approprié pour beaucoup de
systèmes embarqués.</li>
</ul>
En résumé, Linux a été conçu et porté avec plaisir. Cependant,
comme d'habitude, le temps que vous allez y consacrer pourra varier
et vous devrez vérifier que Linux puisse s'adapter à votre projet,
ce que ce document se propose de faire.
<h2><a name="s2">2. Obtenir cette FAQ</a></h2>
<p>Vous pouvez télécharger ce document dans plusieurs formats (et
en anglais, NDT):</p>
<ul>
<li>Une version HTML <a href=
"http://oss.sgi.com/mips/mips-howto.html">http://oss.sgi.com/mips/mips-howto.html</a></li>
<li>Une version texte <a href=
"http://oss.sgi.com/mips/mips-howto.txt">http://oss.sgi.com/mips/mips-howto.txt</a></li>
<li>Une version postscript <a href=
"http://oss.sgi.com/mips/mips-howto.ps">http://oss.sgi.com/mips/mips-howto.ps</a></li>
<li>Une version Linux-Doc SGML <a href=
"http://oss.sgi.com/mips/mips-howto.sgml">http://oss.sgi.com/mips/mips-howto.sgml</a></li>
</ul>
Cette FAQ est ausi accessible sous forme de code source SGML par
CVS anonyme sur oss.sgi.com. L'archive contient aussi un Makefile
qui le convertira en plusieurs formats. Une version ASCII est
réguliérement postée sur <em>comp.os.linux.answers</em> et les
autres cannaux des manuels Linux.
<h2><a name="s3">3. Quel est le matériel supporté par Linux/MIPS
?</a></h2>
<h2><a name="ss3.1">3.1 Les plates-formes matérielles</a></h2>
<p><a name="hardware-platforms"></a></p>
<p>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
<a href="#supported-cpus">Types de processeurs</a>. 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.</p>
<h3>Le PICA d'Acer</h3>
<p>Le <em>PICA d'Acer</em> est dérivé de l'architecture <em>Mips
magnum 4000</em>. 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.</p>
<h3>Les séries Baget/MIPS</h3>
<p>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 <a href=
"mailto:rajko@mech.math.msu.su">Gleb Raiko
(rajko@mech.math.msu.su)</a> et <a href=
"mailto:vroganov@msiu.ru">Vladimir Roganov (vroganov@msiu.ru)</a>
avec l'aide de <a href="mailto:zimin@msiu.ru">Serguei Zimin
(zimin@msiu.ru)</a>. 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é.</p>
<p>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
<a href=
"http://decstation.unix-ag.org/">http://decstation.unix-ag.org/</a>.</p>
<h3>Le Qube et le Raq de Cobalt</h3>
<p>Les séries de produits Qube&nbsp;Cobalt sont des systèmes de
serveurs headless de faible coût basés sur un IDT&nbsp;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 <a href=
"http://www.cobaltnet.com">http://www.cobaltnet.com</a>. Le support
du Qube de Cobalt n'a jamais été intégré dans les noyaux officiels
2.1.x de Linux/MIPS.</p>
<h3>Les machines NEC</h3>
<p>Les machines uni-processeur NEC sont des systèmes <em>PICA
d'Acer</em>, 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.</p>
<h3>Les plates-formes basées sur les VR41xx de NEC</h3>
<p>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&nbsp;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 <a href=
"http://linux-vr.org/">http://linux-vr.org/</a>.</p>
<h3>Les plates-formes TMPR39xx de Toshiba/PR31700 de Philips</h3>
<p>Semblable aux VR41xx, le matériel avec ces processeurs ont été,
à l'origine, destinés pour faire tourner Windows&nbsp;CE.
Cependant, il y a des noyaux fonctionnels avec des drivers de base
pour le <em>Sharp Mobilon</em> et la <em>série C de Compaq</em>. 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 <a href=
"http://linux-vr.org/">http://linux-vr.org/</a>.</p>
<h3>Le Netpower 100</h3>
<p>Le <em>Netpower 100</em> est apparamment un <em>PICA d'Acer</em>
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.</p>
<h3>La Nintendo 64</h3>
<p>La <em>nintendo 64</em> 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.</p>
<h3>Le Challenge S de Silicon Graphics</h3>
<p>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.</p>
<h3>L'Indigo de Silicon Graphics</h3>
<p>Cette machine n'est mentionée que parce que certaine personne la
confonde avec les Indys ou l'Indigo&nbsp;2. L'Indigo posséde une
architecture différente, basée sur un R3000 cependant, et n'est pas
encore supporté.</p>
<h3>L'Indigo2 de Silicon Graphics</h3>
<p>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 <a href="mailto:flo@rfc822.org">Florian
Lohoff (flo@rfc822.org)</a> soit <a href=
"mailto:spock@mgnet.de">Klaus Naumann (spock@mgnet.de)</a>.</p>
<h3>L'Indy de Silicon Graphics</h3>
<p>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 <a href="mailto:guido.guenther@gmx.net">Guido Guenther
(guido.guenther@gmx.net)</a>. 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 <a href=
"http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/">http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/</a>.</p>
<h3>Quantité étrange d'espace mémoire</h3>
<p>Lors du boot, le noyau de l'Indy reporte la mémoire utilisable
dans un message du type :</p>
<pre>
   Memory: 27976k/163372k available (1220k kernel code, 2324k data)
   
</pre>
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.
<h3>Problèmes avec la PROM de l'Indy</h3>
<p>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 :</p>
<pre>
   Exception: &lt;vector=Normal&gt;
   Status register: 0x30004803&lt;CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE&gt;
   Cause register: 0x4000&lt;CE=0,IP7,EXC=INT&gt;
   Exception PC: 0xbfc0b598
   Interrupt exception
   CPU Parity Error Interrupt
   Local I/O interrupt register 1: 0x80 &lt;VR/GIO2&gt;
   CPU parity error register: 0x80b&lt;B0,B1,B3,SYSAD_PAR&gt;
   CPU parity error: address: 0x1fc0b598
   NESTED EXCEPTION #1 at EPC: 9fc3df00; first exception at PC: bfc0b598
   
</pre>
Dans 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.
<h3>Le supprot d'ELF avec des vieilles versions de PROMs</h3>
<p>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.</p>
<p>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.</p>
<h3>Pourquoi y-a-t-il autant de mémoire réservée sur mon Indy
?</h3>
<p>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.</p>
<h3>Les Silicon Graphics Origin&nbsp;200 et 2000</h3>
<p><a href="mailto:ralf@gnu.org">Ralf Bächle (ralf@gnu.org)</a> et
une équipe d'employés de SGI travaillent actuellement sur un
portage vers l'Origin&nbsp;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.</p>
<h3>Les Silicon Graphics Onyx&nbsp;2</h3>
<p>L'Onyx&nbsp;2 est, à la base, un Origin&nbsp;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&nbsp;2000.</p>
<h3>Silicon Graphics Power Series</h3>
<p>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&nbsp;...</p>
<h3>Consoles Série sur les machines SGI</h3>
<p>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 <em>console</em> ARC soit
avec la valeur <em>d1</em> soit avec la valeur <em>d2</em> pour les
Indy et les Challenge&nbsp;S en fonction de l'interface série que
vous allez utiliser comme console.</p>
<p>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.</p>
<h3>Les autres machines de Silicon Graphics</h3>
<p>A l'heure actuelle, aucune machine Silicon Graphics n'est
supportée. Ceci s'applique aussi aux systèmes basés sur les
<i>très</i> vieux Motorola 68k.</p>
<h3>La Playstation de Sony</h3>
<p>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.</p>
<h3>SNI RM200C</h3>
<p>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é.</p>
<h3>SNI RM200</h3>
<p>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. <a href=
"mailto:engel@numerik.math.uni-siegen.de">Michael Engel
(engel@numerik.math.uni-siegen.de)</a> a réussi à faire fonctionner
son RM200 partiellement mais les patches n'ont pas encore été
inclus dans les sources de Linux/MIPS officiels.</p>
<h3>SNI RM300C</h3>
<p>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.</p>
<h3>SNI RM400</h3>
<p>Le RM400 n'est pas supporté.</p>
<h3>SNI RW320</h3>
<p>Cette machine est une variante OEM d'un SGI Indigo et, par
conséquent, elle n'est pas encore supportée.</p>
<h3>Algorithmics P4032</h3>
<p>Le portage de l'Algorithmics P4032 tourne encore, lors de la
redaction de ce document, sous Linux 2.1.36.</p>
<h3>Algorithmics P5064</h3>
<p>Le P5064 est, à la base, une variante 64 bits du P4032 basé sur
un R5000. Un portage est en cours.</p>
<h3>DECstation series</h3>
<p>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 <a href=
"mailto:Harald.Koerfgen@home.ivm.de">Harald Koerfgen
(Harald.Koerfgen@home.ivm.de)</a> et par d'autres personnes. Sur
Internet, des informations sur les DECstations peuvent être trouvé
sur le site <a href=
"http://decstation.unix-ag.org/">http://decstation.unix-ag.org/</a>.</p>
<p>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.</p>
<p>Les modèles des DECstations suivants sont activement supportés
:</p>
<ul>
<li>2100, nom de code PMAX</li>
<li>5000/xx (DECstation&nbsp;Personnel), nom de code MAXine</li>
<li>5000/1xx, nom de code 3MIN</li>
<li>5000/200, nom de code 3MAX</li>
<li>5000/2x0, nom de code 3MAX+</li>
<li>5900/2x0 (identique au 3MAX+).</li>
</ul>
<p>Ces modèles de DECstations sont orphelins parce que personne ne
travaille dessus, alors que leur support peut être relativement
facile à finir.</p>
<ul>
<li>3100, identique au 2100 sauf le R2000A/R2010A @ 16 MHz</li>
<li>5100, nom de code MIPSMATE, presque identique au 2100 mais avec
une puce R3000/R3010.</li>
</ul>
<p>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
:</p>
<ul>
<li>5400, nom de code MIPSFAIR</li>
<li>5500, nom de code MIPSFAIR2</li>
<li>5800, nom de code ISIS</li>
</ul>
<h3>Mips Magnum 4000 / Olivetti M700-10</h3>
<p>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&nbsp;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&nbsp;NT et
RISC/os.</p>
<p>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 <a href=
"ftp://ftp.fnet.fr">ftp://ftp.fnet.fr</a>.</p>
<p>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 <i>listdev</i> qui listera les périphériques ARC
existants.</p>
<p>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.</p>
<h3>MIPS Magnum 4000SC</h3>
<p>Le Mips Magnum 4000SC est semblable au Magnum 4000 (voir
ci-dessus) sauf qu'il utilise un CPU R4000SCC.</p>
<h2><a name="supported-cpus"></a> <a name="ss3.2">3.2 Les types de
processeur</a></h2>
<h3>La famille des R2000, R3000</h3>
<p>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.</p>
<p><a href="mailto:Harald.Koerfgen@home.ivm.de">Harald Koerfgen
(Harald.Koerfgen@home.ivm.de)</a> et <a href=
"mailto:raiko@niisi.msk.ru">Gleb O. Raiko (raiko@niisi.msk.ru)</a>
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.</p>
<h3>R6000</h3>
<p>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.</p>
<p>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 <i>BIT Technology</i>. 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
<i>tranche TLB (TLB slice)</i>. 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é.</p>
<h3>La famille des R4000 et R5000</h3>
<p>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.</p>
<p>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.</p>
<p>Remerciements particuliers pour <a href=
"mailto:grim@zigzegv.ml.org">Ulf Carlsson (ulfc@engr.sgi.com)</a>
qui a fourni le module CPU pour deboguer le support du R4000SC /
R4400SC.</p>
<h3>R8000</h3>
<p>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.</p>
<p>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&nbsp;Graphics avant que le R10000 soit terminé.</p>
<h3>R10000</h3>
<p>Le R10000 est supporté dans le noyau mips64 qui est actuellement
supporté par les IP22 (l'Indy de SGI, le Challenge&nbsp;S et
l'Indigo&nbsp;2) et l'Origin.</p>
<p>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&nbsp;O2 et Indigo.</p>
<h2><a name="ss3.3">3.3 Matériel qui ne sera jamais
supporté</a></h2>
<h3>IBM RS6000</h3>
<p>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 <a href=
"http://www.linuxppc.org/">http://www.linuxppc.org/</a> pour de
plus amples informations.</p>
<h3>VaxStation</h3>
<p>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.</p>
<h3>SGI VisPC</h3>
<p>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. <a href="mailto:kck@mailbox.esd.sgi.com">Ken
Klingman (kck@mailbox.esd.sgi.com)</a> posté le 17 Janvier 1999 sur
la liste de discussion Linux de SGI&nbsp;:</p>
<pre>
  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.

  
</pre>
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 <a href=
"http://oss.sgi.com/">http://oss.sgi.com/</a>. 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.
<h3>Les machines basé sur le 68k de Motorola comme
l'Iris&nbsp;30000</h3>
<p>Ce sont de <i>très</i> 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.</p>
<h2><a name="s4">4. Les distributions Linux</a></h2>
<h2><a name="ss4.1">4.1 RedHat</a></h2>
<p>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 <a href=
"ftp://oss.sgi.com/pub/hardhat">ftp://oss.sgi.com/pub/hardhat</a>.</p>
<p>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 <a href=
"http://www.redhat.com/product.phtml/RC1000">http://www.redhat.com/product.phtml/RC1000</a>.</p>
<p>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 <a href=
"ftp://intel.cleveland.lug.net/pub/Mipsel">ftp://intel.cleveland.lug.net/pub/Mipsel</a>.
<a href=
"ftp://bolug.uni-bonn.de/mips">ftp://bolug.uni-bonn.de/mips</a>
possède plusieurs paquetages rpm Redhat&nbsp;6.0 et 6.1.</p>
<h2><a name="ss4.2">4.2 Debian</a></h2>
<p>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,
<a href="http://www.debian.org/ports/mips/">http://www.debian.org/ports/mips/</a>
pour le développement.</p>
<h2><a name="ss4.3">4.3 Simple</a></h2>
<p>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
<a href=
"ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple">ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple</a>.
Un système de cross-compilation est également disponible pour aider
le développement.</p>
<h2><a name="s5">5. Ressources Linux/MIPS sur le net</a></h2>
<h2><a name="ss5.1">5.1 Serveurs FTP anonymes</a></h2>
<p>Les deux serveurs FTP anonymes principaux pour Linux/MIPS sont
:</p>
<dl>
<dt><b><a href="ftp://oss.sgi.com">oss.sgi.com</a></b></dt>
<dd>
<p>Ce serveur devrait satisfaire presque tous vos désirs ftp sur
Linux/MIPS. Vraiement.</p>
</dd>
<dt><b><a href="ftp://ftp.fnet.fr">ftp.fnet.fr</a></b></dt>
<dd>
<p>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.</p>
</dd>
</dl>
Sur tous ces serveurs ftp, il existe une liste de sites mirroirs
que vous devrez plutôt utiliser pour avoir des accès plus rapide.
<p>Une autre source de binaires MIPS "little endian" se situe sur
<a href=
"ftp://intel.cleveland.lug.net/pub/Mipsel">ftp://intel.cleveland.lug.net/pub/Mipsel</a>
qui contient la plupart des versions très récentes des binaires
pour la Redhat avec les binaires du Cobalt.</p>
<h2><a name="ss5.2">5.2 Serveurs CVS anonymes</a></h2>
<p>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 :</p>
<pre>
   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 &lt;repository&gt;
 
</pre>
où vous insérez linux, libc, gdb ou faq à la place de
&lt;repository&gt;. 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 <a href=
"http://cvs.on.openprojects.net/">http://cvs.on.openprojects.net/</a>.
Les modules qui ont de l'intérêt sont "linux", "modutils",
"pciutils", "netutils".
<h2><a name="ss5.3">5.3 Serveurs Web</a></h2>
<p>Les deux principaux serveurs web pour Linux/MIPS sont :</p>
<dl>
<dt><b><a href=
"http://oss.sgi.com/mips">http://oss.sgi.com/mips</a></b></dt>
<dd>
<p>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.</p>
</dd>
<dt><b><a href=
"http://lena.fnet.fr">http://lena.fnet.fr</a></b></dt>
<dd>
<p>Ce serveur n'est actuellement plus très à jour ; il est inclu
ici principalement pour être exhaustif.</p>
</dd>
</dl>
Tous ces serveurs possèdent des mirroirs éparpillés à travers le
monde ; vous devrez sans doute en utiliser un pour obtenir de
meilleures performances.
<h2><a name="ss5.4">5.4 Serveur Web CVS</a></h2>
<p>Via <a href=
"http://oss.sgi.com/mips/cvsweb">http://oss.sgi.com/mips/cvsweb</a>
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.</p>
<h2><a name="ss5.5">5.5 Listes de discussions</a></h2>
<p>Il existe trois listes de discussions sur Linux/MIPS :</p>
<dl>
<dt><b><a href=
"mailto:linux-mips@fnet.fr">linux-mips@fnet.fr</a></b></dt>
<dd>
<p>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 à
<a href=
"mailto:linux-mips-request@fnet.fr">linux-mips-request@fnet.fr</a>.
Vous pouvez vous desinscrire à partir de la liste de discussions en
envoyant <em>unsubscribe &lt;votre-adresse-mail&gt;</em> à la même
adresse.</p>
</dd>
<dt><b><a href=
"mailto:linux-mips@oss.sgi.com">linux-mips@oss.sgi.com</a></b></dt>
<dd>
<p>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 <a href=
"mailto:majordomo@oss.sgi.com">Majordomo
(majordomo@oss.sgi.com)</a> ; envoyez simplement un courrier
électronique avec les mots <em>subscribe linux</em>. Pour se
désinscrire, envoyez <em>unsubscribe linux</em>. 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 <a href=
"http://oss.sgi.com/mips/email.html">http://oss.sgi.com/mips/email.html</a>.</p>
</dd>
<dt><b><a href=
"mailto:linux-mips@vger.rutgers.edu">linux-mips@vger.rutgers.edu</a></b></dt>
<dd>
<p>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 <a href=
"mailto:majordomo@vger.rutgers.edu">Majordomo
(majordomo@vger.rutgers.edu)</a> ; envoyez juste un courrier
électronique avec les mots <em>subscribe linux-mips</em>. Pour se
désinscrire envoyez un courrier avec <em>unsubscribe
linux-mips</em>.</p>
</dd>
</dl>
<h2><a name="ss5.6">5.6 Canal IRC</a></h2>
<p>Il existe un canal IRC nommé #mipslinux pour Linux/MIPS qui peut
être trouvé sur irc.openprojects.net.</p>
<h2><a name="s6">6. L'installation de Linux/MIPS et ses problèmes
classiques</a></h2>
<h2><a name="ss6.1">6.1 Le boot sur NFS échoue</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss6.2">6.2 Des noyaux compilés plantent au
démarrage</a></h2>
<p>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.</p>
<pre>
   Exception: &lt;vector=UTLB Miss&gt;
   Status register: 0x300004803&lt;CU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IE&gt;
   Cause register: 0x8008&lt;CE=0,IP8,EXC=RMISS&gt;
   Exception PC: 0x881385cc, Exception RA: 0x88002614
   exception, bad address: 0x47c4
   Local I/O interrupt register 1: 0x80 &lt;VR/GIO2&gt;
   Saved user regs in hex (&amp;gpda 0xa8740e48, &amp;_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
  
</pre>
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
<pre>
   LINKFLAGS       = -static -N
 
</pre>
<p>en :</p>
<pre>
   LINKFLAGS       = -static
 
</pre>
<h2><a name="ss6.3">6.3 Le démarrage du noyau sur l'Indy échoue
avec des messages d'erreurs de la PROM</a></h2>
<pre>
   &gt;&gt; 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.
  
</pre>
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.
<h2><a name="ss6.4">6.4 Où puis-je obtenir le microcode en "little
endian" pour mon SNI ?</a></h2>
<p>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
<a href="mailto:ralf@gnu.org">Ralf Bächle (ralf@gnu.org)</a>.</p>
<h2><a name="ss6.5">6.5 ld meurt avec un signal 6</a></h2>
<pre>
   collect2: ld terminated with signal 6 [Aborted]
 
</pre>
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.
<h2><a name="ss6.6">6.6 Ma machine ne télécharge pas mon noyau
lorsque j'essaye de booter par le réseau</a></h2>
<p>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 &gt; /proc/sys/net/ipv4/ip_no_pmtu_disc" sous
compte administrateur (root) sur votre serveur de démarrage.</p>
<h2><a name="ss6.7">6.7 Erreur dans la version 2 de DHCP</a></h2>
<p>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.</p>
<h2><a name="s7">7. Milo</a></h2>
<p>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&nbsp;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.</p>
<p>Il est prévu de supprimer l'utilisation de Milo dans un futur
proche.</p>
<h2><a name="ss7.1">7.1 Compiler Milo</a></h2>
<p>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.</p>
<h2><a name="ss7.2">7.2 Pandora</a></h2>
<p>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.</p>
<h2><a name="s8">8. Modules chargeables</a></h2>
<p>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.</p>
<h2><a name="s9">9. Comment configurer un compilateur croisé
?</a></h2>
<h2><a name="ss9.1">9.1 Binaires existant</a></h2>
<p>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 :</p>
<pre>
  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.rpm
 
</pre>
Et voici la liste des paquetages pour les cibles "little endian" :
<pre>
  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.rpm
 
</pre>
Il n'est pas nécessaire de tous les installer ; la plupart des
personnes peuvent oublier les compilateurs C++, Objective&nbsp;C et
Fortran&nbsp;77. Les binaires pour Intel ont été linké avec la GNU
libc 2.1, donc vous devez l'installer aussi pour une mise à jour.
<h2><a name="ss9.2">9.2 Construire votre propre compilateur
croisé</a></h2>
<p>Avant toute chose, téléchargez les paquetages des sources et les
patches :</p>
<ul>
<li>binutils-2.8.1.tar.gz</li>
<li>binutils-2.8.1-2.diff.gz</li>
<li>egcs-1.0.3a.tar.gz</li>
<li>egcs-1.0.3a-1.diff.gz</li>
<li>glibc-2.0.6.tar.gz</li>
<li>glibc-crypt-2.0.6.tar.gz</li>
<li>glibc-localedata-2.0.6.tar.gz</li>
<li>glibc-linuxthreads-2.0.6.tar.gz</li>
</ul>
Ce sont les versions actuellement recommandées. Des versions plus
anciennes peuvent marcher comme elles ne peuvent pas marcher. Si
vous essayez d'utiliser des versions plus anciennes, ne nous
envoyez pas de rapport de bug s'il vous plaît ; nous n'y préterons
pas attention. Lors de l'installation, veuillez procéder dans
l'ordre binutils, egcs, puis glibc. A moins que vous ayez des
versions plus anciennes déjà installées, le fait de changer l'ordre
<i>fera</i> échouer l'installation. La description de
l'installation suivante mentionne un certain nombre de patches que
vous pouvez récupérer à partir des paquetages SRPM respectifs sur
<a href="ftp://oss.sgi.com">oss.sgi.com</a>. Cependant, puisque ces
paquetages SRPM sont censés être compilés dans la bonne
architecture, il n'est pas possible de simplement les recompiler.
<h2><a name="ss9.3">9.3 Espace disque nécessaire</a></h2>
<p>Vous devez choisir un répertoire pour l'installation. Je ferais
référence à ce répertoire par &lt;prefix&gt;. Pour éviter certain
problème, il vaut mieux utiliser la même valeur pour &lt;prefix&gt;
que pour le gcc natif. Par exemple, si votre gcc est installé dans
/usr/bin/gcc alors choisissez /usr pour &lt;prefix&gt;. Vous devez
utiliser la même valeur de &lt;prefix&gt; pour tous les paquetages
que vous allez installer.</p>
<p>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 &lt;prefix&gt;. 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.</p>
<h2><a name="ss9.4">9.4 Ordre des octets</a></h2>
<p>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.</p>
<p>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 <a href=
"#hardware-platforms">Hardware Platforms</a> pour l'ordre des
octets des machines.</p>
<h2><a name="ss9.5">9.5 Les noms de configuration</a></h2>
<p>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 &lt;cpu&gt;-&lt;entreprise&gt;-&lt;SE&gt; voire même
&lt;cpu&gt;-&lt;entreprise&gt;-&lt;noyau&gt;-&lt;SE&gt;. 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 <i>devez</i> 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.</p>
<p>Je ferais maintenant référence au nom de configuration cible par
&lt;target&gt;.</p>
<h2><a name="ss9.6">9.6 Installation de GNU binutils</a></h2>
<p>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 :</p>
<pre>
   gzip -cd binutils-&lt;version&gt;.tar.gz | tar xf -
   cd binutils-&lt;version&gt;
   patch -p1 &lt; ../binutils-&lt;version&gt;-mips.patch
   ./configure --prefix=&lt;prefix&gt; --target=&lt;target&gt;
   make CFLAGS=-O2
   make install
  
</pre>
Cela 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.
<h2><a name="ss9.7">9.7 Assert.h</a></h2>
<p>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
&lt;prefix&gt;/&lt;target&gt;/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.</p>
<h2><a name="ss9.8">9.8 Installation des sources du noyau</a></h2>
<p>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.</p>
<p>Maintenant, allez dans le répertoire
&lt;prefix&gt;/&lt;target&gt;/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.</p>
<h2><a name="ss9.9">9.9 Première installation d'egcs</a></h2>
<p>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 :</p>
<pre>
   gzip -cd egcs-1.0.3a.tar.gz | tar xf -
   cd egcs-&lt;version&gt;
   patch -p1 &lt; ../egcs-1.0.3a-mips.patch
   ./configure --prefix=&lt;prefix&gt; --with-newlib --target=&lt;target&gt;
   make SUBDIRS="libiberty texinfo gcc" ALL_TARGET_MODULES= \
           CONFIGURE_TARGET_MODULES= INSTALL_TARGET_MODULES= LANGUAGES="c"
 
</pre>
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 :
<pre>
   make SUBDIRS="libiberty texinfo gcc" INSTALL_TARGET_MODULES= \
           LANGUAGES="c" install
 
</pre>
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.
<h2><a name="ss9.10">9.10 Tester ce que vous avez fait
jusqu'ici</a></h2>
<p>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.</p>
<h2><a name="ss9.11">9.11 L'installation de la GNU libc</a></h2>
<p>Faites :</p>
<pre>
   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 &lt; ../glibc-2.0.6-mips.patch
   mkdir build
   cd build
   CC=&lt;target&gt;-gcc BUILD_CC=gcc AR=&lt;target&gt;-ar RANLIB=&lt;target&gt;-ranlib \
         ../configure --prefix=/usr --host=&lt;target&gt; \
         --enable-add-ons=crypt,linuxthreads,localedata --enable-profile
   make
 
</pre>
Vous avez maintenant une GNU libc compilée qui doit encore être
installée. <i>Ne</i> faites <i>pas</i> 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 &lt;somedir&gt; à partir du quel nous déplacerons
dans le répertoire cible actuel les parties que nous avons besoin
pour la compilation croisée :
<pre>
   make install_root=&lt;somedir&gt; install
 
</pre>
Maintenant pénétrez dans &lt;somedir&gt; et installez finalement la
GNU libc manuellement
<pre>
   cd usr/include
   find . -print | cpio -pumd &lt;prefix&gt;/&lt;target&gt;/include
   cd ../../lib
   find . -print | cpio -pumd &lt;prefix&gt;/&lt;target&gt;/lib
   cd ../usr/lib
   find . -print | cpio -pumd &lt;prefix&gt;/&lt;target&gt;/lib
 
</pre>
La 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 :
<pre>
   cd ../info
   gzip -9 *.info*
   find . -name \*.info\* -print | cpio -pumd &lt;prefix&gt;/info
 
</pre>
Si vous n'avez pas de programme d'amorce, votre installation n'est
pas finis
<h2><a name="ss9.12">9.12 Recompilation d'egcs</a></h2>
<p>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 :</p>
<pre>
   gzip -cd egcs-&lt;version&gt;.tar.gz | tar xf -
   cd egcs-&lt;version&gt;
   patch -p1 &lt; ../egcs-1.0.3a-mips.patch
   ./configure --prefix=&lt;prefix&gt; --target=&lt;target&gt;
   make LANGUAGES="c c++ objective-c f77"
 
</pre>
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 :
<pre>
   make LANGUAGES="c c++ objective-c f77" install
 
</pre>
Vous avez presque terminé. Si vous pensez ne pas avoir besoin des
compilateurs Objective&nbsp;C ou F77, vous pouvez les enlever des
commandes ci-dessus ; chacune vous sauvera environ 3 Mo. Ne
compilez pas gcov, protoize ou unprotoize.
<h2><a name="ss9.13">9.13 Dois-je compiler les compilateurs C++,
Objective&nbsp;C ou F77 ? La réponse à cette question dépend
largement de l'utilisation que vous ferez de votre environnement de
compilateur croisé. Si vous avez pour unique but de recompiler le
noyau Linux alors vous n'avez pas besoin d'une configuration pleine
à craquer et vous pouvez ommettre en toute sécurité les
compilateurs Objective&nbsp;C et F77. Vous devez, cependant,
compiler le compilateur C++, parce que la compilation des
bibliothèques inclues avec la distribution d'egcs nécessite
C++.</a></h2>
<h2><a name="ss9.14">9.14 Problème connu lors de compilation
croisée</a></h2>
<h3>Plantage d'IRIX</h3>
<p>Origin&nbsp;200 tournant sous IRIX 6.5.1 peut se planter lors
d'un "make depend" dans les sources de noyau Linux. IRIX&nbsp;6.5
sur un Indy et IRIX&nbsp;6.5.4 sur un Origin&nbsp;200 sont connus
pour fonctionner correctement. Tout rapports pour aider à isoler le
problème de configuration est la bienvenue.</p>
<h3>Ressources limitées sur les machines basées sur le standard
System&nbsp;V</h3>
<p>Les Unix basés sur le standard System&nbsp;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.</p>
<h2><a name="ss9.15">9.15 GDB</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="s10">10. Litteratures sur le même thème</a></h2>
<h2><a name="ss10.1">10.1 Voir un MIPS tourner (See MIPS
Run)</a></h2>
<p>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 :</p>
<ul>
<li><a href=
"http://www.algor.co.uk/algor/info/seemipsrun.html">http://www.algor.co.uk/algor/info/seemipsrun.html</a>
(europe)</li>
<li><a href=
"http://www.mkp.com/books_catalog/1-55860-410-3.asp">http://www.mkp.com/books_catalog/1-55860-410-3.asp</a>
(US)</li>
</ul>
et chez tous les bonnes librairies. Il contient 512 pages et coûte
environ 50 $ aux Etats-Unis et 39.95 � au Royaume-Unis. J'aimerais
parler de deux autres livres aussi, publiés chez Morgan Kaufmann et
disponible sur www.mkp.com ou chez n'importe quelle librairie :
<h2><a name="ss10.2">10.2 Le manuel du programmeur MIPS (The MIPS
Programmer's Handbook)</a></h2>
<p>auteurs Farquhar et Bunce, publié par Morgan Kaufmann,
ISBN&nbsp;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.</p>
<h2><a name="ss10.3">10.3 Architecture informatique - Une approche
quantitative (Computer Architecture - A Quantitative
Approach)</a></h2>
<p>auteurs Hennessy &amp; Patterson, publié chez Morgan Kaufmann,
ISBN&nbsp;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 <em>semblable</em> au MIPS ... Son seul défaut est sa taille
et son poids - mais à la différence des gros bouquins, il le vaut à
chaque page.</p>
<h2><a name="ss10.4">10.4 Supplément pour les processeur MIPS ABI
sous UNIX System&nbsp;V (UNIX System&nbsp;V ABI MIPS Processor
Supplement)</a></h2>
<p>par Prentice Hall, publié le 05 1991, ISBN&nbsp;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
<em>"http://www.mipsabi.org/"</em> ne répond plus.</p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / MIPS-HOWTO.html
