Sourcecode Fortschritt
-
version = "0.0.3.54 - Rev: 1255"
ohci.c: nun wird der Port aktiviert ("enabled"), erfolgt nur beim Anstecken eines Device. Alle PortStatusBits werden ausgewertet/zurückgesetzt(falls notwendig).
-
version = "0.0.3.55 - Rev: 1256"
ohci.h/c: ED, TD
-
version = "0.0.3.56 - Rev: 1257"
ohci.c: Port-Aktivierung im Code vereinfacht (MrX: bitte testen, Start-of-frame muss aktiviert bleiben für die Porterkennung)
usb1.h/c: als frame hinzugefügt (für UHCI und OHCI)TODO: bei EHCI Abgabe an companion HC überprüfen
-
version = "0.0.3.57 - Rev: 1258"
ehci.c: Wechsel zwischen EHCI und Companion HC eingebaut (nun ist UHCI und OHCI ja verfügbar). Es wird z.Z. die "lowest cHC number" verwendet.
(SE0 --> EHCI, K-State --> lowest cHC)
-
version = "0.0.3.58 - Rev: 1259"
siehe: http://www.c-plusplus.net/forum/p2116360#2116360
ehci.c: K- und J-State werden abgegeben. Code als switch/case übersichtlicher.J-State kann z.B. mit einer Fullspeed Gamer-Maus getestet werden.
-
version = "0.0.3.59 - Rev: 1260"
ehci.h/c. kleine Veränderungen
-
version = "0.0.3.60 - Rev: 1261"
ohci.h/c: ED, TD, TDbuffer eingerichtet
-
version = "0.0.3.61 - Rev: 1262"
ehci umgebaut von global auf Struktur ehci_t pro EHCI
-
version = "0.0.3.62 - Rev: 1263"
Auch für _EHCI_DIAGNOSIS_ und _USB2_DIAGNOSIS_ nun fehlerfrei.
Nun kann man in os.h alle HCI gezielt für die Installation in PrettyOS einstellen:
#define _EHCI_ENABLE_ // EHCI will be installed, if this is defined, otherwise not #define _OHCI_ENABLE_ // OHCI will be installed, if this is defined, otherwise not #define _UHCI_ENABLE_ // UHCI will be installed, if this is defined, otherwise not
-
Version 0.0.3.63:
- Interrupt-Filter für EHCI, OHCI und UHCI verbessert
- Code umsortiert, Codestyle
-
Version 0.0.3.64:
- EHCI-Transactions implementiert, mit usbTransferEnumerate und usbTransferDevice getestet
-
Version 0.0.3.65:
- usb2.c auf neue Transaction-Funktionen umgestellt
-
version = "0.0.3.66 - Rev: 1267"
usb2_msd.c: control-transfers umgesetzt auf neues usb-interface
-
version = "0.0.3.67 - Rev: 1268"
ehci.c: VMWare läuft nun wieder (seit rev. 1258: HCHalted)
// e->CapRegs->HCSPPORTROUTE_Hi = e->CapRegs->HCSPPORTROUTE_Lo = 0; // all valid ports go to lowest cHC number // VMWare does not reset!
Dieses 15-nibble-array-Register sollte sowieso RO sein, also ein netter VMWare-Bug.
-
version = "0.0.3.68 - Rev: 1269"
- ohci-Ports werden nun ebenfalls "attached"
- Ausgabe der Port-Liste bezüglich Formatierung verbessert
-
Version 0.0.3.69:
- USB/EHCI-Code aufgeräumt
- Bugfix: Unicode-Strings werden wieder korrekt transferriert (Vergessene Verweise auf dataQTDpage0 entfernt)
-
Version 0.0.3.70:
- SCSI-Commands umgeschrieben. (Funktioniert emuliert, aber nicht auf echter Hardware)
-
sehr fragil, stick-abhängig.
USB_BULK ist besser als USB_CONTROL für die bulk-tranfers. Damit ging es am PC mit einem anderen Stick, bei dem dann ttt ausgeführt werden konnte.Probleme:
- hispeed-sticks werden am PC nicht sicher erkannt, dann Umschalten auf cHC
- 3:/ttt --> file not found (obwohl es da sein muss, floppy geht manchmal!)
- Kombination aus TestUnitReady und RequestSense in testDeviceReady(...) klappt mit dem neuen Code nicht bei jedem Stick zuverlässig (kein ehci/usb Code-Problem)
Die Probleme tauchen auf bei VBox 4.08 und beim EHCI-Test-PC (OHCI als cHC)
-
version = "0.0.3.71 - Rev: 1272"
usb msd etwas optimiert (VBox 4.08 und test-PC läuft nun).
Der ehci/usb-Umbau ist gelungen.sleepMilliSeconds(50 + velocity * 200);
Es spielt also das Zeitverhalten eine große Rolle.
Das Wechselspiel zwischen den SCSI commands TestUnitReady und RequestSense läuft solange, bis das Ergebnis zufriedenstellend ist, siehe testDeviceReady(...), allerdings z.Z. höchstens drei Runden ( const uint8_t maxTest = 3; ).
In der Regel klappt es nach dem zweiten TestUnitReady.
TODO: usb- und usb_msd-Funktionen unabhängig machen von e/o/uhci!
-
Erhard Henkes schrieb:
version = "0.0.3.71 - Rev: 1272"
usb msd etwas optimiert (VBox 4.08 und test-PC läuft nun).
Der ehci/usb-Umbau ist gelungen.sleepMilliSeconds(50 + velocity * 200);
Es spielt also das Zeitverhalten eine große Rolle.
Sehr schön, dass Du den Fehler gefunden hast.
Ärgerlich allerdings, dass es ausgerechnet mit der Ausführungsgeschwindigkeit des asyncSchedulers zusammenhängt - wir müssen unbedingt einen Weg finden, diese langen Wartezeiten loszuwerden, andernfalls bleibt unser EHCI so lahm wie ein Floppylaufwerk.Erhard Henkes schrieb:
TODO: usb- und usb_msd-Funktionen unabhängig machen von e/o/uhci!
Weitgehend obsolet - Genau das haben wir doch jetzt getan.