Thema: Fragen zum Bootloader und kernelübersetzung

[kevin]

Ganz ehrlich: Bootloader und Kernel sind zwei wirklich verschiedene Baustellen. Viel mehr als eine Lowlevel-Denkweise (sofern nicht sowieso schon vorhanden) wirst du für den Kernel nicht mitnehmen können - es sei denn, dein Bootloader ist in Wirklichkeit schon ein Kernel, natürlich. Das ist kein gutes Argument dafür, selben einen Bootloader zu schreiben.

Aber das macht es natürlich nicht schlechter, einen guten Bootloader zu schreiben. Das ist auch ein spannendes Projekt. Aber dann muß man eben mehr reinstecken als die anderthalb Tage, um zwei rohe Sektoren von der Floppy zu kratzen. Dann ist der Bootloader das Projekt und nicht das OS.

[ehenkes]

...
Aber das macht es natürlich nicht schlechter, einen guten Bootloader zu schreiben. ... Aber dann muß man eben mehr reinstecken als die anderthalb Tage, um zwei rohe Sektoren von der Floppy zu kratzen. Dann ist der Bootloader das Projekt und nicht das OS.

Bisher kenne ich nur "Your own tiny bootloader" oder "we use GRUB". Wo ist ein Ansatz für die Personen, die beide Varianten nicht überzeugend finden? Hast Du hierzu einen Link? 

[kevin]

Nein, Tutorials speziell für größere Bootloader kenne ich nicht. Ist irgendwie kein so beliebtes Thema. Das heißt, ein Stück weit bist du auf dich gestellt, aber grundsätzlich kannst du vom Aufbau her vieles mit einem monolithischen OS-Kernel teilen. Du brauchst Plattentreiber (wobei man da evtl. das BIOS hernimmt),  Dateisystemtreiber, Tastaturtreiber, wahrscheinlich zumindest eine einfache Form von Speicherverwaltung... Prozeßverwaltung und Multitasking wirst du in einem Bootloader natürlich nicht haben.

[matheguru]

Ich hab da noch eine Frage also im Moment mache ich es so das der erste teil in den 512Byte bei der Partitionstabelle liegt, den Rest aus den folgenden Sektoren lädt. Dieser Teil schaltet in den PM und springt dann in den C-Teil, indem dann Treiber und so reinkommt. Meine Frage solle ich lieber kurz vor dem laden des OS`s in den PM schalten, denn dann spart man sich mühevolle Arbeit an SATA-/ATA-Treiber etc. ?

[bluecode]

Ich hab da noch eine Frage also im Moment mache ich es so das der erste teil in den 512Byte bei der Partitionstabelle liegt, den Rest aus den folgenden Sektoren lädt. Dieser Teil schaltet in den PM und springt dann in den C-Teil, indem dann Treiber und so reinkommt. Meine Frage solle ich lieber kurz vor dem laden des OS`s in den PM schalten, denn dann spart man sich mühevolle Arbeit an SATA-/ATA-Treiber etc. ?

Was genau meinst du mit Laden des OS? Nur den Kernel? Dann ist die Antwort natürlich nein, im Bootloader macht ein ATA-Treiber keinen Sinn/Spaß.
Falls du das Laden von Treibern oä. meinst, dann kommt es auf die Kernelart an:
* Wenn du einen Mikrokernel (oder einen modularisierten monolithischen Kernel) willst, dann sollten die Treiber bereits im RAM sein, sonst müsstest du ja deinen ATA-Treiber in den Kernel verfrachten, was du aber ja eben bei einem Microkernel nicht willst.
* Wenn du einen monolithischen Kernel würde ich zuerst in den Protected-Mode wechseln und dann zum Kernel springen, schon allein weil es quasi-unmöglich ist 16bit Code mit 32bit Code zu mischen.
Falls du das Laden von Shell, etc... meint, dann ist die Antwort wiederum nein, da du sowieso einen ATA-Treiber brauchst, sonst kannst du ja keine Anwendungen "nachladen" und ausführen.

[matheguru]

