4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    Version 0.0.4.70 - Revision 1458

    usb3 Ports am xHC resettet/enabled und Status dargestellt.
    Funktioniert momentan nur bei bereits eingesteckten Devices.
    In VMware lässt sich dies hervorragend emulieren.

    0
  • E
    Mod

    Version 0.0.4.71 - Revision 1459

    xhxi.c: events (Versuche bisher nicht erfolgreich, MSI-X?)

    0
  • E
    Mod

    Version 0.0.4.72 - Revision 1460

    xhci.h: Fehler in den Lo-Adressen korrigiert

    0
  • E
    Mod

    Version 0.0.4.73 - Revision 1461

    xhci.c: verbessert zum Testen auf Port Status Change (CSC Bit, Connected Status)

    Testergebnisse von Tobiking:
    connected status, connected status change sowie enabled reagieren auf connect/disconnect einer usb3-HDD via VMware.
    Allerdings erscheint noch kein port status change event im event ring.

    0
  • E
    Mod

    Version 0.0.4.74 - Revision 1462

    xhci.c: Fehler korrigiert bei Eventring Table.
    (leider noch Addressfehler enthalten)

    EDIT: Kann nun selbst Hardwaretests durchführen dank usb3-PCIe-Karte im Testrechner.

    0
  • E
    Mod

    Version 0.0.4.75 - Revision 1463

    xhci.c: Adress-Fehler behoben.
    Hardware-Test: Nun werden Events angezeigt mit type 0x22 (TRB_EVENT_PORT_STS_CHANGE) 👍
    Zwei usb3-Sticks werden als connected erkannt und erhalten pro Stick zwei Events vom type 0x22.

    0
  • E
    Mod

    Version 0.0.4.76 - Revision 1464

    xhci.c: Ausgaben verfeinert, und CSC Bit wird nach Anzeige gelöscht. Jeder Übergang 0->1 ergibt ein Event. Ziehen/Stecken ergibt weitere Events.

    0
  • E
    Mod

    Version 0.0.4.77 - Revision 1465

    xhci.c: No Op Command bewirkt viele TRB_EVENT_CMD_COMPLETE und einen TRB_EVENT_HOST_CTRL. Damit ist der Command Ring ebenfalls funktionsfähig. 👍

    0
  • E
    Mod

    Version 0.0.4.78 - Revision 1466

    xhci.h/c: Completion Code (TRB error) ergänzt und ausgegeben. Event TRB Struktur verallgemeinert.

    0
  • E
    Mod

    Version 0.0.4.79 - Revision 1467

    xhci.c: Fehler bei Adressierung und Aufsetzen von TRBs im Command Ring behoben.

    OpReg crcr ist nicht lesbar, gibt immer 0 zurück. Daher ist dieses Register für die xHCI-Treiber Software unbrauchbar!

    Nun wird der enq-Ptr des Command Rings verwendet. Cycle Bit muss am Anfang auf 0, nicht 1! Nun klappt das beim Test-Command "No Op" sauber. Wir erhalten jeweils "Success". 👍

    Leider spielt Bochs und VMware noch nicht mit. In VMware kann man crcr z.B. zahlenmäßig auslesen, was eindeutig falsch ist (siehe spec)! Für die Entwicklung ist also lediglich reale Hardware brauchbar.

    Screenshot: http://henkessoft.de/Sonstiges/PrettyOS_xHCI.JPG

    Nächster Schritt: Cycle Bit der TRB im Command Ring gemäß Producer Cycle State (Startwert?) einstellen. Den Consumer Cycle State können wir nach Bit0 von OpReg crcr schreiben (momentan 0, Vorsicht: alles im crcr wird beim Lesen als 0 zurück gegeben! Daher werden z.Z. alle TRB mit c=0 (alle) gelesen.

    The Enqueue Pointer is managed by the producer and the Dequeue Pointer is managed by the consumer. The producer maintains a Producer Cycle State (PCS) flag which identifies the value that it shall write to the TRB Cycle bit. The consumer maintains a Consumer Cycle State (CCS) flag, which it compares to the Cycle bit in TRBs that it fetches. If the CCS flag is equal to the value of the TRB Cycle bit, then the consumer owns the TRB pointed to by the Dequeue Pointer and may process it. If they are not equal, then the consumer shall stop processing TRBs and wait for a notification of more work.

    Idee: Im nächsten Versuch wird daher in das hinter die drei No Op folgende TRB eine 1 (~PCS) - siehe Figur 14, xHCI spec - geschrieben, um den HC zu stoppen.

    Wahrscheinlich macht es mehr Sinn, PCS und CCS zu Beginn auf 1 (CCS: bit0 in crcr), zu setzen (siehe Figur 16 für den gesamten Ablauf incl. Link-TRB, xHCI spec). <== So wurde es nun umgesetzt in der nächsten Version!

    0
  • E
    Mod

    Version 0.0.4.80 - Revision 1468

    xhci.h/c: CmdRingProducerCycleState hinzugefügt und genutzt, damit der xHC am enqueue-Ptr stehen bleibt. Klappt hervorragend.

    Bochs kennt leider den No Op Command nicht ("Unknown trb type found: 23(dec)"). ^^

    0
  • E
    Mod

    Version 0.0.4.81 - Revision 1469

    xhci.h: ergänzt um weitere Strukturen
    xhci.c: device context array begonnen und TRB_TYPE_ENABLE_SLOT gesendet (darauf reagiert Bochs normal).

    0
  • E
    Mod

    Version 0.0.4.82 - Revision 1470

    xhci.h/c: ptr vereinfacht, allgem. Funktionen beim cmd-ring geschaffen

    0
  • E
    Mod

    version = "0.0.4.83 - Rev: 1471"

    xhci.h/c: weitere kleine Verbesserungen

    Leider kann der Interrupt noch nicht eingeschaltet werden (Uhrzeit bleibt bei Hardware stehen), daher lassen wir die Interrupter noch ausgeschaltet:

    x->RuntimeRegs->IRS[0].IE = 0; // 1: interrupter can generate an interrupt, 0: generating interrupts is prohibited (5.5.2.1, Table 43)
    0
  • E
    Mod

    version = "0.0.4.84 - Rev: 1472"

    xhci.c: Eventausgabe etwas überarbeitet, jetzt auch testweise einmal direkt in Konsole, einmal in eigener Konsole (Test wegen Handler)

    Interessanterweise kann man nun in bochs den Interrupt einschalten: 🙂
    xhci.c, Zeile 278:

    x->RuntimeRegs->IRS[0].IE = 1; // 1: interrupter can generate an interrupt, 0: generating interrupts is prohibited (5.5.2.1, Table 43)

    Bei Hardware bei meinem Test-PC leider störendes Dauerfeuer auf den Handler (Ursache nicht klar), das alles lahm legt. 🙄

    0
  • E
    Mod

    version = "0.0.4.85 - Rev: 1473"

    apic.h/c weiter entwickelt. Wirkung von APIC wurde im Nachgang von MrX durch Ausschalten des PIC ( http://wiki.osdev.org/PIC#Disabling ) gezeigt. Der APIC-Timer im Local APIC sendet periodische Interrupts. Nun fehlt noch die Programmierung des IO APIC
    ( http://www.lowlevel.eu/wiki/I/O_Advanced_Programmable_Interrupt_Controller ).

    0
  • M

    Version 0.0.4.86

    - Local-APIC-Treiber weiter verbessert: Timer-Interrupts funktieren nun
    -- PIC- und IDT-Code besser von einander getrennt
    -- Testweise handler auf APIC-Timer-Interrupt (no. 0x2F==47)
    -- EOI für APIC ausgeführt
    - Codestil verbessert

    0
  • E
    Mod

    Wer die Version 0.0.4.86 ausprobieren möchte:
    in os.h:

    /// #define _BOOTSCREEN_         // Enables the bootscreen displayed at startup
#define _SERIAL_LOG_         // Enables log information over the COM-Ports
/// #define _EHCI_ENABLE_        // EHCI driver will be installed and used on the disadvantage of UHCI/OHCI if supported by the attached device
/// #define _OHCI_ENABLE_        // OHCI driver will be installed
/// #define _UHCI_ENABLE_        // UHCI driver will be installed
/// #define _XHCI_ENABLE_        // xHCI driver will be installed

    in ckernel.c:

    if (apic_available())
        log("APIC", apic_install())
    else // PIC as fallback // Use APIC+PIC until our APIC driver is ready to replace PIC
        simpleLog("PIC", pic_install()); // Cf. interrupts.asm

    Testen kann man am besten mit VBox oder qemu. VMware bringt die 't' etwas langsamer. Bochs verbeisst sich in die FDD und bleibt nach einem 't' hängen.

    Dies ist ein unkalibrierter timer interrupt des neu eingerichtenen local APIC.

    idt_install wird übrigens am Ende von isr_install ausgeführt.

    0
  • E
    Mod

    version = "0.0.4.87 - Rev: 1475"

    apic.h/c zwischenstand (läuft noch nicht korrekt!)

    0
  • E
    Mod

    version = "0.0.4.88 - Rev: 1476"

    apic.h/c: APIC timer mittels PIT justiert.

    Tests: Test-PC und VMware laufen zeitgenau. xHCI in os.h ausgeschaltet, da es bei VMware dabei massive Probleme gibt. Qemu läuft etwas zu schnell. Bochs stürzt ab (exception). VBox läuft sehr langsam.

    0
Anmelden zum Antworten