4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • M

    Version 0.0.3.136:

    - Bugfix: Shell stürzt nicht mehr ab, wenn man den Schreibcursor nach links bewegt
    - Bugfix: Kein #GPF mehr, wenn ein USB-Stick schon beim boot steckt (EHCI)
    - Einige fehlende E0-Tasten ergänzt - Entf, Pos1, End, ...-Tasten funktionieren wieder (u.a. von der Shell unterstützt)
    - Timer-Ticks jetzt als uint64_t gespeichert (Rechnungen weiterhin mit uint32_t, da keine 64-bit-Unterstützung)
    - video_updateCursor in vga_updateCursor umbenannt. Einsatz überarbeitet.

    0
  • E
    Mod

    version = "0.0.3.137 - Rev: 1338"

    uhci.c: transfer/transactions/QH- u. TD-Funktionen eingerichtet (Transfers klappen noch nicht)

    0
  • E
    Mod

    version = "0.0.3.138 - Rev: 1339"

    uhci.c: Fehler beseitigt (Transfers laufen noch nicht korrekt)

    0
  • E
    Mod

    version = "0.0.3.139 - Rev: 1340"

    uhci.c: weiter gecheckt, aber Transfers laufen noch nicht. 🙄

    0
  • E
    Mod

    version = "0.0.3.140 - Rev: 1341"

    uhci.c: Verkettung und Vf, QH, T sollte nun stimmen nach debugging.

    Aufgabe: TDs werden noch nicht abgearbeitet (active bit).

    0
  • E
    Mod

    version = "0.0.3.141 - Rev: 1342"

    uhci.c: Port Reset nach attach, alle 1024 Frames auf QH
    Debugging zeigt korrekte Verknüpfung, Transfers laufen trotzdem noch nicht (wie wenn device nicht vorhanden; evtl. noch nicht korrekt konfiguriert nach attach)

    0
  • E
    Mod

    version = "0.0.3.142 - Rev: 1343"

    uhci.h/c: Erste erfolgreiche uhci usb 1.1 Transfers erfolgen, nun kann die Optimierung beginnen. 🙂

    0
  • M

    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_

    0
  • M

    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

    0
  • E
    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.

    0
  • E
    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).

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

    0
  • E
    Mod

    version = "0.0.3.147 - Rev: 1348"

    ipc.c und paging.c: Style Anpassungen

    0
  • E
    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.

    0
  • E
    Mod

    version = "0.0.3.149 - Rev: 1350"

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

    0
  • E
    Mod

    version = "0.0.3.150 - Rev: 1351"

    paging_getVirtAddr(uintptr_t physAddress) bezüglich Geschwindigkeit optimiert

    0
  • E
    Mod

    version = "0.0.3.151 - Rev: 1352"

    kheap.c: kleine Änderungen

    0
  • M

    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

    0
  • E
    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!)

    0
  • M

    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)

    0
Anmelden zum Antworten