4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    Rev. 372:

    erweiterte Abfrage via USB2.0: device, config, interface, endpoints

    Test mit qemu:

    USB2: GET_DESCRIPTOR device, dev: 0 endpoint: 0                                 
12h 01h 00h 02h 00h 00h 00h 40h 00h 00h 00h 00h 00h 00h 01h 02h 03h 01h         
length:            18           descriptor type:   1                            
USB specification: 2.0          USB class:         0000h                        
USB subclass:      0000h        USB protocol       0000h                        
max packet size:   64           vendor:            0000h                        
product:           0000h        release number:    0.0                          
manufacturer:      0001h        product:           0002h                        
serial number:     0003h        number of config.: 1                            

USB2: GET_DESCRIPTOR config, dev: 0 endpoint: 0                                 
09h 02h 20h 00h 01h 01h 00h C0h 00h 09h 04h 00h 00h 02h 08h 06h 50h 00h 07h 05h 
81h 02h 40h 00h 00h 07h 05h 02h 02h 40h 00h 00h                                 
length:               9         descriptor type:      2                         
total length:         32        number of interfaces: 1                         
ID of config:         0001h     ID of config name     0000h                     
remote wakeup:        no        self-powered:         yes                       
max power (mA):       0                                                         

length:               9         descriptor type:      4                         
interface number:     0         alternate Setting:    0                         
number of endpoints:  2         interface class:      8                         
interface subclass:   6         interface protocol:   80                        
interface:            0000h                                                     

length:            7            descriptor type:   5                            
endpoint in/out:   in           endpoint number:   1                            
attributes:        02h          max packet size:   64                           
interval:          0                                                            

length:            7            descriptor type:   5                            
endpoint in/out:   out          endpoint number:   2                            
attributes:        02h          max packet size:   64                           
interval:          0

    Erläuterung: descriptor type
    1: device
    2: configuration
    3: string (oben noch nicht genutzt)
    4: interface
    5: endpoint

    Abfrage ist noch nicht variabel eingerichtet, klappt zur Zeit nur mit einem Interface und zwei Endpoints.

    Die Spezifikation ist hier am einfachsten erklärt: http://www.beyondlogic.org/usbnutshell/usb5.htm

    0
  • 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
Anmelden zum Antworten