Thema: BIOS-Interrupts

[rizor]

Hallo zusammen,

ich habe momentan ein Problem mit meinen BIOS-Interrupts.
Mein System soll den Speicher selbst bestimmen durch 0xe820.
Habe mir dazu Code geschrieben, der in den unreal-mode springt und wieder in den PM springt.
Den Code habe ich gegen Adresse 0x7000 gelinkt und lade ihn auch an die Stelle.
In meinem Kernel rufe ich folgenden Assembler-Befehl:

Code: [Auswählen]

call *0x7000
Leider laedt er nicht 0x7000 in EIP sondern den Inhalt von 0x7000.
Wenn ich es mit

Code: [Auswählen]

call (0x7000)
probiere, kommt nichts sinnvolles bei raus. Das was dann in EIP steht, kann ich in meinem Code nicht finden.

Wie sieht er richtige Befehl aus?

Danke.

Grusz
rizor

[sfan]

Wie wär's mit

Code: [Auswählen]

call 0x7000
?

[rizor]

Das geht auch nicht. Da versucht er auch auf komische Adressen zuzugreifen.
Keine Ahnung, woher er die Werte bekommt.

[sfan]

Wäre es nicht möglich

Code: [Auswählen]

mov eip, 7000h
zu benutzen?

[rizor]

Das laesst GAS nicht zu. Da sagt er mir, dass EIP das falsche Register ist.

[Svenska]

EIP kann man weder lesen noch schreiben. Darum geht keine IP-relative Adressierung. Es lässt sich nur über CALL und JMP verändern.

[freecrac]

EIP kann man weder lesen noch schreiben. Darum geht keine IP-relative Adressierung. Es lässt sich nur über CALL und JMP verändern.

Wir können auch eine Adresse auf den Stack schieben und dann ein Rücksprung machen.

Dirk

[sfan]

Wenn "call *0x7000" den Inhalt von 0x7000 nach EIP lädt und nicht 0x7000, dann müsste

Code: [Auswählen]

var db 0x7000
call var
doch 0x7000 nach EIP laden.
Das ist doch das Ziel!


Sfan

[Jidder]

Normalerweise macht man das so:

Code: [Auswählen]

mov $0x7000, %eax
call *%eax
oder lädt gleich das Segment dazu:

Code: [Auswählen]

lcall $0x08,$0x7000

[sfan]

Normalerweise macht man das so:

Code: [Auswählen]

mov $0x7000, %eax
call *%eax

Das geht natürlich auch!
Meine Methode sollte aber möglichst nichts an den Regtistern ändern.


Sfan

[MNemo]

also laut AMD-Manuals gibt es keinen

Code: [Auswählen]

call immfür absolute adressen

es bleiben dir also nur die drei möglichkeit: far call, eax oder var

[kevin]

Meine Methode sollte aber möglichst nichts an den Regtistern ändern.

Programme, die nichts an den Registern ändern, müssen ziemlich langweilig sein.

[rizor]

Okay, jetzt wird der Code ausgefuehrt, macht aber ein paar Zicken, sobald ich in den RM springe.
Hier ist mal der Code:

Code: [Auswählen]

.code16gcc

int_e820:
xor %ebx, %ebx
xor %bp, %bp
mov $0x8004, %eax
mov %eax, %edi
mov $0x0534D4150, %edx
mov $0xe820, %eax
mov $24, %ecx
int $0x15
jc exit
cmp %eax, %edx
jnz exit
cmp %ebx, 0x0
jz exit
jmp check
loop:
mov $0x1, %eax
mov %eax, 0x14(%edi)
mov $24, %ecx
int $0x15
jc exit
mov $0x0534D4150, %edx
check:
jcxz bad_entry
cmp %cl, 20
jbe check_length
mov 20(%edi), %ecx
test $0x1, %ecx
je bad_entry
check_length:
mov 0xc(%edi), %ecx
or 0x8(%edi), %ecx
jz bad_entry
inc %bp
add 24, %edi
bad_entry:
test %ebx, %ebx
jne loop
exit:
mov %bp, (0x8000)
clc
mov %cr0, %eax
or 0x1, %eax
mov %eax, %cr0
push $0x8
push $goback
retf

