Universal Serial Bus (USB) was developed by the PC industry to provide a low-cost solution for attaching peripheral devices, such as keyboards, mouse devices, and printers, to a system.
USB connectors are designed to fit only one type of cable, one way. The primary design motivation for USB was to alleviate the need for multiple connector types for different devices. This design reduces the clutter on the back panel of a system.
Devices connect to USB ports on external USB hubs, or on a root hub that is located on the computer itself. Since hubs have several ports, several brances of a device tree can stem from a hub.
Additional advantages of using USB devices are as follows:
USB devices are hot-pluggable. For more information, see Hot-Plugging USB Devices.
USB 1.1 devices are supported in the Solaris 9 environment.
Supports a maximum of 126 devices per host controller in the Solaris environment.
Supports a maximum of 12 Mbit/sec data transfer.
Supports low-speed (1.5 Mbit/sec) and full-speed (12 Mbit/sec).
Solaris Ready USB PCI controllers are available. For more information, see http://www.sun.com/io.
The bus can be easily extended by adding low-cost external hubs. Hubs can be connected to hubs to form a tree topology.
Sun Microsystems platform provides support for USB devices includes the following:
SPARC based systems with OHCI host controllers that support USB 1.1 provide low- and full-speed devices:
Sun BladeTM systems that run the Solaris 8 or 9 release.
NetraTM X1/T1 and some Sun FireTM systems that run the Solaris 9 release.
SPARC based systems provide support for low- and full-speed support for USB 1.1 devices:
Any PCI-based sun4u system including those listed above, that run the Solaris 8 or 9 release.
x86 based systems with OHCI and UHCI controllers that run the Solaris 8 or 9 x86 Platform Editions provide USB 1.1 support.
x86 based systems with OHCI host controllers that run the Solaris 8 or 9 x86 Platform Editions provide USB 1.1 support.
This table lists specific USB devices that are supported in the Solaris environment.
USB Devices |
Systems Supported |
---|---|
HID control on audio devices |
SPARC based and x86 based systems. |
Hubs |
SPARC based and x86 based systems. |
Keyboards and mouse devices |
SPARC based and x86 based systems. |
Mass storage devices |
SPARC based and x86 based systems. Supported configurations include only one keyboard and mouse. These devices must be connected to an on-board USB host controller. |
Printers |
SPARC based and x86 based systems. |
Speakers and microphones |
SPARC based and x86 based systems. |
The following table describes the USB acronyms that are used in the Solaris environment. For a complete description of USB components and acronyms, go to http://www.usb.org.
Acronym |
Definition |
---|---|
USB |
Universal Serial Bus |
USBA |
Universal Serial Bus Architecture (Solaris) |
USBAI |
USBA Client Driver Interface (Solaris) |
HCD |
USB host controller driver |
EHCI |
Enhanced Open Controller Interface |
OHCI |
Open Host Controller Interface |
UHCI |
Universal Host Controller Interface |
The USB specification is openly available and free of royalties. The specification defines the electrical and mechanical interfaces of the bus and the connectors.
USB employs a topology in which hubs provide attachment points for USB devices. The host controller contains the root hub, which is the origin of all USB ports in the system. For more information about hubs, see USB Host Controller and Root Hub.
Figure 29–1 shows a system with three active USB ports. The first USB port connects a Zip drive. The second USB port connects an external hub, which in turn, connects a cdrw device, and a composite keyboard and mouse device. Being a composite device, this keyboard contains a USB controller, which operates both the keyboard and an attached mouse. The keyboard and the mouse share a common USB bus address because they are directed by the same USB controller.
Figure 29–1 also shows an example of a hub and a printer as a compound device. The hub is an external hub that is enclosed in the same casing as the printer. The printer is permanently connected to the hub. However, the hub and printer have separate USB bus addresses. The same diagram shows an example of a composite device.
The device tree path name for some of the devices that are displayed in Figure 29–1 are listed in this table.
Zip drive |
/pci@1f,4000/usb@5/storage@1 |
Keyboard |
/pci@1f,4000/usb@5/hub@2/device@1/keyboard@0 |
Mouse |
/pci@1f,4000/usb@5/hub@2/device@1/mouse@1 |
cdrw device |
/pci@1f,4000/usb@5/hub@2/storage@3 |
Printer |
/pci@1f,4000/usb@5/hub@3/printer@1 |
USB devices are divided into device classes. Each device class has a corresponding driver. Devices within a class are managed by the same device driver. However, the USB specification also allows for vendor-specific devices that are not part of a specific class. Devices with similar attributes and services are grouped.
The Human Interface Device (HID) class contains devices that are user-controlled such as keyboards, mouse devices, and joysticks. The Communication Device class contains devices that connect to a telephone, such as modems or an ISDN interface. Other device classes include the Audio, Monitor, Printer, and Storage Device classes. Each USB device contains descriptors that reflect the class of the device. A device class specifies how its members should behave in configuration and data transfer. You can obtain additional class information from http://www.usb.org.
USB devices are represented as two levels of device tree nodes. A device node represents the entire USB device. One or more child interface nodes represent the individual USB interfaces on the device. For special cases, the device nodes and interface nodes are combined into a single combined node.
Driver binding is achieved by using the compatible name properties. For more information, refer to 3.2.2.1 of the IEEE 1275 USB binding and Writing Device Drivers. A driver can either bind to the entire device and control all the interfaces, or can bind to just one interface. If no vendor or class driver claims the entire device, a generic USB multi-interface driver is bound to the device-level node. This driver attempts to bind drivers to each interface by using compatible names properties, as defined in section 3.3.2.1 of the IEEE 1275 binding specification.
The Solaris USB Architecture (USBA) adheres to the USB 1.1 specification plus Solaris driver requirements. The USBA model is similar to Sun Common SCSI Architecture (SCSA). The USBA is a thin layer that provides a generic USB transport-layer abstraction to the client driver.