Patent ID: 12223308

The figures are not to scale. In general, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts. As used herein, connection references (e.g., attached, coupled, connected, and joined) are to be construed in light of the specification and, when pertinent, the surrounding claim language. Construction of connection references in the present application shall be consistent with the claim language and the context of the specification which describes the purpose for which various elements are connected. As such, connection references do not necessarily infer that two elements are directly connected and in fixed relation to each other.

Descriptors “first,” “second,” “third,” etc. are used herein when identifying multiple elements or components which may be referred to separately. Unless otherwise specified or understood based on their context of use, such descriptors are not intended to impute any meaning of priority, physical order or arrangement in a list, or ordering in time but are merely used as labels for referring to multiple elements or components separately for ease of understanding the disclosed examples. In some examples, the descriptor “first” may be used to refer to an element in the detailed description, while the same element may be referred to in a claim with a different descriptor such as “second” or “third.” In such instances, it should be understood that such descriptors are used merely for ease of referencing multiple elements or components.

DETAILED DESCRIPTION

Some entities (e.g., cloud service providers) provide services (e.g., compute-as-a-service (CaaS)) to computing devices of users (e.g., computers, laptops, servers, virtual machines, etc.). Initially, the entity may provide (e.g., deploy) software, instructions, commands, etc., that may be implemented at the computing device of a user. However, as the entity generates updated software, instructions, patches, etc., the entity may deploy updates to the computing devices to update the computing system.

Traditionally, when an update from an entity includes or is based on a firmware update (e.g., updating the configuration of firmware at the computing device), a computing device performs a full reboot to install the firmware update. During a full reboot, the operating system of the computing device shuts down and restarts all the processes and/or components of the computing device (e.g., including hardware drivers, kernels etc.) by interacting with the ACPI and/or the Basic Input/Output System (BIOS). The BIOS is firmware that performs hardware initialization during power up and/or booting the computing device. The ACPI is an interface layer between the system hardware and/or firmware and the operating system.

Although firmware updates may be vital to the performance and/or security of the computing device, a full boot causes the computing device to be inoperable and/or unusable for a few minutes. Such disruptions are undesirable. In some examples, such disruptions of service may violate a contract corresponding to a percentage of “ON” time and/or memory requirements. Additionally, a cloud service provider may require that computing devices (e.g., servers, virtual machines, etc.) keep memory intact. However, traditional firmware-based reboots may destroy the memory contents in violation of the requirement from the cloud service provider. Accordingly, to comply with the cloud server provider requirements, traditional firmware updating techniques include migrating workload and/or other information from the computing device to other nodes in a network of servers to be temporarily stored in the memory of the other nodes until the computing device reboots and can reload the remotely stored data. Accordingly, such traditional firmware updates are undesirable due to the time and resource consumption required to perform such traditional firmware updates.

Examples disclosed herein eliminate the need of a traditional full reboot to perform a firmware update at a computing device, thereby reducing the downtime and computing resources associated with traditional firmware updates. Examples disclosed herein eliminate the traditional reboot by leveraging the S3 sleep state (also referred to as S3 state or S3) infrastructure of a computing system established in the operating systems (OS) (e.g., Windows, Linux, etc.). As used herein, S3 is a sleep state or power state of a computing device. Sleep states may include an S0 state (e.g., a wake state in which most components of a computer are fully powered), S1 state (e.g., a sleep state in which the CPU is stopped and the computer in standby mode), S2 state (e.g., the CPU is stopped, the computer is in standby mode, the CPU context and contents of the system cache are lost due to power loss of the processor), S3 state (e.g., data or context is saved in RAM, and hard drives, fans, etc. are shut down), S4 state (e.g., data or context is saved to disk, also known as hibernate), and S5 state (e.g., complete shutdown power state).

Examples disclosed herein trigger a pseudo-S3 protocol, which the OS interprets or detects as an S3 protocol (e.g., the OS ‘thinks’ that a S3 protocol is being implemented). In this manner, the OS pauses the drivers, keeps the memory intact, keeps the stack pointers intact (e.g., by storing in memory), etc. While in the OS interprets the pseudo-S3 protocol as if the S3 protocol is being performed, examples disclosed herein perform a pseudo-S3 protocol instead of entering the sleep date or performing a full reboot by performing a warm reset to update firmware without destroying the physical memory content, and ensuring that the memory related configurations (e.g., stack pointer, OS operations, etc.) are not changed. In this manner, upon pseudo-S3 resume (e.g., returning from a pseudo-S3 state), the OS continues operation based on the location of the stack pointer (e.g., kept prior to entering the pseudo-S3 state) with updated firmware without performing a full reboot. Using examples disclosed herein, the system utilizes sleep states to perform a firmware update without actually entering into a sleep state or performing a warm reset or full reboot.

