Tài liệu USB Architecture

Nội dung text: Tài liệu USB Architecture

1. z  USB Architecture
2. USB Architecture A USB system consists of a host computer, one or more USB devices, and a physical bus. The host consists of two layers: an upper software layer, which includes USB device drivers, and a host controller hardware layer, also known as an adapter layer. The main responsibility of the host computer is to control data transfers to and from USB devices. USB devices are peripherals that use the USB electrical and data format specifications to communicate with the host computer. The physical bus is the set of USB cables that links the controller with the peripherals. Bus-powered and Self-powered USB Devices Windows CE 2.10 and later provide full support for bus-powered and self-powered USB devices. When a user connects a self-powered or bus-powered device to a Windows CE–based platform, the USB system software automatically accepts or rejects the device, based on the power requirements of the device. The power model is the same for both bus-powered and self-powered devices. When a USB device is attached to a Windows CE–based platform, the HCD module sets the initial power configuration. During the device attachment processing phase, the HCD module reads the power requirements of the USB device configurations from the device configuration descriptor structures. In this way, the HCD module can choose an appropriate power configuration for the device. Some devices may provide several configurations with different power requirements. OEMs who port an HCD module to their hardware can implement policies to choose the appropriate power configurations from those provided by the USB devices. For example, Windows CE–based platforms have a registry setting that specifies the maximum total current draw allowable for USB devices connected to the host computer. If enabling a device would exceed this power threshold, the device is not configured unless the device has an alternate configuration with acceptable power requirements. OEMs can customize the platform-specific portions of the HCD module to choose dynamically whether to configure devices based on the current system power level. OEMs can implement a power model suitable for their platforms because the HCD module calls platform-specific code in its PDD layer for all USB devices connected to the bus. Therefore, an OEM can implement a power model that can selectively grant or deny power to individual USB devices according to whatever criteria the OEM chooses.
3. Because an HCD module cannot know which configuration might be appropriate for different uses of a USB device, a USB device driver can change its device configuration after the device driver is loaded, to the extent that the new configuration meets overall system power requirements. A USB device driver uses the SetConfiguration function to change a USB device configuration. In the unconfigured state, USB devices may not draw more than 100 mA. Built on Wednesday, October 04, 2000 USB Components Supplied by Microsoft Microsoft supplies the following USB software components: • The USB driver (USBD) module, which loads USB device drivers and manages resources in the USB subsystem. • The complete set of USBD interface functions listed in the Universal Serial Bus Specification, Revision 1.1, implemented by the USBD module. The API set includes transfer functions, pipe functions, device configuration functions, and miscellaneous functions. This API enables developers to write USB device drivers to support any USB devices. • A sample HCD module that works with open host controller interface (OHCI)–compliant USB host controllers. OEMs must port the PDD portion of this driver to their hardware if their platform contains an OHCI host controller. • A sample HCD module that works with universal host controller driver (UHCI)–compliant USB host controllers. OEMs must port the PDD portion of this driver to their hardware if their platform contains a UHCI host controller. Note that the sample UHCI implementation for the CEPC reference platform does not support suspend and resume functionality. To add this support, the sample PDD layer would have to be modified to use the suspend and resume support present in the MDD layer. • A sample USB class driver for human interface devices (HID). Source code for these components is available in \Wince\Public\Common\Oak\Drivers\USB located in the Windows CE Platform Builder. Header files are in \Wince\Public\Oak\Inc and \Wince\Public\Ddk\Inc. Platform sample code is in Platform\Cepc\Drivers\Usb. Built on Wednesday, October 04, 2000
4. USB Device Driver Load Process The USBD module takes the following steps when loading drivers, stopping as soon as it finds a driver that accepts control of the device. The following rules describe the algorithm that the USBD module uses to search for USB device drivers. In the descriptions, GroupX_ID refers to a key with the specified group set to one of the forms described in Registry Keys for USB Device Drivers and the remaining groups set to Default. If multiple drivers are registered within the same group, the one that contains the simplest form is loaded first. For example, a driver specifying a Group1_ID with device class code only, such as Default\DeviceClass\Default, loads before a driver specifying a Group1_ID with device class and subclass code, such as Default\DeviceClass_Subclass\Default. This allows Windows CE to conserve resources by loading as few drivers as possible. This procedure takes the following steps: 1. The USBD module searches for a subkey with the name Default\Default\Default. If present, the module loads the driver listed within the Default\Default\Default\DriverName\DLL subkey. A driver registered in this way is loaded for all USB devices that are connected to the system. 2. The USBD module searches for a vendor-specific driver. Vendor-specific drivers are identified by searching for the most general Group1_ID subkey that matches the device descriptor information. The most general subkey is the one that has a matching Group1_ID subkey containing the simplest allowable form and Default for the Group2_ID and Group3_ID subkeys. If a matching subkey is found, the module loads the driver that is listed within the subkey’s DriverName\DLL subkey. For more information on allowable forms, see Registry Keys for USB Device Drivers. 3. The USBD module searches for a device class-specific driver. Class-specific drivers are identified by searching for the most general Group2_ID subkey. If a matching subkey is found, the module loads the driver listed within the subkey’s DriverName\DLL subkey. The searches in steps 1 through 3 may not yield a matching USB device driver to control the device as a whole; that is, the device may have multiple interfaces, but no driver identified in steps 1 through 3 may match all of the interfaces present on the device. If so, the USBD module takes the following steps to search for matching drivers for each interface present on the device, searching for the most general Group3_ID subkey. If the USBD module finds a matching subkey, it loads the driver listed within the subkey’s DriverName\DLL subkey. Finally, if no appropriate USB device driver is located, the USBD module prompts a user to enter the name of a DLL containing the correct driver. The USBD module then loads the driver and calls the driver’s USBInstallDriver function. USBInstallDriver should create an appropriate subkey for the driver by calling the
5. RegisterClientSettings function so the next time that the USB device is attached, the USBD module can locate the correct driver without prompting a user. In some cases it may be necessary to specify the precedence order to a greater level of detail; for example, combining vendor- and device-class specifiers. In these cases, the GroupX_ID values may be combined to generate other combinations. The precedence for such combinations is as follows, in descending order: 1. Group1_ID\Default\Default 2. Group1_ID\Group2_ID\Default 3. Default\Group2_ID\Default 4. Group1_ID\Group2_ID\Group3_ID 5. Group1_ID\Default\Group3_ID 6. Default\Group2_ID\Group3_ID 7. Default\Default\Group3_ID If multiple drivers are registered at a particular precedence level, the USBD module loads the one with the most general form. Built on Wednesday, October 04, 2000 USB Devices USB peripheral devices consist of one or more physical components that implement the abilities of the devices. These components are called interfaces. Each interface typically provides some useful grouping of functionality, but exactly what constitutes an interface is an implementation detail. For example, a USB mouse device could present one interface for horizontal and vertical movement information and a separate interface for left and right button information. As another option, the device could present a single interface containing all of the information. Both are valid approaches, but each approach has implications for how the device driver must operate. Associated with each interface is a set of endpoints. Endpoints are the ultimate producers or consumers of data that is transmitted across the bus. All USB devices have a special endpoint, known as endpoint 0, which supports the generic USB status and configuration protocol. USB device drivers establish logical communication channels, called pipes, to the various endpoints on a USB device. A pipe is a software association between a USB device driver and an endpoint. Pipes can be thought of as communication channels that use function calls to the USB system software to communicate with their associated endpoints. The characteristics of a pipe, such as the direction of communication and the required bandwidth, are determined by the endpoint characteristics, which in turn are indicated in the endpoint descriptor structure. The bus interface hardware on a USB device is responsible for the transmission and reception of USB-structured data. The logical USB device corresponding to a
6. physical USB device consists of USB abstraction entities, such as the device endpoints and their corresponding pipes. Built on Wednesday, October 04, 2000 Universal Serial Bus Drivers The universal serial bus (USB) is an external bus architecture for connecting USB- capable peripheral devices to a host computer. USB is not designed to be used as the internal bus for connecting CPUs to main memory and to devices that reside on a motherboard. Instead, USB is a communication protocol that supports serial data transfers between a host system and USB-capable peripherals. USB technology was developed as a solution to the increasing user demands on computers and the need for flexible and easy-to-use peripherals. USB technology directly affects a number of standard peripherals, such as keyboards, joysticks, mouse devices, digital cameras, computer telephony integration (CTI), and video-conferencing products. USB offers the following benefits to system designers and users: • USB provides a single, well-defined, standard connector type for all USB devices. This simplifies not only the design of USB devices, but also a user’s task of determining which plugs correspond to which ports on their computer. • USB eliminates the need for separate mouse, modem, keyboard, and printer ports, thus reducing hardware complexity. • USB supports hot plugging, which means that USB devices can be safely connected and disconnected while the host is turned on. Other generic peripheral connection standards, such as the Small Computer System Interface (SCSI), require that the host be turned off when peripherals are added or removed. • USB supports Plug and Play. When a USB device is plugged in, the host computer identifies the device and configures it by loading the appropriate driver. • USB provides flexibility in how devices are powered. USB devices can draw power directly from the USB cable (bus-powered devices), supply their own power from batteries or from a wall outlet (self-powered devices), or use a combination of both types of power. • USB supports power-saving suspend and resume modes. • USB offers a high-speed 12-megabits-per-second mode (Mbps) and a low- speed 1.5-Mbps mode that support a variety of peripherals. • USB guarantees certain amounts of bandwidth for devices that cannot tolerate transmission that comes in bursts, such as streaming audio and video devices.
7. • USB offers four different data transfer types that are suited to the needs of various types of peripheral. • USB enables multiple peripherals to communicate simultaneously with the host. Consult the following sources for additional information about USB technology that is important both for OEMs who add USB support to their Windows CE– based platforms and for independent hardware vendors (IHVs) who build USB peripherals: • USB Implementers Forum Web site This site contains the complete USB specification, Universal Serial Bus Specification, Revision 1.1. • Intel Corporation Web site This site contains information on USB hardware and microcontroller chips, such as the 8x930Ax and 8x931xA series chips. Note The official Universal Serial Bus Specification, Revision 1 uses the term function to refer to USB-capable peripheral devices. However, because function typically refers to callable units of C/C++ code, Windows CE documentation uses the term USB device to refer to USB peripherals. In addition, the official Universal Serial Bus Specification, Revision 1, uses the term USB client driver to refer to device drivers for USB devices, but to avoid confusion with client/server terminology, this documentation uses the term “USB device driver.” Built on Wednesday, October 04, 2000 Supported and Unsupported USB Features Windows CE 2.10 and later support the following USB features: • Bus enumeration Windows CE supports enumeration of USB devices on the bus. The bus enumeration process is a multistep query sequence: the HCD module acquires information from a connected device, assigns it a unique USB address, and sets a configuration value. Once enumeration is complete, the device is configured and ready to conduct, transmit, and receive transactions. At this point, the USBD module attempts to load one or more USB device drivers to control the device, based on the information contained in the device and interface descriptors. If no suitable driver has been registered for the device, a user is prompted to enter the name of a driver to control the device. • Power management Windows CE provides support for bus-powered and self-powered devices. For both types of device, the USBD module reads the power requirements of the device from the descriptor information and rejects the device if it exceeds
8. the maximum power threshold. OEMs can set the current-draw limit, so IHVs should not rely on any particular amount of available current, except as detailed in the Universal Serial Bus Specification, Revision 1. Current-draw limits are enforced by USB hubs, not by the host computer; devices which draw too much current will be shut down by their hub. Hubs that cannot control the power level on individual ports may simply shut down all their ports, or may be forcibly shut down by an upstream hub, when a current over-draw situation occurs. This can cause multiple USB devices to disconnect from the bus if a single device draws too much current. Windows CE does not support complex power saving modes or partial-power modes for USB devices when the Windows CE device is suspended. Instead, the entire bus is shut down. Consequently, Windows CE does not support resuming from suspension in response to the needs of a USB device. Also, Windows CE does not support the remote wakeup feature as described in the Universal Serial Bus Specification, Revision 1. • Transfer types Windows CE supports all four types of data transfer defined in the Universal Serial Bus Specification, Revision 1. USB device drivers can use any of the transfer types that are appropriate for their peripherals. • Class drivers The USB architecture implemented in Windows CE supports loading class drivers. Examples of USB device classes include the human input device (HID) class and the mass storage class, among others. OEMs or IHVs can write their own class drivers and load them appropriately, using the registry mechanism. Windows CE 2.12 and later supports the following features: • Support for integrated and external hubs. Windows CE 3.0 and later supports connecting hub devices up to five levels deep, the maximum allowed by the Universal Serial Bus Specification, Revision 1. Windows CE offers limited support for the following features: • Unknown USB peripherals. Unknown USB peripherals generally cause no problems in Windows CE systems, but under some circumstances connecting an unknown USB peripheral to a Windows CE system that uses completely legacy-free ports and has an OHCI-based host controller can cause the USB subsystem to stop responding. This is rare, but can happen when the USB peripheral does not have a driver installed on the Windows CE system, when an unknown USB peripheral is connected to a running Windows CE system, and then the system is cold- or warm-booted, or when an unknown USB peripheral is connected to a Windows CE system that is powered off and the system is subsequently rebooted. In these cases, other USB peripherals that have been enumerated will continue to function, but
9. device enumeration actions will not complete. You may be able to connect and disconnect an unknown USB peripheral to a running Windows CE system so long as you do not reboot the system, but if problems occur you must disconnect the unknown USB peripheral and reboot the Windows CE system. USB Host Controller The host controller, or adapter, is a hardware layer that is contained within the host computer. The host controller converts data between the format that is used by the host computer and the USB format. Only OEMs who implement Windows CE– based products that use USB need to write drivers for USB host controllers. For more information, see Developing Native Device Drivers USB and WDM Modem Update The USB Device Working Group has completed work on the Communications Device Class (CDC) Specification, Version 1.0. It covers analog modems and telephones. Some IHVs have implemented this specification. Microsoft has built a class driver for USB modems, called Usbser.sys. It is included in the beta release of Windows 98 SP1. It is included in Windows 2000 Beta 3. Usbser.sys is a WDM driver. It is supported by way of the CCPORT mapping layer on Windows 2000, which is also included in Windows 98 SP1. WHQL is currently developing a test program for USB modems. They will begin testing by the time USB modem support is shipping with an operating system, such as Windows 98 SP1. Conclusion Soft modems are appropriate when bundled in some systems, but they require careful design on the part of the modem designer and the system designer. Call to action for soft modems: • All review comments on the soft modem guidelines are welcome. Please send comments to pc99@microsoft.com with Soft Modem in the Subject line. Please include your name, title, company name, and phone and fax numbers. Disclaimer for Working Documents The information contained in this document represents the current view of Microsoft Corporation of the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
10. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Send feedback to MSDN. Look here for MSDN Online resources. USB Power Management Windows CE provides full support for power management of USB devices, as described in the Universal Serial Bus Specification, Revision 1. Very important for Windows CE are support for suspending and resuming, because Windows CE– based platforms have a power-on and startup cycle that differs from the one on desktop computers. Support for bus-powered and self-powered USB devices is also important because many Windows CE–based platforms have limited power resources. For more information about power management, see Developing Native Device Drivers. Windows CE supports power cycling USB devices in association with the standard Windows CE power states. When Windows CE issues a POWER_DOWN notification, the HCD module resets and halts the USB host controller hardware and removes power from the bus, but does not suspend any connected USB devices. When power returns to the platform, Windows CE sends a POWER_UP notification to the HCD module. When the host controller hardware has been re- initialized, the USBD module unloads the USB device drivers loaded prior to the POWER_DOWN notification, identifies all the USB devices that are currently connected to the bus—a process called bus enumeration—and loads the USB device drivers for those devices. This power cycle processing is very similar to that performed by the Windows CE Device Manager for PC Card devices. This implies that USB device drivers may need to take special action to make a power cycle transparent to upper-level applications. For example, if a USB device provides a file system, the device driver should preserve open file handles across a power cycle. There are several ways to accomplish this. One solution is for the USB device driver to register itself with the Device Manager as a stream interface driver by calling the ActivateDevice function. This increments the reference count on the USB device driver’s dynamic-link library (DLL) so that when the USBD module unloads the driver, the driver’s code still remains in memory. The USB device driver could keep any application file handles open and wait for the call to the USBDeviceAttach function, which occurs after the system resumes and the USB device is ready to be used. The disadvantage of this approach is that the driver remains in memory even after the USB device is detached from the system. The second solution is to separate the USB interface from the upper-level file system interface; keep the file system driver code which manages file handles separate from the USB device driver code that actually manages the storage hardware.
11. Windows CE provides full support for bus-powered and self-powered USB devices. When a user connects any self-powered or bus-powered device to a Windows CE– based platform, the USB system software automatically accepts or rejects the device, based on the device’s power requirements and the system’s overall power load. The power model is identical for both self-powered and bus-powered devices. When a USB device is attached to a platform, the HCD module sets the initial power configuration. During the device attachment processing phase, the HCD module reads the power requirements of the USB device configurations from the device configuration descriptor structures. It then calls in to the platform-specific portion of the HCD module to determine if the host platform can support the USB device’s power requirements. An OEM can implement code in the platform- specific portion of the HCD module to test system power status, such as whether the system is running on batteries or is plugged into a power outlet, to assist in making this determination. USB device drivers may be able to choose an appropriate configuration for their devices if that functionality is supported in the OEM’s HCD module. Windows CE does not support placing a USB peripheral into suspend mode programmatically. USB device drivers that are managed by the USBDI module do not receive the normal Windows CE POWER_UP and POWER_DOWN notifications—such drivers are only aware of the USBDI module loading and unloading them at various times. If such a driver needs to track the power status of the system, it can do so by implementing a stream interface and calling ActivateDevice or RegisterDevice so that the driver’s stream interface receives POWER_UP and POWER_DOWN messages. Built on Wednesday, October 04, 2000 Suspending and Resuming Windows CE supports suspending and resuming USB devices in association with the standard Windows CE power states. When Windows CE issues a POWER_DOWN notification, the HCD module suspends the USB host controller hardware and all devices. To achieve this, the MDD layer of the HCD module calls a function in the PDD layer to enable the HCD module to complete any platform- specific processing needed to suspend the host controller hardware properly. Suspending power to the host controller hardware typically causes USB devices connected to a Windows CE–based platform to enter the suspended state. However, this is not recommended for all devices; USB devices that can collect and store data while the host computer is off should not be suspended. When the Windows CE–based platform is turned on again, Windows CE sends a POWER_UP notification to the HCD module. Next, the MDD layer of the HCD module calls a function in the PDD layer. Because the PDD layer is used, OEMs
12. can customize the HCD module to perform any necessary platform-specific processing. Following the call to the PDD layer, the HCD module reinitializes the host controller hardware. When the host controller hardware has been reinitialized, the USB driver module unloads the USB device drivers loaded prior to the POWER_DOWN notification, identifies all the USB devices currently connected to the bus—a process called bus enumeration—and loads the USB device drivers for those devices. This suspend and resume processing is very similar to that performed by the Windows CE Device Manager for PC Card–based devices. Built on Wednesday, October 04, 2000 USB System Software USB system software consists of two layers: an upper layer of USB device drivers and a lower layer of USB functions that are implemented by Windows CE. USB device drivers use the USB functions to establish connections to the devices they control and to configure and communicate with the devices. The lower layer of USB functions performs several interrelated tasks: • Manage all communication between USB device drivers and the host computer’s built-in USB root hub • Load and unload USB device drivers at the appropriate times • Translate data to and from the USB protocol’s frame and packet formats • Perform generic configuration and status-related tasks by establishing communication with the generic endpoint on all USB devices The lower layer is itself composed of two parts—the upper universal serial bus driver (USBD) module and the lower host controller driver (HCD) module. The USBD module implements the high-level USBD interface functions in terms of the functionality provided by the HCD module. USB device drivers use the USBD interface functions to communicate with their peripherals. IHVs and manufacturers of USB devices should make use of the functions that are provided by the USBD to implement their USB device drivers. OEMs are responsible for providing an HCD module to their Windows CE–based platforms so that their hardware properly interfaces with the USBD module. The following illustration shows the two layers of software in the context of the The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. host’s USB hardware and a peripheral device.
13. During a data transfer, the flow of operation typically proceeds in the following sequence: 1. A USB device driver initiates transfers by using USBD interface functions to issue requests to the USBD module. 2. The USBD module passes the requests to the HCD module. 3. The HCD module divides requests into individual transactions, based on its knowledge of the bus and on characteristics of the USB devices that are connected to the bus, and schedules these transactions over the bus. 4. The host controller hardware performs or completes the transactions. Note: the USBD module is layered in order to assist OEMs in porting the USBD module to their USB Host Controller Hardware implementations. Internally, the USBD module contains a set of USBDI functions, in the same way that layered drivers contain DDSI functions. USB device drivers are not allowed to invoke the USBDI functions directly; they should limit themselves to the USBD interface functions. The USBDI functions are described in the Windows CE Driver Development Kit reference section for the benefit of OEMs who need to use them in their USBD module implementations. All transactions on the bus originate from the host side; the peripherals are totally dependent.
14. The following sections on USB system software describe the various components of USB support in Windows CE. The primary goal of USB support provided by Microsoft, aside from enabling IHVs to write device drivers for USB devices, is to help OEMs expand existing USB support on their platforms. Windows CE also has device-side support, which enables Windows CE–based platforms to serve as USB peripherals to other USB hosts. The Windows CE Platform Builder contains sample code implementing device-side support. Built on Wednesday, October 04, 2000 Send feedback to MSDN. Look here for MSDN Online resources. Testing USB Device Drivers There is no extensive USB test suite for Windows CE at this time. The sample USB HID driver and the USB 8x930Ax peripheral kit and evaluation board from Intel Corporation can be used to assist in testing USB scenarios. These are the methods used at Microsoft to test the USB system software for Windows CE. Further details on testing a USB system and the device drivers on an OEM platform are available in the Windows CE Platform Builder. USB Topology USB is a tree-structured bus, which in the vocabulary of the Universal Serial Bus Specification, Revision 1 is a star-tier topology. The host computer contains a single root node, or hub, of the USB tree. This hub mediates between its host computer and any peripheral devices. Hubs have exactly one connection—called an upstream port—to higher levels in the USB tree. Hubs can have up to 64 downstream ports for connecting peripheral devices and other hubs. By connecting hubs together, up to 127 total devices, including hubs, can be attached to the host computer. Peripheral devices are always leaf nodes within a USB bus. However, as a matter of practical implementation, many USB peripheral devices have hubs integrated into them, so users typically do not need to purchase separate USB hubs. The following illustration shows a USB bus with several common peripherals connected. This illustration is modeled after the diagram of a typical USB bus configuration in the Universal Serial Bus Specification, Revision 1, but with the hubs and peripheral devices represented more explicitly.
15. The association of the mouse with the keyboard’s internal hub and the speakers with the monitor’s internal hub is arbitrary. For example, a user could instead connect the mouse to the monitor’s internal hub, the modem to the keyboard’s internal hub, and the speakers to the stand-alone hub in Tier 1 without affecting the system’s functionality and without having to reconfigure any software on the host computer. USB devices and their corresponding USB device drivers should behave identically regardless of the specific bus topology. Built on Wednesday, October 04, 2000 Send feedback to MSDN. Look here for MSDN Online resources. USB Transfer Types Windows CE 2.10 and later support all four types of data transfer defined in the Universal Serial Bus Specification, Revision 1. Device drivers for USB devices can use any of the following transfer types, as appropriate: • Control transfers Control transfers are bidirectional transfers that are used by the USB system software mainly to query, configure, and issue certain generic commands to USB devices. Control transfers typically take place between the host computer and the USB device’s endpoint 0, but vendor-specific control transfers may use other endpoints. • Isochronous transfers Isochronous transfers provide guaranteed amounts of bandwidth and latency. They are used for streaming data that is time-critical and error-tolerant or for
16. real-time applications that require a constant data transfer rate. For example, an Internet telephony application that carries a conversation in real time is a good candidate for isochronous transfer mode. Isochronous data requires guaranteed amounts of bandwidth and guaranteed maximum transmission times. For isochronous transfers, timely data delivery is much more important than perfectly accurate or complete data transfer. • Interrupt transfers Interrupt transfers are used mainly to poll devices to check if they have any interrupt data to transmit. The device’s endpoint descriptor structure determines the rate of polling, which can range from 1 through 255 milliseconds. This type of transfer is typically used for devices that provide small amounts of data at sporadic, unpredictable times. Keyboards, joysticks, and mouse devices fall into this category. • Bulk transfers Bulk transfers are for devices that have large amounts of data to transmit or receive and that require guaranteed delivery, but do not have any specific bandwidth or latency requirements. Printers and scanners fall into this category. Very slow or greatly delayed transfers can be acceptable for these types of device, as long as all of the data is delivered eventually. However, in the absence of any other demands for bus bandwidth, Windows CE processes bulk transfers as quickly as possible. Note: Windows CE 2.10 and later have limits on the amounts of data per transfer. All data transfers using USBDI transfer functions are limited to 8K of data per transfer, due to an internal limitation in Microsoft’s USB implementation. If you are porting USB client drivers from Microsoft Windows NT, Windows 95 or Windows 98, you may need to make changes in your code to enforce a limit of 8K per transfer. Writing USB Device Drivers This section describes how to write device drivers for USB devices running on Windows CE. USB device drivers exist to make the services of peripheral devices available to applications. Although there are no standard mechanisms that USB devices must use to accomplish this, there are various strategies that USB device drivers can adopt, depending on the nature of the peripherals that they control: • Use the stream interface functions A USB device driver can expose the stream interface functions. Applications can then treat the peripheral device as a file and use standard file I/O functions to interact with the device. However, because the Device Manager is not involved in the loading and unloading of USB device driver s, any driver that exposes the stream interface functions must register and deregister its special device file name manually, using the ActivateDevice
17. and DeactivateDevice functions. These functions should be called when the USB device driver is loaded and unloaded, respectively. • Use existing Windows CE application programming interfaces (APIs) USB device drivers can indirectly expose certain types of peripherals to applications if Windows CE has an existing API that is appropriate to the peripheral. For example, USB device drivers for mass storage devices, such as hard drives and CD-ROM drives, can expose such devices through the standard installable file system interface. Similarly, a USB mouse device could use this strategy. The driver would not expose the mouse device directly to applications; rather, it would interact with existing Windows CE APIs to submit the correct input events to the system. Thus, the USB nature of the mouse device is transparent to applications. • Create a custom API specific to a particular USB device driver This strategy does not place any restrictions on the way that a USB device driver exposes a device. It allows you to create an API for the device that best maps to the ways that applications are likely to use it. However, you must provide appropriate documentation to application writers so that their applications can use the driver. Built on Wednesday, October 04, 2000 Common Driver Problems The following are descriptions of common driver problems and issues: • The attach and detach functions should never go into infinite loop—or, hang. If a function does hang, no more USB device drivers can be loaded and it appears that the USB cannot enumerate the devices. • The attach and detach functions should take as little time as possible. If it takes too long, the UI application may become confused and think that the device is unplugged during ‘ignition off’ and plugged back in after ‘ignition on’. • The device driver should implement external thread entrance/exiting counting. Since the USB client device driver DLL can be unloaded at any time—‘ignition off’ can occur at any time—any external thread that is executing inside the DLL at the time may be terminated and cause an exception in the calling applications. To avoid this, thread counting must be implemented in most functions—especially those _Read, _Write and IoControl—that could be called by other threads. And, the detach function must wait until the thread count goes to zero before returning. • When calling USB::IssuexxxTransfer function with a completion callback function, the callback function simply calls SetEvent and returns.
18. • In the detach function, the client driver should call UnregisterNotificationRoutine. The notification is identified by both the callback address and the parameter. So, you must unregister with the same parameters you used to register the notification. • In Windows CE 2.12 or earlier, there is a performance bug related to manual–reset event. Don’t use a manual–reset event in time–critical threads. • The attach/detach function should not call IssuexxxTransfer function. Built on Thursday, January 25, 2001 Components of USB The foundation for a test approach requires a basic understanding of functional dependency and relationships. However, the order in which to go about beginning the actual approach may differ from the order of logical dependency. A tip in starting is to approach testing USB from a user point of view, keeping in mind the coverage of the logical and physical integration and cross–dependencies, in order to affirm completeness in coverage. The information in the following paragraphs encourage the creation of a simple test approach. The following diagram shows the USB architecture for an automotive computing device:
19. Transfer Types USB supports the 4 basic transfer types listed below. For more information, see Further Reference_apctest_Further_Reference. • Interrupt (Keyboard, Legacy) • Bulk (CUEđ, Vetronixđ Box) • Isochronous (CD Changer) • Control (All) Built on Thursday, January 25, 2001 How WCEfA USB is different from Desktop PCs The primary differentiating factor between WCEfA USB and Desktop PC USB is the type of physical connector. Automotive computing devices use the Hiroshi type connector. In addition to the data and 5 volt power, this connector provides the 12 volts typically found in the car environment. In the car environment, the USB chain experiences high frequency power cycles from the root node. To attach a function, use the USBDeviceAttach function in the USB client driver. To detach a function, use the USB_CLOSE_DEVICE handler of the USBDeviceNotifications function in the USB client driver. The following list describes hardware actions and the expected response for each: • Warm boot – the attach function is called. • Hot unplug – the detach function is called. • Hot plug–in – the attach function is called if the device driver is already registered. • Ignition Off/Faceplate Detached – nothing is called. • Unplug and Plug during Ignition Off – nothing is called. • Ignition On/Faceplate Attached – the USB host controller enumerates all the USB devices connected. A thread—with the highest priority—will call the detach function of each loaded device driver, one by one. The same thread will call the attach function for all the currently connected device drivers, one by one, if the device driver is registered. Built on Thursday, January 25, 2001 Send USB Configurations A USB network is composed of a master host computer that is connected to slave USB devices. These devices may have a single function, such as a cell phone, or may contain a hub connection that allows other USB devices to be chained to them.
20. This creates a tiered-star architecture that may be expanded to multiple levels. Examples include the following: A USB network may support up to 127 devices. This limit is due to the device address field being limited to 7 bits. The Auto PC is limited to four tiers and only one hub below the host hub. This counts the Auto PC as the first tier with three layers below it. Built on Thursday, January 25, 2001 Send feedback to MSDN. Look here for MSDN Online USB Connectivity USB offers a reliable, high-speed alternative to a standard serial port for connecting a Windows CE-based platform to a desktop computer. Windows CE 2.10 and 2.12, however, could not support USB connectivity to desktop systems, unless an OEM implemented that functionality. Windows CE 3.0 and later, however, do offer connectivity through USB. Windows CE 3.0 and later provide a USB Function controller driver for Windows CE-based platforms that include the appropriate USB Function controller hardware. By means of this driver, the USB Function controller hardware appears to Windows CE as a virtual serial port. Similarly, the desktop computer must have a similar host-side USB serial driver. With the Windows CE-based platform and the desktop computer so configured, the standard serial-port based mechanisms for connectivity can be used over a USB connection. OEMs can find the files necessary for implementing USB connectivity in the platform\cepc\drivers\serial_sl11\ directory of their
21. Microsoft Windows CE Platform Builder installations. These files support the Scanlogic Corporation’s SL11 USB Function controller chipset. For complete information on implementing a virtual serial port via USB on a Windows CE-based platform, see Sample USB Function Controller Driver. There is, however, still no support for making a Windows CE–based platform itself appear as a USB peripheral to other host computers. This is because Windows CE only implements the host side of the USB client/host architecture. That is, the HCD and USBD modules supplied in Windows CE do not provide facilities to connect a Windows CE–based platform to a desktop computer that is running as a USB host. An OEM could implement this functionality if desired, although, as with the above connectivity scenarios, the Windows CE-based platform would still require USB Function controller hardware. Built on Wednesday, October 04, 2000 Send feedback to MSDN. Look here for MSDN Online resources. USB Connector The connectors on the reference platforms are the standard 4-pin USB type intended for the desktop environment and are only used during development and testing. The Auto PC reference hardware documentation refers to an eight-pin connector designed by Hirose (part number GT17-8DP-DS) and meant for a car’s high- vibration and wide-temperature-range environment. The pinout is as follows: Pin Number Pin Function 1 +5V 2 Data - 3 Data + 4 GND 5 GND 6 Wakeup2 7 Remote Power 8 +12V Main battery Two wires are used for the USB standard serial data bus. This data bus is shared by the Auto PC and its USB slave devices. The data rate is typically 12 megabits per second (Mbps), but there is an optional 1.5 Mbps mode. In accordance to the USB standard, the data is differentially driven to improve noise immunity. The USB connector can also supply power to the hubs and devices on the USB network. While some devices are self-powered from their own power supplies, others pull power from the USB connector. The Auto PC USB connector supplies two power sources of +5V and +12V.
22. The +5V supply is specified by the USB standard and is required to provide a maximum of 600 mA continuous. The +12V line is added by the Auto PC design and continuously supplies a maximum of 3 A. The Auto PC USB connector also adds two signal lines for use in wakeup modes (labeled Wakeup2 and Remote Battery). The OEM system designer can use these signal lines to allow USB peripherals to signal the Power Management System to trigger a power event. This allows the Auto PC to transition from a powered-down state to a partial-power state to process information from the USB peripheral; for example, to store a page message. See the Power Management specification for more information. Built on Thursday, January 25, 2001 Requirements for the Generic Bus Driver Model Microsoft Corporation December 1998 This article is intended for hardware device designers for all operating systems, not just the Microsoftđ Windowsđ 98 and Windows 2000 operating systems. It describes a generic model for device enumeration that can be performed by any operating system to discover and enable the hardware devices it finds on a platform. This generic model imposes design requirements for hardware devices that run on the platform: devices must be discoverable, self-describing, and multiplexable. Universal Serial Bus (USB) devices are examined in this article to determine how well they correspond to this generic model and meet these device design requirements. However, these ideas are not specific to USB; they can be applied to other buses. In general, all operating system designers strive to meet these goals: • Provide an enhanced user experience. An operating system is successful from the users' point of view if the system is easy to use and easy to upgrade. • Enable multiple devices from multiple Independent Hardware Vendors (IHVs) to run transparently. An operating system is successful from the hardware vendors' point of view if the operating system treats equally all devices running on the platform. The operating system must allow a device to run on a platform regardless of the device class, device manufacturer, and presence or absence of any other particular device on the platform.
23. • Facilitate development of IHVs software. Ideally, IHVs would not have to write a device driver for their device to run on the platform. If a driver is required, it should consist of a small amount of code with the simplest logic possible. This article describes two types of operating systems, arbitrarily called "Type 1" and "Type 2," and compares how well they meet the three goals in relation to hardware configuration. How a Type 1 Operating System Searches for Hardware Devices A Type 1 operating system loads drivers on speculation and expects the driver code to search for its own hardware. The loaded driver searches for its hardware using a device-specific method that typically touches all the devices already installed on the platform. Problems with this method are: • Detection methods used by drivers might conflict with hardware already installed on the platform. For example, if a platform has a drill press installed, the detection method used by a newly installed driver could inadvertently start up the drill press, causing material damage. • Detection methods can inadvertently detect a device other than the one the loaded driver controls. • This method requires the operating system to load all possible drivers. • When loaded, the driver must assume its hardware is present; however, drivers are loaded whose hardware is not present. • Hot plugging and unplugging of devices is not quick or easy. This list shows that a Type 1 operating system does not promote the two higher priority operating system design goals: enhanced user experience and interoperability of devices. A Type 1 operating system might promote the lowest priority goal: it can be easier for IHVs to write drivers for their devices because the driver logic assumes the IHV's device is present whenever the driver is invoked, and the driver simply begins using a device. However, this simplifying assumption can lead to some of the problems listed that do not promote the higher priority goals of a good user experience and interoperability of devices.
24. How a Type 2 Operating System Searches for Hardware Devices A Type 2 (Plug and Play) operating system uses components called "bus drivers" each time the system boots to discover and enable the hardware devices currently installed on the platform. If the bus supports it, bus drivers can also handle hot plugging and hot unplugging of devices between boot events. A Type 2 operating system promotes the higher priority operating system design goals. • The user experience is enhanced because the operating system automatically adjusts to hardware configuration changes and can easily handle hot swapping of devices. • Interoperability of devices on the bus is promoted because functions on the bus can come from multiple IHVs and generic extensions are possible at any time. Generic Bus Driver Model Each bus driver sees its bus in a simple, general way: some number of "functions" is currently attached to the bus, which the bus driver owns. All functions look alike to a bus driver. See Figure 1. Figure 1. Generic bus driver model In this model, the bus driver discovers hardware functions first, then loads drivers only as they are needed. The bus driver can even prompt the user when it discovers a device and finds no driver is installed for that device. To keep it simple, the bus driver maps each function to one driver (there is a one-to-one mapping of a hardware function to a loaded device driver). To select the driver to load, the bus driver requires no device-specific information and no information about what other functions are currently attached to the bus. The generic bus driver that enables a Type 2 operating system has the following characteristics: • A bus driver sees its bus in a simple, general way. For a bus driver, there are no device class dependencies. The membership of an attached function in one device class or another (for example, storage, audio, input, and so on) is transparent to the bus driver.
25. • A bus driver discovers all functions using the same method. Specifically, and most importantly, the bus driver requires no knowledge of what functions are already on the bus, or their state, to discover another function. A simple example of this is shown in Figure 2, where functions "X" and "Y" are shown enclosed in one hardware device container; however, the bus driver does not need to know anything about "X" to discover "Y" and vice versa. • A bus driver creates an abstraction (in the form of a data structure) for each function it discovers. The driver that the bus driver loads to control the discovered function uses this abstraction to access its function. • A bus driver does not load a driver for a function not currently attached to the bus. Figure 2. Generic bus driver model when two functions are contained in one device Bus Driver and Device Requirements for a Generic Driver Model Bus driver code does the following: • Discovers ("enumerates") all functions on the bus. • Determines the capabilities of each function. For example, what resources, such as I/O ports, memory ranges, IRQ ranges, power, and/or bandwidth, can the function use? What driver(s) can control the device? • Loads a driver for each function it discovers. • Gives each function a unique structure or handle (provides an abstraction that allows the loaded driver to access its function). For a device, or function, to participate in the generic bus driver model, it must be: • Discoverable - When the function is attached to the bus, it can be found by the bus driver. • Self-describing - The function must describe itself to the bus driver so the bus driver can find a driver to load.
26. • Multiplexable - Each function must be individually controllable with no cross-dependencies between functions (access to one function does not require knowledge of another function's state or access to another function). Applying the Requirements to USB Devices and Interfaces Some USB device designs fit the generic bus driver model by meeting the requirements of discoverability, self-description, and multiplexability. Other USB device designs do not fit the model, with consequences described in the following section. Note USB hardware functions are described either at the device level (in the device descriptor) or at the interface level (in an interface descriptor). Simple USB devices meet all three requirements for participating in the generic bus driver model: • Discoverable - Each device plugs into one USB port. • Self-describing - The device descriptor in ROM describes the device. • Multiplexable - Each device has a unique USB address. Most USB devices can be further enumerated by functional interface, beyond the simple device itself. USB devices of this type may not meet the requirements of discoverability and multiplexability. • Discoverable - If special information is required in descriptors to group interfaces into functions, this is a problem for a generic bus driver. • Self-describing - The interface descriptor in ROM describes the function to a generic bus driver, so there is no problem. • Multiplexable - If a function cannot be controlled independently of other functions, this is a problem for a generic bus driver. Examples of Problems with Some USB Devices The USB Audio class specification requires multiple, interacting interfaces to perform a single function. This means the USB bus driver must "discover the function" by lumping together some predetermined set of interfaces, requiring Audio class-specific information in the descriptors and Audio class-specific (special-case) code in the USB bus driver. This special-case code means that not every function looks the same to the USB bus driver. The USB Communications class specification requires two interacting interfaces to perform the single function of "legacy modem." The USB bus driver must contain code that uses Communications class-specific information in the device descriptor to recognize yet another special case. (See to obtain
27. current versions of USB Class Definition for Communications Devices, USB Device Class Definition for Audio Devices, and USB Specification.) Current USB bus driver code must contain blocks of special-case code for two class-specific exceptions to the generic model for device enumeration: one for the Audio class and one for the Communications class. This increases the complexity of the code, and fully testing the code is more difficult. This has a potential negative impact on the end users' experience with USB devices and the interoperability of USB functions on a platform. An objective at Microsoft is to add no more special-case code to the Windows USB bus driver. Call to Action for Designers of Future USB Devices: Designers of future USB devices are strongly encouraged to use one of the following design alternatives, so the device fits the generic bus driver model required by the USB bus driver. • Build one USB device that has one function. • Build one USB device that has multiple, independently operating functions with a one-to-one mapping of device functions to USB interfaces. By using one of these two alternatives, the IHV does not have to write a driver to do class-specific enumeration, and new classes will not need new enumerators. Note When a USB device designer does not use one of these design alternatives, an additional driver that does the class-specific device enumeration must be provided. In the beginning, this driver must be written by the IHV but might eventually be provided by the operating system vendor. Call to Action for Device Designers of Future Devices on Other Buses: • Buses other than USB, including new buses in the future, have bus drivers that use the generic device enumeration model presented in this article. • Designers of devices for these buses must understand what the generic bus driver model means for a device on that bus and strive to design devices that are discoverable, self-describing, and multiplexable. Send feedback to MSDN. Look here for MSDN Online resources. USB Host Controller A USB network has a master/slave organization. All device control, initialization, and data exchanges are initiated and controlled by a host controller. There are currently two standards in place for USB host controllers.
28. The Open Host Controller Interface (OHCI) standard was created by Compaq, Microsoft, and National Semiconductor. The Auto PC uses this host controller for the following: • Auto PC Reference Platform (APCRP) using the Hitachi SH4 • Hitachi GERP platform The Univeral Host Controller Interface (UHCI) standard was created by Intel. The Auto PC uses this host controller for the following: • Auto PC Reference Platform (XRP) using the Intel 0x86 The WCEfA v3.0 release continues to support both UHCI and OHCI. The OEM makes the decision over which controller interface to use. Built on Thursday, January 25, 2001 Legacy Support for USB Keyboards and Mice and the Host Controller Driver Microsoft Corporation December 3, 1998 The operating system brings a Universal Serial Bus (USB) host controller to an operational state using the following steps: • Load the host controller driver and find the host controller. • Verify the host controller and allocate system resources. • Take control of the host controller. • Set up host controller registers and host controller communications area (HCCA). • Start sending Start of Frame (SOF) tokens on the USB. This article examines the third step of the process—taking control of the host controller—in the context of providing a solution to the problem of legacy keyboard and mouse support when a USB keyboard, mouse, or both are attached to the PC. The information in this article applies to both Microsoftđ Windowsđ 98 and Windows 2000. USB support in Windows 98 and Windows 2000 is designed based on these assumptions: • System vendors want to support USB keyboards and mice when the BIOS has control of the system (for example, the USB keyboard works when the BIOS Setup program is running or the system is running in MS-DOSđ mode).
29. • Host controller hardware and firmware vendors provide some amount of support for the emulation of PS/2-compatible keyboards and mice by USB keyboards and mice. Under conditions where these assumptions are met, this article describes the way Windows host controller drivers hand off USB keyboard and mouse interrupt processing between the operating system and the BIOS. The implementations used by the Open Host Controller Interface (OHCI) host controller driver and Universal Host Controller Interface (UHCI) host controller driver differ because of fundamental differences in the OHCI and UHCI specifications. Both implementations are described in this article. The operating system/BIOS handoff of legacy keyboard and mouse support is a two-way process. In other words, the handoff can occur from the BIOS to the operating system or from the operating system to the BIOS. Both handoff directions are described in this article. An example sequence of events that involves handoff of the host controller in both directions is shown in Figure 1. Figure 1. Example sequence of events in handoff of the host controller The time line in Figure 1 starts with a power-up (cold boot) event on the PC. • Immediately after power-up and for some period of time, the BIOS controls the PC and the host controller. During this time interval, a user should be able to use a USB keyboard to enter BIOS Setup and use all keys on the USB keyboard that are valid during BIOS Setup. • If the user does not choose to enter BIOS Setup, the BIOS starts the operating system at some point and the operating system takes control of the PC and the host controller. As shown in Figure 1, code in a routine in the operating system host controller driver performs the necessary steps to hand off control of the legacy keyboard support function from the BIOS to the operating system host controller driver (in this article, that routine is called StopBIOS). • The next event shown in Figure 1 occurs when the user employs the Shutdown menu to shut down to MS-DOS. This causes the host controller driver to be unloaded; before unloading, it executes a routine that performs the necessary steps to hand off control of the legacy keyboard support
30. function to the BIOS (in this article, that host controller driver routine is called StartBIOS). Hand Off for the OHCI Host Controller The host controller driver is responsible for a per-host controller set of data called device data. At startup and shutdown, the host controller driver manages the host controller through a set of Operational Registers. These registers are part of the host controller and are accessed by the host controller driver using memory references through a noncached virtual pointer. As defined in the OHCI specification, legacy keyboard and mouse emulation is provided by a set of registers controlled by code running in System Management Mode (SMM). When data is received from the keyboard or mouse, the SMM emulation code is notified and translates the USB keyboard/mouse data into a data sequence that is equivalent to what would be produced by a PS/2-compatible keyboard/mouse interface. This emulation scheme is described in the "Operational Theory" section of Appendix B in the OHCI specification. Interrupts generated by the host controller emulation hardware when USB keyboard or mouse data is received are steered by the host controller hardware to either a system management interrupt (SMI) or the standard host controller interrupt. The host controller uses these rules to steer the interrupt: • When the InterruptRouting bit in the host controller HcControl register is cleared, interrupts are steered to the standard host controller interrupt. • When the InterruptRouting bit is set, interrupts are steered to the SMI interrupt. Note SMM is a processor mode in Intelđ Architecture platforms that is transparent to the operating system and application software. SMM is intended for use only by firmware. SMM is one of the processor's major operating modes, on a level with protected mode, real-address mode, or virtual-86 mode. An external signal, SMI#, causes the processor to switch to SMM; this is known as the SMI interrupt. The SMI# signal might be generated, for example, by closing the lid of a portable computer. When the processor recognizes an SMI# signal, the processor waits for all stores to complete and saves state. Then the processor begins to execute the SMM handler in firmware. Power-Up Processes The SMM driver gets control of the processor before any other driver. The SMM driver must set the InterruptRouting bit to cause all host controller interrupts to be routed to the SMI interrupt. The SMM driver then sets system-specific fields in the host controller registers, waits at least the minimum time specified in the USB Specification for assertion of reset on the USB, and then sets up the host controller.
31. Operating System Takes Control of the OHCI Host Controller Later, when the host controller driver is loaded and running, it can determine that the SMM driver is active because the InterruptRouting bit is set in the HcControl register. When it wants the interrupts steered to the standard host controller interrupt, the host controller driver sets the OwnershipChangeRequest bit in the HcCommandStatus register, then monitors the InterruptRouting bit to determine when the ownership change has taken effect. The following pseudocode shows the structure and logic of the entire StopBIOS routine in the Windows OHCI host controller driver. Notice that the StopBIOS routine is called from only one place in the host controller driver, from the OpenHCI_InitializeHardware routine. Get a pointer to a per-device, per-host controller data structure If InterruptRouting bit is set to 1 // SMM driver owns host controller. Set OwnershipChangeRequest bit While total time elapsed is less than 0.5 seconds Wait 1 ms Read InterruptRouting bit If InterruptRouting bit is cleared //SMM has relinquished ownership. Set LEGACY_BIOS_DETECTED bit in per-device, per-host data structure Return (STATUS_SUCCESSFUL) Endif Endwhile // 0.5 sec have elapsed and SMM has not relinquished control. Endif Return (STAUS_UNSUCCESSFUL) Note that a return of STATUS_UNSUCCESSFUL can result in a Code 10 message appearing in the Device Manager entry for the OHCI host controller. BIOS Takes Control of the OHCI Host Controller The following pseudocode shows the structure and logic of the entire StartBIOS module in the Windows OHCI host controller driver. Notice that the StartBIOS routine is called only after the host controller driver will not touch the hardware again. Get pointer to per-device, per-host controller data structure If LEGACY_BIOS_DETECTED flag set in per-device, per-host controller data structure //hand back control of host controller to SMM driver. Set OwnershipChangeRequest bit in HcCmd register Set OwnershipChange interrupt enable bit in HcInt register Set MasterInterruptEnable bit in HcInt register Endif Return(STATUS_SUCCESSFUL)
32. Hand Off for the UHCI Host Controller Section 5 of the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1 gives an example implementation of mouse and keyboard legacy support and describes one way to hand off control of the host controller between the BIOS and the UHCI host controller driver in the operating system. The key UHCI register used in the example is the legacy support register (LEGSUP). For implementers in a PCI device, the LEGSUP register is located at offset C0-C1h, in function 2 PCI configuration space. The Microsoft UHCI host controller driver also uses the LEGSUP register as the primary interface in implementing the handoff of the host controller between the operating system and the BIOS; the Microsoft host controller driver implementation logic is described in this section of the article. LEGSUP register structure. The LEGSUP register is a bitmap containing 16 bits. The meaning of each of the 16 bits is fully specified in Section 5 of the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1. A summary description is given in the following table so the reader can interpret the bitmap constant values used in later sections of this article without referring to the Design Guide. Table 1. LEGSUP register structure Bit Name Description 1 = A20GATE passthrough sequence has 15 (R/WC) A20PTS ended. 14 Reserved. 1 = USB interrupt is routed to PIRQD (default). 0 = Not routed to PIRQD. This bit 13 (R/W) USBPIRQDEN can be used to prevent the host controller from generating an interrupt. 12 (RO) USBIRQS 1 = USB IRQ is active. 11 (R/WC) TBY64W 1 = Write to port 64h has occurred. 10 (R/WC) TBY64R 1 = Read to port 64h has occurred. 9 (R/WC) TBY60W 1 = Write to port 60h has occurred. 8 (R/WC) TBY60R 1 = Read to port 60h has occurred. 1 = Enable generation of an SMI when 7 (R/W) SMIEPTE A20GATE passthrough sequence has ended. 0 = Disable (default). 1 = A20GATE passthrough sequence is 6 (RO) PSS currently in progress. 0 = Not executing (default). 5 (R/W) A20PTEN 1 = Enable A20GATE passthrough sequence.
33. 0 = Disable (default). 1 = Enable SMI# generation on USB IRQ. 4 (R/W) USBSMIEN 0 = Disable (default). 1 = Enable I/O Trap and SMI# generation of 3 (R/W) 64WEN port 64h write. 0 = Disable (default). 1 = Enable I/O Trap and SMI# generation of 2 (R/W) 64REN port 64h read. 0 = Disable (default). 1 = Enable I/O Trap and SMI# generation of 1 (R/W) 60WEN port 60h write. 0 = Disable (default). 1 = Enable I/O Trap and SMI# generation of 0 (R/W) 60REN port 60h read. 0 = Disable (default). How the Microsoft host controller driver uses the LEGSUP register. The Microsoft UHCI host controller driver writes the following value to LEGSUP for normal HCD use: 0x2000. Note that this sets bit 13 and clears bit 4, which routes USB interrupts to PIRQD and disables SMI# generation on a USB IRQ event. The host controller driver sets bit 4 for BIOS/SMI use, which enables SMI# generation on a USB IRQ event. SOF MODIFY register. The SOF MODIFY register is a one-byte register that can be used to modify the value used to generate timing on the USB. (For more information, see section 2.1.6 of the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1.) Guidelines for modification of frame time are contained in Chapter 7 of the USB Specification. How the Microsoft host controller driver uses the SOF MODIFY register. When the Microsoft host controller driver takes control of the host controller from the BIOS, it always reads the value of the SOF MODIFY register value established by the BIOS and saves it in a per-device, per-host controller data structure. USB COMMAND (USBCMD) register structure. The USBCMD register is a bit- map containing 16 bits. The meaning of each of the 16 bits is fully specified in Section 2.1.1 of the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1. A summary description is given in the following table so the reader can, without referring to the Design Guide, interpret the CMDREG bits that are set and cleared in the pseudocode in later sections of this article. Table 2. USBCMD register structure Bit Name Description 15:8 Reserved. 7 (R/W) MAXP 1 = 64 bits.
34. 0 = 32 bits. Host controller driver software sets this bit as the last action in its process of configuring the host controller; 6 (R/W) CF has no effect on the hardware. Provided only as a semaphore service for the software. 1 = Debug mode. 5 (R/W) SWDBG 0 = Normal mode. 1 = host controller sends Global Resume signal on the 4 (R/W) FGR USB. 3 (R/W) EGSM 1 = host controller enters Global Suspend mode. 1 = host controller sends Global Reset signal on the 2 (R/W) GRESET USB and then resets all its logic. 1 = host controller resets its internal timers, counters, 1 (R/W) HCRESET state machines, and so on to their initial values. 1 = Run (host controller proceeds with execution of the schedule). 0 (R/W) RS 0 = Stop (host controller completes current transaction and then halts). How the Microsoft host controller driver uses the USBCMD register. When it takes control of the host controller from the BIOS, the Microsoft host controller driver clears the RS bit to stop the host controller and clears the CF bit. USB STATUS (USBSTS) register structure. The USBSTS register is a bitmap containing 16 bits. The meaning of each of the 16 bits is fully specified in Section 2.1.2 of the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1. A summary description is given in the following table so the reader can, without referring to the Design Guide, interpret the CMDSTS bits that are set and cleared in the pseudocode in later sections of this article. Table 3. USBSTS register structure Bit Name Description 15:6 Reserved. 5 (R/WC) HcHalted Set to 1 by host controller when it is halted. Set to 1 by host controller when it encounters a Host Controller 4 (R/WC) consistency check error while processing a Process Error Transfer Descriptor. Host System Set to 1 by host controller when a serious error 3 (R/WC) Error occurs during a host system access. Set to 1 by host controller when it receives a 2 (R/WC) Resume Detect RESUME signal from a USB device. 1 (R/W) USB Error Set to 1 by host controller when completion of a
35. Interrupt USB transaction results in an error condition. Set to 1 by host controller either when completion 0 (R/W) USBINT of a USB transaction causes an interrupt or when a short packet is detected. How the Microsoft host controller driver uses the USBSTS register. During the process of taking control of the host controller from the BIOS, the Microsoft host controller driver monitors the HcHalted bit to determine if and when the host controller is halted. Operating System Takes Control of the UHCI Host Controller When the host controller driver is loaded and running, it can determine whether the platform has a USB BIOS by the bits set in the LEGSUP register. A USB BIOS is a BIOS that contains code to: • Configure the host controller. • Enable a USB keyboard and mouse. • Set up the host controller scheduler. • Route USB keyboard and mouse input to the 8042 Keyboard Controller (KBC). When a USB BIOS boots, if it contains the code that does the functions listed above and has legacy keyboard support enabled, then it should always set bit 4 of the host controller LEGSUP register and make sure bit 13 is cleared. Conversely, when a BIOS boots that does not contain the code that does the above functions or when it contains the code but has legacy keyboard support disabled, the BIOS should always set bit 13 of the LEGSUP register and make sure bit 4 is cleared. This will ensure the appropriate interaction between the BIOS and the Windows UHCI host controller driver. The following pseudocode shows the structure and logic of the entire StopBIOS routine in the UHCI host controller. Get a pointer to the per-device, per-host controller data structure Read current value of SOF MODIFY register into data structure Read current value of USB COMMAND REGISTER into data structure Read current value of USB INTERRUPT ENABLE REGISTER into data structure Read upper 20 bits of FRAME LIST BASE ADDRESS REGISTER into data structure // Override SOF MODIFY value from BIOS with value in Registry, if there is one. If SOF MODIFY value is in the Registry Read SOF MODIFY value from Registry Save SOF MODIFY value read from Registry in data structure Endif
36. // Prepare first host controller command. Read current value of USB COMMAND REGISTER Clear RS bit in the USB COMMAND REGISTER // Will stop host controller. Clear CF bit in the USB COMMAND REGISTER // Will signal BIOS that OS has control. Write new value to USB COMMAND REGISTER // Wait until host controller halts. While total time elapsed is less than one millisecond Write 0xFF to Interrupt Status Register // Clear all pending interrupts. If HcHalt bit in USB STATUS REGISTER is set Break // Host controller has halted. Endif Endwhile Read the current value of the LEGSUP register Save read value of LEGSUP register in data structure // If any bits in the bit pattern 0x00BF are set in read LEGSUP value, then the platform // BIOS has legacy keyboard support code and legacy keyboard support is enabled for // the platform. If ((LEGSUP value) AND (0x00BF))!= 0 then Set USBBIOS flag in data structure // Platform has USB BIOS. Clear SMI enable bit (bit 4) in read LEGSUP value Write new value to LEGSUP register Read current value of LEGSUP register Write 0x2000 to the LEGSUP register // Route USB interrupt to PIRQD and // disable SMI# interrupt generation. Endif Return(STATUS_SUCCESSFUL) BIOS Takes Control of the UHCI Host Controller The following pseudocode shows the structure and logic of the StartBIOS routine for the UHCI host controller. Note that whenever StartBIOS is executed, it can be assumed that StopBIOS has been executed earlier; all StartBIOS calls are conditional and performed only if the USBBIOS flag is set in the per-device, per- controller data structure maintained by the host controller driver. This means that a set of host controller register values the BIOS needs to take control of the host controller are saved in the same data structure. Get pointer to per-device, per-host controller data structure // Clear all pending interrupts. Write 0xFF to Interrupt Status Register // Restore host controller register values saved at last BIOS to operating system handoff. Write value from data structure to HC USB INTERRUPT ENABLE REGISTER Write value from data structure to HC FRAME LIST BASE ADDRESS REGISTER // Enable routing of USB keyboard and mouse interrupts to SMI#. Write value from data structure into HC LEGSUP register Read value of HC LEGSUP register into data structure Set USBSMIEN bit (bit 4) of LEGSUP register value in data structure Write new value from data structure into HC LEGSUP register // Start host controller schedule.
37. Write value from data structure into HC COMMAND REGISTER Set RS bit of COMMAND REGISTER value in data structure Write new COMMAND REGISTER value to HC COMMAND REGISTER Return(STATUS_SUCCESSFUL) HID Draft #4 Compliance Note In the USB HID Device Class Definition for Human Interface Devices, Draft #4, the HID descriptor has been repositioned within the Configuration descriptor; the correct order is now Configuration/Interface/HID/Endpoint. The HID USB driver supplied with Windows 98 and Windows 2000 looks at the order of the descriptors within the Configuration descriptor to determine whether a device is Draft #4– compliant. If the driver sees a descriptor order of Interface/Endpoint/HID, it assumes this is an older device and sends all requests to the Endpoint. If it sees a descriptor order of Interface/HID/Endpoint, it assumes this is a Draft #4– compliant device and sends all requests to the Interface. If the value of bmRequestType is 82h, the HID descriptor is associated with the Endpoint descriptor, rather than with the Interface descriptor. To fix this, the developer must relocate the HID descriptor so that it sits after the Interface descriptor and before the Endpoint descriptor. The device firmware that handles the setup packet needs to look for a request type of 81h, rather than 82h. Finally, for devices with multiple interfaces, such as a keyboard with built-in mouse, the wIndex field must reflect the interface for which a Report descriptor is being requested. The Windows 95 OSR 2.1 USB class driver incorrectly assumes that the Endpoint descriptor immediately follows the Interface descriptor. A solution that works equally well on Windows 95 and Windows 98 is to clear everything out of the Configuration descriptor returned from the device except Configuration, Interface, and Endpoint descriptors before being passed to USB functions. A sample function that performs this task can be downloaded from the web site at www.microsoft.com/hwdev/driver/hid4.htm. References and Call to Action • OEMs should ensure that the BIOS they ship on all platforms with USB host controllers and USB connectors has the code that provides legacy keyboard and mouse support for USB keyboards and mice. The platform should have legacy keyboard support enabled. • BIOS vendor developers who write code that provides legacy support for USB keyboards and mice on Windows platforms should use program logic that works with the host controller driver code logic presented in this article. • For more information and related references, see:
38. • OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a, available from www.microsoft.com/hwdev/specs/default.htm. • Intel information about USB, including the UHCI design guide for USB • USB Specification and USB Implementers Forum • USB information on Microsoft Hardware Developers web site www.microsoft.com/hwdev/busbios/default.htm. For more information about SMM, see Chapter 20 in Pentium Processor User's Manual, Volume 3: Architecture and Programming Manual, 1994, which can be ordered from Intel by calling 1-800-548-4725. Send feedback to MSDN. Look here for MSDN Online resources. Legacy Support for USB Keyboards and Mice and the Host Controller Driver Microsoft Corporation December 3, 1998 The operating system brings a Universal Serial Bus (USB) host controller to an operational state using the following steps: • Load the host controller driver and find the host controller. • Verify the host controller and allocate system resources. • Take control of the host controller. • Set up host controller registers and host controller communications area (HCCA). • Start sending Start of Frame (SOF) tokens on the USB. This article examines the third step of the process—taking control of the host controller—in the context of providing a solution to the problem of legacy keyboard
39. and mouse support when a USB keyboard, mouse, or both are attached to the PC. The information in this article applies to both Microsoftđ Windowsđ 98 and Windows 2000. USB support in Windows 98 and Windows 2000 is designed based on these assumptions: • System vendors want to support USB keyboards and mice when the BIOS has control of the system (for example, the USB keyboard works when the BIOS Setup program is running or the system is running in MS-DOSđ mode). • Host controller hardware and firmware vendors provide some amount of support for the emulation of PS/2-compatible keyboards and mice by USB keyboards and mice. Under conditions where these assumptions are met, this article describes the way Windows host controller drivers hand off USB keyboard and mouse interrupt processing between the operating system and the BIOS. The implementations used by the Open Host Controller Interface (OHCI) host controller driver and Universal Host Controller Interface (UHCI) host controller driver differ because of fundamental differences in the OHCI and UHCI specifications. Both implementations are described in this article. The operating system/BIOS handoff of legacy keyboard and mouse support is a two-way process. In other words, the handoff can occur from the BIOS to the operating system or from the operating system to the BIOS. Both handoff directions are described in this article. An example sequence of events that involves handoff The linked image cannot be displayed. The file may have been moved, renamed, or deleted. Verify that the link points to the correct file and location. of the host controller in both directions is shown in Figure 1. Figure 1. Example sequence of events in handoff of the host controller The time line in Figure 1 starts with a power-up (cold boot) event on the PC.
40. • Immediately after power-up and for some period of time, the BIOS controls the PC and the host controller. During this time interval, a user should be able to use a USB keyboard to enter BIOS Setup and use all keys on the USB keyboard that are valid during BIOS Setup. • If the user does not choose to enter BIOS Setup, the BIOS starts the operating system at some point and the operating system takes control of the PC and the host controller. As shown in Figure 1, code in a routine in the operating system host controller driver performs the necessary steps to hand off control of the legacy keyboard support function from the BIOS to the operating system host controller driver (in this article, that routine is called StopBIOS). • The next event shown in Figure 1 occurs when the user employs the Shutdown menu to shut down to MS-DOS. This causes the host controller driver to be unloaded; before unloading, it executes a routine that performs the necessary steps to hand off control of the legacy keyboard support function to the BIOS (in this article, that host controller driver routine is called StartBIOS). Hand Off for the OHCI Host Controller The host controller driver is responsible for a per-host controller set of data called device data. At startup and shutdown, the host controller driver manages the host controller through a set of Operational Registers. These registers are part of the host controller and are accessed by the host controller driver using memory references through a noncached virtual pointer. As defined in the OHCI specification, legacy keyboard and mouse emulation is provided by a set of registers controlled by code running in System Management Mode (SMM). When data is received from the keyboard or mouse, the SMM emulation code is notified and translates the USB keyboard/mouse data into a data sequence that is equivalent to what would be produced by a PS/2-compatible keyboard/mouse interface. This emulation scheme is described in the "Operational Theory" section of Appendix B in the OHCI specification. Interrupts generated by the host controller emulation hardware when USB keyboard or mouse data is received are steered by the host controller hardware to either a system management interrupt (SMI) or the standard host controller interrupt. The host controller uses these rules to steer the interrupt: • When the InterruptRouting bit in the host controller HcControl register is cleared, interrupts are steered to the standard host controller interrupt. • When the InterruptRouting bit is set, interrupts are steered to the SMI interrupt.
41. Note SMM is a processor mode in Intelđ Architecture platforms that is transparent to the operating system and application software. SMM is intended for use only by firmware. SMM is one of the processor's major operating modes, on a level with protected mode, real-address mode, or virtual-86 mode. An external signal, SMI#, causes the processor to switch to SMM; this is known as the SMI interrupt. The SMI# signal might be generated, for example, by closing the lid of a portable computer. When the processor recognizes an SMI# signal, the processor waits for all stores to complete and saves state. Then the processor begins to execute the SMM handler in firmware. Power-Up Processes The SMM driver gets control of the processor before any other driver. The SMM driver must set the InterruptRouting bit to cause all host controller interrupts to be routed to the SMI interrupt. The SMM driver then sets system-specific fields in the host controller registers, waits at least the minimum time specified in the USB Specification for assertion of reset on the USB, and then sets up the host controller. Operating System Takes Control of the OHCI Host Controller Later, when the host controller driver is loaded and running, it can determine that the SMM driver is active because the InterruptRouting bit is set in the HcControl register. When it wants the interrupts steered to the standard host controller interrupt, the host controller driver sets the OwnershipChangeRequest bit in the HcCommandStatus register, then monitors the InterruptRouting bit to determine when the ownership change has taken effect. The following pseudocode shows the structure and logic of the entire StopBIOS routine in the Windows OHCI host controller driver. Notice that the StopBIOS routine is called from only one place in the host controller driver, from the OpenHCI_InitializeHardware routine. Get a pointer to a per-device, per-host controller data structure If InterruptRouting bit is set to 1 // SMM driver owns host controller. Set OwnershipChangeRequest bit While total time elapsed is less than 0.5 seconds Wait 1 ms Read InterruptRouting bit If InterruptRouting bit is cleared //SMM has relinquished ownership. Set LEGACY_BIOS_DETECTED bit in per-device, per-host data structure Return (STATUS_SUCCESSFUL) Endif Endwhile // 0.5 sec have elapsed and SMM has not relinquished control. Endif Return (STAUS_UNSUCCESSFUL)
42. Note that a return of STATUS_UNSUCCESSFUL can result in a Code 10 message appearing in the Device Manager entry for the OHCI host controller. BIOS Takes Control of the OHCI Host Controller The following pseudocode shows the structure and logic of the entire StartBIOS module in the Windows OHCI host controller driver. Notice that the StartBIOS routine is called only after the host controller driver will not touch the hardware again. Get pointer to per-device, per-host controller data structure If LEGACY_BIOS_DETECTED flag set in per-device, per-host controller data structure //hand back control of host controller to SMM driver. Set OwnershipChangeRequest bit in HcCmd register Set OwnershipChange interrupt enable bit in HcInt register Set MasterInterruptEnable bit in HcInt register Endif Return(STATUS_SUCCESSFUL) Hand Off for the UHCI Host Controller Section 5 of the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1 gives an example implementation of mouse and keyboard legacy support and describes one way to hand off control of the host controller between the BIOS and the UHCI host controller driver in the operating system. The key UHCI register used in the example is the legacy support register (LEGSUP). For implementers in a PCI device, the LEGSUP register is located at offset C0-C1h, in function 2 PCI configuration space. The Microsoft UHCI host controller driver also uses the LEGSUP register as the primary interface in implementing the handoff of the host controller between the operating system and the BIOS; the Microsoft host controller driver implementation logic is described in this section of the article. LEGSUP register structure. The LEGSUP register is a bitmap containing 16 bits. The meaning of each of the 16 bits is fully specified in Section 5 of the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1. A summary description is given in the following table so the reader can interpret the bitmap constant values used in later sections of this article without referring to the Design Guide. Table 1. LEGSUP register structure Bit Name Description 1 = A20GATE passthrough sequence has 15 (R/WC) A20PTS ended. 14 Reserved. 1 = USB interrupt is routed to PIRQD 13 (R/W) USBPIRQDEN (default). 0 = Not routed to PIRQD. This bit
43. can be used to prevent the host controller from generating an interrupt. 12 (RO) USBIRQS 1 = USB IRQ is active. 11 (R/WC) TBY64W 1 = Write to port 64h has occurred. 10 (R/WC) TBY64R 1 = Read to port 64h has occurred. 9 (R/WC) TBY60W 1 = Write to port 60h has occurred. 8 (R/WC) TBY60R 1 = Read to port 60h has occurred. 1 = Enable generation of an SMI when 7 (R/W) SMIEPTE A20GATE passthrough sequence has ended. 0 = Disable (default). 1 = A20GATE passthrough sequence is 6 (RO) PSS currently in progress. 0 = Not executing (default). 1 = Enable A20GATE passthrough sequence. 5 (R/W) A20PTEN 0 = Disable (default). 1 = Enable SMI# generation on USB IRQ. 4 (R/W) USBSMIEN 0 = Disable (default). 1 = Enable I/O Trap and SMI# generation of 3 (R/W) 64WEN port 64h write. 0 = Disable (default). 1 = Enable I/O Trap and SMI# generation of 2 (R/W) 64REN port 64h read. 0 = Disable (default). 1 = Enable I/O Trap and SMI# generation of 1 (R/W) 60WEN port 60h write. 0 = Disable (default). 1 = Enable I/O Trap and SMI# generation of 0 (R/W) 60REN port 60h read. 0 = Disable (default). How the Microsoft host controller driver uses the LEGSUP register. The Microsoft UHCI host controller driver writes the following value to LEGSUP for normal HCD use: 0x2000. Note that this sets bit 13 and clears bit 4, which routes USB interrupts to PIRQD and disables SMI# generation on a USB IRQ event. The host controller driver sets bit 4 for BIOS/SMI use, which enables SMI# generation on a USB IRQ event. SOF MODIFY register. The SOF MODIFY register is a one-byte register that can be used to modify the value used to generate timing on the USB. (For more information, see section 2.1.6 of the Universal Host Controller Interface (UHCI)
44. Design Guide, Revision 1.1.) Guidelines for modification of frame time are contained in Chapter 7 of the USB Specification. How the Microsoft host controller driver uses the SOF MODIFY register. When the Microsoft host controller driver takes control of the host controller from the BIOS, it always reads the value of the SOF MODIFY register value established by the BIOS and saves it in a per-device, per-host controller data structure. USB COMMAND (USBCMD) register structure. The USBCMD register is a bit- map containing 16 bits. The meaning of each of the 16 bits is fully specified in Section 2.1.1 of the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1. A summary description is given in the following table so the reader can, without referring to the Design Guide, interpret the CMDREG bits that are set and cleared in the pseudocode in later sections of this article. Table 2. USBCMD register structure Bit Name Description 15:8 Reserved. 1 = 64 bits. 7 (R/W) MAXP 0 = 32 bits. Host controller driver software sets this bit as the last action in its process of configuring the host controller; 6 (R/W) CF has no effect on the hardware. Provided only as a semaphore service for the software. 1 = Debug mode. 5 (R/W) SWDBG 0 = Normal mode. 1 = host controller sends Global Resume signal on the 4 (R/W) FGR USB. 3 (R/W) EGSM 1 = host controller enters Global Suspend mode. 1 = host controller sends Global Reset signal on the 2 (R/W) GRESET USB and then resets all its logic. 1 = host controller resets its internal timers, counters, 1 (R/W) HCRESET state machines, and so on to their initial values. 1 = Run (host controller proceeds with execution of the schedule). 0 (R/W) RS 0 = Stop (host controller completes current transaction and then halts). How the Microsoft host controller driver uses the USBCMD register. When it takes control of the host controller from the BIOS, the Microsoft host controller driver clears the RS bit to stop the host controller and clears the CF bit. USB STATUS (USBSTS) register structure. The USBSTS register is a bitmap containing 16 bits. The meaning of each of the 16 bits is fully specified in Section 2.1.2 of the Universal Host Controller Interface (UHCI) Design Guide, Revision
45. 1.1. A summary description is given in the following table so the reader can, without referring to the Design Guide, interpret the CMDSTS bits that are set and cleared in the pseudocode in later sections of this article. Table 3. USBSTS register structure Bit Name Description 15:6 Reserved. 5 (R/WC) HcHalted Set to 1 by host controller when it is halted. Set to 1 by host controller when it encounters a Host Controller 4 (R/WC) consistency check error while processing a Process Error Transfer Descriptor. Host System Set to 1 by host controller when a serious error 3 (R/WC) Error occurs during a host system access. Set to 1 by host controller when it receives a 2 (R/WC) Resume Detect RESUME signal from a USB device. USB Error Set to 1 by host controller when completion of a 1 (R/W) Interrupt USB transaction results in an error condition. Set to 1 by host controller either when completion 0 (R/W) USBINT of a USB transaction causes an interrupt or when a short packet is detected. How the Microsoft host controller driver uses the USBSTS register. During the process of taking control of the host controller from the BIOS, the Microsoft host controller driver monitors the HcHalted bit to determine if and when the host controller is halted. Operating System Takes Control of the UHCI Host Controller When the host controller driver is loaded and running, it can determine whether the platform has a USB BIOS by the bits set in the LEGSUP register. A USB BIOS is a BIOS that contains code to: • Configure the host controller. • Enable a USB keyboard and mouse. • Set up the host controller scheduler. • Route USB keyboard and mouse input to the 8042 Keyboard Controller (KBC). When a USB BIOS boots, if it contains the code that does the functions listed above and has legacy keyboard support enabled, then it should always set bit 4 of the host
46. controller LEGSUP register and make sure bit 13 is cleared. Conversely, when a BIOS boots that does not contain the code that does the above functions or when it contains the code but has legacy keyboard support disabled, the BIOS should always set bit 13 of the LEGSUP register and make sure bit 4 is cleared. This will ensure the appropriate interaction between the BIOS and the Windows UHCI host controller driver. The following pseudocode shows the structure and logic of the entire StopBIOS routine in the UHCI host controller. Get a pointer to the per-device, per-host controller data structure Read current value of SOF MODIFY register into data structure Read current value of USB COMMAND REGISTER into data structure Read current value of USB INTERRUPT ENABLE REGISTER into data structure Read upper 20 bits of FRAME LIST BASE ADDRESS REGISTER into data structure // Override SOF MODIFY value from BIOS with value in Registry, if there is one. If SOF MODIFY value is in the Registry Read SOF MODIFY value from Registry Save SOF MODIFY value read from Registry in data structure Endif // Prepare first host controller command. Read current value of USB COMMAND REGISTER Clear RS bit in the USB COMMAND REGISTER // Will stop host controller. Clear CF bit in the USB COMMAND REGISTER // Will signal BIOS that OS has control. Write new value to USB COMMAND REGISTER // Wait until host controller halts. While total time elapsed is less than one millisecond Write 0xFF to Interrupt Status Register // Clear all pending interrupts. If HcHalt bit in USB STATUS REGISTER is set Break // Host controller has halted. Endif Endwhile Read the current value of the LEGSUP register Save read value of LEGSUP register in data structure // If any bits in the bit pattern 0x00BF are set in read LEGSUP value, then the platform // BIOS has legacy keyboard support code and legacy keyboard support is enabled for // the platform. If ((LEGSUP value) AND (0x00BF))!= 0 then Set USBBIOS flag in data structure // Platform has USB BIOS. Clear SMI enable bit (bit 4) in read LEGSUP value Write new value to LEGSUP register Read current value of LEGSUP register Write 0x2000 to the LEGSUP register // Route USB interrupt to PIRQD and // disable SMI# interrupt generation. Endif Return(STATUS_SUCCESSFUL)
47. BIOS Takes Control of the UHCI Host Controller The following pseudocode shows the structure and logic of the StartBIOS routine for the UHCI host controller. Note that whenever StartBIOS is executed, it can be assumed that StopBIOS has been executed earlier; all StartBIOS calls are conditional and performed only if the USBBIOS flag is set in the per-device, per- controller data structure maintained by the host controller driver. This means that a set of host controller register values the BIOS needs to take control of the host controller are saved in the same data structure. Get pointer to per-device, per-host controller data structure // Clear all pending interrupts. Write 0xFF to Interrupt Status Register // Restore host controller register values saved at last BIOS to operating system handoff. Write value from data structure to HC USB INTERRUPT ENABLE REGISTER Write value from data structure to HC FRAME LIST BASE ADDRESS REGISTER // Enable routing of USB keyboard and mouse interrupts to SMI#. Write value from data structure into HC LEGSUP register Read value of HC LEGSUP register into data structure Set USBSMIEN bit (bit 4) of LEGSUP register value in data structure Write new value from data structure into HC LEGSUP register // Start host controller schedule. Write value from data structure into HC COMMAND REGISTER Set RS bit of COMMAND REGISTER value in data structure Write new COMMAND REGISTER value to HC COMMAND REGISTER Return(STATUS_SUCCESSFUL) HID Draft #4 Compliance Note In the USB HID Device Class Definition for Human Interface Devices, Draft #4, the HID descriptor has been repositioned within the Configuration descriptor; the correct order is now Configuration/Interface/HID/Endpoint. The HID USB driver supplied with Windows 98 and Windows 2000 looks at the order of the descriptors within the Configuration descriptor to determine whether a device is Draft #4– compliant. If the driver sees a descriptor order of Interface/Endpoint/HID, it assumes this is an older device and sends all requests to the Endpoint. If it sees a descriptor order of Interface/HID/Endpoint, it assumes this is a Draft #4– compliant device and sends all requests to the Interface. If the value of bmRequestType is 82h, the HID descriptor is associated with the Endpoint descriptor, rather than with the Interface descriptor. To fix this, the developer must relocate the HID descriptor so that it sits after the Interface descriptor and before the Endpoint descriptor. The device firmware that handles the setup packet needs to look for a request type of 81h, rather than 82h. Finally, for devices with multiple interfaces, such as a keyboard with built-in mouse, the wIndex field must reflect the interface for which a Report descriptor is being requested.