KR101609385B1 - Method for reducing platform boot times by providing lazy input/output abstractions - Google Patents

Abstract

A method, system, and computer program product for enhanced system boot processing for launching an operating system faster than certain devices, such as user input hardware devices, may not be initialized if it is determined that there is no user interruption to the boot process . That is, even if the interface to the device is exposed, no initialization occurs unless a call to the interface occurs. Other embodiments are described and claimed.

Description

METHOD FOR REDUCING PLATFORM BOOT TIMES BY PROVIDING LAZY INPUT / OUTPUT ABSTRACTIONS < RTI ID = 0.0 >

Many computing systems have traditionally been designed to interrupt the boot process in order to set the system clock, manage memory settings, configure a new hard drive, change the boot order, and perform various setup functions such as password reset interrupt. Such an interrupt may be initiated by the user's activation of a particular keyboard button (s), such as delete, F1, F2, F10 or ctrl-alt-delete during the basic input / output system (BIOS) boot process. For such a system, the boot time may be increased as the input / output (I / O) devices such as a universal serial bus (USB) keyboard are enumerated and polled to determine if the user actually initiated such an interrupt Can be remarkably long.

Figure 1 is an illustration of operations performed prior to launching an operating system.
Figure 2 is an illustration of operations performed prior to launching an operating system, in accordance with one embodiment of the present invention.
3 is a flow diagram of a method for performing an enhanced boot, in accordance with an embodiment of the present invention.
4 is a flow diagram of operations performed in conjunction with enabling firmware and enhanced boot interrupt control, in accordance with an embodiment of the present invention.
5 is a block diagram illustrating first and second systems, in accordance with at least one embodiment of the present invention.
6 is a block diagram of a system according to at least one alternative embodiment of the present invention.
7 is a block diagram of a system according to at least one alternative embodiment of the present invention.

Embodiments may provide platform interruptability without having to necessarily incur the burden of polling a particular input / output (I / O) device (e.g., a universal serial bus (USB) keyboard may take from 0.5 to 1.5 seconds) Lt; / RTI > As computing systems such as mobile devices, such as smartphones, tablet computers, Ultrabooks ™, electronic readers, etc., become increasingly common, there is a growing need for users of instant-on or near instant- There is a desire, and the boot speed becomes increasingly important. Nevertheless, there are conflicting requirements, such as providing the ability to interrupt the boot process to enter a particular pre-boot mode, such as for configuration or diagnostics, which can be triggered by a user selecting several shortcuts exist. To accommodate this behavior, the keyboard that accepts the interrupt can take only 0.5 seconds to enumerate the connected bus. In addition, a certain amount of waiting time is provided for the user to press a key, which further aggravates the boot time by introducing a scenario in which the platform repeatedly uses something that has been rarely used, significantly slowing down the boot process.

Embodiments can controllably circumvent this situation for multiple bots that are not provided with any user input, thus enabling almost instant on for the majority of system bots. According to various embodiments, pre-boot code, such as the platform BIOS, may support lazy initialization (i.e., on-demand initialization) for one or more hardware devices, such as I / O devices.

The embodiment shows a standard interface to be normally exposed when the hardware is actually initialized, but the initialization process is avoided. The hardware will only be touched when the interface is called by the consumer, and then (and only after that) will actually occur the time associated with initializing the hardware.

Referring now to FIG. 1, there is shown an example of a conventional operation performed prior to launching an operating system, causing overhead for initializing the hardware to poll for user input. As shown in Figure 1, launching an operating system (OS) begins with BIOS initialization to initialize the central processing unit (CPU) / chipset. Next, a bus such as an I / O bus is enumerated to locate the device. There may be one or more hardware components on this bus, such as a USB controller, which in turn interfaces to a device, such as a user input hardware device, such as a keyboard. Examples of such user input devices, more generally I / O devices, may include a keyboard, a mouse, a numeric keypad, a touch screen, a virtual keyboard displayed on a display screen,

