USB and OS/2 (Part 1: Basic USB support: controllers)

By Jonas Buys

OS/2 and hardware... For more than a decade, OS/2 has been misjudged to have very limited hardware support. But in fact, if you dig some further, you'll notice that OS/2 Warp and eComStation offer extreme large and powerful hardware support. Recently, a whole lot has changed ever since USB support became available for OS/2. Over the last two or three years, IBM has provided us with some great device drivers, which enable the use of several hundreds of older and modern USB devices with the OS/2 Warp family of operating systems. The upcoming series of articles will discuss all IBM USB drivers thoroughly, and list a lot more OS/2 compatible devices and chipsets than the very limited number IBM tested with the drivers.

This article was intended both for novice and advanced OS/2 users. Also, this article should be considered to be an introduction offering basic knowledge for the upcoming articles.

1. Introduction
USB (Universal Serial Bus) is a plug-and-play interface between a computer and a whole variety of add-on devices, such as keyboards, mice, Ethernet cards, scanners, printers, et cetera. With USB, a new device can be added to your computer without having to add an adapter card or even having to turn the computer off.

The USB peripheral bus standard was originally developed by Compaq, IBM, DEC, Intel, Microsoft, NEC and Northern Telecom and the technology is available for all computer and device vendors.

Today, a PC user expects to be able to connect a wide range of external devices to his or her system; not just printers and modems, but scanners, cameras, mass storage devices, PDAs and a very diverse set of other peripherals. But for a long time, anyone attempting to do so was hampered by a lack of suitable input/output ports. Before USB were even invented, the only universal interface for the PC had been SCSI, an expensive and superb option only justified for high-bandwidth devices, especially suited for server needs. Lower speed peripherals generally required either a serial or a parallel port, or used a proprietary interface.

Designed originally for printers and low speed modems, the PC's serial and parallel ports leave a lot to be desired as general purpose interfaces. Their data transfer rate is awfully low (maximum 115Kbps for the COM port, up to 400KBps for an LPT port) and each device requires its own hardware interrupt (IRQ) which limited the amount of expansion possible. Plug-and-play? Never heard of that with those interfaces...

The need for a medium-speed, inexpensive plug-and-play interface that could be used to branch a virtually unlimited number of devices was eventually recognized, and the solution would be the Universal Serial Bus.

1.1.1. USB Design*
The USB was designed to allow large numbers (up to 127) of low- and medium-speed peripherals to be attached to a PC. With an initial maximum transfer rate of 12Mbps, USB was never intended to be an alternative to SCSI. Even today, Hi-Speed USB still can't compete with the newest SCSI standards. Nevertheless, the technology is still much faster than the serial or parallel ports.

USB was designed to be plug-and-play. Devices can be added and removed even while the system is running, avoiding the need to reboot the system to reconfigure it. Technical issues like bus termination and the assignment of device identifiers are taken care of by the hardware and software architecture so these common sources of configuration error will not be a problem. Concerns for power conservation have been catered for by allowing devices to be suspended and resumed.

Typical USB devices are those requiring low and medium bandwidths. At the bottom end of the bandwidth range, USB could be used to connect a keyboard and mouse to a PC. At the top end, scanners, backup devices or cameras for video-conferencing applications could use USB, eliminating the need for proprietary interface boards with their associated installation and configuration problems.

The bus architecture, in which data for different devices travels across the same cable, also has the potential for simplifying connection requirements.

For example, a mouse could plug into a keyboard, and a single cable would then link these with the PC.

1.1.2. Wiring details...*
USB devices are connected together using an inexpensive white or black jacketed four-wire cable with a characteristic impedance of 90 ohms. USB devices can be either self-powered (with their own independent power supply) or bus powered.

One of the pair of wires in the USB cable is used to carry a 5V power: pin 1 carries the supply voltage of +5V, pin 4 is the ground. There are two classes of bus-powered devices. Low power devices may draw no more than 100mA of current, whilst high power devices can draw up to 500mA once configured.



The second pair of wires, D+ and D- on pins two and three, is a twisted pair used to carry data. A high voltage on D+ but not on D- is a 1 bit. A high voltage on D- but not on D+ is a 0 bit.

