Sourcecode Fortschritt



  • Version 0.0.3.143:

    - Einige Memory-Leaks im Videomanager und VBE beseitigt
    - Kleinere Optimierungen im Paging-Modul
    - TransferFlag bei UHCI, OHCI und EHCI eliminiert (redundant durch andere Flags, inkonsequente Nutzung)
    - UHCI kompiliert nun auch ohne _UHCI_DIAGNOSIS_



  • Version 0.0.3.144:

    - Bugfix: Backspace funktioniert wieder (Daten wurden nicht in Videospeicher durchgeschrieben)
    - Bugfix: Kein #PF mehr in IPC (folder-Inhalt war nicht initialisiert)
    - IPC in Betrieb genommen - system_t-Struktur entfernt
    - Callstack automatisch angezeigt bei Fehlern


  • Mod

    version = "0.0.3.145 - Rev: 1346"

    uhci.c: Transfers laufen bei einem Stick bis read capacity komplett fehlerfrei durch. Fehler (babble) tauchen bei singleSectorRead(0, buffer, disk) auf.

    Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/rev.1346_UHCI_USB.PNG

    Babble:

    When a device transmits on the USB for a time greater than its assigned Max Length, it is said to be babbling. Since isochrony can be destroyed by a babbling device, this error results in the Active bit in the TD being cleared to 0 and the Stalled and Babble bits being set to one. The C_Err field is not decremented for a babble. The USB Error Interrupt bit in the HC Status register is set to 1 at the end of the frame. A hardware interrupt is signaled to the system. If an EOF babble was caused by the host controller (due to incorrect schedule for instance), the host controller will force a bit stuff error followed by an EOP and the start of the next frame.

    USB COMMAND REGISTER - Bit 7:

    Max Packet (MAXP). 1=64 bytes. 0=32 bytes. This bit selects the maximum packet size that can be used for full speed bandwidth reclamation at the end of a frame. This value is used by the Host Controller to determine whether it should initiate another transaction based on the time remaining in the SOF counter. Use of reclamation packets larger than the programmed size will cause a Babble error if executed during the critical window at frame end. The Babble error results in the offending endpoint being stalled. Software is responsible for ensuring that any packet which could be executed under bandwidth reclamation be within this size limit.

    Wir wollen hier 512 Byte übertragen (bei ohci geht es in irgendeiner Form problemlos).

    Die Stichworte sind: Babble und Stall

    Auf einem anderen PC mit UHCI wurden analoge Resultate erzielt, also repräsentativ.


  • Mod

    Funktionskette zur Unterstützung bei Abhilfe bezüglich Fehler (Babble):

    // usb2_msd.c, line 600
    analyzeDisk(device->disk);
    
    // devicemanager.c, line 296 ff.
    FS_ERROR analyzeDisk(disk_t* disk)
    {
        uint8_t buffer[512];
        singleSectorRead(0, buffer, disk); // first sector of partition
    
    // devicemanager.c, line 456
    FS_ERROR singleSectorRead(uint32_t sector, uint8_t* buffer, disk_t* disk)
    {
        disk->accessRemaining++;
        return sectorRead(sector, buffer, disk);
    }
    
    // devicemanager.c, line 28 ff.
    diskType_t FLOPPYDISK = {.readSector = &flpydsk_readSector, .writeSector = &flpydsk_writeSector},
               USB_MSD    = {.readSector = &usbRead,            .writeSector = &usbWrite},
               RAMDISK    = {.readSector = 0,                   .writeSector = 0};
    
    // usb2_msd.c, line 603 ff.
    FS_ERROR usbRead(uint32_t sector, void* buffer, void* dev)
    {
        usb2_Device_t* device = dev;
        uint32_t blocks = 1; // number of blocks to be read
        usbBulkTransfer_t read;
    
        startLogBulkTransfer(&read, 0x28, blocks, 0);
    
        usbSendSCSIcmd(device, device->numInterfaceMSD, device->numEndpointOutMSD, device->numEndpointInMSD,
                       read.SCSIopcode,
                       sector, // LBA
                       read.DataBytesToTransferIN,
                       &read, buffer, 0);
    
        logBulkTransfer(&read);
    
        return(CE_GOOD);
    }
    

    Experiment: Tauscht man in usb2_msd.c 512 konsequent gegen 64 aus, so verschwindet babble (und das daraus folgende stall und USB error).


  • Mod

    version = "0.0.3.146 - Rev: 1347"

    uhci.h/c: Funktion bool isTransactionSuccessful(uhci_transaction_t uT)* geschaffen, damit der Erfolg korrekt festgestellt werden kann, denn auch bei manchen Fehlern (z.B. babble) stellt der UHCI das inactive-Bit (active==0) ein.

    usb2_msd.c: Unterscheidung zwischen ohci/ehci und uhci bei usbRead und usbWrite

    TODO: implement 64-byte-packet transfers with UHCI instead of 512-byte-packets with OHCI (obviously auto-split) and EHCI


  • Mod

    version = "0.0.3.147 - Rev: 1348"

    ipc.c und paging.c: Style Anpassungen


  • Mod

    version = "0.0.3.148 - Rev: 1349"

    (in ckernel.c versehentlich nicht angepasst)

    paging.h/c: uint32_t paging_getVirtAddr(void* physAddress);

    Liefert virtuelle Adresse, wenn die phys. Adresse zugeordnet ist, bzw. 0, falls nicht. Damit kann man also auch feststellen, ob eine physische Adresse bereits im Paging verwendet wird.


  • Mod

    version = "0.0.3.149 - Rev: 1350"

    paging.h/c: uintptr_t paging_getVirtAddr(uintptr_t physAddress)


  • Mod

    version = "0.0.3.150 - Rev: 1351"

    paging_getVirtAddr(uintptr_t physAddress) bezüglich Geschwindigkeit optimiert


  • Mod

    version = "0.0.3.151 - Rev: 1352"

    kheap.c: kleine Änderungen



  • Version 0.0.3.152:

    - Initialisierungsreihenfolge bei USB-HCs geändert (*hci_setupUSBDevice)
    -> Kein #PF bei UHCI mehr
    - Aufsplitten von Transaktionen, die größer als die MPS des Endpoints sind (-> Funktioniert nicht?)
    - usbRead/usbWrite werden auch bei UHCI wieder ausgeführt (Teilweiser revert von r1347)
    - Bugfix: RAM in Bytes wird wieder korrekt angezeigt (nicht mehr 0 Bytes)
    - IPC weiter gefüllt (PCI-Daten)
    - IPC-Ausgabe verbessert: waitForKeyStroke alle 36 Zeilen
    - Kleinigkeiten


  • Mod

    Problem liegt im toggle-Verhalten. Durch Verändern von 1 Transfer auf 8 Transfers passt das nicht mehr (Status In-Transfer (13 bytes) ebenfalls 0 wie der letzte der acht vorherigen In-Transfers):

    512: 1 - 0
    64: 1 0 1 0 1 0 1 0 - 0 (bumm!)



  • Erhard Henkes schrieb:

    Problem liegt im toggle-Verhalten. Durch Verändern von 1 Transfer auf 8 Transfers passt das nicht mehr (Status In-Transfer (13 bytes) ebenfalls 0 wie der letzte der acht vorherigen In-Transfers):

    512: 1 - 0
    64: 1 0 1 0 1 0 1 0 - 0 (bumm!)

    Dann hat eine Internetquelle, die ich dazu konsultiert habe, unrecht. Die hat nämlich behauptet dass der Split keinen Einfluss auf das Toggle folgender Transaktions hat (die nicht zum gesplitteten Teil gehören)


  • Mod

    version = "0.0.3.153 - Rev: 1354"

    Formale Änderungen



  • Version 0.0.3.154:

    - *hci_setupUSBDevice-Funktionen zusammengefasst in usb_setupDevice
    - Neues, generischeres Toggle-System (-> UHCI läuft nun)
    - Kleinigkeiten (u.a. überflüssige printf-Parameter an 3 Stellen entfernt)


  • Mod

    Dickes Lob! 👍



  • Version 0.0.3.155:

    - Speicherverbrauch der *HCI-Treiber reduziert
    - USB-Code aufgeräumt und z.T. logischer gestaltet


  • Mod

    Test-Resultat:

    3 Typen bei Test mit uhci:

    1. Corsair Flash Voyager funktioniert komplett incl. 3:/ttt (lediglich 2 * HC Halted ohne Schadwirkung)

    2. EMTEC 4GB: SET ADDRESS ok, GET DEVICE: usb error & stalled

    3. Intenso Rainbow Line: bei SET ADDRESS: No response from Device

    uhci spec:

    4.1.5 STALLED
    This event indicates that a device/endpoint returned a STALL handshake during a transaction or that the transaction ended in an error condition. This indicates that the endpoint has reached a condition where no more activity can occur without intervention from the driver. In addition to the TDs Stalled bit being set, the Active bit will be cleared. HCD will not accept any more transfers on this endpoint until the condition is cleared by driver software. Like the Babble event, reception of a STALL does not decrement the error counter. A hardware interrupt is signaled to the system.


  • Mod

    version = "0.0.3.156 - Rev: 1357"

    usb weiter optimiert. Bei ausbleibendem Erfolg von GET_DEVICE wird mit Fehlermeldung abgebrochen!

    Kleine Korrekturen in uhci (z.B. korrekte Port-Ausgaben j+1).

    TODO: Leider wurde der wesentliche Erfolgsfaktor für alle Typen von usb-Sticks bei uhci noch nicht gefunden (s.o.).


  • Mod

    version = "0.0.3.157 - Rev: 1358"

    Reihenfolge umgebaut:
    Einer der drei EMTEC pensticks, mit denen u.a. getestet wird, läuft basierend auf uhci durch die controls durch und steigt erst bei test-unit-ready (also ab bulk) aus.


Anmelden zum Antworten