Thema: Booten von Diskette führt zu sofortigem Reeboot?

[Noobtotal]

Also ich hab jetz meine ersten Zeilen Programmcode geschrieben. Sie sollen ein den PM schalten und ein Zeichen ausgeben. Nun rebootet mein Testrechner aber immer gleich, wenn ich von der Diskette boote. Ich hab den Bootloader unverändert von der ersten Ausgabe übernommen und die Deskriptoren mit Teejays Programm berechnet ( Nur vorrübergehend, ich werd die Werte der Deskriptoren später selber berechnen ! ).
Hier der Code:

Code: [Auswählen]


[Bits 16]
jmp start

NULL_DESCRIPTOR:

dd 0
dd 0

KERNEL_DESCRIPTOR:

dw 6FFFh
dw 1000h
db 0
db 98
db 40
db 0

DATEN_DESCRIPTOR:

dw 0x1FFF
dw 0x8000
db 0
db 96
db 40
db 0

GDT:

Limit dw 23
Base  dd NULL_DESCRIPTOR+0x10000

start:
cli
lgdt [GDT]
mov eax, cr0
or eax, 1
mov cr0, eax
db 0eah
                dw Protected_Mode_Test_Ausgabe_Viel
                dw 8
[Bits 32]
Protected_Mode_Test_Ausgabe_Viel:
mov [0xB8000] , byte "A"
mov [0xB8001] , byte 7
jmp Protected_Mode_Test_Ausgabe_Viel


[Jidder]

Ist das dein Bootsektor oder bereits der Kernel?

Wenn es ein Kernel sein soll, sehe ich nur einen Fehler:

Code: [Auswählen]

Base  dd NULL_DESCRIPTOR

Die Basis ist eine lineare Adresse. In deinem Fall ist der Wert von NULL_DESCRIPTOR 2, allerdings befindet sich die GDT an einer anderen Adresse. (Beispiel: Wenn der Kernel nach 0x10000 geladen ist, an der Adresse 0x10002.)

Wenn das im Bootsektor ist, kommt noch hinzu, dass ds undefiniert ist, und damit lgdt und dieser Frickeljump ins Leere gehen.

[Noobtotal]

Also den Bootsektor hab ich von der ersten Ausgabe übernommen. Das ist ein "Kernel". Das heisst, Base ist NULL_DESCRIPTOR+CS oder? In meinem Fall aber dann NULL_DESCRIPTOR+0x1000

[Jidder]

Wenn der Wert von CS 0x100 ist ja. Wenn er allerdings 0x1000 ist, dann muss es 0x10000 sein. (Umrechnung Segment -> Lineare Adresse)

[Noobtotal]

Ja, der Kernel liegt an der Adresse 0x1000. Ich hab also 0x10000 addiert, das Ergebnis ist allerdings das gleiche. Ich habs auch schon in Qemu probiert. Der bleibt einfach stehen. Also laut "info registers" ist GDT noch null, also dürfte er dort oder früher hängen bleiben. CS und so weiter hat allerdi gs schon die richtigen Werte, woraus ich schließe, das er irgendwo mitten im Kernel steht, ich weiss nur nicht, wo genau! Kann man mit Qemu vielleicht wie mit Bochs in einen Debug-Mode schalten. Oder zumindest die aktuelle Assembleranweiszung auslesen? Ich komm nähmlich nicht dahinter, wo der Fehler liegt!

[Noobtotal]

Argh! Das gibts doch nicht! Ich hab jetzt den Bootloader dr Ersten Ausgabe und den Kernel von TeeJays Tutorial unverändert übernommen! Ergebnis: Das gleiche! Am Prozessor kanns aber nicht liegen, isn Pentium 2, hat also auf jeden Fall alles was man für nen guten Sprung in den Protected Mode braucht!

[hannibal]

Wie waers mit `for: jmp for` debugging? Hilft oft um rauszufinden ab wo dein Code dich nicht mehr lieb hat.

Lg, Alex

[MNemo]

Du hast in deinem Kerneldiskriptor 98(=62h) stat 98h (oder 0x98) geschrieben
damit hast du ein datensegment mir DPL 3 (da kann man natürlich keinen code ausfüren)
und 40 stat 40h(0x40)
in deinem Datendiscriptor hast du auch das h vergessen!


Außerdem hast du das DS Register nicht installiert bevor du es mit
  MOV [0xB8001] ,...
verwendest