The USB operates at two distinct speeds. Full speed gives a bandwidth of 12Mbps. At this speed, shielded cables must be used to obtain adequate noise immunity and prevent electromagnetic interference (EMI). Shielded cables are about 5 mm in diameter, and cable segments can have a maximum length of 5 meters.

For applications that require a low bandwidth a lower speed operating mode is available. This allows slightly thinner, cheaper unshielded cable to be used. Cable length is reduced for the unshielded cable to a maximum 3 meters. To prevent the high speed signal being transmitted over unshielded cable (which would cause EMI) and to avoid the risk of low speed devices misinterpreting full speed data as commands to which they should respond, communication with low speed devices is disabled whilst full speed signaling is being used.

Two types of plugs and sockets, known as series A and series B, are specified for USB. Series A plugs and sockets are for use with devices to which the external cable is permanently attached, for example keyboards, mice and hubs. Series B connectors are used when the USB cabling is detachable, as in the case of printers, scanners and modems. The two types are not interchangeable.

The series B connectors are about 11 mm x 12 mm with the contacts recessed. The mating plug provides a fully shielded connection.

1.1.3. USB Topology*
USB uses a multi-level star topology which looks like a tree. Places where the bus divides into two or more branches, a hub is present. At the end of each branch is a peripheral function. The word function in this context is a specific USB term.

Each physical USB device consists of a bus interface, a logical device and one or more functions. The bus interface is standard for all USB devices. The logical device is the user view of the device. In physical terms it might contain a single function, or it could consist of several functions with an embedded hub.

An example of a multi-function device with embedded hub is a keyboard with built-in trackball.

Hubs have ports or attachment points that allow other USB devices to be connected to them. Each length of cable starts at a hub and ends at another device. Each connector is terminated, so cable termination is automatic and not something users will need to worry about. At the host there is just a single hub, known as the root hub, attached internally to one or more USB ports. There can be only one root hub per USB interface.

In PC hardware terms the root hub, or rather the USB controller through which the PC software controls it, is a single device with its own IRQ and I/O requirements. Once set up, the USB will not require any hardware reconfiguration no matter what devices you plug in to it. All you will need to do is install the driver software for the new device.

The USB technology is designed to allow "dynamic" attachment and removal of devices, while the system is running (the so-called hot-plugging). This is achieved using an ongoing process of bus enumeration, which constantly checks what devices are on the bus.

When no device is connected to an attachment point, pulldown resistors ensure that both data lines are at ground potential. When a device is attached, a pullup resistor within the device raises one line to above the 2.8V threshold, so the hub knows that a device is attached. The hub can also tell whether a device is low or high speed: low speed devices pull up the D- line, while high speed devices pull D+ high. Having established the presence of a device and its communication speed, the system software can interrogate it to find out what its requirements are, and load the relevant drivers for it.

There are similarities between the USB software and the PC Card Socket Services driver software. There are three software levels. At the lowest level is the host controller driver (HCD) software that interfaces directly to the USB controller. Above this is the USB driver (USBD) software that provides USB support for the operating system the PC is running. Above these two layers is the client software required for each USB function.

Neither applications nor the operating system can talk directly to USB devices. Applications may make I/O requests to the client software, or they may access a USB device indirectly using operating system functions which themselves call the client software. Client software may either make calls directly to the USBD layer, or through an operating system defined interface.

The USBD converts client software requests to the bus transaction level, for example, breaking a request to transfer a large block of data into the requisite number of packet-sized transfers. These are passed to the HCD layer. The HCD interacts directly with the USB controller, turning the transaction requests into a low level implementation dependent form which the controller then responds to by creating bus activity.

1.1.4. PC - USB Device Communication*
Although a physical map of a USB may look like a tree, logically the bus appears as a star with up to 127 devices connected to a single hub. Client software communicates directly with its device. Each device has a unique address, which is assigned to it by the USB system software during configuration to avoid conflicts.

Communication between devices and client software is conceptualized as using pipes. Each pipe is a communication channel between software on the host and an endpoint on a device. Each endpoint represents a part of a device that fulfils one specific purpose for that device, such as to receive commands or transmit data. A full speed device can have up to 16 endpoints, though low speed devices can have only three.

