Universal Serial Bus

USB is a modern bus standard of connecting devices to a computer. It is supported by virtually every modern computer.

USB keyboards/mice

Keyboards and mice are what the USB standard calls HID (Human Interface Device) class devices, and follow a special superset of the USB standard. Once you have a driver for a HID device, all USB HID devices will work with it, including mice, keyboards, joysticks, game controllers, and so forth. The HID standard is built on top of lower-level USB API's to send and receive data packets across the wire, but provides a translation layer that interprets the USB data so that the HID layer could conceivably be implemented on top of other protocols (Like PS/2 or serial).

For early stages, you can probably ignore the fact that those devices are USB. Virtually every chipsets will offer a good old PS/2 emulation of the USB human interface devices, so you can use I/O port 0x60 like the rest of us ...

Booting off of a USB flash disk

This is only possible with BIOSes that support booting from USB devices and with sticks that supports to be bootable. If possible, this page suggests that simply putting your 512 bytes as the boot sector of the USB's FAT partition would be enough ...

Adding USB support

As a first step, you'll need to provide a driver for the USB Host Controller, which appears in most cases as a PCI device and will allow you to enumerate devices on the USB bus and send packets to the identified devices. Documentation about the Open Host Controller Interface, Universal Host Controller Interface and Extended Host Controller Interface are available freely. Your USB-aware chipset should support one of these three.

Some computer may have support for more than one of these standards (there are computer with UHCI for USB 1.1 and EHCI for high-speed USB 2.0 using the same USB ports)

any information about whether both OHCI & EHCI can be found on a single mother board are welcome, as well as information about whether a EHCI driver will work on UHCI hardware

Once you know what devices are present, you'll have to identify a device-specific driver that will match that hardware. For some devices (webcams, scanners, etc), this may require a vendor-specific driver while other devices (USB keychains, HID etc) have to adhere to _class_ standards. This means that one can write a generic USB storage driver that will work with all possible keychains, embedded mp3 players, flash card readers, etc.

USB uses a tree topology, with non-leaf devices in the tree providing _hub_ class services. The tree can be up to 16 levels deep, with each hub theoretically providing up to 16 devices. The "root" of the tree is not considered a hub for some reason. Before you can start talking to devices on the USB, you will want to be able to enumerate all devices. Fortunately, the USB standard requires that all devices, including hubs, are self-describing.

Don't forget that USB devices are hot-pluggable, that is they can be added and removed at any time while the system is running.

Brief Sequence of Operation

Note: This is taken from this thread and may be inaccurate. It needs adding to at any rate.

Setup

• 1) Find Host Controller Type, Info and IO address using the PCI bus
• 2) Reset Host
• 3) Reset Port
• 4) Check Port status to detect for device insertion
• 5) Enable Port.

Device Interaction

• 1) Get Device Descriptor of device
• 2) Get Config Descriptor of device
• 3) Set Address of device
• 4) Set Configuration of device

Sending Commands

Sending commands is protocol specific, this is dependant on the Device Type (OHCI, UHCI and EHCI - UHCI being the easiest).

The command is send in a similar manner to the Device Interaction section:

• 1) Setup Queue Heads linked list
• 2) Setup Transfer Descriptors linked list
• 3) Populate both lists with valid data
• 4) Inform USB Host Controller to start command transaction

For Mass Storage Devices you must send specific commands using the CBW and CBS structures. You will also have to implement the following SCSI commands:

Inquiry, Get_Capacity and Read_10 or Write_10

Functioning

USB looks much more like a network protocol than like RS232 (good old serial cables). Data transmissions follow formatted packets rather than being made of plain characters. However, unlike network protocols like Ethernet, Token Ring, etc. all communications are directed by the host (i.e. your computer), and even 'interrupts' are actually polled by the host.

More information about this section can be found on Usb In A Nutshell (ch. 3)

Packets

These are the smallest formatted things that may transfer on the USB cable. Each USB packet at least have a SYNC header and a EOP trailer that carry no information but help in identifying packets boundaries. Each USB must also have a PID field (Packet IDentifier) that tells the role of the packet in a transfer or a transaction.

