Im Protected Mode, doch wie kommt man jetzt weiter?



  • Ich habe ein kleines nettes OS geschrieben auf einen USB-Stick geschrieben, welches vom Stick aus booten kann. Im Protected Mode beherrscht es Tastatureingaben und Bildschirmausgaben im Textmodus, ebenso existiert eine Arbeitsspeicherverwaltung und sogar eine Prozeßverwaltung. Alles was nicht mit angeschlossener Hardware außer Timer, Interruptcontroller, Tastatur und Bildschirm zu tun hatte, konnte ich schnell erledigen.
    Doch das nützt alles nichts, wenn man Daten nicht auf Massenspeicher auslagern kann. Was also die Hardwareprogrammierung betrifft, fühle ich mich sehr ausgebremst, da es sehr schwierig ist, hierzu an Informationen zu gelangen! Das Analysieren von Fremdcode widerstrebt mir sehr, da es oft sehr schwierig ist, den Sinn nachzuvollziehen. Da braucht man ein Leben lang, bis man ans Ziel kommt.

    Ich möchte also auf den USB-Datenspeicherstick, wo sich mein OS befindet, auch im Protected Mode weiterhin zugreifen können. Ebenso möchte ich feststellen können, ob andere USB-Speichersticks angeschlossen sind, als auch Festplatten an IDE oder ATA. Auch hier möchte ich auf die Massenspeicher zugreifen können.
    Ebenso möchte ich im Protected Mode und nicht anders in den Grafikmodus wechseln bzw. wieder zurück in den Textmodus. Zumindest VGA bzw. SVGA und nicht vor dem Umschalten in den Protected Modus.



  • Grad USB geht denke ich zu weit... Das ist z.B. in PrettyOs hier ganz gut ausgearbeitet. Aber das ist sehr viel Aufwand, das zu verstehen und richtig umzusetzen. Da braucht man schon sehr viel Motivation, um sich das anzutun.
    Kann ich verstehen, wenn man das will. Aber wenn man "schnell" mal ein eigenes Betriebssystem zum Spass basteln will, führt das viel zu weit.



  • w_ciossek schrieb:

    Was also die Hardwareprogrammierung betrifft, fühle ich mich sehr ausgebremst, da es sehr schwierig ist, hierzu an Informationen zu gelangen!

    Die meisten Hardwarespezifikationen sind frei online verfügbar.

    USB: http://www.usb.org/developers/docs/usb20_docs/
    SATA AHCI: https://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1-3-1.html
    (S)VGA: http://www.osdever.net/FreeVGA/home.htm

    Das OSDev Wiki hat zu USB und SATA auch recht ausführliche Artikel, wobei man um die Spec meistens trotzdem nicht herum kommt.

    https://wiki.osdev.org/Universal_Serial_Bus
    https://wiki.osdev.org/AHCI



  • Ich habe auch etwas über USB gefunden. Ich arbeite mich hier gerade in die Grundlagen ein, daß es immer noch besser ist, als fremden Code zu analysieren und zu verstehen. Für mich ist es wichtig Zugang zu diesen Grundlagen zu haben, da ich mangels deutscher Literatur auch Beiträge in deutscher Sprache liefern möchte.

    Ich bin also sehr dankbar, wenn ich Literaturverweise zu diesen Thema erhalte!



  • Mechanics: Genau das möchte ich ja. Es genau verstehen und richtig umsetzen! Da ist mir keine Spezifikation zu umfangreich! Zwar ist es in PrettyOS umgesetzt worden, jedoch verstehe ich es nicht, wenn ich diesen Code mühselig analysiere. Es ist wesentlich aufwendiger, als wenn man eine gute Referenz bzw. Spezifikation über ein Hardware-Teil hat, welches man programmieren kann. Zumal meine Ansätze der OS-Programmierung sich sehr stark von PrettyOS unterscheiden. Da ist es schon wichtig, Grundlagen oder Datenmaterial zur Hardwareprogrammierung zu erhalten. Immerhin muß man ja aus der Arbeitsspeicherumgebung mal herauskommen können.
    Ich habe allerdings mit der Hardwareprogrammierung schon sehr viele Erfahrungen gesammelt, Anfang der siebziger und den frühen achtziger Jahren. Nur bin ich jetzt nicht mehr auf den neuesten Stand. Damals war es ein Leichtes, Informationsmaterial und Datenblätter über Hardware zu bekommen und Hardwareprogrammierung war in jener Zeit eine alltägliche Sache eines jeden Programmierers, als Betriebssysteme noch in den Kinderschuhen waren und Treiber noch nicht existierten. Man schrieb sie selber. Heute scheint man für jedes neue Hardwareteil sich in ein Schweigen zu hüllen. Sucht man in Internet nach Spezifikationen, dann kommen nervende und unbrauchbare Meldungen, wie man mit Windows oder Linux über Treiberfunktionen auf diese Hardware zugreifen kann! Für OS-Entwickler völlig unbrauchbar!

    Was das USB-System betrifft, so wird oftmals in einigen Literaturhinweisen ein Bussystem beschrieben, wie man es benutzen kann. Zur Zeit habe ich noch nicht vollständig dieses Bussystem und alle Materialien hierzu durchgearbeitet. Jedoch fand ich nichts, wie man ein spezielles Gerät erkennen kann. Z.B. eine Tastatur, eine Maus, eine Kamera, ein USB-Speicherstick, oder andere Geräte und wie man mit jenen USB-Geräten kommuniziert. Das scheinen gesonderte Themen zu sein, worüber man kaum etwas findet. Bei meiner Rechnerausstattung hängt die Tastatur an einen USB-Anschluß. Es entsteht auf seltsame Weise ein Tastaturinterrupt und über Ports 60h, 61h, und 64h kann man die Tastatur ansprechen, wie jede Tastatur auch, die nicht an einen USB-Anschluß hängt! Auch hier fehlt mir eine Erklärung, wie so etwas möglich ist, da ich bei meinen OS keinen USB-Treiber für Tastaturen programmiert habe. Da muß also offenbar das BIOS die USB-Anschlüsse durch gecheckt haben, um eine Tastatur zu finden und um eine Verbindung zum Tastaturinterrupt als auch zu den entsprechenden Ports herzustellen, bevor mein Betriebssystem geladen wird.



  • w_ciossek schrieb:

    Zur Zeit habe ich noch nicht vollständig dieses Bussystem und alle Materialien hierzu durchgearbeitet. Jedoch fand ich nichts, wie man ein spezielles Gerät erkennen kann. Z.B. eine Tastatur, eine Maus, eine Kamera, ein USB-Speicherstick, oder andere Geräte und wie man mit jenen USB-Geräten kommuniziert. Das scheinen gesonderte Themen zu sein, worüber man kaum etwas findet.

    Oh Sorry, ich hab dir tatsächlich das Falsche verlinkt. Ich dachte die Controller Spezifikationen waren mit in dem USB Spec Paket.

    Du brauchst nämlich nicht die USB Spec sondern die Spec des USB Controllers:

    eHCI (USB 2.0): https://www.intel.com/content/www/us/en/io/universal-serial-bus/ehci-specification-for-usb.html
    xHCI (USB 3.0): https://www.intel.com/content/www/us/en/io/universal-serial-bus/extensible-host-controler-interface-usb-xhci.html

    Die Specs für die Geräteklassen auf usb.org sind aber unabhängig davon ob du auf Seite des Controllers oder der Devices stehst:

    http://www.usb.org/developers/docs/devclass_docs/

    Geräte erkennen ist aber schon 3 Schritte zu weit. Du musst zunächst den Controller, Root-Hub und die ganzen Ports einschalten. Sonst haben die angeschlossenen Geräte unter Umständen nicht mal Strom. Hand-Off mit dem BIOS (siehe unten) musst du auch noch beachten.

    w_ciossek schrieb:

    Bei meiner Rechnerausstattung hängt die Tastatur an einen USB-Anschluß. Es entsteht auf seltsame Weise ein Tastaturinterrupt und über Ports 60h, 61h, und 64h kann man die Tastatur ansprechen, wie jede Tastatur auch, die nicht an einen USB-Anschluß hängt! Auch hier fehlt mir eine Erklärung, wie so etwas möglich ist, da ich bei meinen OS keinen USB-Treiber für Tastaturen programmiert habe. Da muß also offenbar das BIOS die USB-Anschlüsse durch gecheckt haben, um eine Tastatur zu finden und um eine Verbindung zum Tastaturinterrupt als auch zu den entsprechenden Ports herzustellen, bevor mein Betriebssystem geladen wird.

    Das BIOS beinhaltet einen USB Treiber, da es sonst nicht möglich wäre von USB Geräten zu booten oder per USB-Tastatur Einstellungen vorzunehmen. Das heißt aber auch, dass das BIOS erst einmal die Kontrolle über den USB Controller besitzt. Es gibt ein Hand-Off Kommando (ehci spec 5.1) mit dem man dem BIOS die Kontrolle entzieht.



  • w_ciossek schrieb:

    Für mich ist es wichtig Zugang zu diesen Grundlagen zu haben, da ich mangels deutscher Literatur auch Beiträge in deutscher Sprache liefern möchte.

    Als deutsche Anlaufstelle kann ich dir http://www.lowlevel.eu/wiki/Universal_Serial_Bus empfehlen. Ist allerdings nur bei ohci/uhci (USB 1.0) gefüllt. Das Bulk Transfer Konzept bei ohci sieht aber sehr ähnlich dem bei ehci aus.



  • Aber wenn man "schnell" mal ein eigenes Betriebssystem zum Spass basteln will, führt das viel zu weit.

    Ohne Tiefgang kommt man bei USB nicht weit. Das erfordert eine längere Beschäftigung mit den Spezifikationen und viel Geduld. In PrettyOS steckt einiges an Erfahrung aus zähen Kämpfen mit der Materie. Es lohnt sich es zu verstehen.

    Übrigens kann man hier fragen. Die Entwickler leben noch. 😉



  • Doch das nützt alles nichts, wenn man Daten nicht auf Massenspeicher auslagern kann. Was also die Hardwareprogrammierung betrifft, fühle ich mich sehr ausgebremst, da es sehr schwierig ist, hierzu an Informationen zu gelangen!

    Ich gehe mal davon aus, dass du Daten als Files auf einem usb-Stick ablegen willst. Dazu benötigst du verschiedene Dinge, zumindest die Kommunikation via usb, dann einen konkreten Hardware-Treiber, z.B. ehci oder xhci, zusätzlich noch ein Filemanagementsystem, wie z.B. FAT. Die Spezifikationen sind im Netz allesamt frei zugänglich.

    Diese beiden Seiten sind nicht schlecht für einen ersten Einstieg.
    https://wiki.osdev.org/Main_Page
    http://www.lowlevel.eu/wiki/Lowlevel:Portal

    Die konkreten Spezifikationen solltest du dir als Primärliteratur ebenfalls besorgen, vor allem für x/ehci und FAT.
    https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf
    https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf
    https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system
    etc.

    Wichtig ist auch der Umgang mit usb mass data storage. Dort kommt SCSI beim Bulk Transfer zum Einsatz.
    http://www.usb.org/developers/docs/devclass_docs/usbmassbulk_10.pdf

    Für usb empfehle ich die usb Nutshell Serie (ab chapter 3 geht's zur Sache):
    https://beyondlogic.org/usbnutshell/usb1.shtml

    Hier habe ich wichtige Zusammenhänge zwischen port/disk/partition/usb-Hostcontroller dargestellt: https://www.henkessoft.de/OS_Dev/Bilder/transfer_port_disk_usb.JPG

    Das sollte helfen.