As shown, a probing operation occurs between the hardware component and the device to probe for the presence of the device. Next, a periodic system management interrupt (SMI) is programmed for periodic interrupts to emulate legacy USB. As shown, an interrupt may be generated in the CPU / chipset. Thus, a polling operation occurs, and the polling operation is performed in a system management mode (SMM) in which the handler can execute to poll for the presence of a device, e.g., a keyboard, Let it enter. For example, I / O devices can be queried to determine if the user has provided input to indicate that the boot process should be interrupted. Thus, they are monitored for user initiation input. As an example, this interrogation includes building a handshake with the device and polling the device. The step of establishing the handshake can include, for example, transferring a specific type of data to a particular port.

Continuing to refer to FIG. 1, the OS loader is then read from a target medium such as a non-volatile storage of a system such as, for example, flash memory or, if present, a mass storage device such as a hard drive. The BIOS then allows the OS to launch. After launching the OS, the native OS driver is launched. Note that this boot process may take longer than desired due to the time delay associated with probing and polling operations on the device.

Instead, according to certain embodiments, various overheads may be removed from the boot process prior to OS launch. Referring now to Figure 2, an example of an operation performed prior to launching an operating system, in accordance with an embodiment of the present invention, is illustrated. As shown in FIG. 2, if the overhead is removed, the time between initialization and launching of the OS can be much shorter. As shown, after initialization of the CPU / chipset, the OS loader is read immediately after, the OS can be launched immediately, and the above-mentioned overhead is eliminated.

In this way, even when booting from a powered off platform, a recognized "instant on" or almost "instant on" To achieve such perceived instant-on operation, this overhead for polling of the user input (and not normally occurring) and probing of the device can be avoided. Nevertheless, there are valid product requirements that interrupt the boot process from time to time, such as entering the diagnostic mode or allowing user input to the BIOS setup routine.

Referring now to FIG. 3, a flow diagram of a method for performing an enhanced boot in accordance with an embodiment of the present invention is shown. As shown in FIG. 3, the method 100 may be implemented with firmware logic, such as the logic of the BIOS. As shown, the method 100 begins at system power on (block 105). In response to the power-on of such a system, initialization may be performed (block 110). This initialization can trigger initialization of the CPU / chipset, discovery of memory, one or more buses, and possibly other initial low level hardware initialization. In addition, execution of the preboot environment, for example, a Unified Extensible Firmware Interface (UEFI) preboot environment, can occur. As part of this pre-boot environment, it can be determined in the diamond shape 115 whether the system will enable delayed interface initialization. The scope of the invention is not limited in this regard, but in one embodiment such a determination may be based on a BIOS setting that indicates whether enhanced booting is enabled or disabled. Note that such configuration settings may be controlled by a user, OS, or other entity. If the system is not configured for such delayed interface initialization, control is passed to block 120 where a wide range of normal initialization may be continued. As described above in connection with FIG. 1, such initialization may include activities related to enumeration and initialization of the I / O bus, hardware initialization, polling, and the like.

Still referring to FIG. 3, if it is determined from the diamond shape 115 that an enhanced boot occurs, then control is transferred to block 125 where the interface to the input hardware (e.g., a keyboard or other device) . This operation is a memory only operation, zero time occurs, the actual initialization of the device is avoided, and only the advertisement of the interface occurs. In one embodiment, such an interface advertisement may be in accordance with the UEFI simple text input protocol. Next, control is transferred from the block 125 and the diamond shape 115 to the diamond shape 130 where it can be determined whether an input is requested from the user. This determination may be based on a BIOS setting indicating that booting should be interrupted. In one embodiment, this setting may be selected by the user during a previous power cycle of the platform to indicate whether the user intends to interrupt the next boot of the system. If no such input request occurs, control is passed directly to block 140 where OS bootstrap code can be launched, which, in one embodiment, can be implemented via the boot manager. Thus, control is passed to block 150 where the OS boot can be terminated.

Still referring to FIG. 3, if an input is instead requested from the user, control is passed to block 160 where the interface for the input device can be invoked. In one embodiment, such an interface may be in accordance with the UEFI simple text input protocol. With the invocation of a previously exposed interface, control is passed to block 165 where the input hardware can be initialized according to, for example, PS / 2, USB or other protocols. Note that this initialization may occur in situations where the hardware has not been previously initialized (e.g., as was done in block 120 where a conventional full boot process is selected instead).

