From 22b4e0ea46fc6f8f04e045ac5469d045dff43e9e Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Fri, 19 Jun 2009 01:34:07 +0200 Subject: Completed linux-basics/boot-process/handout_boot-process_de.tex --- .../boot-process/handout_boot-process_de.tex | 150 ++++++++++++++++++++- 1 file 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} -- cgit v1.2.3