Low latency boot from zero-power state

An embodiment of a semiconductor package apparatus may include technology to determine if a wake event corresponds to a zero-power state of a computer operating system, determine if a run-time state is valid to wake the operating system from the zero-power state, and wake the operating system from the zero-power state to the run-time state if the run-time state is determined to be valid. Other embodiments are disclosed and claimed.

TECHNICAL FIELD

Embodiments generally relate to computing devices. More particularly, embodiments relate to a low latency boot from zero-power state.

BACKGROUND

Computing systems or platforms may utilize various memory arrangements. A two-level memory (2LM) system may include near memory (NM) and far memory (FM). Boot time may refer to an amount of time between a power transition and when control is transferred to an operating system (OS). In general, faster boot times are preferred.

DESCRIPTION OF EMBODIMENTS

Many computing devices include a boot process, which may refer to the process of taking the machine from a zero-power state or a low-power state to a run-time state where the device is ready to be used for its intended purpose. For a vertically integrated device (e.g., where the manufacturer provides both the hardware and the software for the device), the boot process may be relatively closed off because the manufacturer controls all aspects of how the hardware and software need to operate together. For a horizontally integrated device (e.g., where the manufacturer provides only a portion of the hardware and/or software for the device), the boot process may be more open because other hardware and/or software providers may need to understand the process for bringing the device from a zero/low power state to a run-time state so that the provided hardware/software works following the boot process. Accordingly, a horizontally integrated product may provide more hooks or indicators (e.g., such as a wake vector) as part of the boot process.

For either vertically or horizontally integrated devices, some embodiments may reduce or eliminate the need for the boot process. For example, some embodiments may include non-volatile memory that fully supports the run-time state. Some embodiments may inherently always operate in a run-time state that is valid or may provide an indicator or a flag that may indicate the run-time state is valid. Accordingly, when the device is powered down, placed in a low-power state, or placed in a suspended state, the run-time state may always be sufficiently preserved such that when the device wakes (e.g., when power is restored, a button is pressed, a lid is opened, or some other action indicates that the device should return to the run-time state) the device may simply resume operation. For example, some embodiments may determine that the run-time is valid based on an indication of successful power-up/operation of the device's components/parts. In some embodiments, the device may read a flag that indicates that the run-time state is valid. Advantageously, some embodiments of a device with non-volatile memory fully supporting the run-time state may appear to be ready for operation substantially instantaneously after being turned on from a zero-power state (e.g., comparable to be resumed from a low-power/suspended state).

For some embodiments (e.g., for legacy compatibility), the device may still follow a boot process but may proceed to boot much faster by bypassing some traditional boot processes. For example, some devices may include both volatile and non-volatile memory involved in the run-time state. Some embodiments may flush the volatile memory to non-volatile before transitioning to the zero-power state, such that the run-time state may be quickly restored when waking from the zero-power state. During run-time, a flag may indicate that the run-time state is not valid to wake from the zero-power state. When transitioning to the zero-power state, if the volatile memory is successfully flushed to the non-volatile memory the flag may be set to indicate that the run-time state is valid to wake from the zero-power state.

Some embodiments may advantageously provide a zero-power low latency boot flow on 2LM machines. In some systems, an ADVANCED CONFIGURATION AND POWER INTERFACE (ACPI) S3 system state may provide a low-power suspend with a very fast resume on a computing device. The S3 low-power state may be very different from zero-power system states such as the S4 and/or S5 states (e.g., in terms of power consumption). In some applications (e.g., automotive applications, mobile applications, etc.), zero-power may be an important requirement (e.g., to reduce or eliminate battery drain). Some systems may support a system connected standby (CS) state. For example, when a MICROSOFT WINDOWS operating system is installed on a CS-enabled platform, the platform may not support S3. The S-state transitions provided may include an SOix (connected standby) state, the S4 state, and the S5 state (e.g., the latter two being zero-power states). In some other systems, transitioning from the S4 and/or S5 state to a normal operating state may involve lengthy resume times.

Advantageously, some embodiments may provide very fast wakeup of a 2LM machine from a zero-power state.

Some embodiments may enable a resume from the zero-power state in a resume time of less than 5 seconds, and some embodiments may enable a resume time of less than 2 seconds (e.g., comparable to resume times from a low-power state). For example, some embodiments may support a zero-power state that maintains the ability to wake the system and have the system be completely usable in less than 5 seconds (e.g., as measured from a CPU reset to the OS initialization complete). Advantageously, embodiments of such faster boot flows may apply to a wide class of computing devices including, for example, personal computers, servers, clients, mobile devices, etc. Some embodiments for automotive applications may support a zero-power state that maintains the ability to wake the system and have the system be usable in less than 2 seconds (e.g., as measured from the time the ignition is turned on and power is supplied to the embedded vehicle computer (e.g., navigation/infotainment system) and when the reverse-view camera is displaying an image). Advantageously, some embodiments may provide a boot flow which is both low latency and zero-power (e.g., with zero extra drain of the battery being caused by the computing device).