FIG.1illustrates an environment100to deploy and implement a firmware update at an example computing device106without performing a full reboot. The example environment100includes an example server102, an example network104, and the example computing device106. The example computing device106includes an example interface108, an example general-purpose input/output (GPIO)112, an example baseboard management controller (BMC)114, an example advanced configuration and power interface (ACPI)116, an example processor117in communication with an example operating system (OS)118, an example BIOS119including an example BIOS system management interrupt (SMI) handler120and an example boot BIOS122, and an example memory124.

The example server102ofFIG.1is a computing device that deploys updates (e.g., software updates, firmware updates, etc.) to the example computing device106via the example network104. For example, an entity utilizes the server102to transmit developed updates to the computing device106periodically, aperiodically, and/or based on a trigger (e.g., when an update is available). The example server102may generate the update and/or may obtain the update from another device (e.g., developed by a developer).

The example network104ofFIG.1is a system of interconnected systems exchanging data between the server102and computing devices (e.g., including the computing device106). The example network104may be implemented using any type of public or private network such as, but not limited to, the Internet, a telephone network, a local area network (LAN), a cable network, and/or a wireless network. To enable communication via the network104, the example server102and/or the computing device106includes a communication interface that enables a connection to an Ethernet, a digital subscriber line (DSL), a telephone line, a coaxial cable, or any wireless connection, etc.

The example computing device106ofFIG.1is a device that implements an operating system. The example computing device106may be a server, a virtual machine, a laptop, etc. The example computing device106includes an interface108to obtain updates (e.g., firmware updates) from the server102via the network104and provide the updates to the computing device106. The interface108could be or include an input/output (I/O) interface (e.g., to interface with to the network104, the memory124, an accelerator, or any other I/O device). The firmware updates can include updates to firmware or firmware components in any component of the computing device106that includes firmware (e.g., the BMC114, the ACPI116, the processor117, the example BIOS119, a manageability engine, a solid state device, a network on chip, etc.).

The example GPIO pin112ofFIG.1is a digital pin or a multi-pin of the BMC114. However, the example GPIO pin112can be or can be included in a platform controller hub (PCH) or a processor uncore or a I/O controller register. The example GPIO pin112of the BMC114, when level triggered, may be used to output a signal or voltage level (e.g., representative of a binary zero or a binary one) that initiates a pseudo-S3 event and/or firmware update. The example GPIO pin112, when end triggered, may be used to trigger a pseudo-S3 event and/or firmware update when the pin changes from high to low or from low to high. In this manner, the BMC114can assert the GPIO pin112(e.g., by setting a zero or greater voltage level at the GPIO pin112to set the GPIO pin112to active) to initiate the pseudo-S3 protocol to update firmware in response to obtaining a firmware update via the interface108. As further described below, the ACPI116monitors the GPIO pin112to determine when the BMC114has transmitted the signal to the GPIO pin112, thereby determining that a pseudo-S3 event is to occur and performs operations to facilitate the pseudo-S3 event. In some examples, instead of using the GPIO pin112to initiate a pseudo S3 event, the OS118and/or some other management agent may inform the BIOS119of the pseudo-S3 event through an in-band message.

The example BMC114ofFIG.1is a device that monitors the physical state of the computing device106using sensors (e.g., measuring internal characteristics such as fan speed, temperature, power-supply voltage, humidity, OS functions, communication parameters, etc.) and by communicating with a system administrator through an independent connection. The example BMC114can notify the administrator if any sensed characteristic varies outside of a predefined range. In some examples, the BMC114includes and/or is implemented by firmware. When the server102transmits a firmware update, the BMC114ofFIG.1identifies that the update includes a firmware update and assert the GPIO pin112corresponding to a firmware update to set the GPIO pin112corresponding to the firmware update and/or pseudo-S3 event to active. In this manner, the example ACPI116, which monitors the GPIO pin112, can determine that the pseudo-S3 event is to occur.