Transaction

A transaction is a "single sentence" between the host and a device. Transactions may be used to send/read data from the device, initiate transfers, set up parameters, get information, etc. Each transaction is typically made of 3 packets:

1. a token packet that always comes from the host and carries the address of the device/endpoint concerned in the transaction. USB defines 4 types of tokens: SETUP (initiates a control transaction), IN (initiates a device->host data transaction) and OUT (initiates a host->device data transaction). Tokens are typically have a small fixed size.
2. a data packet which carries the transaction payload. Depending on the USB version, transfer speed and type of data packet used (DATA0, DATA1, DATA2 or MDATA), the maximum payload may be 8, 64 or 1024.
3. a handshake packet which informs the data emitter of the reception status. Handshake may be ACK (data received correctly), NAK (unable to receive/emit data right now, or no data to send) or STALL (device state invalid, host intervention required)

Transfers

Transactions are used to build more complex protocols like control transfer, interrupt transfer (single small sized status poll), isochronous transfer (periodic non-acknowledged packet transmission, like a sample to play on speakers) and bulk transfer (non-predictable large-sized transfers like a page to print)

More on USB transfers can be found on USB in a nutshell, ch 4

Configuration

The configuration part of the USB standard occurs through the notion of descriptors. Descriptors are blocks of information retrieved through the host controller which defines things like vendor/product identifiers for each device and class/subclass/protocol codes for each device's interface. Based on these informations, the Operating System can assign the proper driver to each device/interface.

A list of structures defining USB descriptors is available in usbdescr.h from Clicker's CVS (LGPL)

Endpoints

Configuration communications are performed on endpoint 0. The USB device will usually define more endpoints used as communication channels between the device and the host, link those endpoints to interfaces which can be assigned a class, subclass and protocol codes (identifying what the device is able to do). For instance a digital camera could offer a couple of endpoints to implement the USBstorage interface (for the camera's memory card) and other endpoints for a webcam interface.

Reading descriptors

The host has to explicitly request descriptors from the device before it manipulates them. This is achieved by a setup transfer using a GET_DESCRIPTOR as the host->device data and receiving the descriptor as the data from the host. The whole transfer will look like

• command transaction:

Setup_TOKEN(addr=device, endpoint=0) : host -> device
DATA[ RequestType=0x80, Request=0x06, value=DESCR_TYPE|DESCR_SELECTOR,
    index=0, length=wished_length] : h->d, 8 bytes
ACK : host <- device

• response transaction:

IN_TOKEN(addr=device, endpoint=0) : host -> device
DATA(the_descriptor) : host <- device (as much bytes as requested)
ACK : host -> device

• confirm transaction:

OUT_TOKEN(addr=device, endpoint=0) : host -> device
DATA() : host -> device (empty)
ACK : host <- device

The DATA packet in the command transaction is called the "Setup Packet" (according to Beyond Logic), and carries almost all of the 'interesting' stuff:

• the RequestType of 0x80 (DeviceToHost=0x80| StandardRequest=0| DeviceTargetted=0)
• the Request (command) 0x06 for "GET_DESCRIPTOR"
• the value (encoding unknown atm)

See Also

Links

• USB.org
• The USB 2.0 Specification. Here you can download the official Universal Serial Bus Revision 2.0 specification, which defines the hardware and software. This is by far the best place to start, although not a light reading.
• information about the HID standard.
• The Linux kernel (though things tends to be confusing there, and you have to be careful with educating yourself from Linux sources if your project isn't GPL'ed).
• In Intel chipsets manuals.
• USB in a Nutshell may also interest you. It looks like a really good tutorial giving all the required knowledge to understand any other USB documentation/source code in a couple of HTML pages ...

any link to a description of USBstorage, USBprinter, HID, USB vendor list, etc. is of course welcome ;)

Forum Topics

• USB stick - discusses the feasability of booting from an USB memory stick
• USB driver - suggests a few startup links about USB
• support USB keyboard explained by Schol-R-Lea
• Collecting links about USB - PypeClicker and Df's collection of links about USB