Thema: Sprung in den RealMode

[Jidder]

Ich kann dir da leider auch nicht weiterhelfen. Die Sache ist ziemlich kompliziert und unmöglich über das Internet zu debuggen.

[üäpöol]

Ich habe es jetzt mal mit incbin versucht.

1. Du erzeugst mit NASM eine flache Binary (-f bin) und fügst die über INCBIN in eine weitere .asm-Datei ein. Dann kopierst du diese Daten (zur Laufzeit) an eine Adresse unter 1 MB und springst dorthin. Dazu brauchst du natürlich labels vor und hinter dem INCBIN.

Ich habe jetzt einfach mal eine Datei mit dem originalen osdev.org gemacht, die ich mit -f bin assembliere und die dann mit incbon inkludiert. Das hat nicht funktioniert. Was meinst du mit Daten zur Laufzeit kopieren?

[Jidder]

Ich glaube dir ist nicht ganz klar, was genau es bedeutet in den Real Mode zu springen. Im Real Mode kannst du nur Speicher bis 1 MB adressieren. Bei der Adressierung werden 16-Bit Segment und 16-Bit Offset miteinander über Segment * 16 + Offset zur linearen Adresse verrechnet. Dein Kernel ist nach 0x100000 gelinkt, was bedeutet, dass sich der Code über 1 MB befindet. Es ist also nicht möglich diese Adresse des Codes mittels Segment und Offset dazustellen.

Wenn dein Code vom Protected Mode in den Real Mode springt, und die CPU noch Code über 1 MB ausführt, wird sie nach dem Sprung irgendeinen anderen Code ausführen und dein System stürzt ab. Das heißt du musst bevor du in den Real Mode wechselst bereits an eine Adresse unter 1 MB springen. Und um deinen Code dahinzubekommen, musst du ihn dahin kopieren.

Ich rate dir allerdings dazu, erstmal nicht weiter zu versuchen in den Real Mode zu springen. Du musst für einen kompletten Sprung hin und zurück wesentlich mehr Aufwand treiben, als diese 20 Zeilen im Schnipsel von osdev.org suggerieren.

[üäpöol]

Hm. Ja, du hast Recht. Ich werde es wohl erstmal ein lassen. Danke trotzdem für deine Hilfe.

[üäpöol]

Ich habe es zwar vorzeitig aufgegeben, habe aber trotzdem generell noch eine Frage zu Möglichkeit 2. Wie kann ich eine flache bin mit linken? ld sagt mir, dass das Dateiformat nicht erkannt wird. Brauche ich dazu ein spezielles Linkerskript?

[Jidder]

Hm, ich glaube dazu musst du die erst mit objcopy ins ELF-Format wandeln. objcopy -B i386 -I binary -O elf32-i386 inputfile outputfile oder so

[üäpöol]

OK. Das funktioniert, aber wie kann ich dann eine Funktion aufrufen?

[Jidder]

Gar nicht. Du kannst aber an den Anfang von dem Blob springen. Das setzt natürlich voraus, dass da auch Code steht.

[üäpöol]

Tut mir Leid, dass ich so blöd frage, aber was ist ein Blob?

[Jidder]

Damit meine ich die Binary. Da sind nur noch unstrukturiere Daten drin, mit denen du nach dem Assemblieren nichts mehr anfangen kannst, insbesondere keine Informationen wie Symbole für Funktionen, etc. extrahieren.

[üäpöol]

Vielen Dank. Ich denke, ich habe es jetzt verstanden. Ich habe allerdings noch ein anderes Problem, das zwar nicht ganz zu dem Thema passt, aber ich glaube, es ist besser als einen anderen Thread zu erstellen. Da ein Sprung in den RealMode im Moment ja nicht möglich ist und ich bisher GRUB benutzt habe, ich aber kurz BIOS Interrupts ausführen muss, habe ich mich entschieden, einen eigene Bootloader zu schreiben und dann mit ASM noch in den ProtecedMode zu springen. Das funktioniert auch alles super, aber plötzlich habe ich ein Problem mit GCC. Ich rufe die main Funktion auf, aber plötzlich nichts mehr. Damit meine ich genau, dass es keine Fehlermeldungen gibt, aber das irgendwie keine externen Funktionen mehr aufgerufen werden können; glaube ich zumindest. Debugged habe ich das schon, aber das sieht alles super. Mit GRUB hat das alles funktioniert. Ich verwende denselben Code wie bei GRUB. Habe ich einen offensichtlichen Fehler gemacht, oder soll ich ein bisschen Code posten?

