==Der Bootprozess==
Bevor wir anfangen, Code zu schreiben, zunächst ein kleiner Blick auf den Bootprozess. Aus Sicht des Kernel könnte dieser Abschnitt den Titel "was bisher geschah" tragen.

Bei einem CPU-Reset (der beispielsweise beim Anschalten passiert) wird der gesamte Prozessorzustand neu gesetzt. Insbesondere schaltet der Prozessor in den Real Mode und springt an die lineare Adresse 0xffff0 (z.B. cs:ip = f000:fff0). An dieser Adresse liegt as BIOS. Das BIOS initialisiert die Hardware, führt einen Selbsttest durch und wenn es fertig ist, löst es einen Interrupt 0x19 aus. Der Handler lädt den Bootsektor von der Festplatte oder Diskette nach linear 0x7c00 (z.B. 07c0:0000) und springt an diese Adresse.

Der Bootloader ist anschließend dafür zuständig, den Kernel des Betriebssystems in den Speicher zu laden und an dessen Einsprungspunkt zu springen.

==Multiboot==
Für unser Betriebssystem werden wir [[GRUB]] als Bootloader benutzen. GRUB ist einfach zu benutzen, weit verbreitet und hat einen großen Funktionsumfang.

Es gibt Leute, die der Meinung sind, man sollte seinen Bootloader selbst schreiben, damit man die Sache wirklich selbst gemacht hat. Diese Leute benutzen dann in ihrem Bootloader die Funktionen des BIOS, fangen also nur an einer anderen Stelle an, auf den Code anderer aufzusetzen. Dazu müssen sie auf Dauer viel Zeit in die Funktionalität des Bootloaders investieren, wenn sie nich in ihrem Betriebssystem mit Einschränkungen leben wollen. Bootloader sind nette Projekte, aber wir konzentrieren uns hier auf das Betriebssystem.

[[Multiboot]] ist der Name der Spezifikation, die ein Kernel einhalten muss, um von GRUB geladen werden zu können. Der verlinkte Artikel enthält dazu mehr Informationen.

==Der Hello-World-Kernel==
"Hello World" ausgeben zu wollen stellt uns vor zwei Schwierigkeiten: Zum ersten müssen wir wissen, wie man Text auf den Bildschirm bekommt - und zum zweiten müssen wir dafür sorgen, dass der entsprechende Code überhaupt ausgeführt wird.

Fangen wir mit dem einfachen an: Direkt nach dem Booten ist ein PC im Textmodus. Im Textmodus werden auf dem Bildschirm die Zeichen dargestellt, die im Grafikspeicher ab der Adresse 0xb8000 liegen. Dabei braucht jedes Zeichen zwei Bytes: Das erste Byte ist das Zeichen selbst. Das zweite Byte ist das sogenannte Attributbyte, das die Farbe und Hintergrundfarbe des Texts festlegt - mehr Details stehen bei Bedarf im Artikel [[Textausgabe]]. Wir legen also folgendermaßen los (die Datei heißt bei mir init.c):

<c>void init(void)
{
    const char hw[] = "Hello World!";
    int i;
    char* video = (char*) 0xb8000;

    for (i = 0; i < sizeof(hw); i++) {
        // Zeichen i in den Videospeicher kopieren
        video[i * 2] = hw[i];

        // 0x07 = Hellgrau auf Schwarz
        video[i * 2 + 1] = 0x07;
    }
}</c>

Nachdem wir das erste Problem souverän gelöst haben, müssen wir den Code jetzt nur noch zur Ausführung bringen. Wir müssen also irgendwie den Multiboot-Header in unsere Binary bekommen. Außerdem benutzt unsere Funktion ein paar lokale Variablen. Lokale Variablen landen auf dem [[Stack]], deswegen müssen wir etwas Speicherplatz für den Stack vorsehen. Diesen Teil erledigen wir in Assembler (diese Datei ist die start.S):

<asm>.section .text

// Init ist eine Funktion aus init.c
.extern init

#define MB_MAGIC 0x1badb002
#define MB_FLAGS 0x0
#define MB_CHECKSUM -(MB_MAGIC + MB_FLAGS)

// Der Multiboot-Header
.align 4
.int    MB_MAGIC
.int    MB_FLAGS
.int    MB_CHECKSUM

// _start muss global sein, damit der Linker es findet und als Einsprungspunkt
// benutzen kann (alle Labels, die nicht global sind, sind nur in dieser Datei
// sichtbar)
.global _start
_start:
    // Stack initialisieren
    mov $kernel_stack, %esp

    // C-Code aufrufen
    call init

    // Falls wir jemals aus init zurueckkommen sollten, gehen wir in eine
    // Endlosschleife
    jmp .

