4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    Rev. 373:

    port reset und USB-Transfer koordiniert

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

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

    0
  • T

    Wohl dem, der ein git hat.

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

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

    0
  • E
    Mod

    Rev. 376:

    nun auch mit SET_ADDRESS

    0
  • C

    Revision 377:

    * Maustreiber Fehlerbehebung (ACK wird jetzt erwartet)

    0
  • C

    Revision 378:

    * Fehler bei Maus ohne Mausrad behoben

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

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

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

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

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

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

    0
  • E
    Mod

    Rev. 384:

    siehe http://www.c-plusplus.net/forum/viewtopic-var-t-is-253016-and-start-is-67html

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

    0
  • M

    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 ...)

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

    0
  • E
    Mod

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

    auf einen QH reduziert

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

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

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

    0
Anmelden zum Antworten