Ziel: USB-Treiber


  • Mod

    Ein wichtiges Ziel ist der Entwurf eines USB-Treibers. Hier eine kurze Übersicht zu diesem Thema:

    The USB host controllers have their own specifications. With USB 1.1, there were two Host Controller Interface Specifications, UHCI (Universal Host Controller Interface) developed by Intel which puts more of the burden on software (Microsoft) and allowing for cheaper hardware and the OHCI (Open Host Controller Interface) developed by Compaq, Microsoft and National Semiconductor which places more of the burden on hardware(Intel) and makes for simpler software. Typical hardware / software engineer relationship ...

    With the introduction of USB 2.0 a new Host Controller Interface Specification was needed to describe the register level details specific to USB 2.0. The EHCI (Enhanced Host Controller Interface) was born. Significant Contributors include Intel, Compaq, NEC, Lucent and Microsoft so it would hopefully seem they have pooled together to provide us one interface standard and thus only one new driver to implement in our operating systems. Its about time.

    USB as its name would suggest is a serial bus. It uses 4 shielded wires of which two are power (+5v & GND). The remaining two are twisted pair differential data signals. It uses a NRZI (Non Return to Zero Invert) encoding scheme to send data with a sync field to synchronise the host and receiver clocks.

    USB supports plug’n’plug with dynamically loadable and unloadable drivers. The user simply plugs the device into the bus. The host will detect this addition, interrogate the newly inserted device and load the appropriate driver all in the time it takes the hourglass to blink on your screen provided a driver is installed for your device. The end user needs not worry about terminations, terms such as IRQs and port addresses, or rebooting the computer. Once the user is finished, they can simply lug the cable out, the host will detect its absence and automatically unload the driver.

    The loading of the appropriate driver is done using a PID/VID (Product ID/Vendor ID) combination.

    Quelle: "USB in a NutShell"
    Link: http://www.beyondlogic.org/usbnutshell/usb1.htm

    Ausführliche Beschreibung:
    http://wiki.osdev.org/USB


  • Mod

    http://code.google.com/p/tatos/

    tatOS is a hobby operating system for assembly language programmers.
    The main feature of tatOS is a protected mode driver allowing direct logical block read/write of USB mass storage pendrive/flashdrive/memorystick.

    siehe im package usbinit.s, ...


  • Mod

    Voraussetzung für die USB-Treiber ist die Information über vorhandene Devices am PCI-Bus und die entsprechenden Basis-Adressen. Informationen zum PCI-Scan findet man in diesem Thread: http://www.c-plusplus.net/forum/viewtopic-var-t-is-252512-and-start-is-70.html


  • Mod

    Auszug aus einem IRC (2009, Nov 08) mit _fricky:
    Erste genauere Schnittstellendefinition seinerseits:

    R/W auf memory-mapped register, 8,16 und 32 bits, aufruf etwa: uint8_t read(uint32_t reg); bzw. void write (uint32_t reg, uint8_t val); <--- beispiel für 8-bit R/W

    ... im prinzip so (ganz grob): du rufst eine funktion meines treibers auf: usb20-init (uint32_t baseaddress) und stellst mir r/w-funktionen zur verfügung, offsets addiere ich selbst
    ...
    das interrupt-handlig kommt dann in einer späteren funktion
    ...
    besser noch: wir können eine usb2.0-struct definieren, die sich erweitern lässt
    in dieser struct wären dann: basis-adresse, function-pointer für R/W, function pointer für die ISR usw.

    ... lass uns ganz einfach beginnen

    refactoring machen wir später, ein generisches treiber-interface und sowas

    ab Rev. 15 (SVN):
    Test in ckernel.c, um einige Inhalte auszulesen und zu sehen, welche Möglichkeiten die read-Funktionen haben müssen:

    /// TEST EHCI Data Begin
    if(  (pciDev_Array[number].interfaceID==0x20)   // EHCI
       && pciDev_Array[number].bar[i].baseAddress ) // valid BAR
    {
    /*
    Offset Size Mnemonic    Power Well   Register Name
    00h     1   CAPLENGTH      Core      Capability Register Length
    01h     1   Reserved       Core      N/A
    02h     2   HCIVERSION     Core      Interface Version Number
    04h     4   HCSPARAMS      Core      Structural Parameters
    08h     4   HCCPARAMS      Core      Capability Parameters
    0Ch     8   HCSP-PORTROUTE Core      Companion Port Route Description
    */
    
    EHCI_data = *((volatile uint8_t* )((pciDev_Array[number].bar[i].baseAddress & 0xFFFFFFF0) + 0x00 ));
    printformat("\nBAR%d CAPLENGTH:  %x \t\t",i, EHCI_data);
    
    EHCI_data = *((volatile uint16_t*)((pciDev_Array[number].bar[i].baseAddress & 0xFFFFFFF0) + 0x02 ));
    printformat(  "BAR%d HCIVERSION: %x \n",i, EHCI_data);
    
    EHCI_data = *((volatile uint32_t*)((pciDev_Array[number].bar[i].baseAddress & 0xFFFFFFF0) + 0x04 ));
    printformat(  "BAR%d HCSPARAMS:  %X \t",i, EHCI_data);
    
    EHCI_data = *((volatile uint32_t*)((pciDev_Array[number].bar[i].baseAddress & 0xFFFFFFF0) + 0x08 ));
    printformat(  "BAR%d HCCPARAMS:  %X \n",i, EHCI_data);
    }
    /// TEST EHCI Data End
    

    Die 64-Bit-Info HCSP-PORTROUTE werden wir wohl in zwei Schritten á 32 Bit auslesen in ein High-DWORD und Low-DWORD, wenn überhaupt notwendig.



  • Ich schreibs mal hierzu, weil ich die Frage wegen USB in Emulatoren grad im IRC erst gesehen habe, als du schon weg warst. VirtualBox und Vmware (weiß nicht ob es von der Version abhängt) können EHCI. QEmu und Bochs scheinbar nicht. Bei VirtualBox ist die USB Unterstützung auch nur in der closed source Variante vorhanden. Sieht so aus als stecken da noch ein paar Geheimnisse drin 🙂


  • Mod

    Danke für die Info! MS Virtual PC konnte es überhaupt nicht, und meine Qemu-Version nur UHCI.

    Sun xVM VirtualBox kann USB EHCI darstellen, fdir (Floppy Dir) funktioniert sowie bei Qemu übrigens ebenfalls problemlos.

    siehe Bild: http://www.henkessoft.de/OS_Dev/Bilder/VirtualBox_PCIScan_USB_EHCI.PNG


  • Mod

    _fricky am 16.11. im IRC bezüglich Strategie hinsichtlich USB2.0-Treiber

    <_fricky> ich bin user eines usb-chips, mit dem ich ziemlich unzufrieden bin
    <_fricky> der soll irgendwann durch 'ne software lösung ersetzt werden
    <_fricky> zu dem zweck bastel ich mir erstmal einen usb2.0 treiber
    <_fricky> dieser treiber setzt auf das EHCI interface auf
    <_fricky> prettyOS muss mir funktionen bereitstellen, mit denen ich auf die register zugreifen kann
    <_fricky> der code wird 0815-ansi-C sein, bei der anpassung werde ich euch unterstützen
    <_fricky> ich brauche noch die basisadresse der EHCI register


  • Mod

    _fricky u.a. am 22.11 im IRC zum Thema USB-Treiber(Auszüge):

    <_fricky> ein usb-treiber muss mit der usb-hardware kommunizieren und dem OS transfer-funktionen bereitstellen
    <ehenkes> was versteht man da unter frames genau?
    <NN> Wenn ein USB-Treiber nur Frames annimmt und die versendet, ist das nicht mal ein vollständiger HCD. Er sollte schon ganze Pakete annehmen und die entsprechend abstrahierten USB-Geräten zuschicken können
    <_fricky> ^^nee, aber das ist der unterste level
    <NN> Aber diese Transferfunktion wird das OS hoffentlich wenig interessieren 😉 Deshalb sollte man sie besser nicht bereitstellen
    <_fricky> XanClic: an welchem USB bastelst du gerade?
    <NN> 1.x
    <_fricky> ^^das OS hostet ja auch die treiber der höheren ebene
    <NN> "[...] und dem OS transfer-funktionen bereitstellen [...] z.b. um frames über usb zu schicken und zu empfangen"
    <_fricky> übrigens: ein treiber-modell fehlt pretty OS wahrscheinlich noch, ne?
    <_fricky> Xanclic: ist wichtig, z.b. um sowas wie den CP2102 anzusprechen
    <NN> Also, wenn das OS ganze Frames selbst verschicken muss, ist der Treiber kaputt
    <_fricky> ^^der will z.b. erstmal konfiguriert werden, ist ein USB<--->RS232 konverter
    <NN> Na, da schickt ein entsprechender Treiber halt die entsprechenden Pakete rüber?
    <_fricky> ja, aber jeder treiber der hierachie ist bestandteil des OS
    <NN> Aber jeder Treiber soll komplett abstrahieren und nicht nur einen Teil
    <NN> Also einige Geräte und andere nicht
    <NN> Im besten Falle reicht das OS einfach die Daten zwischen den Treiberebenen weiter ohne sich darum zu kümmern, was das ist
    <NN> Und am Ende erscheint da z. B. ein Speichergerät, von dem das System nicht wissen muss, ob es eine IDE- oder eine USB-Festplatte ist
    <_fricky> klar, aber es muss auch eine möglichkeit geben, usb-devices anzusprechen, die das OS nicht kennt. gewisser massen eine user-mode usb schnittstelle
    <NN> Du sagtest, jeder Treiber gehört zum OS. Wenn das OS ein Gerät nicht kennt, heißt das, es hat keinen Treiber dafür und dann kann man halt nix machen
    <_fricky> naja, man kann sich auch einen usermode treiber coden. das sollte möglich sein
    <NN> Bei richtigen Monolithen nicht.
    <_fricky> windoof z.b. fehlt eine low-level USB API, unnötige einschränkung
    <NN> Widersprichst du dir nicht grad selbst? Würde man einen Treiber schreiben, würde er ja wieder zum OS gehören
    <ehenkes> Warum soll ein Treiber nicht zum OS gehören? ... Bei einem Monolithen gehört er dazu, sogar im Kernel


  • Mod

    @ _fricky: wie ist der Stand?
    Er hat uns für 2009 einen USB-Treiber versprochen.
    Er hat uns diesbezüglich gnadenlos versetzt, also sein Wort gebrochen.

    Mein Fazit: Auf solche "Trolle" kann man hier gut verzichten.


  • Mod

    Der USB2-Standard ist mittlerweile 10 Jahre alt. Geräte und Mainboards mit dem Nachfolger-Standard USB3 sind seit Anfang des Jahres erhältlich. Die Kompatibilität bleibt gewahrt. Man kann sowohl USB3 Geräte an USB2 Buchsen betreiben, wie auch umgekehrt. In den Genuss der 10-fachen Geschwindigkeit von USB3 kommt man so allerdings nicht.

    Theoretische Übertragungsrate:
    USB2: 480 MBit/s
    USB3: 5000 MBit/s


  • Mod

    Nachdem die Floppy Disk zuverlässig und halbwegs brauchbar als Speichermedium zum Laden von Dateien verwendet werden kann, kann ich mich - hoffentlich unterstützt durch andere OS-Developer - u.a. dem Thema USB-Treiber zuwenden.

    Als Simulationsumgebung kann man z.B. Sun VirtualBox einsetzen, hier ein Beispiel der Erkennung und des Auslesens von USB-Devices mittels PCI-Scan (Rev. 0.0.0.107):
    http://www.henkessoft.de/OS_Dev/Bilder/Rev107_SunVB_USB.PNG


  • Mod



  • Hallo,

    Erhard Henkes schrieb:

    Nachdem die Floppy Disk zuverlässig und halbwegs brauchbar als Speichermedium zum Laden von Dateien verwendet werden kann,

    das ist doch was feines, wer diesen verkorksten DMA-Mist hin bekommt kann doch unmöglich an USB scheitern 😃 😉

    Erhard Henkes schrieb:

    - hoffentlich unterstützt durch andere OS-Developer -

    Ich hoffe ich verspreche Dir jetzt nichts was ich später dann nicht halten kann, aber an USB würde ich mich schon gerne beteiligen (dann hab ich es später leichter wenn ich mit meinem Projekt an dieser Stelle bin). Ich werde mir mal die 3 Host-Controller-Specs genau reinziehen.

    Seit ihr den der Meinung das PrettyOS reif genug für einen richtigen Treiber-Stack ist?

    Grüße
    Erik



  • erik.vikinger schrieb:

    Hallo,

    Erhard Henkes schrieb:

    Nachdem die Floppy Disk zuverlässig und halbwegs brauchbar als Speichermedium zum Laden von Dateien verwendet werden kann,

    das ist doch was feines, wer diesen verkorksten DMA-Mist hin bekommt kann doch unmöglich an USB scheitern 😃 😉

    🙄

    *facepalm*



  • erik.vikinger schrieb:

    Erhard Henkes schrieb:

    Nachdem die Floppy Disk zuverlässig und halbwegs brauchbar als Speichermedium zum Laden von Dateien verwendet werden kann,

    das ist doch was feines, wer diesen verkorksten DMA-Mist hin bekommt kann doch unmöglich an USB scheitern

    USB ist hinreichend komplex um einen Entwickler einige Monate zu beschäftigen. Ihr solltet euch ausserdem beeilen, der nächste USB-Standard ist bereits im Anflug. 😃



  • Hallo,

    Z schrieb:

    USB ist hinreichend komplex um einen Entwickler einige Monate zu beschäftigen.

    Ich glaube das hat sich in zwischen unter allen Beteiligten herumgesprochen.

    Z schrieb:

    Ihr solltet euch ausserdem beeilen, der nächste USB-Standard ist bereits im Anflug. 😃

    USB 3 kann man IMHO auch einzeln implementieren, ist ein neues Parallel-Universum, im Gegensatz zum Verhältnis von USB 1 und USB 2. Nur das USB-Basis-Gerüst muss zwischen den einzelnen Standards unterscheiden.
    Für ein Hobby-OS könnte man sich vielleicht auch erst mal nur auf USB 2 und EHCI beschränken.

    Grüße
    Erik



  • Z schrieb:

    Ihr solltet euch ausserdem beeilen, der nächste USB-Standard ist bereits im Anflug. 😃

    In Linux schon implementiert. 😉

    erik.vikinger schrieb:

    Für ein Hobby-OS könnte man sich vielleicht auch erst mal nur auf USB 2 und EHCI beschränken.

    Man kann sich bei einem Hobby-OS vielleicht erstmal auch auf USB 1.x beschränken, imo.


  • Mod

    Das Primärziel besteht darin, permanenten Speicher via USB anzusprechen, um Daten dort ablegen und von dort laden zu können.



  • Hallo,

    XanClic schrieb:

    erik.vikinger schrieb:

    Für ein Hobby-OS könnte man sich vielleicht auch erst mal nur auf USB 2 und EHCI beschränken.

    Man kann sich bei einem Hobby-OS vielleicht erstmal auch auf USB 1.x beschränken, imo.

    Bei USB 1 brauchst Du aber 2 verschiedene Host-Controller die der CPU auch nur wenig Arbeit abnehmen, und wenn ich das richtig verstanden hab spart sich Intel in den neuesten Chipsätzen auch die USB 1 Host-Controller ganz (damit stünde PrettyOS wieder im Regen). Wenn man ein Low-/Full-Speed-Device über einen HUB anschließt werden die USB 1 Host-Controller sowieso nicht mehr benötigt, dann läuft alles über diese Split-Transactions, ich vermute Intel hat in den Root-Hub so ein Umsetz-(TT)-Mechanismus eingebaut. Für USB 2 braucht man nur einen Host-Controller, der auch mehr Arbeiten selber erledigt, und zusätzlich die 40-fache Geschwindigkeit anbietet. Für nur Mass-Storage ist das IMHO der bessere Einstieg, später kann man dann in den Hub-Treiber noch Unterstützung für die TTs implementieren und hat USB 1 gleich noch mit erledigt.

    Ich werde mir so bald als möglich mal die 3 Host-Controller-Specs reinziehen und kann dann hoffentlich etwas genaueres sagen.

    Grüße
    Erik



  • erik.vikinger schrieb:

    Bei USB 1 brauchst Du aber 2 verschiedene Host-Controller

    Bei USB 2.0 brauch ich drei.

    erik.vikinger schrieb:

    und wenn ich das richtig verstanden hab spart sich Intel in den neuesten Chipsätzen auch die USB 1 Host-Controller ganz (damit stünde PrettyOS wieder im Regen). Wenn man ein Low-/Full-Speed-Device über einen HUB anschließt werden die USB 1 Host-Controller sowieso nicht mehr benötigt, dann läuft alles über diese Split-Transactions, ich vermute Intel hat in den Root-Hub so ein Umsetz-(TT)-Mechanismus eingebaut.

    Das wird vermutlich praktisch funktionieren, aber ist nicht USB-2.0-konform. Da müsste Intel erstmal USB 2.1 oder so rausbringen, in der definiert ist, dass es keine Companion Controller gibt.


Anmelden zum Antworten