Thema: Laden eines C-Kernels

[Programm Noob]

komm doch am besten mal in den IRC Channel #LOST @ irc.euirc.net.
Da kann man solche Sachen viel besser erklären.

[bscreator]

Naja, aber wenn ich die OBJ-Datei und die Flat-Binary nicht verlinken kann, welche Dateiformate muss ich dann für den Bootloader und den C-Kernel wählen ?
Soviel ich weiss, kann man mit NASM auch OBJ-Dateien erstellen. Wenn man die NASM-OBJ und die Turbo-C-OBJ miteinander verlinkt, dann müsste es aber funktionieren, weil beide OBJ-Files 16-Bit-Code enthalten, oder ?

Gruss,
bsc

[Programm Noob]

kann es sein, das du meinen Beitrag nicht gelesen hast? Wenn du keine Fragen beantwortest kann dir keiner richtig helfen.
Als Dateiformat nimmst du bei beiden Flat Binary.

PNoob

[kevin]

Naja, aber wenn ich die OBJ-Datei und die Flat-Binary nicht verlinken kann, welche Dateiformate muss ich dann für den Bootloader und den C-Kernel wählen ?

Der Bootsektor muss eine flache Binary sein. Für den Kernel kannst du wählen, was für ein Format du haben willst - der Bootsektor muss halt in der Lage sein, dieses Format zu laden. Wahrscheinlich willst du dafür also auch eine flache Binary haben.

Das ist aber jeweils nur das Ausgabeformat des Linkers. Wenn du die einzelnen Quellcodedateien erstmal in Objektdateien kompilierst und den Linker dann flache Binaries ausgeben lässt, dann sollte das klappen. Ob der Borland-Linker das mitmacht, weiß ich aber nicht auswendig.

[bscreator]

Klar hab ich deinen Beitrag gelesen.

Der Bootsektor muss eine flache Binary sein.

Stimmt, hab ich vergessen

Als Dateiformat nimmst du bei beiden Flat Binary.

OK, wenn Du mir jetzt noch sagen kannst, wie man den 16-Bit-C-Kernel in eine BIN umwandeln kann, ist alles klar.

Gruss,
bsc

[Programm Noob]

Du hast meinen Beitrag anscheinen d nicht gelesen. Wo sind die antworten auf meine Fragen?
komm mal nach #LOST

PNoob

[Svenska]

Mit dem Compiler hat das nichts zu tun, der erzeugt dir Object-Files (.o oder .OBJ oder sowas) - die sind abhängig vom Compiler! Die ELF-Datei erzeugt dir der Linker.

Ich zitiere mich ja ungern selbst...

Die .OBJ, die dir Turbo C ausspuckt, ist in Borlands eigenem Format und kann somit an sich erstmal nur von Turbo C, TASM und TLINK verarbeitet werden. Ich behaupte einfach so, dass NASM ein anderes OBJ-Format verwendet.

Ich weiß nicht, ob und wie du mit Turbo C direkt eine flat binary erzeugen kannst, aber du kannst eine EXE-Datei erzeugen und diese mit EXE2BIN (gehört zu MS-DOS, eventuell auf der Supplement-Disk) in eine BIN umwandeln. Wie du mit der umgehen musst, kann ich dir aber nicht sagen, da musst du wahrscheinlich mit einem Debugger (DEBUG) drauf losgehen.

Turbo C ist wahrscheinlich auch nicht unbedingt das, was man heutzutage gern hätte. Allerdings gibt es nicht besonders viele Realmode-kompatible C-Compiler. Guck dir mal bin86/as86 an, mit dem wird ELKS (Embedded Linux Kernel Subset, ein Teil der Linux-API für 8086) entwickelt. Das wäre dann aber ein Linux-/Cygwin-Host.

Gruß

[erik.vikinger]

Hallo,


