4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • 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
  • E
    Mod

    version = "0.0.3.75 - Rev: 1276"

    irq.h/c: sprechende defines eingefügt, BIT(n) verwendet

    Bezüglich ehci/usb2.0 hier ein Ablauf (4 screenshots) in VMWare Player beim Anstecken eines usb-sticks: http://www.henkessoft.de/OS_Dev/Bilder/rev.1276_ehci_asyncScheduler.PNG

    3:/arrow wird erfolgreich geladen. Zeitbedarf beim Laden: ca. 50 sec, insgesamt 23 asyncInterrupt Timeouts beim Laden, das aber funktioniert.

    Manche Dateien werden gefunden, manche nicht (Kopie des FAT12 FloppyImages auf den usb-stick mit dd_for_windows aus dem FloppyImage):

    Gefunden werden: arrow, ftp, pqeq, readme (der readcache funktioniert beim Mehrfachladen sehr gut!)
    Nicht gefunden werden: browser, calc, hello, irc, music, piano, pong, psort, showdns, starwars, , test, ttt, udprecv, udpsend, webshell

    Schaut man bei den geladenen Dateien nach einer Gemeinsamkeit, so findet man diese: http://www.henkessoft.de/OS_Dev/Bilder/rev.1276_ehci_asyncScheduler_GeladeneDateien.PNG
    Sie starten bei cluster 1450, 1493, 1429, 1410. Der Ort der Datei im FAT12-Filesystem (1410 - 1493) bestimmt also, ob sie auf dem usb-stick gefunden wird. Von Floppy werden bei gleichem Zustand des devicemanagers, also mit zugefügtem usb-stick, alle Dateien geladen!

    Auch mit einem anderen Stick wurde das gleiche Ergebnis gefunden.

    Ausnahmen: einmal wurde test gefunden, manchmal wird garnichts gefunden.

    Ein Stick wurde dann auf FAT32 formatiert und alle Dateien im Windows Explorer von Floppy auf den Stick kopiert (keine Ahnung, wie die dort ankommen, dürfte bezüglich Reihenfolge aber bleiben). Dateien konnte geladen werden!

    Vielleicht bringt uns dieser umfangreiche Test bei der Fehlersuche weiter. Da dieser Vorgang "früher" problemlos lief, fragt sich, was geändert wurde.

    0
  • E
    Mod

    version = "0.0.3.76 - Rev: 1277"

    fat.c: Ausgaben umgelegt nach serial output (VMWare kann das in ein File umleiten)

    ehci-asyncScheduler deutlich beschleunigt! (asyncInt wird pos./neg. angezeigt)

    0
  • M

    Version 0.0.3.77:

    - EHCI: J-State und undefined state werden nicht mehr an Companion HC abgegeben (Änderung gemäß EHCI-Spezifikation 1.0, Seite 28, 56), port-Reset nach Auslesen des states
    - readCacheFlag entfernt - Readcaches nun dauerhaft aktiv
    - getPartition stabilisiert - Bugfixes in fopen von ehenkes dahingehend überarbeitet.
    - VM86-Tasks mit cli/sti statt task_switching=false/true gesichert -> VBE geht nun wieder
    - flpydsk_refreshVolumeName optimiert, weniger Zugriffe bei mehreren Diskettenlaufwerken, nur noch für Floppylaufwerke aufgerufen

    0
  • E
    Mod

    Bezüglich der Fehlersuche "File not found" wude festgestellt, dass bei einem usb-Stick mit FAT12 (hergestellt durch Kopieren des Floppy-Images mit dd) das rootdir falsch angesteuert wurde.

    Partitions-Start gemäß MasterBootRecord(MBR): sector 32
    Angesteuert wurde Sector 52 bei der Suche nach einem File.
    Das hätte aber 32+19 sein müssen, also 51.
    Ein Test zeigte, dass diese Annahme richtig ist.
    Die Ursache der fehlerhaften Berechnung wurde bisher noch nicht gefunden.

    Eine FATx-abhängige Stelle in fat.c:
    uint32_t cluster2sector(FAT_partition_t* volume, uint32_t cluster)
    Hier erfolgt die Berechnung des Sectors. Für die root dir von FAT12 und FAT16 ist die Formel: sector = (volume->root + cluster * volume->SecPerClus);
    Eine falsche Zahl könnte hier durch volume->root entstehen.

    Anylsiert man die Revisionen, so tritt ein/der Fehler bei dem Übergang Rev. 1178 --> 1179 (MrX) ein.

    0
  • E
    Mod

    version = "0.0.3.78 - Rev: 1279"

    ehci: asyncScheduler umgebaut

    FloppyImage fehlt

    0
Anmelden zum Antworten