Patent Description:
It is therefore the object of the present invention to provide an improved method implemented, by a baseboard management controller, for monitoring operation of the devices, as well as a corresponding baseboard management controller.

This object is solved by the subject matter of independent claims <NUM> and <NUM>.

Methods, systems, apparatuses, and computer-readable storage mediums described herein are configured to dynamically configure a baseboard management controller to monitor a state of a computing device (e.g., a server). For example, a configuration schema may be provided to the baseboard management controller. The configuration schema specifies each of the devices of the computing device that is to be monitored by the baseboard management controller. The configuration schema also specifies additional configuration details with respect to each of the devices. Based on the configuration information included in the configuration schema, the baseboard management controller performs a discovery sequence with respect to each of the devices to verify that such devices are communicatively coupled to the baseboard management controller. If the discovery sequence is successful, the baseboard management controller begins monitoring the devices. However, if the discovery sequence is unsuccessful, the baseboard management controller issues an error, thereby enabling the proper personnel to remediate the issue (e.g., updating the configuration schema).

Further features and advantages, as well as the structure and operation of various example embodiments, are described in detail below with reference to the accompanying drawings. It is noted that the example implementations are not limited to the specific embodiments described herein. Such example embodiments are presented herein for illustrative purposes only. Additional implementations will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate example embodiments of the present application and, together with the description, further serve to explain the principles of the example embodiments and to enable a person skilled in the pertinent art to make and use the example embodiments.

The features and advantages of the implementations described herein will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout.

The present specification and accompanying drawings disclose numerous example implementations. References in the specification to "one implementation," "an implementation," "an example embodiment," "example implementation," or the like, indicate that the implementation described may include a particular feature, structure, or characteristic, but every implementation may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same implementation. Further, when a particular feature, structure, or characteristic is described in connection with an implementation, it is submitted that it is within the knowledge of persons skilled in the relevant art(s) to implement such feature, structure, or characteristic in connection with other implementations whether or not explicitly described.

In the discussion, unless otherwise stated, adjectives such as "substantially" and "about" modifying a condition or relationship characteristic of a feature or features of an implementation of the disclosure, should be understood to mean that the condition or characteristic is defined to within tolerances that are acceptable for operation of the implementation for an application for which it is intended.

Numerous example embodiments are described as follows. Implementations are described throughout this document, and any type of implementation may be included under any section/subsection. Furthermore, implementations disclosed in any section/subsection may be combined with any other implementations described in the same section/subsection and/or a different section/subsection in any manner.

Embodiments described herein dynamically configure a baseboard management controller to monitor a state of a computing device (e.g., a server). For example, a configuration schema may be provided to the baseboard management controller. The configuration schema specifies each of the devices of the computing device that is to be monitored by the baseboard management controller. The configuration schema also specifies additional configuration details with respect to each of the devices. Based on the configuration information included in the configuration schema, the baseboard management controller performs a discovery sequence with respect to each of the devices to verify that such devices are communicatively coupled to the baseboard management controller. If the discovery sequence is successful, the baseboard management controller begins monitoring the devices. However, if the discovery sequence is unsuccessful, the baseboard management controller issues an error, thereby enabling the proper personnel to remediate the issue (e.g., updating the configuration schema).

The foregoing provides several advantages. For instance, the firmware of the baseboard management controller no longer needs to be statically hardcoded with values specifying the devices coupled thereto and the properties thereof. Instead, the baseboard management controller simply needs to process the configuration schema and dynamically configure the baseboard management controller via the discovery sequence. In the event that a device of the computing device is changed or removed, an updated configuration schema reflecting the changed configuration is provided to the baseboard management controller, which then performs the discovery sequence in accordance with the updated configuration schema. In prior solutions, such a change in configuration would require a firmware update, where the firmware would be rewritten with new hardcoded values to reflect the new device configuration. Such firmware updates require a lengthy validation cycle to ensure that the firmware does not cause the baseboard management controller to malfunction. The foregoing techniques virtually remove this validation cycle, as the firmware is not manually rewritten, but instead, is updated via the configuration schema-driven discovery sequence.

<FIG> shows a block diagram of an example system <NUM> for configuring a baseboard management controller <NUM> to monitor a plurality of devices <NUM> in accordance with an example embodiment. As shown in <FIG>, system <NUM> includes baseboard management controller <NUM> and plurality of devices <NUM>. Baseboard management controller <NUM> may be configured to monitor the state of a computer, server, and/or other hardware device in which baseboard management controller <NUM> is included. Baseboard management controller <NUM> may be included on a motherboard, baseboard, or main circuit board of the device to be monitored. Baseboard management controller <NUM> may be implemented as a system-on-a-chip (SoC), an application-specific integrated circuit (ASIC), a microcontroller, etc..

Baseboard management controller <NUM> may be implemented in a system that implements an IPMI (Intelligent Platform Management Interface) computer interface specification, or other system, to provide management and monitoring capabilities independent of a host system's CPU (central processing unit), firmware (e.g., BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface)), and operating system). For instance, baseboard management controller <NUM> may be a microcontroller or other processor type embedded on the motherboard of a computer, and may be configured to manage the interface between system management software and platform hardware. For example, as further described elsewhere herein, sensors built into the computer may report to baseboard management controller <NUM> on parameters such as temperature, cooling fan speeds, power status, operating system (OS) status, etc. Baseboard management controller <NUM> monitors the sensors and can send alerts to a system administrator via a network connection if any parameters do not stay within pre-set limits, indicating a potential failure of the computer. The administrator may be enabled to remotely communicate with baseboard management controller <NUM> to take corrective actions, such as resetting or power cycling the computer to get a hung OS running again. These abilities can save on the total cost of ownership of a computer.