von der Benutzung von EXE2BIN kann ich nur abraten, das Tool funktioniert nur bei EXE-Dateien die keine Relokation beim laden benötigen und das dürfte auf Code von Compilern definitiv nicht zutreffen. Selbst bei kleinen Assembler-Programmen kann bereits diese Notwendigkeit auftreten. Wenn man das vermeiden will muss man schon genau wissen was man tut.
Als Alternative sollte man den Compiler/Linker anweisen eine COM-Datei zu erzeugen dann wird der Code gleich so generiert das keine Relokation erforderlich ist (und man ist auf das Memory-Model Tiny festgelegt).
Auf der anderen Seite ist ein EXE-Loader (für das MZ-EXE-Format von DOS) nicht allzu schwer das sollte sich mit weniger als 1kByte Code realisieren lassen, also noch im Rahmen eines kleinen Bootloaders liegen.

Der Bootloader selber muss aber zwingend eine simple Binärdatei sein weil das BIOS eben keine Relokation für den Boot-Sektor durchführt. Zusammenlinken von Boot-Loader und Kernel ist IMHO auch absolut unmöglich.


@ bscreator :
Du solltest dir aber wirklich erst mal das nötige Basiswissen über die Formate der OBJ-Dateien und der verschiedenen Executable-Formate anlesen!


Grüße
Erik

[Svenska]

COM-Dateien werden beim Erzeugen reloziiert, und zwar fest auf die Adresse 0x100.
Das ist für den Bootloader unvorteilhaft. Zumal der aufgrund seiner geringen Größe noch in Assembler erstellt werden kann. (Wenn man Features braucht, die nicht-trivial sind, sollte man ohnehin einen anderen Bootloader verwenden.)

[erik.vikinger]

Hallo,

COM-Dateien werden beim Erzeugen reloziiert

Korrekt.

und zwar fest auf die Adresse 0x100.

Nicht korrekt.
Es ist das Offset 0x0100 in einem beliebigen Segment (der Code einer COM-Datei darf nicht vom Segment abhängen in dem er liegt, es werden also nur NEAR-Pointer benutzt).

Das ist für den Bootloader unvorteilhaft.

Das stimmt natürlich, aber ich meinte das eigentlich für den Kernel. Wenn der Kernel eine COM-Datei ist kann man den einfach überall in den 640k hinlegen und anspringen und er läuft.

Wenn man Features braucht, die nicht-trivial sind, sollte man ohnehin einen anderen Bootloader verwenden.

Was IMHO fast immer der Fall ist. Ich will ja nicht überheblich klingen aber reloziieren im Bootloader ist immer "nicht-trivial" (vor allem für Anfänger), das sollte man sich für den Kernel aufheben wenn man ne gute Basis hat und dann richtiges ELF o.ä. laden möchte. Außerdem erspart man sich mit der Verwendung eines vorhandenen/ordentlichen Bootloaders den ekligen x86-Real-Mode und das ganze BIOS-Gedöhns.


Grüße
Erik

[Svenska]

Naja, die Adresse 0x100 ist trotzdem fest. Das mit dem Segment hatte ich nicht ausdrücklich hingeschrieben, stimmt natürlich.

Der Bootloader muss nicht reloziieren können, der Kernel kann ja an eine feste Adresse (z.B. 128K) geladen werden - die muss halt nur beim Linken des Kernels ebenfalls bekannt sein. Ich meinte mit nicht-trivial mehr so Informationen, die der Bootloader an den Kernel übergeben kann (von wo wurde gebootet, wo soll das Root-Dateisystem herkommen, Zeiger auf BIOS-Strukturen, ...).

Ansonsten: FULL ACK.

[erik.vikinger]

Hallo,

Naja, die Adresse 0x100 ist trotzdem fest.

Ich weiß Du hällst mich für einen Haarespalter aber die 0x0100 ist keine vollwertige Adresse sondern ein Offset, das muss man im Real-Mode immer explizit dazu sagen.

Der Bootloader muss nicht reloziieren können, der Kernel kann ja an eine feste Adresse (z.B. 128K) geladen werden - die muss halt nur beim Linken des Kernels ebenfalls bekannt sein.

