Thema: Der große tyndur-Blog-und-Twitter-Ersatzthread

[kevin]

Mir ist gerade danach, ein bisschen mehr Hintergrund zu meinen Andeutungen von gestern zu geben, ohne dass ich allerdings unbedingt einen kompletten Lagebericht wie für den Status-Thread passend zusammenstellen will. Daher hier mal ein Thread für alles mögliche und unmögliche, das in irgendeinem Zusammenhang mit tyndur steht, vielleicht sogar aktuell ist und unbedingt in die Welt raus muss, vom Einzeiler bis zum Roman. Kommentieren ist ausdrücklich erlaubt.

Gestern habe ich mir kedit-Verbesserungen gewünscht, um Treiber debuggen zu können. Vielleicht ist der Zusammenhang da nicht auf Anhieb klar, und außerdem möchte ich nicht den Eindruck erwecken, dass ich einfach nur die ganze Arbeit von anderen gemacht sehen will [1].

Ich komme wohl nicht drum herum, bei XanClics USB-Patches anzufangen, an denen er in den letzten paar Tagen geschraubt hat. Diese Chance, ihm schonungslos seine Fehler aufzuzeigen, konnte ich mir natürlich nicht entgehen lassen. Und so habe ich mein gutes altes, momentan anderweitig unbenutztes Thinkpad T500 ausgegraben und den USB-Treiber darauf losgelassen. Mit Erfolg, das hat nämlich erstmal ein paar Bugs aufgedeckt, aber nach ein, zwei Tagen hat alles soweit funktioniert und ich kann jetzt tyndur vom USB-Stick booten. Ziemlich coole Sache.

Nun da ich eine Möglichkeit hatte, tyndur ziemlich leicht auf echter Hardware zu testen, ohne ständig zu rebooten oder CDs zu brennen, war natürlich nicht der nächste Gedanke nicht fern: Wäre doch nett, wenn der Rest von diesem Stück Hardware auch funktionieren würde. Wir haben ziemlich viele Treiber, die zwar im Emulator tun, aber auf diesem Laptop irgendwie doch nicht: Da wären AHCI und hdaudio, und wir haben einen Treiber für e1000, aber nicht für den vermutlich recht ähnlichen e1000e.

Aber selbst einen USB-Stick ständig umzustecken und nach jeder Debugging-Änderung ein neues Image draufzuspielen war mir mit der Zeit dann doch noch zu umständlich. Stattdessen habe ich mir Compiler, binutils, tyndur-libc und libcdi auf das Image gepackt, dazu noch den Quellcode von den Treibern, und versuche jetzt, die Probleme an Ort und Stelle auf dem Laptop zu debuggen. Mit kedit am Code rumpfuschen, durchbauen, probieren, Treiberprozess wieder killen und von vorne. Geht wesentlich schneller, und selbst die ab und zu nötigen Reboots, weil der ext2-Treiber über den Jordan gegangen ist (oder der zu debuggende Treiber die Konsole so vollspammt, dass man nichts mehr erkennen kann ), ändern da nichts daran.

Nur macht das Editieren mit kedit halt nur bedingt Spaß, wenn man eine Zeile nicht einfach mal veschieben kann, sondern sie löschen und an anderer Stelle neu tippen muss... Da fängt man auf einmal an, den Code strategisch zu editieren, um ja so wenig wie möglich verschieben zu müssen. Deswegen die Frage, ob da nicht nebenher jemand was dran machen will, während ich noch an den Hardwaretreibern hänge.

Die andere Möglichkeit, sich an der Hardware-Offensive zu beteiligen, wäre natürlich, einfach mal selbst tyndur auf echte Hardware loszulassen und schauen, was alles tut und wo es noch etwas zu tun gibt (und es dann natürlich auch hier oder im IRC mit uns zu teilen!). Für CD gibt es nach wie vor die Nightlies von LittleFox, das USB-Image muss im Moment noch von Hand aus Max' Branch gebaut werden.

