usb(HW)

usb -- Universal Serial Bus

Description

Universal Serial Bus (USB) is a low-cost, hot-pluggable device bus that is supported by most modern motherboards and is also available through add-in cards. In SCO OpenServer, the USB interface is implemented via the Uniform Driver Interface (UDI). Three USB Host Controller Interfaces (HCI) exist and are supported by this implementation:

HCI name USB standard Speed

Universal Host Controller Interface (UHCI) USB 1.1 12Mbps

Open Host Controller Interface (OHCI) USB 1.1 12Mbps

Enhanced Host Controller Interface (EHCI) USB 2.0 480Mbps

HCI name	USB standard	Speed
Universal Host Controller Interface (UHCI)	USB 1.1	12Mbps
Open Host Controller Interface (OHCI)	USB 1.1	12Mbps
Enhanced Host Controller Interface (EHCI)	USB 2.0	480Mbps

USB 1.1 devices are typically low-cost, low-bandwidth units. USB 2.0 offers speeds up to 480 megabits per second, which is comparable to mid-range IDE and SCSI bus speeds.

USB hubs and USB devices (such as mice, keyboards, and mass storage devices) may be plugged into the host. A maximum of 128 devices may be nested up to 8 layers deep using combinations of hubs and devices. USB devices may be attached before or after the host computer starts; devices may be unplugged from the bus while the computer is running.

Mouse and keyboard devices send very little data across the USB bus. Other devices, such as mass storage, use bulk transfer mode to move data blocks over the bus, but the data rates achieved are typically less than SCSI or IDE bus devices. USB is an effective mechanism for adding devices to a host that does not already have that functionality, such as adding a mouse or trackball to a laptop or adding supplementary storage such as a Zip^® or CD-ROM drive. USB can be used for hard disk storage when top performance is not required.

Note the following when using these supported USB device types:

Hubs

Powered hubs are recommended over unpowered hubs.

Keyboards

USB keyboards work like AT and PS/2 keyboards.
The simultaneous use of multiple USB keyboards, along with one AT or PS/2 keyboard, is supported.
LEDs and shift states are synchronized across all keyboards physically attached to a system. If you press the <Caps Lock> key on one keyboard, the Caps Lock state (including the LEDs) is active on all keyboards.
If you hot-add a USB keyboard, it ``adopts'' the current LED and shift state.

NOTE: USB keyboards cannot be used in the following situations:

when the kernel has been shut down. This means that you are unable to reboot at the system shutdown prompt using a USB keyboard:
```
   **    Safe to Power Off    **
                -or-
   ** Press Any Key to Reboot **
```
using the in-kernel version of the scodb kernel debugger. (See ``Using SCODB'' in the SCODB User's Guide.) You can enter the debugger from a USB keyboard but after that, the keyboard will not function. Systems that have scodb linked into the kernel and/or have hotkeys defined for the debugger should have an AT or PS/2 keyboard. Alternately, you can configure the debugger to use a serial console -- see ``Setting up serial consoles'' in the SCO OpenServer Handbook for more information.

Mice

USB mice work like keyboard mice (also known as PS/2 mice).
Any USB Human Interface Device that is a pointing device should work with the USB mouse driver.
Scrolling wheels are supported.
Three button mice are supported. Additional buttons are ignored by the X server.
You can have more than one USB mouse attached to the system at the same time. However, all USB mice are channeled through a single event channel. It is not possible to separately associate one USB mouse with one terminal and another USB mouse with a different terminal.
Having multiple USB mice might be useful if one of the devices is a joystick, graphics tablet, touchscreen, or other pointing device.
For multiple mice, the inputs are effectively connected together. It is possible, for example, to move the pointer with one USB mouse and click a mouse button on a different mouse; both operations are accepted as if they came from the same mouse. If you have identical mice and you move them in opposite directions at exactly the same speed, the mouse pointer remains still.

Printers

Multiple printers can be used on a system.
Printers can be attached and removed from the USB bus at any time.
In order for a printer to be supported, there must be a user-level driver/filter specific to that printer available.
The printer drivers are accessed through device nodes in /etc/usb (see giomap_noded(ADM) for more information). Printer status can be obtained from an UDI_GIO_DATA_XFER ioctl with the ``u_op'' field set to <PRNT_GET_PORT_STATUS. These constants and the needed data structures can be found in the giousr.h file. Status is returned as one byte and conforms to the Universal Serial Bus Device Class Definition for Printing Devices, Version 1.1 standard.

CD-ROM/DVD-ROM drives and CD/DVD writers

Multiple CD-ROM and DVD-ROM drives and writers can be used on a system.
Removing an attached CD-ROM or DVD-ROM drive (especially one that is mounted) may trigger a problem elsewhere in the system.
Devices that support software media lock are locked while they are in use by the operating system. Devices with mechanical media releases (for example, a CD-ROM drive with a hinged door instead of a tray) cannot be locked. Ejecting the media while the device is in use by the operating system can cause data corruption or a system panic.

Hardware

Root hub

The ``root hub'' refers to the USB ports configured on the motherboard. Many systems allow built-in USB ports to be disabled in BIOS setup. If USB is not working, check that it is enabled in the BIOS. Alternatively, if you do not wish to use USB, you may want to disable it in the BIOS setup since many motherboards use two to three interrupts for USB HCIs.

Connectivity options

The root hub ports may be used for either a USB device or a USB hub. Any combination of hubs and devices may be connected, up to the maximum device limit and the hub depth -- 128 devices nested 8 layers deep.

Software layers

USB devices are supported by a layered software implementation. Inside the kernel, there are several layers of software for USB support, including the USB protocol stack and USB class drivers. USB devices are configured using the mkdev(ADM) commands, such as mkdev mouse or mkdev hd. These commands provide access to USB devices from user applications.

USB protocol stack

The central driver of the USB protocol stack is the USB stack manager, usbd. This driver maintains an internal representation of the ``tree'' of USB hubs and devices. It notices the appearance and disappearance of devices as they are physically attached to and removed from ports and hubs. usbd attaches and detaches device descriptors to the corresponding USB class drivers.

USB class drivers

USB class drivers handle the attaching, detaching, and accessing of various classes of devices. SCO OpenServer includes separate class drivers for keyboard and mouse (usb_hid), mass storage devices (usb_msto), and hubs (usb_hub).

USB device configuration

USB mass storage devices look like SCSI devices to the kernel. The following table lists the different types of USB storage devices, the corresponding SCSI driver name, and the mkdev(ADM) script you use to configure the device:

Peripheral type Driver name mkdev command

Hard disk Sdsk mkdev hd

Removable disk Sdsk or Sflp mkdev hd, mkdev flopti (mkdev ls120)

CD-ROM drive Srom mkdev cdrom

Peripheral type	Driver name	mkdev command
Hard disk	Sdsk	mkdev hd
Removable disk	Sdsk or Sflp	mkdev hd, mkdev flopti (mkdev ls120)
CD-ROM drive	Srom	mkdev cdrom

When you physically attach a USB storage device to the system, a kernel configuration message is displayed on the console. As an example, a hard disk might produce a message similar to:

   %disk - - - type=S unit=1 ha=0 id=2 lun=0 bus=0 ht=usb_msto

In this message:

usb_msto (USB Mass Storage) is the name of the SCSI Host Bus Adapter driver.
The id number is the USB device ID assigned to the mass storage device. All storage devices attached to the USB bus are assigned a USB device ID, determined by the order in which the device is detected by the system. See ``USB device IDs'' for more information.
The unit number refers to unit numbers of the peripheral driver. In this example, unit=1 indicates that this is the second SCSI disk in the system. A value of ``0'' would indicate the first SCSI hard drive.

Once the USB storage device is plugged in, you must run the appropriate mkdev(ADM) script, as shown in the above table. You are prompted for the USB device ID that was listed in the id= field in the kernel configuration message. (You can also determine a device's ID by running hwconfig(C) with the -h option and locating the entry for the desired USB device in the resulting hardware list.)

Normally when adding a new SCSI device, you are required to relink the kernel and reboot the system. Because USB devices are hot-pluggable, however, this step is not always necessary.

Configuring hard disks

Use mkdev hd to configure USB hard disks, supplying the appropriate USB device ID for the device. Using the hard disk example shown above, you would enter USB ID 2. Because the device is already present and recognized, it is not necessary to relink the kernel and reboot the system.

You then need to run mkdev hd a second time to set up partitions, divisions, and filesystems.

Configuring removable storage devices

Removable USB storage devices, such as Zip, Jaz^®, LS-120, LS-240, and floppy drives, flash memory devices, and certain cameras, are recognized by both the Sdsk and Sflp drivers.

To configure a removable storage device as a floppy drive, use mkdev flopti (or mkdev ls120).
Typically, this is how you want to configure removable storage devices, unless you specifically want to establish partitions and divisions on the device's ``disk''.
To configure a removable storage device as a hard disk, with partitions and divisions, use mkdev hd.

NOTE: You cannot use USB removable storage devices, including floppy and LS-120/LS-240 drives, to format media.

By default, the system kernel is configured with the /dev/fd0 and /dev/fd1 device nodes. Depending on the number of traditional floppy drives attached to the motherboard floppy controller, you may be able to use one or both of these device nodes for USB removable devices, instead of running the device-specific mkdev(ADM) scripts. For example, if your system contains one traditional floppy drive, you can access one USB removable storage device from /dev/fd1. If you are not using any traditional floppy drives, you can access two USB removable storage devices from /dev/fd0 and /dev/fd1.

Sflp units are enumerated last in the list of floppy devices. If there is a standard floppy drive and a USB LS-120 drive on the system, the LS-120 will be /dev/fd1 and the standard floppy drive will be /dev/fd0.

NOTE: Most of the other floppy device nodes created (see fd(HW) for details) are only useful for USB removable storage devices that can use traditional floppy media (for example, floppy and LS-120 drives). Also see the floptical(HW) manual page for more information.

Configuring CD-ROM and DVD-ROM drives and writers

Use mkdev cdrom to configure USB CD-ROM and DVD-ROM devices. These devices can be mounted for read-only random access. Writable devices can be written with software such as cdrecord.

USB device IDs

When you attach a USB mass storage device, the system assigns the device a USB device ID. (USB device IDs are only assigned to USB storage devices, not to non-storage devices like mice and keyboards.) USB device IDs are determined by the order in which the system detects each device. However, the enumeration of devices depends on several factors and different circumstances may result in different device ID assignments on the same machine. For example, devices that you attach to a running system are enumerated in the order that you plug them in. At boot time, however, the entire USB hub/device tree is traversed and devices may be detected in a different order, resulting in different device ID assignments. In general, these guidelines apply:

if you attach all of your USB storage devices while the system is turned off, the enumeration order when the computer is started will likely persist between system reboots.
if you hot-add or hot-remove USB storage devices, device IDs may change when the system is rebooted.
if you add, remove, or change the order of USB storage devices on a non-running system that previously contained USB storage devices, device IDs may be different when the system is rebooted.

The following example illustrates a situation in which previously assigned USB device IDs could change.

If you have a computer that contains a USB CD-ROM drive as the only USB storage device, the CD-ROM drive is assigned USB device ID 0 when the system is booted. If you then hot-add a USB LS-120 drive, it is assigned USB device ID 1. Finally, you plug in an external USB hard drive and it is assigned USB device ID 2.

After running mkdev cdrom, mkdev ls120, and mkdev hd to configure the USB storage devices, the appropriate device nodes are created and the /etc/conf/cf.d/mscsi file is updated to contain entries similar to:

   usb_msto    Srom   0   0   0   0
   usb_msto    Sflp   0   1   0   0
   usb_msto    Sdsk   0   2   0   0

In this example, when you reboot the system, it is possible that the USB LS-120 device could now be assigned device ID 2 and the USB hard drive has switched to device ID 1. (If the CD-ROM drive remains the first detected device in the USB chain, it would retain device ID 0.) Now, if you access /dev/hd10, the system tries (most likely unsuccessfully) to use the LS-120 drive instead of the hard drive, and vice versa.

If you encounter a situation like this, you need to edit the mscsi(F) file and modify the usb_msto entries so the correct device IDs are assigned to the appropriate driver. (To confirm the USB device ID assignments on your system, run hwconfig -h. Check the value of the id= field for each of the USB mass storage device entries (usb_msto) in the list of hardware. In this example, you would change the mscsi file to read:

   usb_msto    Srom   0   0   0   0
   usb_msto    Sdsk   0   1   0   0
   usb_msto    Sflp   0   2   0   0

After editing the mscsi file, you need to relink the kernel and reboot the system. When the system is running again, the attached USB storage devices should now function properly.

Any time you make a change to the number or order of USB storage devices on the system, you may need to edit the mscsi file as described above. See the mscsi(F) and scsi(HW) manual pages for more information.

Device drivers in the USB protocol stack

HCI drivers

Controls I/O to the various USB host controllers found on motherboards and add-in cards. The HCI drivers include:

usb_ehci: Enhanced Host Controller Interface (hardware driver)
usb_ohci: Open Host Controller Interface (hardware driver)
usb_uhci: Universal Host Controller Interface (hardware driver)

usb_hci

Host Controller UDI meta-language

Communications interface between the USB stack and the HCI drivers.

usbd

USB stack manager

Communications interface between the USB stack and the HCI drivers. This driver maintains an internal representation of the ``tree'' of USB hubs and devices, and attaches/detaches device descriptors to corresponding USB class drivers as USB peripherals are added/removed.

usbdutil

USB stack utilities library

Utility functions used by usbd.

opnusbdi

OpenUSBDI UDI meta-language

USB ``tree'' management functions used by usbd.

usb_hub

Hub (USB class driver)

Class driver for managing USB hubs.

usb_prnt

Printer (USB class driver)

Class driver for managing USB printers.

usb_msto

Mass storage (USB class driver)

The pseudo Host Bust Adapter driver. This is the driver that appears in the mscsi(F) file to attach USB storage devices to SCSI peripheral drivers.

usb_hid

Human Interface Device (USB class driver)

Class driver for talking to Human Interface Devices (mice, keyboards, and so forth.)

udihidpr

Human Interface Device parser library

Functions for decoding messages from HID devices.

udi_hid

Human Interface Device UDI meta-language

Functions for controlling HID devices.

udiMkb

SCO OpenServer keyboard mapper

Connects HID keyboard type devices to the SCO OpenServer console driver.

udiMmse

SCO OpenServer mouse mapper

Connects HID ``pointing device'' type devices to the SCO OpenServer event driver.

Files

/etc/conf/cf.d/*: system device configuration files and utilities
/dev/usb/*: USB device nodes
/usr/lib/event/*: device files for mice

Standards conformance

This USB interface conforms to Release 2.0 of the USB specification. For more information, see the USB web page.