Still referring to FIG. 3, next, control is passed to block 170 where the request can be serviced and data can be returned. For example, in the context of a user keyboard input, a keyboard handler may be called to obtain the keystroke that is coming in from the keyboard buffer, and return the data to a specified location, such as a BIOS routine that uses this data as input. Control is then passed to block 150 for launching the OS bootstrap code, as described above. Although shown in this high level in the embodiment of FIG. 3, it is understood that the scope of the present invention is not limited in this regard.

Referring now to FIG. 4, there is shown a flow diagram of operations performed in conjunction with enabling firmware and enhanced interrupt control of an interrupt according to an embodiment of the present invention. As shown in Figure 4, operation may be performed in part by OS-present logic, and in part by BIOS logic. In general, the OS logic may be used to allow the user to configure the platform so that the next boot up is interrupted, e.g., to enable diagnostic mode, user update of BIOS settings, and the like. In turn, the BIOS logic can be used to perform enhanced boot (also referred to as high performance boot mode) or user interrupt boot mode, depending on the configuration.

As shown in Figure 4, the method 300 may begin (in diamond shape 305), in one embodiment, by determining whether the user will select a BIOS setup control panel applet that may reside in the control panel user interface of the OS . If so, control is passed to block 310 where a particular application programming interface (API) may be called, e.g., a Set Firmware Environment Variable API, to indicate that the next boot should be interrupted. This configuration information may be stored in a shared static variable, which in one embodiment is a common repository accessible to both the OS and the BIOS, which may serve as a mailbox interface so that the settings selected using the OS may later be accessed by the BIOS. Location. ≪ / RTI > Control is then passed to the diamond shape 315 where it can be determined whether the applet policy indicates that a restart should occur. Otherwise, normal system operation may continue at block 320. If not, a platform restart may occur at block 330. Although the embodiment of FIG. 4 illustrates the use of an applet of a control panel program that allows a user to set one or more firmware environment variables (e.g., UEFI variables, etc.), in other embodiments the user input may be a driver, an applet, But may be input by another software program separate from the software program.

Still referring to FIG. 4, the BIOS operation during boot based on such OS-provided settings may occur in response to such a platform restart or may occur at the next boot-up of the system. In either case, control is passed to block 340 where the system can be powered on. Control is then passed to block 345 where the platform may be initialized, for example, as described above. Then, in diamond shape 350, it can be determined whether the platform is enabled to support conditional high performance booting. As described above, such conditional high performance booting can avoid the overhead of initializing specific hardware, such as user interface hardware.

Still referring to FIG. 4, if the platform is so enabled, control is passed to block 360 where a policy variable that can be accessed from the static variable store can be read to determine if a high performance boot mode is selected. That is, if no user interruption occurs (or is unlikely to occur), an enhanced boot according to an embodiment of the present invention can be performed. This policy variable may be an indicator (such as a flag) to indicate, in one embodiment, whether a user interrupt is expected or likely (meaning that the user is planning to interrupt the next boot for some reason). These variables can be stored in a commonly accessible storage location in an environment where the OS is present. In one embodiment, this repository location may be any such shared memory location in a volatile or nonvolatile memory (NVM), such as a UEFI variable backed up by a flash NVM.

If the boot is in a high performance mode with no user-initiated boot interrupt (determined in diamond shape 365), control is passed directly to block 390 where the OS may be launched. Otherwise, control is passed to block 370 (control is also delivered if the platform is not enabled for high performance or enhanced boot). At block 370, initialization may continue, which may include enumerating the various I / O buses to probe (and thus initialize) the input device. Next, it can be determined in diamond shape 375 whether any boot interrupt has been received. If so, then appropriate operations such as a given BIOS routine, e.g., a display routine, that enables display of the BIOS menu may be executed (block 380). In one embodiment, such a display may be a diagnostic screen, BIOS setup user interface menu, or other display. The BIOS menu, for example, includes the following options: configure the hardware; Establishing various password prompts such as passwords to set the system clock, and / or to protect access to the BIOS user interface function itself and to prevent malicious users from booting the system from unauthorized peripheral devices . ≪ / RTI > Of course, in response to these menus, the user can provide specific information such as configuration updates, clock updates, and the like.

