Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: clemensoft am 30. December 2004, 17:32
-
Ich benutze folgenden Code, um in den PM zu kommen. Wenn ich ihn starte, stürzt VMWare ab, Bochs und mein PC starten neu. Codesegment und Datensegment im Real Mode sind 2000h
load_pm:
xor eax,eax
mov ax,cs
shl eax,4
add ax,eos_null_desc
mov dword [BaseAddr],eax
bits 32
lgdt [eos_gdt_desc+20000h]
mov eax,cr0
or eax,1
mov cr0,eax
mov word ax, [eos_code_selector]
mov cs, ax
mov word ax, [eos_data_selector]
mov ds, ax
mov word [kernlin],kernel_pm
DB 0EAh
DW 0000000000010000b
kernlin DW 0
;Data
eos_data_selector:
dw 0000000000001000b
eos_code_selector:
dw 0000000000010000b
eos_gdt_desc:
Limit dw 3*8
BaseAddr dd 0
eos_gdt:
eos_null_desc:
dw 0
dw 0
dw 0
dw 0
eos_firstmb_data_desc:
dw 100h ;Segment Limiter 0-15
dw 2000h ;Segmentbasisadresse 0-15
db 0 ;Segmentbasisadresse 16-23
db 10010010b ;Data Segement (Writeable), Ring-0, no expand-down, present
db 11000000b ;4KB Granularity, 386, 0,0 , Segment Limiter 16-19
db 0 ;Segmentbasisadresse 24-31
eos_firstmb_code_desc:
dw 100h ;Segment Limiter 0-15
dw 2000h ;Segmentbasisadresse 0-15
db 0 ;Segmentbasisadresse 16-23
db 10011010b ;Code Segement (Readable), Ring-0, no expand-down, present
db 11000000b ;4KB Granularity, 386, 0,0 , Segment Limiter 16-19
db 0 ;Segmentbasisadresse 24-31
kernel_pm:
bits 32
;Hier fängt der 32-Bit Kernel an!
mov word [ds:0B8000h],"P "
test_hang:
jmp test_hang
-
Hi,
tjo dann fang ich mal an. ist ein bisschen spät, deswegen find ich vielleicht nicht alles. aber immerhin kannst du so morgen (also heute) ganz früh (also dann wenn ich noch schlafe :P) anfangen daran weiter zu machen. ^^
load_pm:
xor eax,eax
mov ax,cs
shl eax,4
add ax,eos_null_desc
mov dword [BaseAddr],eax
bits 32
nicht so ungeduldig ;) wir sind noch nicht im protected mode, deswegen ist das bits32 hier falsch (und kann für einen absturz sorgen.) also weg damit.
lgdt [eos_gdt_desc+20000h]
sollte besser lgdt [cs:eos_gdt] heissen. gibt nur probleme mit dem herumgerechne. vor allem im realmode kannst du so ein großes offset (> 16 bit) gar nicht verarbeiten. ;)
mov eax,cr0
or eax,1
mov cr0,eax
hier gehört das "bits 32" hin, denn erst hier sind wir im protected mode. :D
mov word ax, [eos_code_selector]
mov cs, ax
das wird nicht gehen. :shock: cs und (e)ip kann (soll) man nur über jmp's und call's usw. ändern. seltsam, dass dein assembler das ohne meckern übersetzt ... auf jeden fall ist dein prozessor spätestens jetzt im nirvana. :roll:
deswegen solltest du folgendes schreiben: :idea:
jmp dword 0x10:kernel_pm
das stück code lädt cs mit 0x10 und eip mit einem korrekten offset. es springt also zu kernel_pm. du kannst das in dieser variante leider nicht so mit dem cs-aus-variable-laden machen. ist aber mMn auch nicht nötig. :wink:
mov word [kernlin],kernel_pm
DB 0EAh
DW 0000000000010000b
kernlin DW 0
das wird damit auch überflüssig. immer diese leute, die ihre opcodes selber zusammen popeln ... :roll:
deine selektoren schauen für mich ok aus. ich habe aber nie mit einer basis ungleich 0 gearbeitet, deswegen kann ich nicht so aus dem kopf sagen, ob das so einfach geht... :roll:
kernel_pm:
bits 32
das bits 32 ist hier überflüssig, weil es oben schon vorhanden ist, dürfte aber keinen schaden anrichten.
PorkChicken
-
Danke! Mal checken!
-
das stück code lädt cs mit 0x10 und eip mit einem korrekten offset. es springt also zu kernel_pm. du kannst das in dieser variante leider nicht so mit dem cs-aus-variable-laden machen. ist aber mMn auch nicht nötig.
Bochs sagt, cs==0, also muss ich was in cs reinladen! sonst beschwert er sich!
-
aber wenn ich jmp dword cs:kernel_pm mache, meckert er auch, obwohl ich in den zeilen davor cs und ds geladen habe
-
00000812920p[CPU ] >>PANIC<< jump_protected: cs == 0
00000812920i[SYS ] Last time is 1104621686
00000812920i[CPU ] protected mode
00000812920i[CPU ] CS.d_b = 16 bit
00000812920i[CPU ] SS.d_b = 16 bit
00000812920i[CPU ] | EAX=c88e0010 EBX=0000000f ECX=00000002 EDX=00000000
00000812920i[CPU ] | ESP=0000fff4 EBP=00000000 ESI=00000143 EDI=0000ffe4
00000812920i[CPU ] | IOPL=0 NV UP DI NG NZ NA PE NC
00000812920i[CPU ] | SEG selector base limit G D
00000812920i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00000812920i[CPU ] | DS:2000( 0001| 0| 0) 00020000 000fffff 1 1
00000812920i[CPU ] | ES:2000( 0001| 0| 0) 00020000 000fffff 1 1
00000812920i[CPU ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000812920i[CPU ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000812920i[CPU ] | SS:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00000812920i[CPU ] | CS:2000( 0000| 0| 0) 00020000 0000ffff 0 0
00000812920i[CPU ] | EIP=00000337 (00000332)
00000812920i[CPU ] | CR0=0x60000011 CR1=0x00000000 CR2=0x00000000
00000812920i[CPU ] | CR3=0x00000000 CR4=0x00000000
00000812920i[ ] restoring default signal behavior
00000812920i[CTRL ] quit_sim called with exit code 1
Laut Bochs ist also in CS noch ein RealMode-Wert drin. In DS und ES ist limit fffff im gegensatz zu den anderen. obwohl ich cs auch geladen habe, scheint es ihn nicht zu interressieren!