On Thu, 26 Apr 2012, [ISO-8859-1] Miguel �gel �varez wrote: > >> CONFIG_USB_ARCH_HAS_HCD=y > >> CONFIG_USB_ARCH_HAS_OHCI=y > >> CONFIG_USB_ARCH_HAS_EHCI=y > >> CONFIG_USB=y > >> CONFIG_USB_DEVICEFS=y > >> CONFIG_USB_EHCI_HCD=y > >> CONFIG_USB_EHCI_ROOT_HUB_TT=y > >> CONFIG_USB_EHCI_FSL=y > >> CONFIG_USB_EHCI_HCD_PPC_OF=y > >> CONFIG_USB_STORAGE=y > > > > That combination of settings doesn't make sense. �If your EHCI root hub > > has a built-in TT then there's no reason to have an OHCI controller as > > well. �Are you sure that's what you want? > > > > I thought it was required to have an OHCI also... I will change the > configuration and test again. Wait, I misread this. Your extract has CONFIG_USB_ARCH_HAS_OHCI set, but not CONFIG_USB_OHCI_HCD. That's okay. Sorry for the noise. > >> I have also take a look to usbmon.txt and have obtained the following > >> traces with usbmon: > >> "dfbbdc80 199323393 C Ii:1:001:1 0:2048 1 = 02 > >> dfbbdc80 199323420 S Ii:1:001:1 -115:2048 4 < > >> df164500 199323575 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > >> df164500 199323601 C Ci:1:001:0 0 4 = 01010100 > >> df164500 199323657 S Co:1:001:0 s 23 01 0010 0001 0000 0 > >> df164500 199323663 C Co:1:001:0 0 0 > >> df164500 199323680 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > >> df164500 199323684 C Ci:1:001:0 0 4 = 01010000 > >> df164500 199355049 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > >> df164500 199355060 C Ci:1:001:0 0 4 = 01010000 > >> df164500 199387044 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > >> df164500 199387051 C Ci:1:001:0 0 4 = 01010000 > >> df164500 199419045 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > >> df164500 199419052 C Ci:1:001:0 0 4 = 01010000 > >> df164500 199451050 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > >> df164500 199451057 C Ci:1:001:0 0 4 = 01010000 > > > > The part above shows a normal connection and debounce. > > > >> df164500 199451088 S Co:1:001:0 s 23 03 0004 0001 0000 0 > >> df164500 199451092 C Co:1:001:0 0 0 > >> dfbbdc80 199506111 C Ii:1:001:1 0:2048 1 = 02 > >> dfbbdc80 199506118 S Ii:1:001:1 -115:2048 4 < > >> df164500 199507054 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > >> df164500 199507062 C Ci:1:001:0 0 4 = 03050000 > >> usb 1-1: new high speed USB device using fsl-ehci and address 2 > >> df164500 199647083 S Co:1:001:0 s 23 01 0014 0001 0000 0 > >> df164500 199647090 C Co:1:001:0 0 0 > > > > This shows a normal port reset. > > > >> df164500 199652801 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < > >> df164500 199656936 C Ci:1:000:0 -71 0 > >> df164500 199658438 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < > >> df164500 199662434 C Ci:1:000:0 -71 0 > >> df164500 199664958 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < > >> df164500 199668934 C Ci:1:000:0 -71 0 > > ... > > Is there any readable documentation that can help me in interpreting > the frames? I do not want to disturb you people if I can manage to do > it myself. Documentation/usb/usbmon.txt. To interpret the values you have to know the various codes standardized in the USB spec. I have attached a little cheat sheet which should help. > By the way... The Ci does not mean traffic from device to host? The 'C' stands for Control and the 'i' stands for IN, i.e., from the device IN to the host. > > If you can, you should attach a USB bus analyzer on the connection > > leading to the SSD to see whether it really is sending any response > > packets back to the computer. Or indeed, whether the computer's > > inquiries are getting sent over the USB connection to the drive in the > > first place. > > > > This should be the best way, of course. Any recommendations on USB bus > analyzers? The least expensive one I know of (still kind of pricy, though) is the Beagle USB 480 from Totalphase (www.totalphase.com). Alan Stern
Standard device requests RQtype Req Value Index Length ---------------------------------------------- 0 1 dev-feat 0 0 Clear device feature 0 3 dev-feat 0 0 Set device feature 0 5 address 0 0 Set device address 0 9 config-value 0 0 Set configuration 1 b altsetting intf 0 Set interface 1 1 intf-feat intf 0 Clear interface feature 1 3 intf-feat intf 0 Set interface feature 2 1 ep-feat ep 0 Clear endpoint feature 2 3 ep-feat ep 0 Set endpoint feature 80 0 0 0 2 Get device status 80 6 descr-type/ 0/ len Get descriptor index lang-ID 80 8 0 0 1 Get configuration 81 0 0 intf 2 Get interface status 81 a 0 intf 1 Get interface (altsetting) 82 0 0 ep 2 Get endpoint status Device features: 0 = self-powered, 1 = remote wakeup Interface features: None Endpoint features: 0 = halt Descriptor types: 1 = device, 2 = config, 3 = string, (4 = interface, 5 = endpoint), 6 = device qualifier, 7 = other-speed config Hub class requests RQtype Req Value Index Length ---------------------------------------------- 20 1 hub-feat 0 0 Clear hub feature 20 3 hub-feat 0 0 Set hub feature 23 1 port-feat sel/ 0 Clear port feature port 23 3 port-feat sel/ 0 Set port feature port a0 0 0 0 4 Get hub status a0 6 2900 0 len Get hub descriptor a3 0 0 port 4 Get port status Hub features: 0 = hub local power, 1 = hub over current, 10 = ch hub local power, 11 = ch hub over current Port features: 0 = connect, 1 = enable, 2 = suspend, 3 = over current, 4 = reset, 8 = power, 9 = low speed, a = high speed, b = test mode, c = indicator, 10 = ch connect, 11 = ch enable, 12 = ch suspend, 13 = ch over current, 14 = ch reset Selector is used for port indicators HID class requests RQtype Req Value Index Length ---------------------------------------------- 21 9 report-type/ID intf len Set report 21 a duration/ID intf 0 Set idle 21 b proto intf 0 Set protocol 81 6 descr-type/set intf len Get class descriptor a1 1 report-type/ID intf len Get report a1 2 0/ID intf 1 Get idle a1 3 0 intf 1 Get protocol Report type: 1 = input, 2 = output, 3 = feature Descriptor type: 21 = HID, 22 = Report, 23 = Physical Protocol: 0 = boot, 1 = report
