Nun ja, ich will aber, ist kein grund, aber ich will erstmal das grundlegenste über OS-Dev lernen, und dazu gehört ein Bootloader und das Bootstrapping.
Eben nicht. Du lernst viel über die zugrundeliegende Hardwareplattform, aber nur sehr wenig über Betriebssystementwicklung. Die PC-Plattform gibt es seit 1984 (IBM PC/AT) - und die stinkt inzwischen an einigen Stellen (und ist zudem noch zu ihrem Vorgänger kompatibel).
Es gibt da einiges zu beachten, was eigentlich total irrelevant wäre, wenn da nicht die Geschichte und so. Das fängt schon mit einer zuverlässigen Methode an, den RAM anzusprechen (Stichwort A20) oder überhaupt rauszufinden, wieviel RAM überhaupt verbaut ist (dazu brauchst du BIOS-Interrupts - und die gehen im PM nicht).
Ein Bootloader kann dir das abnehmen und gibt dir gleichzeitig sehr viel Flexibilität, damit du dich auf das konzentrieren kannst, was du eigentlich willst: Ein Betriebssystem entwickeln. Darum meinte ich, dass "ich will aber" kein guter Grund ist. Nur sehr, sehr viel sinnlose Arbeit und viele Kompatiblitätsprobleme.
Was sind LBA-Adressen und was sind CHS-Adressen?
LBA: Logical Block Addressing. Die Sektoren sind durchnummeriert. Festplatten ab 2 GB können das zuverlässig.
CHS: Cylinder/Head/Sector. Jeder Sektor hat Zylinder-, Kopf- und Sektornummer. Bei Diskettenlaufwerken kommst du da nicht drum herum, ansonsten will man sich damit nicht mehr ohne Grund herumärgern (es gibt für Festplatten diverse Translation-Mechanismen, jeweils mit verschiedenen Grenzen und Fehlermöglichkeiten).
Beim Start des Bootsektors habe ich doch bp und sp gesetzt?
Das sind so Dinge, die man nicht will. Adressen im Real Mode bestehen aus Segment:Offset, für den Stack SS:SP. Es geht konkret um CS, DS und SS.
Laut dem Buch, welches ich dafür benutze sollte ich eig 15 Sektoren laden.
Da liegt das Problem. Leg das Buch weg, mache einen Zeitsprung über 20 Jahre und betritt danach die wunderbare Welt der Gegenwart. Dann gehst du in das Wiki zu dem
OS-Dev für Einsteiger-Tutorial und spielst das durch. Dann geht es weiter.
Wie gesagt, Ich wollte als nächstes die main() über assembler labeln, damit auch garantiert dahingesprungen wird.
Das wird so nicht ohne weiteres funktionieren. Dein Kernel ist eine Datei, die du in den Speicher lädst, aber du musst auch wissen, an welche Stelle (relativ zum Dateianfang) du springen musst, damit es losgeht. Sowas steht normalerweise in einem Header, aber du kannst den Linker auch überreden, eine flat binary mit main() ganz am Anfang zu erzeugen. Musst du halt nur machen.
Ich wollte nach dem Fiasko und der Frustration auch Grub verwenden. Nur da hab ich keinen Einstieg, da ich jetzt in dem Thema "voll drin bin" und weil ich absolut keine Ahnung habe, wie ich Grub in Qemu zum laufen kriege.
Brauchst du für die ersten Schritte nicht, weil Qemu Linux- und Multibootkernel selbst laden und starten kann ("qemu -kernel mein_multiboot_kernel.elf"). Ich persönlich mag Grub nicht und nutze lieber Syslinux.
Kann ich denn auch den Kernel nach dem laden in den PM-Mode springen lassen? Oder wie meinst du das?
Es gibt sogar Kernel, die nie in den PM springen (DOS zum Beispiel). Üblicherweise lädt der Bootsektor nur einen 2nd stage, welcher dann das Dateisystem des Bootlaufwerks lesen kann und damit den Kernel sowie eventuell nötige Treiber in den RAM lädt und danach erst den Kernel startet. Ein guter 2nd stage hat die Komplexität eines kleinen Betriebssystems.
Ist da irgendetwas was Bochs richtiger macht?
Nicht richtiger, sondern anders. Du willst vermutlich garnicht wissen, was für Seltsamkeiten verschiedene BIOS-Hersteller einbauen.
PS: Doppelpostings sind böse. Du kannst alte Beiträge auch bearbeiten.
PPS: Übrigens herzlich Willkommen hier im Forum!
Gruß,
Svenska
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken