Sourcecode Fortschritt


  • Mod

    Rev. 373:

    port reset und USB-Transfer koordiniert


  • Mod

    Rev. 374:

    TEST für ehci/usb2: nur zwischenschritt, um Host System Error auf real Hardware zu überwinden (noch re-init notwendig)

    in ehci.c:
    zeile 16-18:

    /// TEST
    const uint8_t PORTRESET = 3; /// TEST: only one port is reset!!! PORTRESET+1 is the indicated port
    /// TEST
    

  • Mod

    Unser SVN bei source forge ist an diesem Wochenende down. 😮



  • Wohl dem, der ein git hat.

    Dann müsst ihr jetzt wohl ein Wochenende lang an tyndur basteln und euch dort Ideen holen. 😉


  • Mod

    Rev. 375:

    TEST für ehci/usb2: nur zwischenschritt, um Host System Error bei mancher real Hardware zu überwinden (extended bei qtd eingefügt);

    nur ein port, z.B. 7 (angezeigt 8), kann leicht umgestellt werden.

    Zeile 16-19: ehci.c

    /// TEST
    //const uint8_t PORTRESET = 7; /// TEST: only one port is reset!!! PORTRESET+1 is the indicated port
    #define PORTRESET j
    /// TEST
    

    @taljeth: danke für das nette Angebot. Wir holen uns gerne Ideen, nicht nur von týndur. Aber am liebsten basteln wir an unserem OS weiter. 🙂

    Das kann sich aber noch ändern. Vor uns ist nichts sicher. 😃


  • Mod

    Rev. 376:

    nun auch mit SET_ADDRESS



  • Revision 377:

    * Maustreiber Fehlerbehebung (ACK wird jetzt erwartet)



  • Revision 378:

    * Fehler bei Maus ohne Mausrad behoben

    (EDIT: verdammt, kein neues Image hochgeladen..-.-)


  • Mod

    Rev. 379:

    nun läuft das mit SET_ADDRESS zumindest in qemu EHCI
    --> nur noch QTD_SETUP und QTD_IO

    zu qemu: ist aber Blödsinn, wenn das bei qemu mit nicht angeschlossenem Gerät klappt, daher Umbau auf reale Verhältnisse in rev. 380


  • Mod

    Rev. 380:

    - jetzt nur bei attached device (also 0x1005), klappte bei einem ersten real PC Test noch nicht

    Tests mit real PC:
    anschließend noch mit device 0 getestet, ob SET_ADDRESS überhaupt geklappt hat:
    brachte auch nur Nullen, das Adresse setzen könnte also auch dort geklappt haben! 🙂


  • Mod

    Rev. 381:

    PCI Command Register, Bit 2 (Bus Master) zusätzlich gesetzt

    // pci bus data
    	uint32_t num = ODA.pciEHCInumber;
    	uint8_t bus  = pciDev_Array[num].bus;
        uint8_t dev  = pciDev_Array[num].device;
        uint8_t func = pciDev_Array[num].func;
    	uint8_t irq  = pciDev_Array[num].irq;
    	// prepare PCI command register // offset 0x04
    	// bit 9 (0x0200): Fast Back-to-Back Enable // not necessary
        // bit 2 (0x0004): Bus Master               // cf. http://forum.osdev.org/viewtopic.php?f=1&t=20255&start=0
    	uint16_t pciCommandRegister = pci_config_read(bus, dev, func, 0x0204);
    	printf("\nPCI Command Register before:          %x", pciCommandRegister);
    	pci_config_write_dword(bus, dev, func, 0x04, pciCommandRegister /*already set*/ | 1<<2 /* bus master */); // resets status register, sets command register 
        printf("\nPCI Command Register plus bus master: %x", pci_config_read(bus, dev, func, 0x0204));
    
        irq_install_handler(32 + irq,   ehci_handler);
        /// irq_install_handler(32 + irq-1, ehci_handler); /// work-around for VirtualBox Bug!
    

    Tobiking und Cuervo haben schon vollständige Transfers (set_address, device 18 byte, config 9+9+7+7 byte) gesehen, allerdings erst beim zweiten Hochfahren. Bei mir blieb es stabil negativ auf einem Test-PC.

    Ob und inweiweit die sogenannten PCI Capabilities List (angezeigt beo 0x34) eine Rolle spielen, ist mir unklar.

    capabilities list: 0x50
    eecp: 0x68 (das haben wir zum BIOS/OS-Umschalten verwendet)

    Weiß jemand mehr über diese "pci capabilities list" bei EHCI (unterhalb eecp)?


  • Mod

    Rev. 382:

    code review usb.c

    TODO:
    - abwarten bis Transfer wirklich beendet (USB-Status abfragen)
    - array anlegen für adressen/infos von usb-devices
    - neue Adresse vergeben: erste frei Adresse verwenden


  • Mod

    Rev. 383:

    Testvariante für USB_Transfer bezüglich dem ersten TODO topic (s. Rev. 382):

    1. Adresse ändern
    2. device abfragen
    3. config abfragen (statisch aufgebaut: 1 interface mit 2 endpoints)

    Technik für warten:
    USBINT (wird gesetzt bei complete transfer) setzt USBINTflag, erst dann weiter (mit timeout).

    Nach SET_ADDRESS wird 1 sec gewartet (war nicht sicher, ob da STS_USBINT überhaupt kommt, da kein Datentransfer)

    Nun sieht man, wie lange der erfolgreiche Transfer dauert (#-zeichen * 20 ms)


  • Mod


  • Mod

    Rev. 385: (ohne FloppyImage.img, weil SVN das nicht wollte)

    jetzt auch SET_ADDRESS mit abwarten auf STS_USBINT

    hier der Host Sytem Error bei meinem Development PC:

    PrettyOS [Version 0.0.0.385]                               Console 1: EHCI Ports
    --------------------------------------------------------------------------------
    
    >>> >>> function: resetPort 4                                                   
    
    >>> Status of USB Ports <<<                                                     
    port 4: 00001005h, line: 00h  SE0,power on, enabled, EHCI owned                 
    >>> Press key to start USB-Test. <<<                                            
    
    USB2: SET_ADDRESS                                                               
    Reset STS_USBINT and enable Async Schedule                                      
    .#                                                                              
    SETUP:                                                                          
    QTD: C0217000h Statusbyte: 00h                                                  
    
    USB2: GET_DESCRIPTOR device, dev: 4 endpoint: 0                                 
    
    ehci_handler: Host System Error                                                 
    PCI status word: 2290h                                                          
    Capabilities List                                                               
    Fast Back-to-Back Transactions Capable                                          
    Received Master-Abort                                                           
    
    >>> Init EHCI after fatal error:           <<<                                  
    >>> Press key for EHCI (re)initialization. <<<
    

    Man sieht aber, dass der SET_ADDRESS sauber durchgeht:

    USB2: SET_ADDRESS
    Reset STS_USBINT and enable Async Schedule
    .#
    SETUP:
    QTD: C0217000h Statusbyte: 00h

    Der Punkt stammt vom interrupt, der das USBINTflag setzt, und nach 20 ms (ein 😵 ist der USB-Transfer erledigt.

    Der nachfolgende pci master abort error bei GET_DESCRIPTOR device sollte von einem fehlerhaften Speicherzugriff herrühren. Ursache unklar. Wir sind für jeden Hinweis dankbar, da dieses Problem die Weiterentwicklung der EHCI/USB2-Treiber im Hardwarebereich behindert. Bei Qemu, VMWare und VBox kein Problem.

    Wie sieht das bei Cuervo und Tobiking aus? Auch dieses 0Ah?
    PCI Capabilities List: first Pointer: 0050h
    PCI Capabilities List: ID: 01h, next Pointer: 58h
    PCI Capabilities List: ID: 0Ah, next Pointer: 00h



  • Revision 386:

    - Definition von bool in userlib.h nun identisch zu types.h
    - user_program_c heißt nun shell
    - kdebug nun als inline-fkt. mit Farb-Funktionalität
    - Aufräumarbeiten (u.a. rtl8139.c ...)


  • Mod

    Rev. 387:

    page in createQTD_...:

    void* data = malloc(PAGESIZE, PAGESIZE); // Enough for a full page
        memset(data,0,PAGESIZE);
    

    vorsichtshalber, sollte aber tokenBytes reichen


  • Mod

    Rev. 388: (versehentlich 387 in ckernel.c)

    auf einen QH reduziert

    bleibt die async. List stehen? das ist die frage. 😃


  • Mod

    Rev. 389:

    Asynchrone Liste wird nach USB-Transfer im USBCMD ausgeschaltet, da das H-Bit offenbar noch unzuverlässig arbeitet.

    pOpRegs->USBCMD &= ~CMD_ASYNCH_ENABLE;
    

    Bitte testen.
    EDIT: sieht sehr gut aus (positive Tests bei Cuervo, Tobiking, Erhard Henkes)! Ursache gefunden, wenn auch noch nicht verstanden. 😉

    Wir haben festgestellt, dass die asynchrone Liste einfach das H-Bit ignoriert im QH und weiter läuft. Beim nächsten Transfer haben wir dann dem laufenden Asynchronen Scheduler die Basisadresse weg gezogen. 😃

    Von nun an können wir uns hoffentlich auf USB 2.0 konzentrieren. 🙂


  • Mod

    Rev. 390:

    ehci.h/c u. usb.c: Umbenennungen und ein Ausgabefehler (Rev. 389: ein Statusbyte ausgewiesen, dass es gar nicht gibt) beseitigt

    Jetzt sieht das alles gut aus.


Anmelden zum Antworten