The example ACPI116ofFIG.1facilitates the identification and/or configuration of computer hardware components to perform power management (e.g., putting components to sleep, status monitoring, etc.). In some examples, the ACPI116includes and/or is implemented by firmware. The ACPI116monitors the GPIO pin112. In response to the BMC114asserting the GPIO pin112, the ACPI116determines that the obtained update is a firmware update because the GPIO pin112of the BMC114was asserted. The example ACPI116determines that because the GPIO pin112was asserted, a pseudo-S3 protocol should be initiated based on the asserted pin of the GPIO pin112. In response to determining that the update is a firmware update, the example ACPI116conveys the initiation of a pseudo-S3 protocol to the BIOS SMI handler120using a flag (e.g., by setting a pseudo-S3 flag, changing the value in a dedicated register corresponding to pseudo-S3, utilizing a unified extensible firmware interface (UEFI) variable to identify the pseudo-S3 protocol, and/or using any other method of flagging a pseudo-S3 event to BIOS SMI handler120). A UEFI variable stores data (e.g., non-volatile data) that can be shared between firmware and the OS118. In this manner, the UEFI variable can share whether a flag is set or not based on the value of the UEFI variable. After setting the pseudo-S3 flag, the ACPI116asserts a power button event. A power button event occurs on the computing device106when the power button is pressed (e.g., to enter into a sleep state, exit from a sleep state, power down, and/or restart). Accordingly, the ACPI116asserts a power button event to initiate the OS118to prepare to enter into the sleep state (e.g., S3).

The example OS118ofFIG.1is a software system managing the example processor117to manage hardware of the computing device106, software resources, and/or provides servers for computer programs and/or applications. When the example OS118determines that the power button event occurred while the computing device106is powered on (e.g., in the S0 state), the OS118handles the power button event as a normal S3 event by executing the S3 protocol steps that trigger S3 flow. For example, the OS118writes a value corresponding to the S3 state to the sleep state resister (e.g., ACPI SLP_TYP). Accordingly, the example OS118handles the power button event as an S3 event (e.g., by performing the steps for the S3 protocol), when the event is actually a pseudo-S3 event corresponding to a warm reset and firmware updates (e.g., the OS118is unaware of the warm reset and/or that the firmware is being updated). In some examples, the OS118may be aware of the pseudo S3 event and may flag the pseudo S3 event to other components of the device. After the example OS118writes the value corresponding to the S3 state to the sleep state register, the OS118and/or firmware triggers a SMI. For example, firmware of the computing device106may be structured to trigger an SMI in response to the OS118writing to the sleep state register. The OS118may additionally prepare for the S3 sleep state by flushing processor cache or I/O cache, storing critical contents in the memory124, setting up the wake vector, etc.

The example BIOS119ofFIG.1is and/or includes firmware. The BIOS119includes the example SMI handler120to handle SMIs during runtime and the example boot BIOS112to perform handle warm resets during boots and/or reboots. The example BIOS SMI handler120is and/or includes firmware that performs tasks in response to a triggered SMI. When a SMI is triggered, the example OS118saves the current state of the processor (e.g., the processor current state) and switches to a separate operating environment for system management mode (SMM) code to run. System management mode is an operating environment that is used during a sleep state where each core of the computing device106starts executing from address space of the respective cores. The BIOS SMI hander120starts the execution of the separate operating environment. The example BIOS SMI handler120determines if the pseudo-S3 flag is set or not. If the pseudo-S3 flag is not set, the example BIOS SMI handler120performs a normal S3 protocol. If the pseudo-S3 flag is set, the example BIOS SMI handler120triggers a warm reset.