Soweit mal für heute mit dem ausführlichen Einstiegsbeitrag, in den nächsten Tagen gibt es dann wahrscheinlich eher die kürzeren Updates.


[1] Der Eindruck wäre natürlich trotzdem nicht hundertprozentig falsch...

[kevin]

Zu AHCI hatte ich ja vor ein paar Tagen schon was geschrieben. Platte anschalten hilft. Für den Moment reicht mir das, aber das CD-Laufwerk im Laptop will noch nicht. Darauf muss ich später nochmal zurückkommen, wenn mir keiner zuvorkommt.

Bei hdaudio tut der Player zwar so als würde er etwas abspielen, aber es bleibt verdächtig ruhig. Mein Treiber findet drei veschiedene Output-Widgets in der Funktionsgruppe, die ich vermutlich haben will - das sind wohl interner Lautsprecher, Kopfhörer und keine Ahnung was. Der Treiber nimmt einfach den erstbesten davon. Entweder spiele ich also gerade auf dem "keine Ahnung was"-Output ab, irgendwas ist noch auf mute, oder ich müsste irgendwelche Verbindungen zwischen Widgets noch einrichten. Als nächstes sollte ich mir vermutlich mal anschauen, welche Widget so allgemein herumschwirren, wie sie zusammengehören und wofür die alle gut sind. Wenn ich das Pin-Widget zum Output-Widget finde, müsste ich eigentlich sagen können, was das ist (und ob da auch was eingesteckt ist).

Grundsätzlicher stellt sich die Frage, wie man überhaupt mit mehreren Outputs umgehen sollte. Prinzipiell wäre es ja schon nett, auf Lautsprecher und Kopfhörer gleichzeitig was abspielen zu können, wozu das unterschiedliche CDI-Geräte sein sollten. Aber völlig unabhängig sind sie dann auch wieder nicht, weil die Hardware begrenzte Ressourcen hat und nicht auf allen Outputs gleichzeitig spielen kann, wenn das mal ein paar mehr sind. Vielleicht ist die richtige Lösung, das CDI-Interface irgendwie zu erweitern, dass es verschiedene Outputs pro Gerät kennt - und die faule Lösung für den Anfang, einfach irgendeinen sinnvollen Output zu nehmen (Kopfhörer falls eingesteckt, sonst Lautsprecher; über "Hotplug" von Kopfhörern will ich mir gerade aber auch keine Gedanken machen...)

[TheThing]

Mit Erfolg, das hat nämlich erstmal ein paar Bugs aufgedeckt, aber nach ein, zwei Tagen hat alles soweit funktioniert und ich kann jetzt tyndur vom USB-Stick booten. Ziemlich coole Sache.
[...]
Aber selbst einen USB-Stick ständig umzustecken und nach jeder Debugging-Änderung ein neues Image draufzuspielen war mir mit der Zeit dann doch noch zu umständlich.

Da hätte ich doch glatt den nächsten Vorschlag in Sachen Bootvorgang: Mit iPXE+NFS übers Netzwerk booten

[kevin]

Netzwerkboot wäre auch noch interessant, ja. Aber ich hab ja im ersten Beitrag schon angedeutet, dass der Netzwerktreiber für die e1000e noch fehlt, und ohne den wird das auf diesem Laptop schwierig. Und irgendein Protokoll, über das man das Dateisystem lesen kann, müsste auch noch implementiert werden. NBD könnte ich mir vorstellen, bei Gelegenheit mal zu machen. NFS überlasse ich aber gern dir.

[kevin]

Kurzes Update: Ich habe die AHCI-Fixes gestern sowohl ins tyndur- als auch CDI-Repository gepusht. Die USB-Patches habe ich soweit angefangen anzuschauen wie man noch nichts von USB zu wissen braucht.