Dann stelle ich die Frage noch einmal in korrektem klaren Deutsch aus, damit es nicht zu verwechslungen kommt. Also der erste Teil meines Bootmanagers HABOMA soll im MBR meiner Festplatte liegen, dieser überprüft eben ob überhaupt eine gültige Partitionstabelle vorhanden ist, falls ja werden die Sektoren direkt hinter dem MBR, indenen der Rest des Bootmanagers liegt, in den RAM geladen, an Adresse 0x10000 selbstverständlich! Von hier aus wollte ich eig. ersteinmal in den PM wechseln um den Betriebssystem hinterher Arbeit zu ersparen und weil GRUB das ja auch macht. Nun mein Problem oder Frage, wie man`s sieht! Wenn ich jetzt schon in den PM wechsle, bräuchte ich jetzt natürlich auch einen HD-Treiber oder ich müsste über den virtuellen x86 Mode auf die Interrupts zugreifen, wenn ich allerdings kurz vor dem laden des Kernels erst in den PM wechsle kann ich mir das mit dem HD-Treiber ja sparen! Wie macht das denn GRUB und liegen die Dateien von GRUB auch direkt hinter dem MBR, denn die alten Betriebssysteme lassen zwischen MBR und erster Partition doch etwas Platz? Und sagt mir bitte nicht: " Dann nimm doch gleich GRUB, wenn du wissen willst wie GRUB das macht". Ich nehme das ja nur als Vorlage um mir das besser vorzustellen. Gib mir am besten mal eine Liste mit Komponenten, die unbedingt drin sein müssen und was man brauch! Ich möchte euch Danken für die ganzen Antworten ich habe jetzt einiges in diesen 2 Wochen gelernt. Danke

[bluecode]

Grub lädt den Kernel (und alle Module) bevor es in den Protected-Mode wechselt. Ich nehme an Grub2 wird das genauso machen, aber sicher bin ich mir nicht. Eine kurze Erklärung was die stages bei Grub tun gibts hier.

Gib mir am besten mal eine Liste mit Komponenten, die unbedingt drin sein müssen und was man brauch.

Der Bootloader sollte zusätzliche Module laden können für einen Mikrokernel. Er sollte ELF32/64 unterstützen und jeweils in den 32bit Protected-Mode bzw. den LongMode wechseln. Am besten sollte er Multiboot oder/und den Multiboot2 Vorschlag unterstützen. Unterstützung für mehrere Dateisysteme (FAT, ext2, ISO9660 mit El Torito, ...).
Gescheite Tools um das Ding auf Floppy/CD-ROM Images zu installieren.

[matheguru]

Danke, dann können die Module aber doch nicht über die 1MB grenze geladen werden, oder nicht?

[bluecode]

Doch, das auf jeden Fall, Grub lädt grundsätzlich nur über 1MB, sowohl Kernel als auch Module. Es könnte sein, dass Grub immer ein Stück liest, dann in Protected-Mode wechselt, das Stück kopiert und wieder zurück wechselt.

[matheguru]

Ja, aber dann hätte man ja wiederrum das Problem mit den BIOS-Interrupts, die man höchstens noch im virtuellen x86 Mode nutzen könnte wie das Vesa-Interface im PM. Wie erklärst du dir das? Das ist kompliziert, entweder Treiber oder Vx86Mode oder nur 1MB speicher.

[bluecode]

Es könnte sein, dass Grub immer ein Stück liest, dann in Protected-Mode wechselt, das Stück kopiert und wieder zurück wechselt.

Gemeint ist im Realmode mit BIOS-Interrupts lesen, im Protected-Mode kopieren, ohne Virtual-8086-Mode.

[matheguru]

OK, das ist eine Lösung, also ein Platz im RAM freihalten, dort reinkopieren und dann wechseln, verschieben und zurückschalten!

[kevin]

Ja, soweit ich weiß, wechselt GRUB fröhlich hin und her. Für den Zugriff auf Platte/Diskette nimmt er auf jeden Fall das BIOS.

[matheguru]

Ich habe mir gerade die Neuerungen in GRUB2 durchgelesen, stage1.5 wird rausgenommen und auch komprimierungsverfahren werden angewedet.

[kevin]

stage1.5 hat doch schon bisher niemand genutzt.

Meine persönliche Einschätzung zu GRUB 2: Das wird der emacs unter den Bootloadern. Wird vermutlich ein ganz passables Betriebssystem, aber booten kann man damit halt leider nicht vernünftig. Ob sie wenigstens das mit dem Editor besser hinbekommen, wird man noch sehen.

[matheguru]

Sry das ich den Thrad noch mal hochhole, aber ich muss jetzt echt zugeben, nachdem ich recherchiert habe und angefangen habe einen eigenen bootmanager zu schreiben, dass GRUB geil ist, der hat so viele funktionen und bietet alles was man brauch und eignet sich wirklich optimal für ein eigenes OS! An alle die genauso gedacht haben wie ich am anfang, nämlich das GRUB doof ist , seht ja selbst ich war auch hartnäckig in diese Meinung versetzt, aber GRUB ist dann doch sehr brauchbar

[ehenkes]

Was sind die drei wichtigsten Vorteile, die dich zu deiner Meinungsaenderung bewogen haben? Das interessiert mich, weil ich im dritten Teil meines OS-Tut ebenfalls GRUB (unter Windows) einsetzen will.

[matheguru]

Also als erstes wollte ich ja nur einen tinybootloader, der mein kernel lädt, das konnte ich aber schnell knicken, da ich mein kernel immer von eineer fat32 partition lade und der Treiber müsste erst mal nachgeladen werden! Dann dachte ich mir es ist doch bestimmt nicht schwer, so ein treiber einzuarbeiten, dann kam mir die überlegen, dass es ja hinterher mehr fs unterstützen muss! Ich kan zu dem schluss das ich nen eigenen bootmanager schreiben wollte, was allerdings auch nen reinfall war, weil als ich mich näher mit dem thema beschäftigt habe, ist mir aufgefallen das grub alles bietet was man sich nur wünschen kann! Man kann mehrere Module mitladen, man kann eine INITRAMDISK laden, er schaltet direkt in den protected mode, er ist leicht zu konfigurieren und er unterstützt multiboot strukturen! GRÜSE Paul

[ehenkes]

GRUB ist bei Linux ja schon dabei. Wie sieht das bei Windows aus? Kann es da Stoerungen geben zwischen dem ExperimentalOS und Windows? Man moechte sich ja nicht seinen Lieblingsrechner zerschiessen?

[bluecode]

Wenn du grub in den MBR installierst eigentlich nicht. Du musst dann nur einen Eintrag für Windows machen, der den Bootsektor der WIndowspartition lädt (chainloading).