Thema: PMODE geht nimmer wenn VESA aktiviert ist.

[Another Stupid Coder]

Also, ich habe mal wieder (wie sooft) ein Problem: Der PMode funktioniert einwandfrei (noch immer BlueXSevens Code aus dem Pmode-Thread, wenn er was dagegen hat, soll er sich bitte per PM oder einfach hier melden ) doch wenn ich in einen VBE-Modus (0x0100 + LFB = 0x4100) schalte, geht auch das, nur dann geht der Jump in den PMode nimmer.
Hier der Bochs-Error:

Code: [Auswählen]


00000697755i[VGA  ] VBE enabling x 640, y 400, bpp 8, 256000 bytes visible
00000697856p[CPU  ] >>PANIC<< jump_protected: task gate.p == 0

und nun der Code:

Code: [Auswählen]



[bits 16]

jmp Start

; ---------------------------------------
; - Global Descriptor Table. -
; ---------------------------------------
Descriptors dw 0x0000
dw 0x0000
db 0x00
db 0x00
db 0x00
db 0x00

dw 0xFFFF
dw 0x0000
db 0x00
db 0x9A
db 0xCF
db 0x00

dw 0xFFFF
dw 0x0000
db 0x00
db 0x92
db 0xCF
db 0x00

GDT dw 23
dd 0
; ---------------------------------------
; - VESA block. -
; ---------------------------------------
VbeSignature db "VBE2"
VbeVersion dw 0x0200
OemStringPtr dd 0x0
Capabilities dd 0x0
VideoModePtr dd 0x0
TotalMemory dw 0x0
OemSoftwareRev dw 0x0
OemVendorNamePtr dd 0x0
OemProductNamePtr dd 0x0
OemProductRevPtr dd 0x0
Reserved times 222 db 0x0
OemData times 256 db 0x0
SixtyFourBytes times 64 db 0x0
; ---------------------------------------
; - ModeInfo block. -
; ---------------------------------------
ModeAttributes dw 0x0
WinAAttributes db 0x0
WinBAttributes db 0x0
WinGranularity dw 0x0
WinSize dw 0x0
WinASegment dw 0x0
WinBSegment dw 0x0
WinFuncPtr dd 0x0
BytesPerScanLine dw 0x0
XResolution dw 0x0
YResolution dw 0x0
XCharSize db 0x0
YCharSize db 0x0
NumberOfPlanes db 0x0
BitsPerPixel db 0x0
NumberOfBanks db 0x0
MemoryModel db 0x0
BankSize db 0x0
NumberOfImagePages db 0x0
Reserved2 db 0x0
RedMaskSize db 0x0
RedFieldPosition db 0x0
GreenMaskSize db 0x0
GreenFieldPosition db 0x0
BlueMaskSize db 0x0
BlueFieldPosition db 0x0
RsvdMaskSize db 0x0
RsvdFieldPosition db 0x0
DirectColorModeInfo db 0x0
PhysBasePtr dd 0x0
Reserved3 dw 0x0, 0x0, 0x0
LinBytesPerScanLine dw 0x0
BnkNumberOfImagePages db 0x0
LinRedMaskSize db 0x0
LinRedFieldPosition db 0x0
LinGreenMaskSize db 0x0
LinGreenFieldPosition db 0x0
LinBlueMaskSize db 0x0
LinBlueFieldPosition db 0x0
LinRsvdMaskSize db 0x0
LinRsvdFieldPosition db 0x0
MaxPixelClock dd 0x0
Reserved4 times 189 db 0x0

Start:

; ---------------------------------------
; - VBE. -
; ---------------------------------------

mov ax, VbeSignature
stosw
mov ax, 0x4F00
int 0x10
cmp al, 0x004F
je .1
.1:
mov ax, SixtyFourBytes
stosw
mov ax, 0x4F02
mov bx, 0x4100 ; # of the Mode.
int 0x10


; ---------------------------------------
; - Protected Mode Start. -
; ---------------------------------------
mov ax, cs
mov ds, ax

cli

xor eax, eax
mov ax, ds
shl eax, 4
add eax, Descriptors
mov dword [GDT+2], eax

lgdt [GDT]

mov eax, cr0
or al, 00000001b
mov cr0, eax

jmp 0x0008:dword 0x10000+ProtectedMode

; =======================================
; = Here starts 32bit protected mode. =
; =======================================

[bits 32]


ProtectedMode:

mov ax, 0x0010
mov ds, ax
mov es, ax
mov ss, ax
mov fs, ax
mov gs, ax
mov esp, 0x1FFFFF

mov edi, 0x000B8000
mov Byte [edi  ], 'L'
mov Byte [edi+2], 'O'
mov Byte [edi+4], 'W'

; ---------------------------------------
; - Functions and variables. -
; ---------------------------------------