Für meinen eigenen Code kann ich mich nicht recht entscheiden, ob ich mit e1000e oder hdaudio anfangen soll. Auf jeden Fall wären aber vermutlich ein paar CDI-Loggingfunktionen und dazu passende Debugoptionen auf die Kommandozeile mal hilfreich. #ifdef um printf()s ist auf Dauer keine besonders tolle Lösung.

[kevin]

Der CDI-e1000-Treiber implementiert zwei verschiedene Methoden, den EEPROM auszulesen (da steht die MAC-Adresse drin, deswegen wäre das ganz praktisch). Die tun aber beide nicht mit meiner Hardware. Stellt sich raus, dass Linux für dieses Modell nochmal eine ganz andere Methode verwendet. Manchmal könnte man echt denken, Hardware-Designer machen sowas absichtlich.

Immerhin scheint es eine passende Spec zu geben. Mal schauen, ob die auch halbwegs stimmt (vollständig ist sie jedenfalls schonmal nicht, aber vielleicht reicht es, ein paar Konstanten aus anderen Treibern abzuschreiben...)

[kevin]

Ich hab ganz vergessen, hier was zu schreiben nachdem es mal wieder Neuigkeiten in Sachen e1000 gibt.

Das größte Problem war es tatsächlich, die nötige Dokumentation zusammenzutragen, um den Flashspeicher lesen zu können, in dem bei meiner Onboard-e1000e die MAC-Adresse steht. Die eigentliche Implementierung ist recht einfach, man muss nur ein zusätzliches BAR mappen und hat da drin ein paar Register, die einen relativ leicht auf den Flash zugreifen lassen.

Nachdem das dann funktioniert hat mussten noch ein paar Bits hier und da ergänzt werden, dass er auch wirklich Pakete sendet und empfängt, aber halbwegs funktionierendes IRC war dann schnell erreicht. Allerdings nicht ganz zuverlässig, sondern nach einer Weile ist nichts mehr durchgekommen. Ein paar Debugausgaben später (ohne nennenswerte sonstige Änderungen) hat alles funktioniert. Debugausgaben weg, tut immer noch. Ich vermute, der Bug wird sich früher oder später wieder zurückmelden...

Außerdem braucht die Karte nach dem Initialisieren ein bisschen, bis sie entdeckt, dass sie eine Verbindung hat. Bis dahin ist tyndur mit dem DHCP-Versuch längst fertig, was natürlich nicht so geschickt ist. Man kann das dann nochmal manuell anstoßen und dann geht es, aber das ist ja auch Dauer auch nicht der Weisheit letzter Schluss.

Und schließlich sollte ich vielleicht bei Gelegenheit auch mal probieren, ob jetzt nicht zwar der Laptop tut, aber die e1000 von qemu, VirtualBox usw. kaputt sind. Das wäre ja auch eher schade.

[kevin]

Nur damit ich es selber nicht vergesse: Im ncurses-lbuild wird _nc_timed_wait() gepatcht, und es sieht mir fast so aus als würde der reingepatchte Code gar nicht benutzt, weil mittlerweile HAVE_SELECT gesetzt sein sollte. Was vermutlich bedeutet, dass ich erstens eher select() als den Hack in ncurses fixen solle, dass das auch mit blockierendem read() noch tut, und dass ich zweitens den toten Code bei Gelegenheit wegwerfen könnte.

[kevin]

select() ist jetzt soweit geflickt, dass ctris und Supertux wieder spielbar sind.

Obacht! Lynx ist noch kaputt, weil socket.h ein paar böse Hacks verwendet, die nicht mehr tun, wenn die POSIX-Dateifunktionen intern kein stdio.h mehr verwenden. Ich schätze, man kann den existierenden Hack einfach auf LIO-Streams umschreiben. (Das Problem ist, dass es einen Filedeskriptor eigentlich nur für offene LIO-Streams gibt, und direkt nach dem socket() gibt es den noch nicht, aber wir müssen den Filedeskriptor schon zurückgeben.)

[LittleFox]