The BIOS can then use this information to perform storage and update of the configuration. This operation is a terminal state due to, for example, an update to the BIOS setup menu, so that a restart of the machine occurs and thus control can be passed to block 340 (for illustrative convenience, Not).

Still referring to FIG. 4, if no boot interrupt is received in the diamond shape 375, control is passed to the diamond shape 385 where it is possible to determine if a platform specific amount of time has elapsed prior to launching the OS. This predetermined amount of time may vary from platform to platform and may be based, at least in part, on a platform-specific maximum amount of time allowed to elapse for boot processing before the OS is launched. Otherwise, control returns to block 370. If the amount of time has elapsed, control is passed to block 390 where the OS may be launched.

The foregoing figures illustrate an embodiment in which the default operation is an enhanced, faster boot process wherein the user does not query the I / O device unless it overrides the enhanced processing and instead selects the boot to be interruptible. However, those skilled in the art will recognize that default processing is a matter of policy and, conversely, can be easily implemented. Thus, the choice of whether the polling of the I / O device should be part of the default boot processing is a matter of platform policy, and may be different according to different embodiments. For alternative embodiments, the default boot operation is that a query to the I / O device always occurs to provide a boot processing interrupt, but the user may instead use user override processing to perform faster, enhanced boot processing For example, without any polling or querying of I / O devices).

Thus, embodiments can be used to reduce the boot time within the BIOS to greater than 25% and to meet conflicting requirements of "instant on" and boot interruptability. Such an increase in boot performance as a normal booting behavior is also beneficial to larger platforms that are intended to enter mission critical environments and to meet the requirements of five to nine (99.999% up-time) Respectively. Boot speed is a factor due to 99.999% uptime requirements, and the platform can only be "down" for 5 minutes and 30 seconds a year. If the platform needs to be rebooted, a faster reboot is better.

Referring now to FIG. 5, a block diagram of a first system 500a and a second system 500b is shown, each capable of performing an embodiment of the enhanced boot processing described above. As shown in FIG. 5, the first system 500a may include one or more processing components 510, 515 coupled to a graphics memory controller hub (GMCH) The optional nature of the additional processing component 515 is specified by the dashed line in FIG.

Each processing element 510, 515 may be a single core or, alternatively, may comprise multiple cores. The processing components 510 and 515 may optionally include other on-die components other than a processing core such as an integrated memory controller and / or integrated I / O control logic. It should also be appreciated that for at least one embodiment of the first system 500a, the core (s) of the processing components 510, 515 may comprise more than one hardware thread context per core May be multithreaded.

FIG. 5 illustrates that the GMCH 520 may be coupled to memory 530, which may be, for example, a dynamic random access memory (DRAM). For at least one embodiment, memory 530 may include code or instructions that include an operating system.

The GMCH 520 may be part of a chipset, or chipset. The GMCH 520 may communicate with the processor (s) 510, 515 and may control the interaction between the processor (s) 510, 515 and the memory 530. The GMCH 520 may also serve as an accelerated bus interface between the processor (s) 510, 515 and other components of the system 500a. For at least one embodiment, the GMCH 520 communicates with the processor (s) 510, 515 via a multidrop bus, such as a frontside bus (FSB) For other embodiments (e.g., see FIGS. 6 and 7), the GMCH 520 communicates with the processor (s) 510, 515 via a point-to-point interconnect.

The GMCH 520 is also coupled to a display 540 (e.g., such as a flat panel display or a touch sensitive display device). The GMCH 520 may include an integrated graphics accelerator. The GMCH 520 is further coupled to an input / output (I / O) controller hub (ICH) 550 that may be used to couple various peripheral devices to the system 500a. An external graphics device 560, which may be a discrete graphics device coupled to the ICH 550 with other peripheral device (s) 570, such as one or more keyboard, mouse or numeric keypad, do.

