OSDev.org

Ben, i'm assume, that my EHCI driver successfully works on real hardware, because hub, mouse and keyboard drivers are working on it. If i send some command, and after that i won't try to recieve CSW some commands are working properly, read10 reads first sector, but after that always send it to me, may be it is bug in my code, i will test, but can you explain why readcapacity10, testunitready and some commands work properly if i send StartUnit and isn't reading CSW after send, may be device 'Waking up'?

This is probably not the case. Your Mouse, Keyboard, and probably your hub are low- or full-speed devices while the MSD device is probably a high-speed device. Your EHCI driver needs to account for this.

For example, if the hub is a full-speed hub and you plug your high-speed MSD in to it, the MSD will operate at full-speed but the EHCI will still require some high-speed characteristics for the MSD device.

Your hub driver, which includes the Root Hub as well as external hubs, must keep track of what is down-stream as well as up-stream.

Here are a few examples:

1) high-speed root hub (EHCI) --> MSD (high-speed) thumb drive

All traffic is high-speed.

2) high-speed root hub (EHCI) --> full-speed external hub -- > MSD (high-speed) thumb drive

All traffic is full-speed.

3) high-speed root hub (EHCI) --> high-speed external hub -- > HID (low-speed) mouse

Traffic is high-speed until the last hub, which is now low-speed to the mouse

4) full-speed root hub (UHCI) --> full-speed external hub -- > MSD (high-speed) thumb drive

All traffic is full-speed.

5) high-speed root hub (EHCI) --> full-speed external hub -- > high-speed external hub -- > MSD (high-speed) thumb drive

All traffic is full-speed.

Number five is a very good example of this. Even though you are on an EHCI root hub, which is high-speed capable, the device attached is a full-speed device. Any down-stream traffic can only be full-speed or less, period. However, the high-speed capable device at the end of the stream (MSD thumb drive) still requires some high-speed characteristics set in the TD sent to the EHCI controller (as well as the high-speed hub before it).

Your Hub driver must account for this. i.e.: You need a few routines, called from your packet driver, to check to see if this device is a high-speed device, *and* check to see if this is a high-speed device operating at high-speed or a high-speed device operating at full-speed. To make things more complicated, you need this for Super-Speed as well :-)

The emulators don't account for this and would explain why your code works. Real hardware *does* account for this and even a single bit in the TD in error will not let your MSD work.

- Ben

So, now i'm successfully complete one command: Test Unit Ready, but status in CSW = 1. Next bulk data in is always with qTD's 'active' bit in token is set for ever.

One more thing I forgot to mention. You need to make sure the toggle bits are correct. The in_endpt's toggle bit is independent of the out_endpt's toggle bit. However, the toggle bit knows of no such thing as a command block or status block. i.e.: you need to toggle the endpt's toggle bit no matter the 'B' in 'BBB'. (The standard protocol for MSD is Bulk/Bulk/Bulk, i.e: BBB)

Also, if you clear the stall using the Clear_Feature request (or reset the port), the first/next toggle will be zero.

The emulators don't check for the toggle bit and work either way, while real hardware does check the toggle bit.

- Ben

Ben, i have a great mistake: what initial state of toggle bit for InEndpoint and OutEndpoint. Did you mean, that after success completion of TD, toggle bit of endpoint must be changed? I.e.: first state of toggle of OutEndpoint is 1, after sending CBW, toggle bit for OutEndpoint must be changed to 0?

Ok, Ben. My working usb stick are working with my driver. But other stick have interval=255, and it hasn't works, what it may be?

So, almost working. I'm sending request to read one sector, reading 512 bytes, and after that i'm always returns my sector in CSW, and no one of next command will complete. What it may be?

The toggle bit initially is set to zero. Therefore, the first transfer on the endpoint has a toggle bit of zero. Then every transfer after has the toggle bit toggled. Hence the name of the bit. However, this toggle bit is independent of each endpoint. Each endpoint has its own toggle bit.

This toggle bit remains toggled on each transfer until a Stall is found, in which you send a Set_Feature(Clear Stall) request to that endpoint. By doing this, you reset the endpoint to zero. i.e.: After a Clear Stall request, the next transfer will have a toggle bit of zero.

Appendix D of Volume 8 has a very good example of this toggle bit for BBB transfers.

One thing you must remember is that if you set up your TD's to use 64-byte transfers, due to full-speed traffic, expecting 512-byte sectors, and receive a short packet, you must calculate via the short package location, the last toggle bit used, so that the very next toggle bit is the correct toggle value. i.e.: You can't just place eight (8) TD's on the "stack" and expect the next toggle bit to be a given value. If at any time one of those eight packets errors, short packets, or stalls, you have to know what the next toggle bit will be.

Also, for a read, the CSW packet is part of that toggle sequence, since a read uses the in endpoint. For a write, the CBW is part of the toggle sequence, since a write uses the out endpoint.

The toggle bit doesn't care what type of packet it is, a CSW, Data, or CBW. It only cares that it is an in endpoint or an out endpoint and is toggled each time it sends/receives data.

Ben

Ben, thanks for all. My driver now works fine! Topic closed, but i'm need to solve problem with VirtualBox, that you know.

Glad to hear it. Was it the toggle bit? This usually gets most people, including myself once in a while.

Ben

Ben, but i'm sill can't understand what is interval for endpoint? I'm need to wait some time to get device is ready?
Yes, i'm fixed toggle bit, and set properly MaxPacketSize value for endpoints TDs.

Interval is used for Periodic transfers. For example, a mouse might send an updated packet every 32mS. The Interval value tells you not to request it any sooner, as well as expect to request it at least this frequently.

Ben