The example boot BIOS122ofFIG.1is and/or includes firmware that receives the warm reset trigger from the BIOS SMI handler120. In response to obtaining the reset trigger, the example boot BIOS122runs a normal warm reset flow. A warm reset (also referred to as a warm reboot a soft reset, or a soft reboot) includes closing current programs, including the OS118, and reinitiating a boot sequence until the OS118and all startup programs are reloaded. Because the example OS118is operating in an S3 state and memory is not cleared during a warm boot, when the OS118is reloaded, the example OS118continues operation where it left off based on a warm up vector that corresponds to the position in the stack where the OS118left off. Thus, during a warm reset, the memory contents are preserved by the platform, the processor117, and a memory controller of the computing device106. A full reboot (as referred to as a cold reboot), on the other hand, completely resets the hardware (e.g., including the memory and/or the stack), reloads the operating system, performs computer self-test routine(s) (not performed during a warm boot), and the example OS118starts operation at the beginning of the stack because memory is cleared during a full reboot. During the warm-reset flow, the example boot BIOS122ensures that the boot BIOS122uses only BIOS-reserved area of the memory124for boot purposes and does not use the memory124that is not reserved for BIOS use only (e.g., to preserve the memory used by the OS118). The allocation of the example memory124is preset and further illustrated below in conjunction withFIG.4.

Before ending the warm reset and returning control to the example OS118, the boot BIOS122ofFIG.1checks the pseudo-S3 flag to see if the warm reset is due to a pseudo-S3 event or a non-pseudo-S3 event. For example, if the ACPI116set a pseudo-S3 flag in UEFI variable in a register to a value indicative of a pseudo-S3 event, the BIO112checks the value in the register to determine if the value corresponds to the pseudo-S3 event. Additionally, the boot BIOS122checks if any memory topology has changed. A memory topology may change due to a hot plug of memory, when the interleave configuration is changed, when memory partition settings are changed, etc. When the memory topology is changed compared to a previous boot, the memory/interleave is re-initialized and the contents of the OS118in memory124may be lost during the re-initialization process. If the example boot BIOS122determines that the pseudo-S3 flag was set (e.g., based on a value in a register), and the memory topology has not changed, the boot BIOS122hands off operation to (e.g., triggers a change in control to) the OS118using on a OS specified wake vector that identifies where the OS118left off in a stack. In this manner, the example OS118can read the wake vector and continue operation where it left off when the pseudo-S3 event was initiated (e.g., returning to a normal operating state (e.g., the S0 state)), thus a firmware update is performed without entering a sleep state and/or performing a full reboot. If the example boot BIOS122determines that the pseudo-S3 flag was not set (e.g., another flag was set) or the memory topology has changed, the boot BIOS122clears the flag and a normal initialization flow is performed (e.g., a normal initialization flow corresponding to a sleep state).

The example memory124ofFIG.1is memory used to store instructions for the components of the computing device106. The memory124may be any type of suitable memory. As described above, there may be predefined sections of the memory that are dedicated to different components. The allocation of the example memory124is further described below in conjunction withFIG.4.

While an example manner of implementing the example computing device106is illustrated inFIG.1, one or more of the elements, processes and/or devices illustrated inFIG.1may be combined, divided, re-arranged, omitted, eliminated, and/or implemented in any other way. Further, the example interface108, the example GPIO pin112, the example BMC114, the example ACPI116, the example processor117, the example BIOS SMI handler120, the example boot BIOS122, and/or, more generally, the example computing device106ofFIG.1may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example interface108, the example GPIO pin112, the example BMC114, the example ACPI116, the example processor117, the example BIOS SMI handler120, the example boot BIOS122, and/or, more generally, the example computing device106ofFIG.1could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example interface108, the example GPIO pin112, the example BMC114, the example ACPI116, the example processor117, the example BIOS SMI handler120, the example boot BIOS122, and/or, more generally, the example computing device106ofFIG.1is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, example computing device106ofFIG.1may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated inFIG.1, and/or may include more than one of any or all of the illustrated elements, processes, and devices. As used herein, the phrase “in communication,” including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.

Flowcharts representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the example computing device106ofFIG.1are shown inFIGS.2A-2B. The machine readable instructions may be one or more executable programs or portion(s) of an executable program for execution by a computer processor such as the processor412shown in the example processor platform400discussed below in connection withFIG.4. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor412, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor412and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowcharts illustrated inFIGS.2A-2Bany other methods of implementing the example computing device106may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.

The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data (e.g., portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers). The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc. in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement a program such as that described herein.

In another example, the machine readable instructions may be stored in a state in which they may be read by a computer, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, the disclosed machine readable instructions and/or corresponding program(s) are intended to encompass such machine readable instructions and/or program(s) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.

The machine readable instructions described herein can be represented by any past, present, or future instruction language, scripting language, programming language, etc. For example, the machine readable instructions may be represented using any of the following languages: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc.

