Inhaltsverzeichnis
Linux auf Nicht-Intel-Hardware
Daß Linux auf Intel-kompatiblen Rechnern (auch "PCs" genannt) läuft, ist mittlerweile weithin bekannt. Neben den günstigen Rechnern, die man beim Fachmann oder im Aldi käuflich erwerben kann, gibt's natürlich auch noch richtige Rechner, die ein paar Vorteile mit sich bringen:
- Die Rechner sind (obwohl sie meist nicht an die Megahertz-Zahlen von PCs herankommen) deutlich schneller als PCs
- Die Hardware kommt oft aus einer Hand, man hat weniger Kompatibilitäts-Probleme
- Solche Exoten zu benutzen macht mehr Spaß als das Daddeln auf PCs:-)
Auf der anderen Seite sind da natürlich noch kleine, alte Schätzchen, auf denen man auch Linux laufen lassen kann. Dazu zählen z.B. einige Amigas und Ataris...
Allgemeine Tips zu Exoten
Die teueren Modelle unterstützen fast alle SerielleConsole
Viele Modelle können über NetzBooten
Worauf kann man Linux denn nun laufen lassen?
LinuxAufAlpha (DEC Alpha)
LinuxAufHPPA (HP-Rechner)
LinuxAufIA64 (Diverse 64bit Intel-basierende Systeme)
LinuxAufm68k (Amiga, Atari, frühe Macintosh- und Sun-Systeme, ...)
LinuxAufSparc (Sun)
LinuxAufPPC (Apple/Macintosh, IBM-RS6000)
LinuxAufS390 (Mainframe von IBM)
LinuxAufMIPS (von SGI, DEC und oft auch in Embedded-Systemen)
LinuxAufStrongARM (Oft in Embedded-Systemen)
LinuxAufSH (Oft in Embedded-Systemen, z.B. einige Windows CE Geräte (meist SH3), oder die Dreamcast (SH4))
LinuxAufX86_64 AMDs 64bit-Hammer
LinuxAufXBOX Xbox Linux (Benutzt zwar einen i386er Prozessor ist aber doch ein Exot)
LinuxAufC64 Commodore C64 Linux (Kult...)
LinuxAufWLanRoutern Linux läuft möglicherweise auch auf eurem W-Lan Router
- ...
Übersicht über die Consolen-Befehle der unterschiedlichen "BIOS"-Typen
Sparc-Hardware benutzt die OpenPROM Console (Sparc_BIOS_OPC)
Alphas benutzen entweder SRM (Alpha_BIOS_SRM) (->Wofür steht SRM eigentlich?) (ist zum Booten von Unix-Systemen gedacht) oder AlphaBIOS (Alpha_BIOS_AlphaBIOS), was an sich mal zum Booten von WinNT gedacht war. SRM ist Textmode (meist mit blauem Hintergrund) mit >>> als Prompt; AlphaBIOS sieht eher wie ein Win31 aus...
- ...
Die wichtigsten Links auf einem Blick
alpha-linux
arm-linux
hppa-linux
http://www.parisc-linux.org/ (englisch) - 32- und 64-bit PA-RISC (PA = Precision Architecture), von HP entwickelt
hppa64-linux
http://www.parisc-linux.org/ (entlisch) - 32- und 64-bit PA-RISC (PA = Precision Architecture), von HP entwickelt
ia64-linux
m68k-linux
http://www.linux-m68k.org/ (englisch) - betrifft Motorolas 680x0-Prozessoren, die in neueren Atari-/Amiga- und in Apple Macintoshs stecken. (Im Atari ST steckt leider nur ein 68000er, mit dem TT sollte Linux kein Problem sein. Umgekehrt ist STONX ein Atari-Emulator für Linux.)
mips-linux
mips64-linux
mipsel-linux
ppc-linux
ppc64-linux
sh4-linux
s390-linux
s390x-linux
sparc-linux
http://osinvestor.com/sparc/ - Aktueller Status von 2.4.x und 2.5.x auf sparc32-Hardware
sparc64-linux
Eine Sun Blade 100 ist ein 64bitter, hier ist die Installation z.Z. (woody) nicht so ganz einfach. Wenn man das System einfach so booten will, gibt es reichlich Fehler und von einem realen Start des Installationsprozesses ist nicht zu reden. flo hat mich auf den richtigen Weg gebracht, auf lists.debian.org http://lists.debian.org/search.html zu suchen und zu finden (wo sonst?). Eine funktionierende Beschreibung gibt es, wenn man dort nach "blade 100" sucht, im List filter "sparc" markiert und im Date filter die Jahre 2002-2003 mitnimmt. Als Ergebnis kommen eine Haufen Verweise, den richtigen zu finden ist aber nicht so schwer. Auf jeden Fall braucht man einen weiteren PC und ein Netzwerk, da der zweite Rechner einige Dienste zu Verfügung stellen muß:
- rarpd
- tftpd
- nfs
Zusätzlich muß man noch einiges an Dateien 'runterladen, die Ben Collins http://auric.debian.org/~bcollins/ zur Verfügung stellt. Und am besten legt man alle weiteren Grafikkarten still, beim booten sollte nur die Karte aktiv sein, die auf dem Motherboard integriert (ATI) ist... Ansonsten ist der Installationsvorgang und das Handling wie bei einem x86. Ein Ausnahme: Niemals Nie Nicht "fdisk /dev/hda" aufrufen, und danach nicht so butz booten. Es kann dann passieren, daß "/" danach read-only ist. Und dann braucht es einige fsck Läufe, bis die Karre wieder brummt. Daher sollte man auch bei der Installation schon ext3 einrichten und benutzen und fdisk nur im Single User Mode...
x68_64-linux
c64-linux
*-linux
Bisher gibt es leider noch das Problem, daß die Änderungen für die einzelnen Portierungen noch nicht in den Linux-Baum von Linus eingeflossen sind. Daher gibt es Bestrebungen, einen zentralen Linux-Baum, der für alle Architekturen funktioniert, aufzusetzen. UnifyAllLinuxPorts
Wie schnitzt man einen Cross-Compiler?
Bei vielen Architekturen sind Benutzer-Programme (gewohnt) stabil am Laufen, aber der Linux-Kernel läuft nicht allzu stabil, was sich dann später in Abstürzen äußert. Da viele Nicht-Intel-Architekturen von der Geschwindigkeit her nicht mit aktuellen Gigahertz-Monstern imthalten können (alte Amigas zum Beispiel), macht es Sinn, der Linux-Kernel auf einem anderen Rechner (z.B. dem normalen PC) zu kompilieren. Das Problem hierbei ist, daß der PC und die Architektur, für die der Kernel kompiliert werden soll, unterschiedliche Sprachen sprechen. Deshalb kann nicht einfach der installierte GCC (und die dazugehörigen Tools) benutzt werden. Vielmehr bracht man einen Crosscompiler, der für die Zielarchitektur ausgelegt ist.
Was hier noch fehlt, ist, daß man auch die Sourcen der glibc braucht. Auch, wenn man die glibc nicht mitkompilieren möchte, so werden doch header files daraus benötigt. Um diese wiederum zu bekommen, sind zusätzlich noch Kernel-Header-Dateien nötig, sodaß auch noch die Kernel-Sourcen bereitliegen müssen. Das muß aber noch dokumentiert werden...
Siehe auch: Cross-gcc Linux/m68k
Cross-Binutils
Sourcen besorgen
Bei den Binutils sollte man immer die aktuellste Version benutzen. Um an diese zu kommen, gibt es zwei Möglichkeiten:
- Offizielle Releases der FSF
- Aktueller CVS-Abzug
FSF-Release
Die aktuellen offiziellen Releases kann man von ftp://sources.redhat.com/pub/binutils/snapshots/ herunterladen. Dann einfach das .tar.bz2 auspacken und man hat funktionierende Sourcen.
CVS-Abzug
Will man auf dem Stand der aktuellen Entwicklung sein (was bei Binutils und GCC durchaus hilfreich sein kann), so sollte man sich den akuellen CVS-Stand besorgen. Da im CVS-Baum auch einige weitere Tools eingelagert sind, die wir nicht benötigen, ist dieses etwas aufwendiger (da beim Compilieren versucht würde, alle diese Tools zu bauen, was vollkommen unnötig ist und dazu führt, daß ein Dutzend weiterer Entwicklungs-Pakete installiert sein müßte...) Hier also das Vorgehen:
$ # 1. Einmalig am CVS-Server anmelden; Password ist "anoncvs" $ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src login $ # 2. Nun die Sourcen herunterladen... $ cvs -z9 -d :pserver:anoncvs@sources.redhat.com:/cvs/src co binutils $ cd src $ # ...oder aktualisieren $ cd src $ cvs update $ # Als nächstes daraus die "wichtigen" Sourcen extrahieren, indem wir selbst ein "Release" erzeugen $ make src-release binutils.tar.bz2 $ cd .. $ # ...und das Ding irgendwo auspacken $ cd /tmp $ tar xjf ..../binutils-2.*.tar.bz2
Binutils bauen
Binutils (wie auch die GCC) werden nicht in ihrem eigenen Source-Tree gebaut. Das ist ein großer Unterschied zu anderen Programmen, die fast immer innerhalb ihres eigenen Source-Trees gebaut werden.
$ cd /tmp $ mkdir binutils-build-dir $ cd binutils-build-dir $ ..../configure --target=mips-linux --disable-nls --prefix=~/bin $ make $ make install
Unter --target wird der Name der Ziel-Platform angegeben. Sinnvoll sind da z.B.:
- mips-linux
- mipsel-linux
- ppc-linux
- ...
Unterstützung für mehrere Sprachen braucht man bei Toolchain auch nicht wirklich und wird deshalb abgeschaltet (--disable-nls). Weiterhin sollte man angeben, wohin die Programme installiert werden sollen. Dabei sollte man nicht /usr angeben, da später u.U. Teile des normalen Compilers überschrieben werden könnten.
Cross-GCC
Sourcen besorgen
Beim GCC gibt es, im Gegensatz zu den Binutils, mehrere parallele Entwicklungs-Zweige, von denen nicht jeder für das ausgewählte Target funktioniert.
FSF-Release
Die offiziellen Releases funktionieren ganz gut für all die Platformen, die schon etwas älter sind und eine geweisse Verbreitung haben. Das sind z.B. Alpha, m86k und sparc. Bei selteneren Platformen (oder junge Portierungen auf neue oder sehr seltete Platformen) ist meistens die CVS-Abzüge besser geeignet.
CVS-Abzug
Die CVS-Abzüge geben Zugang zu den unterschiedlichen Entwicklungs-Linien der GCC. Diese sind, gerade für die selteneren Platformen, oft besser geeignet als die FSF-Releases.
GCC bauen
Hier fehlt noch viel, aber der Anfang ist:
$ # Für gcc-3.4
$ ../gcc/configure --prefix=/home/jbglaw/bin/ --target=mips-linux \
--enable-languages=c --disable-nls \
--disable-shared --disable-threads
$ # Allgemein für gcc-3.x (falls die mips-linux-*****-Programme nicht automatisch erkannt werden):
$ ../gcc/configure --prefix=/home/jbglaw/bin/ --target=mips-linux \
--enable-languages=c --disable-nls \
--disable-shared --disable-threads \
--with-ar=/home/jbglaw/bin/bin/mips-linux-ar \
--with-as=/home/jbglaw/bin/bin/mips-linux-as \
--with-ld=/home/jbglaw/bin/bin/mips-linux-ld \
--with-nm=/home/jbglaw/bin/bin/mips-linux-nm \
--with-objcopy=/home/jbglaw/bin/bin/mips-linux-objcopy \
--with-ranlib=/home/jbglaw/bin/bin/mips-linux-ranlib
$ make
$ make installTODO: Document --with-headers=...