Ziel: USB-Treiber
-
Mein aktueller Stand:
Es fehlt noch nen ganzes Stückchen, aber man sieht wie es funktionieren soll. CreateQH/CreateQTD erstellt eine recht generische Version, die dann in den spezifischen Funktionen wie die IN und OUT Varianten weiter manipuliert werden. Durch die übergebene Adresse werden die Einträge direkt an der richtigen Stelle erstellt. Am Ende müssen diese nur noch zusammen gehängt werden. Fehlen tun auf jeden Fall noch ein paar Parameter und die spezifische Funktion für SETUP Einträge. Das mit dem SETUP ist allerdings wieder etwas komplexer.
-
Echt toll!
Ich habe den aktuellen Stand als Zwischenschritt in Rev. 194 implementiert, damit sich da nichts auseinander entwickelt.
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1865696.html#1865696SETUP:
http://wiki.osdev.org/USB#USB_Device_Requests
http://lowlevel.brainsware.org/wiki/index.php/Universal_Serial_Bus#Setuppaket
USB 2.0 Spec: 5.3.1.1 Endpoint Zero Requirements, 9.4 Standard Device Requests, Table 9-4: Standard Request Codes, Table 11-14: Hub Responses to Standard Device Requests.Da gibt es das gesuchte SET_ADDRESS, damit wir von der 0 weg kommen.
-
Erhard Henkes schrieb:
Da gibt es das gesuchte SET_ADDRESS, damit wir von der 0 weg kommen.
Ja, nur bringt es im Moment nicht viel damit anzufangen, da man nicht überprüfen kann ob das ganze geklappt hat. Der erste Schritt ist daher erstmal das auslesen des Device Desciptor.
Ich hab das ganze nochmal umgebaut, und es sieht nun deutlich sinniger aus. Der QH beinhaltet jetzt einen kompletten QTD. Das elemeniert einiges an doppelten Code.
Der Test sollte eigentlich soweit vollständig sein. Funktionieren tut es allerdings nicht. Data ist nicht 18 wie es sein sollte und der Controller schaltet auf Halted. Das heißt jetzt erstmal Fehler suchen.
-
Ich habe es in Rev. 196 als Zwischenschritt eingespielt. Bei mir kommt immer 80h als Data zurück. Ich werde da mal an einigen Parametern drehen, mir sind beim Lesen der EHCI und USB 2.0 Specs einiges aufgefallen, was noch nicht passt bei uns.
-
Und der nächste neue Ansatz.
Meine komplette ehci.c. Ich hab die alten Funktionen und die Ausgaben komplett rausgeworfen. Die passten nicht mehr so richtig.
Hintergrund ist das ich die EHCI Spezifikation mal gezielt nach Schritten durchsucht habe, die von der Software durchgeführt werden müssen. Da habe ich in dem Abschnitt vor 4.10.1 folgendes gefunden:
For the very first use of a queue head, software may zero-out the queue head transfer overlay, then set the Next qTD Pointer field value to reference a valid qTD.
Das ist im Prinzip auch das was ich nun mache. Der Overlay Bereich wird genullt und nur der next pointer wird auf die Setup QTD gesetzt, dessen next pointer dann auf die In QTD zeigt. Also keinerlei queue heads außer dem ersten mehr.
Die qemu ehci Testversion läuft damit schon recht weit. An meinem Laptop kriege ich leider wieder Host System Error.
-
Der erste Erfolg! http://www.henkessoft.de/OS_Dev/Bilder/rev219a.jpg
die lang ersehnte 12h wurde mittels 80 06 00 01 00 00 12 00 (setup request) geholt. http://www.jungo.com/st/support/documentation/windriver/1002/wdusb_man_mhtml/node55.html#SECTION001221600000000000000Allerdings noch nicht stabil und schwierig reproduzierbar an anderen Stellen und Sims.
Das Problem liegt in resetPort(...) (<--- grausam). da müssen wir weiter machen. resetPort wird einmal vom initEHCI... udn einmal vom EHCI-Handler via ShowPortSC(...) aufgerufen, einmal mit sleep... und einmal mit diesem bescheuerten Zähler-Work-around. 
-
Geht übrigens auch mit qemu:
http://www.henkessoft.de/OS_Dev/Bilder/rev219qemu.jpgDas qemu erhält man hier: http://download.tyndur.org/temp/qemu-ehci.tgz
Skript:
qemu.exe -fda FloppyImage.bin -soundhw pcspk -localtime -usb -usbdevice disk:format=raw:dummy.binoder mit netzwerk
qemu.exe -fda FloppyImage.bin -soundhw pcspk -net nic,model=rtl8139,addr=1F,macaddr=00:12:12:12:12:12 -localtime -usb -usbdevice disk:format=raw:dummy.bin
-
... und nach einem Tipp von XanClic, dass VBox eine IRQ tiefer verwendet (also 10 anstelle 11 wie beim PCI festgestellt), nun auch VBox:
http://www.henkessoft.de/OS_Dev/Bilder/rev221VB.jpg (data: 12h)Also alles bestens.
-
Hier ein Test mit 2 QHs in der async. Liste, einer davon mit 3 QTD: http://www.henkessoft.de/OS_Dev/Bilder/rev268_asyncList.PNG (ab Rev. 268)
-
Nach dem Einbau des Multithreadings geht es langsam wieder weiter bei USB:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-254893-and-start-is-378.htmlAllerdings klappt es im EHCI-Bereich noch nicht sauber auf real PC.
-
Bei der Suche nach Problemen bezüglich Real PC und Simulationen bezüglich USB-Transfer sind wir bisher auf folgendes gestoßen:
-
Extended Buffer Pointer (64 Bit) bei QTD notwendig
-
PCI Command Register: Bus Mastering (Bit 2) muss gesetzt sein (real PC: das erledigt das BIOS bereits); VMWare: setzt dies nicht, USB läuft aber erst nach dem Setzen dieses Bits
-
PCI Capabilities List: hier ist unklar, ob dies eine Bedeutung für EHCI hat?!
Hier eine Auswertung:
**
PCI Capabilities List: first Pointer: 0050h
PCI Capabilities List: ID: 01h, next Pointer: 00h**
PrettyOS [Version 0.0.0.384] Console 0: EHCI -------------------------------------------------------------------------------- >>> >>> function: initEHCIHostController PCI Command Register before: 0106h PCI Command Register plus bus master: 0106h PCI Capabilities List: first Pointer: 0050h PCI Capabilities List: ID: 01h, next Pointer: 00h >>> >>> function: startHostController (reset HC) DeactivateLegacySupport: eecp = 0070h eecp = 0070h, eecp_id = 0001h BIOS did not own the EHCI. No action needed. >>> >>> function: enablePorts >>> >>> function: resetPort 1 >>> >>> function: resetPort 2 >>> >>> function: resetPort 3 >>> >>> function: resetPort 4 >>> >>> function: resetPort 5 >>> >>> function: resetPort 6 >>> Press key to close this console. <<< -------------------------------------------------------------------------------- Saturday, April 19, 2064, 19:13:42 51 s runtime. CPU: 1121 MHz /Zugehöriger Code in ehci.c:
uint16_t pciCapabilitiesList = pci_config_read(bus, dev, func, 0x0234); printf("\nPCI Capabilities List: first Pointer: %x", pciCapabilitiesList); if (pciCapabilitiesList) // pointer != NULL { uint16_t nextCapability = pci_config_read(bus, dev, func, 0x0200 | pciCapabilitiesList); printf("\nPCI Capabilities List: ID: %y, next Pointer: %y",BYTE1(nextCapability),BYTE2(nextCapability)); while (BYTE2(nextCapability)) // pointer != NULL { nextCapability = pci_config_read(bus, dev, func, 0x0200 | BYTE2(nextCapability)); printf("\nPCI Capabilities List: ID: %y, next Pointer: %y",BYTE1(nextCapability),BYTE2(nextCapability)); } }Die Bedeutungen der IDs sind in Anhang H der PCI Local Bus Specification beschrieben:
Die ID=1 von obigem PC bedeutet:
PCI Power Management Interface – This capability structure provides a standard interface to control power management features in a PCI device. ...
Hier ein Beispiel eines PC, der mit Host System Error reagiert:**
PCI Capabilities List: first Pointer: 0050h
PCI Capabilities List: ID: 01h, next Pointer: 58h
PCI Capabilities List: ID: 0Ah, next Pointer: 00h**PrettyOS [Version 0.0.0.384] Console 0: EHCI -------------------------------------------------------------------------------- >>> >>> function: initEHCIHostController PCI Command Register before: 0006h PCI Command Register plus bus master: 0006h PCI Capabilities List: first Pointer: 0050h PCI Capabilities List: ID: 01h, next Pointer: 58h PCI Capabilities List: ID: 0Ah, next Pointer: 00h >>> >>> function: startHostController (reset HC)waiting for HC reset DeactivateLegacySupport: eecp = 0068h eecp = 0068h, eecp_id = 0001h set OS-Semaphore. BIOS-Semaphore being not set. OS-Semaphore being set. Check: BIOSownedSemaphore: 0 OSownedSemaphore: 1 ehci_handler: Port Change >>> >>> function: enablePorts >>> >>> function: resetPort 1 Port 1: high speed enabled, device attached >>> Press key to start USB-Test. <<<ID 0x0A bedeuetet: Debug Port Capability (siehe EHCI spec, Appendix C. Debug Port)
-
-
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1885822.html#1885822
Die Ursache für den hartnäckigen Host System Error ist gefunden.
Er liegt im USB-Transfer begraben (hält am H-Bit nicht an).
-
Ein Meilenstein erreicht:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-254893-and-start-is-423.html
LBA 0 von einem USB-Stick auf einem real PC korrekt mit read(10) ausgelesen. Version ist allerdings noch nicht stabil (klappt nur bei wenigen Konstellationen), aber das Ziel ist in Sicht, nun ist wieder die übliche Fleißarbeit angesagt.
-
Leider immer noch nicht stabil. Konstruktive Unterstützung erwünscht.
siehe: http://www.c-plusplus.net/forum/viewtopic-var-p-is-1891501.html#1891501
Ich würde dies geren verallgemeinern, finde aber den Hebel dazu einfach nicht. Die community ist noch nicht schlagkräftig genug, das schnell zu lösen. Bei tatkräftiger Unterstützung Belohnung (Fachbuch aus meiner breiten Sammlung) nicht ausgeschlossen.Wir benötigen Unterstützung im Bereich USB, damit wir rascher voran kommen. Die Floppy hat ausgedient, es leben die USB Mass Storage Devices.
-
tatOS verwendet usb MSD, alles in Assembler.
Hier ein sehr interessanter Kommentar zur Abfolge der SCSI commands nach dem Setzen der Konfiguration:
;now we start on the SCSI commands ;the order of the commands and redundancy is important ;we init the flash toggles here and then let prepareTDchain touch them only mov dword [bulktogglein] ,0 mov dword [bulktoggleout],0 STDCALL mpdstr18,putmessage call Inquiry STDCALL mpdstr19,putmessage call TestUnitReady STDCALL mpdstr20,putmessage call RequestSense STDCALL mpdstr19,putmessage call TestUnitReady STDCALL mpdstr20,putmessage call RequestSense STDCALL mpdstr21,putmessage call ReadCapacity ;done-ready for read10/write10
-
Mit Rev. 441 ff. gelingt der Ablauf endlich auch auf real PC. Versuche zeigen jedoch, dass der Ablauf am IN-endpoint noch nicht ausreichend stabil ist. Daher muss nun eine Optimierung des async Schedulers statt finden und Fehlerbehandlungen eingebaut werden. Wir suchen zu diesem Thema noch Mitstreiter, die sich mit EHCI/USB/SCSI auskennen.
-
Bei Apples Xcode ist ein Tool mitgeliefert, nennt sich 'USB Prober', welches ziemlich interessant ist. Ich habe einfach mal einen Screenshot gemacht und die Ausgabe dazukopiert. Zu finden ist das genze hier:
http://prettyos.fanofblitzbasic.de/USB/
Vllt hilft euch das irgendwie.
Cuervo
-
Rev. 452 bereinigt wichtige Fehlerquellen im bulk-Transfer (überflüssiger und damit sogar schädlicher handshake seitens OS, nicht abwechselndes Togglen pro bulk-endpoint)
-
Diese für USB Mass Storage Devices interessante WebPage von Jan Axelson dokumentiere ich hier, bevor sie verschwindet:
http://www.lvr.com/device_errors.htm
USB Mass Storage Device Problems
These are reported problems with various USB mass-storage devices. If you're developing device firmware, check this list for common problems to avoid. If you're developing host software, check this list for problems you may need to work around. Thanks to the Usb-storage e-mail list for many of these. Additions, corrections, and suggestions welcome via
Descriptor Problems
The device’s bInterfaceSubClass is FFh instead of 06h or another value defined by the USB mass-storage specifications.
The device’s bInterfaceProtocol is invalid (should be 50h for bulk-only transport).
The device has no serial number or the serial number has invalid characters as defined in the bulk-only transport specification.
Multiple devices with the same Vendor ID and Product ID have the same serial number.
Different device or firmware revisions have the same bcdDevice value.
Control Transfer Problems
A device with multiple LUNs doesn’t implement the Get Max LUN request.
When the endpoint isn’t halted, receiving a Clear Feature (ENDPOINT_HALT) request for the endpoint causes the device to crash.
On receiving a Clear Feature (ENDPOINT_HALT) request followed by a Get Status (ENDPOINT) request, the device crashes.
The device doesn’t implement the Bulk-only Mass Storage Reset request properly. To work around this failure, a host might need to issue a Set Port Feature (PORT_RESET) request to the device’s hub port.
On receiving a Set Interface request, the device doesn’t reset the data toggles for the bulk endpoints.
General Problems with Commands
The device has a single LUN but responds to commands for any LUN.
The signature in the CSW is incorrect.
The device returns no data or incorrect data in the dCSWDataResidue field.
The data-transport phase fails unless there is a delay of up to 120 msecs. between the end of the command-transport phase and the beginning of the data-transport phase.
After completing enumeration, the device requires a few seconds before it responds properly to received CBWs.
In commands where the device may return variable-length data in the data-transport phase, after returning all available data but less than the requested amount of data, the device returns 01h (failed) in the bCSWStatus field of the CSW.
The device can only do transfers of 32 KB, or can only do transfers of 32 KB or less, or returns invalid dCSWDataResidue data in the CSW for transfers greater than 32 KB.
Problems with Specific SCSI Commands
Specific commands challenge some devices.
INQUIRY
The device crashes if the ALLOCATION LENGTH parameter doesn’t equal 36.
The device returns an incorrect value in the VERSION field (byte 2). See the SPC specification or other relevant command-set documents for the correct values for your device.
The device returns 05h (SPC-3) in the VERSION field but the device doesn’t support the REPORT LUNS command (mandatory for SPC-3).
The device returns an incorrect value in the ADDITIONAL LENGTH parameter.
When a UNIT ATTENTION condition exists, the device fails the command and returns a sense key of UNIT ATTENTION. (The device should perform the command and should not report or clear the UNIT ATTENTION condition.)
MODE SENSE
The device crashes if the ALLOCATION LENGTH parameter doesn’t equal 192.
When the PAGE CODE parameter equals 3Fh (Return all subpage 00h mode pages in page_0 format), the device crashes.
The device doesn’t implement all mode pages required by relevant specifications.
The device doesn’t implement all mandatory versions of the command. Read/write devices that are bootable and that don’t have a PDT of 05h (CD/DVD drive) must support MODE SENSE(10).
PREVENT ALLOW MEDIUM REMOVAL
On receiving the command, the device stops functioning or behaves as if the storage media is removed even if it isn’t.
READ
The device doesn’t implement all mandatory versions of the command. Devices that comply with SBC-2 or SBC-3 should implement both READ(6) and READ(10).
READ CAPACITY
The LOGICAL BLOCK ADDRESS field contains an incorrect value (the correct value + 1) because the device is reporting the number of sectors rather than the LBA of the highest sector.
REQUEST SENSE
In devices with removable media, when the media changes, the device doesn’t set the SENSE KEY to 06h (UNIT ATTENTION) to indicate the change (required by SBC-2 and SBC-3).
START STOP UNIT
On receiving the command, the device crashes.
WRITE
The device doesn’t implement all mandatory versions of the command. Writable devices that comply with SBC-2 or SBC-3 should implement both WRITE(6) and WRITE(10).
siehe auch: http://www2.one-eyed-alien.net/~mdharm/linux-usb/target_offenses.txt
-
In http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/usb/scsa2usb/usb_ms_bulkonly.c findet man folgende Handlungsanweisung:
/* * scsa2usb_bulk_only_transport: * Implements the BO state machine by these steps: * a) Issues CBW to a Bulk Only device. * b) Start Data Phase if applicable * c) Start Status Phase * * returns TRAN_* values * * scsa2usb_bulk_only_state_machine: * * scsa2usb_bulk_only_transport() handles the normal transitions or * continuation after clearing stalls or error recovery. * * Command Phase: * prepare a valid CBW and transport it on bulk-out pipe * if error on bulkout: * set pkt_reason to CMD_TRAN_ERR * new pkt state is SCSA2USB_PKT_DO_COMP * reset recovery synchronously * else * proceed to data phase * * Data Phase: * if data in: * setup data in on bulkin * else if data out: * setup data out on bulkout * * data: (in) * copy data transferred so far, no more data to transfer * * if stall on bulkin pipe * terminate data transfers, set cmd_done * clear stall on bulkin syncrhonously * else if other exception * set pkt_reason to CMD_TRAN_ERR * new pkt state is SCSA2USB_PKT_DO_COMP * reset recovery syncrhonously * else (no error) * receive status * * data: (out) * if stall on bulkout pipe * terminate data transfers, set cmd_done * clear stall on bulkout synchronously USBA * else if other exception * set pkt_reason to CMD_TRAN_ERR * new pkt state is SCSA2USB_PKT_DO_COMP * reset recovery synchronously * else (no error) * receive status * * Status Phase: * * if stall (first attempt) * new pkt state is SCSA2USB_PKT_PROCESS_CSW * setup receiving status on bulkin * if stall (second attempt) * new pkt state is SCSA2USB_PKT_DO_COMP * reset recovery synchronously, we are hosed. * else * goto check CSW * else * goto check CSW * * check CSW: * - check length equals 13, signature, and matching tag * - check status is less than or equal to 2 * - check residue is less than or equal to data length * adjust residue based on if we got valid data * * if not OK * new pkt state is SCSA2USB_PKT_DO_COMP * set pkt reason CMD_TRAN_ERR * reset recovery synchronously, we are hosed * else if phase error * new pkt state is SCSA2USB_PKT_DO_COMP * set pkt reason CMD_TRAN_ERR * reset recovery synchronously * else if (status < 2) * if status is equal to 1 * set check condition * if residue * calculate residue from data xferred and DataResidue * * set pkt_residue * goto SCSA2USB_PKT_DO_COMP * * The reset recovery walks sequentially thru device reset, clearing * stalls and pipe resets. When the reset recovery completes we return * to the taskq thread. * * Clearing stalls clears the stall condition, resets the pipe, and * then returns to the transport. */Hinweis: "we are hosed" ---> http://forum.wordreference.com/showthread.php?t=1115999
Dieses schrittweise Vorgehen beim bulk-only-Transfer - vor allem mit der entsprechenden Fehlerbehandlung - fehlt uns noch, wird nun step-by-step umgesetzt.
Ab Rev. 460 wurde eine Struktur hinzugefügt, mit der man bulk Transfers bezüglich command-, data, status-Phase verfolgen kann, um auf Fehler angemessen zu reagieren und den erfolgreichen Verlauf festhalten zu können.
