BenLunt wrote:
Quote:
So my current guess is that I have to implement at least 3 drivers :
1 for my HCI (in this case OHCI)
1 that uses my HCI driver to talk to USB devices by doing all the USB bus administration/wrapping USB packets
1 for the particular device I want to talk to
In theory, yes.
1) You need a HC driver, which simply sets up the HC and monitors events.
2) You need a packet transfer driver. A layer between the device layer and the HC layer.
3) You need a device specific driver, in this example a Bulk-only driver.
Number 2) is optional, though a more advanced system will benefit greatly with this option.
I suspect, Iaen may have meant a USB core driver as his number two.
I would model it something akin to the way Seabios does it. I have seen similar systems replicated in different pieces of software, so they must be doing something right. The idea is that you have, as abstract entities, a USB host controller, a USB device, a USB hub, and a USB pipe. A host controller knows how to open a pipe to a specific endpoint on a specific device, and how to dispose of the pipe again, and how to transfer packets in all of the four modes and all of the two directions through any pipe opened through it.
A USB device knows not much more than its device address and the configuration descriptor. From that, configuration, interfaces, and endpoints intrinsically follow. It is just part of the spec. Again, host controllers can open pipes to given endpoints on given devices.
A USB hub knows how many ports it has, and how to enable, disable, query the status of, and reset the device behind each port.
And finally the pipes are the means of communication. They know what endpoint they connect to, and the host controller uses them to transfer data in the given way to the given endpoint. Obviously, there is some leeway in the division of labor here.
Each actual host controller implementation then must provide both a USB host controller and a root hub for the implementation. The USB core can provide routines such as the enumerator, because that is the same for all host controllers. Actually, all hubs: You enumerate a hub by doing this, for each port in parallel:
- enable port
- wait until "Power Good"
- check to see if there is a device there
- if not, disable port and exit
- else take lock on the bus (the "reset lock")
- reset the port
- address the device
- release the reset lock
- then enumerate the device itself
And that last one then entails such things as reading its config descriptor and seeing if you can do anything with the device. That enumeration then initializes a USB class driver. That is where they come in. You will definitely need a driver for USB hub devices. Those are also USB hubs as specified above, only with specific methods (which typically entail sending configuration requests on the default control pipe). And yes, USB MSC is also a class that needs a driver, as is USB UAS, and USB HID. Those four should tide you over for a while.
The point of all that modularity, is, of course, to insulate the USB class drivers from the host controllers themselves. So adding a new host controller doesn't mean you have to write all you USB MSC stuff again.