4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    Version 0.0.4.61 - Rev: 1449

    xhci.c hinzugefügt (für xHCI, USB3).
    Erste Tests gelingen mit VMware Player (qemu 1.6 soll auch xHCI bieten).
    Eingehängt haben wir den xHCI bereits, nun muss er ordnungsgemäß aktiviert werden.

    ... USB xHCI CA520000h MMIO sz: 131072                                                            
XHCI_MMIO CA520000h mapped to virt addr C0003000h                               
--------------                                                                  
xHCI bar physical address: CA520000h                                            
HCIVERSION:  00.96                                                              
HCSPARAMS 1: 007F0400h  HCSPARAMS 2: 00000000h  HCSPARAMS 3: F2830000h          
Ports:       0                                                                  
HCCPARAMS: 08200388h                                                            
OpRegs Address: C0003020h

    Bei der xHCI-Konsole findet man noch "HC Halted", da wir noch nicht gestartet haben. 😉

    0
  • E
    Mod

    Version 0.0.4.62 - Rev: 1450
    xhci.c weiter ausgebaut bis zum Einschalten des Run/Stop Bits (allerdings noch mit vielen offenen TODO's, s. Kommentare).

    0
  • E
    Mod

    Version 0.0.4.63 - Rev: 1451
    xhci.c weiter ausgebaut: Command Ring, dequeue-/enqueue-Pointer, crcr

    Vielen Dank an Tobiking für die Unterstützung im Chat bezüglich des Verstehens und Umsetzens der xHCI spec.

    0
  • E
    Mod

    Version 0.0.4.64 - Rev: 1452

    xhci.h: TRB types (als #define)
    xhci.c: xhci_deactivateLegacySupport(x); //chapter 7.1

    0
  • M

    Version 0.0.4.65:

    - Kleine Ergänzugen im APIC-Code
    - Includes aufgeräumt
    - Userspace: puts gibt Anzahl geschriebener Zeichen zurück - ermöglicht Optimierung von vprintf

    0
  • E
    Mod

    Version 0.0.4.66 - Rev: 1454

    xhci.h/c: event ring / runtime regs aufgebaut

    Bitte in xhci.c austauschen, damit das Programm nicht in der for-Schleife hängen bleibt:

    //eventTRB
    for (uint16_t i=0; i<256; i++)
    0
  • E
    Mod

    Version 0.0.4.67 - Rev: 1455

    Verschiedene Fehler in xhci.c behoben

    0
  • J

    Version 0.0.4.68 - Revision 1456

    • userheap.c/h hinzugefuegt [userHeap_create, userHeap_alloc, userHeap_free]
    • Entsprechende syscalls fuer userHeap_create, userHeap_alloc, userHeap_free und userHeap_destroy hinzugefuegt (userHeapSc_xxx; vornehmlich Gueltigkeits-Checks)
    • malloc/free auf neue Syscalls umgebogen
    • HACK: start.asm erstellt beim Start einen initialen Prozess-Heap und exportiert ein entsprechendes Symbol, dass dann von malloc/free genutzt wird
    0
  • J

    Version 0.0.4.69 - Revision 1457

    • HACK entfernt -> Heap wird nur noch bei Bedarf = 1. Aufruf von malloc erstellt
    • userHeap_cleanUp wird nun in kill in tasking.c aufgerufen
    • Versehentliche Plenks durch switch( -> switch ( bei Funktionsaufrufen korrigiert
    0
  • E
    Mod

    Version 0.0.4.70 - Revision 1458

    usb3 Ports am xHC resettet/enabled und Status dargestellt.
    Funktioniert momentan nur bei bereits eingesteckten Devices.
    In VMware lässt sich dies hervorragend emulieren.

    0
  • E
    Mod

    Version 0.0.4.71 - Revision 1459

    xhxi.c: events (Versuche bisher nicht erfolgreich, MSI-X?)

    0
  • E
    Mod

    Version 0.0.4.72 - Revision 1460

    xhci.h: Fehler in den Lo-Adressen korrigiert

    0
  • E
    Mod

    Version 0.0.4.73 - Revision 1461

    xhci.c: verbessert zum Testen auf Port Status Change (CSC Bit, Connected Status)

    Testergebnisse von Tobiking:
    connected status, connected status change sowie enabled reagieren auf connect/disconnect einer usb3-HDD via VMware.
    Allerdings erscheint noch kein port status change event im event ring.

    0
  • E
    Mod

    Version 0.0.4.74 - Revision 1462

    xhci.c: Fehler korrigiert bei Eventring Table.
    (leider noch Addressfehler enthalten)

    EDIT: Kann nun selbst Hardwaretests durchführen dank usb3-PCIe-Karte im Testrechner.

    0
  • E
    Mod

    Version 0.0.4.75 - Revision 1463

    xhci.c: Adress-Fehler behoben.
    Hardware-Test: Nun werden Events angezeigt mit type 0x22 (TRB_EVENT_PORT_STS_CHANGE) 👍
    Zwei usb3-Sticks werden als connected erkannt und erhalten pro Stick zwei Events vom type 0x22.

    0
  • E
    Mod

    Version 0.0.4.76 - Revision 1464

    xhci.c: Ausgaben verfeinert, und CSC Bit wird nach Anzeige gelöscht. Jeder Übergang 0->1 ergibt ein Event. Ziehen/Stecken ergibt weitere Events.

    0
  • E
    Mod

    Version 0.0.4.77 - Revision 1465

    xhci.c: No Op Command bewirkt viele TRB_EVENT_CMD_COMPLETE und einen TRB_EVENT_HOST_CTRL. Damit ist der Command Ring ebenfalls funktionsfähig. 👍

    0
  • E
    Mod

    Version 0.0.4.78 - Revision 1466

    xhci.h/c: Completion Code (TRB error) ergänzt und ausgegeben. Event TRB Struktur verallgemeinert.

    0
  • E
    Mod

    Version 0.0.4.79 - Revision 1467

    xhci.c: Fehler bei Adressierung und Aufsetzen von TRBs im Command Ring behoben.

    OpReg crcr ist nicht lesbar, gibt immer 0 zurück. Daher ist dieses Register für die xHCI-Treiber Software unbrauchbar!

    Nun wird der enq-Ptr des Command Rings verwendet. Cycle Bit muss am Anfang auf 0, nicht 1! Nun klappt das beim Test-Command "No Op" sauber. Wir erhalten jeweils "Success". 👍

    Leider spielt Bochs und VMware noch nicht mit. In VMware kann man crcr z.B. zahlenmäßig auslesen, was eindeutig falsch ist (siehe spec)! Für die Entwicklung ist also lediglich reale Hardware brauchbar.

    Screenshot: http://henkessoft.de/Sonstiges/PrettyOS_xHCI.JPG

    Nächster Schritt: Cycle Bit der TRB im Command Ring gemäß Producer Cycle State (Startwert?) einstellen. Den Consumer Cycle State können wir nach Bit0 von OpReg crcr schreiben (momentan 0, Vorsicht: alles im crcr wird beim Lesen als 0 zurück gegeben! Daher werden z.Z. alle TRB mit c=0 (alle) gelesen.

    The Enqueue Pointer is managed by the producer and the Dequeue Pointer is managed by the consumer. The producer maintains a Producer Cycle State (PCS) flag which identifies the value that it shall write to the TRB Cycle bit. The consumer maintains a Consumer Cycle State (CCS) flag, which it compares to the Cycle bit in TRBs that it fetches. If the CCS flag is equal to the value of the TRB Cycle bit, then the consumer owns the TRB pointed to by the Dequeue Pointer and may process it. If they are not equal, then the consumer shall stop processing TRBs and wait for a notification of more work.

    Idee: Im nächsten Versuch wird daher in das hinter die drei No Op folgende TRB eine 1 (~PCS) - siehe Figur 14, xHCI spec - geschrieben, um den HC zu stoppen.

    Wahrscheinlich macht es mehr Sinn, PCS und CCS zu Beginn auf 1 (CCS: bit0 in crcr), zu setzen (siehe Figur 16 für den gesamten Ablauf incl. Link-TRB, xHCI spec). <== So wurde es nun umgesetzt in der nächsten Version!

    0
  • E
    Mod

    Version 0.0.4.80 - Revision 1468

    xhci.h/c: CmdRingProducerCycleState hinzugefügt und genutzt, damit der xHC am enqueue-Ptr stehen bleibt. Klappt hervorragend.

    Bochs kennt leider den No Op Command nicht ("Unknown trb type found: 23(dec)"). ^^

    0
Anmelden zum Antworten