Various embodiments described herein may include a memory component and/or an interface to a memory component. Such memory components may include volatile and/or nonvolatile memory. Nonvolatile memory may be a storage medium that does not require power to maintain the state of data stored by the medium. In one embodiment, the memory device may include a block addressable memory device, such as those based on NAND or NOR technologies. A memory device may also include future generation nonvolatile devices, such as a three dimensional (3D) crosspoint memory device, or other byte addressable write-in-place nonvolatile memory devices. In one embodiment, the memory device may be or may include memory devices that use chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level Phase Change Memory (PCM), a resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), anti-ferroelectric memory, magnetoresistive random access memory (MRAM) memory that incorporates memristor technology, resistive memory including the metal oxide base, the oxygen vacancy base and the conductive bridge Random Access Memory (CB-RAM), or spin transfer torque (STT)-MRAM, a spintronic magnetic junction memory based device, a magnetic tunneling junction (MTJ) based device, a DW (Domain Wall) and SOT (Spin Orbit Transfer) based device, a thiristor based memory device, or a combination of any of the above, or other memory. The memory device may refer to the die itself and/or to a packaged memory product. In particular embodiments, a memory component with non-volatile memory may comply with one or more standards promulgated by the Joint Electron Device Engineering Council (JEDEC), such as JESD218, JESD219, JESD220-1, JESD223B, JESD223-1, or other suitable standard (the JEDEC standards cited herein are available at jedec.org).

Turning now toFIG. 1, an embodiment of an electronic processing system10may include a processor11, memory12communicatively coupled to the processor11, and logic13communicatively coupled to the processor11to determine if a wake event corresponds to a zero-power state (e.g., of an operating system (OS) of the electronic processing system10), determine if a run-time state is valid to wake from the zero-power state, and wake from the zero-power state to the run-time state if the run-time state is determined to be valid. For example, the logic13may be configured to determine if a wake vector is available (e.g., the wake vector including information related to a transition of the OS to the zero-power state), and wake the OS from the zero-power state based on the wake vector, if the wake vector is determined to be available. In some embodiments, the logic13may be configured to replay an initialization sequence from the zero-power state, if the wake vector is determined to be available. In some embodiments, the logic13may be further configured to determine if the memory12includes a multi-level memory with at least one level of non-volatile memory (NVM). For example, the logic13may also be configured to receive an indication of a transition to a zero-power state, and create the wake vector, if the memory12is determined to include the multi-level memory with at least one level of NVM. In some embodiments, the logic13may be further configured to initiate a flush of volatile memory to the NVM of the multi-level memory based on the received indication of the transition to the zero-power state. For example, the NVM may include PCM (e.g., 3D crosspoint memory such as INTEL 3D XPOINT memory). In some embodiments, the logic13may be located in, or co-located with, various components, including the processor11(e.g., on a same die).

Embodiments of each of the above processor11, memory12, logic13, and other system components may be implemented in hardware, software, or any suitable combination thereof. For example, hardware implementations may include configurable logic such as, for example, programmable logic arrays (PLAs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), or fixed-functionality logic hardware using circuit technology such as, for example, application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, or any combination thereof.

Alternatively, or additionally, all or portions of these components may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out the operations of the components may be written in any combination of one or more operating system (OS) applicable/appropriate programming languages, including an object-oriented programming language such as PYTHON, PERL, JAVA, SMALLTALK, C++, C# or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. For example, the memory12, persistent storage media, or other system memory may store a set of instructions which when executed by the processor11cause the system10to implement one or more components, features, or aspects of the system10(e.g., the logic13, determining if the wake event is from the zero-power state, determining if the run-time state is valid, waking to the run-time state from the zero-power state, etc.).

