Im Bootloader schon in den Protected Mode schalten

fr33g

Hey Leute,
zur Zeit lese ich mir Erhards Tutorial durch und lese mich auch durch die diversen OS-Dev Wikis. Ich tippe den Code vom Tut dann immer ab und probiere ihn dann nachzuvollziehen. Erst dann geh ich den nächsten Abschnitt an. Allerdings entwickel ich dazu parallel mein eigenes OS, wenn ich einen Teil vom Tut fertig habe, update ich mein eigenes OS immer eine Version weiter, sprich ich probier das gelernte dort einzusetzen, aber eben auf meine Weise:-P und probiere natürlich neue Dinge zu versuchen.
Daher wollte ich nun schon in meinem selbst geschriebenen Bootloader in den Protected Mode springen. Nach kurzer Überlegung, erwies sich dies jedoch als schwerer als Gedacht... Ich dachte zuerst, ich lade den Kernel an eine Adresse und springe dann in den Protected Mode, allerdings ist der Kernel ja dann auf nicht einmal maximal 1MB begrenzt, reicht zwar für den Anfang, aber es geht ja auch ums Prinzip. Nun wenn ich vorher in den Protected Mode schalte, kann ich allerdings den Kernel nicht mehr mit Hilfe des BIOS laden, daher nun die Frage wie man dies am besten manuell erledigt. Vielleicht hat ja jemand einen Link oder kann mir die grobe Vorgehensweise kurz erläutern. Schonmal vielen Dank

Lg freeG

taljeth

Entweder du begnügst dich damit, dass 640k für jeden genug sein sollten und lädst den Kernel halt dort hin, wo es dein eingeschränkter Bootloader erlaubt. Oder du machst einen anständigen Bootloader, der selbst schon im Protected Mode läuft und für den Hardwarezugriff in den Real Mode zurückschaltet (bzw. VM86 benutzt, aber das lohnt sich in einem Bootloader wohl nicht). Dann brauchst du nur einen kleinen Bounce Buffer in den unteren 640k, wo der BIOS-Interrupt reinschreiben kann, und dein PM-Code kann die Daten dann an die wirkliche Zieladresse über 1 MB kopieren.

Erhard Henkes

Im aktuellen doppelstufigen Bootloader von PrettyOS schaltet Stage 2 von RM nach PM um:

boot2.asm, zeile 102:

; switch to PM
    mov si, msgSwitchToPM
    call print_string
    cli
    mov eax, cr0                       ; bit 0 in CR0 has to be set for entering PM
    or al, 1
    mov cr0, eax
    jmp DWORD CODE_DESC:ProtectedMode  ; far jump to code selector (cs = 0x08)

[Bits 32]
ProtectedMode:
    mov ax, DATA_DESC                  ; set data segments to data selector (0x10)
    mov ds, ax
    mov ss, ax
    mov es, ax
    mov esp, 0x9000

taljeth

Das hätte jetzt fast was mit der Frage zu tun gehabt.

Erhard Henkes

Frage:

wenn ich vorher in den Protected Mode schalte, kann ich allerdings den Kernel nicht mehr mit Hilfe des BIOS laden, daher nun die Frage wie man dies am besten manuell erledigt.

Antwort: Das stimmt, nach dem Umschalten in den PM ist das BIOS zunächst weg, daher lädt man beispielsweise zuerst den Kernel (wir verwenden hierfür FAT12) und schaltet erst anschließend um in den PM, oder man verwendet die von meinem Vorschreiber angesprochenen Methoden.

fr33g

Ok, allerdings verstehe ich Taljeths Methode nicht so ganz. Ich schalte erst in den Protected Mode, so bereite alles vor, schalte dann in den Real Mode zurück um den Kernel zu laden, welchen ich dann anschließend im Protected Mode an meine gewünschte Stelle kopiere. Aber dadurch kann der Kernel doch wieder nicht größerals 640k sein oder übersehe ich da gerade etwas?

Lg freeG

Erhard Henkes

Ich schalte erst in den Protected Mode, so bereite alles vor, schalte dann in den Real Mode zurück um den Kernel zu laden, welchen ich dann anschließend im Protected Mode an meine gewünschte Stelle kopiere.

Man kann auch die Hose mit der Beißzange anziehen.
Es gibt da schon einige Dinge zwischen RM und PM, aber für dich als Einsteiger ist die von mir oben erwähnte Methode sicher die verständlichste. Normalerweise empfiehlt taljeth GRUB, weil du dich auf den Kernel konzentrieren sollst und nicht auf den Bootloader.

XanClic

fr33g schrieb:

Aber dadurch kann der Kernel doch wieder nicht größerals 640k sein oder übersehe ich da gerade etwas?

Ja. Zuerst einmal lädst du einen Sektor (oder auch ein paar mehr) der Datei im RM. Dann schaltest du in den PM und kopierst die Daten dahin, wo du sie im Speicher haben willst. Dann schaltest du wieder zurück in den RM und liest weitere Daten, gehst wieder in den PM, kopierst sie „hoch“ in den Speicher, liest wieder etwas im RM usw. usf., bis die gesamte Datei eingelesen ist. Dadurch kannst du insgesamt (theoretisch) so viele Daten lesen, wie in den im PM adressierbaren Speicher passen.

(Theoretisch kann man sich die Umschalterei auch sparen, aber das fällt dann unter die von ehenkes erwähnten „Dinge zwischen RM und PM“.)

taljeth

Stimmt, an Unreal Mode habe ich nicht gedacht, das wäre natürlich auch noch eine Option. Aber letztendlich braucht man dafür doch auch nicht wesentlich weniger (oder wesentlich anderen) Code als fürs Zurückschalten in den RM.

Ansonsten erklärt XanClic genau das, was ich meine, und wie auch andere Bootloader vorgehen, auch wenn sich Erhard drüber lustig macht, vermutlich weil sein eigener Bootloader das nicht kann.

Erhard Henkes

Unser Bootloader setzt Unreal Mode ein, auch wenn du das nicht für möglich hältst. Wir sind übrigens sehr zufrieden mit PrettyOS, und deine lächerlichen kleinen Sticheleien amüsieren uns immer aufs Neue. Mach ruhig weiter so, das spornt uns nur an.

Unreal Mode: http://wiki.osdev.org/Unreal_Mode

The reason for doing this is to enable 32-bit offsets in real mode.

fr33g

Ok vielen Dank, das klingt logisch. Jetzt verstehe ich es auch Probier ich mal umzusetzen. Ich weiß das ein eigener Bootloader der auch richtig arbeiten soll nicht so easy is, aber ich mag das eben trotzdem selber anständig machen, und werde es auch schaffen

Also vielen Dank für die Hilfe

Lg freeG

Erhard Henkes

OK, lass uns an deinen Fortschritten teil haben. Mit dem 2-stage-BL in PrettyOS hast du eine Vorlage.