Echt? Geht das auch bei ELF? Bekommt man da nicht doch irgendwo Probleme? Mir ist klar das der Linker, wenn er über alle Informationen das Loaders verfügt, auch die Aufgaben des Loaders mit übernehmen kann aber ich hätte nicht gedacht das er dann wirklich 100% vollständig reloziieren kann. Also mal wieder was gelernt.


Grüße
Erik

[Svenska]

Wenn der Kernel eine flat binary ist, wird die beim Zusammenbauen ja ohnehin reloziiert, und zwar an eine fixe (Basis-)Adresse. Man muss "nur" Bootloader & Kernel aufeinander abstimmen.

Ob das bei ELF auch so leicht geht - keine Ahnung.

[bscreator]

Die Dateien werden klar vom Linker erzeugt. Nur wenn ich von Compiler spreche, dann meine ich meinstens auch den Linker.
Linux-Umgebung hab ich auch nicht, bin nur Windows User.
Das mit der COM-Adresse ist der Offset 0x100, aber weiß nicht, wie das meinem Kernel helfen soll, eine Binary zu werden.

Also ihr meint, dass ich mir einen anderen RM-Compiler für C suchen sollte, der auf NASM "passt", oder ?
Habt ihr da Vorschläge oder Compiler(bzw. Linker), die ihr kennt ?

[bscreator]

Ich hab mich jetzt mal ein bisl umgeschaut bzgl. NASM kompatiblen C-Compilern, aber leider noch keinen gefunden.
Zwar gabs einige für TASM und MASM aber NASM 

Im Prinzip will ich ja nichts anderes, als einen C-Kernel vom Bootloader mit einem JMP-Befehl zu starten. Ich hab mal einen Tutorial
Beispielcode gefunden (glaub bei bonafide), der auch funktioniert hat. Da haben sie allerdings einen Crosscompiler verwendet.
Und das Tutorial such ich auch schon ewig, finde es nur nichtmehr.

Also gibts nur die folgenden 2 Möglichkeiten, oder ?
- Einen 16-Bit-C-Compiler (bzw. Linker) finden, der BINs erstellen kann
- Irgendwie mit einem Crosscompiler

Gruss,
Matthias

[Programm Noob]

svenska, taljeth: jetzt mal nicht wieder aggressiv werden.
bscreator: du merkst, was es für ne Scheiß arbeit ist im Realmode nen OS zu schreiben? Es ist von uns allen ein gut gemeinter Rat dir GRUB zu nehmen, den Crosscompiler hier ausm Wiki und das OS-DEV für Einsteiger Tut durchzuarbeiten. dann hast du den 32 Bit Kernel, mit dem du viel mehr machen kannst. Ein weiterer Vorteil eines 32 Bit OSes ist, es programmieren bis auf wenige Ausnahmen alle 32/&4 Bit und daher können wir dir viel besser helfen. Ich will dir jetzt nichts einreden, sondern dich dazubringen deine Einstellung zu überdenken. Mich würde sowieso mal interressieren, was dich so am RM hält.

PNoob

[kevin]

Ja, RM ist Blödsinn, aber wenn er mehrfach sagt, dass er es trotzdem will, dann ist das zu akzeptieren.

Ich hab mich jetzt mal ein bisl umgeschaut bzgl. NASM kompatiblen C-Compilern, aber leider noch keinen gefunden.

Also mein nasm behauptet, das Format zu können, und zwar wenn man -fobj verlangt. Damit hast du dann alle Objektdateien im gleichen Format. Dann brauchst du aber auch noch einen Linker, der dieses Format kann und was passendes ausspuckt. tlink kann meines Wissens keine flachen Binaries produzieren, das heißt, dein Bootloader müsste einen .exe-Loader implementieren. Das wird zwar ein bisschen Arbeit kosten, dürfte aber machbar sein (die Frage ist allerdings, ob es mit deinem Wissensstand machbar ist - bedenke, dass sich von uns so gut wie keiner mit antiken Formaten beschäftigt und wir dir deshalb nur beschränkt helfen können).

