OSDev.org

Hey everyone,
Hope youre all well.

I have a question purtaining to devices on (external) EHCI hubs (specifically in my case, the good ol' Intel Rate Matching Hub).

Ive got a really thin driver working (high speed msd and hub devices only), and can enumerate and communicate with the aforementioned classes of device if they are plugged into the root hub of an EHCI bus. However, im having trouble getting the driver working with devices on hubs, specifically detecting devices on hubs and then communicating with them.

I get the principle that once the port the device is in is reset the device appears on the bus with address 0 and we have to set it into the address and then configured state as normal.
However, I can barely get the configuration descriptors from msd devices attached to the Hub. Ive tried quite a bit to get this working and its starting to really annoy me, especially since this is being tested on real hardware without a protocol analyser (I use Bochs usually and it seems that Bochs doesnt have a high speed hub device. Perhaps I should look into qemu).

Anyway the current procedure is (in a poor and painful way, attempting to emulate a certain Microsoft blogpost on their EHCI enumeration procedure), as follows:

After powering the port and waiting 2*Power Good, I reset the port, pause for a long delay before clearing the reset, then pausing again before requesting the Config descriptor on address zero (which also fails 9/10 times on the first try, thereby entering a loop of resetting the port and requesting ithe configuration descriptor up to 10 times), after which I might get lucky and get the config descriptor (I should add, the Hub Port ALWAYS successfully returns that ive got a High speed device). However, afterwards, setting the address and all subsequent commands seems to always fail.
Fairly bloody annoying.

But alas, my main question is, does anyone have a sort of checklist of steps they take in those inital steps of their EHCI external hub enumeration procedure (including any delays, bits to poll etc) that they wouldnt mind sharing? Or any advice/help if ive misunderstood something. Ive been scouring over the documentation for a while now, but alongside my degree and work, its been a bit of a hassle and im sure ive missed something.

Thanks anyhoos.

Hi,

First, an external hub has nothing to do with the EHCI. EHCI is the host-side controller. An external hub does not comply to the EHCI specs. An external hub can be USB 1.1, USB 2.0, USB 3.0, etc., compliant.

Anyway, just a few questions/comments?
1) are you resetting any other ports on the hub at the same time? i.e.:, a hub should not have more than one port in the reset mode at a time. If you try to reset more than one port at a time, multiple attached devices can and will be in the default state, which is a big no-no.
2) are you sure it is a high-speed hub?
3) a high-speed hub plugged into a low/full-speed root-hub port makes the hub a full-speed hub.
4) a full speed hub plugged into a high speed root-hub port makes the hub a full speed hub (still).
5) sending and receiving packets to/from a downstream device is the same as if the device was plugged in to the root hub. i.e.: It doesn't matter that there is an external hub in-between the root-hub and the downstream device. This is the point of external hubs. Therefore, does your code work without the external hub, but not when the external hub is used? (your post hints to this).
6) if your code works without the external hub, but doesn't with the external hub, you are not initializing the hub correctly, or:
7) if the hub is a full-speed hub, any attached device will only enumerate up to full-speed, not high-speed. (a downstream device is only as fast as its parent device).
8) is the external hub you speak of the Rate Matching Hub on the EHCI card? If so, the RMH can (and usually does) have a vendor-specific initialization procedure.

On a slightly different note, is there any reason you are using EHCI? Is this the only hardware you have? I actually recommend either UHCI/OHCI or the new xHCI instead. Unless you only have EHCI hardware (root hubs), I suggest you choose another controller type.

Anyway, let us know more information about what is going on and we might be able to help out.
Ben
- http://www.fysnet.net/the_universal_serial_bus.htm

BenLunt wrote:Hi,

First, an external hub has nothing to do with the EHCI. EHCI is the host-side controller. An external hub does not comply to the EHCI specs. An external hub can be USB 1.1, USB 2.0, USB 3.0, etc., compliant.

