Universal Serial Bus

From OSDev Wiki
(Redirected from USB)
Jump to navigation Jump to search

The Universal Serial Bus was first introduced in 1994 with the intention of replacing various specialized interfaces, and to simplify the configuration of communication devices. The communication industry did not develop as the USB-IF foresaw, but the various transfer modes that USB introduced allowed it to become one of the most popular standards in use today. Virtually every modern computer supports USB.

Introduction

Despite how attractive USB support is, the 650-page USB 2.0 specification manages to deter even some of the most driven hobbyists (especially if English isn't their primary language). Not only is the USB 2.0 specification long, but it's a prerequisite for the XHCI, EHCI, UHCI, and OHCI specifications, which define the actual hardware OSes interface with. Furthermore, the USB specification defines a plethora of terms, some used interchangeably and seemingly lazily; as a lengthy technical document, it is neither easy nor practical to flip back and forth to clarify a confusing term or concept.

What this text covers

The truth is that a software developer doesn't need to read the entire USB 2.0 specification; there are sections specific to hardware developers, for example. The information presented here attempts to summarize chapters 4, 5, and 8 through 10.

Chapter 11 is specific to hubs and is also essential for a full USB 2.0 implementation, however it is almost as long as chapters 4, 5, 8, 9, and 10 combined, and could be regarded as the documentation for a specific (albeit special) class of USB devices. Chapter 11 is covered thusly in its own wiki entry, USB Hubs. Even so, some concepts which pertain to USB hubs are briefly discussed where relevant in this article.

Ideally, the text here will establish familiarity with the terms and concepts that a hobby OS developer needs to begin implementing USB support and, if necessary, easily parse the USB specification without becoming intimidated by the amount of information. At the very least, the system programmer should keep a copy of the USB 2.0 specification for reference while working with USB-related hardware.

Fortunately, all of the necessary documentation is available for free (see Links).

What this text does not cover

Please note that USB, unlike other standards like VGA or PCI, is agnostic of the hardware interface to the system bus (and, by extension, to the operating system). Such an interface is provided by one or more USB host controllers and is defined by the appropriate documentation. Therefore, one should not expect this text to discuss specifics or code samples (e.g., as one finds in the wiki entries about VGA or PCI) detailing how the operating system initiates and maintains communication with USB devices. Although such information may be found on wiki entries discussing a particular Host Controller Driver, those wiki entries assume an understanding of the concepts and terms discussed here.

Host Controllers

The Host Controller is the USB interface to the host computer system. In other words, the host controller is what the system software uses to communicate with USB devices.

USB 1.0 Host Controllers

Main article: Universal Host Controller Interface
Main article: Open Host Controller Interface

Intel brought USB 1.0 to the market with its Universal Host Controller Interface (UHCI), while Compaq, Microsoft, and National Semiconductors did the same with their Open Host Controller Interface (OHCI). Naturally, the two interfaces are incompatible, and to make things worse, VIA Technologies licensed Intel's UHCI standard, thereby ensuring that both standards survived. Typically, an on-board chip set will contain a UHCI implementation, whereas a peripheral card typically implements the OHCI standard (but this is by no means a guarantee).

USB 2.0 Host Controllers

Main article: Enhanced Host Controller Interface
Figure 1: Block Diagram of Port Routing Behavior

In designing USB 2.0, the USB-IF insisted on a single implementation. That single implementation is Intel's Enhanced Host Controller Interface (EHCI). However, even though the USB 2.0 specification requires that a USB 2.0 interface support USB 1.0 devices, this doesn't mean that the EHCI must support USB 1.0 devices, and in fact, it doesn't. Each EHCI host controller is accompanied by (usually several) UHCI and/or OHCI host controllers. When a USB 1.0 device is attached, the EHCI simply hands control over to a companion controller. Refer to figure 1 for a simple block diagram implementation of this behavior. Therefore, the system programmer must support all three standards in order to support USB 2.0.

The EHCI host controller only handles USB 1.0 devices if they are attached indirectly through a USB 2.0 hub. The specifics of handling USB 1.0 devices attached to a USB 2.0 hub are briefly discussed and illustrated in the hubs section, and in more detail in the wiki entry for USB Hubs. Note that some newer chipsets like the Intel 5-series chipsets do not have companion controllers at all and instead have internal "rate matching" hubs that all USB devices go through.

USB 3.0 Host Controllers

Main article: eXtensible Host Controller Interface

Like its predecessor USB 2.0, USB 3.0 has only one host controller specification: Intel's eXtensible Host Controller Interface. Unlike its predecessor EHCI, however, xHCI controllers can and do interface with USB 1.0 and 2.0 devices without the use of companion controllers. Even on early hardware where there was both an EHCI and xHCI controller included (so that OSes which did not yet support xHCI could still use at least some USB devices), ports attached to the EHCI controller could generally be "re-routed" to the xHCI controller, and the EHCI controller disabled entirely.

Also unlike its predecessors, xHCI was designed with some degree of forwards compatibility, so that revisions to the USB specification can be made without designing a new host controller interface (for instance, USB 3.1 and 3.2 add new speeds, with only minor updates to the specification to match them.) Unfortunately, this means that xHCI bears only a passing resemblance to the controllers that came before it, and make it challenging to write drivers for.

Basic Concepts and Nomenclature

The USB is a polled bus, meaning the host controller must initiate all transfers. Do not mistake this to mean that the system software must poll the USB. The host controller takes care of polling the bus and can be programmed to issue interrupts to the OS whenever the bus needs attention.

USB System

Figure 2: USB System Illustration

A USB System consists of three discrete parts: the USB device(s), the USB interconnect, and the USB host. Figure 2 illustrates a USB System.

USB Device(s)

USB devices are classified as either a hub or a function (not to be confused with a program procedure). Hubs provide additional attachment points, whereas functions provide capabilities to the system. Some devices may implement several functions and an embedded hub in one physical package. These are called compound devices.

Functions

All functions understand the USB protocol, respond to standard operations (e.g, configuration or reset), and describe capabilities to the USB host.

There are four speed classes of functions:

  • Super-speed functions operate at up to 5 Gb/s.
  • High-speed functions operate at up to 480 Mb/s.
  • Full-speed functions operate at up to 12 Mb/s.
  • Low-speed functions operate at up to 1.5 Mb/s.

The original USB specification defined low- and full-speed devices, while USB 2.0 added high-speed devices and USB 3.0 added super-speed devices.

Hubs

In a high-speed system, a high-speed hub plays a special role. Since the high-speed hub establishes a high-speed transfer rate with the host, it must isolate any full- or low-speed signaling from both the host and any attached high-speed devices.

To better understand, consider that the EHCI controller is accompanied by one or more companion controllers, as illustrated in figure 1 above. When a full- or low-speed device is attached directly to the root hub, the EHCI controller can relinquish ownership of that specific port to a companion controller as seen in figure 3. However, if a high-speed hub is connected to a port, as in Figure 4, then the EHCI controller must retain ownership of the port because it is a high-speed device. Now suppose other high-speed devices are attached to the high-speed hub in figure 4; obviously the EHCI controller retains control as in figure 5.

But what happens when a full- or low-speed device is connected to the high-speed hub in figure 5? If the EHCI controller were to relinquish ownership of the port, the high-speed devices will no longer be able to operate at high-speed, if at all, as in figure 6. Instead, the host controller and the hub support a special type of transaction called a split transaction. A split transaction involves only the host controller and a high-speed hub; it is transparent to any devices. This scheme of using split-transaction to support low- and full-speed devices on a high-speed hub is illustrated in figure 7.

Note that some newer chipsets like the Intel 5-series chipsets do not have companion controllers at all and instead have internal "rate matching" hubs that all USB devices go through.