To monitor the state of a computing device, baseboard management controller <NUM> may monitor a plurality of devices (e.g., devices <NUM>) of the computing device. For instance, a given computing device (e.g., a server) may include any number of devices that may be coupled to the main circuit board (or motherboard) on which baseboard management controller <NUM> is attached and/or on a different circuit board coupled to the main circuit board (e.g., via one or more expansion slots, cables, connectors, etc.). Examples of devices <NUM> include, but are not limited to, power supply units, fans, temperature sensors, humidity sensors, memories (e.g., random access memories (RAM), such, static RAMs (SRAMs), dynamic RAMs (DRAMs), etc.), storage devices (e.g., hard disk drives, solid state drives, etc.), central processing units (CPUs), hardware accelerators, video cards, sound cards, storage controllers, network controllers, other peripheral devices (such as, but not limited to. PCI-Express-based peripheral devices), etc. Given that a particular computing device, such as a server, may comprise racks and racks of hardware devices, the total number of devices <NUM> to be monitored can be anywhere from the hundreds to even the thousands.

To configure baseboard management controller <NUM> to monitor such devices <NUM>, baseboard management controller <NUM> may be provided a configuration schema <NUM>. Configuration schema <NUM> specify the devices (e.g., devices <NUM>) that are to be included in the computing device being monitored by and coupled to baseboard management controller <NUM>. Configuration schema <NUM> may comprise information (e.g., metadata) that specifies the configuration of the computing device being monitored. For example, configuration schema <NUM> may identify each of devices <NUM>, and may specify a logical address at which each of devices <NUM> is located, a physical address at which each of devices <NUM> is located (e.g., expansion slot <NUM> of rack <NUM>), a logical address of one or more configuration registers associated with each of devices <NUM>, an expected value for each of such configuration register(s), a communication protocol utilized by each of devices <NUM>, etc. Configuration schema <NUM> may comprise one or more user-generated files and/or one or more automatically-generated files (e.g., via a graphical user interface in which a user, such as an administrator, specifies values for the above-described information and that automatically generates configuration schema <NUM> based on the specified values). In accordance with an embodiment, configuration schema <NUM> may be formatted in accordance with a JavaScript Object Notation (JSON) format, an Extensible Markup Language (XML) format, or any other format suitable for organizing and/or transmitting data.

Using configuration schema <NUM>, baseboard management controller <NUM> may perform an automated discovery sequence to discover each of devices <NUM> and verify that each of devices <NUM> are included in the computing device being monitored. Upon verifying that each of devices <NUM> are included in the computing device, baseboard management controller <NUM> may accept configuration schema <NUM> as the configuration for the computing device and monitor devices <NUM> (e.g., the fan speeds, temperature, humidity, power consumption, etc., of devices <NUM>). Upon successful verification, configuration schema <NUM> may also be utilized on any other similarly configured computing device. Upon determining that at least one of devices <NUM> is not included in the computing device or is exhibiting unintended behavior, baseboard management controller <NUM> may provide an error signal to notify an administrator of the issue. The administrator can then take the necessary corrective action to remediate the issue. Additional details regarding baseboard management controller <NUM> is described below with reference to <FIG>.

<FIG> shows a block diagram of an example system <NUM> for configuring a baseboard management controller <NUM> to monitor a plurality of devices 206A-206N in accordance with another example embodiment. As shown in <FIG>, system <NUM> includes baseboard management controller <NUM> and plurality of devices 206A-206N, where N is any positive integer. Baseboard management controller <NUM> is an example of baseboard management controller <NUM>, and devices 206A-206N are examples of devices <NUM>, as described above with reference to <FIG>. Baseboard management controller <NUM> comprises a processor <NUM>, a memory <NUM>, and one or more communication interfaces <NUM>. As further shown in <FIG>, memory <NUM> may store an operating system <NUM>, an application layer <NUM>, a configuration process <NUM>, a sensor data record (SDR) <NUM>, one or more fan algorithms <NUM>, one or more power policies <NUM>, a diagnostics process <NUM>, a device monitor <NUM>, and a system event log (SEL) <NUM>. Examples of memory <NUM> include, but are not limited to, a non-volatile memory device (e.g., flash memory, ferroelectric RAM, an electrically erasable programmable read-only memory (EEPROM), and/or the like), a volatile memory device (e.g., DRAMs, SRAMs, and/or the like), etc..

