Autor Thema: C++ Kernel?  (Gelesen 11981 mal)

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« am: 18. April 2005, 16:49 »
Hallo zusammen
Nörgle immer noch bei den kernel rum ... :'(
Also ich habe den bootlader von Teejay und die 3 verschieden C und C++ kernel ausprobiert... passiert komischerweise immer das selbe :( nämlich garnichts :P Hat vielleicht jemand eine Idee wieso?


PS: Wie klug wäre es eigentlich wenn ich noch im kernel eine ganze oberfläche einbaue? wäre ja nicht wirklich das kernel prinzip ;)

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 19. April 2005, 17:52 »
Hey
Also ich habe ein paar vermutungen wieso es nicht geht ABER da ich hier der bin der keine ahnung hat  ... ;)

Gründe
1. Der bootloader lädt eine datei die 512 gross is, der kernel is aber nicht unbedingt so gross
2. Ich wechsle zu spät oder (was mich erstaunen würde) garnicht in denn 32 bit mode...


Das sind so die gründe wo ich denke an was das es liegt, aber eben, wie gesagt. Ich bin kein profi und darum frag ich ja auch ^^

Another Stupid Coder

  • Beiträge: 749
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 19. April 2005, 18:14 »
Hm...in OS Coding hätte das wohl besser gepasst und es ist vorallem grundsätzlich eine gute Idee Source mitzuliefern, sonst wird das helfen schwer.

B.G.

  • Beiträge: 27
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 19. April 2005, 18:15 »
Wenn du C nutzen willst, dann kann ich nur http://www.osdever.net/tutorials/basickernel.php?the_id=12.

Mit *etwas* (*ähäh*) aufarbeit und ner neuen print funktion ist das echt gut. Habs auch als Grundlage für meine Kernel benutzt.

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 19. April 2005, 18:52 »
Das is 1 zu 1 der Code aus eurem Tutorial ;) Und denn kann man sich ja selber anschauen ohne zu posten ...


Also der Bootloader funzt, habs mit einem kleinen Assembler kernel versucht.

@B.G. Was für einen kernel brauchst du? Sind bei dir bei der compilierung irgendwelche warnings aufgekommen?

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #5 am: 19. April 2005, 19:48 »
Zitat von: B.G.
Wenn du C nutzen willst, dann kann ich nur http://www.osdever.net/tutorials/basickernel.php?the_id=12.

Mit *etwas* (*ähäh*) aufarbeit und ner neuen print funktion ist das echt gut. Habs auch als Grundlage für meine Kernel benutzt.


Ups, und da steht noch mein Name drunter! ;)
*post*

B.G.

  • Beiträge: 27
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 19. April 2005, 21:18 »
Zitat von: matthieuriolo
@B.G. Was für einen kernel brauchst du? Sind bei dir bei der compilierung irgendwelche warnings aufgekommen?


Ich hab einen C-Kernel. Den den ich gepostet habe nur stark aufgetuned: IDT, unterteilt in mehrer Dateien etc.
Nur muss man für den Kernel ein en anderen Bootloader (auch Fat12 nehmen. Link im Link.)

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 20. April 2005, 20:42 »
Ok ich habe jetzt denn bootloader und nen c-Kernel. Aber wie nun weiter? Wenn ich denn bootf.bin mit rawwrite rauf tu, is die diskette "unformatiert"! Kann also dann nicht normal einen kernel rein dropen :'( Und wenn ich die zwei in ein img file zusammen kopiere, sagt mir bochs das es nich bootbar sei!

B.G.

  • Beiträge: 27
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 20. April 2005, 21:21 »
Du musst die Bootf.bat nehemn. Dadurch wirds mit Partcopy geschrieben. Das ist besser als rawwrite weil man da direkt den sektor etc. auswählen kann. Also lad Partcopy und machs mit der Bootf.bat dann Kernel kopieren.

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 21. April 2005, 20:05 »
Irgendwie komisch ...

Bochs mit dem Bootloader von TeeJay:

[CPU0] prefetch: RIP> CS.limit

Bochs mit dem anderen bootloader wo mir B.G. empfohlen hat:

[CPU0] WARNING: HLT instruction with IF=0!