Turning now toFIG. 2, an embodiment of a semiconductor package apparatus20may include one or more substrates21, and logic22coupled to the one or more substrates21, wherein the logic22is at least partly implemented in one or more of configurable logic and fixed-functionality hardware logic. The logic22coupled to the one or more substrates21may be configured to determine if a wake event corresponds to a zero-power state (e.g., of an OS), determine if a run-time state is valid to wake from the zero-power state, and wake from the zero-power state to the run-time state if the run-time state is determined to be valid. For example, the logic22may be configured to determine if a wake vector is available (e.g., the wake vector including information related to a transition of the OS to the zero-power state), and wake the OS from the zero-power state based on the wake vector, if the wake vector is determined to be available. In some embodiments, the logic22may be configured to replay an initialization sequence from the zero-power state, if the wake vector is determined to be available. In some embodiments, the logic22may be further configured to determine if a system memory includes a multi-level memory with at least one level of NVM. For example, the logic22may also be configured to receive an indication of a transition to a zero-power state, and create the wake vector, if the system memory is determined to include the multi-level memory with at least one level of NVM. In some embodiments, the logic22may be further configured to initiate a flush of volatile memory to the NVM of the multi-level memory based on the received indication of the transition to the zero-power state. For example, the NVM may include PCM. In some embodiments, the logic22coupled to the one or more substrates21may include transistor channel regions that are positioned within the one or more substrates21.

Embodiments of logic22, and other components of the apparatus20, may be implemented in hardware, software, or any combination thereof including at least a partial implementation in hardware. For example, hardware implementations may include configurable logic such as, for example, PLAs, FPGAs, CPLDs, or fixed-functionality logic hardware using circuit technology such as, for example, ASIC, CMOS, or TTL technology, or any combination thereof. Additionally, portions of these components may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out the operations of the components may be written in any combination of one or more OS applicable/appropriate programming languages, including an object-oriented programming language such as PYTHON, PERL, JAVA, SMALLTALK, C++, C# or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.

The apparatus20may implement one or more aspects of the method28(FIGS. 3A to 3C), or any of the embodiments discussed herein. In some embodiments, the illustrated apparatus20may include the one or more substrates21(e.g., silicon, sapphire, gallium arsenide) and the logic22(e.g., transistor array and other integrated circuit/IC components) coupled to the substrate(s)21. The logic22may be implemented at least partly in configurable logic or fixed-functionality logic hardware. In one example, the logic22may include transistor channel regions that are positioned (e.g., embedded) within the substrate(s)21. Thus, the interface between the logic22and the substrate(s)21may not be an abrupt junction. The logic22may also be considered to include an epitaxial layer that is grown on an initial wafer of the substrate(s)21.

Turning now toFIGS. 3A to 3C, an embodiment of a method28of waking an OS may include determining if a wake event corresponds to a zero-power state at block29(e.g., a zero-power state of an OS), determining if a run-time state is valid to wake from the zero-power state at block30, and waking from the zero-power state to the run-time state if the run-time state is determined to be valid at block31. For example, the method28may include determining if a wake vector is available at block32(e.g., the wake vector including information related to a transition of the OS to the zero-power state), and waking the OS from the zero-power state based on the wake vector at block33, if the wake vector is determined to be available. Some embodiments of the method28may include replaying an initialization sequence from the zero-power state at block34, if the wake vector is determined to be available. Some embodiments of the method28may also include determining if a system memory includes a multi-level memory with at least one level of NVM at block35. For example, the method28may include receiving an indication of a transition to a zero-power state at block36, and creating the wake vector at block37, if the system memory is determined to include the multi-level memory with at least one level of NVM. Some embodiments of the method28may further include initiating a flush of volatile memory to the NVM of the multi-level memory based on the received indication of the transition to the zero-power state at block38. For example, the NVM may include PCM at block39.

Embodiments of the method28may be implemented in a system, apparatus, computer, device, etc., for example, such as those described herein. More particularly, hardware implementations of the method28may include configurable logic such as, for example, PLAs, FPGAs, CPLDs, or in fixed-functionality logic hardware using circuit technology such as, for example, ASIC, CMOS, or TTL technology, or any combination thereof. Alternatively, or additionally, the method28may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out the operations of the components may be written in any combination of one or more OS applicable/appropriate programming languages, including an object-oriented programming language such as PYTHON, PERL, JAVA, SMALLTALK, C++, C# or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.

For example, the method28may be implemented on a computer readable medium as described in connection with Examples 23 to 29 below. Embodiments or portions of the method28may be implemented in firmware, applications (e.g., through an application programming interface (API)), or driver software running on an operating system (OS).

Turning now toFIG. 4, some embodiments may be physically or logically arranged as one or more modules or components. For example, an embodiment of an electronic processing system40may include a processor41, persistent storage media42(e.g., a hard disk drive (HDD), a solid state drive (SSD), etc.) communicatively coupled to the processor41, boot logic43communicatively coupled to the processor, and a memory controller44communicatively coupled to the processor41and the boot logic43. The memory controller44may also be communicatively coupled to a two-level memory (2LM)45including a first level memory46and a second level memory47. In various embodiments, any of the first level memory46and the second level memory47may include NVM and/or volatile memory. For example, the 2LM45may correspond to system memory or main memory having a near memory and a far memory. The first level memory46may correspond to the near memory and include smaller, faster DRAM. The second level memory47may correspond to the far memory and include larger storage capacity NVM (e.g. a byte-addressable 3D crosspoint memory). In some embodiments, the boot logic43may be configured to determine if a wake event corresponds to a zero-power state, determine if a wake vector is available, and wake an OS from the zero-power state based on the wake vector, if the wake vector is determined to be available.

