Vielleicht bedarf es eines Haufens Erklaerungen, warum manchmal Dinge faszinieren, die veraltet und unbeeindruckt von technischer Komplexitaet daherkommen und angesichts der technischen Entwicklung der letzten Jahre Schmerzen verursachen, die man sich nicht antun muesste.
Manchmal passieren Dinge, die einem laengst vergessene schlechte Ideen wieder in den Kopf bringen. So geschehen am vergangenen Freitag, wo ein Bekannter ein Notebook auf meinen Schreibtisch stellte. Eigentlich hatte ich nach altem Notebook-SDRAM gefragt, fuer ein anderes Bastelprojekt, stattdessen stellt er ein altes Toshiba Satellite 220CS auf meinen Tisch. Alt, grau und stabil. Das Gewicht laesst meinen Schreibtisch ein beschwertes Aechzen von sich geben und ich fuerchte kurz, er koennte brechen. Es ist definitiv ein Geraet aus einer Zeit, in der SDRAM noch eine Technik war, auf die man mit Andacht und Ehrfurcht blickte. “Mach damit, was du willst, bei mir steht das nur im Keller.” – eindeutige Worte.
Notebooks diesen Alters haben oft – wie hier – eine himmlische Tastatur…
Was macht man mit so einer Seegurke? Kaum 133 Mhz, PCMCIA ist vorhanden, aber offenbar defekt, das 800×600 Pixel einfassende DSTN Display hat weniger kontrast der Himmel an verregneten Wintertagen… erzaeugt aber dafuer zumindest ein aehnlich deutliches Bild. “Ich weiss nur, dass der Akku kaputt ist”, fuegt er noch an und das ist genau das, was ich hoeren wollte. Mir faellt mein Urmelaltes Escom Notebook ein – ein Intel 80486 mit 66 Mhz, also ein Geraet aus der gleichen Aera. Vor einiger Zeit sollte auf diesem Stueck Geschichte mit 20MB RAM ein kleines Debian zum Einsatz kommen um meinen MPD auf der anderen Seite des Wohnzimmers fernzusteuern. Das Unternehmen scheiterte daran, dass die Display-Schaniere ausgebrochen waren – offensichtlich loest sich auch der beste Kunststoff irgendwann auf. Weiterhin war das Display kaum zu lesen und mit dem Standard Debian Kernel war das System nicht zu booten, da der Speicherbedarf des initramfs und dessen Extraktion schon die vorhandenen Ressourcen ueberstieg. Nun sind 32MB auch nicht sehr viel mehr, doch die aufkommende SIGINT Konferenz in Koeln und die damit verbundenen Stunden am Tisch mit Notebook liessen den Unterschied zwischen 32MB und 20MB gross genug erscheinen, um mit diesem Geraet einen neuen Versuch zu wagen. Ohnehin ist die Tastatur dieses alten Toshiba Notebooks ein Traum, den man nicht austraeumen moechte.
Leider erledigte sich der Traum vom Debian auf dem Toshiba ebenfalls recht schnell, da auch hier die initrd nicht entpackt und das System daher nicht gestartet werden konnte. Ich beschloss daher, mich erneut an einer buildroot-umgebung zu versuchen. Nach einiger Probiererei – die die Aufmerksamkeit des D-Radios auf sich zog, das auf der SIGINT Interviews durchfuehrte [1] (Tonbeitrag unten) – hatte ich erfolg mit einer git-Version und machte mich daran den Kernel zu bauen. Als alles im Endeffekt zumindest in einer VM bootete und ich unmengen an Treibern mit einkompiliert hatte, um die bisher vollkommen unbekannte Hardwarelandschaft des Geraetes zu ergruenden, machte ich mich an einen Boot-Versuch auf der Originalhardware. Ich stellte fest, dass der alte ISA-IDE-Controller mit dem pata_isapnp modul nicht funktionieren wollte. Zwar wurde die Festplatte erkannt, jedoch konnte man von ihr nicht lesen. Erfolg hatte ich mit pata_legacy.
Ich machte mich also daran, die Vernetzung des Systems zu planen. Angedacht war, dem Notebook via PCMCIA eine Wlan-Karte zu spendieren – zugegeben eine recht langweilige Angelegenheit. Waehrend meiner Versuche stellte ich allerdings fest, dass die Buildroot-Umgebung ohne PCMCIA-Utils daherkommt. Ohnehin schien aber der PCMCIA-Teil des Notebooks ein paar Fehler zu haben, da weder PCMCIA-Karten noch Cardbus-Karten zu irgendeinem Resultat fuehrten. PCMCIA und Cardbus stellten sich also als Sackgasse heraus und in Ermangelung eines erkennbaren IRQ war auch der eingebaute USB-Controller, den ich als Fallback im Hinterkopf hatte, nicht nutzbar. Etwas ernuechtert war ich kurz davor aufzugeben, als ich im Tool zur Kernelkonfiguration einen laengst vergessenen Schalter fand: “SLIP”. Meine Erfahrungen mit SLIP stammen nicht aus der Zeit, in der man SLIP benutzt haette, weil nichts anderes zur Verfuegung stand, sondern aus einer Zeit, in der ich zu viel Zeit hatte – das liegt noch nicht ganz 2 Jahre zurueck und hatte mit einem PDA zutun, der ein bisschen Internet brauchte. Der naechste Rechner mit seriellem Port steht leider auf der anderen Seite des Wohnzimmers, ist aber wie der Zufall es so will ist genau dieses System das, was ich fernbedienen will. Dennoch sind etwa 6-8m Kabel von der einen Stelle des Wohnzimmers bis zur anderen noetig und ich zweifle ein wenig daran, dass ueber diese Leitungslaenge mit Klingeldraht, welchen ich noch in rauhen Mengen vorraetig habe, eine stabile Verbindung zustande kommt. Ich hoffe also insgeheim weiter dass aus irgendeinem Grund der USB-Controller doch noch laeuft – doch werde enttaeuscht. Immer die gleiche Meldung bringt mich beim Laden des Kernelmoduls davon ab, weiter zu hoffen. Ich vermute, dass generell der PCI-Teil des Geraetes eine Macke hat und freue mich, dass wenigstens die Grafikkarte noch funktioniert und mache mich an die Optimierung der groesse von Kernel und buildroot.
Was einen 2.6.34-Kernel auf so alter Hardware angeht, habe ich jegliche Bedenken abgelegt. Zwar ist der Kernel um ein vielfaches neuer als die Hardware, dennoch sind keine essentiellen Funktionen und Treiber aus dem Kernel verschwunden. ISA haelt sich auch in modernen Rechnern zur Systemueberwachung noch hartnaeckig – auch wenn Microsoft inzwischen auf eine Unterstuetzung des “echten” ISA-busses verzichtet – und das zuvor genannte legacy-Modul fuer IDE im ATA-Teil des Kernels ist sogar relativ frisch. Ich deaktiviere also fleissig alle Punkte die ich nicht brauche, komme aber trotz allem noch auf knapp 300 Zeilen Kernel-Konfiguration. Ich deaktiviere zusaetzlich noch die Unterstuetzung fuer Kernelmodule und komme abschliessend auf ein 860kiB grosses Kernel Image. Mit dem Buildroot habe ich zunaechst noch grosses vor. Ich baue SDL und DirectFB ein, weiss selbst nicht genau warum und nehme es im Endeffekt wieder heraus. Schliesslich ist die fernbediente Applikation auch nur eine Konsolenanwendung auf die via SSH zugegriffen wird. Auch eine Reduktion der Busybox-Funktionen bringt eine erhebliche Einsparung. Da ich mich auch gegen die Verwendung der Soundkarte entscheide, fliegen ALSA und Co aus der Umgebung. Nur ein Bildbetrachter fuer die Verwendung mit dem Framebuffer bleibt erhalten – schliesslich ist, wenn man betrachtet, dass auch heute noch viele billige digitale Bilderrahmen DSTN-Displays benutzen eine Verwendung als digitaler Bilderrahmen durchaus denkbar. Die vormals zu testzweicken eingebauten Wireless Utils und USB-Tools fliegen ebenso aus dem Image wie das vormals zur Vorsicht eingebaute IPTables, das aber mittlerweile auch meine Kernel-Config nicht mehr beinhaltet. Am Ende habe ich mit Kernel und Umgebung eine Groesse von 24 MB erreicht und bin relativ unzufrieden. Das muss noch kleiner gehen, denke ich bei mir und mache mich auf die Suche nach den Platzhirschen in /usr/lib. Nachdem ich feststelle, dass auch die entfernten libraries wieder in die Umgebung landen beisse ich in den sauren Apfel und bereinige die Build-Umgebung um nocheinmal alles von neuem bauen zu lassen. Indes denke ich darueber nach, wie ich wohl das neue Image auf die Maschine bekomme, ohne meine bereits angepasste Konfiguration und die Scripte zu verlieren.
[ash] joel@nireko:~$> sudo du -hsx /
6.9M /[ash] joel@nireko:~$> mount
rootfs on / type rootfs (rw)
/dev/root on / type ext3 (rw,…)
proc on /proc type proc (rw,…)
devpts on /dev/pts type devpts (rw,…)
tmpfs on /tmp type ramfs (rw,…)
sysfs on /sys type sysfs (rw,…)
Das neubauen der Umgebung bringt einige Zeit spaeter das Root-Filesystem mit kernel auf etwas ueber 8MB – schon eher eine Hausnummer, die ich anpeile. Die Groesse beinhaltet das Linux-System mit Dokumentationen und den Kernel. Ein SSH-Client ist in form von dropbear vorhanden, das zur Verwendung von SLIP notwendige slattach ist in der busybox enthalten – und unterstuetzt den fuer mich unerlaesslichen 3-wire-Modus, bei dem auf die Verwendung der Flow-Control Pins verzichtet wird.
Traffic-Indikator leicht gemacht.
Um das Geraet in seinen endgueltigen Zustand zu bringen, fehlen mir allerdings noch 2 Hardware- Modifikationen. Das serielle Kabel fuer die Internet-Verbindung sowie einen CF-Karten-Adapter, um CF-Karten im mini-IDE HDD-Bay des Geraetes unterzubringen. Dies spart Energie und die Nerven der Leute, die relativ haeufig auf meiner Couch schlafen und sich sonst naechtliche Spin-Up-Down-Ortien anhoeren duerften (was mich an einige Naechte auf einem Fussboden in Buederich erinnert, wo ein sehr aehnliches Notebook mir um ein Haar den letzten Nerv geraubt haette… das war eine der Naechte in denen ich sowas getraeumt habe, wie ich hier bereits schrieb: siehe hier) . Das Material – 2 DB9(male) Stecker, 7m 4adrige Rangierleitung, 1 LED (niederstrom) – fuer das Kabel habe ich immer im Haus… anders sieht es mit dem IDE Bay aus, den ich bei eBay ersteigere. Ein Haendler bietet fuer etwa 6 Euro eien Adapter an, der 2 CF-Karten fassen kann und diese als Master/Slave an den IDE-Bus anbindet. Die Idee gefaellt und somit kaufe ich das Teil.
Was das Kabel anbelangt, so ist alles schnell erledigt. An beiden Seiten loete ich die 3 der 4 Adern an RX(2), TX(3) und GND(5) – so, dass jeweils RX von der einen Seite auf dem TX der anderen Seite liegt (jeweils Pin 2 auf Pin 3 der anderen Seite). Die freie Ader moechte ich nicht offen herumliegen lassen und loete sie an die Steckermasse. Was die LED anbelangt, so bringe ich diese an Notebook Seite an der RX-Leitung und der Masse an. So leuchtet sie bei eingehendem Datenverkehr und geht hoffentlich nicht so schnell kaputt 
(was sie wird, wenn man sich den Pegel von RS232 anschaut).
Nachdem das Kabel gebaut, die CF-Karte mit Image und Bootloader bespielt und ein SLIP-Server aufgesetzt ist, ist es endlich fertig… Willkommen auf der umstaendlichsten Fernbedienung der Welt:
In dieser Situation macht es Sinn, die Applikation auf einem anderen System auszufuehren, da der RAM sehr begrenzt ist
Hier noch ein paar Erkenntnisse, die ich nebenher erkannt habe:
- Linux IST ein sehr schlankes Betriebssystem, wenn man will
- Alte Hardware ist stabil, haesslich und man muss sie einfach lieben
- Stundenlanges Suchen nach dem BIOS-Setup Entry Key: Das Satellite kommt mit ESC gefolgt von F1 ins BIOS Setup
- 90% der Kernel Features baut man nur ein, weil man da “vielleicht irgendwann mal mit basteln will”[tm]
- Der “kaputte” Akku haelt noch 2 Stunden
- manchmal sollte der RAM DEUTLICH groesser sein, als das OS in Summe an Festplattenspeicher belegt…
Danke an Kappa fuer das Notebook
Tonbeitrag aus dem D-Radio: Hacker auf der SIGINT 2010
Config-Files zum selbst bauen: buildroot busybox kernel 2.6.34