Ich hab dann mal die Nightlies wieder erreichbar gemacht^^

[kevin]

Oh, sehr cool. Danke!

Vielleicht sollte ich das dann grad mal nutzen, um noch zu erwähnen, was sich in den neuen Nightlies dann verändert hat.

Das Problem mit den Sockets ist mit dem schon erwähnten angepassten Hack vorerst gelöst (einem uninitialisierten io_resource_t wird in socket() schon ein FD zugewiesen und nachdem dann connect() bzw. accept() tatsächlich ein lio_compat_open() benutzen, um die Verbindung zu öffnen, wird das zurückgegbene Objekt per memcpy drüberkopiert, so dass die Adresse gleich bleibt und der FD noch funktioniert).

Damit war dann alles von stdio.h auf LIO-Funktionen konvertiert und der Weg frei für blockierendes Lesen in LIO. Außerdem blockiert waitpid() jetzt auch richtig anstatt Busywaiting zu machen. Dadurch braucht tyndur jetzt in den meisten Fällen keine 100% CPU mehr.

[kevin]

Es gibt jetzt übrigens wieder neue Nightlies. Die URL, die neue Builds triggert, hatte sich verändert und deswegen gab es keine mehr.

Neben ein paar Bugfixes ist die Unterstützung für erweiterte Partitionen jetzt neu. Außerdem habe ich an Patches gewerkelt, die zusätzliche IDE-Controller unterstützen (was bei SATA im IDE-Modus häufiger mal vorkommt), aber das ist noch nicht in master, sondern nur in meinem ide-Branch. Testen konnte ich das leider noch nicht, weil ich meines Wissens keine Hardware rumstehen habe, bei der dieses Szenario vorkommt. Testberichte von euch wären also hilfreich.

Edit: Ups, sehe grad, dass die vorherigen Änderungen noch gar nicht erwähnt wurden. hdaudio hat einen größeren Treiberumbau hinter sich und tut inzwischen auf dem T500. Nachdem das Interface standardisiert ist, sollte es auch auf anderer echter Hardware gehen. e1000e ist nach wie vor ein bisschen hakelig, aber geht prinzipiell jetzt auch mit der aktuellen git-Version. Die fehlenden Instruktionen im VM86-Monitor sind auch ergänzt, so dass ich jetzt auch bunt bekomme (sobald ich mal ein serielles Kabel hatte, war das trivial zu debuggen ). Für rtl8168b ist der Treiber im Repo und wird gebaut, aber setup richtet diese Karte noch nicht automatisch ein. Soviel zur Hardwareseite.

Außerdem gibt es jetzt ein Verzeichnis dev:/fs/, indem Symlinks zu mountbaren Dateisystemen abgelegt werden. Für jedes CDI-Storage-Gerät, das auftaucht, werden die Dateisystemtreiber gefragt, ob sie damit was anfangen könnten, und wenn ja, wird der Link (Dateiname = Volumename) angelegt. Wenn man also dem Rootdateisystem einen Namen gibt, kann man z.B. von dev:/fs/tyndur-boot booten, ohne sich darum kümmern zu müssen, ob das jetzt IDE oder AHCI ist, oder ob es das erste oder zweite CD-Laufwerk ist.

Ich glaube, das war's, aber für die durchschnittliche Aktivität in tyndur ist das ja eine ganze Menge.

[kevin]

Eine geöffnete Datei zu löschen macht den Dateisystemtreiber kaputt (führt zu use after free, also 0xd00fc0de). Das ist schade, weil Öffnen und direkt wieder Löschen eigentlich eine gängige Weise ist, mit temporären Dateien umzugehen. Konkret macht das auch mutt in mutt_pager(). Wenn man das unlink() auskommentiert, stürzt nichts mehr ab, aber aus irgendeinem Grund zeigt er trotzdem nur eine Mail an. Die temporäre Datei enthält statt der kompletten Mail nur ein einziges Byte, nämlich '\n'.