In some embodiments, the boot logic43may be configured to replay an initialization sequence from the zero-power state, if the wake vector is determined to be available. In some embodiments, the boot logic43may be further configured to determine that the system memory includes the 2LM45including NVM for the second level memory47. For example, the boot logic43may also be configured to receive an indication of a transition to a zero-power state, and create the wake vector (e.g., because the 2LM45includes NVM for the second level memory47). In some embodiments, the boot logic43may be further configured to initiate a flush of the first level memory46(e.g., DRAM) to the second level memory47(e.g., NVM) of the 2LM45based on the received indication of the transition to the zero-power state. For example, portions or aspects of the boot logic43may be integrated with various other components of the system40(e.g., on a same die as one or more of the processor41, the memory controller44, etc.).

Embodiments of the processor41, the persistent storage media42, the boot logic43, the memory controller44, the 2LM45, the first level memory46, the second level memory47, and other components of the system40, may be implemented in hardware, software, or any combination thereof including at least a partial implementation in hardware. For example, hardware implementations may include configurable logic such as, for example, PLAs, FPGAs, CPLDs, or fixed-functionality logic hardware using circuit technology such as, for example, ASIC, CMOS, or TTL technology, or any combination thereof. Additionally, portions of these components may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out the operations of the components may be written in any combination of one or more OS applicable/appropriate programming languages, including an object-oriented programming language such as PYTHON, PERL, JAVA, SMALLTALK, C++, C# or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.

Turning now toFIG. 5, an embodiment of a method50of booting an operating system may include portions performed by a basic input/output system (BIOS) shown in dotted lines and portions performed by the OS shown in dashed lines. When the BIOS starts at block51(e.g., following a wake event), the BIOS may write script data which may be captured at block52to keep an input/output (IO) replay database of hardware (HW) initialization sequences during normal boot. The BIOS may hand over control to an OS loader at block53which may perform OS initialization of the HW/SW at block54to place the OS into a run-time state at block55. While the OS is running at block55, some action or software trigger may initiate a transition to a low-power or zero-power state. The OS may then determine if the SOix (CS) state should be entered at block56. If so, a monitor wait (MWAIT) instruction may place the OS in the low-power CS state at block57until the monitored condition is detected and the OS resumes running at block55. Otherwise, the OS may determine if there was a request for S4 at block58. If not, the OS may continue running at block55. If so, based on OS power management (OSPM) policy and whether wake from S4 is supported at block59, the OS may skip hiberfile creation and set an address for the waking vector to a non-zero-value at block60(e.g., a zero value for the S4 waking vector may indicate that wake from S4 is not available) and establish an S4 waking vector. Otherwise, the OS may create the hiberfile at block61. Following either block60or block61, the OS may call sleep register S4 transition at block62and the BIOS may call the S4 handler to perform the system shutdown at block63(e.g., which may retrieve the replay script data). After the system shuts down (e.g., S4, S5, etc.), upon a wake event (e.g., open-lid, power button, etc.), the BIOS may check the reason for the shutdown (e.g., S4), and if the address for the S4 waking vector is non-zero at block64. If not, the BIOS may restart from block51. If so, the BIOS may initiate memory reference code (MRC) initialization and IO replay at block65, and may then jump to the S4 OS waking vector at block66to wake the OS at block67and place the OS into the run-time state at block55.

Advantageously, by providing hints to the OS, some embodiments may enable the OS to bypass some of the time-consuming S4/zero-power state transitions actions (e.g. writing of the hiberfile) and establish a waking vector. In addition, in some embodiments the BIOS may leverage underlying IO HW replay support (e.g., not normally used in the S4 state) to quickly initialize the HW and then jump to a waking vector that the OS establishes. Using both of these improvements together, and by leveraging characteristics of the underlying HW (e.g., persistent media in the 2LM), some embodiments may advantageously provide a zero-power/low-latency boot flow. For example, some embodiments may allow a platform that has been placed in a zero-power state to resume in a manner similar to a platform that has simply been quiesced. Some embodiments may advantageously provide a near instant-on feel when the user opens the lid or presses the power button.

