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, percontroller 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 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 www.microsoft.com/hwdev/driver/hid4.htm from the web site at 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:  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 http://developer.intel.com/design/litcentr/ http://developer.intel.com/design/usb/  USB Specification and http://www.usb.org/developers/ 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  Take the host control controller of and the allocate system host resources 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)  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 Figure Example sequence of events in handoff of the host controller The time line in Figure 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 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 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 // SMM driver owns host controller Set OwnershipChangeRequest bit While total time elapsed is less than 0.5 seconds Wait 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 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) data Hand Off for the UHCI Host Controller Section 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 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 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 LEGSUP register structure Bit Name Description = A20GATE passthrough sequence has 15 (R/WC) A20PTS ended 14 Reserved = USB interrupt is routed to PIRQD (default) = 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 = USB IRQ is active 11 (R/WC) TBY64W = Write to port 64h has occurred 10 (R/WC) TBY64R = Read to port 64h has occurred (R/WC) TBY60W = Write to port 60h has occurred (R/WC) TBY60R = Read to port 60h has occurred = Enable generation of an SMI when (R/W) SMIEPTE A20GATE passthrough sequence has ended = Disable (default) = A20GATE passthrough sequence is (RO) PSS currently in progress = Not executing (default) = Enable A20GATE passthrough sequence (R/W) A20PTEN = Disable (default) = Enable SMI# generation on USB IRQ (R/W) USBSMIEN = Disable (default) = Enable I/O Trap and SMI# generation of (R/W) 64WEN port 64h write = Disable (default) = Enable I/O Trap and SMI# generation of (R/W) 64REN port 64h read = Disable (default) = Enable I/O Trap and SMI# generation of (R/W) 60WEN port 60h write = Disable (default) (R/W) 60REN = Enable I/O Trap and SMI# generation of 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 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 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 USBCMD register structure Bit Name Description 15:8 Reserved = 64 bits (R/W) MAXP = 32 bits Host controller driver software sets this bit as the last action in its process of configuring the host controller; (R/W) CF has no effect on the hardware Provided only as a semaphore service for the software = Debug mode (R/W) SWDBG = Normal mode = host controller sends Global Resume signal on the (R/W) FGR USB (R/W) EGSM = host controller enters Global Suspend mode = host controller sends Global Reset signal on the (R/W) GRESET 1USB and then resets all its logic = host controller resets its internal timers, counters, (R/W) HCRESET 1state machines, and so on to their initial values = Run (host controller proceeds with execution of the schedule) (R/W) RS = 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 USBSTS register structure Bit Name Description 15:6 Reserved (R/WC) HcHalted Set to by host controller when it is halted to by host controller when it encounters a Controller Set (R/WC) Host consistency check error while processing a Process Error Transfer Descriptor System Set to by host controller when a serious error (R/WC) Host Error occurs during a host system access to by host controller when it receives a (R/WC) Resume Detect Set RESUME signal from a USB device USB Error Set to by host controller when completion of a (R/W) Interrupt USB transaction results in an error condition Set to by host controller either when completion (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  Set a up USB the keyboard host and controller mouse 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 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 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))!= 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, percontroller 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 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:  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 http://developer.intel.com/design/litcentr/ http://developer.intel.com/design/usb/  USB Specification and http://www.usb.org/developers/ 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  Take the host control controller of and the allocate system host resources 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)  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 Figure Example sequence of events in handoff of the host controller The time line in Figure 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 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 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 // SMM driver owns host controller Set OwnershipChangeRequest bit While total time elapsed is less than 0.5 seconds Wait 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 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) data Hand Off for the UHCI Host Controller Section 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 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 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 LEGSUP register structure Bit Name Description = A20GATE passthrough sequence has 15 (R/WC) A20PTS ended 14 Reserved = USB interrupt is routed to PIRQD (default) = 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 = USB IRQ is active 11 (R/WC) TBY64W = Write to port 64h has occurred 10 (R/WC) TBY64R = Read to port 64h has occurred (R/WC) TBY60W = Write to port 60h has occurred (R/WC) TBY60R = Read to port 60h has occurred = Enable generation of an SMI when (R/W) SMIEPTE A20GATE passthrough sequence has ended = Disable (default) = A20GATE passthrough sequence is (RO) PSS currently in progress = Not executing (default) = Enable A20GATE passthrough sequence (R/W) A20PTEN = Disable (default) = Enable SMI# generation on USB IRQ (R/W) USBSMIEN = Disable (default) = Enable I/O Trap and SMI# generation of (R/W) 64WEN port 64h write = Disable (default) = Enable I/O Trap and SMI# generation of (R/W) 64REN port 64h read = Disable (default) = Enable I/O Trap and SMI# generation of (R/W) 60WEN port 60h write = Disable (default) = Enable I/O Trap and SMI# generation of (R/W) 60REN port 60h read = 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 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 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 USBCMD register structure Bit Name Description 15:8 Reserved = 64 bits (R/W) MAXP = 32 bits Host controller driver software sets this bit as the last action in its process of configuring the host controller; (R/W) CF has no effect on the hardware Provided only as a semaphore service for the software = Debug mode (R/W) SWDBG = Normal mode = host controller sends Global Resume signal on the (R/W) FGR USB (R/W) EGSM = host controller enters Global Suspend mode = host controller sends Global Reset signal on the (R/W) GRESET 1USB and then resets all its logic = host controller resets its internal timers, counters, (R/W) HCRESET 1state machines, and so on to their initial values = Run (host controller proceeds with execution of the schedule) (R/W) RS = 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 USBSTS register structure Bit Name Description 15:6 Reserved (R/WC) HcHalted Set to by host controller when it is halted to by host controller when it encounters a Controller Set (R/WC) Host consistency check error while processing a Process Error Transfer Descriptor System Set to by host controller when a serious error (R/WC) Host Error occurs during a host system access to by host controller when it receives a (R/WC) Resume Detect Set RESUME signal from a USB device USB Error Set to by host controller when completion of a Interrupt USB transaction results in an error condition Set to by host controller either when completion (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 (R/W) 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  Set a up USB the keyboard host and controller mouse 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 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 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))!= 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, percontroller 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 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:  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 http://developer.intel.com/design/litcentr/ http://developer.intel.com/design/usb/  USB Specification and http://www.usb.org/developers/ 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 Universal Serial Bus Support for Windows CE Jason Black, Sridhar Mandyam Microsoft Corporation July 27, 1998 Abstract This document provides a brief introduction to Universal Serial Bus (USB) technology, an overview of the USB support present in Windows® CE 2.10, and an overview of how to write USB device drivers for Windows CE 2.10  ... 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. .. 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. .. steps:  Load the host controller driver and find the host controller  Verify  Take the host control controller of and the allocate system host resources controller  Set up host controller registers