All USB devices support endpoint 0 when powered up. This endpoint is the target of the default pipe. After the attachment of a device has been detected, the USBD software uses endpoint 0 to initialize the device, perform generic (i.e. non device-specific) configuration, and obtain information about the other endpoints provided by the device. Endpoints are characterized by their endpoint number (set at design time) and bus bandwidth, access frequency, latency and error handling behavior requirements.

Once the endpoints of a device have been identified and configured, pipes come into existence allowing the client software to communicate with the device. A pipe has associated with it characteristics such as a claim on bus access and bandwidth, the type of transfer, the direction of transfer and the maximum data payload size. These terms, however, lie beyond the scope of this article.

At the bottom of this page, you will find links to several complete PDF files explaining every details about USB.

USB defines four types of transfer: control transfers which are typically used for command or status operations, interrupt transfers which are initiated by a device to request some action from the host, isochronous transfers which are used to carry data the delivery of which is time critical (such as for video and speech), and bulk transfers which can use all available bandwidth but are not time critical. All transfers take the form of packets, which contain control information, data and error checking fields.

There are also two types of pipe: message pipes and stream pipes. Control transfers are made using message pipes. In a message pipe, the data portion of each packet has some meaning to the USB system software.

Stream pipes are used for interrupt, isochronous and bulk transfers. In a stream pipe, the data portion of the packet has no defined meaning to the USB: the data is merely conveyed between client software and device.

1.1.5. USB: the bad, the ugly, the beauty
In this section, we'll briefly have a look at USB's advantages and disadvantages.

USB is a very flexible, versatile solution. That's what makes it so user friendly. Just plug your device in an available USB port, install one driver, and that's it: ready to go! The technique will work in any situation and configuration.

USB is cheap. Prices for a lot of USB devices have dropped significantly the past few years.

Also, USB can serve your mobility needs. USB Ethernet cards, USB Memory Sticks, floppy disk drives... It's all available, and since every non-iron age computer has two or more USB ports, you can use those devices anytime, anywhere.