Turning now toFIG. 6, an embodiment of a method70of waking an OS may include portions performed by a BIOS shown in dotted lines, portions performed by an OS shown in dashed lines, and portions performed by microcode such as processor code (PCODE) shown in lines with alternating dots and dashes. After the BIOS starts at block71(e.g., following a hard reset), the BIOS may hand over control to an OS loader at block72which may perform OS initialization of the HW/SW at block73to place the OS into a run-time state at block74. While the OS is running at block74, some action or software trigger may initiate a transition to a low-power or zero-power state. The OS may then determine if the SOix (CS) state should be entered at block75. If so, a monitor wait (MWAIT) instruction may place the OS in the low-power CS state at block76until the monitored condition is detected and the OS resumes running at block74. Otherwise, the OS may determine if there was a request for S4 at block77. If not, the OS may continue running at block74. If so, the OS may skip hiberfile creation at block78and establish a waking vector at block79. The OS may then call sleep register S4 transition at block80. PCODE may then initiate a flush on write of a sleep enable indicator (e.g., SLP_EN) for the S-state transition at block81, and the BIOS may call the S4 handler to perform the system shutdown at block82. After the system shuts down, upon a wake event (e.g., open-lid, power button, etc.), the BIOS may initiate a resume from zero-power at block83, and jump to the waking vector at block84to wake the OS at block85and place the OS into the run-time state at block74.