// 8 kB Stack fuer den Kernel. Das Label steht hinter dem freien Speicher,
// weil der Stack nach unten waechst
.section .bss
.space 8192
kernel_stack:</asm>

An dieser Stelle wären wir mit dem Code fertig. Jetzt müssen wir ihn noch kompilieren und irgendwie ausprobieren. Man kann natürlich von Hand den Compiler und den Linker aufrufen, aber es empfiehlt sich, <i>make</i> dafür zu benutzen. make übersetzt immer nur alle Dateien neu, die sich tatsächlich geändert haben, und es vergisst dabei auch nichts. Eine passende <i>[[Makefile]]</i> (das ist der Dateiname der Steuerdatei für make) könnte beispielsweise so aussehen:

<pre>
SRCS = $(shell find -name '*.[cS]')
OBJS = $(addsuffix .o,$(basename $(SRCS)))

CC = gcc
LD = ld

ASFLAGS = -m32
CCFLAGS = -m32 -Wall -g
LDFLAGS = -melf_i386 -Ttext=0x100000

kernel: $(OBJS)
    $(LD) $(LDFLAGS) -o $@ $^

%.o: %.c
    $(CC) $(CCFLAGS) -c -o $@ $^

%.o: %.S
    $(CC) $(ASFLAGS) -c -o $@ $^

clean:
    rm $(OBJS)

.PHONY: clean
</pre>

Erwähnenswert ist vor allem die Option <i>-Ttext=0x100000</i> für ld. Das ist die Adresse, an die der Kernel geladen werden soll und an der er ausgeführt wird. GRUB kann einen Kernel nicht an eine niedrigere Adresse als 1 MB laden und 0x100000 sind genau 1 MB.

Die Werte für CC und LD müssen ggf. angepasst werden, so dass sie auf einen Compiler bzw. Linker zeigen, der i386-ELF-Dateien erzeugt. Mit dem Crosscompiler unter Windows könnte es beispielsweise sein, dass für CC <i>i586-elf-gcc</i> und für LD <i>i586-elf-ld</i> eingetragen werden muss.

Nach einem Aufruf von <i>make</i> solltest Du jetzt eine Datei <i>kernel</i> vorfinden. Jetzt müssen wir ihn nur noch irgenwie ausführen. Dazu gibt es mehrere Möglichkeiten:
* qemu kann ab Version 0.11 Multiboot-Kernel direkt laden. <i>qemu -kernel kernel</i> bringt unseren Kernel zur Ausführung und schreibt ein wunderschönes Hello World in die linke obere Ecke. Den Rest des Bildschirms zu löschen haben wir leider vergessen, so dass das über irgendwelche BIOS-Meldungen geschrieben wird.
* Jeder beliebige Emulator kann von Disketten-Images booten, z.B. qemu mit <i>qemu -fda floppy.img</i>. Wir brauchen also ein Diskettenimage, das GRUB und unseren Kernel enthält. Dazu gibt es folgende Artikel in diesem Wiki:
** [[GRUB-Image erstellen]] (für Linux)
** [[GRUB-Image erstellen (Windows)]]
* Ein echter PC und eine echte Floppy geht natürlich auch. Dazu entweder das Image erstellen und auf Diskette schreiben (z.B. mit <i>dd</i> oder <i>rawrite</i>) oder direkt eine GRUB-Diskette nehmen und den Kernel darauf kopieren

Wenn wir nicht mit qemu 0.11 direkt booten, sondern ein Diskettenimage (bzw. eine echte Diskette) benutzen, begrüßt uns nach dem Booten GRUB (jedenfalls, wenn keine menu.lst angelegt wurde). Der Kernel kann dann folgendermaßen gestartet werden:
<pre>kernel /kernel
boot</pre>

==Multiboot-Header in einer eigenen Sektion==
Der Kernel scheint zwar wunderbar zu funktionieren, aber er enthält einen Fehler. Der Fehler ist im Moment nicht dramatisch, aber irgendwann wird er unerwartet zuschlagen - wir sollten es deshalb lieber gleich richtig machen.

Wie bereits erwähnt muss der Multiboot-Header der Kernels in den ersten 8 kB der Datei liegen. Das funktioniert im Moment mehr oder weniger zufälligerweise. Die Sektion .text landet zwar am Anfang der Binary, aber in welcher Reihenfolge die Dateien hineingeschrieben werden, bleibt dem Linker überlassen. Wir können es aber erzwingen, dass .text mit dem Multiboot-Header anfängt: Wir legen ihn zunächst in seine eigenen Sektion und sagen dem Linker dann, wie er es zusammenbauen soll.