In den RM springe ich, indem ich einfach das PM-Bit loesche.
Sollte doch funktionieren, oder?

[Jidder]

So einfach ist das nicht.

Wie das geht, steht hier: http://wiki.osdev.org/Real_mode#Switching_from_Protected_Mode_to_Real_Mode

[sfan]

Meine Methode sollte aber möglichst nichts an den Regtistern ändern.

Programme, die nichts an den Registern ändern, müssen ziemlich langweilig sein.

Nur das kleine Codestück sollte nichts an den Registern ändern



Sfan

[freecrac]

Okay, jetzt wird der Code ausgefuehrt, macht aber ein paar Zicken, sobald ich in den RM springe.
Hier ist mal der Code:
....

Wird diesen 16 Bit-RM-Bios-Interrupt vom Virtual 8086 Mode aus aufgerufen, denn sonst zickt dieser Bios-Interrupt schon selber sogar noch bevor in den RM geschaltet wird herum?

Dirk

[rizor]

Die Frage verstehe ich nicht. Der Kernel soll in den Unrealmode springen und dort den Interrupt ausfuehren. Das muesste funktionieren.

[Svenska]

Du willst die BIOS-Interrupts im Unrealmode ausführen? Geht das überhaupt zuverlässig, denn so ein BIOS-Code kann ja sonstwas tun?

[freecrac]

Du willst die BIOS-Interrupts im Unrealmode ausführen? Geht das überhaupt zuverlässig, denn so ein BIOS-Code kann ja sonstwas tun?

Bios-Interrupts lassen sich entweder im RM, oder im V86-Mode, oder im 16 Bit-Unrealmode ausführen, aber nicht im PM.
Erst wenn erneut in den PM geschaltet wird und Segmente geladen werden mit anderen Einträgen bei der Segmentgrößße im dortigen GDT,
dann wird diese Segmentgröße in die Schattenregister geschrieben.

Mir ist kein Bios-Interrupt bekannt der selber in den PM schaltet und wieder zurückin den RM. (Mainboad mit EFI-Bios?)

Dirk

[erik.vikinger]

Hallo,


während meiner Schulzeit, also vor sehr vielen Jahren, hab ich und ein Kumpel mal versucht ein RM-Programm zu bauen das mit Hilfe von FS und GS mehr als 64 kB ansprechen sollte. Wir haben FS und GS auch anständig im PM initialisiert und sind korrekt in den RM zurückgesprungen. Das System lief auch ganz normal weiter aber irgendwann gab es dann eine GP-Exception wenn über FS oder GS mit einem Offset größer 64 kB zugegriffen wurde. Unsere Lösung war das wir einen passenden Excpetion-Handler in die RM-IDT eingetragen haben (für INT 0x0D) der einfach nur in den PM ging, FS und GS wieder passend initialisierte und dann zurück im RM ein IRET gemacht hat. Mit diesem Trick konnten wir die durchschnittliche Laufzeit unseres Programm deutlich steigern aber irgendwann krachte es trotzdem wegen irgendeiner unbehandelten Exception. Soweit ich mich noch erinnern kann hatten wir einfach Probleme im RM genau zu analysieren ob der INT nun wirklich eine Exception ist oder eben ein IRQ 5 (ein INT 0x0D wäre zwar auch möglich gewesen aber das hatten wir einfach mal ignoriert). Eigentlich sollte das kein Problem sein aber mit dem PIC kannten wir uns damals nicht so richtig aus. Einen Dissasembler der den Befehl auf den der IP auf dem Stack zeigt genau analysiert um zu erkennen ob das ein Speicherzugriff ist oder nicht erschien uns damals als zu aufwendig und einfach immer in den PM zu gehen kostete enorm viel Performance und löste das Problem trotzdem nicht vollständig. Zumindest nicht bei Programmen die die Soundkarte (welche ja IRQ 5 wollte) benutzt haben. Aber auch wenn es keinen IRQ 5 gab hielt unser Schmalspur-UnReal-Mode nicht ewig.

Es ist zwar durchaus möglich das wir das damals nicht ordentlich implementiert haben und es deswegen nicht stabil lief aber von einer ernsthaften/längeren Benutzung des UnReal-Mode kann ich persönlich trotzdem einfach nur abraten.


Grüße
Erik