USB is hot pluggable. This means you can attach and remove devices on the fly without the need to reconfigure (if you've already installed the device drivers), nor reboot. More information about hot plugging will be provided later on.

One of the main disadvantages is that USB is a serial technology, what causes the bandwidth to be distributed between all devices in a linear way. No way to prevent this issue, unfortunately.

USB allows wires only to be as long as 5 meters. You can extend this length by using USB hubs to 30 meters, but that really is the maximum.

Another thing is that the technique has not been managed strictly. I mean: take a look at modems. Only very few work according to the USB Communications Protocol 1.1, since manufacturers tend to use mixtures of chipsets that either don't support this at all, or only partial, thus limiting these devices only for winusers. Happily, a lot of manufacturers begin to keep these standards in mind. Most recent USB Memory Keys, for example, support the USB Mass Storage Device (MSD) Standard, thus extending their market to users of other, and better, OS'es.

1.2. Some common USB Terminology...
There are many reasons why USB is inferior to other technologies like e.g. SCSI, but that will not be discussed in this article. Fact remains that, despite of its limited performance (and this performance limit doesn't matter with today's modern Hi-Speed USB 2.0) USB is a great technology, since it combines ease of use, compatibility with all major operating systems, and especially mobility (USB memory keys, USB Ethernet NICs).

Unfortunately, there often seems to be some misunderstanding related to USB terminology when discussing the Universal Serial Bus technology. That's why a brief and clear overview is given here: So far for a brief overview of technologies. Now, in the "USB technology family", there are some variants, types of Host Controller Interfaces: First, for USB 1.1 (or for USB 2.0 cards that can also use USB 1.1 devices), we have UHCI and OHCI.

UHCI is short for Universal Host Controller Interface. It is one particular direction in the USB controller interfaces. It is used by Intel and VIA chipsets. Other brands also can be compatible with UHCI. This is the real standard for USB 1.1. nVidia nForce is also UHCI. UHCI, Intel&#8217;s proprietary interface, defines how the USB controller talks to the host computer and its operating system. UHCI is optimized to minimize host computer design complexity and uses the host CPU to control the USB bus.

A kind of equivalent of UHCI is OHCI, Open Systems Host Controller Interface. It's another particular direction in USB 1.1, and is mainly used in chipsets branded by SiS, ALi, Opti and Cyrix (Gnode), Agere Systems, Silicon Core. OHCI, jointly developed by Compaq, Microsoft, and National Semiconductor Corporation and backed by more than 25 companies, defines the register level interface that enables the USB controller to "talk" to the host computer and its operating system. OHCI defines an industry standard hardware interface for operating systems, device drivers, and the basic input output system (BIOS) to manage the USB. OHCI optimizes performance of the USB bus while minimizing central processing unit (CPU) overhead to control the USB. USB devices don't care whether you're using an OHCI or UHCI controller; you can use all devices on any kind of controller.

Then, there is EHCI: Enhanced Host Controller Interface. This is a direction that enables USB 2.0, more to say USB Hi-Speed. The two-direction market as exists for USB 1.1 is not present here; all controllers use the same specific technologies.

One thing you should very well be aware of is that USB is a serial technology. That means that the maximum bandwidth (12Mbps for USB 1.1, 480Mbps for USB 2.0 Hi-Speed) is divided between all USB ports. This also applies to USB Hubs, where this issue should be accounted for more seriously. This problem will be discussed thoroughly in the article about USB hubs; for regular PCI USB controllers, with only a limited number of ports, there should not be any real problems, unless you are using several fast devices, like USB 2.0 harddisks, USB 2.0 Memory Keys, USB Audio, and USB Ethernet cards simultaneously. The problem is even more present on USB 1.x controllers. But remember that if you use a lot of USB devices at the same moment, this unavoidably leads to a performance degradation.

All of these variants are supported using OS/2 Base USB Device Drivers (EHCI.EXE).

1.3. Chipsets
Perhaps your (onboard) USB controller is supported, but you thought OS/2 didn't support it, because some years ago, only UHCI controllers were supported. Recently, that changed: any recent USB controller, whether it is USB 1.1 or 2.0 Hi-Speed should be compatible.

Over the years especially Intel and VIA solutions became very wide-spread, and recently, NEC's µ7201 chip is the standard for PCI USB 2.0 cards. Next, we'll give a brief overview of the most popular chipsets used on USB controllers.Controllers that are, of course, compatible with OS/2.

For OHCI, there are the CMD chipsets: USB0670 and USB0673 chipsets, USS-302 from Lucent Technologies and OPTi 82C861. Most SiS, ALi, and Cyrix (Gnode) chips are also supported.

For UHCI, all Via and Intel chipsets are compatible. Intel has two very popular and wide-spread chips, the 440BX an 440LX. Also nVidia's nForce is UHCI and works smoothly with OS/2.

For EHCI, the main chipsets available today are the NEC µ7201 and the VIA VT6202. These chipsets have also a USB 1.1 aspect for the backwards compatibility, described above: the NEC also supports OHCI, and the VIA UHCI. Without this feature, the USB controllers wouldn't be able to use USB 1.1 devices.

Of course, a lot more chipsets exist, but this section's goal was to list the most popular compatible chipsets. Special mixtures of several unknown chipsets will most probably not work. The table* below lists all chipsets tested by OS/2 CHL:


 * Note that the chipsets listed in the USB 2.0 column also support USB 1.1; no entries for the USB 1.1 compatibilities are added to the table.

2. Base USB Device Driver Installation
The IBM USB Basic Device Driver, also called USB Stack, comes in a self-extracting file. The official driver is available via IBM SoftWare Choice or IBM PassPort Advantage subscriptions, and can be downloaded from the IBM OS/2 Device Driver Pack Online. eComStation 1.0 and 1.1 also include these drivers. An older version that only supports UHCI can be downloaded from the OS/2 Warp USB web site.

In order to use this driver, your computing system must meet the following requirements:
 * OS/2 Warp 3, OS/2 Warp 4 Merlin, OS/2 Warp Server for e-business Aurora, MCP1 or ACP1, MCP2 or MCP2, eComStation 1.0 or higher;
 * Any PCI to USB Host Controller compatible with USB 1.1 or USB 2.0 specification and using UHCI, OHCI or EHCI interface. Only PCI-to-USB controllers are supported, it is not worth the effort to try PCMCIA USB controllers; they will not work.

In fact, this self-extracting file contains three separate drivers; one for EHCI (USBEHCI.SYS), another for OHCI (USBOHCI.SYS), and again another for UHCI (USBUHCI.SYS). The USBBASIC.EXE file, once executed, will extract seven files: the three drivers just mentioned, an underlying driver (USBD.SYS),

the USB Human Interface driver (USBHID.SYS), the Host Controller adapter(s) monitor utility (HCIMONIT.EXE), an installation utility (USBINST.EXE) and USBBASIC.TXT, a limited readme.

2.2.1. USB-Basic Installation Instructions
To install the USB device drivers manually, proceed as follows:

Unlike the powerful USB support in eCS 1.1, eCS 1.0 and the IBM Convenience Packages do install and configure the USB device drivers, but by default, they are REMmed out in config.sys. The USB stack must first be added to the OS/2 Installation diskette labeled "Diskette 1" if you want to use USB peripherals like floppy disk drives, mice and keyboards during installation or when booting from diskette.

If you haven't got boot diskettes, first make them by running cdinst.cmd from the OS/2 Warp installation

cd-rom (or the second cd for the Convenience Packages). You will then be prompted to insert floppies and the program will guide you through the process. Then, refer to the README with the basic USB device driver package for instructions on updating the diskette for the devices.

2.2. eComStation 1.1
Even though eComStation 1.1 uses the very same IBM drivers as MCP, and these drivers offer the same potential of functionality, the eCS crew working on the installer have performed a great job. During this installer, a lot of options can be chosen in that you will have less work later with configuring the individual drivers. This section will only discuss basic USB support installation using the eCS 1.1 installer. If you need to change your USB configuration once eCS has already been installed, you should act as described in the previous section. Right from the very first phases of the installation, the installer reflects that extreme powerful USB support is present. This is a great improvement compared to IBM's CP2 (Convenience Pack 2) strategy, where USB drivers are copied to disk, but are by default REMmed out of config.sys.



The image above shows the third page of the boot options menu. You can get to it by booting from the eCS cd-rom, and selecting boot with menu for own values. Then, you will be guided towards the eComstation BOOT OPTIONS: Keys Help menu. Press ENTER. The eComstation BOOT OPTIONS: Miscellaneous menu appears. Here you can set the codepages, choose which installer you want to use, and set some drive letters. By pressing ENTER, you will get to the screen eComStation BOOT OPTIONS: Storage, where driver options for your controllers, which should be auto-detected, can be set, and drivers can be selected for other controllers that were not detected. By again pressing ENTER, you will get to the screen eComStation BOOT OPTIONS: USB, as showed in the image above. Navigate to the appropriate fields by using the tab button and change the options if necessary. Normally, you shouldn't need to change anything, since USB devices are detected automatically. For each kind of controllers (EHCI, OHCI, UHCI), you can select a maximum of four controllers (mind it; controllers, not ports; a controller has several ports). Using the tab button, navigate to the appropriate fields, and use the up/down arrows to specify the number of USB controllers in the first three fields. Please keep the remark at the end of this section in mind when specifying this number! You can have EHCI, OHCI and UHCI controller support installed simultaneously, so in theory you can use up to 12 USB controllers. Only if at least one USB host controller is selected, you can modify the last fields. By default, these last three options are deselected. Navigate towards the appropriate fields and press space bar to enable support for these devices. If enabled, a V-sign appear between the brackets. The last option, Support USB mass storage devices: has a submenu where you must use the arrows too to specify the number of those USB devices attached to your computer. If you haven't got them, set the number to zero, otherwise select the appropriate number. As was the case for controllers, you can only specify a maximum of four USB floppy disk drives and CD-R(W) devices. Please note that the Support USB mass storage devices: does not install IBM's latest USB MSD driver, so it won't allow you to use USB memory keys; for that, you should install IBM's driver version 1.3 or higher, which can be downloaded from the eComstation web site. Now you have finished the first steps of eCS 1.1 installation. To continue, you must confirm the choices you made, by pressing F10. After some seconds, the graphical installer will appear.



In the image above, you can see the Hardware and peripherals windows from the eCS 1.1 installer. Here, you can review the choices you already made in the eComStation BOOT OPTIONS: USB menu, and also install support for non-USB technologies. Additionally, you can specify any extra USB devices you want to have support installed for by checking the appropriate checkboxes for CD, floppy disk drive, or modem. If you had specified USB controllers in the eComStation BOOT OPTIONS: USB menu, then the current window will reflect your choices. Also, if you had selected floppy disk drives attached under the menu Support for USB mass storage devices:, then this option will already be selected.

From this window, several options can be specified for the USB device drivers. To do so, just click a subentry in the USB Support entry, click in the field Additional parameters near the bottom of the screen, and type the options you wish to add in your config.sys. The options for USB controllers will be covered in the next section of this article, other options will be covered in later articles. Once you're finished with this window of the installer, click Next> to continue with installation.



As usual, OS/2 prefers a unique IRQ for the USB host controller. Even though the IBM USB device drivers were developed to support shared interrupts, in practice, it's best to assign it a unique, legacy IRQ. Experience has learned that it is best to assign your USB controller an IRQ below 6. Of course, other IRQs can also be used, but for some reason problems can occur with higher ones. Recommended is to use IRQ4, thus disabling one of your serials ports.

Something very important is that for each pair of USB ports on a controller, a line specifying the appropriate device driver must be added in your config.sys. For example: a six-port controller requires you to have three lines in your config.sys (or even more if it's USB 2.0: two lines for each pair: one for the driver used for USB 1.1 devices; the other for USB 2.0). If you've got a controller with an odd number of USB ports, then increment the number of cards by one, and take that number to decide how many copies of the driver line should be present in config.sys.

2.3. USB Device Driver Options
There are some config.sys device driver options that come in handy. We'll briefly take a look at them, and discuss whether or not these settings are useful. BASEDEV=USBD.SYS [/I13] [/REQ:USBUHCD$,USBOHCD$,USBEHCD$] [/V]

/I13:

This option allow you to boot from USB devices. Best to add it in config.sys. This switch is also required if you want to boot from USB hard disk drives, floppy drives, memory keys, and other USB mass storage devices.

/REQ:USBUHCD$,USBOHCD$,USBEHCD$:

This switch is some kind of "error protection". It makes sure that the USBD.SYS driver is not loaded when no drivers are loaded for EHCI, OHCI, and/or UHCI controllers. It does impose a very important limitation: the config.sys lines for USBEHCI.SYS, USBOHCI.SYS, and USBUHCI.SYS must be before the USBD.SYS line in your config.sys, otherwise, since OS/2 processes its config.sys top-down, USBD.SYS won't be loaded because the xHCI.SYS drivers are only loaded afterwards it. Using this switch, one of the drivers should be initialized before OS/2 will initialize USBD.SYS. If none were initialized, USBD.SYS won't be loaded. Caution! Mind it to append the EXACT option described above to your config.sys; otherwise, you'll see "Invalid config.sys option" at config.sys. Fortunately, if that's the case, the bad option is ignored and the drivers are loaded appropriately, though without this option. Note the $-signs; normally, an OS/2 device is called by the system and applications by a driver name, followed by a dollar sign. Thus, a UHCI controller is called with USBUHCD$, a OHCI one by USBOHCD$, and an EHCI one by USBEHCD$. Nice to be confronted with internal driver details, not?

Recommendation: append this option to the appropriate line(s) in your config.sys. BASEDEV= EHCD.SYS|OHCD.SYS|UHCD.SYS [/FS] [/V]

EHCD.SYS|OHCD.SYS|UHCI.SYS:

In each line of your config.sys, you can only pick one of these. Of course, when specifying several different lines, you can pick a selection of them. Note that one line only supports up to a set of two USB ports from a controller. If you've for, for example, a controller with five UHCI ports, then you must have three lines "BASEDEV=UHCD.SYS /V" in your config.sys!

/FS:

Forces driver to stop USB host when shutting OS/2 down. This parameter can be used to prevent POST (power on system test) failure on some hardware with legacy keyboard. Recommendation: don't use it! This option can only cause a lot of problems in modern computer systems. BASEDEV=USBHID.SYS [/V]

And then, applicable to all of the drivers above, the /V option forces the driver to display its initialization information. Doing so, during boot, you will get to the the IRQ and I/O addresses from the controller(s) detected.

When specifying these option in the Additional Options field using the eCS 1.1 installer, don't type the beginning of these statements. The only options you may type there are /FS; /REQ:UHCD$,OHCD$,EHCD$; I13 and /V. To avoid problems, always put the /V option as last switch.

3. What you should think of when choosing a USB controller card
This is rather straightforward, actually. With today's extreme low prices for USB controllers, pick one out that is USB Hi-Speed 2.0. You can keep using your existing USB 1.0 or USB 1.1 devices, and in meantime make use of devices like external hard disks that can use USB 2.0's 480Mbps data transfer rate. If you can, go for a controller with the NEC &micro;7201 (EHCI + OHCI) chipset, which offer much greater performance than the equivalent VIA6202 (EHCI + UHCI) chipset. Taken a look at the design and principles of OHCI compared to UHCI, go for OHCI, since this technology uses less CPU time, thus increasing performance. This is also the reason why I advice you to buy USB 2.0 controllers with the NEC7201 chipset (EHCI and OHCI) instead of the VIA VT6202 (EHCI and UHCI). Most new USB controllers are available as add-on PCI cards. However, should you plan to purchase a brand-new computer, then ask your local vendor for a PC equipped with a motherboard with USB 2.0 ports. An on-board controller is a far more elegant solution, and it doesn't waste a PCI slot.

Where USB 1.1 controllers normally came with a default maximum of two ports, a lot of newer controllers, especially 2.0, come with five to six ports. If you want to make intense use of OS/2's USB support, then the best thing would be to purchase a PCI card, since manufacturers tend to impose a limit of a maximum of four ports with on-board controllers.

Nevertheless, OS/2 should support any USB controller available today. One remark I'd like to make is not to use PCI boards with both USB and FireWire ports. I've tried one once, and the card took one IRQ for each technology, and at this moment you just can't use FireWire with OS/2.

4. OS/2 CHL Tested USB Controllers
The following devices have been tested by OS/2 CHL team and have been found 100% compatible with OS/2 and eCS. For the most up-to-date listing of tested devices (this is only subset of those in the list), please consult the [OS/2 CHL] (www.os2warp.be), where you'll also find the appropriate chipsets using in each device.

All USB 1.1 devices should work perfectly with IBM's Convenience Packages and eCS. For USB 2.0 devices, if using something else than eCS 1.1, it is recommended to update the USB device drivers to the most current level of IBM's USB base DDs.

5. And what about Linux?


At this moment only USB 1.1 (OHCI and UHCI) support is fairly complete. Almost every chipset should be able to work. USB support was first introduced in kernel release 2.2.18. For now, USB 2.0 (EHCI) is still under development, but it should work fine with most controllers. USB 2.0 EHCI support has been introduced in kernel release 2.4.18 but will have full support in the new kernel 2.6. The NEC implementation of EHCI (NEC &micro;7201) seems to have a hardware bottleneck at around 28 MByte/sec aggregate transfer rate. While this is clearly enough for a single device at 20 MByte/sec, putting three such devices onto one bus does not get you 60 MByte/sec.

You can find a list of tested devices at []. All chipsets from chapter 1.3 should be supported, except for the NEC &micro;7201. For more information about Linux and USB, visit [].

6. Conclusion
The Universal Serial Bus technology provides a versatile, flexible method of connecting a wide range of low- and medium-speed peripherals to a PC at relatively low cost. Its plug-and-play configuration means that the installation and support of peripherals is much easier compared with devices using the serial, parallel or proprietary interfaces. Of course, compared to professional technologies like SCSI, USB is inferior. All these advantages make the technology well-suited for both home and business use. USB controllers are the basis of USB technology. They allow you to use USB devices using additional device drivers. IBM's basic OS/2 USB device drivers offer great support for a very diverse set of devices; all PCI EHCI, OHCI and UHCI controllers should be supported, and also on-board controllers should be supported.

7. References

 * IBM Device Driver Pack Online
 * IBM SoftWare Choice web site
 * [eComStation Home Page]
 * [OS/2 Compatible Hardware List (OS/2 CHL) web site]
 * [USB vs SCSI comparison]
 * [USB Technical in-depth details]
 * [USB Terminology Compare (Compaq)]
 * [USB Technical in-depth details, superb reference]].

(*): This section is a derived version of an article that appeared some years ago in PC Support Advisor. Although it provides a good general introduction to USB concepts, some of the details are left out since they are not relevant for general daily use of OS/2 USB device drivers.