Anyway, just a few questions/comments?
1) are you resetting any other ports on the hub at the same time? i.e.:, a hub should not have more than one port in the reset mode at a time. If you try to reset more than one port at a time, multiple attached devices can and will be in the default state, which is a big no-no.
2) are you sure it is a high-speed hub?
3) a high-speed hub plugged into a low/full-speed root-hub port makes the hub a full-speed hub.
4) a full speed hub plugged into a high speed root-hub port makes the hub a full speed hub (still).
5) sending and receiving packets to/from a downstream device is the same as if the device was plugged in to the root hub. i.e.: It doesn't matter that there is an external hub in-between the root-hub and the downstream device. This is the point of external hubs. Therefore, does your code work without the external hub, but not when the external hub is used? (your post hints to this).
6) if your code works without the external hub, but doesn't with the external hub, you are not initializing the hub correctly, or:
7) if the hub is a full-speed hub, any attached device will only enumerate up to full-speed, not high-speed. (a downstream device is only as fast as its parent device).
is the external hub you speak of the Rate Matching Hub on the EHCI card? If so, the RMH can (and usually does) have a vendor-specific initialization procedure.

On a slightly different note, is there any reason you are using EHCI? Is this the only hardware you have? I actually recommend either UHCI/OHCI or the new xHCI instead. Unless you only have EHCI hardware (root hubs), I suggest you choose another controller type.

Anyway, let us know more information about what is going on and we might be able to help out.
Ben
- http://www.fysnet.net/the_universal_serial_bus.htm

Hey, thanks for the quick response. Ive kinda blurred the lines between EHCI and USB 2.0 in my head (though I am fully aware that they are two different things), so my bad.

Thats a lot of info to consider so thanks. Definitely nothing is full speed or low speed, though those are points to consider for future endeavours.
As things stand right now, my code does work without external hubs.
Hardware-wise, I have both EHCI and xHCI, though three test machines with EHCI and only two with xHCI. I plan on working on xHCI over the summer, but ive made so much progress with the EHCI stack that I dont really want to abandon it.

The external hub in question is indeed the Rate Matching Hub. Do we have any info on the vendor specific initialisation procedure, or possibly where can one get their hands on such information?

Thanks again

ylli122 wrote:...but ive made so much progress with the EHCI that I dont really want to abandon it.

I don't blame you one bit.

ylli122 wrote:The external hub is indeed the Rate Matching Hub. Do we have any info on the vendor specific initialisation procedure? Where can one get their hands on such information?

Retrieve the Vendor ID and Device ID from the PCI card (the actual EHCI controller), then go to Intel's web site and download the hardware specification for that specific card. Sometimes, you have to get the whole chipset specification, i.e.: the whole mobo specification, and scroll to the EHCI part.

Within the EHCI PCI specification of that particular device, there are a few fields that describe what bits must be set/cleared depending on the environment.

There are many reasons I shy away from EHCI, the RMH being one of them. :-)

Ben

BenLunt wrote: Retrieve the Vendor ID and Device ID from the PCI card (the actual EHCI controller), then go to Intel's web site and download the hardware specification for that specific card. Sometimes, you have to get the whole chipset specification, i.e.: the whole mobo specification, and scroll to the EHCI part.

Within the EHCI PCI specification of that particular device, there are a few fields that describe what bits must be set/cleared depending on the environment.

There are many reasons I shy away from EHCI, the RMH being one of them.

Ben

Oh Jesus, alright, well, looks like I got a fun weekend ahead of me haha. Gosh, programming my EHCI driver has been such an adventure, it makes VGA feel simple in retrospect. I was just flipping over the xHCI specs just now, things seem so much more streamlined, im kind of regretting not having started with that. Oh well, still, im happy with what ive got.

Thanks for the heads up regarding the RMHs, the web seems devoid of almost anything regarding them. Ill see what I can do and post any updates to this thread.