Sourcecode Fortschritt
-
0.0.4.164 - Rev: 1550 (Rev.-Nr. versehentlich im kernel zu hoch)
xhci.h/c: Own event/slot structs for feedback by events. Sleeps substituded by timeout-while-loops with check of target.
test-PC: transfers run well. Babble detect at last bulk transfer (read sector 0).
Doorbell Device at slotNr.: 4 DCI: 5 type: IN
Timeout Error: waiting for Bulk Transfer
after Xfer:
slot: 4, states EP0: 1 EP1: 1 0 EP2: 0 1 pls: 0 slot st.: 3,
Completion: Success slot:4 EP:5 ED:0 XferLen:0 c:1 type:Xfer Event
Completion: Success slot:4 EP:5 ED:0 XferLen:0 c:1 type:Xfer Event
- - - - - - - - - - - press key - - - - - - - - - - -00 78 4F FF 00 00 02 00
55 53 42 53 25 42 42 42 00 00 00 00 00
CSW signature OK CSW tag 25h OK CSW data residue OK CSW status OK
Capacity: 3840 MiB, Last LBA: 4283398144, block size: 131072
>SCSI: read sector: 0
OUT part
toggle OUT 1
before Xfer:
slot: 4, states EP0: 1 EP1: 1 0 EP2: 0 1 pls: 0 slot st.: 3,
xhci_outTransaction - Out transaction
Doorbell Device at slotNr.: 4 DCI: 2 type: OUT
Timeout Error: waiting for Bulk Transfer
after Xfer:
slot: 4, states EP0: 1 EP1: 1 0 EP2: 0 1 pls: 0 slot st.: 3,
Completion: Success slot:4 EP:2 ED:0 XferLen:0 c:1 type:Xfer Event
- - - - - - - - - - - press key - - - - - - - - - - -
IN part
before Xfer:
slot: 4, states EP0: 1 EP1: 1 0 EP2: 0 1 pls: 0 slot st.: 3,
xhci_inTransaction - In transaction
xhci_inTransaction - In transaction
Doorbell Device at slotNr.: 4 DCI: 5 type: IN
Timeout Error: waiting for Bulk Transfer
after Xfer:
slot: 4, states EP0: 1 EP1: 1 0 EP2: 0 2 pls: 0 slot st.: 3,
Completion: Babble Detected Error slot:4 EP:5 ED:0 XferLen:512 c:1 type:Xf
er Event
- - - - - - - - - - - press key - - - - - - - - - - -
--------------------------------------------------------------------------------
usb3 Port: 4, device attached and enabled
Cmd: 18, Evt0: 53, Xfer: 25 6 0 0 10
-
0.0.4.165 - Rev: 1551
xhci: läuft gut, allerdings zwei erkennbare Probleme:
- timeout error bei issue Transfer (doorbell/event-mechanismus funktioniert noch nicht wie beabsichtigt)
- babble detect bei read sector 0 (Idee: TDsize vlt. richtig setzen)
-
0.0.4.166 - Rev: 1552
xhci: Doppelten Code etwas aufgeräumt, Commands in Funktionen gepackt. Keine Verbesserung, aber auch keine Verschlechterung. Aufgaben wie oben bestehen noch.
-
0.0.4.167 - Rev: 1553
xhci: weiteres debugging eingebaut (experimentelle Version), Auslesen der Adress-Pointer beim event-thread (bei ED = 0 ist das der auslösende TRB)
-
Version 0.0.4.168:
- Verbesserungen am xHCI-Treiber:
-- Funktion calculateDCI() zur berechnung der DCI aus der EP-Nummer
-- Mechanismus zur Nutzung von TDsize in in- und out-Transactions
-- 256 statt 20 Event-TRBs
-- Warte erst auf Abschluss des Transfers, kopiere dann die Daten
- paging_getVirtAddr repariert
- fehlendes irq_resetCounter() im Floppytreiber ergänzt
-
0.0.4.169 - Rev: 1555
xhci.c:
- doorbell aus den commands genommen
- Zahl der slots auf MAX_HC_SLOTS erhöht (für Hubs)Test auf vmware erfolgreich, beim Test-PC kommen z.Z. außer dem ersten keine weiteren Event-Interrupts
-
0.0.4.170 - Rev: 1556
xhci: Fehler bez. fehlendes cycle-bit in transaction korrigiert
vmware läuft gut, bei test-PC nur ein event-interrupt
-
Version 0.0.4.171:
- Typen der Parameter von USB-Control-Transfers korrigiert
- DataStage von Control-Transfers (TRT) korrekt gesetzt
- IOC=1 für letzte Transaction eines Transfers (aber derzeit auch noch für alle anderen Transactions)
-
0.0.4.172 - Rev: 1558
xhci: event debugging für commands verbessert
Das Event liefert die phys. Adresse des Commands. Via paging_getVirtAddr greifen wir auf den TRB-Typ des Commands zu. Damit lässt sich Event und Command besser zuordnen und auswerten.
Damit paging_getVirtAddr funktioniert, wurde lookForVirtAddr korrigiert: i >= start
-
0.0.4.173 - Rev: 1559
xhci:
- Event-Anzeige ohne eigene Konsole (Vereinfachung des Ablaufs)
- Event-Anzeige nur bei Error
-
0.0.4.174 - Rev: 1560
xhci: Verschieben von Zeigern von der xHC- zu den Endpoints-Structs.
typedef struct { //... // transfer ring xhci_xfer_NormalTRB_t* virtEnqTransferRingPtr; xhci_xfer_NormalTRB_t* virtDeqTransferRingPtr; xhci_xfer_NormalTRB_t* TransferRingbase; bool TransferRingProducerCycleState; // PCS uint32_t TransferCounter; } xhci_endpoint_t;Nun sollte auch bei mehreren Sticks jeder Endpoint seinen eigenen Transferring haben. Die Interrupts werden immer noch alle nach Interrupter 0 geschickt.
-
0.0.4.175 - Rev: 1561
xhci: Erste Reaktion in parseEvent auf Babble Detect
Übergang von Halted zu Stopped gelingt bereits.
-
Version 0.0.4.176:
- Fehlerkorrekturen in USB:
-- Allokiere soviele Endpoints, wie das Gerät hat
-- Größen von Strukturen und Transfers aneinander angepasst/korrigiert
-- Fehlende Nullterminierung eines Strings hinzugefügt
-
Rev: 1563 im Kernel versehentlich alles eine Nummer zu tief!
usb: Fehler behoben Bei Descriptor Device
Experimentell:
xhci: xhci_Set_TR_DeqPointer_Command eingebaut, Endpunkt von Halted(2) über Stopped(3) nach Running(1) bewegt.Details siehe: http://www.c-plusplus.net/forum/p2398877#2398877
-
0.0.4.178 - Rev: 1564
xhci: bulk Transfers laufen ohne babble detect error
z.Z. auf Grund von Zeitproblemen noch mit _XHCI_DIAGNOSIS_
Anmerkung zum xhci_handler: // printf("Interrupt came from another xHCI device!\n"); // TODO: clarify the source of the interrupt!
Geladen via 3:/ttt
PrettyOS [Version 0.0.4.178 - Rev: 1564] Console 0: 3:/ttt.ELF -------------------------------------------------------------------------------- ================================================================================ TicTacToe 3x3 v0.7.0 -------------------------------------------------------------------------------- ------------- | 0 | 1 | 2 | ------------- | 3 | 4 | 5 | ------------- | 6 | 7 | 8 | ------------- ------------- | | | | ------------- | | | | ------------- | | | | ------------- Player X: Please type in a number betwen 0 and 8. -------------------------------------------------------------------------------- Tuesday, May 13, 2014, 19:08:52 94 s runtime. CPU: 3410 MHz \
-
0.0.4.179 - Rev: 1565
xhci: mps und interval werden von usb übernommen, timing durch variation der schalter in os.h etwas eingeengt
usb: interval zusätzlich in endpoints
os.h: XHCI Schalter aufgespaltentest-PC funktioniert bestens!
vmware bindet angedockte sticks über einen hub ein (bisher noch kein erfolg ein programm zu laden)
-
0.0.4.180 - Rev: 1566
Die xhci/usb-Debug-Schalter in os.h können nun alle deaktiviert werden.
Überraschend mussten in xhci_prepareSlotsForBulkTransfers die Zeilen 794-797 und 817-821 verbleiben, warum auch immer (Klärungsbedarf).
-
0.0.4.181 - Rev: 1567
xhci:
Fehler gefunden in xhci_prepareSlotsForBulkTransfers.
Debugs für xhci wieder vereinheitlicht.
-
0.0.4.182 - Rev: 1568
usb_msd.c: Korrektur der Kapazitätsbestimmung mittels read capacity (10)
(Big-Endian bei SCSI)
-
0.0.4.183 - Rev: 1569
xhci:
- Fehler in initHC beseitigt
- weitere Ausgaben hinter DEBUG-Schalter gesetzt, damit ein flüssiger Ablauf stattfindet
- Transfers beschleunigt (Problem: Aussetzer nach dem ersten Event-Interrupt)test-PC: erfolgreiche Ladevorgänge von usb-Sticks (sticks: usb 2.0 oder 2.10)