[kevin]

Der offensichtliche Fehler ist, einen eigenen Bootloader zu schreiben. Vermutlich hat entweder deine Funktion, die den Kernel von der Platte liest, ein Problem, oder dein ELF-Loader.

Was heißt denn "kann nicht mehr aufgerufen werden"? Irgendwas muss ja passieren, wenn du es versuchst.

[üäpöol]

Natürlich ist es in meinem Fall Schwachsinn, einen Bootloader zu schreiben, aber ich brauche kurz und nur zum Testen BIOS Interrupts. Der Kernel wird einwandfrei geladen und ich lade keine elf-Dateien, sondern linke die zu einer flachen binary zusammen, die ich dann zum Bootloader kopiere. Wenn ich den Kernel debugge (dazu linke ich die Dateien zu einer elf Datei zusammen), sieht das alles super aus. Es scheint so, als würde das Aufrufen einer C Funktion (nicht einer externen Funktion) dazu führen, dass kein weitere Code geladen wird.

[kevin]

Lädt der Bootloader eventuell nur einen halben Kernel?

[üäpöol]

Das könnte sein, ich zeig den Bootloader einfach mal:

Code: [Auswählen]

[ORG 0x7C00]
start:
cli
mov ax, 0x9000
mov ss, ax
mov sp, 0
sti
mov [bootdrive], dl
call load
mov ax, 0x1000
mov es, ax
mov ds, ax
push ax
mov ax, 0
push ax
retf

load:
push ds
mov ax, 0
mov dl, [bootdrive]
int 0x13
pop ds
jc load
 
load1:
mov ax, 0x1000
mov es, ax
mov bx, 0
mov ah, 2
mov al, 30
mov cx, 2
mov dx, 0
int 0x13
jc load1
retn

bootdrive db 0

times 510-($-$$) db 0
dw 0xAA55
Ich kenne mich leider nicht wirklich aus und Tutorials dazu sind ja auch Mangelware.

[üäpöol]

Hat niemand eine Idee?

[Jidder]

taljeths Theorie könnte hinkommen. Du lädst nur zwei Sektoren (cx = 2). Wenn dein Kernel größer als 1 KB ist, reicht das nicht. Beim Lesen ignorierst du außerdem den Wert in [bootdrive]. Das könnte ein Problem sein, wenn du nicht vom ersten Laufwerk bootest.

Die Parameter für den BIOS-Aufruf sind zum Beispiel hier dokumentiert: http://www.ctyme.com/intr/rb-0607.htm

[üäpöol]

Ja, eine andere Erklärung gibt es eigentlich nicht - glaube ich.
Leider funktioniert nichts mehr, wenn etwas anderes in cx steht. Ich habe es auch so verstanden, dass die Sektoren in al stehen. Im Moment sind es übrigens bei mir 16 Sektoren. Ich glaube auch, cl ist der Anfangssektor, der gelesen werden soll. Ich bin mir aber nicht sicher. Habt ihr noch andere Ideen? Ich bin leider echt überfragt.

[Jidder]

Und wieder mal hab ich die Doku, die ich selbst verlinkt habe, nicht richtig gelesen ... Hast Recht, das ist der Anfangssektor. Du könntest mal prüfen, wieviele Sektoren tatsächlich transferiert wurden.

[Dimension]

Und wieder mal hab ich die Doku, die ich selbst verlinkt habe, nicht richtig gelesen

Das beunruhigt dich? Ich kann einen Abschnitt 20x lesen und immer noch nicht verstanden haben.