Eigenes OS?



  • Erhard Henkes schrieb:

    Geht das nicht einfacher als unten im Code?

    wahrscheinlich nicht.

    Erhard Henkes schrieb:

    Ist schwierig zu verstehen.

    du wolltest doch unbedingt das x86-flickwerk nehmen. jetzt musst da wohl durch.
    🙂



  • Das ist nicht unbedingt ein Problem von NASM (bzw. mir faellt kein Assembler ein, mit dem das wirklich geschickter ginge), sondern eine Eigenart des x86, dass hier in einem Code einfach verschiedene Adressierungsmechanismen zum Zugriff auf die selben Labels benutzt werden.
    Am saubersten waere es IMHO, wenn du dafuer sorgst, dass dieses Phaenomen der unterschiedlichen Basisadressen gar nicht erst auftritt. Dazu musst du in diesem Code-Abschnitt immer die Segment-Basis 0 benutzen (im RM also alle Segmentregister auf 0 setzen, dh. der Code muss auch in den ersten 64K Speicher liegen, im PM die Basisadresse fuer Zugriffe auf diesen Code auch 0) und an den Anfang des Codes entsprechend eine org-Anweisung mit dem Start-Offset des Codes zur Basis 0 (also das Offset innerhalb der ersten 64k, wo der Code anfaengt).
    32Bit-Segmente mit Basis 0 und bis zu 4GB Groesse zu verwenden, bietet sich dann im PM spaeter natuerlich so oder so auch an...
    So kannst du dir dann auch zB. den extra-Descriptor fuer die Textausgabe sparen und hast einen leichteren Uebergang zu C-Code (wie wuerde man direkt aus c heraus ueberhaupt mit verschiedenen Selectoren umgehen?).
    So solltest du keine Probleme mit irgendwelchen "org"ien oder "Kunstgriffen" mit addierten Basisadressen o.Ae. bekommen.

    Falls du deinen Code unbedingt im Segment 1000 lassen willst, kommst du um einiges Gebastel mit Addition der phys. Basisadresse (10000) zur Adresse der GDT und evtl. die Differenz der Basisadressen der Code-Segmente in RM und PM zum Far-Jump in den PM wahrscheinlich nicht umhin.
    Das waere dann immerhin evtl. eine gute Gelegenheit, die Adressierungsmechanismen des RM, rein physikalischer Adressen und PM ohne paging genauer zu beleuchten... wenn du das wirklich sauber kommentierst und erklaerst.

    Noch zu etwas Anderem:
    In meinem letzten OS-Projekt in der Uni, und nun in deinem Code, wurde mir mal wieder deutlich vor Augen gefuehrt, dass es nicht "cool", sondern hoechstens verwirrend ist, irgendwelche weitgehend unkommentierten Zahlen zur Darstellung von Bit-flags hinzuklatschen. Du tust deinen Lesern sicher einen Gefallen, wenn du flags in den Deskriptoren genauer kommentierst.

    Mich wuerde auch interessieren, weshalb du meinen Tipp zu deinem strcmp nicht uebernummen hast?


  • Mod

    Mich wuerde auch interessieren, weshalb du meinen Tipp zu deinem strcmp nicht uebernummen hast?

    @Nobuo T:
    Sorry, hatte vergessen, es auch im Tutorial einzutippen. Dein Tipp ist hervorragend! Code ist jetzt kürzer: Carry-Flag weg und nur noch eine Rücksprungadresse '.done'

    ..

    Ich hoffe zumindest, dass ich Dich so richtig verstanden habe.
    Wie hättest Du dies mit 'test op,op' (AND-Verknüpfung ohne Speicherung, nur Flags setzen) gemacht? Das nimmt man doch eher, um zu testen, ob ein bestimmtes Bit gesetzt ist? z.B. test AL, 64 (check auf Bit 6)

    Bezüglich RM -> PM bin ich noch am Grübeln. da muss ich noch einige Hobby-OS analysieren. Vielleicht kann man die besten Ideen aus allen heraus kristallisieren. Die Idee von Nobuo T ist auf jeden Fall bedenkenswert. Welchen offset würde man da mittels org wählen und warum? Mir ist noch nicht klar, warum die meisten den Kernel (oder ersten Teil des Kernels) nach 10000h setzen.

    ... dass es nicht "cool", sondern hoechstens verwirrend ist, irgendwelche weitgehend unkommentierten Zahlen zur Darstellung von Bit-flags hinzuklatschen. Du tust deinen Lesern sicher einen Gefallen, wenn du flags in den Deskriptoren genauer kommentierst.

    Völlig richtig! So darf man das auch nicht machen, war nur Test.
    Besser: binäre Darstellung im Assemblercode mit Kommentar, der die einzelnen Bits bezüglich ihrer Aufgabe beschreibt/erklärt. 👍


  • Mod

    Zunächst mal vielen Dank an alle, die mich bisher nicht entmutigten, sondern mich mit Rat und Tat unterstützen. IMHO ein wirklich konstruktives Subforum.

    Für die Ungeduldigen:
    Nun wollen wir mal versuchsweise von RM nach PM schalten (ist noch nicht im Tutorial, weil didaktisch noch nicht klar genug), indem man den Befehl "pm" eingibt.

    Ich habe zunächst die Methode der Kalkulation für die GDTR-Werte nach dem Umschalten verwendet, um zu sehen, ob das alles gut klappt. Funktioniert wirklich. Didaktisch ist dieser Weg nicht perfekt, lässt sich aber dennoch erklären. Vielleicht kann Nobuo T seine Idee daneben stellen zum Vergleich.

    Nun fehlt didaktisch nur noch ein Command Line Interpreter und ein Befehl "RM" im Protected Mode, der den Rücksprung nach Real Mode gewährt.

    In Zeile 277 steht noch nichts Sinnvolles als Zieladresse (zur Zeit wird der Code "gedumpt", ich habe mal in DL mit den Farben gespielt). Hat jemand eine kleine gute Idee für den Einstieg?

    Typisch wäre jetzt ein Sprung in einen C-Kernel. Aber inzwischen gefällt mir Assembler viel besser. Man gewöhnt sich an alles. 😉



  • Hallo,

    habe mal den Code in bochs ausprobiert, weiss nicht, ist es normal, dass nach dem Kommando pm lauter farbiger Zeichen erscheinen... 😉
    Bezüglich der drei Zeilen:

    db    0xea            ; instruction code for FAR JUMP
      dw    ProtectedMode        ; offset for jump
      dw    0x8            ; selector of the segment for the jump
    

    Man kann sich die Binärdatei mit dem Programm ndisasm, das mit nasm mit dabei ist, disassemblieren lassen, z.B. so:

    c:\nasm-2.06rc6\ndisasm.exe -b 16 kernel.bin
    

    Dann sieht man, wie ndisasm es interpretiert:

    000001E4  EA57020800        jmp word 0x8:0x257
    

    Also kann man die oberen 3 Zeilen durch eine ersetzen:

    jmp word 0x8:ProtectedMode
    

    Damit wird scheinbar auch ein FAR JUMP generiert. Man kann es auch hier nachlesen: http://www.nasm.us/doc/nasmdo10.html#section-10.1
    Ich hab es mal ausprobiert und es kommen immer noch die farbigen Zeichen - also wahrscheinlich funktioniert es wie vorher. Und die ndisasm Ausgabe stimmt auch mit der vorherigen überein.


  • Mod

    habe mal den Code in bochs ausprobiert, weiss nicht, ist es normal, dass nach dem Kommando pm lauter farbiger Zeichen erscheinen... 😉

    Das Progrämmchen war nur Spaß zum Testen, lief durch die Strings und wechselte die Farbe bei jedem 'NUL'. Ich bräuchte das hier:

    Hat jemand einen ASM-Code für '.clearScreen' (ab 0xB0000) und '.eineSekundePause' in PM?
    Dann könnte man dies hier machen:

    ProtectedMode2:
      mov ecx, 0x0B8000
      mov esi, 0x10000 + msg_pm2 ; 'OS currently uses Protected Mode.'
      mov dl,  0x01
    .endlessloop:
      call .eineSekundePause
      call .clearScreen
      inc dl
      cmp dl, 0x15
      jz .resetcolor
      call PutStr_32
      jmp .endlessloop
    .resetcolor:
      xor dl, dl
      jmp .endlessloop
    

    Bestimmt nicht schlecht für den Anfang. 😉

    jmp word 0x8:ProtectedMode
      ;db	0xea			; instruction code for FAR JUMP
      ;dw	ProtectedMode		; offset for jump
      ;dw	0x8			; selector of the segment for the jump
    

    Ja, geht! Offenbar gibt es bei manchen Compilerversionen Probleme, sonst würden nicht viele sich zu diesem Kunstgriff retten.


  • Mod

    Die Subroutine ClrScr32 bewirkt einen Reboot. Kommentiert man den Befehl aus, läuft der String 'OS currently uses Protected Mode.' oben links in 16 Farben durch. Ich möchte nur jeweils vorher den Bildschirm löschen. Code macht aber Probleme. Vielleicht hat jemand eine Idee?

    ..


  • Mod

    Im Tutorial könnte man den clrscr zunächst noch im RM ausführen. GDT habe ich
    nach gdt.inc ausgelagert. Inzwischen alles schon ganz schön unübersichtlich.
    So sieht momentan eine zumindest in Bochs binär von Platte funktionierende Version (von floppy im PC booten klappt momentan nicht?) aus:

    ..


  • Mod

    Ich habe das OS auf einem alten PC (AMD 1400 MHz) getestet. Dort rebootet er bei Eingabe "pm", während bochs das OS brav von Diskette schluckt. Weiß jemand, wo der "real wirksame" Fehler liegt?

    Didaktisch steckt das "OS" momentan im Schlamm, da ich momentan nicht sicher bin, wie man das Ganze am besten in kleine Häppchen verpacken kann. Was würdet ihr in welche inc-Dateien packen? Man kann das ja auch kaum noch sinnvoll hier posten (warum gibt es keine scroll-Funktion für solche Dateien wie in anderen Foren?).

    lgdt [gdt] findet man in google 216 mal.
    lgdt [gdtr] findet man in google 740 mal.
    Letzteres ist ja auch richtiger, werde das anpassen.

    Jemand hatte auch nach Einstieg in x86-64 gefragt. Hier sind Links dazu:
    http://wiki.osdev.org/Entering_Long_Mode_Directly
    http://en.wikipedia.org/wiki/Long_mode



  • Ok, mal der Reihe nach abarbeiten...

    Erhard Henkes schrieb:

    Ich hoffe zumindest, dass ich Dich so richtig verstanden habe.
    Wie hättest Du dies mit 'test op,op' (AND-Verknüpfung ohne Speicherung, nur Flags setzen) gemacht? Das nimmt man doch eher, um zu testen, ob ein bestimmtes Bit gesetzt ist? z.B. test AL, 64 (check auf Bit 6)

    Ja, so war das gedacht, sieht ok. 🙂
    "test" kannst du sowohl, wie du schreibst, benutzen, um einzelne Bits zu testen, allerdings erzielst du mit "test al, al" praktisch das gleiche Ergebnis wie mit "or al, al" (oder wohl auch "and al, al", wenn wir schon dabei sind), ist aber IMHO zumindest konsequenter. 🙂

    Erhard Henkes schrieb:

    Welchen offset würde man da mittels org wählen und warum?

    Das offset, an den du den Code im RAM bzgl. Segment 0 kopierst. Da bietet sich IMHO zB. 8000h an...

    Erhard Henkes schrieb:

    Mir ist noch nicht klar, warum die meisten den Kernel (oder ersten Teil des Kernels) nach 10000h setzen.

    ...aus dem selben Grund, aus dem wohl auch viele Frickler ihren Code nach 10000h laden: Es ist einfach eine schoene runde Adresse. Und bei 10000h laeuft man praktisch auch keine Gefahr mehr, irgendwo mit den Untiefen der BDA in Konflikt zu geraten. 8000h sollte da AFAIK aber auch sicher und "rund" genug sein.

    Erhard Henkes schrieb:

    Ich habe das OS auf einem alten PC (AMD 1400 MHz) getestet. Dort rebootet er bei Eingabe "pm", während bochs das OS brav von Diskette schluckt. Weiß jemand, wo der "real wirksame" Fehler liegt?

    Ohne zu testen, kommt mir folgendes eigenartig vor:

    ;z234-237, kernel.asm
      mov    WORD [CODE_Desc+2], 0    ; code segment base address = 0
      mov    WORD [DATA_Desc+2], 0    ; data segment base address = 0
      mov    BYTE [CODE_Desc+4], 0    ; code segment base address = 0
      mov    BYTE [DATA_Desc+4], 0    ; data segment base address = 0
    

    Halte ich durchaus fuer problematisch, mit den RM-Segmenten im PM auf den Speicher zuzugreifen. -> Mein Tipp waere, das Ganze als initialisierte Daten anzulegen, dann kannst du dir diesen Code (wie die restliche Initialisierung in z 104 eigentlich auch) sparen.

    Ausserdem bekommst du potentiell Probleme, wenn du auf Speicher >1MB zugreifst (stack), ohne die A20 eingeschaltet zu haben.

    ...

    Erhard Henkes schrieb:

    Vielleicht kann Nobuo T seine Idee daneben stellen zum Vergleich.

    ...seufz... Das wuerde einiges an Arbeit, da ich deinen Code erst recht nicht ohne Testen umfangreich umschreiben und hier einstellen will. Mal sehen, ob ich heute Abend Zeit und Nerv finde.

    Zu deinem clearscreen32:
    32Bit loop und rep benutzen ecx... Vielleicht liegt es daran.


  • Mod

    Zu test op,op:
    Ich dachte, Du würdest dies als Ersatz für cmp op,op einsetzen wollen.

    Ich habe leider noch nicht genau verstanden, wie Du das mit den initialisierten Daten als Vereinfachung meinst. Ein konkreter Vorschlag würde hier echt helfen.

    Wie kann man in Bochs eigentlich die Belegung des Speichers visualisieren?
    Kenne bisher nur den Bochs Debugger mit der Register-Visualisierung.
    Ist das biedere Bochs eigentlich das ideale Tool bezüglich Visualisierung oder hat jemand bessere Erfahrung mit anderen Emulationen gemacht? Einer der didaktischen Probleme ist ja, dass man überhaupt nicht "sieht", in welchem Mode (RM, PM) man sich befindet, ob A20 aktiviert ist, usw. Da ist eines der Probleme beim Einstieg in die OS-Entwicklung.


  • Mod

    ...seufz... Das wuerde einiges an Arbeit, da ich deinen Code erst recht nicht ohne Testen umfangreich umschreiben und hier einstellen will. Mal sehen, ob ich heute Abend Zeit und Nerv finde.

    Hier ist noch eine andere ältere (Okt. 1996) Quelle für dieses Vorgehen:
    http://www.fh-zwickau.de/doc/prmo/pmtutor/code/pmode/pm_01.asm (einfach)
    http://www.fh-zwickau.de/doc/prmo/pmtutor/code/pmode/pm_07_03.asm (komplex mit multitasking)

    Dies war wahrscheinlich auch Vorbild für die bereits o.g. Vorgehensweise, die Dir nicht sonderlich gefällt:
    http://lowlevel.brainsware.org/wiki/index.php/Protected_Mode

    Erklärbar ist es auf jeden Fall ganz gut.
    Mich irritiert momentan, dass es in Bochs läuft, aber auf einem alten PC von Floppy nicht bootet. 🙄


  • Mod

    Ich habe als Vorbereitung etwas zu RM und PM geschrieben:
    http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId362977

    Es ist wichtig, dass man die Erklärungen und Zeichnungen möglichst einfach und richtig versteht. Ansonsten versteht man die praktische Abfolge hinterher falsch. Könnt ihr das bitte mal checken?

    Die nächste geistige Reihefolge wäre dann z.B.:

    1. Selektor (hier kommen GDT und LDT sowie die Privilege Levels 0-3 ins Spiel)
    2. Aufbau GDT
    3. Welche Deskriptoren gibt es noch?
    4. Interrupts
    5. Programmablauf in PM
    6. Multitasking


  • Ich habe deine Quellcodes mal etwas umgebaut. Um die Scrollerei einzudaemmen, habe ich die Dateien mal hier hochgeladen.
    Waere praktisch, wenn du die Quellcodes in deinem Tutorial auch direkt als Downloads haettest (habe sie zumindest nicht gefunden).
    Eine aufschlussreiche Seite zum A20-Kram ist zB. hier zu finden.

    Zu deinem Text:
    Begriffe im Deutschen werden meist ziemlich nach Lust und Laune verwendet, aber
    lineare und physikalische Adresse ist AFAIK nicht das Gleiche. Spaetestens beim Paging nicht: Da wird aus der linearen (zT. dann auch logische Adresse genannt) Adresse mit der PageTable erst die physikalische Adresse gewurstet.

    IMHO koenntest du noch etwas ausfuehrlicher darauf eingehen, warum fuer Multitasking nun auf einmal Schutzmechanismen noetig sind, und warum fuer DOS nicht, bzw. was unter Multitasking grob zu verstehen ist.

    Ansonsten bin ich mir nicht sicher, ob das so schon "leicht verstaendlich" ist.
    IMHO ist dein Fazit noch etwas verwirrend und deinen "5)" in der praktischen Umsetzung kann nicht mal ich so nachvollziehen.


  • Mod

    lineare und physikalische Adresse ist AFAIK nicht das Gleiche.

    Ja, da hast Du ab dem 386er völlig Recht. Man findet in der Literatur ständig einen Mischmasch aus 286er 16-Bit-Protected-Mode und 386er 32-Bit-Protected-Mode. Beim 286er ist die "lineare" Adresse identisch mit der physikalischen Adresse, beim 386er muss letztere aus der ersten wegen des Pagings berechnet werden. Auch die Deskriptoren sind beim Sprung vom 286er zum 386er von sechs auf acht Byte gewachsen. Erst durch direkten Vergleich beider Systeme versteht man, warum das heute so chaotisch angeordnet ist.

    Nobuo, vielen Dank für Deinen Quellcode! Ich werde eine Seite mit Download-Links einbauen. Dort wird es dann auch einen Bereich "Erlkönig" geben, wo wir alphas und betas ablegen können.


  • Mod

    IMHO koenntest du noch etwas ausfuehrlicher darauf eingehen, warum fuer Multitasking nun auf einmal Schutzmechanismen noetig sind, und warum fuer DOS nicht, bzw. was unter Multitasking grob zu verstehen ist.

    Akzeptiert.

    Das "Fazit" werde ich ebenfalls überdenken.


  • Mod

    Feedback bezüglich Code von Nobuo T:

    Test 1: Auf Floppy schreiben und "echt" booten.
    Resultat: Perfekt! 👍

    Erstes Code-Studium:
    Kernel auf 0x08000 gesetzt wie diskutiert,
    buffer weg,
    A20 eingeschaltet (die berühmte 21. Adressleitung),
    ansprechende Ausgabe der Meldung im PM

    @Nobuo T: Danke für die fundierte Unterstützung! 🙂

    @all: bitte den Code checken, gute Ideen werden sofort angenommen. Vielleicht kann man auch im Real Mode noch etwas Interessantes ergänzen, z.B. den CPUID-Befehl?!

    Waere praktisch, wenn du die Quellcodes in deinem Tutorial auch direkt als Downloads haettest (habe sie zumindest nicht gefunden).

    http://www.henkessoft.de/OS_Dev/Downloads/20090321_eh_os.zip

    Ich werde diesen m.E. gelungenen Einstieg in den PM nun didaktisch aufarbeiten, damit das Tutorial Einsteigern das Leben so leicht wie möglich macht. Da fehlen noch einige gute Abbildungen. Die Unterscheidung zwischen 16-Bit- und 32-Bit-Protected Mode ist didaktisch wichtig. Paging, Unterschied lineare/phys. Adresse ebenso.



  • Erhard Henkes schrieb:

    Vielleicht kann man auch im Real Mode noch etwas Interessantes ergänzen

    Vielleicht folgendes:

    Wenn man im PM ein Segmentregister initialisiert und dann wieder in den RM wechselt, bleibt die Segmentgröße des Selektors für das initialisierte Segmentregister erhalten. Dadurch hat man über dieses Segmentregister Zugriff auf die gesamte Segmentgröße auch im RM.

    Was heißt, die Begrenzung auf 1MB RAM im RM kann relativ einfach außer Kraft gesetzt werden. Das Segmentregister darf nur nicht im RM wieder verändert werden. Sonst ist der Spaß vorbei. Aber man ja beliebig oft hin und her wechseln. 🙂


  • Mod

    @+gjm+:
    Das klingt ja echt abenteuerlich! 😃
    Findet man dazu bereits einen Link im Internet oder ist das Geheimwissen?
    Wie läuft denn da die genaue Adressierung im zurück geschalteten RM ab?

    @abc.w: Hast Du den neuen Code bereits ausprobiert?
    http://www.henkessoft.de/OS_Dev/Downloads/20090321_eh_os.zip

    @Nobuo T: Deine konstruktiven Vorschläge wurden aufgenommen und hoffentlich weitgehend umgesetzt. Multitasking und A20 Gate wird jetzt auch breiter besprochen. Das ist schon ganz schön viel Text, hoffentlich brauchbare Abbildungen und ziemlich viele Zeilen Assembler, nur um die Basis PM zu erreichen. Didaktisch ist es wirklich nicht ganz einfach die x86 Historie verständlich zu erklären, ohne allzu langatmig zu werden. 😉


  • Mod

    Eine Frage zum Bootloader-Code:
    http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId80121

    Wir schreiben den Offset der Sprung-Adresse des Kernels nachs BX.
    Später springen wir ohne Verwendung dieses Registers.

    mov bx, 0x8000     ; set up start address of kernel
    ;...
    jmp 0x0000:0x8000   ; address of kernel
    

    ES:BX ist notwendig für int 0x13 als "Buffer Address Pointer".
    So läuft es auf jeden Fall auch:

    mov bx, 0x8000     ; set up start address of kernel
    ;...
    jmp bx   ; address of kernel
    

    Wäre letzteres o.k.? Ist das didaktisch nicht besser? Man verwendet BX auch im Sprungbefehl sofort sofort.

    Das erscheint ja auch etwas merkwürdig:

    mov [bootdrive], dl ; boot drive from DL
    ...
    mov dl,[bootdrive] ; select boot drive
    

    Man könnte den Kernel wohl auch von anderer Stelle laden?
    Da unser System dies nicht macht, könnte man [bootdrive] doch auch völlig weg lassen?

    Label load_kernel1 kann jetzt ja auch entfallen nach Nobuos Änderung?


Anmelden zum Antworten