As mentioned above, the example process ofFIGS.2A-2Bmay be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

“Including” and “comprising” (and all forms and tenses thereof) are used herein to be open ended terms. Thus, whenever a claim employs any form of “include” or “comprise” (e.g., comprises, includes, comprising, including, having, etc.) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. As used herein, when the phrase “at least” is used as the transition term in, for example, a preamble of a claim, it is open-ended in the same manner as the term “comprising” and “including” are open ended. The term “and/or” when used, for example, in a form such as A, B, and/or C refers to any combination or subset of A, B, C such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, and (7) A with B and with C. As used herein in the context of describing structures, components, items, objects and/or things, the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects and/or things, the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.

As used herein, singular references (e.g., “a”, “an”, “first”, “second”, etc.) do not exclude a plurality. The term “a” or “an” entity, as used herein, refers to one or more of that entity. The terms “a” (or “an”), “one or more”, and “at least one” can be used interchangeably herein. Furthermore, although individually listed, a plurality of means, elements or method actions may be implemented by, e.g., a single unit or processor. Additionally, although individual features may be included in different examples or claims, these may possibly be combined, and the inclusion in different examples or claims does not imply that a combination of features is not feasible and/or advantageous.

FIGS.2A-2Billustrate an example flowchart representative of machine readable instructions200that may be executed to implement the example computing device106ofFIG.1to perform a firmware update with a warm reset using a pseudo-S3 protocol instead of a full reboot. Although the instructions200are described in conjunction with the example computing device106ofFIG.1, the instructions200may be described in conjunction with any type of computing device.

The example flowchart ofFIGS.2A and2Binclude multiple processes implemented by different components of the computing device. For example, the flowchart includes an example BMC process202implemented by the example BMC114, an example ACPI process204implemented by the example ACPI116, an example OS process206implemented by the OS118, an example BIOS SMI handler process208implemented by the BIOS SMI handler120, and an example boot bios process210implemented by the example boot BIOS122. In other examples, the operations represented inFIGS.2A and2Bmay be implemented differently than shown.

At block212, the example BMC114(FIG.1) determines if a firmware update was obtained (e.g., received from the server102via the interface108ofFIG.1). As described above, the example server102may transmit a firmware update to the computing device106to update the firmware of the computing device106for any of a number of reasons (e.g., to increase the efficiency of the computing device, to increase the security of the computing device, etc.). If the example BMC114determines that a firmware update has not been obtained (block212: NO), control returns to block210until a firmware update is received. If the example BMC114determines that a firmware update has been obtained (block212: YES), the example BMC114asserts the GPIO pin112(FIG.1) corresponding to the pseudo-S3 event (block214).

At block216, the example ACPI116(FIG.1) determines if a pseudo-S3 event is initiated. For example, the ACPI116monitors the GPIO pin112to determine when the GPIO pin112has been set to active (e.g., asserted by the BMC114). If the example ACPI116determines that a pseudo-S3 event has not been initiated (block216: NO), the computing device106performs a normal operation corresponding to the event that has been triggered (e.g., if a normal S3 event was triggered, the computing device106performs a normal S3 protocol) (block217). If the example ACPI116determines that a pseudo-S3 event has been initiated (block216: YES), the example ACPI116sets a pseudo-S3 flag to identify the pseudo-S3 event to the BIOS SMI handler120(block218). For example, the ACPI116may set a value in a register and/or set a value with a UEFI variable to represent the pseudo-S3 flag.

At block220, the example ACPI116asserts a power button event (e.g., transmit a signal to the OS118indicative of a power button event). As described above, a power button event triggers the OS118to prepare to enter into a sleep state (e.g., S3 sleep state). At block222, after the power button event is asserted, the example OS118performs the normal S3 protocol (e.g., to prepare to enter into the S3 sleep state). The normal S3 protocol includes writing a value to the sleep type register as an S3 event and triggering a SMI. As described above, although the pseudo-S3 protocol is being performed at the computing device106, the OS118operates according to a normal S3 protocol and is unaware that the pseudo-S3 event is occurring. At block224, the example BIOS SMI handler120determines if an SMI event has been triggered. If the example BIOS SMI handler120(FIG.1) determines that an SMI event has not been triggered (block224: NO), control returns to block214until the SMI has been triggered.