Dazu ändern wir den Anfang der start.S folgendermaßen ab:
<asm>.section multiboot
#define MB_MAGIC 0x1badb002
#define MB_FLAGS 0x0
#define MB_CHECKSUM -(MB_MAGIC + MB_FLAGS)

// Der Multiboot-Header
.align 4
.int    MB_MAGIC
.int    MB_FLAGS
.int    MB_CHECKSUM

.section .text

// Init ist eine Funktion aus init.c
.extern init

// _start muss global sein, damit der Linker es findet und als Einsprungspunkt
...</asm>

Außerdem erstellen wir ein <i>Linkerskript</i>, die Datei kernel.ld:
<pre>
/*  Bei _start soll die Ausfuehrung losgehen */
ENTRY(_start)

/*
 * Hier wird festgelegt, in welcher Reihenfolge welche Sektionen in die Binary
 * geschrieben werden sollen
 */
SECTIONS
{
    /*
     * . ist die aktuelle Position in der Datei. Wir wollen den Kernel wie gehabt
     * an 1 MB laden, also muessen wir dort die erste Sektion hinlegen
     */
    . = 0x100000;

    /*
     * Der Multiboot-Header muss zuerst kommen (in den ersten 8 kB).
     * Die Standardsektionen einfach hintereinander weg einbinden.
     */
    .text : {
        *(multiboot)
        *(.text)
    }
    .data ALIGN(4096) : {
        *(.data)
    }
    .rodata ALIGN(4096) : {
        *(.rodata)
    }
    .bss ALIGN(4096) : {
        *(.bss)
    }
}
</pre>

Anschließend muss der Linker auch noch wissen, dass er die Datei benutzen soll. Daher wird in der Makefile das <i>-Ttext=0x100000</i> zu einem <i>-Tkernel.ld</i>

==printf==
Nach sehr viel sehr detailliert besprochenem Code kommen wir zu einigen Aufgaben, die ich dem geneigten Leser gern zur Übung überlassen würde. Es handelt sich dabei um Funktionen zur Textausgabe - denn man kann keine Fehler finden, wenn man sich keine Informationen anzeigen lassen kann. Wir brauchen mindestens:

* Eine Funktion zum Löschen des Bildschirms (nicht zwingend, sieht aber einfach schöner aus)
* Eine Funktion um Text auszugeben
* Eine Funktion um Zahlen in dezimaler Schreibweise auszugeben
* Eine Funktion um Zahlen und Pointer in hexadezimaler Schreibweise auszugeben

In den folgenden Teilen gehe ich davon aus, dass die unteren drei Aufgaben von einer Funktion kprintf() übernommen werden, die für die genannten Fälle genau so funktioniert, wie die normale printf()-Funktion. Die Funktionen kommen am besten in ihre eigene Quellcodedatei (z.B. console.c) und werden in den Beispielen in der Headerdatei <i>console.h</i> erwartet.

Für die Implementierung von printf benötigt man <i>stdarg.h</i>, um die variable Parameterliste auszuwerten. gcc bietet dafür bereits Builtins an (bzw. eine komplette <i>stdarg.h</i> Header, wenn man einen [[Cross-Compiler]] benutzt), so dass die Headerdatei nur folgendes enthalten muss:
<c>
typedef __builtin_va_list       va_list;
#define va_start(ap, X)         __builtin_va_start(ap, X)
#define va_arg(ap, type)        __builtin_va_arg(ap, type)
#define va_end(ap)              __builtin_va_end(ap)
</c>

Außerdem könnte es eine gute Idee sein, alle Ausgaben auch auf der [[serielle Schnittstelle | seriellen Schnittstelle]] auszugeben. Die Emulatoren können eigentlich alle die Ausgaben auf der seriellen Schnittstelle auf der Konsole anzeigen oder in eine Datei schreiben. Das macht es unnötig, Dinge aus dem Emulator abzuschreiben (z.B. Adressen in Fehlermeldungen).

Die Datei init.c sollte hinterher nur noch so aussehen (abgesehen vielleicht von einem Aufruf, um den Bildschirm zu löschen):
<c>#include "console.h"

void init(void)
{
    kprintf("Hello World!\n");
}</c>

==Navigation==
* Voriger Artikel [[Teil 3 - Trockenübungen]]
* Nächster Artikel [[Teil 5 - Interrupts]]

[[Kategorie:OS-Dev für Einsteiger]]