4. Sourcecode Fortschritt

Sourcecode Fortschritt

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

    Version 0.0.4.81 - Revision 1469

    xhci.h: ergänzt um weitere Strukturen
    xhci.c: device context array begonnen und TRB_TYPE_ENABLE_SLOT gesendet (darauf reagiert Bochs normal).

    0
  • E
    Mod

    Version 0.0.4.82 - Revision 1470

    xhci.h/c: ptr vereinfacht, allgem. Funktionen beim cmd-ring geschaffen

    0
  • E
    Mod

    version = "0.0.4.83 - Rev: 1471"

    xhci.h/c: weitere kleine Verbesserungen

    Leider kann der Interrupt noch nicht eingeschaltet werden (Uhrzeit bleibt bei Hardware stehen), daher lassen wir die Interrupter noch ausgeschaltet:

    x->RuntimeRegs->IRS[0].IE = 0; // 1: interrupter can generate an interrupt, 0: generating interrupts is prohibited (5.5.2.1, Table 43)
    0
  • E
    Mod

    version = "0.0.4.84 - Rev: 1472"

    xhci.c: Eventausgabe etwas überarbeitet, jetzt auch testweise einmal direkt in Konsole, einmal in eigener Konsole (Test wegen Handler)

    Interessanterweise kann man nun in bochs den Interrupt einschalten: 🙂
    xhci.c, Zeile 278:

    x->RuntimeRegs->IRS[0].IE = 1; // 1: interrupter can generate an interrupt, 0: generating interrupts is prohibited (5.5.2.1, Table 43)

    Bei Hardware bei meinem Test-PC leider störendes Dauerfeuer auf den Handler (Ursache nicht klar), das alles lahm legt. 🙄

    0
  • E
    Mod

    version = "0.0.4.85 - Rev: 1473"

    apic.h/c weiter entwickelt. Wirkung von APIC wurde im Nachgang von MrX durch Ausschalten des PIC ( http://wiki.osdev.org/PIC#Disabling ) gezeigt. Der APIC-Timer im Local APIC sendet periodische Interrupts. Nun fehlt noch die Programmierung des IO APIC
    ( http://www.lowlevel.eu/wiki/I/O_Advanced_Programmable_Interrupt_Controller ).

    0
  • M

    Version 0.0.4.86

    - Local-APIC-Treiber weiter verbessert: Timer-Interrupts funktieren nun
    -- PIC- und IDT-Code besser von einander getrennt
    -- Testweise handler auf APIC-Timer-Interrupt (no. 0x2F==47)
    -- EOI für APIC ausgeführt
    - Codestil verbessert

    0
  • E
    Mod

    Wer die Version 0.0.4.86 ausprobieren möchte:
    in os.h:

    /// #define _BOOTSCREEN_         // Enables the bootscreen displayed at startup
#define _SERIAL_LOG_         // Enables log information over the COM-Ports
/// #define _EHCI_ENABLE_        // EHCI driver will be installed and used on the disadvantage of UHCI/OHCI if supported by the attached device
/// #define _OHCI_ENABLE_        // OHCI driver will be installed
/// #define _UHCI_ENABLE_        // UHCI driver will be installed
/// #define _XHCI_ENABLE_        // xHCI driver will be installed

    in ckernel.c:

    if (apic_available())
        log("APIC", apic_install())
    else // PIC as fallback // Use APIC+PIC until our APIC driver is ready to replace PIC
        simpleLog("PIC", pic_install()); // Cf. interrupts.asm

    Testen kann man am besten mit VBox oder qemu. VMware bringt die 't' etwas langsamer. Bochs verbeisst sich in die FDD und bleibt nach einem 't' hängen.

    Dies ist ein unkalibrierter timer interrupt des neu eingerichtenen local APIC.

    idt_install wird übrigens am Ende von isr_install ausgeführt.

    0
  • E
    Mod

    version = "0.0.4.87 - Rev: 1475"

    apic.h/c zwischenstand (läuft noch nicht korrekt!)

    0
  • E
    Mod

    version = "0.0.4.88 - Rev: 1476"

    apic.h/c: APIC timer mittels PIT justiert.

    Tests: Test-PC und VMware laufen zeitgenau. xHCI in os.h ausgeschaltet, da es bei VMware dabei massive Probleme gibt. Qemu läuft etwas zu schnell. Bochs stürzt ab (exception). VBox läuft sehr langsam.

    0
  • M

    Version 0.0.4.89:

    - Fehler behoben: Crash bei Read-Only-Sektionen in PE/ELF-Dateien
    - Interrupt-Code aufgeräumt: Weniger redundanter Code, alle 256 Interrupts nun benutzbar
    - Ein paar unnötige memset entfernt
    - bochs.bxrc repariert (reverted)
    - APIC-Code stilistisch aufgeräumt

    0
  • M

    Version 0.0.4.90:

    - Compilerfehler bei aktivierten DIAGNOSIS-Modi behoben
    - _SERIAL_LOG_ standardmäßig deaktiviert (ist eine Debug-Option)
    - Neue Testergebnislisten

    0
  • E
    Mod

    version = "0.0.4.91 - Rev: 1479"

    pit.h, apic.c: kleine Ergänzungen
    Init IO APIC vor local APIC

    0
  • M

    Version 0.0.4.92:

    - textgui und VBEShell entfernt
    - const-correctness erhöht
    - VM86-Handler um Befehlsvarianten erweitert
    - Optimierungen in VGA-Treiber und vsnprintf
    - VBE-Debugausgabe (via strg+v)

    0
  • M

    Version 0.0.4.93:

    - initrd (initrd.c/h, make_initrd) und angehängtes vfs (fs.h/c) gelöscht
    - Neue Ramdisk-Implementation begonnen
    - Shell nun direkt in kernel eingebunden, ohne Ramdisk-Wrapper

    0
  • E
    Mod

    version = "0.0.4.94 - Rev: 1482"

    ESC+p (paging_analyzeBitTable) korrigiert (schreibt nun korrekt auf den Bildschirm und auf den in os.h angegebenen seriellen Port)

    0
  • E
    Mod

    "0.0.4.95 - Rev: 1483"

    apic.c weiter optimiert (vmware, test-pc laufen; qemu, Vbox, bochs nicht bzw. nicht korrekt)

    0
Anmelden zum Antworten