In some embodiments, processor <NUM> may be configured to execute multiple computing threads, computing programs, and/or applications stored in memory <NUM> (e.g., operating system <NUM>, application layer <NUM>, fan algorithm(s) <NUM>, power policies <NUM>, diagnostics process <NUM>, device monitor <NUM>, configuration process <NUM>, etc. In some embodiments, processor <NUM> may each comprise one or more processor core(s).

Operating system <NUM> may be configured to manage one or more hardware components (e.g., processor <NUM>, memory <NUM>, communication interface(s) <NUM>, etc.) and software executing on baseboard management controller <NUM> (e.g., application layer <NUM>, fan algorithm(s) <NUM>, power policies <NUM>, diagnostics process <NUM>, device monitor <NUM>, configuration process <NUM>, etc.).

Application layer <NUM> may be an abstraction layer that interfaces operating system <NUM> and/or devices 206A-206N with configuration process <NUM>, diagnostics process <NUM>, and/or device monitor <NUM> via communication interface(s) <NUM>. Communication interface(s) <NUM> may comprise interface(s) suitable for receiving configuration schema <NUM>. Examples of such interfaces include, but are not limited to, a local area network (LAN) interface, a low pin count (LPC) interface, and an I2C (Inter-Integrated Circuit) interface. An I2C interface interfaces with an I2C serial computer bus used for attaching lower-speed peripheral integrated circuits (ICs) to processors and microcontrollers in short-distance, intra-board communication. An I2C bus is synchronous, multi-master, multi-slave, packet switched, and single-ended, as is well-known to persons skilled in the relevant art(s). Communication interface(s) <NUM> may also comprise interface(s) suitable for communicating with devices 206A-206N. Examples of such interfaces include, but are not limited to, a system management bus (SMBus) interface, a power management bus (PMBus) interface, an I2C bus interface, a management component transport protocol (MCTP)-based bus interface, and/or the like.

Configuration schema <NUM> may be an example of configuration schema <NUM>, as described above with reference to <FIG>. Configuration schema <NUM> may specify the devices (e.g., devices 206A-206N) that are to be included in the computing device being monitored by and coupled to baseboard management controller <NUM>. Configuration schema <NUM> may comprise information (e.g., metadata) that specifies the configuration of the computing device being monitored. For example, configuration schema <NUM> may identify each of devices <NUM> (e.g., via an identifier that identifies each of devices <NUM>), specifies a logical address at which each of devices 206A-206N is located, a physical address at which each of devices 206A-206N is located (e.g., expansion slot <NUM> of rack <NUM>), a logical address of one or more configuration registers associated with each of devices 206A-206N, an expected value for each of such configuration register(s), a communication protocol utilized by each of devices 206A-206N, etc. In accordance with an embodiment, configuration schema <NUM> may be formatted in accordance with a JavaScript Object Notation format, an Extensible Markup Language (XML) format, or any other format suitable for organizing and/or transmitting data.

Configuration schema <NUM> may be provided to baseboard management controller <NUM> via communication interface(s) <NUM>. For example, a computing device (e.g., a computer, laptop, tablet, etc.) storing configuration schema <NUM> may be coupled to baseboard management controller <NUM> via communication interface(s) <NUM>. The computing device may transfer configuration schema <NUM> to baseboard management controller <NUM> via communication interface(s) <NUM>. Configuration schema <NUM> may be stored in memory <NUM> of baseboard management controller <NUM> (shown as configuration schema <NUM>').

After storing configuration schema <NUM>', application layer <NUM> may initiate configuration process <NUM>. Configuration process <NUM> may be configured to validate configuration schema <NUM>'. For instance, configuration schema <NUM>' may be digitally signed. The digital signature may be based on a hash computed for configuration schema <NUM>' that is encrypted using a private key of the entity that generated configuration schema <NUM>. A public key associated with the entity may be provided to baseboard management controller <NUM> along with configuration schema <NUM>. Configuration process <NUM> may be configured to decrypt the hash using the public key and also computes its own hash for configuration schema <NUM>'. If that hash value matches the decrypted hash value, configuration process <NUM> may determine that configuration schema <NUM>' is valid. If the hash values do not match, configuration process <NUM> may cause an error signal to be issued and/or an error to be logged in system event log <NUM>, thereby informing a user of an invalid configuration schema <NUM>'. The foregoing process advantageously prevents unauthorized configuration schemas from tampering with the configuration of baseboard management controller <NUM>.

Configuration process <NUM> may also be configured to determine whether configuration schema <NUM>' is formatted correctly. For instance, configuration process <NUM> may be configured to determine whether configuration process <NUM> is formatted in accordance with a predetermined formatting scheme (e.g., JSON, XML, etc.). For example, configuration process <NUM> may determine whether configuration schema <NUM>' utilizes the proper syntax and/or structure (e.g., ensuring that a JSON object is encapsulated using an opening brace '{' and a closing brace '}', ensuring that key value pairs are separated by a comma ',', etc.). If configuration process <NUM> determines that configuration schema <NUM>' is not formatted correctly, configuration process <NUM> may cause an error signal to be issued and/or an error to be logged in system event log <NUM>, thereby informing a user of an invalid configuration schema <NUM>'.

After validating configuration schema <NUM>' and determining that it is formatted correctly, configuration process <NUM> may be configured to read configuration schema <NUM>' and determine each of the devices (e.g., devices 206A-206N) that are to be monitored by baseboard management controller <NUM> and perform a discovery sequence to verify that such devices are coupled to baseboard management controller <NUM>. For example, configuration process <NUM> may cause processor <NUM> to issue a request (or "ping") to each of devices 206A-206N specified by configuration schema <NUM>' and to wait for a response from each of devices 206A-206N via communication interface(s) <NUM>. The request may be transmitted in accordance with the communication protocol utilized by the device, as specified by configuration schema <NUM>'. If no response is received, baseboard management controller <NUM> may provide an error signal and/or log an event in system error log <NUM> to notify an administrator of the issue. The administrator can then take the necessary corrective action to remediate the issue. For instance, configuration schema <NUM>' may incorrectly identify a particular device of device 206A-206N. Accordingly, the administrator may update configuration schema <NUM> and provide the updated schema to baseboard management controller <NUM>.

Upon receiving a response from a particular device, configuration process <NUM> reads configuration registers associated with that device, as specified by configuration schema <NUM>'. The address at which the configuration registers are located are also specified by configuration schema <NUM>'. Accordingly, configuration process <NUM> causes processor <NUM> to issue a read request to such addresses. Configuration schema <NUM>' may also specify expected values for such registers. Configuration process <NUM> may compare the content read from the configuration registers to the expected values. If the content matches the values, configuration process <NUM> may determine that the associated device is coupled to baseboard management controller <NUM>. If each of devices 206A-206N provides a response and the contents for the configuration registers of each device matches their respective expected values, baseboard management controller <NUM> may accept configuration schema <NUM>' as the configuration for the computing device. Upon successful verification, configuration schema <NUM>' may also be utilized on any other similarly configured computing device. Moreover, entities external to baseboard management controller <NUM> may query baseboard management controller <NUM> (e.g., via communication interface(s) <NUM>) to obtain configuration schema <NUM>'. Such entities include, but are not limited to a rack manager, a chassis manager, a data center manager, etc. Such entities may use configuration schema <NUM>' to determine the computing device's configuration.

If the content does not match, configuration process <NUM> may determine that the device is not coupled to baseboard management controller <NUM> and/or the device is defective. In this case, baseboard management controller <NUM> may provide an error signal to notify an administrator of the issue. The administrator can then take the necessary corrective action to remediate the issue. For instance, the administrator may update configuration schema <NUM> with the correct configuration and provide the updated schema to baseboard management controller <NUM>.

The content read from a particular device's configuration registers may correspond to properties of the device. For instance, the content may specify an identifier of the device (e.g., device name, model number, serial number, etc.), one or more parameters of the device (e.g., fan speed limits, temperature and/or humidity limits, power characteristics and/or limits, default initialization settings, etc.), etc. Accordingly, such properties may be utilized to uniquely identify each of devices 206A-206N, and therefore, be utilized to verify that such devices 206A-206N are coupled to baseboard management controller <NUM>. Configuration registers may also comprise error registers that store values indicative of whether an associated device has incurred an error, fault, and/or failure. Configuration schema <NUM>' may also specify the addresses of such error registers.

Configuration process <NUM> may utilize such properties to populate sensor data record <NUM>. Configuration process <NUM> also populates sensor data record <NUM> with information included in configuration schema <NUM>' (e.g., the logical address at which each device 206A-206N is located, a physical address at which each of devices 206A-206N is located, logical addresses of the configuration registers associated with each device 206A-206N, a communication protocol utilized by each device 206A-206N, etc.). Accordingly, sensor data record <NUM> comprises a complete listing of device 206A-206N that are to be monitored by baseboard management controller <NUM>, along with the properties associated therewith.

Configuration schema <NUM>' may also specifies one or more fan algorithms and/or power management policies that are specific to the configuration of the computing device being monitored by baseboard management controller <NUM>. The fan algorithms and/or power policies may specify how certain devices of devices 206A-206N (e.g., fans, power supplies) are to be controlled based on certain factors, such as measured temperature, humidity, and/or power readings. Upon successful verification of devices 206A-206N, configuration process <NUM> may store such fan algorithms and/or power policies in memory <NUM> (shown as fan algorithm(s) <NUM> and power policies <NUM>, respectively).

Device monitor <NUM> may be configured to monitor devices 206A-206B in accordance with the information stored in sensor data record <NUM>. For instance, device monitor <NUM> may be configured to read certain configuration registers of devices 206A-206N specified by sensor data record <NUM> that store operational parameters of such devices 206A-206N (e.g., the current temperature, the current humidity, etc.) and/or values indicative of whether devices 206A-206N have incurred an error, fault, and/or failure (i.e., the error registers). If the operational parameters are not within a predetermined threshold (e.g., the temperature is too high, is too much power being consumed, etc.) and/or the error registers indicate that an error, fault, and/or failure has occurred, device monitor <NUM> may log an event in system event log <NUM>. The event may also specify the physical location at which the malfunctioning device is located. In this way, a service technician may easily locate and service the device.

Device monitor <NUM> may also cause baseboard management controller <NUM> to perform a remedial action. For instance, device monitor <NUM> may provide a command to diagnostics process <NUM>. Diagnostics process <NUM> may issue a command to one or more of device 206A-206N to remediate the issue exhibited by the computing device being monitored. For instance, diagnostics process <NUM> may cause processor <NUM> to issue a command to a fan to change its fan speed (e.g., in accordance with fan algorithm(s) <NUM>), may cause processor <NUM> to issue a command to device of devices 206A-206N to control its power consumption scheme (e.g., in accordance with power policies <NUM>), may cause processor <NUM> to issue a command to restart a device of devices 206A-206N, etc..

Accordingly, in example embodiments, a baseboard management controller may be configured to monitor a plurality of devices in various ways. For instance, <FIG> shows a flowchart <NUM> of a method for configuring a baseboard management controller to monitor a plurality of devices in accordance with an example embodiment. In an embodiment, flowchart <NUM> may be implemented by a system <NUM> shown in <FIG>, although the method is not limited to that implementation. <FIG> shows a block diagram of system <NUM> for configuring a baseboard management controller <NUM> mounted to a motherboard <NUM> in accordance with an example embodiment. As shown in <FIG>, system <NUM> comprises baseboard management controller <NUM> and a plurality of devices <NUM>. Baseboard management controller <NUM> and devices <NUM> are examples of baseboard management controller <NUM> and devices 206A-206N, as described above with reference to <FIG>. Baseboard management controller <NUM> is mounted on motherboard <NUM>. As further shown in <FIG>, baseboard management controller <NUM> comprises a configuration process <NUM>, an application layer <NUM>, a device monitor <NUM>, and one or more communication interfaces <NUM>, which are examples of configuration process <NUM>, application layer <NUM>, device monitor <NUM>, and communication interface(s) <NUM>, as respectively described above with reference to <FIG>. Configuration process <NUM> may include a schema interface <NUM>, a schema validator <NUM>, and a device discoverer <NUM>. Configuration process <NUM>, device monitor <NUM> and application layer <NUM> may be stored in a memory of baseboard management controller (e.g., memory <NUM>, as shown in <FIG>). Baseboard management controller <NUM> may be communicatively coupled to devices <NUM> via a communication bus <NUM>. Examples of communication bus <NUM> includes, but are not limited to, an SMBus, a PMBus, an I2C bus, an MCTP-based bus, and/or the like. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, a configuration schema is received that specifies a plurality of devices associated with the motherboard and coupled to the baseboard management controller by a communication bus. For example, with reference to <FIG>, baseboard management controller <NUM> receives a configuration schema <NUM> via communication interface(s) <NUM> (e.g., from an administrator of system <NUM> using a computer, from a computer according to a management process, etc.) and stores configuration schema <NUM> in a memory (e.g., memory <NUM>, as shown in <FIG>) of baseboard management controller <NUM>. Configuration schema <NUM> is received by schema interface <NUM> of configuration process <NUM> via application layer <NUM>. Configuration schema <NUM> specifies devices <NUM> that are associated with motherboard <NUM> and coupled to baseboard management controller <NUM> by communication bus <NUM>. Configuration schema <NUM> is an example configuration schema <NUM>, as described above with reference to <FIG>. Devices <NUM> may be attached to motherboard <NUM> and/or may be attached to another circuit board communicatively coupled to motherboard <NUM>.

In accordance with one or more embodiments, the plurality of devices comprises at least one of a temperature sensor, a humidity sensor, a fan, a power supply unit, a memory device, a central processor unit, or a hardware accelerator.

In accordance with one or more embodiments, the configuration schema is in accordance with a JSON format. For example, with reference to <FIG>, configuration schema <NUM> is in accordance with a JSON format.

In accordance with one or more embodiments, the baseboard management controller is configured to determine that a digital signature associated with the configuration schema is valid and determine whether the configuration schema is formatted in accordance with a predetermined formatting scheme. For example, with reference to <FIG>, schema interface <NUM> may provide configuration schema <NUM> to schema validator <NUM>. Schema validator <NUM> may determine that a digital signature associated with configuration schema <NUM> is valid and determining whether configuration schema <NUM> is formatted in accordance with a predetermined formatting scheme (e.g., a JSON format). In the event that schema validator <NUM> determines that the digital signature is invalid and/or configuration schema <NUM> is not formatted properly, schema validator <NUM> may log an error (e.g., in system event log <NUM>, as shown in <FIG>).

In step <NUM>, for each of device of the plurality of devices, a discovery sequence is performed over the communication bus based on the configuration schema to verify that the device is communicatively coupled to the baseboard management controller and to determine a property of the device. For example, with reference to <FIG>, responsive to schema validator <NUM> determining that the digital signature is valid and configuration schema <NUM> being formatted properly, schema validator <NUM> may provide configuration schema <NUM> to device discoverer <NUM>. Device discoverer <NUM> may perform a discovery sequence over communication bus <NUM> based on configuration schema <NUM> to verify that each of devices <NUM> are coupled to baseboard management controller <NUM> and to determine a property of the device. Additional details regarding the discovery sequence is described below with reference to <FIG> and <FIG>.

In step <NUM>, responsive to verifying that the devices are communicatively coupled to the baseboard management controller, operation of the devices is monitored. For example, with reference to <FIG>, device monitor <NUM> monitors operation of devices <NUM> responsive to device discoverer <NUM> verifying that devices <NUM> are communicatively coupled to baseboard management controller <NUM>.

In accordance with one or more embodiments, the configuration schema further specifies at least one of, for each device of the plurality of devices, an address at which the device is located, an address at which one or more configuration registers of the device is located, an expected value for each of the one or more configuration registers, a communication protocol utilized by the device, or a physical location at which the device is located.

<FIG> shows a flowchart <NUM> of a method for performing a discovery sequence in accordance with an example embodiment. In an embodiment, flowchart <NUM> may be implemented by a system <NUM> shown in <FIG>, although the method is not limited to that implementation. <FIG> shows a block diagram of system <NUM> for performing a discovery sequence in accordance with an example embodiment. As shown in <FIG>, system <NUM> comprises baseboard management controller <NUM> and a device <NUM>. Baseboard management controller <NUM> and device <NUM> are examples of baseboard management controller <NUM> and devices <NUM>, as respectively described above with reference to <FIG>. Baseboard management controller <NUM> is mounted on a motherboard <NUM>. Device <NUM> may be attached to motherboard <NUM> and/or may be attached to another circuit board communicatively coupled to motherboard <NUM>. As further shown in <FIG>, baseboard management controller <NUM> comprises a configuration process <NUM>, an application layer <NUM>, and one or more communication interfaces <NUM>, which are examples of configuration process <NUM>, application layer <NUM>, and communication interface(s) <NUM>, as respectively described above with reference to <FIG>, and a processor <NUM>, a system event log <NUM> and a sensor data record <NUM>, which are examples of processor <NUM>, system event logic <NUM> and sensor data record <NUM>, as respectively described above with reference to <FIG>. Configuration process <NUM> may include a device discoverer <NUM>, which is an example of device discoverer <NUM>, as described above with reference to <FIG>. Configuration process <NUM>, application layer <NUM>, system event log <NUM>, and sensor data record <NUM> may be stored in a memory of baseboard management controller <NUM> (e.g., memory <NUM>, as shown in <FIG>). As further shown in <FIG>, configuration schema <NUM> has been provided to baseboard management controller <NUM> and stored thereon in the memory of baseboard management controller <NUM>. Baseboard management controller <NUM> may be communicatively coupled to a device <NUM> via a communication bus <NUM>. Device <NUM> may include one or more configuration registers <NUM>. Communication bus <NUM> is an example of communication bus <NUM>, as described above with reference to <FIG>. It is noted that baseboard management controller <NUM> may perform a discovery sequence with respect to any number of devices. However, <FIG> depicts a discovery sequence with respect to a single device (i.e., device <NUM>) for the sake of brevity. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, a request is transmitted to the device. For example, with reference to <FIG>, device discoverer <NUM> may read configuration schema <NUM> to determine an address at which device <NUM> is located and issues a request <NUM> (e.g., a "ping") to device <NUM>. Request <NUM> is provided to application layer <NUM>, which causes processor <NUM> to issue request <NUM> via communication interface(s) <NUM>. Communication interface(s) <NUM> provides request <NUM> to device <NUM> via communication bus <NUM>.

In step <NUM>, a response is received from the device. For instance, with reference to <FIG>, device <NUM> provides a response <NUM> to communication interface(s) <NUM> via communication bus <NUM>. Communication interface(s) <NUM> provide response <NUM> to processor <NUM>, which provides response <NUM> to device discoverer <NUM> via application layer <NUM>. It is noted that if response <NUM> is not received (e.g., after a predetermined period of time), device discoverer <NUM> may log an error in system error log <NUM>.

In step <NUM>, responsive to receiving the response from the device, contents of configuration register(s) associated with the device are read. For example, with reference to <FIG>, device discoverer <NUM> may read configuration schema <NUM> and determine address(es) for configuration register(s) <NUM> of device <NUM>. Device discoverer <NUM> may issue a read request <NUM> to configuration register(s) <NUM> using the address(es). Read request <NUM> may be provided to application layer <NUM>, which causes processor <NUM> to issue read request <NUM> via communication interface(s) <NUM>. Communication interface(s) <NUM> may provide read request <NUM> via communication bus <NUM>. In response, device <NUM> may issue a response <NUM> including the contents of configuration register(s) <NUM>. Response <NUM> may be provided to communication interface(s) <NUM> via communication bus <NUM>. Communication interface(s) <NUM> may provide response <NUM> to processor <NUM>, which provides response <NUM> to device discoverer <NUM> via application layer <NUM>.

In step <NUM>, a determination is made as to whether the contents of each of the configuration register(s) match the expected value specified for each of the configuration register(s) by the configuration schema. For example, with reference to <FIG>, device discoverer <NUM> determines whether the contents of configuration register(s) <NUM> received via response <NUM> match the expected value specified for each of configuration register(s) <NUM>, as specified by configuration schema <NUM>. If a determination is made that the contents do not match the expected values, flow continues to step <NUM>. Otherwise, flow continues to step <NUM>.

In accordance with one or more embodiments, the contents of the configuration register(s) of the device specify the property of the device. For example, with reference with <FIG>, the contents of configuration register(s) <NUM> of device <NUM> specify the property of device <NUM>.

In step <NUM>, an error signal is provided indication that the contents do not match. For example, with reference to <FIG>, device discoverer <NUM> may issue an error signal <NUM>, which is logged in system error log <NUM>.

In step <NUM>, a determination is made that the device is coupled to the baseboard management controller. For example, with reference to <FIG>, device discoverer <NUM> determines that device <NUM> is coupled to baseboard management controller <NUM>.

In accordance with one or more embodiments, the contents of the configuration register(s) (shown as contents <NUM>) are stored in a sensor data record of the baseboard management controller. For example, with reference to <FIG>, the contents of configuration register(s) <NUM> received via response <NUM> are stored in sensor data record <NUM>.

<FIG> depicts a block diagram of a processor (or controller) device <NUM> in which baseboard management controller <NUM>, baseboard management controller <NUM>, baseboard management controller <NUM>, baseboard management controller <NUM> (and/or the components described therein (e.g., processor <NUM>, communication interface(s) <NUM>, memory <NUM>, operating system <NUM>, application layer <NUM>, device monitor <NUM>, power policies <NUM>, sensor data record <NUM>, fan algorithm(s) <NUM>, diagnostics process <NUM>, system even log <NUM>, and/or configuration process <NUM>, as shown in <FIG>, communication interface <NUM>, application layer <NUM>, configuration process <NUM>, device discoverer <NUM>, schema validator <NUM>, schema interface <NUM>, and/or device monitor <NUM>, , as shown in <FIG>, communication interface(s) <NUM>, application layer <NUM>, sensor data record <NUM>, system event log <NUM>, configuration process <NUM>, device discoverer and/or processor <NUM>, as shown in <FIG>), and/or any of the steps of any of the flowcharts of <FIG> and <FIG> may be implemented.

Processor <NUM> may include central processing unit (CPU) <NUM> (which may be an example of processor <NUM> and/or processor <NUM>), an I/O controller <NUM>, a program memory <NUM>, and a data memory <NUM> (program memory <NUM> and/or data memory <NUM> may be examples of memory <NUM>). CPU <NUM> may be configured to perform the main computation and data processing function of processor <NUM>. I/O controller <NUM> (which may be an example of communication interface(s) <NUM>, communication interface(s) <NUM>, and/or communication interface(s) <NUM>) may be configured to control communication to external devices via one or more serial ports and/or one or more link ports. For example, I/O controller <NUM> may be configured to provide data read from data memory <NUM> to one or more external devices and/or store data received from external device(s) into data memory <NUM>. Program memory <NUM> may be configured to store program instructions used to process data. Data memory <NUM> may be configured to store the data to be processed.

Processor <NUM> further includes one or more data registers <NUM>, a multiplier <NUM>, and/or an arithmetic logic unit (ALU) <NUM>. Data register(s) <NUM> may be configured to store data for intermediate calculations, prepare data to be processed by CPU <NUM>, serve as a buffer for data transfer, hold flags for program control, etc. Multiplier <NUM> may be configured to receive data stored in data register(s) <NUM>, multiply the data, and store the result into data register(s) <NUM> and/or data memory <NUM>. ALU <NUM> may be configured to perform addition, subtraction, absolute value operations, logical operations (AND, OR, XOR, NOT, etc.), shifting operations, conversion between fixed and floating point formats, and/or the like.

CPU <NUM> further includes a program sequencer <NUM>, a program memory (PM) data address generator <NUM>, a data memory (DM) data address generator <NUM>. Program sequencer <NUM> may be configured to manage program structure and program flow by generating an address of an instruction to be fetched from program memory <NUM>. Program sequencer <NUM> may also be configured to fetch instruction(s) from instruction cache <NUM>, which may store an N number of recently-executed instructions, where N is a positive integer. PM data address generator <NUM> may be configured to supply one or more addresses to program memory <NUM>, which specify where the data is to be read from or written to in program memory <NUM>. DM data address generator <NUM> may be configured to supply address(es) to data memory <NUM>, which specify where the data is to be read from or written to in data memory <NUM>.

Techniques, including methods, described herein may be implemented by hardware (digital and/or analog) or a combination of hardware with software and/or firmware. Techniques described herein may be implemented by one or more components. Embodiments may comprise computer program products comprising logic (e.g., in the form of program code or software as well as firmware) stored on any computer useable medium, which may be integrated in or separate from other components. Such program code, when executed by one or more processors, causes a device to operate as described herein. Devices in which embodiments may be implemented may include storage, such as storage drives, memory devices, and further types of computer-readable storage media. Examples of such computer-readable storage media include, but are not limited to, a hard disk, a removable magnetic disk, a removable optical disk, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like. In greater detail, examples of such computer-readable storage media include, but are not limited to, a hard disk associated with a hard disk drive, a removable magnetic disk, a removable optical disk (e.g., CDROMs, DVDs, etc.), zip disks, tapes, magnetic storage devices, MEMS (micro-electromechanical systems) storage, nanotechnology-based storage devices, as well as other media such as flash memory cards, digital video discs, RAM devices, ROM devices, and the like. Such computer-readable storage media may, for example, store computer program logic, e.g., program modules, comprising computer executable instructions that, when executed, provide and/or maintain one or more aspects of functionality described herein with reference to the figures, as well as any and all components, steps and functions therein and/or further embodiments described herein.

By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared and other wireless media, as well as signals transmitted over wires. Embodiments are also directed to such communication media. Additional Example Embodiments not falling under the claimed scope.

A method implemented by a baseboard management controller mounted to a motherboard. The method includes: receiving a configuration schema that specifies a plurality of devices associated with the motherboard and coupled to the baseboard management controller by a communication bus; for each device of the plurality of devices, performing a discovery sequence over the communication bus based on the configuration schema to verify that the device is communicatively coupled to the baseboard management controller and to determine a property of the device; and responsive to verifying that the devices are communicatively coupled to the baseboard management controller, monitoring operation of the devices.

In one implementation of the foregoing method, said receiving comprises: determining that a digital signature associated with the configuration schema is valid; and determining whether the configuration schema is formatted in accordance with a predetermined formatting scheme.

In another implementation of the foregoing method, the configuration schema further specifies, for each device of the plurality of devices, at least one of: an address at which the device is located; an address at which one or more configuration registers of the device is located; an expected value for each of the one or more configuration registers; a communication protocol utilized by the device; or a physical location at which the device is located.

In another implementation of the foregoing method, said performing comprises: for each device of the plurality of devices: transmitting a request to the device; receiving a response from the device; responsive to receiving the response from the device, reading contents of one or more configuration registers associated with the device; determining whether the contents of each of the one or more configuration registers match the expected value specified for each of the one or more configuration registers by the configuration schema; in response to determining that the content match, determining that the device is coupled to the baseboard management controller; and in response to determining that the contents do not match, providing an error signal indicating that the contents do not match.

In another implementation of the foregoing method, the contents of the one or more configuration registers of the device specify the property of the device.

In another implementation of the foregoing method, the method further comprises: storing the contents of the one or more configuration registers in a sensor data record of the baseboard management controller.

In another implementation of the foregoing method, the configuration schema is in accordance with a JavaScript Object Notation (JSON) format.

In another implementation of the foregoing method, the plurality of devices comprises at least one of: a temperature sensor; a humidity sensor; a fan; a power supply unit; a memory device; a central processor unit; a hardware accelerator; a storage device; a storage controller; or a network controller.

A baseboard management controller is also described herein. The baseboard management controller includes: a schema interface for receiving a configuration schema that specifies a plurality of devices coupled to the baseboard management controller; a device discoverer configured to: for each device of the plurality of devices, perform a discovery sequence based on the configuration schema to verify that the device is coupled to the baseboard management controller and to determine a property of the device; and a device monitor configured to: responsive to verifying that the devices are coupled to the baseboard management controller, monitor operation of the devices.

In one implementation of the foregoing baseboard management controller, the baseboard management controller further comprises: a schema validator configured to: determine that a digital signature associated with the configuration schema is valid; and determine whether the configuration schema is formatted in accordance with a predetermined formatting scheme.

In another implementation of the foregoing baseboard management controller, the configuration schema further specifies, for each device of the plurality of devices, at least one of: an address at which the device is located; an address at which one or more configuration registers of the device is located; an expected value for each of the one or more configuration registers; a communication protocol utilized by the device; or a physical location at which the device is located.

In another implementation of the foregoing baseboard management controller, the device discoverer is further configured to: for each device of the plurality of devices: transmit a request to the device; receive a response from the device; responsive to receiving the response from the device, read contents of one or more configuration registers associated with the device; determine whether the contents of each of the one or more configuration registers match the expected value specified for each of the one or more configuration registers by the configuration schema; in response to determining that the content match, determine that the device is coupled to the baseboard management controller; and in response to determining that the contents do not match, provide an error signal indicating that the contents do not match.

In another implementation of the foregoing baseboard management controller, the contents of the one or more configuration registers of the device specify the property of the device.

In another implementation of the foregoing baseboard management controller, the baseboard management controller further comprises: a sensor data record, wherein the device discoverer is configured to store the contents of the one or more configuration registers in the sensor data record.

In another implementation of the foregoing baseboard management controller, the configuration schema is in accordance with a JavaScript Object Notation (JSON) format.

In another implementation of the foregoing baseboard management controller, the plurality of devices comprises at least one of: a temperature sensor; a humidity sensor; a fan; a power supply unit; a memory device; a central processor unit; a hardware accelerator; a storage device; a storage controller; or a network controller.

A controller device is also described herein. The controller devices includes: an interface for receiving a configuration schema that specifies a plurality of devices coupled to the controller device; at least one processor circuit; and at least one memory that stores program code configured to be executed by the at least one processor circuit, the program code comprising: a device discoverer configured to: for each device of the plurality of devices, perform a discovery sequence based on the configuration schema to verify that the device is coupled to the controller device and to determine a property of the device; and device monitor configured to: responsive to verifying that the devices are coupled to the controller device, monitor operation of the devices.

In one implementation of the foregoing controller device, the program code further comprises: a schema validator configured to: determine that a digital signature associated with the configuration schema is valid; and determine whether the configuration schema is formatted in accordance with a predetermined formatting scheme.

In one implementation of the foregoing controller device, the configuration schema further specifies, for each device of the plurality of devices, at least one of: an address at which the device is located; an address at which one or more configuration registers of the device is located; an expected value for each of the one or more configuration registers; a communication protocol utilized by the device; or a physical location at which the device is located.

In another implementation of the foregoing controller device, the configuration schema further specifies at least one of: for each device of the plurality of devices: an address at which the device is located; an address at which one or more configuration registers of the device is located; an expected value for each of the one or more configuration registers; a communication protocol utilized by the device; or a physical location at which the device is located.

In another implementation of the foregoing controller device, the device discoverer is further configured to: for each device of the plurality of devices: transmit a request to the device; receive a response from the device; responsive to receiving the response from the device, read contents of one or more configuration registers associated with the device; determine whether the contents of each of the one or more configuration registers match the expected value specified for each of the one or more configuration registers by the configuration schema; in response to determining that the content match, determine that the device is coupled to the controller device; and in response to determining that the contents do not match, provide an error signal indicating that the contents do not match.

Claim 1:
A method implemented by a baseboard management controller (<NUM>) mounted to a motherboard (<NUM>), comprising:
receiving (<NUM>) a configuration schema (<NUM>) that specifies a plurality of devices (<NUM>) associated with the motherboard and coupled to the baseboard management controller by a communication bus (<NUM>);
determining that a digital signature associated with the configuration schema (<NUM>) is valid and whether the configuration schema is formatted in accordance with a predetermined formatting scheme;
responsive to determining that the digital signature is valid and that the configuration schema is formatted in accordance with a predetermined formatting scheme, for each device of the plurality of devices, performing (<NUM>) a discovery sequence over the communication bus based on the configuration schema to verify that the device is communicatively coupled to the baseboard management controller and to determine a property of the device; and
responsive to verifying that the devices are communicatively coupled to the baseboard management controller, monitoring (<NUM>) operation of the devices.