Alternatively, additional or different processing components may also be present in the first system 500a. For example, any of the features discussed immediately below in connection with the embodiment 500b of the second system may be included in the first system 500a. The additional processing component (s) 515 may also include additional processor (s) the same as processor 510, additional processor (s) that are heterogeneous or asymmetric to processor 510, A field programmable gate array or any other processing component, such as, for example, graphics accelerators or digital signal processing (DSP) units). There may be various differences between the physical resources 510, 515 in terms of various valuable metrics including architecture, microarchitecture, temperature, power consumption characteristics, and the like. This difference can effectively manifest them as asymmetry and heterogeneity among the processing components 510, 515. For at least one embodiment, the various processing components 510, 515 may reside in the same die package.

Figure 5 also illustrates that the second system 500b may include one or more processing components 511. [ As with the first system 500a shown in FIG. 5, the system 500b is an electronic device that can be implemented using any suitable hardware and / or software to configure the electronic device 500b as desired. 5 illustrates a system 500 that includes a touch sensitive display device 502, one or more processors 511, system control logic 504 coupled to at least one processor 511, system control logic 504, Nonvolatile memory and / or storage device (s) 535 coupled to the system control logic 504 and one or more communication interfaces 506 coupled to the system control logic 504 Gt; 500b < / RTI >

The touch sensitive display device 502 (also referred to herein as a "touch screen") may include any suitable suitable device, such as, for example and without limitation, capacitive, resistive, surface acoustic wave (SAW) Can be implemented using touch sensing technology. The touch sensing technology used in the touch sensitive display device 502 for one embodiment may not require an actual touch on its surface, but rather may sense the presence of an object near the surface. Nevertheless, such a technique can be considered as a touch sensing technique, since such a technique likewise senses an object that is actually touching the surface of the display device 502, and that surface is actually touched when the electronic device 500b is used There is a possibility. The touch sensitive display device 502 for one embodiment may be implemented using any suitable multitouch technology. The touch sensitive display device 502 includes a display that can be implemented using any suitable display technology, such as for example a liquid crystal display (LCD). The system control logic 430 for at least one embodiment may include one or more graphics controllers that provide one or more display interfaces for the touch sensitive display device 502. [

The system control logic 504 for at least one embodiment includes at least one processor 511 that communicates with the system control logic 504 and / or any suitable suitable device that provides any suitable interface for any suitable device or component And an interface controller.

The system control logic 504 for at least one embodiment may include one or more memory controllers that provide an interface to the system memory 530. [ The system memory 530 may be used, for example, to load and store data and / or instructions for the system 500b. For at least one embodiment, system memory 530 may be used to store any suitable software 532, such as any suitable driver software, application software, and / or operating system software. The system memory 530 for one embodiment may include any suitable volatile memory, such as, for example, a suitable dynamic random access memory (DRAM).

System control logic 504 for at least one embodiment provides an interface to touch sensitive display device 502, non-volatile memory and / or storage device (s) 535 and communication interface (s) One or more input / output (I / O) controllers may be included.

Non-volatile memory and / or storage device (s) 535 may be used, for example, to store data and / or instructions. Non-volatile memory and / or storage device (s) 535 may comprise any suitable non-volatile memory, such as, for example, flash memory and / or may comprise one or more hard disk drives (HDD) (CD) drive and / or one or more digital versatile disk (DVD) drives. For at least one embodiment, non-volatile memory and / or storage device (s) 535 may include non-volatile read-only memory (ROM) that stores instructions 537 for BIOS processing.

The communication interface (s) 506 may provide an interface to the system 500b to communicate and / or communicate with one or more networks or with any other suitable device. The communication interface (s) 506 may comprise any suitable hardware and / or firmware. The communication interface (s) 506 for one embodiment may include, for example, a network adapter, a wireless network adapter, a telephone modem, and / or a wireless modem. For wireless communication, the communication interface (s) 506 for an embodiment may use one or more antennas 508. [

The system control logic 504 for at least one embodiment includes, for example, an audio device, a camera, a camcorder, a microphone, a microphone, a microphone, a microphone, a microphone, Output (I / O) controller to provide an interface to any suitable input / output device (s), such as a printer, printer, and / or scanner.

For at least one embodiment, at least one processor 511 may be packaged with logic for one or more controllers of the system control logic 504. For one embodiment, at least one processor 511 may be packaged with logic for one or more controllers of the system control logic 504 to form a System in Package (SiP). For one embodiment, at least one processor 511 may be integrated on the same die as the logic for one or more controllers of the system control logic 504. For one embodiment, at least one processor 511 may be integrated on the same die as one or more controller logic of system controller logic 504 to form a system on chip (SoC).

Although one embodiment has been described as being used in system 500b, a touch sensitive display device 502 for other embodiments may be used in other system configurations.

Referring now to FIG. 6, a block diagram of a third system embodiment 600 in accordance with an embodiment of the present invention is shown. 6, the multiprocessor system 600 is a point-to-point interconnect system and includes a first processing component 670 coupled via a point-to-point interconnect 650, And a processing component 680. [ 6, each of the processing components 670 and 680 may include a plurality of processor cores (e.g., processor cores 674a and 674b and processor cores 684a and 684b) Processor.

Alternatively, one or more of the processing components 670, 680 may be components other than a processor, such as an accelerator or field programmable gate array.

Although only two processing components 670 and 680 are shown, it should be understood that the scope of the appended claims is not limited thereto. In other embodiments, there may be one or more additional processing components in a given processor.

The first processing component 670 may include a memory controller hub (MCH) 672 and a point-to-point (P-P) interface 676 and 678. Similarly, the second processing component 680 may include an MCH 682 and a P-P interface 686 and 688. 6, the MCHs 672 and 682 couple processors to respective memories, that is, memory 632 and memory 634, which may be portions of the main memory locally attached to the processors .

The first processing component 670 and the second processing component 680 may be coupled to the chipset 690 via the P-P interconnects 652 and 654, respectively. As shown in FIG. 6, the chipset 690 includes P-P interfaces 694 and 698. The chipset 690 also includes an interface 692 that couples the chipset 690 with the high-performance graphics engine 638. In one embodiment, the bus 639 may be used to couple the graphics engine 638 to the chipset 690. Alternatively, the point-to-point interconnect 639 may combine these components.

In turn, the chipset 690 may be coupled to the first bus 616 via interface 696. [ In one embodiment, the first bus 616 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or other third generation I / O interconnect Connection bus.

6, various I / O devices 614 may be coupled to the first bus 616 with a bus bridge 618 coupling the first bus 616 to the second bus 620 have. In one embodiment, the second bus 620 may be a low pin count (LPC) bus. For example, in one embodiment, a data storage unit 628, such as a disk drive or other mass storage device, which may include a keyboard and / or mouse 622, communication device 626 and code 630 May be coupled to the second bus 620. The code 630 may include instructions for performing one or more of the methods described above. The audio I / O 624 may also be coupled to the second bus 620. Note that other architectures are possible. For example, instead of the point-to-point architecture of FIG. 6, the system may implement a multi-drop bus or another such architecture.

Referring now to FIG. 7, a block diagram of a fourth system embodiment 700 in accordance with an embodiment of the present invention is shown. Similar components in Figs. 6 and 7 have similar reference numerals, and certain aspects of Fig. 6 have been omitted from Fig. 7 to avoid obscuring the other aspects of Fig.

7 illustrates that the processing components 670 and 680 may include integrated memory and I / O control logic ("CL") 672 and 682, respectively. For at least one embodiment, CLs 672 and 682 may include a memory controller hub logic (MCH) as described above with respect to FIGS. 5 and 6. The CLs 672 and 682 may also include I / O control logic. 7 illustrates that I / O device 714 may also be coupled to control logic 672, 682 as well as memory 632, 634 coupled to CL 672, 682. Legacy I / O device 715 may be coupled to chipset 690.

Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation approaches. Embodiments may be implemented on a programmable system including at least one processor, a data storage system (including volatile and / or nonvolatile memory and / or storage components), at least one input device, and at least one output device Lt; / RTI >

Program code, such as code 630 illustrated in FIG. 6, may be applied to the input data to perform the functions described herein and to generate output information. For example, program code 630 may include an operating system and / or a BIOS coded to perform the embodiments illustrated in Figures 3 and 4. Accordingly, embodiments of the present invention may be embodied in many different forms and forms without departing from the spirit or scope of the invention as defined by the following claims, including instructions for performing the operations of the present invention, or machine-accessible instructions including design data such as HDL, Media. Such embodiments may also be referred to as program products.

Such a machine-accessible storage medium may be a non-volatile storage medium such as a hard disk, a floppy disk, an optical disk, a compact disk read only memory (CD-ROM), a compact disk rewritable (CD- (ROM), dynamic random access memory (DRAM), random access memory (RAM) such as static random access memory (SRAM), erasable programmable read only memory (EPROM) , A semiconductor device such as a flash memory, an electrically erasable programmable read only memory (EEPROM), a magnetic or optical card, or any type of medium suitable for storing electronic instructions. The actual construction of the article can be included without limitation.

The following examples relate to further embodiments. In one embodiment, a system includes a processor, at least one user input hardware device coupled to the processor, and a processor for performing initialization of the processor and exposing an interface to at least one user input hardware device based on the configuration of the system, And a non-volatile store that stores a pre-boot code that includes a first routine that launches the OS bootstrap code to initialize the OS without initializing at least one user input hardware device without initializing the user input hardware device of the at least one user input hardware device .

In one embodiment, the system further comprises a second storage for storing an indicator for indicating whether the next boot of the system should be interrupted by user input. The processor accesses the indicator stored in the second depot and can initialize the at least one user input hardware device if the indicator indicates that the next boot of the system should be interrupted. The processor also launches the OS bootstrap code after a predetermined time without initialization and no user input via at least one user input hardware device. The preboot code may include a second routine to receive a configuration update via at least one user input hardware device, store the configuration update in the repository, and then cause the system to be restarted. If the indicator indicates that the next boot of the system is not to be interrupted, the processor can immediately launch the OS bootstrap code without initializing at least one user input device.

In another embodiment, a method includes performing an initialization of a computer system that initializes a processor of the computer system; Executing pre-boot code of the processor, including exposing an interface to a user input hardware device of the computer system based on the configuration of the pre-boot code, but not initializing the user input hardware device; And launching the OS bootstrap code to launch the OS without initializing the user input hardware device.

The method may further include determining whether input from the user is requested prior to launching the OS bootstrap code, and, if so, invoking an interface to the user input hardware device. The user input hardware device may be initialized in response to invoking the interface. After initializing the user input hardware device, data can be obtained from the user input hardware device via the user interface handler, which can be provided to the pre-boot code. Determining whether input from a user is requested may include accessing a static variable that indicates whether a user interrupt is expected during execution of the preboot code. In one embodiment, the configuration of the pre-boot code is controlled by the user. The user may update the settings in the pre-boot code during the previous power cycle of the computer system to cause the user input hardware device to be initialized before launching the OS bootstrap code in the next power cycle of the computer system. An indicator indicating whether the next boot of the computer system should be interrupted by user input may be stored in the computer system and thus the method may include accessing the indicator during the next boot and indicating that the next boot of the computer system should be interrupted , It initializes the user input hardware device during the next boot.

In yet another embodiment, at least one computer readable medium includes instructions that, when executed, cause the computer system to perform the steps of: providing an interface to a user input hardware device of the computer system during a preboot environment, Exposing but without initializing user input hardware devices; Allows the OS bootstrap code to be launched to launch the OS in the boot environment of the computer system prior to initialization of the user input hardware device.

The medium may further comprise instructions to cause the computer system to immediately launch the OS bootstrap code prior to initialization of the user input hardware device if the indicator stored in the repository of the computer system indicates that the next boot of the computer system is not to be interrupted have. The instructions may also be used to initialize a user input hardware device if the computer system accesses an indicator stored in the depot and the indicator indicates that the next boot of the system should be interrupted, After a predetermined time without reception, the OS bootstrap code is launched. The instructions also cause the computer system to receive the configuration update via the user input hardware device and store the configuration update in the repository, after which the computer system is restarted. The instructions may also cause the computer system to initialize the user input hardware device by invoking the interface and, after initialization of the user input hardware device, obtain data corresponding to the configuration update from the user input hardware device via the user interface handler have.

The output information may be applied to one or more output devices in a known manner. For such applications, the processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC) .

The program may be implemented in a high-level procedural or object-oriented programming language to communicate with the processing system. The program may also be implemented in assembly or machine language, if desired. In fact, the mechanisms described herein are not limited to any particular programming language in that category. In any case, a language can be a language that is compiled or interpreted.

Although the present invention has been described in connection with a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. The appended claims are intended to cover all such changes and modifications that come within the true spirit and scope of the invention.

Claims (20)

As a system,
Processor means;
At least one user input hardware means coupled to the processor means; And
Means for performing initialization of the processor means and exposing an interface to the at least one user input hardware means based on the configuration of the system but without initializing the at least one user input hardware means, Non-volatile storage means for storing pre-boot code comprising a first routine for launching OS bootstrap code for launching an operating system (OS)
≪ / RTI > The method according to claim 1,
And second storage means for storing an indicator indicating whether the next boot of the system should be interrupted by user input. 3. The method of claim 2,
Wherein the processor means accesses an indicator stored in the second storage means and initializes the at least one user input hardware means if the indicator indicates that the next boot of the system should be interrupted. The method of claim 3,
Wherein the processor means launches the OS bootstrap code after a predetermined time without receiving the user input after the initialization and through the at least one user input hardware means. The method of claim 3,
Wherein the preboot code comprises a second routine for receiving a configuration update via the at least one user input hardware means and storing the configuration update in storage means and thereafter causing the system to be restarted. 3. The method of claim 2,
Wherein the processor means immediately launches the OS bootstrap code without initialization of the at least one user input hardware means if the indicator indicates that the next boot of the system is not to be interrupted. As a method,
Initializing a processor of the computer system by performing an initialization of the computer system;
Executing a preboot code of the processor, the step of exposing an interface to a user input hardware device of the computer system based on the configuration of the preboot code but not initializing the user input hardware device Included -; And
Launching an OS bootstrap code to launch an operating system (OS) without initializing the user input hardware device
≪ / RTI > 8. The method of claim 7,
Determining whether input from a user is requested prior to launching the OS bootstrap code; and if so, invoking an interface to the user input hardware device. 9. The method of claim 8,
Further comprising: initializing the user input hardware device in response to invoking the interface. 10. The method of claim 9,
Further comprising: after initializing the user input hardware device, obtaining data from the user input hardware device via a user interface handler. 11. The method of claim 10,
And providing the data to the pre-boot code. 9. The method of claim 8,
Wherein determining whether input from the user is requested comprises accessing a static variable indicating whether a user interrupt is expected during execution of the preboot code. 8. The method of claim 7,
Wherein the configuration of the preboot code is controlled by a user. 14. The method of claim 13,
Further comprising the step of allowing the user to update the settings in the preboot code during a previous power cycle of the computer system to cause the user input hardware device to be initialized prior to launching the OS bootstrap code in the next power cycle of the computer system Methods of inclusion. 8. The method of claim 7,
Storing an indicator in the computer system indicating whether a next boot of the computer system should be interrupted by user input, accessing the indicator during the next boot, and if the indicator indicates that the next boot of the computer system is interrupted And if so, initializing the user input hardware device during the next boot. As a computer system,
Means for exposing an interface to a user input hardware device of the computer system during a preboot environment based on the configuration of the computer system but not initializing the user input hardware device; And
Means for launching an OS bootstrap code to launch an operating system (OS) in a boot environment of the computer system prior to initialization of the user input hardware device
≪ / RTI > 17. The method of claim 16,
Further comprising means for launching the OS bootstrap code immediately prior to initialization of the user input hardware device if the indicator stored in the repository of the computer system indicates that the next boot of the computer system is not to be interrupted. 18. The method of claim 17,
Accessing the indicator stored in the repository and initializing the user input hardware device if the indicator indicates that the next boot of the system should be interrupted; And means for launching the OS bootstrap code after a predetermined time without reception. 17. The method of claim 16,
Further comprising means for receiving a configuration update via the user input hardware device and storing the configuration update in a repository, after which the computer system is restarted. 20. The method of claim 19,
Further comprising means for invoking the interface to initialize the user input hardware device and to obtain data corresponding to the configuration update from the user input hardware device via a user interface handler after initialization of the user input hardware device. system.

Images