4. Sourcecode Fortschritt

Sourcecode Fortschritt

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

    version = "0.0.3.79 - Rev: 1280"

    fat.c: Fehler bei FAT12/16 korrigiert
    Es fehlte: fpart->FatRootDirCluster = 0; bei FAT12/16

    0
  • M

    Version 0.0.3.80:

    - Erkennung und Abgabe von Fullspeed-Geräten
    - Erkennung von fehlgeschlagenen Transfers ergänzt, Timeout von 5 zur Wiederholung
    - Codestil und -vereinfachungen

    0
  • E
    Mod

    Diese Version läuft bezüglich usb hervorragend (vor allem richtig schnell) auf VMWare, allerdings schlecht (transfers klappen nicht vernünftig) auf meinem EHCI-Test-PC (lief früher dort perfekt). 😉

    Hispeed sticks werden auf dem PC abgewiesen und nach ohci (noch nicht in usb-Transfers eingebunden) abgegeben.

    0
  • M

    Version 0.0.3.81:

    - USB-Abstraktion verbessert, zahlreiche EHCI-Abhängigkeiten beseitigt
    - statische disk- und usb2_Device_t-Arrays beseitigt
    - Patch von neuer_user für FTP-Client: Shortcuts umgebaut, neue Funktionen (Upload, Dateirechte), Ausgaben verbessert

    0
  • E
    Mod

    version = "0.0.3.82 - Rev: 1283"

    asyncScheduler: Zeitsteuerung optimiert, so dass sowohl VMWare als auch PC mit verschiedenen Sticks läuft.

    performAsyncScheduler(e, true, true, 1 + transfer->packetSize/100);
    timeout = 3 * velocity + 1;
    sleepMilliSeconds(10);

    Bei 512 Byte: ( 3 * 6 + 1 ) * 10 = 190 ms

    0
  • E
    Mod

    version = "0.0.3.83 - Rev: 1284"

    usb_hc.c: Implementierung für u/o/ehci vorgesehen unter Nutzung der Schnittstelle transfer->HC->type

    0
  • E
    Mod

    version = "0.0.3.84 - Rev: 1285"

    ohci.h/c: USB-Transfers vorbereitet

    Für Tests:
    OHCI_USB_TRANSFER aktivieren in ohci.c, line 16

    Offene Fragen/TODOs:
    Beim Anstecken eines Low-Speed-Device (einfache Maus) werden sofort alle Konsolen belegt (Grund nicht klar).

    Die Zahl der von Anfang an vorhandenen rootports bei ohci reicht nicht aus, wenn weitere ports von ehci abgegeben werden können, im Prinzip alle. Hier sollte ein separater Portmanager her, der alle usb-Ports verwaltet.

    Aber die Abstraktion von USB und HC ist gelungen! 👍

    0
  • E
    Mod

    version = "0.0.3.85 - Rev: 1286"

    ohci.c korrigiert

    0
Anmelden zum Antworten