Turning now toFIG. 7, an embodiment of a method90of waking an OS may include portions performed by a BIOS shown in dotted lines, portions performed by an OS shown in dashed lines, and portions performed by PCODE shown in lines with alternating dots and dashes. The method90may include using hints and/or information such as a pointer to a waking vector (e.g., #1=X Firmware_Waking_VECTOR), a flag to indicate if the system is CS-enabled (e.g., #2=Low_Power_SO_Idle_Capable), and a flag to indicate if the system supports low latency wake from the S4 state (e.g., #3=S4_Wake_Supported). When the BIOS starts at block91(e.g., following a hard reset), an extensible firmware interface (EFI) (e.g., Unified EFI (UEFI), version 2.7, published May 2017, uefi.org) may include a pre-EFI initialization (PEI) phase (e.g., early HW initialization including MRC) where S3 script data may be written which may be captured at block92to keep an IO replay database of HW initialization sequences during normal boot. At block93, a UEFI driver execution environment (DXE) phase may load drivers and initialize IO, busses, etc. For a MICROSOFT WINDOWS environment, the BIOS/UEFI may hand over control to an OS loader at block94which may perform OS initialization of the OS and read values for #2 and #3 at block95to place the OS into a run-time state at block96. While the OS is running at block96, some action or software trigger may initiate a transition to a low-power or zero-power state. The OS may first determine if #2 is true at block97. If not, the OS may indicate that CS is not active at block98, and the OS may continue to run at block96. If so, the OS may indicate that CS is active at block99and then determine if the SOix state should be entered at block100. If so, a MWAIT instruction may place the OS in the low-power CS state at block101until the monitored condition is detected and the OS resumes running at block96. Otherwise, the OS may determine if #3 is true at block102. If not, the OS may continue running at block96. If so, the OS may suspend applications and devices (e.g., skipping hiberfile write) at block103and set an address for #1 for the waking vector, initiate S4 sleep register write, and establish a waking vector at block104. PCODE may then initiate a flush on write of a sleep enable indicator (e.g., SLP_EN) for the S-state transition at block105, after which the system may shut down. After the system shuts down, upon a wake event (e.g., open-lid, power button, etc.), the BIOS may initiate a resume from zero-power using IO replay data at block106(e.g., retrieving the S3 script data), and jump to the waking vector at block107to wake the OS at block108and place the OS into the run-time state at block96.

Turning now toFIG. 8, an embodiment of an electronic processing system110may include a central processor unit (CPU)111coupled to a platform controller hub (PCH)112. The CPU111may include an integrated near memory (NM) controller111acoupled to one or more DRAM devices113, and an integrated far memory (FM) controller111bcoupled to one or more NVM devices114(e.g., INTEL 3D XPOINT memory media, INTEL OPTANE MEMORY, etc.). The DRAM113and NVM114may be configured as a 2LM main memory system for the system110. The PCH112may be coupled to one or more mass persistent storage media devices115(e.g., such as a SSD or HDD). For example, the technology of the system110may include a combination of 3D XPOINT memory media, INTEL memory and/or storage controllers, INTEL INTERCONNECT IP, and INTEL software which may be referred to as INTEL OPTANE TECHNOLOGY.

Some embodiments of the system110may include flags and/or additional information to enable various aspects of the zero-power low latency boot flow. Some embodiments may utilize and/or repurpose flags and/or information from other boot flows. For example, some systems may include a firmware waking vector (FWV) value as specified by ACPI which may be used by the S3 (standby) state. In some embodiments, the BIOS may establish a zero'ed FWV value that may be exposed to the OS. If during a S4 resume, the BIOS determines that the FWV value has changed from its zero'ed state to something other than that, the BIOS may use the FWV value to wake the OS (e.g., if and only if the BIOS knows or determines that the platform is 2LM and S4 wake-enabled). For example, the OS may advantageously establish a waking vector when going into the S4 state (normally only done for the S3 state) and set the FWV value to a physical memory address for the zero-power waking vector.

Additionally, in some embodiments, the BIOS may expose a flag/bit that the OS may use to determine if the machine is in fact a 2LM machine (e.g., including NVM in the 2LM). Normally a 2LM machine may be software invisible. Some embodiments may use this platform hint to make a policy decision that may be included in the boot flow. For example, the OS may normally have a choice during operation that if the machine was idle, the machine may go into an SOix mode to save power. However, normally when a thermal or battery event occurs, the OS may go into an S4 mode to go into a zero-power state. By using the hint provided by the platform, the OS may then alternately choose to establish a waking vector and communicate the choice back to the BIOS by updating the standard FWV value (normally used by S3). Advantageously, the flags/information provided by some embodiments of a 2LM-type system may provide an improved or optimal mode that may resume very quickly from a zero-power state.

FIG. 9Ashows a zero-power low latency boot apparatus132(132a-132g) that may implement one or more aspects of the method28(FIGS. 3A to 3C), the method50(FIG. 5), the method70(FIG. 6), and/or the method90(FIG. 7). The zero-power low latency boot apparatus132, which may include logic instructions, configurable logic, fixed-functionality hardware logic, may be readily substituted for the logic13(FIG. 1), and/or the boot logic43, already discussed. A wake detector132amay include technology to detect a wake event. A wake vector detector132bmay include technology to detect if a zero-power wake vector is available. An OS waker132cmay include technology to wake an OS using the zero-power wake vector. For example, the wake detector132amay include technology to determine if a wake event corresponds to a zero-power state. The wake vector detector132bmay include technology to determine if a wake vector is available. The OS waker132cmay include technology to wake the OS from the zero-power state based on the wake vector, if the wake vector is determined to be available. In some embodiments, the OS waker132cmay be configured to replay an initialization sequence from the zero-power state, if the wake vector is determined to be available. In some embodiments, the wake vector detector132bmay be further configured to determine if a system memory includes a multi-level memory with at least one level of NVM. For example, the OS waker132cmay also be configured to receive an indication of a transition to a zero-power state, and to create the wake vector, if the system memory is determined to include the multi-level memory with at least one level of NVM. In some embodiments, the OS waker132cmay be further configured to initiate a flush of volatile memory to the NVM of the multi-level memory based on the received indication of the transition to the zero-power state. For example, the NVM may include PCM.

Turning now toFIG. 9B, zero-power low latency boot apparatus134(134a,134b) is shown in which logic134b(e.g., transistor array and other integrated circuit/IC components) is coupled to a substrate134a(e.g., silicon, sapphire, gallium arsenide). The logic134bmay generally implement one or more aspects of the method28(FIGS. 3A to 3C), the method50(FIG. 5), the method70(FIG. 6), and/or the method90(FIG. 7). Thus, the logic134bmay determine if a wake event corresponds to a zero-power state, determine if a wake vector is available, and wake an OS from the zero-power state based on the wake vector, if the wake vector is determined to be available. In some embodiments, the logic134bmay replay an initialization sequence from the zero-power state, if the wake vector is determined to be available. In some embodiments, the logic134bmay also determine if a system memory includes a multi-level memory with at least one level of NVM. For example, the logic134bmay also receive an indication of a transition to a zero-power state, and create the wake vector, if the system memory is determined to include the multi-level memory with at least one level of NVM. In some embodiments, the logic134bmay initiate a flush of volatile memory to the NVM of the multi-level memory based on the received indication of the transition to the zero-power state. For example, the NVM may include PCM. In one example, the apparatus134is a semiconductor die, chip and/or package.

FIG. 10also illustrates a memory270coupled to the processor core200. The memory270may be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those of skill in the art. The memory270may include one or more code213instruction(s) to be executed by the processor core200, wherein the code213may implement one or more aspects of the method28(FIGS. 3A to 3C), the method50(FIG. 5), the method70(FIG. 6), and/or the method90(FIG. 7), already discussed. The processor core200follows a program sequence of instructions indicated by the code213. Each instruction may enter a front end portion210and be processed by one or more decoders220. The decoder220may generate as its output a micro operation such as a fixed width micro operation in a predefined format, or may generate other instructions, microinstructions, or control signals which reflect the original code instruction. The illustrated front end portion210also includes register renaming logic225and scheduling logic230, which generally allocate resources and queue the operation corresponding to the convert instruction for execution.

Although not illustrated inFIG. 10, a processing element may include other elements on chip with the processor core200. For example, a processing element may include memory control logic along with the processor core200. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches.

Referring now toFIG. 11, shown is a block diagram of a system1000embodiment in accordance with an embodiment. Shown inFIG. 11is a multiprocessor system1000that includes a first processing element1070and a second processing element1080. While two processing elements1070and1080are shown, it is to be understood that an embodiment of the system1000may also include only one such processing element.

Each processing element1070,1080may include at least one shared cache1896a,1896b(e.g., static random access memory/SRAM). The shared cache1896a,1896bmay store data (e.g., objects, instructions) that are utilized by one or more components of the processor, such as the cores1074a,1074band1084a,1084b, respectively. For example, the shared cache1896a,1896bmay locally cache data stored in a memory1032,1034for faster access by components of the processor. In one or more embodiments, the shared cache1896a,1896bmay include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof.

As shown inFIG. 11, various I/O devices1014(e.g., cameras, sensors) may be coupled to the first bus1016, along with a bus bridge1018which may couple the first bus1016to a second bus1020. In one embodiment, the second bus1020may be a low pin count (LPC) bus. Various devices may be coupled to the second bus1020including, for example, a keyboard/mouse1012, network controllers/communication device(s)1026(which may in turn be in communication with a computer network), and a data storage unit1019such as a disk drive or other mass storage device which may include code1030, in one embodiment. The code1030may include instructions for performing embodiments of one or more of the methods described above. Thus, the illustrated code1030may implement one or more aspects of the method28(FIGS. 3A to 3C), the method50(FIG. 5), the method70(FIG. 6), and/or the method90(FIG. 7), already discussed, and may be similar to the code213(FIG. 10), already discussed. Further, an audio I/O1024may be coupled to second bus1020.

Note that other embodiments are contemplated. For example, instead of the point-to-point architecture ofFIG. 11, a system may implement a multi-drop bus or another such communication topology.

Additional Notes and Examples:

Example 1 may include an electronic processing system, comprising a processor, memory communicatively coupled to the processor, and logic communicatively coupled to the processor to determine if a wake event corresponds to a wake from a zero-power state, determine if a run-time state is valid to wake from the zero-power state, and wake from the zero-power state to the run-time state if the run-time state is determined to be valid.

Example 2 may include the system of Example 1, wherein the logic is further to determine if a wake vector is available, and wake an operating system from the zero-power state based on the wake vector, if the wake vector is determined to be available.

Example 3 may include the system of Example 2, wherein the logic is further to replay an initialization sequence from the zero-power state, if the wake vector is determined to be available.

Example 4 may include the system of Example 2, wherein the logic is further to determine if the memory includes a multi-level memory with at least one level of non-volatile memory.

Example 5 may include the system of Example 4, wherein the logic is further to receive an indication of a transition to a zero-power state, and create the wake vector, if the memory is determined to include the multi-level memory with at least one level of non-volatile memory.

Example 6 may include the system of Example 5, wherein the logic is further to initiate a flush of volatile memory to the non-volatile of the multi-level memory based on the received indication of the transition to the zero-power state.

Example 7 may include the system of any of Examples 4 to 6, wherein the nonvolatile memory comprises phase change memory.

Example 8 may include a semiconductor package apparatus, comprising one or more substrates, and logic coupled to the one or more substrates, wherein the logic is at least partly implemented in one or more of configurable logic and fixed-functionality hardware logic, the logic coupled to the one or more substrates to determine if a wake event corresponds to a zero-power state, determine if a run-time state is valid to wake from the zero-power state, and wake from the zero-power state to the run-time state if the run-time state is determined to be valid.

Example 9 may include the apparatus of Example 8, wherein the logic is further to determine if a wake vector is available, and wake an operating system from the zero-power state based on the wake vector, if the wake vector is determined to be available.

Example 10 may include the apparatus of Example 9, wherein the logic is further to replay an initialization sequence from the zero-power state, if the wake vector is determined to be available.

Example 11 may include the apparatus of Example 9, wherein the logic is further to determine if a system memory includes a multi-level memory with at least one level of non-volatile memory.

Example 12 may include the apparatus of Example 11, wherein the logic is further to receive an indication of a transition to a zero-power state, and create the wake vector, if the system memory is determined to include the multi-level memory with at least one level of non-volatile memory.

Example 13 may include the apparatus of Example 12, wherein the logic is further to initiate a flush of volatile memory to the non-volatile memory of the multi-level memory based on the received indication of the transition to the zero-power state.

Example 14 may include the apparatus of any of Examples 11 to 13, wherein the non-volatile memory comprises phase change memory.

Example 15 may include the apparatus of any of Examples 8 to 14, wherein the logic coupled to the one or more substrates includes transistor channel regions that are positioned within the one or more substrates.

Example 16 may include a method of waking an operating system, comprising determining if a wake event corresponds to a zero-power state, determining if a run-time state is valid to wake from the zero-power state, and waking from the zero-power state to the run-time state if the run-time state is determined to be valid.

Example 17 may include the method of Example 16, further comprising determining if a wake vector is available, and waking an operating system from the zero-power state based on the wake vector, if the wake vector is determined to be available.

Example 18 may include the method of Example 17, further comprising replaying an initialization sequence from the zero-power state, if the wake vector is determined to be available.

Example 19 may include the method of Example 17, further comprising determining if a system memory includes a multi-level memory with at least one level of non-volatile memory.

Example 20 may include the method of Example 19, further comprising receiving an indication of a transition to a zero-power state, and creating the wake vector, if the system memory is determined to include the multi-level memory with at least one level of non-volatile memory.

Example 21 may include the method of Example 20, further comprising initiating a flush of volatile memory to the non-volatile memory of the multi-level memory based on the received indication of the transition to the zero-power state.

Example 22 may include the method of any of Examples 19 to 21, wherein the non-volatile memory comprises phase change memory.

Example 23 may include at least one computer readable medium, comprising a set of instructions, which when executed by a computing device, cause the computing device to determine if a wake event corresponds to a zero-power state, determine if a run-time state is valid to wake from the zero-power state, and wake from the zero-power state to the run-time state if the run-time state is determined to be valid.

Example 24 may include the at least one computer readable medium of Example 23, comprising a further set of instructions, which when executed by the computing device, cause the computing device to determine if a wake vector is available, and wake an operating system from the zero-power state based on the wake vector, if the wake vector is determined to be available.

Example 25 may include the at least one computer readable medium of Example 24, comprising a further set of instructions, which when executed by the computing device, cause the computing device to replay an initialization sequence from the zero-power state, if the wake vector is determined to be available.

Example 26 may include the at least one computer readable medium of Example 24, comprising a further set of instructions, which when executed by the computing device, cause the computing device to determine if a system memory includes a multi-level memory with at least one level of non-volatile memory.

Example 27 may include the at least one computer readable medium of Example 26, comprising a further set of instructions, which when executed by the computing device, cause the computing device to receive an indication of a transition to a zero-power state, and create the wake vector, if the system memory is determined to include the multi-level memory with at least one level of non-volatile memory.

Example 28 may include the at least one computer readable medium of Example 27, comprising a further set of instructions, which when executed by the computing device, cause the computing device to initiate a flush of volatile memory to the non-volatile memory of the multi-level memory based on the received indication of the transition to the zero-power state.

Example 29 may include the at least one computer readable medium of any of Examples 26 to 28, wherein the non-volatile memory comprises phase change memory.

Example 30 may include a computing apparatus, comprising means for determining if a wake event corresponds to a zero-power state, means for determining if a run-time state is valid to wake from the zero-power state, and means for waking from the zero-power state to the run-time state if the run-time state is determined to be valid.

Example 31 may include the apparatus of Example 30, further comprising means for determining if a wake vector is available, and means for waking an operating system from the zero-power state based on the wake vector, if the wake vector is determined to be available.

Example 32 may include the apparatus of Example 31, further comprising means for replaying an initialization sequence from the zero-power state, if the wake vector is determined to be available.

Example 33 may include the apparatus of Example 31, further comprising means for determining if a system memory includes a multi-level memory with at least one level of non-volatile memory.

Example 34 may include the apparatus of Example 33, further comprising means for receiving an indication of a transition to a zero-power state, and means for creating the wake vector, if the system memory is determined to include the multi-level memory with at least one level of non-volatile memory.

Example 35 may include the apparatus of Example 34, further comprising means for initiating a flush of volatile memory to the non-volatile memory of the multi-level memory based on the received indication of the transition to the zero-power state.

Example 36 may include the apparatus of any of Examples 33 to 35, wherein the non-volatile memory comprises phase change memory.

As used in this application and in the claims, a list of items joined by the term “one or more of” may mean any combination of the listed terms. For example, the phrase “one or more of A, B, and C” and the phrase “one or more of A, B, or C” both may mean A; B; C; A and B; A and C; B and C; or A, B and C.