Thema: Kernel mit Pascal

[Cjreek]

Hi,

Das scheint ja eine etwas problematische Sache zu sein. Vorallem wenn man nicht GRUB, sondern einen eigenen Bootloader benutzen will.

Das Problem ist, dass ich mit dem Free Pascal compiler fpc scheinbar keine flat binaries erzeugen kann. Nur ELF oder PE. Und die kann ich ja nicht laden/benutzen.

Ich stehe also gerade etwas blöd da 

Das andere Problem ist:

nasm boot.asm -f bin -o boot.o

==>

boot.asm:43: error: binary output format does not support external references

Fehlermeldung kommt wegen [extern kernel_main] in meinem asm Code. Das brauche ich ja. Sonst kann ich ja nicht in meinen Kernel springen -.-

Was heißt das jetzt für mich?

[kevin]

Du willst keine flachen Binaries benutzen. Das ist eine Krücke, die dir ewig Ärger machen würde, bis du dann doch mal deinen Bootloader umbaust. Und die dir jetzt schon Ärger macht, wie du anhand der Fehlermeldung siehst. Symbole gibt es bei flachen Binaries nicht - ist ja schließlich nur eine Folge von Opcodes - also gibt es auch keine externen Symbole.

Deswegen ja, mal wieder die übliche Empfehlung: Entweder du nimmst GRUB (absolut zu bevorzugen) oder du planst ordentlich Zeit einen, um einen richtigen Bootloader zu schreiben, der dann auch mit ELF und sinnvollerweise einem Dateisystem umgehen kann. Schnell an einem Nachmittag auf einem Tutorial basierend einen Bootsektor hinrotzen ist so oder so keine tragfähige Basis für deinen Kernel.

Aber schön zu sehen, dass jemand Pascal ins Auge fasst. Ein bisschen Abwechslung zum ewigen C auf x86 schadet nicht.

[Cjreek]

Hi,

Ich wollte eigentlich etwas Abstand von GRUB halten. Nix gegen GRUB. Aber ich würds schon gern selbst probieren.

Auf deutsch heißt das also, dass ich am besten FAT(12) unterstützen sollte/muss und einen ELF/PE Loader in meinem Bootloader, der dann meinen Kernel startet?

[kevin]

Genau, das wäre das Minimum für einen vernünftigen Bootloader. Dummerweise wirst du es kaum schaffen, Floppytreiber, Dateisystemtreiber und ELF/PE-Loader in 512 Bytes unterzubringen. Das heißt, du kannst den Bootloader schonmal in zwei Stufen aufteilen. Der Bootsektor müsste dann die Sektoren kennen, wo der eigentliche Loader liegt, um den direkt von Diskette/Platte zu lesen. Und erst der eigentliche Loader würde dann Dateisystemtreiber und ELF-Loader und sowas enthalten.

Ein Bootloader ist halt doch keine komplett triviale Thematik, wenn er was taugen soll.

[Cjreek]

Trivial ist hier gar nichts 

Nunja. Ich sehe es als Herausforderung 
Notfalls kann ich immernoch zu GRUB greifen 

[bluecode]

Wenn fpc ELF Objektdateien erzeugen kann, dann kannst du diese auch mit den ELF Objektdateien von nasm mit ld und einem Linkerscript zusammenlinken und eine flat binary bekommen.
Trotz allem kann ich wie taljeth nur grub empfehlen.

[Krendor]

Ich war Anfangs auch gegen GRUB.

Ich will auf niedrigstem Level programmieren um unabhängig zu sein.
Warum soll ich dann GRUB benutzen. Dann hätte ich ja nichts gelernt.

Ich habe dann ein paar BootLoader selber geschrieben, die konnten
mehr oder weniger. Jedenfalls hat es keiner zu einem FAT12 Treiber
geschafft. Aber ich habe sehr viel gelernt! Ich habe kleine RealMode
Programme geschrieben, alle in Assembler ohne auf andere Programme
zurückzugreifen. Darunter eines um den jeweils ersten Sektor der Diskette
oder der Festplatte auszulesen, eines um Musik mit dem Speaker beim
Booten auszugeben, ...

Inzwischen programmiere ich an einem (sehr kleinem) OS, für welches
ich GRUB benutze, um mir den CDROM Treiber aufzuschieben. Und dann
programmiere ich nebenbei noch niedliche und nützliche kleine RMode
Programme.

Wenn du also ein OS entwickeln willst: Ich rate dir dringenst zu GRUB!
Geht es dir darum, den PC besser kennenzulernen und einfach kleine
und unabhängige Programme zu schreiben, dann versuch dich mal an
einem kleinen Bootloader. Erwarte aber nicht zu viel. Und du kannst im
Nachhinein eine ELF datei mit dem Linker zu einer Binary linken.

Viele Grüße
Sebastian

[Cjreek]

Hi,

Wollte jetzt mal GRUB testen. Und habe mir dafür mal einen Dummy Kernel in Pascal geschrieben und die system.pas und die prt0.asm hierher geklaut.

Ich benutze Windows und bekomme meinen Kernel aufs verrecken nicht compiliert -.-

ich compiliere folgendermaßen:

fpc.exe pas\kernel.pas -Anasmelf -n -Xd -Rintel -Tlinux

Fehlermeldung:

Can't find unit si_prc used by kernel.

Wenn ich "Tlinux" weglasse, dann meint er, dass die sysinitpas fehlt.

Hab das ganze auch schon mit Twin32 und -Anasmwin32 versucht, aber es nutzt nix. Es will einfach nicht. Was mache ich falsch?

[kevin]

Kurzes Googeln nach si_prc führt zur Information, dass das wohl eine andere Variante für prt0.asm ist, die (mittlerweile?) für Linux verwendet wird. Aus dem Stand heraus würde ich mal folgende Sachen ausprobieren:

Zum einen könntest du statt -Tlinux mal -Tfreebsd versuchen. Google behauptet, dafür werde nach wie vor die prt0.asm benutzt. In dem Fall sollte der Rest einfach so funktionieren.

Oder du kriegst es so nicht hin und versuchst irgendwie zu tricksen. Also ihm irgendwie eine leere si_prc unterzuschieben und von Hand mit der prt0.o zu linken, oder (etwas eleganter) den Kernel statt als program als unit deklarieren, damit er die si_prc erst gar nicht haben will und dann wiederum von Hand Linken (und in der prt0.o statt PASCALMAIN die richtige Einstiegsfunktion anspringen).

Oder natürlich einfach mal nachschauen, wie das mit der si_prc wirklich gedacht ist (d.h. was macht der Code für Linux?) und das entsprechend richtig umsetzen.