Sourcecode Fortschritt


  • Mod

    0.0.4.138 - Rev: 1525

    xhci: portsEnabled flag eingebaut für den reset-Vorgang in detectDevice.

    vmware reagiert nun endlich mit den bereits angesteckten usb-devices.
    Beim test-PC gibt es mit bereits beim Hochfahren angesteckte usb-devices noch Probleme (attached, but not enabled).


  • Mod

    0.0.4.139 - Rev: 1526

    xhci.c: experimentelle Version


  • Mod

    0.0.4.140 - Rev: 1527

    xhci: enablePorts in prepareSlots umbenannt. Resetvorgang zur Verbesserung der Transparenz nur noch in detectDevice, in prepareSlots gestrichen.

    Der eigentliche EnablePort/Device-Vorgang erfolgt durch Reset des Ports.

    vmware: klappt
    test-PC: Port Power (PP), aber kein PED (Port Enabled Detect)


  • Mod

    0.0.4.141 - Rev: 1528

    xhci.h/c: Modul mit Erfahrungen der letzten Versionen verbessert.
    Aktuell: vmware und test-PC starten usb-Transfer mit angehängtem Stick, beim test-PC klappt der nachträgliche Attach nicht (PP, aber kein PED nach Reset)


  • Mod

    0.0.4.142 - Rev: 1529

    xhci: neue Funktion showStates(...)

    vmware: klappt
    test-PC: angehängt Hochfahren klappt prinzipiell.
    test-PC: späteres Einstecken: PLS 7 -> 9 (hot reset) ??? PED klappt nicht.



  • Version 0.0.4.143:

    - Ineffizientes byteweises Lesen und Schreiben im FAT-Treiber eliminiert; Unnötige Schreib-/Lesevorgänge entfernt
    - Fehlende Initialisierungen von TDBuffer in xHCI ergänzt
    - Fehlerkorrektur im Floppytreiber: Floppy läuft nun auch in Bochs 2.6.2
    - Fehlerkorrektur im Devicemanager: Motor nach Schreibvorgängen abgeschaltet
    - Kleine Codestil-Korrekturen
    - NextRelease.txt ergänzt


  • Mod

    0.0.4.144 - Rev: 1531
    xhci: Ablauf verbessert. Address Cmd mit BSR=1 in detectDevice ermöglicht beim test-PC den Port Link State - Übergang von 7 nach 0 (ohne: 7 nach 9). Damit ist nun ein Setzen des PED im PORTSC beim späteren Anstecken eines Sticks möglich.

    vmware: reset und usb Ablauf ok
    test-PC:
    angesteckt hochfahren: reset OK, usb-Ablauf OK bzw. nicht OK (device abhängig)
    später anstecken: reset OK, usb-Ablauf OK


  • Mod

    0.0.4.145 - Rev: 1532

    xhci.h/c: CmdRing- u. TransferRing Management aufgebaut bez. LinkTRB (in beide stellt die Software TRBs ein)

    TODO:
    - Auf Richtigkeit prüfen
    - HACK mit Ringzeiger beseitigen (phys./virt. Address)
    - EventRing Management analog aufbauen (dort stellt der xHC TRBs ein)
    - Mehrere Transferringe und Eventringe ermöglichen


  • Mod

    0.0.4.146 - Rev: 1533

    video.c: Korrektur bez. writeInfo(...)
    xhci.h/c: Ring Management weiter ausgebaut (Cmd u. Transfer klappt, Event noch nicht)
    *(xhci-Fehler: delay anstelle sleep schafft Probleme in detectDevice)
    *


  • Mod

    0.0.4.147 - Rev: 1534

    xhci.h/c: delay durch sleep ersetzt. DEBUG erweitert für event-ring

    vmware klappt wieder
    test-PC steigt aus (wegen showCounter in start...)


  • Mod

    0.0.4.148 - Rev: 1535

    xhci: Fehler im Event-Ring beseitigt

    nach dem korrekten Rücksprung:
    vmware: rast bis zum Ende durch (?)
    test-PC: bleibt am Anfang stehen (xHC schiebt offensichtlich nichts mehr nach)


  • Mod

    0.0.4.149 - Rev: 1536

    xhci: weitere Versuche zur Optimierung des Eventringes

    test-PC: bisher interessantes Verhalten, wenn auch noch nicht korrekt, zumindest wird der Eventring nach dem Rücksprung wieder bearbeitet.


  • Mod

    0.0.4.150 - Rev: 1537

    xhci: prepareEventRing geschaffen zur Verbesserung der Übersicht. showEvent so eingestellt, dass der EventRing den wrap back durchführt und cyclisch mit neuen Events startet (allerdings nach wrap back verzögert).
    Zum Testen wurde Folgendes eingestellt:

    const uint16_t TRB_PER_SEGMENT    = x->evtSegmentSize = 40; // at least 16!
    

    test-PC und vmware: Reset/Ctrl Transfers laufen sowohl angehängt und als auch später angesteckt (beim PC).


  • Mod

    0.0.4.151 - Rev: 1538

    xhci: weiter entwickelt, eher experimentell.
    Event-Ring läuft auf test-PC (damit sind die cmd/transfer/event-Ringe bez. xhci funktionsfähig)


  • Mod

    0.0.4.152 - Rev: 1539
    xhci: Verbesserungen im Debug (z.B. Zuordnung Event zu Command über die phys. Adresse)


  • Mod

    0.0.4.153 - Rev: 1540
    xhci:
    doorbell array darf man nur als DWORD ansprechen, endlich sind die "EP not enabled" weg! <== wichtiger Fortschritt
    Event-Ring wieder auf 256 TRB eingestellt, damit Störungen beim wrap back nicht andere überlagern oder auslösen.
    EP states 0, 1 IN/OUT, 2 IN/OUT angezeigt für die Analyse.


  • Mod

    0.0.4.154 - Rev: 1541

    xhci: Vorbereitungen für den Bulk-Transfer getroffen, die EP1 OUT und EP2 IN stehen aber noch nicht auf "running" (=1).

    Ideen:

    1. Für jeden EP einen eigenen Transferring schaffen (spec: "... There is a 1:1 mapping between Transfer Rings and USB Pipes. They are defined by an Endpoint Context data structure contained in a Device Context ...")
      2)vorverlagern vor das usb SET_CONFIGURE (spec: "in conjunction")

  • Mod

    0.0.4.155 - Rev: 1542

    xhci: Pro EP - getrennt nach IN/OUT - einen eigenen Transferring geschaffen.
    ControlTransfers laufen auf vmware u. test-PC. Bei Bulk noch kein EP enabled.


  • Mod

    0.0.4.156 - Rev: 1543

    xhci: Vorbereitungen für bulk transfers weiter optimiert, allerdings wurden die bulk IN/OUT EP bisher nicht enabled.


  • Mod

    0.0.4.157 - Rev: 1544

    Geschafft. Die Bulk-IN/OUT-Endpoints nehmen nun auch in xhci ihre Arbeit auf. Wir können uns damit in die Bulk-Transfers vertiefen. Der bisher erste Gruß auf dem test-PC ist ein "Stall Error" (stickabhängig). 😉

    PrettyOS [Version 0.0.4.157 - Rev: 1544] Console 0: xhci_portCheck
    --------------------------------------------------------------------------------
    F7 7B FA 7D FE 4F 4F B2 EF 6E 2E 7F 5E F2 F3 17

    length: 18 descriptor type: 3
    string: 7365D699 serial: 7365D699

    USB: SET_CONFIGURATION 1
    xhci_setupTransfer
    before Xfer:
    slot: 3, states EP0: 1 EP1: 0 0 EP2: 0 0 pls: 0 slot st.: 2,
    xhci_setupTransaction. req = 9 loVal = 1
    prepareSlotsForBulkTransfers DCI_bulk_OUT: 2 DCI_bulk_IN: 5 mpsOUT = 64 mpsIN =
    64
    Configure Endpoint Command
    enqueueCommand at phys: 00DD2110
    setEnqueueCommandPtr
    ringDoorbell_HC
    slot: 3, states EP0: 1 EP1: 1 0 EP2: 0 1 pls: 0 slot st.: 3 ...
    --------------------------------------------------------------------------------
    usb3 Port: 3, device attached and enabled
    Cmd: 18, Evt0: 29, Xfer: 22 0 0 0 0

    test-PC: EP1 OUT und EP2 IN sind "running" (state=1), und der xHC geht von "addressed" (state=2) nach "configured" (state=3).

    Im State "configured" sind nur noch diese Commands erlaubt:
    Configure Endpoint,
    Reset Endpoint,
    Stop Endpoint,
    Set TR Dequeue Pointer,
    Evaluate Context,
    Reset Device,
    Negotiate Bandwidth,
    Disable Slot.


Anmelden zum Antworten