If the example BIOS SMI handler120determines that an SMI event has been triggered (block224: YES), the BIOS SMI handler120checks the pseudo-S3 flag to determine if the flag has been set to indicate that the SMI corresponds to a pseudo-S3 event (block226). If the BIOS SMI handler120determines that the pseudo-S3 flag has not been set to indicate a pseudo-S3 event (block226: NO), the computing device106performs a normal S3 protocol (block220). If the BIOS SMI handler120determines that the pseudo-S3 flag has been set to indicate a pseudo-S3 event (block226: YES), the example BIOS SMI handler120triggers a warm reset (block228). As described above, during a warm reset, the memory contents are preserved by the platform, the processor117, and a memory controller of the computing device106. At block230ofFIG.2B, the example boot BIOS122(FIG.1) performs a boot path (e.g., the flow or instructions executed to boot after a warm reset). In some examples, the boot path includes updating and/or utilizing data in a BIOS reserved area of memory. The BIOS reserved area is a predefined area of the memory124that is not used by the OS118. During the boot path, the boot BIOS112may check the pseudo-S3 flag to determine whether a pseudo-S3 event should occur. During the boot path (e.g., if a pseudo-S3 event should occur), the boot BIOS122updates and/or replaces its own firmware and/or the firmware of other components of the computing device106according to the firmware update.

At block236, the example boot BIOS122checks whether a system firmware boot process is to occur. In some examples, the boot BIOS122checks whether the system firmware boot process is to occur by checking the pseudo-S3 flag to determine whether the pseudo-S3 flag flow is being/has been implemented. In some examples, this step is performed at block230. If the example boot BIOS122determines that the system firmware boot process is not to be performed (block236: NO), control continues to block240, as further described below. If the example boot BIOS122determines that the system firmware boot process is to be performed (block236: YES), the boot BIOS122determines if the memory topology changed (block238). The memory topology may change when memory interleave changes, memory failure is detected, new memory is inserted, etc. If the example boot BIOS122determines that the memory topology has not changed (block238: NO), the example boot BIOS122invokes a wake vector (block244). For example, the wake vector may be a location of the memory124, where the BIOS119needs to jump to (e.g., change pointer to this location). The location is set by the OS118with S3 wake startup code. When the BIOS119jumps to the location, the OS118wake startup routine begins executing to continue operation. As described above, a wake vector informs the OS118to continue operation (e.g., return to the S0 state/wake state operation) and provides the OS118with the location in the stack where the OS118left off before the pseudo-S3 event occurred, so that the OS118can continue operation where it left off In this manner, firmware can be updated while the OS118operates according to a sleep state protocol without the computing device106entering a sleep state or performing a full reboot.

If the example boot BIOS122determines that the memory topology has changed (block238: YES), the example boot BIOS122clears any set sleep state flag(s) and/or the pseudo-S3 flag (e.g., resets any set and/or activated sleep state flags) (block240). At block242, the example boot BIOS122performs the corresponding initialization sleep state flow (e.g., boot path). For example, the boot BIOS112identifies which sleep state is being executed and performs the corresponding initialization instructions that correspond to a protocol for booting after the sleep state ends. At block246, the OS118determines if a register error has occurred. For example, the OS118expects the configuration of the OS118to be the same as it was before the pseudo-S3 event occurred because the OS118is built on an assumption of how the hardware is configured. Accordingly, if the OS118identifies a configuration change in the registers compared to what the OS118expects, it is a register error that needs to be fixed.

If the OS118determines that a register error has occurred (block246: YES), the OS118performs a recovery operation (block248). For example, if the OS118is implementing Windows, the recovery operation may include triggering a kernel soft reboot (KSR). A KSR is a windows server software defined (WSSD)-validated reboot that restarts the stack that the OS118implements. The KSR shuts down the OS118and restarts updated OS code and configuration and/or rebuilds the stack, skipping firmware power on self-test, to fix the register errors (e.g., other components of the computing device106are not reset). If the OS118is implementing another type of OS, the OS118may perform a recovery operation corresponding to the OS type to recover lost data to restore the state of the OS118. If the OS118determines that a register error has not occurred (block246: NO), the OS118performs a normal boot process (e.g., waking from the S3 state and/or returning to normal operation) and resumes operation (block250).

