Abstract:
A first driver bypasses execution of a transaction descriptor that causes a non-maskable interrupt (NMI) when executed by a host controller while under control of a second driver. The transaction descriptor is pointed to by an entry in a frame list. The host controller has a plurality of host controller registers including a frame list base address register defining a base address of the frame list and a frame number register addressing the entry.

Description:
BACKGROUND 
     1. Field of the Invention 
     This invention relates to Universal Serial Bus (USB). In particular, the invention relates to USB Host Controllers. 
     2. Description of Related Art 
     The Universal Serial Bus (USB) is an industry standard extension to the Personal Computer (PC) architecture with focus on PC peripherals. The USB supports functional data and control exchange between the USB host and a USB device as a set of either unidirectional or bi-directional pipes. USB data transfers take place between host software and a particular endpoint on a USB device. The USB host interacts with USB devices through a USB Host Controller (HC). The USB system software on the host manages interactions between USB devices and host-based device software. 
     The USB system software includes USB drivers, client driver software, and HC driver. In a typical PC environment, the USB drivers may exist in the Basic Input/Output System (BIOS) and the Operating System (OS). When control is transferred from the USB HC from the BIOS device driver to the OS device driver, the OS device driver saves a snapshot of all the USB input/output (I/O) registers. The OS driver will restore the snapshot of these USB I/O registers when the user wishes to perform one of the following tasks: (1) restart to Microsoft-Disk Operating System (MS-DOS), (2) select “Shutdown of OS”, and (3) unload OS USB drivers using device manager in the OS. 
     The BIOS needs to determine when the transfer of control from the OS driver to the BIOS is completed. Existing techniques include use of the Configure Flag (CF). The USB HC driver sets this bit as the last action in its process of configuring the Host Controller. However, the OS device driver will have re-enumerated the USB devices and assigned new addresses. Therefore, restoring the USB I/O registers will not restore the BIOS Legacy functionality. 
     Therefore, there is a need to have an efficient technique to detect when the control transfer from OS device driver to BIOS is completed. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The features and advantages of the present invention will become apparent from the following detailed description of the present invention in which: 
     FIG. 1 is a diagram illustrating a system in which one embodiment of the invention can be practiced. 
     FIG. 2 is a diagram illustrating a frame list shown in FIG. 1 according to one embodiment of the invention. 
     FIG. 3 is a flowchart illustrating a process to initialize USB operations during boot-up according to one embodiment of the invention. 
     FIG. 4 is a flowchart illustrating a process to support USB operations by the BIOS USB driver during boot-up according to one embodiment of the invention. 
     FIG. 5 is a flowchart illustrating a process to support USB operations by the OS USB driver during control transfer from OS to BIOS according to one embodiment of the invention. 
    
    
     DESCRIPTION 
     In the following description, for purposes of explanation, numerous details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that these specific details are not required in order to practice the present invention. In other instances, well-known electrical structures and circuits are shown in block diagram form in order not to obscure the present invention. 
     FIG. 1 is a diagram illustrating a computer system  100  in which one embodiment of the invention can be practiced. The computer system  100  includes a processor  110 , a host bus  120 , a memory control hub (MCH)  130 , a Basic Input/Output System (BIOS) memory  135 , a system memory  140 , an input/output control hub (ICH)  150 , a mass storage device  170 , and input/output devices  180   1  to  180   K . 
     The processor  110  represents a central processing unit of any type of architecture, such as embedded processors, micro-controllers, digital signal processors, superscalar computers, vector processors, single instruction multiple data (SIMD) computers, complex instruction set computers (CISC), reduced instruction set computers (RISC), very long instruction word (VLIW), or hybrid architecture. In one embodiment, the processor  110  is compatible with the Intel Architecture (IA) processor, such as the IA-32 and the IA-64. The processor  110  typical contains a number of control registers to support memory management tasks such as virtual memory and cache memory. These tasks may include paging and segmentation. 
     The host bus  120  provides interface signals to allow the processor  110  to communicate with other processors or devices, e.g., the MCH  130 . The host bus  120  may support a uni-processor or multiprocessor configuration. The host bus  120  may be parallel, sequential, pipelined, asynchronous, synchronous, or any combination thereof. 
     The MCH  130  provides control and configuration of memory and input/output devices such as the system memory  140  and the ICH  150 . The MCH  130  maybe integrated into a chipset that integrates multiple functionalities such as the isolated execution mode, host-to-peripheral bus interface, memory control. For clarity, not all the peripheral buses are shown. It is contemplated that the system  100  may also include peripheral buses such as Peripheral Component Interconnect (PCI), accelerated graphics port (AGP), Industry Standard Architecture (ISA) bus, and Universal Serial Bus (USB), etc. 
     The BIOS memory  135  stores boot-up code and data. The BIOS memory  135  typically is implemented with non-volatile memory such as Read Only Memory (ROM), flash memory, and other similar memories. The BIOS memory  135  may also be stored inside the MCH  130 . The BIOS memory  135  contains a BIOS USB driver  138  and other drivers. 
     The system memory  140  stores system code and data. The system memory  140  is typically implemented with dynamic random access memory (DRAM) or static random access memory (SRAM). The system memory may include program code or code segments implementing one embodiment of the invention. The system memory includes an Operating System (OS)  141  and USB memory  149 . The OS  141  contains an OS USB driver  142 . The USB memory  149  contains data structures and scratchpad data for controlling USB devices. Examples of these data structures include frame lists, transaction descriptors, queues, etc. In particular, the USB memory  149  includes a frame list  143 , a non-maskable interrupt (NMI) transaction descriptor (TD)  144 , and a dummy TD  145  and data TD&#39;s  146 . The system memory  140  may also include other programs or data which are not shown, such as an operating system. 
     The ICH  150  has a number of functionalities that are designed to support I/O functions. The ICH  150  may also be integrated into a chipset together or separate from the MCH  130  to perform I/O functions. The ICH  150  may include a number of interface and I/O functions such as PCI bus interface, processor interface, interrupt controller, direct memory access (DMA) controller, power management logic, timer, universal serial bus (USB) interface, mass storage interface, low pin count (LPC) interface, etc. In particular, the ICH  150  includes a USB host controller (HC)  151  and interface to the USB bus  155 . The USB host controller  151  contains a number of host controller registers as defined in the Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1, published by Intel Corporation, March 1996. Examples of these registers include USB command register, USB status register, USB interrupt enable register, USB frame number register, USB frame list base address register, USB start of frame (SOF) register, USB Port 0 Status and Control register, and USB Port 1 Status and Control register. The USB bus  155  is coupled to a number of USB devices such as USB keyboard  152 , USB mouse  154 , USB camera  156 , and other USB devices  158 . 
     The mass storage device  170  stores archive information such as code, programs, files, data, applications, and operating systems. The mass storage device  170  may include compact disk (CD) ROM  172 , floppy diskettes  174 , and hard drive  176 , and any other magnetic or optic storage devices. The mass storage device  170  provides a mechanism to read machine-readable media. 
     The I/O devices  180   1  to  180   K  may include any I/O devices to perform I/O functions. Examples of I/O devices  180   1  to  180   K  include controller for input devices (e.g., keyboard, mouse, trackball, pointing device), media card (e.g., audio, video, graphics), network card, and any other peripheral controllers. 
     The present invention may be implemented by hardware, software, firmware, microcode, or any combination thereof. When implemented in software, firmware, or microcode, the elements of the present invention are the program code or code segments to perform the necessary tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc. The program or code segments may be stored in a processor readable medium or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The “processor readable medium” may include any medium that can store or transfer information. Examples of the processor readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable ROM (EROM), a floppy diskette, a compact disk (CD-ROM), an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc. 
     It is noted that the invention may be described as a process which is usually depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function. 
     FIG. 2 is a diagram illustrating the USB memory  149  shown in FIG. 1 according to one embodiment of the invention. The USB memory  149  includes the frame list  143 , the NMI TD  144 , the dummy TD  145 , and the data TA&#39;s  146 . 
     The frame list  142  includes a number of entries  210   1  to  210   N . The N entries  210   1  to  210   N  are addressed by the USB frame number stored in the USB frame number register in the host controller  151 . Each of the N entries  210   1  to  210   N  corresponds to a frame number. In one embodiment, N is 1024 and each entry is composed of 4 bytes, corresponding to 4 KB of frame list. For USB devices, each entry corresponds to a particular frame of approximately 1 millisecond (ms). Each of the N entries  210   1  to  210   N  contains a pointer to other data structures (e.g., Transaction Descriptors, Queue Heads) and control bits. In particular, there is the non-maskable interrupt (NMI) TD  144 , the dummy TD  145 , and data TD&#39;s  146 . The NMI TD  144  is used to indicate that the control transfer from the OS USB driver  142  (FIG. 1) to the BIOS USB driver  138  (FIG. 1) has been completed. The dummy TD  145  is used to provide rollback at 1 second interval. The data TD&#39;s  146  are used for the control and operation of the USB devices. 
     The base address of the frame list  143  is defined or provided by the USB frame list base address stored in the USB frame list base address register in the USB HC  151 . By changing the USB frame list base address, it is possible to allow the USB HC  151  to access to a different frame list which points to different TD&#39;s. 
     The BIOS USB driver  138  or the OS USB driver  142  (FIG. 1) programs the Host Controller  151  with the starting address of the frame list in the USB frame list base address register and the Frame list index. Then, the driver causes the HC  151  to execute the schedule by setting the Run/Stop bit in the USB Control register to Run. The USB HC  151  then processes the schedule one entry at a time. Executing the schedule refers to fetching the entry and obtaining the Transaction Descriptor or the Queue Head. If the frame list entry indicates that it points to a TD, the HC  151  fetches the entry and begins the operations necessary to initiate a transaction on the USB. 
     The USB HC  151  provides interrupt capability based on two types: one is related to the execution of the transactions in the schedule, and one is related to the HC operation error. The transaction-based interrupts are maskable. These interrupts include Cyclic Redundancy Code (CRC) error or time-out, Interrupt on Completion, Short Packet Detect, Serial Bus Babble, Stalled, Data Buffer Error, and Bit Stuff Error The non-transaction based interrupts include Resume Receive, HC Process Error, and Host System Error. Out of these three non-transaction based interrupts, the HC Process Error and the Host System Error are non maskable. The NMI TD can be forced to be generated by using the HC Process Error interrupt. This HC Process Error can be created by using a non valid Packet Identifier (PID) or use a maximum length of greater than the allowable maximum value (e.g., 1280). 
     To set a positive flag that indicates a control transfer from the OS USB driver  143  to the BIOS USB driver has occurred, the OS USB driver can cause NMI to occur by restoring the previously saved USB HC registers and setting the HC to execute the USB schedule that contains the NMI. When the HC executes the NMI TD, a non-maskable interrupt is generated which can be converted into a legacy USB System Management Interrupt (SMI). On the occurrence of this interrupt, the HC  151  clears the Run/Stop bit which prevents further execution of the TD. The BIOS SMI handler then passes control to the BIOS USB driver  138 . The BIOS USB driver  138  is therefore in control when the NMI is generated. Upon receiving control, the BIOS USB driver  138  reprograms the USB frame list base register to prevent or bypass execution of the NMI. Then the BIOS USB driver  138  can go through parsing the TD&#39;s in the frame list after positively confirming that the control is transferred from the OS USB driver  142 . It is noted that the NMI TD is part of the BIOS-built USB schedule. The frame number that corresponds to the entry pointing to the NMI TD is known to the BIOS but not to the OS. 
     In other words, when the BIOS USB driver  138  is in control as a result of a legacy SMI caused by execution of an NMI TD, a positive detection of control transfer from the OS to the BIOS is achieved. To prevent or bypass execution of the NMI TD by the OS USB driver  142  when control is transferred to OS USB driver  142 , the BIOS  138  re-programs the frame list base address to another frame list which does not point to the NMI TD. 
     FIG. 3 is a flowchart illustrating a process  300  to initialize USB operations during boot-up according to one embodiment of the invention. 
     Upon START, the system is powered on and the boot-up begins (Block  310 ). Next, the BIOS code starts execution and initializes system memory and other devices (Block  320 ). Then, the BIOS USB driver executes the USB schedule (Block  330 ). Next, the BIOS USB driver processes control and data from USB devices (Block  340 ). 
     Then, the BIOS loads the OS from mass storage to the system memory (Block  350 ). Next, the BIOS transfers control to the OS (Block  360 ). The OS USB driver then saves the current state of the USB host controller registers as initialized by the BIOS USB driver (Block  370 ). Next, the OS loads the OS USB driver (Block  380 ). The OS USB driver then handles control and data from the USB devices (Block  390 ). The process  300  is then terminated. 
     FIG. 4 is a flowchart illustrating a process  400  to support USB operations by the BIOS USB driver during boot-up according to one embodiment of the invention. 
     Upon START, the process  400  determines if there is a data transfer to or from USB devices or if there is execution of dummy TD which occurs approximately every one second for rollback (Block  410 ). If no, the process  400  is terminated. Otherwise, the process  400  invokes the BIOS USB driver (Block  420 ). Then, the BIOS USB driver checks the USB frame number in the USB frame number register in the Host Controller (HC) (Block  430 ). From this USB frame number, the BIOS USB driver determines whether it is time to bypass the execution of the NMI TD (Block  440 ). If not, the process  400  goes to Block  460 . Otherwise, the BIOS USB driver programs the frame list base address in the USB frame list base address register (Block  450 ). By changing the base address, the frame list is positioned at a different memory address from that contains the entry pointing to the NMI TD. 
     Next, the BIOS USB driver parses the data TD&#39;s to process the data transferred to or from the USB devices accordingly (Block  460 ). Then the BIOS USB driver enables the data TD&#39;s for the next iteration processing if necessary (Block  470 ). Next, the BIOS USB driver passes control back to the regular code execution (Block  480 ) and is then terminated. 
     FIG. 5 is a flowchart illustrating a process  500  to support USB operations by the OS USB driver during control transfer from OS to BIOS according to one embodiment of the invention. 
     Upon START, the process  500  determines if it is desire to transfer control from the OS USB driver to the BIOS USB driver (Block  510 ). Typically, this is provided by the user&#39;s selection of one of the following tasks: (1) restart to Microsoft-Disk Operating System (MS-DOS), (2) select “Shutdown of OS”, and (3) unload OS USB drivers using device manager in the OS. If not, the process  500  continues execution of the OS USB drivers or other OS functions (Block  515 ) and is then terminated. Otherwise, the OS USB driver unloads the OS USB driver by restoring the USB HC registers previously saved prior to installation of the OS USB driver (Block  520 ). 
     Then, the USB HC executes the USB schedule using the restored registers (Block  530 ). Next, the USB HC executes the USB NMI TD which has not been bypassed by the BIOS USB driver (Block  540 ). Next, the process  500  generates the NMI as result of the execution of NMI TD to transfer control to the BIOS USB driver (Block  550 ). This NMI is redirected or converted to the legacy SMI which will be serviced by the BIOS SMI handler. The BIOS SMI handler then passes control to BIOS USB driver. When the BIOS USB driver takes control, it parses through the USB TD&#39;s to confirm the control transfer from OS USB driver (Block  560 ). After confirming, the BIOS USB driver re-initializes the USB devices and starts normal processing of USB device data as needed (Block  570 ). Then, the process  500  exits the BIOS USB driver and returns to regular code execution (Block  580 ) and is then terminated. 
     While this invention has been described with reference to illustrative embodiments, this description is not intended to be construed in a limiting sense. Various modifications of the illustrative embodiments, as well as other embodiments of the invention, which are apparent to persons skilled in the art to which the invention pertains are deemed to lie within the spirit and scope of the invention.