Absolut nicht schön, aber ich wollte erstmal das es funktioniert bevor ich den Code schöner mache und ihn eventuell in ein Tut einbaue (daher sind auch ALLE Bytes "belabelt" (was für eine Tipp-Arbeit!).

[Another Stupid Coder]

Danke, sehr nett von dir
k, "mov di, VbeSignature" sollte genauso funktionieren, ist klar
Das der Grafikspeicher nichtmehr konstant ist, ist mir durchaus bewusst, mein Plan war ja nur erstmal in den Mode zu switchen (was sogar mit Pmode gelungen war) und dann die ModeInfos zu holen (WICHTIG: Erst seit ich den ModeInfo-Block eingebaut habe und die Abfrage für die Modeinfos, funzt das ganze nimmer!) denn PhysBasePtr kenne ich erst, wenn ich die ModeInfos habe

[joachim_neu]

aha... "00000697856p[CPU  ] >>PANIC<< jump_protected: task gate.p == 0"... scheint, als bist du schon im PM!? komisch! aber ich habe ja auch die probleme mit den jump, und da is auch VESA an... sehr komisch!

[Another Stupid Coder]

Also, ich habe nun die GDT ein Stück verschoben (im Code) nämlich steht diese jetzt direkt hinter dem VESA Block, nichtmehr davor (für den Fall der unerreichbarkeit) und es kommt tatsächlich was anderes: Nun meint Bochs:

Code: [Auswählen]


00006637769i[VGA  ] VBE enabling x 640, y 400, bpp 8, 256000 bytes visible
00006932020e[CPU  ] jump_protected: cs == 0
00006932020e[CPU  ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

Nur habe ich keine Ahnung wodurch das aufgelöst werden könnte...falls es jemand testen will (eh fast das gleiche wie oben):

Code: [Auswählen]



[bits 16]

jmp Start

; ---------------------------------------
; - VESA block. -
; ---------------------------------------
VbeSignature db "VBE2"
VbeVersion dw 0x0200
OemStringPtr dd 0x0
Capabilities dd 0x0
VideoModePtr dd 0x0
TotalMemory dw 0x0
OemSoftwareRev dw 0x0
OemVendorNamePtr dd 0x0
OemProductNamePtr dd 0x0
OemProductRevPtr dd 0x0
Reserved times 222 db 0x0
OemData times 256 db 0x0
SixtyFourBytes times 64 db 0x0
; ---------------------------------------
; - ModeInfo block. -
; ---------------------------------------
ModeAttributes dw 0x0
WinAAttributes db 0x0
WinBAttributes db 0x0
WinGranularity dw 0x0
WinSize dw 0x0
WinASegment dw 0x0
WinBSegment dw 0x0
WinFuncPtr dd 0x0
BytesPerScanLine dw 0x0
XResolution dw 0x0
YResolution dw 0x0
XCharSize db 0x0
YCharSize db 0x0
NumberOfPlanes db 0x0
BitsPerPixel db 0x0
NumberOfBanks db 0x0
MemoryModel db 0x0
BankSize db 0x0
NumberOfImagePages db 0x0
Reserved2 db 0x0
RedMaskSize db 0x0
RedFieldPosition db 0x0
GreenMaskSize db 0x0
GreenFieldPosition db 0x0
BlueMaskSize db 0x0
BlueFieldPosition db 0x0
RsvdMaskSize db 0x0
RsvdFieldPosition db 0x0
DirectColorModeInfo db 0x0
PhysBasePtr dd 0x0
Reserved3 dw 0x0, 0x0, 0x0
LinBytesPerScanLine dw 0x0
BnkNumberOfImagePages db 0x0
LinRedMaskSize db 0x0
LinRedFieldPosition db 0x0
LinGreenMaskSize db 0x0
LinGreenFieldPosition db 0x0
LinBlueMaskSize db 0x0
LinBlueFieldPosition db 0x0
LinRsvdMaskSize db 0x0
LinRsvdFieldPosition db 0x0
MaxPixelClock dd 0x0
Reserved4 times 189 db 0x0
; ---------------------------------------
; - Global Descriptor Table. -
; ---------------------------------------
Descriptors dw 0x0000
dw 0x0000
db 0x00
db 0x00
db 0x00
db 0x00

dw 0xFFFF
dw 0x0000
db 0x00
db 0x9A
db 0xCF
db 0x00

dw 0xFFFF
dw 0x0000
db 0x00
db 0x92
db 0xCF
db 0x00

GDT dw 23
dd 0

Start:

; ---------------------------------------
; - VBE. -
; ---------------------------------------

mov ax, VbeSignature
stosw
mov ax, 0x4F00
int 0x10
cmp al, 0x004F
je .1
.1:
mov ax, SixtyFourBytes
stosw
mov ax, 0x4F02
mov bx, 0x4100 ; # of the Mode.
int 0x10


; ---------------------------------------
; - Protected Mode Start. -
; ---------------------------------------
mov ax, cs
mov ds, ax

cli

xor eax, eax
mov ax, ds
shl eax, 4
add eax, Descriptors
mov dword [GDT+2], eax

lgdt [GDT]

mov eax, cr0
or al, 00000001b
mov cr0, eax

jmp 0x0008:dword 0x10000+ProtectedMode

; =======================================
; = Here starts 32bit protected mode. =
; =======================================

[bits 32]


ProtectedMode:

mov ax, 0x0010
mov ds, ax
mov es, ax
mov ss, ax
mov fs, ax
mov gs, ax
mov esp, 0x1FFFFF

mov edi, 0x000B8000
mov Byte [edi  ], 'L'
mov Byte [edi+2], 'O'
mov Byte [edi+4], 'W'

; ---------------------------------------
; - Functions and variables. -
; ---------------------------------------


[Roshl]

jmp   0x0008:dword   0x10000+ProtectedMode
Das da ist totaler Blödsinn.
Dort kommt noch kein dword hin, sondern nur ein word, also das 0x10000+PM geht nicht weil 0x10000 mehr als ein word ist. Demzufolge düfte der an eine falsche Stelle springen^^. In solchem Falls muss man den Deskriptor bei 0x10000 anfangen lassen und danach auch 0x10000 umbauen, weil dann gehen dort dword's^^

[Another Stupid Coder]

@Roshl Ne, BlueXSeven hat schon Recht, sein Code funzt ja ohne dem VESA-Zeugs einwandfrei
@BlueXSeven Okay, du hattest Recht ich hatte vergessen die Anzahl der Sectoren zu erhöhen, war noch immer auf 2 ^^ Aber da es bei dir gefunzt hat, muss ich den Loader jetzt wohl nochmal überfliegen, denn jetzt sagt mir Bochs:

Code: [Auswählen]


00000633108e[HD   ] device set to 0 which does not exist
00000633401e[HD   ] device set to 1 which does not exist
00000727573p[CPU  ] >>PANIC<< prefetch: RIP > CS.limit
Blöder IP

[Roshl]

Tut mir wirklich leid euch da enttäusche zu müssen, aber ich habe mir keineswegs selbst wiedersprochen. Dieser jump der zum flashen der Befehlskette dient, liegt noch im 16Bit Bereich, also kann dort auch nur ein 16Bit Offset angegeben werden. Deswegen ist 0x10000 zu gross, und deswegen kann dort auch kein dword sein. Das ist schon alles richtig so.
Das er dann zu kurz springt ist klar, weil er nur 0x0000 statt 0x10000 nimmt, deswegen ja auch dieser ganze quatsch mit deskriptor bei 0x10000 anfangen lassen, in 32 bit springen, descriptor umbauen und wieder springen, den TeeJay und ich und viele andere dort veranstalten.
Zitat TeeJay's PM-Tut:

Das Dumme ist nur, das dieser FAR JUMP eine gewisse Einschränkung hat. Wir können da nämlich nur den Selektor für das Code Segment und eine 16-Bit Offset Adresse angeben. Und genau bei diesen 16 Bit liegt unser Problem. Die meisten Leute (so wie ich) laden ihren Kernel an die Lineare Adresse 0x10000. Diese Adresse ist aber mit einem 16 Bit Wert nicht mehr erreichbar. Das heisst wir können nicht in das Code Segment springen, das ja bei der Linearen Adresse 0 beginnt und gleichzeitig zu dem Offset springen das genau hinter unserem FAR JUMP Befehl liegt. Daher müssen wir uns abhelfen. Um das Problem zu lösen, werden wir zur Laufzeit den Deskriptor für das Code Segment so umschreiben, das seine Lineare Basisadresse nicht mehr bei 0 liegt, sondern bei der Linearen Adresse an welche wir unseren Kernel geladen haben. Nämlich 0x10000.

Kurz: dieser jump ist nur eine 16:16 Kombination, keine 16:32, deswegen kein dword, kein 0x10000, nichts.
Wer hat nun recht?

[Roshl]

der prefix gilt weit ich weiss nur für die operanten also eax,statt ax, nicht für die adressen

[TeeJay]

Der Prefix 66h hat soweit ich weiß nur eine Bedeutiung sofern man, mit 32 Bit registern Arbeitet. Sprich wenn man 32-Bit Werte bearbeitet und hin und herschiebt.

Bei einem Jump sieht das wieder ganz anders aus. Im RM geht der Prozzi ja davon aus das es nur einen 20 Bit breiten Adressbus gibt. Da kann er auch mit dem 66h nix zaubern

[Roshl]

Wenn dem so ist waren TJ und ich wohl bisher falsch
Aber bei dem Linux-Ausschnitt dort, wird als Offset auch nur 0x1000 angegeben , das würde auch in 16Bit passen.
Was für einen Sinn (ausser eben bei diesem einen jmp) sollte es denn machen im RM Sprünge mit 32-Bit-Offset zu machen. Ich werde es mal in meinem Kernel kurz testen.

Ergebniss: Wenn ich jmp 0x18:dword 0x10000 angebe sagt mir der assembler dass dies eine nicht erlaubte opcode-Kombination ist. Allerdings manuell kodiert, als db 0x66,0xea dd 0x10000 dw 0x18, führt er den jump korrekt aus. Kann Intel denn nicht einmal konsequent sein? 16Bit heisst 16Bit und nicht "ach lassen wir den Programmierer mal machen".
Anway, der jump in der Form braucht 3-Bit mehr, und da ich alles im Bootloader erledige ist da eh schon kein Platz^^