Merge branch 'master' of ssh://tglx.de/home/linutronix/git/schulung

1 files changed, 144 insertions, 6 deletions

diff --git a/linux-basics/boot-process/handout_boot-process_de.tex b/linux-basics/boot-process/handout_boot-process_de.tex
index 4c391b2..7f39dc7 100644
--- a/linux-basics/boot-process/handout_boot-process_de.tex
+++ b/linux-basics/boot-process/handout_boot-process_de.tex
@@ -1,17 +1,155 @@
-\documentclass{article}
+\documentclass{lxarticle}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{lxheaders}
+\usepackage{lxextras}
 
 \begin{document}
 
-\section*{Titel}
+\section*{Der Linux-Boot-Prozess}
 
-\subsection*{Abschnitt1}
+\subsection*{Aufgaben des Bootloaders}
 
-Text
+Hauptaufgabe des Bootloaders ist die rudimentäre Initialisierung der
+Hardware, so dass mindestens das RAM benutzt werden kann. Dazu ist auf den
+meisten Boards die Initialisierung eines (S)DRAM-Controllers erforderlich.
 
-\subsection*{Abschnitt2}
+Soll das Board aus einem NAND-Flash booten können, so muss auch dessen
+Controller initialisiert werden.
 
-Text
+Viele Prozessoren beinhalten PLLs, die aus dem Prozessortakt andere Clocks
+für verschiedene Peripherie-Einheiten generieren. Auch diese müssen
+initialisiert werden.
+
+Anschließend müssen die Peripherie-Einheiten initialisiert werden, die
+der Bootloader benötigt, um den Kernel laden zu können. Für TFTP-Boot wäre
+dies beispielsweise der Netzwerk-Chip.
+
+Meist ist es auch erwünscht, dass der Bootloader eine serielle Schnittstelle
+initialisiert. Dies ermöglicht nicht nur hilfreiche Meldungen aus dem
+Bootloader, es ermöglicht auch dem Kernel bereits im frühen Stadium des
+Bootvorgangs die Ausgabe von Meldungen (und nicht erst nach dem Laden seines
+UART-Treibers und der Konsole). Viele Bootloader bieten ausserdem eine Art
+Monitorprogramm, mit dem man mit Hilfe eines Terminalprogramms interaktiv
+Einstellungen ändern oder Speicher lesen und schreiben kann.
+
+Nach erfolgreicher Initialisierung lädt der Bootloader von der gewählten
+Quelle das komprimierte Kernel-Image ins RAM. Am Anfang eines komprimierten
+zImage steht (natürlich unkomprimiert) der Dekompressor-Code. Der Bootloader
+springt diese Adresse an und hat damit seine Arbeit beendet. Alles weitere
+läuft im Kernel ab.
+
+\subsection*{Gängige Bootloader}
+
+Die Wahl des Bootloaders ist weitgehend eine Geschmacksfrage. Die
+verbreiteten Bootloader U-Boot und Redboot bieten im Wesentlichen die gleiche
+Funktionalität. Die Bedienung unterscheidet sich zwar deutlich, aber der
+ohnehin nötige Einarbeitungsaufwand dürfte bei beiden etwa gleich sein.
+
+Auch beim Kompilieren dieser Bootloader sind die Unterschiede nicht gross.
+Beide zeichnen sich durch schwer durchschaubaren Sourcecode und ein
+eigenwilliges Buildsystem aus.
+
+Es gibt aber auch die Möglichkeit, ganz auf einen derartigen Bootloader zu
+verzichten. Statt dessen verwendet man einen minimalen \emph{Initial Program
+Loader (IPL)}, der lediglich die rudimentären Initialisierungsaufgaben
+erfüllt und danach einen minimalen Bootkernel lädt und ausführt. Dieser
+lädt wiederum den eigentlichen Produktiv-Kernel nach.
+
+Vorteile der letztgenannten Vorgehensweise sind hohe Flexibilität und die
+Tatsache, dass man im Bootkernel schon nach wenigen hundert Millisekunden
+jeden gewünschten Treiber zur Verfügung hat. Dadurch können in elegante
+Weise Anforderungen wie das Anzeigen eines Bildes auf einem TFT (500
+Millisekunden nach dem Einschalten) gelöst werden. Wollte man dies mit
+einem der oben erwähnten Bootloader erreichen, müsste man zunächst die
+für das TFT benötigten Treiber vom Kernel in den Bootloader portieren und
+dort zum Laufen bringen. Ähnliches gilt für andere gängige Forderungen,
+wie das Booten von einem USB-Stick.
+
+Es erscheint als überflüssige Mühe, einen im Kernel bereits
+funktionierenden Treiber in den Bootloader portieren zu müssen. Mit IPL und
+Bootkernel sind ausserdem komplexe Aufgaben während des Bootvorgangs,
+beispielsweise automatisierte und sichere Firmware-Updates leicht
+realisierbar.
+
+\subsection*{Bootprobleme: Im Bootloader}
+
+Während der Entwicklungsphase sind Probleme im Bootloader besonders
+unangenehm. Falls dieser bereits abstürzt, ehe er die serielle Schnittstelle
+initialisieren konnte, so sieht man schlichtweg gar nichts. Aber auch bei
+späteren Fehlern ist der Entwicklungszyklus mühsam, da man den Bootloader
+meist erst mit einem JTAG-Adapter oder ähnlichen Werkzeugen ins Flash des
+Boards befördern muss, bevor man den nächsten Versuch machen kann. Bei
+Änderungen am Bootloader-Code ist daher große Sorgfalt geboten. Wenn möglich,
+sollte man zu zweit an solchem Code arbeiten und sich ständig gegenseitig
+kontrollieren.
+
+Häufige Problemquellen im Bootloader sind beispielsweise:
+
+\begin{itemize} 
+\item Der Bootloader wurde nicht korrekt ins Flash geschrieben. In einem Fall
+	passierte dies beispielsweise, wenn der Compiler ein Binary mit
+	ungerader Länge erzeugte. Aber auch falsche Konfiguration des JTAGer
+	kann zu solchen Problemen führen.
+\item Im Bootloader wurden die Timings für Bus-Schnittstellen wie RAM oder
+	Flash nicht korrekt eingestellt. Gerade wenn die Timings nicht ganz
+	falsch, sondern nur grenzwertig sind, kann es zu schwer
+	reproduzierbaren Bootproblemen kommen.
+\item Die Ladeadresse für den Kernel ist nicht korrekt. Bei manchen
+	Bootloadern kann es leicht zu Verwechslungen zwischen physikalischen
+	und virtuellen Adressen kommen. Weder U-Boot noch Redboot melden
+	einen Fehler, wenn man den Kernel an eine Adresse lädt, an der
+	sich überhaupt kein RAM befindet...
+\item Beim Laden des Kernels per TFTP kann es zusätzlich weitere Probleme
+	geben, die mit dem Netzwerk zusammenhängen. Diese reichen von falsch
+	aufgesetzten TFTP-Servern über falsch konfigurierte DHCP-Server oder
+	falschen IP-Adressen bis hin zu Treiber- oder Hardware-Problemen.
+\end{itemize} 
+
+\subsection*{Bootprobleme: Im Kernel}
+
+Bootprobleme im Kernel sind vergleichsweise einfach zu finden, sobald man
+eine Konsole auf der seriellen Schnittstelle hat. Der Kernel gibt meist recht
+aussagekräftige Fehlermeldungen und bietet viele zusätzliche Debug-Funktionen,
+die man in der Kernel-Konfiguration aktivieren kann. Falls sich der Kernel
+bereits früher aufhängt, so dass man nach der Meldung
+
+\cmd{Uncompressing Linux.....}
+
+überhaupt nichts mehr sieht, dann wird es schwieriger. Man sollte zunächst
+überprüfen, ob die im Bootloader vorgegebene Commandline für den Kernel
+korrekt ist, insbesondere die Einstellung der für die Konsole verwendeten
+seriellen Schnittstelle (\cmd{console=tty...}).
+
+Ein weiteres gängiges Problem ist, dass der Kernel am Ende des Bootvorgangs
+kein Root-Filesystem mounten kann. Dies kann daran liegen, dass man bei der
+Kernelkonfiguration vergessen hat, dass \emph{alle} für das Rootfs nötigen
+Hardware- und Dateisystem-Treiber in den Kernel einkompiliert sein müssen
+und nicht etwa als Module gebaut wurden. Bei Medien, die erst detektiert
+werden müssen (z.B. SD-Karten) kann es passieren, dass das Medium noch nicht
+bereit ist, wenn der Kernel es mounten will. In diesem Fall hilft der
+Parameter \cmd{rootwait}.
+
+Falls der Kernel zwar das Rootfs mounten kann, aber danach mit einer
+Fehlermeldung hängen bleibt, anstatt \cmd{/sbin/init} zu starten, dann
+liegt dies oft an fehlenden Device-Nodes im Verzeichnis \cmd{/dev}.
+Überprüfen Sie dies.
+
+\subsection*{Bootprobleme: In den Startskripten}
+
+Wenn der Kernel erfolgreich das Rootfs mounten und \cmd{/sbin/init} starten
+konnte, wird letzteres versuchen, die in \cmd{/etc/inittab} angegebenen
+Anweisungen auszuführen. Dies ist normalerweise zunächst der Aufruf eines
+Startskripts, das in der Regel weitere Skripte und Programme aufruft. Je
+nach Art der aufgerufenen Programme kann es hier zu weiteren Problemen
+kommen. Dazu gehören etwa fehlerhafte Konfigurationsdateien, fehlende
+Device-Nodes oder Ähnliches.  
+
+Ausserdem kommt es bei Startskripten vor, dass diese nicht auf jede Situation
+sauber und fehlertolerant reagieren. Man sollte vermeiden, dass sich das
+Skript zur Konfiguration des Netzwerks aufhängt, wenn kein DHCP-Server
+gefunden wurde oder kein Netzwerkkabel eingesteckt ist. Des weiteren sollte
+das Skript selber erkennen, wenn über die Netzwerkschnittstelle das Rootfs
+per NFS gemountet wurde, und dann eine Neukonfiguration tunlichst unterlassen.
 
 \end{document}