Back to results
US 12,591,293 B2Granted
Out-of-band management for waking of individual components in low power modes in a heterogeneous computing platform
AssigneeDell Products L.P.
InventorsAdolfo S. Montero, Abeye Teshome, Alok Pant
Life of this patent
Estimating the term…
Abstract
Systems and methods for an interconnect architecture for Out-of-Band (OOB) manageability in heterogeneous computing platforms. In some embodiments, an Information Handling System (IHS) may include a heterogeneous computing platform having a plurality of devices and an OOB Microcontroller Unit (MCU) integrated into the heterogeneous computing platform, where the OOB MCU is configured to: receive a command; and transmit the command or an indication of the command to a selected one of the plurality of devices via an interconnect while a host processor is in a low-power state.
Claims20
An Information Handling System (IHS), that comprises:
- a heterogeneous computing platform comprising a plurality of devices;
- and
- an Out-of-Band (OOB) Microcontroller Unit (MCU) integrated into the heterogeneous computing platform, wherein the OOB MCU is configured to:
- in response to a trigger signal from within the IHS, wake from an OOB MCU low-power state while every IHS host processor is in a host processor low-power state;
- upon wake from the OOB MCU low-power state, receive an OOB command via a network interface while every IHS host processor remains in their host processor low-power state;
- determine, based, at least in part, on an OOB packet within which the OOB command was received, while every IHS host processor remains in their host processor low-power state, whether the OOB packet comprises an opaque payload decodable only by Original Equipment Manufacturer (OEM) firmware with an OEM key;
- in response to a determination that the OOB packet has an opaque payload, determine, while every IHS host processor remains in their host processor low-power state, whether the OOB packet is directed to the OOB MCU, based, at least in part on an OOB command routing header within the OOB packet;
- in response to a determination that the OOB packet has an opaque payload directed to the OOB MCU, execute, while every IHS host processor remains in their host processor low-power state, the OOB command in an OEM OOB MCU execution environment governed by OEM firmware and isolated to execute the OOB command in a memory space separate and distinct from a baseline OOB MCU execution environment memory space configured to execute non-opaque OOB commands, wherein the OEM OOB MCU execution environment is configured to decode the opaque payload with the OEM key and execute the decoded OOB command under a Real-Time OS (RTOS) instantiated by the OOB MCU to operate as a segregated RTOS with the OEM firmware;
- and
- in response to a determination that the command is not an opaque packet, route the command for execution while every IHS host processor remains in their host processor low-power state, comprising:
- individually wake a selected one of the plurality of devices based, at least in part, on activation of one of a plurality of power domains selected based at least in part upon the OOB command routing header;
- and
- transmit the OOB command or an indication of the OOB command to the selected one of the plurality of devices via an interconnect.
10 more elements
A method, comprising:
- in response to a trigger signal from within a heterogeneous computing platform, waking an Out-of-Band (OOB) Microcontroller Unit (MCU) integrated into the heterogeneous computing platform from an OOB MCU low-power state while every host processor of the heterogeneous computing platform is in a host processor low-power state;
- upon waking from the OOB MCU low-power state, receiving, by the OOB MCU, an OOB command from a cloud server via a network while every host processor of the heterogeneous computing platform remains in their host processor low-power state;
- determining, by the OOB MCU, based, at least in part, on an OOB packet within which the OOB command was received, while every IHS host processor remains in their host processor low-power state, whether the OOB packet comprises an opaque payload decodable only by Original Equipment Manufacturer (OEM) firmware with an OEM key;
- in response to determining, by the OOB MCU, that the OOB packet has an opaque payload, determining, while every IHS host processor remains in their host processor low-power state, whether the OOB packet is directed to the OOB MCU, based, at least in part on an OOB command routing header within the OOB packet;
- in response to determining, by the OOB MCU, that the OOB packet has an opaque payload directed to the OOB MCU, executing, while every IHS host processor remains in their host processor low-power state, the OOB command in an OEM OOB MCU execution environment governed by OEM firmware and isolated to execute the OOB command in a memory space separate and distinct from a baseline OOB MCU execution environment memory space configured to execute non-opaque OOB commands, wherein the OEM OOB MCU execution environment is configured to decode the opaque payload with the OEM key and execute the decoded OOB command under a Real-Time OS (RTOS) instantiated by the OOB MCU to operate as a segregated RTOS with the OEM firmware;
- and
- in response to determining, by the OOB MCU, that the command is not an opaque packet, routing the command for execution while every IHS host processor remains in their host processor low-power state, comprising:
- identifying a selected one or more of a plurality of devices integrated into the heterogeneous computing platform, based at least in part, upon the OOB command routing header, while every host processor of the heterogeneous computing platform remains in their host processor low-power state;
- and
- transmitting the OOB command or an indication of the OOB command to the selected one or more of the plurality of devices via an interconnect.
7 more elements
An Out-of-Band (OOB) Microcontroller Unit (MCU) integrated into or coupled to a heterogeneous computing platform of an Information Handling System (IHS), wherein the OOB MCU comprises:
- a processor core distinct from any host processor of the heterogeneous computing platform;
- and
- a memory coupled to the processor core, the memory configured with program instructions stored thereon that, upon execution by the processor core, cause the OOB MCU to perform operations that comprise:
- in response to a trigger signal from within the IHS, wake from an OOB MCU low-power state while every host processor of the heterogeneous computing platform is in a host processor low-power state;
- upon wake from the OOB MCU low-power state, receive an OOB command via a network interface while every host processor of the heterogeneous computing platform remains in their host processor low-power state;
- determine, based, at least in part, on an OOB packet within which the OOB command was received, while every IHS host processor remains in their host processor low-power state, whether the OOB packet comprises an opaque payload decodable only by Original Equipment Manufacturer (OEM) firmware with an OEM key;
- in response to a determination that the OOB packet has an opaque payload, determine, while every IHS host processor remains in their host processor low-power state, whether the OOB packet is directed to the OOB MCU, based, at least in part, on an OOB command routing header within the OOB packet;
- in response to a determination that the OOB packet has an opaque payload directed to the OOB MCU, execute, while every IHS host processor remains in their host processor low-power state, the OOB command in an OEM OOB MCU execution environment governed by OEM firmware and isolated to execute the OOB command in a memory space separate and distinct from a baseline OOB MCU execution environment memory space configured to execute non-opaque OOB commands, wherein the OEM OOB MCU execution environment is configured to decode the opaque payload with the OEM key and execute the decoded OOB command under a Real-Time OS (RTOS) instantiated by the OOB MCU to operate as a segregated RTOS with the OEM firmware;
- in response to a determination that the command is not an opaque packet, route the command for execution while every IHS host processor remains in their host processor low-power state, comprising:
- determine, based, at least in part, on the OOB command routing header, whether the OOB packet is directed to a Basic Input/Output System (BIOS);
- in response to a determination that the OOB packet is directed to the BIOS, determine, based, at least in part, on a BIOS status flag set by the BIOS, whether the BIOS is in execution, and in response to a determination, based on the BIOS status flag, that the BIOS is not in execution, store the OOB packet as a queued OOB packet for later delivery to the BIOS upon receipt of an indication via the BIOS status flag that the BIOS is in execution;
- and
- in response to a determination that the OOB packet is not directed to the BIOS:
- identify a selected one or more of a plurality of devices integrated into the heterogeneous computing platform, based, at least in part, upon the OOB command routing header and a look-up table that associates:
- (i) commands or types of commands;
- with (ii) corresponding ones of the plurality of devices or types of devices;
- individually wake the selected one or more of the plurality of devices based, at least in part, on activation of one or more of a plurality of power domains selected based at least in part upon the OOB command routing header;
- and
- transmit the OOB command or an indication of the OOB command to the selected one or more of the plurality of devices via an interconnect while every host processor of the heterogeneous computing platform remains in their host processor low-power state;
- and
- in response to receipt of an indication via the BIOS status flag set by the BIOS that the BIOS is in execution, deliver the queued OOB packet to the BIOS.
18 more elements
Dependencies are inferred from the claim text.