EHCI flash drive behind hub times out

[sounds]

Short version:

I can read sectors from a flash drive using the BBB protocol, using real hardware. But if the flash drive is behind a hub, the communication breaks:

Code: Select all

Has ECP
BIOS owned
transfer to OS owned
BIOS released
CMD_HCRESET
HCRESET done
2 ports
CMD_RUN
HALT done
CONFIGFLAG = 1
sleep 10ms
All RH ports POWER + ENABLE
Go and enable XHCI
ASE
PSE
got +CONNECTION
set +RESET
clear RESET
get USB_DEVICE_DESCRIPTOR ok
set +RESET
clear RESET
get USB_DEVICE_DESCRIPTOR ok
get USB_CONFIG_DESCRIPTOR
set config 0
interface: class=9 hub
get USB_DEVICE_QUALIFIER ok
device bcdUSB=200
4 ports
set all hub ports +POWER
get hub port 2 status = +CONNECTION
set hub port 2 status = +RESET
interrupt hub port 2: cleared RESET
get hub port 2 status = CONNECTION|ENABLE|POWER|HIGHSPEED
send SETUP request: GET_DEVICE_DESCRIPTOR
wait 5 seconds
No changes in EHCI QUEUE HEAD

At this point, it fails with a "timed out" error. I've already extended the timeout to 5 seconds just in case. The drive is a samsung flash drive, USB 3.0, and works fine in linux.

What steps could I double check? I'm not really excited at the prospect of getting a protocol analyzer.

[BenLunt]

Hi,

What is the Hub? If the Hub is full-speed only, you have to treat the thumb-drive as full-speed only.
A device will only be as fast as the parent it is plugged into.

Also, if you are on an EHCI Host Controller, EHCI has additional fields for devices plugged into an external hub. Do you account for these fields?

No changes in EHCI QUEUE HEAD

Says you may be using an EHCI.

If you are on an xHCI Host Controller, it too has additional fields for devices plugged into an external hub.

Go and enable XHCI

Does this mean you are on an xHCI or an EHCI?

Both of these controllers have additional fields that must be accounted for when the device is downstream of an external hub.

Ben
- https://www.fysnet.net/the_universal_serial_bus.htm

[sounds]

What is the Hub? If the Hub is full-speed only, you have to treat the thumb-drive as full-speed only.
A device will only be as fast as the parent it is plugged into.

Thanks, Ben. It's a CablesToGo USB2.0 hub (according to the label). I'm getting a high speed connection to the root hub port when it detects the hub on startup. 480Mbps.

I double checked what linux thinks of the hub, and it matches what I was seeing:

Code: Select all

/sys/bus/usb/devices/3-11.4# ls -l
total 0
drwxr-xr-x 8 root root     0 Feb 26 20:33 3-11.4:1.0
drwxr-xr-x 5 root root     0 Feb 26 20:33 3-11.4.3
-rw-r--r-- 1 root root  4096 Feb 26 20:34 authorized
-rw-r--r-- 1 root root  4096 Feb 26 20:34 avoid_reset_quirk
-r--r--r-- 1 root root  4096 Feb 26 20:33 bcdDevice
-rw-r--r-- 1 root root  4096 Feb 26 20:34 bConfigurationValue
-r--r--r-- 1 root root  4096 Feb 26 20:33 bDeviceClass
-r--r--r-- 1 root root  4096 Feb 26 20:34 bDeviceProtocol
-r--r--r-- 1 root root  4096 Feb 26 20:34 bDeviceSubClass
-r--r--r-- 1 root root  4096 Feb 26 20:34 bmAttributes
-r--r--r-- 1 root root  4096 Feb 26 20:34 bMaxPacketSize0
-r--r--r-- 1 root root  4096 Feb 26 20:34 bMaxPower
-r--r--r-- 1 root root  4096 Feb 26 20:34 bNumConfigurations
-r--r--r-- 1 root root  4096 Feb 26 20:34 bNumInterfaces
-r--r--r-- 1 root root  4096 Feb 26 20:34 busnum
-r--r--r-- 1 root root  4096 Feb 26 20:34 configuration
-r--r--r-- 1 root root 65553 Feb 26 20:33 descriptors
-r--r--r-- 1 root root  4096 Feb 26 20:34 dev
-r--r--r-- 1 root root  4096 Feb 26 20:34 devnum
-r--r--r-- 1 root root  4096 Feb 26 20:34 devpath
lrwxrwxrwx 1 root root     0 Feb 26 20:33 driver -> ../../../../../../bus/usb/drivers/usb
drwxr-xr-x 3 root root     0 Feb 26 20:34 ep_00
-r--r--r-- 1 root root  4096 Feb 26 20:33 idProduct
-r--r--r-- 1 root root  4096 Feb 26 20:33 idVendor
-r--r--r-- 1 root root  4096 Feb 26 20:34 ltm_capable
-r--r--r-- 1 root root  4096 Feb 26 20:34 maxchild
lrwxrwxrwx 1 root root     0 Feb 26 20:34 port -> ../3-11:1.0/3-11-port4
drwxr-xr-x 2 root root     0 Feb 26 20:34 power
-r--r--r-- 1 root root  4096 Feb 26 20:34 quirks
-r--r--r-- 1 root root  4096 Feb 26 20:34 removable
--w------- 1 root root  4096 Feb 26 20:34 remove
-r--r--r-- 1 root root  4096 Feb 26 20:34 rx_lanes
-r--r--r-- 1 root root  4096 Feb 26 20:34 speed
lrwxrwxrwx 1 root root     0 Feb 26 20:33 subsystem -> ../../../../../../bus/usb
-r--r--r-- 1 root root  4096 Feb 26 20:34 tx_lanes
-rw-r--r-- 1 root root  4096 Feb 26 20:33 uevent
-r--r--r-- 1 root root  4096 Feb 26 20:34 urbnum
-r--r--r-- 1 root root  4096 Feb 26 20:34 version
/sys/bus/usb/devices/3-11.4# cat idVendor 
0409
/sys/bus/usb/devices/3-11.4# cat idProduct 
005a
/sys/bus/usb/devices/3-11.4# cat bcdDevice 
0100
/sys/bus/usb/devices/3-11.4# cat speed 
480
/sys/bus/usb/devices/3-11.4# cat bDeviceClass
09
/sys/bus/usb/devices/3-11.4# cat bDeviceSubClass 
00
/sys/bus/usb/devices/3-11.4# cat bDeviceProtocol
01