FIG.3illustrates memory preservation schemes for the memory124ofFIG.1corresponding to different phases of the computing device ofFIG.1. The example ofFIG.3includes an example cold boot memory configuration300, an example OS phase memory configuration302, an example warm reset memory configuration304, and an example OS reuse memory configuration306.

In a full OS context saving scenario, the boot BIOS122preserves area(s) of the memory124so that the OS118will not utilize the preserved area(s). In this manner, the preserved areas of memory can be adjusted during a firmware update without affecting the OS118, thereby allowing the OS to operate under S3 flow while a warm reset is performed. The areas may be based on the configuration of the computing device106. The preserved areas may be dynamically adjustable with a predefined size. For example, if the memory capacity of the memory124changes, the allocation of the memory can also change. As shown in the example memory configurations300,302,304,306, a section of the memory124is reserved for boot BIOS122, a section of the memory may be shared by the OS118and the boot BIOS122, and a section of the memory is not used by the boot BIOS122and can be dedicated to the OS. In this manner, the OS can save all context through a well-established S3 flow in a section of the memory124not reserved for the boot BIOS122, while the hardware and/or computing device106perform a warm reboot to update firmware. During the warm reboot, the boot BIOS122goes through the warm reset flow without destroying the memory content/map and/or critical registers corresponding to OS operation. In this manner, the OS118can be restored with a firmware update faster than a full reboot, thereby reducing the downtime associated with traditional firmware updates.

FIG.4is a block diagram of an example processor platform400structured to execute the instructions ofFIGS.2A-2Bto implement the computing device106ofFIG.1. The processor platform400can be, for example, a server, a personal computer, a workstation, a web plugin tool, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), an Internet appliance, or any other type of computing device.

The processor platform400of the illustrated example includes a processor412(e.g., which may implement the processor117ofFIG.1). The processor412of the illustrated example is hardware. For example, the processor412can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor412implements the example GPIO pin112, the example BMC114, the example ACPI, the example OS118, the example BIOS SMI handler120, and the example boot BIOS122ofFIG.1.

The processor412of the illustrated example includes a local memory413(e.g., a cache). The processor412of the illustrated example is in communication with a main memory including a volatile memory414and a non-volatile memory416via a bus418. The volatile memory414may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) and/or any other type of random access memory device. The non-volatile memory416may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory414,416is controlled by a memory controller. The example local memory412, the example volatile memory414, and/or the example non-volatile memory416may implement the example memory124ofFIG.1.

The processor platform400of the illustrated example also includes an interface circuit108. The interface circuit108may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a Bluetooth® interface, a near field communication (NFC) interface, and/or a PCI express interface.

In the illustrated example, one or more input devices422are connected to the interface circuit108. The input device(s)422permit(s) a user to enter data and/or commands into the processor412. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices424are also connected to the interface circuit108of the illustrated example. The output devices424can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touchscreen, etc.), a tactile output device, a printer and/or speaker. The interface circuit108of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip, and/or a graphics driver processor.

The interface circuit108of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network426. The communication can be via, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, etc.

The processor platform400of the illustrated example also includes one or more mass storage devices428for storing software and/or data. Examples of such mass storage devices428include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and digital versatile disk (DVD) drives.

The machine executable instructions432ofFIGS.2A-2Bmay be stored in the mass storage device428, in the volatile memory414, in the non-volatile memory416, and/or on a removable non-transitory computer readable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that example methods, apparatus and articles of manufacture have been disclosed to perform a pseudo-S3 protocol to update firmware and/or activate new firmware with a warm reset. Example methods, apparatus and articles of manufacture reduce the amount of downtime of a computing device when firmware is to be updated by performing triggering allowing the OS to perform S3 flow while the computing device performs a warm reset to update firmware. In this manner, firmware can be updated without a full reboot. Accordingly, example methods, apparatus and articles of manufacture disclosed herein are directed to one or more improvement(s) in the functioning of a computing system.

Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.

Example methods, apparatus, systems, and articles of manufacture to perform a pseudo-S3 protocol to update firmware and/or activate new firmware with a warm reset are disclosed herein. Further examples and combinations thereof include the following: Example 1 includes an apparatus comprising an advanced configuration and power interface (ACPI) to initiate a pseudo-sleep event in response to identifying a firmware update, and assert a power button event, an operating system (OS) to prepare to enter into a sleep state in response to the power button event, and a basic input/output system (BIOS) to initiate a warm reset in response to the OS preparing to enter the sleep state, the warm reset to update firmware according to the firmware update, and transmit a wake vector to the OS to continue operation.