Also das IF=0 bedeutet das keine Interrups möglich sind, KA wieso diese fehler meldung kommt :( Ne idee?

PS: Der andere kernel der du mir empfohlen hast geht auch ned... versucht es noch auf die "alte" art zu kompilieren

Another Stupid Coder

  • Beiträge: 749
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 21. April 2005, 20:12 »
1. da geht der Instruction Pointer über das Code-Segment-Limit, jumpst du wohin, wo nur 0's stehen? z.B. eine Endlosschleife am Ende vergessen?
2. Das macht nichts...weil du Interrupts verboten hast mit cli... und hlt hält die CPU ja normalerweise nur bis zum nächsten Interrupt an, aber da du keine Interrupts erlaubt hast, wird die CPU ewig halten, davor warnt sie.

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 21. April 2005, 20:41 »
Dann also irgendwo hier start: cli ;{0}
lgdt [cs:gdt] ;Load GDT
mov ecx, CR0 ;Switch to protected mode
inc cx
mov CR0, ecx ;{5}
.5: in al, 0x64 ;Enable A20 {4A}
test al, 2
jnz .5
mov al, 0xD1
out 0x64, al
.6: in al, 0x64
and ax, byte 2
jnz .6
mov al, 0xDF
out 0x60, al

noch sti einflicken? Und zwar noch vor dem .5: ?  :oops:

Another Stupid Coder

  • Beiträge: 749
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 22. April 2005, 16:17 »
Das ist doch nur ne Warnung, wenn du nicht willst, dass hlt unterbrochen wird (was du beim Kernelende ja nicht willst) dann würde ich es so lassen.

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 22. April 2005, 17:08 »
Nun ja darum geht es wahrscheinlich nicht ;) darum muss/sollte ich das da noc reinflicken. Oder etwa nicht B.G.?

Roshl

  • Beiträge: 1 128
    • Profil anzeigen
    • http://www.lowlevel.net.tc
Gespeichert
« Antwort #14 am: 22. April 2005, 17:43 »
das Problem ist, dass du nur halb in den PM wechselst.
nach dem ändern von cr0 muss ein far jump kommen.
So versucht er nach dem aktivieren des 32Bit Modus noch 16-Bit Code auszuführen in einem halb aktiven 32-Bit Modus, das kann doch nicht gut gehen^^
[schild=1]Wieder ein wertvoller(?) Beitrag von Roshl[/schild]

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #15 am: 22. April 2005, 18:29 »
Langsam solltet ihr wissen das ich kein assembler kann ^^ darum wäre es furchtbar nett wenn du mir schnell erklären könntest wieso das passiert. Also das mit dem PM is klar aber der wechsel und was dieser befehl macht... unklar  :roll:

Roshl

  • Beiträge: 1 128
    • Profil anzeigen
    • http://www.lowlevel.net.tc
Gespeichert
« Antwort #16 am: 22. April 2005, 19:10 »
Hat ja nix mit ASM zu tun sondern mit dem Verständniss der Architektur des x86. Also ok:
mov eax,cr0
inc eax
mov cr0,eax
Setzt das PE-Bit im ControlRegister 0 und aktiviert damit den Protected Mode. Also die Adressierungsart mit den vielen Schutzmechanismen^^. Also Deskriptoren und der ganze Mist. Da aber danach noch eine 16Bit-Code Befehle im Ausführungscache des Prozessors sein könnten muss man einen Far-Jump ausführen, der leert diesen Cache und lädt CS mit einem gültigen 32-Bit-Selektor.
So du machst diesen Sprung nicht also bist du nicht richtig im PM. Allerdings is es so das manche Opcodes im PM anders interpretiert werden als im RM. Z.B. jnz und Verwandte haben im RM eine maximale Sprungreichweite von 64Byte im PM nicht also muss es etwas anders codiert werden.
Damit nasm das anders assembliert muss man [BITS 32] dort einsetzten wo er anfangen soll PM-Adressierung zu verwenden. Sonst führt der Prozessor totalen Mist aus weil er was anderes an Code sieht als du ihm geben wolltest.
Das war jetzt ganz einfach erklärt wenn dus genauer brauchst dann krall dir die Intel-Dokus, was besseres gibts nicht^^
[schild=1]Wieder ein wertvoller(?) Beitrag von Roshl[/schild]

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #17 am: 22. April 2005, 20:04 »
Der soll sich doch garnicht in den 32 bit modus schalten ... dieser booter is mir einfach zu schräg ^^ nime liebr wieder den von TeeJay, und da muss ich ich DA mov bx, 0x1000 ;Segmentadresse festlegen an die der Kernel geladen werden soll
mov dx, [RootEntCnt] ;Startsektor der Datensektoren errechnen
shl dx, 5
add dx, [BytesPerSec]
dec dx
shr dx, 9
add [Temp], dx ;Und das Ergebnis in Temp-Variable speichern


was ändern. Und zwar statt [BytesPerSec] einfach ein 1 reinschreiben. Oder nicht? :wink: weil er sucht alle 512 bytes ab und der kernel is nicht unbedingt gerade eine 512 grosses file (auch wenn er sich in einem so grossen sektor befindet)

crashmakerMX

  • Beiträge: 8
    • Profil anzeigen
Gespeichert
« Antwort #18 am: 25. April 2005, 10:00 »
wenn [bytespersec] die bytes in einem sektor sind, müssen es eigentlich immer 512 sein. man kann sowieso nur ganze sektoren lesen.

javadomi

  • Gast
Gespeichert
« Antwort #19 am: 19. May 2005, 20:46 »
Also bei mir geht es auch nicht, obwohl ich mich an das Tutorial gehalten habe. Ich glaube, weil der NASM ein Fehler ausgibt: External referenzes Oder so. Ich bräuchte eine sehr genaue Anweisung, wie ich alles Kompilieren soll.

 

Einloggen