4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    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)

    0
  • E
    Mod

    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.

    0
  • E
    Mod

    version = "0.0.3.59 - Rev: 1260"

    ehci.h/c. kleine Veränderungen

    0
  • E
    Mod

    version = "0.0.3.60 - Rev: 1261"

    ohci.h/c: ED, TD, TDbuffer eingerichtet

    0
  • E
    Mod

    version = "0.0.3.61 - Rev: 1262"

    ehci umgebaut von global auf Struktur ehci_t pro EHCI

    0
  • E
    Mod

    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
    0
  • M

    Version 0.0.3.63:

    - Interrupt-Filter für EHCI, OHCI und UHCI verbessert
    - Code umsortiert, Codestyle

    0
  • M

    Version 0.0.3.64:

    - EHCI-Transactions implementiert, mit usbTransferEnumerate und usbTransferDevice getestet

    0
  • M

    Version 0.0.3.65:

    - usb2.c auf neue Transaction-Funktionen umgestellt

    0
  • E
    Mod

    version = "0.0.3.66 - Rev: 1267"

    usb2_msd.c: control-transfers umgesetzt auf neues usb-interface

    0
  • E
    Mod

    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.

    0
  • E
    Mod

    version = "0.0.3.68 - Rev: 1269"

    - ohci-Ports werden nun ebenfalls "attached"
    - Ausgabe der Port-Liste bezüglich Formatierung verbessert

    0
  • M

    Version 0.0.3.69:

    - USB/EHCI-Code aufgeräumt
    - Bugfix: Unicode-Strings werden wieder korrekt transferriert (Vergessene Verweise auf dataQTDpage0 entfernt)

    0
  • M

    Version 0.0.3.70:

    - SCSI-Commands umgeschrieben. (Funktioniert emuliert, aber nicht auf echter Hardware)

    0
  • E
    Mod

    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:

    1. hispeed-sticks werden am PC nicht sicher erkannt, dann Umschalten auf cHC
    2. 3:/ttt --> file not found (obwohl es da sein muss, floppy geht manchmal!)
    3. 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)

    0
  • E
    Mod

    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!

    0
  • M

    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.

    0
  • E
    Mod

    version = "0.0.3.72 - Rev: 1273"

    Zwei (bisher ignorierte) Fehler bei der Eingabe ungültiger Laufwerke in die Shell abgefangen (fsmanager.c, fopen).

    0
  • E
    Mod

    version = "0.0.3.73 - Rev: 1274"

    #define _EHCI_DIAGNOSIS_ // Debug EHCI
    #define _USB2_DIAGNOSIS_ // Debug USB 2.0 transfers
    können nun wieder verwendet werden (liefert Einsichten in Details des Transfer-Ablaufs).

    0
  • E
    Mod

    version = "0.0.3.74 - Rev: 1275"

    ehci-usb-Transfer signifikant beschleunigt durch Nutzung der doorbell und des bit5 im Statusregister. Stabil?

    usbsts:

    USBSTS - USB Status Register, bit5: Interrupt on Async Advance R/WC 0=Default. System software can force the host controller to issue an interrupt the next time the host controller advances the asynchronous schedule by writing a one to the Interrupt on Async Advance Doorbell bit in the USBCMD register. This status bit indicates the assertion of that interrupt source.

    doorbell:

    USBCMD – USB Command Register, bit 6: Interrupt on Async Advance Doorbell R/W. This bit is used as a doorbell by software to tell the host controller to issue an interrupt the next time it advances asynchronous schedule. Software must write a 1 to this bit to ring the doorbell. When the host controller has evicted all appropriate cached schedule state, it sets the Interrupt on Async Advance status bit in the USBSTS register. If the Interrupt on Async Advance Enable bit in the USBINTR register is a one then the host controller will assert an interrupt at the next interrupt threshold. See Section 4.8.2 for operational details. The host controller sets this bit to a zero after it has set the Interrupt on Async Advance status bit in the USBSTS register to a one. Software should not write a one to this bit when the asynchronous schedule is disabled. Doing so will yield undefined results.

    Test auf PC mit zwei usb2.0-Sticks: viele asyncInt time outs, noch immer langsam. Funktioniert aber. 🙄

    0
Anmelden zum Antworten