Also, if you are on an EHCI Host Controller, EHCI has additional fields for devices plugged into an external hub. Do you account for these fields?

Says you may be using an EHCI.

If you are on an xHCI Host Controller, it too has additional fields for devices plugged into an external hub.

My xhci code is incomplete. The last thing it does is complete the bios to os handoff.

Does this mean you are on an xHCI or an EHCI?

I think ehci. Which is supported logically because the xhci driver would never even see the hub, much less timeout on a device attached to it.

Both of these controllers have additional fields that must be accounted for when the device is downstream of an external hub.

Thank you, I am looking at this more carefully.

https://www.intel.com/content/dam/www/p ... or-usb.pdf section 3.6 figure 3-7 page 56/155 has the QUEUE HEAD spec.

These are the fields from figure 3-7, and I don't see any others: Port Number, and Hub Addr.

Figure 3-7 says "These fields are used exclusively to support split transactions to USB 2.0 Hubs" Also, Table 3-20 says:

Port Number. This field is ignored by the host controller unless the EPS field indicates a full- or low-speed device.

Hub Addr. This field is ignored by the host controller unless the EPS field indicates a full- or low-speed device.

I left them set to 0 (unless the device was a full or low speed device). Imagine how surprised I was now that I set them to their values unconditionally, and it doesn't time out anymore. I mean Port Number and Hub Addr for High Speed devices.

Now it halts...

Thank you again for suggesting I look at these fields.

[BenLunt]

Just a few comments:
- The hardware will report the speed of the device attached. You know it is a USB 3.0 (presumably*) a super-speed device. However, since the hub is (presumably*) a high-speed device, the thumb drive now must operate at no more than a high-speed device. What speed are you placing in the TD's? You must get the speed from the hardware, rather than presuming it is a super-speed device.
- Before you start to enumerate the thumb-drive, you have already given an address to the hub, correct?
- You must only reset/power one hub port at a time. If you reset/power more than one without first enumerating each port, you may have multiple devices trying to answer to address zero requests.
- Have you checked to see if the hub is always powered, or if you have to power it as a whole, or as individual ports. Remember that there is a wait time after power before you can start to send requests.

At the moment, that is all I can remember. It has been quite a few years since I actually worked with the EHCI. I will admit, personally, I like the EHCI the least. :-)

- Ben

* Note: Just because a device is USB 3.0, doesn't mean it is a super-speed device, as well as if it is a USB 2.0 device, doesn't indicate that it is a high-speed device. A device can be low-speed and still be USB 3.0 compliant. Also, a device can be super-speed and still be USB 1.1 compliant, though not doing much past a minimal enumeration.