Du kannst dir auch noch einen anderen Linker suchen, der OMF liest und Flat Binaries ausspuckt. Ich kenn keinen, aber Google hilft dabei sicher.

Also gibts nur die folgenden 2 Möglichkeiten, oder ?
- Einen 16-Bit-C-Compiler (bzw. Linker) finden, der BINs erstellen kann
- Irgendwie mit einem Crosscompiler

Weißt du, was ein Crosscompiler ist? Wenn ja, erklär mal, was er mit deinem Problem zu tun hat. Das ist mir nämlich ein wenig rätselhaft.

[Svenska]

Du wiederholst dich, PNoob. Im RM brauchst du übrigens keine nennenswerten Treiber schreiben (du nutzt die des BIOS) und dein OS läuft auch auf 8086ern noch. Das sind konkrete Vorteile. Die Nachteile kennen wir ohnehin alle. Zudem behaupte ich, dass ein RM-Betriebssystem einfacher zu schreiben ist als eins für den PM, solange deine Anwendungen und der Kernel nicht größer werden als 64K.

Zum Thema:

Du brauchst vorerst keinen Crosscompiler, da du ja von i86 auf i86 kompilierst und dein Zielbetriebssystem selbst baust. Crosscompiler wird erst interessant, wenn du neben dem Kernel auch eine libc für dein OS hinreichend fertig hast und Anwendungen bauen möchtest.

Zum Turbo C passt bevorzugt der TASM, die anderen werden wahrscheinlich schwieriger sein und/oder ein anderes OBJ-Dateiformat benutzen.

Du musst "irgendwie" deinem Turbo C beibringen, dass es eine flat binary erzeugt und diese an eine bestimmte Adresse linkt. Das kann eine BIN sein, das kann aber auch eine COM sein (wenn du mit der Adresse "BeliebigesSegment:100h" und dem Model=Tiny leben kannst).

Crosscompiler von DOS für i86 wirst du vermutlich nicht finden, am ehesten bin86 (Linux-Host) oder ACK (Amsterdam Compiler Kit, Minix-Host).

Schlussfolgerung, eh mir PNoob nochmal in den Nacken springt: Entweder du befasst dich mit Turbo C soweit, bis du ihn dazu bringst, Dinge zu tun, die du gern getan haben möchtest - oder du wechselst den Compiler. Ich glaube, dass du zu TC keine große Dokumentation mehr finden wirst, außer der damaligen/mitgelieferten oder einem alten Fachbuch aus der Uni-/FH-Bibliothek deines Vertrauens. Die haben sowas meistens.

Wenn du deinen Kernel an eine bestimmte Adresse gelinkt hast UND er eine flat binary ist, dann muss dein Bootloader diesen Kernel an exakt dieselbe Adresse laden und kann ihn dann per JMP ausführen.

Solltest du konkrete Fragen haben, melde dich. Ansonsten betrachte ich zu diesem Thema erstmal alles gesagt. Gibt sonst nur Ärger.

Nach kurzer Recherche überrascht mich, dass TLink angeblich keine flatbinaries erstellen kann, Quelle hier. Dort gibt es aber viele Linker zur Auswahl. Schon der erste klingt nicht soo schlecht. Damit musst du dich aber selbst beschäftigen.

Gruß,
Sebastian

[Programm Noob]

Alos Treiberprogrammierung ist natürlich eine Sache, die man im PM amchen muss, aber ansonsten ist es, da er ja snscheinend eh liber mit C schreiben will im PM um einiges leichter.

PNoob

[kevin]

@Svenska: Auf der Seite bin auch gelandet. Und die scheint ein bisschen irreführend zusein: Was tlink nämlich kann, ist COM. Und das würde ich durchaus als flache Binary deklarieren. Also halb so schlimm und man müsste auch mit nasm/Turbo C/tlink was funktionierendes hinbekommen.