Example 2 includes the apparatus of example 1, further including a baseboard management controller (BMC) to set a general purpose input/output (GPIO) as active when the firmware update is obtained, the ACPI to identify the firmware update based on a status of the GPIO.

Example 3 includes the apparatus of example 1, wherein the OS is to trigger an interrupt when preparing to enter into the sleep state, further including an interrupt handler to in response to the interrupt, determine that the pseudo-sleep event was initiated, and trigger the BIOS to initiate the warm reset in response to the determination.

Example 4 includes the apparatus of example 1, wherein the OS is to return to operation after obtaining the wake vector.

Example 5 includes the apparatus of example 1, further including memory including a first section dedicated to the BIOS and a second section dedicated to the OS.

Example 6 includes the apparatus of example 5, wherein the BIOS is to update the firmware using the first section of the memory and keeping the second section of the memory intact.

Example 7 includes the apparatus of example 1, wherein the BIOS is to reset a second sleep state flag when at least one of (a) a pseudo-sleep flag is not set or (b) a memory topology has changed, the pseudo-sleep flag identifying that the pseudo-sleep event was initiated.

Example 8 includes the apparatus of example 1, wherein the firmware for at least one of BMC, the ACPI, the BIOS, a processor, a manageability engine, a solid state device, or a network-on-chip.

Example 9 includes a non-transitory computer readable storage medium comprising instructions which, when executed, cause a basic input/output system (BIOS) to at least in response to (a) a pseudo-sleep event being initiated and (b) an operating system preparing for a sleep state, initiate a warm reset to update firmware according to a firmware update, and transmit a wake vector to the operating system after the firmware is updated.

Example 10 includes the non-transitory computer readable storage medium of example 9, wherein the instructions are to cause the BIOS to update the firmware using a first section of memory dedicated to the BIOS and keeping a second section of the memory intact, the second section of memory dedicated to the operating system.

Example 11 includes the non-transitory computer readable storage medium of example 9, wherein the instructions are to cause the BIOS to reset a second sleep state flag when at least one of (a) a pseudo-sleep flag is not set or (b) a memory topology has changed, the pseudo-sleep flag identifying that the pseudo-sleep event was initiated.

Example 12 includes the non-transitory computer readable storage medium of example 9, wherein the firmware for at least one of a BMC, an ACPI, the BIOS, a processor, a manageability engine, a solid state device, or a network-on-chip.

Example 13 includes the non-transitory computer readable storage medium of example 9, wherein the instructions are to cause the BIOS to determine that the pseudo-sleep event is initiated based on a flag, and determine that the operating system is preparing to enter the sleep state based on the operating system triggering an interrupt.

Example 14 includes an apparatus comprising means for, in response to (a) a pseudo-sleep event being initiated and (b) an operating system preparing to enter a sleep state, initiating a warm reset to update firmware according to a firmware update, and means for waking up the operating system with a wake vector after the firmware is updated.

Example 15 includes the apparatus of example 14, further including means for storing data, the storing means including a first section dedicated to a BIOS and a second section dedicated to the operating system.

Example 16 includes the apparatus of example 15, wherein the waking means is to update the firmware using the first section of the storing means and keeping the second section of the storing means intact.

Example 17 includes the apparatus of example 14, wherein the waking means is to reset a second sleep state flag when at least one of (a) a pseudo-sleep flag is not set or (b) a memory topology has changed, the pseudo-sleep flag identifying that the pseudo-sleep event was initiated.

Example 18 includes the apparatus of example 15, wherein the firmware for at least one of a BMC, an ACPI, a BIOS, a processor, a manageability engine, a solid state device, or a network-on-chip.

Example 19 includes the apparatus of example 14, wherein the initiating means is to determine that the pseudo-sleep event is initiated based on a flag, and determine that the operating system is preparing to enter the sleep state based on the operating system triggering an interrupt.

Example 20 includes the apparatus of example 14, wherein the sleep state is an S3 sleep state.

The following claims are hereby incorporated into this Detailed Description by this reference, with each claim standing on its own as a separate embodiment of the present disclosure.