Adaptive method, device, system and medium for out-of-band management interface

Abstract

The application discloses an adaptive method, device, system and medium of an out-of-band management interface. The method is applied to a computing device, and comprises the following steps: when the computing device is in an initialization stage of power-on startup and loads device initialization firmware of a target expansion card, acquiring, by a host boot firmware, a working mode currently actually supported by an out-of-band management interface of the target expansion card; and sending the working mode to an out-of-band application management program via a preset out-of-band communication protocol, so as to trigger the out-of-band application management program to select a corresponding underlying interface according to the working mode to perform an out-of-band management initialization operation on the target expansion card, or to abort an out-of-band initialization handshake when a state is invalid. The application overcomes the defects that passive detection of a communication link by an out-of-band management program easily causes decision errors and process card stagnation, and improves the out-of-band link establishment efficiency and system running stability.

Description

Technical Field

[0001] This application relates to the field of server hardware management technology, and in particular to an adaptive method, apparatus, system and medium for an out-of-band management interface. Background Technology

[0002] In modern computing devices and servers, expansion cards such as storage controllers or network controllers are typically equipped with out-of-band management interfaces for independent management of hardware status. Currently, mainstream expansion card out-of-band management interfaces are usually implemented based on different underlying physical communication protocols, such as I2C bus-based communication or PCIe bus-based MCTP communication. In practical applications, out-of-band application management programs running on the baseboard management controller need to establish a link with the expansion card through the corresponding interface mode to perform various out-of-band functions such as obtaining controller information and configuring logic disks.

[0003] However, some expansion cards support multiple out-of-band interfaces in hardware, but only one specific communication mode is configured and activated during actual operation. Since out-of-band application management programs are often passive, they cannot directly and accurately determine the actual interface operating modes supported by the expansion card. Existing technologies typically rely on the management program to probe data from different interfaces to determine the communication method. When faced with an expansion card that responds to scans for both interface modes but only one channel is actually usable, the management program is prone to misjudgments. This flaw in the probing mechanism often causes the application management program process to stall, severely reducing the flexibility of out-of-band device management and the reliability of the initialization phase. Summary of the Invention

[0004] The purpose of this application is to provide an adaptive method, apparatus, system, and medium for out-of-band management interfaces to solve the technical problems mentioned in the background art, such as the tendency of out-of-band application management programs to passively detect communication links, which can easily lead to decision-making errors and process stagnation.

[0005] To achieve the above objectives, according to a first aspect of the embodiments of this application, an adaptive method for an out-of-band management interface is provided, applied to a computing device, wherein the computing device runs host boot firmware responsible for system initialization, the method comprising:

[0006] When the computing device is in the power-on initialization phase and the device initialization firmware of the target expansion card connected to the computing device is loaded, the host boot firmware is used to obtain the current working mode actually supported by the out-of-band management interface of the target expansion card through the interface provided by the device initialization firmware.

[0007] The actual working mode is sent from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol, so as to trigger the out-of-band application management program to select the corresponding underlying interface to perform out-of-band management initialization operation on the target expansion card according to the actual working mode, or to abort the out-of-band initialization handshake when the actual working mode indicates an invalid state.

[0008] In one possible implementation, the step of obtaining the currently supported operating modes of the out-of-band management interface of the target expansion card through the host boot firmware and the interface provided by the device initialization firmware specifically includes:

[0009] Extract the out-of-band link attribute inside the controller chip of the target expansion card as the actual working mode;

[0010] The device initialization firmware includes an Option ROM deployed on the target expansion card.

[0011] In one possible implementation, the out-of-band management interface currently supports any of the following operating modes:

[0012] The first bus mode is an out-of-band management mode based on a basic bus protocol, including I2C or I3C.

[0013] The second bus mode is an out-of-band management mode based on the MCTP protocol. The physical bus on which the MCTP protocol relies includes any one of PCIe, USB, I2C or I3C.

[0014] Invalid state.

[0015] In one possible implementation, the transmission of the actual operating mode from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol specifically includes any of the following transmission methods:

[0016] Using the system's internal KCS or BT physical channel, an IPMI protocol command is initiated to direct a message encapsulating the actual operating mode to the baseboard management controller, which acts as the carrier of the out-of-band application management program; or,

[0017] Using the firmware-level Redfish interface specification, variable parameters carrying the actual working mode are sent to the out-of-band application management program.

[0018] In one possible implementation, the target expansion card specifically includes a storage controller or a network controller.

[0019] In one possible implementation, the step of triggering the out-of-band application management program to select the corresponding underlying interface to perform out-of-band management initialization operations on the target expansion card based on the actual working mode, or aborting the out-of-band initialization handshake when the actual working mode indicates an invalid state, specifically includes:

[0020] When the out-of-band application management program determines that the actual working mode is the first bus mode, it establishes a communication channel based on the first bus mode and performs an initialization operation.

[0021] When the out-of-band application management program determines that the actual working mode is the second bus mode, it establishes a communication channel based on the second bus mode and performs an initialization operation.

[0022] When the out-of-band application management program determines that the actual working mode is the invalid state, it terminates the out-of-band initialization handshake for the target expansion card and triggers the set exception handling process.

[0023] In one possible implementation, when the out-of-band application management program is triggered to establish a communication channel based on the instruction mode and perform initialization operations, it further includes triggering the program to call a dedicated out-of-band management library pre-installed for the target expansion card, and in conjunction with the received actual working mode, to perform out-of-band function reading and configuration of the controller information, hard disk information and logical disk information inside the target expansion card.

[0024] According to a second aspect of the embodiments of this application, an adaptive device with an out-of-band management interface is provided, applied to a computing device, the device comprising:

[0025] The working mode acquisition module is used to obtain the working mode currently actually supported by the out-of-band management interface of the target expansion card through the host boot firmware when the computing device is in the power-on startup initialization phase and the device initialization firmware of the target expansion card connected to the computing device is loaded.

[0026] The mode information sending module is used to send the actual working mode from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol, so as to trigger the out-of-band application management program to select the corresponding underlying interface to perform out-of-band management initialization operation on the target expansion card according to the actual working mode, or to stop the out-of-band initialization handshake when the actual working mode indicates an invalid state.

[0027] According to a third aspect of the embodiments of this application, an electronic device system is provided, the system being a server, the electronic device system comprising:

[0028] The main processor and its data-coupled memory subsystem;

[0029] At least one target expansion card is connected to the electronic device system, and the target expansion card has an out-of-band management interface;

[0030] A baseboard management controller that runs its own out-of-band application management program;

[0031] And a non-volatile memory coupled to the main processor, wherein the non-volatile memory stores host boot firmware, which is loaded and executed by the main processor during the system power-on boot phase, to implement the adaptive method of the out-of-band management interface as described in any one of claims 1 to 7, thereby triggering the baseboard management controller to determine and initialize the out-of-band management communication channel with the target expansion card before entering the host operating system.

[0032] According to a fourth aspect of the present application, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the adaptive method for the out-of-band management interface as described in the first aspect above.

[0033] The above-described one or more technical solutions in the embodiments of this application have at least one or more of the following technical effects:

[0034] This application provides an adaptive method for out-of-band management interfaces. When the computing device is in the power-on initialization phase and the device initialization firmware of the target expansion card connected to the computing device is loaded, the host boot firmware obtains the currently supported operating mode of the target expansion card's out-of-band management interface and sends this operating mode to the out-of-band application management program via a preset out-of-band communication protocol. This advance acquisition mechanism overcomes the shortcomings of the out-of-band application management program passively probing the underlying communication link. Since the out-of-band application management program can select the corresponding underlying interface to perform out-of-band management initialization operations based on the operating mode, or abort the out-of-band initialization handshake when the state is invalid, the time overhead of trying different bus channels is reduced. This technical solution avoids management program judgment errors and process stagnation caused by multi-interface response scanning of the expansion card, which is beneficial to improving the efficiency of establishing out-of-band communication links and improving the compatibility of the device's underlying out-of-band management and the operational stability during the system boot phase.

[0035] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0036] Figure 1 This is a flowchart illustrating an adaptive method for an out-of-band management interface according to an exemplary embodiment.

[0037] Figure 2 This is a structural block diagram of an adaptive device with an out-of-band management interface according to an exemplary embodiment;

[0038] Figure 3 This is a schematic diagram of the hardware architecture of an electronic device system according to an exemplary embodiment.

[0039] Explanation of reference numerals in the attached figures: 110, Working mode acquisition module; 120, Mode information transmission module; 210, Main processor; 220, Memory subsystem; 230, Non-volatile memory; 240, Baseboard management controller; 250, Target expansion card. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0041] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0042] Figure 1 This is a flowchart illustrating an adaptive method for an out-of-band management interface according to an exemplary embodiment, such as... Figure 1 As shown, the method is applied to a computing device, which runs host boot firmware responsible for system initialization. The method includes:

[0043] In step S100, when the computing device is in the power-on initialization phase and loading the device initialization firmware of the target expansion card connected to the computing device, the host boot firmware uses the interface provided by the device initialization firmware to obtain the current operating mode actually supported by the out-of-band management interface of the target expansion card. Specifically, after the computing device receives the power-on command, the system immediately executes the power-on self-test and boot process. In this initialization phase, the host boot firmware performs a full scan of the system bus and device enumeration. When the enumeration process identifies the target expansion card connected to the motherboard interface, the host boot firmware loads the device initialization firmware of the target expansion card into the system memory; the host boot firmware described in this application, as an example, can be BIOS (Basic Input / Output System) or UEFI (Unified Extensible Firmware Interface).

[0044] Because the target expansion card's device initialization firmware is designed according to the unified extensible firmware interface specification and exposes standardized interaction routines, the host boot firmware can directly call these interaction routines to obtain the actual out-of-band management interface operating mode of the target expansion card under the current configuration. This acquisition process occurs before the operating system boots; through active interaction between the host boot firmware and the device initialization firmware, the type of communication bus currently used by the target expansion card is determined.

[0045] After acquisition, the host boot firmware temporarily stores the operating mode information in a designated memory space for later transmission to the out-of-band application management program. Acquiring the actually supported operating mode in advance avoids invalid scanning of multiple bus channels or program hangs caused by attempting to connect to inactive interfaces, ensuring the stable establishment of subsequent out-of-band communication links during the device boot phase.

[0046] In step S200, the actual operating mode is sent from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol. This triggers the out-of-band application management program to select the corresponding underlying interface based on the actual operating mode to perform out-of-band management initialization operations on the target expansion card, or to abort the out-of-band initialization handshake when the actual operating mode indicates an invalid state. Specifically, after obtaining the actual operating mode of the target expansion card, the host boot firmware encapsulates it into a data packet of a preset format and transmits the data packet directly to the out-of-band application management program through the out-of-band communication channel supported by the computing device. This information synchronization process occurs before the out-of-band application management program actively initiates a blind scan, allowing it to obtain the communication attributes of the target expansion card in advance. After receiving and parsing the packet, if the out-of-band application management program determines that the actual operating mode is a specific and valid protocol type, it directly locks and calls the interface library and bus driver that match the operating mode, sends a sequence of control commands to establish a connection to the target expansion card, and thus completes the subsequent out-of-band management initialization operations.

[0047] On the other hand, if the status read by the host boot firmware indicates that the target expansion card does not have out-of-band management functionality, or that its out-of-band management module is not activated in the current hardware state, the actual working mode passed to the out-of-band application management program will be invalid. Upon recognizing this invalid state, the out-of-band application management program will no longer perform subsequent interface connection probes and will proactively terminate the out-of-band initialization handshake with the target expansion card. By guiding the subsequent actions of the out-of-band application management program based on the precise result transmitted by the host boot firmware, it ensures that the program can accurately establish a correctly matched communication link, avoiding repeated trial and error and process stagnation caused by unclear interface types. Especially when the underlying firmware design of some target expansion cards is not perfect, resulting in multiple bus channels being scanned for support information but only one channel actually being effective, this firmware-based advance acquisition mechanism can directly indicate to the application side the currently activated and available channel, effectively preventing the out-of-band application management program from getting stuck for a long time due to not knowing how to select a channel.

[0048] By acquiring the actual operating modes currently supported by the out-of-band management interface of the target expansion card during the power-on initialization phase of the computing device and loading the device initialization firmware of the target expansion card connected to the computing device, the host boot firmware obtains the actual operating modes of the target expansion card's out-of-band management interface and sends these actual operating modes to the out-of-band application management program via a preset out-of-band communication protocol. This advance acquisition mechanism overcomes the shortcomings of the out-of-band application management program passively probing the underlying communication link. Since the out-of-band application management program can select the corresponding underlying interface to perform out-of-band management initialization operations based on the operating mode, or abort the out-of-band initialization handshake when the status is invalid, the time overhead of trying different bus channels is reduced. This technical solution can avoid management program judgment errors and process stagnation caused by multi-interface response scanning of the expansion card, which is conducive to improving the efficiency of establishing out-of-band communication links and improving the compatibility of the device's underlying out-of-band management and the operational stability of the system boot phase.

[0049] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0050] In an exemplary embodiment, the step of obtaining the currently supported operating modes of the out-of-band management interface of the target expansion card through the host boot firmware and the interface provided by the device initialization firmware specifically includes:

[0051] Extract the out-of-band link attribute inside the controller chip of the target expansion card as the actual working mode;

[0052] The device initialization firmware includes an Option ROM deployed on the target expansion card.

[0053] Specifically, target expansion cards typically have an Option ROM (Option Read-Only Memory) burned into their onboard storage media at the factory. During the boot phase, the host boot firmware loads its code segment into system memory to execute a pre-configuration program for the target expansion card. Simultaneously, the core of the target expansion card's data processing and interaction is its controller chip. This controller chip has specific register bits or configuration status words set up to record the out-of-band communication mode determined by current configuration parameters or hardware jumpers; this recorded content constitutes the out-of-band link attribute. Furthermore, this out-of-band link attribute and its corresponding interface mode themselves support active pre-setting. Its underlying mechanism is similar to directly reading or actively modifying the currently active default communication interface in an operating system using command-line tools provided by the hardware manufacturer, such as the storecli command tool for Broadcom controller cards. This application executes this reading action before the firmware boot phase, ensuring the timeliness and accuracy of hardware status acquisition.

[0054] Furthermore, after the Option ROM is loaded and executed, its open interface routines are directly invoked to initiate a status query to the aforementioned controller chip, reading the out-of-band link attributes recorded internally by the controller chip. Since these out-of-band link attributes reflect the hardware enable status of the controller chip for the bus communication interface, they are extracted and directly used as the actual operating mode currently supported by the target expansion card. By directly reading the controller chip's internal attributes, the indirect acquisition method relying on external message probing is avoided, ensuring that the acquired operating mode corresponds to the target expansion card's actual out-of-band communication capabilities.

[0055] In an exemplary embodiment, the out-of-band management interface currently supports any of the following operating modes:

[0056] The first bus mode is an out-of-band management mode based on a basic bus protocol, including I2C or I3C.

[0057] The second bus mode is an out-of-band management mode based on the MCTP protocol. The physical bus on which the MCTP protocol relies includes any one of PCIe, USB, I2C or I3C.

[0058] Invalid state.

[0059] Specifically, the out-of-band communication methods used by the target expansion cards differ in their design. When the actual operating mode is the first bus mode, it indicates that the target expansion card is currently active and using an out-of-band management mode based on a basic bus protocol. The specific protocol type can be a pure I2C protocol or the next-generation high-speed I3C protocol. This mode typically relies directly on independent physical signal lines for control signal transmission, resulting in low protocol overhead. It is a lightweight out-of-band communication method commonly configured in some expansion card models or traditional architectures.

[0060] Furthermore, when the actual operating mode is the second bus mode, it indicates that the target expansion card is currently active and adopts an out-of-band management mode based on the MCTP protocol. The MCTP protocol can multiplex and carry data across hardware buses of different speeds. Specific implementations include MCTP over PCIe, MCTP over USB, MCTP over I2C, and MCTP over I3C. This communication method, which combines a unified transport layer protocol with diverse physical buses, possesses high communication efficiency, good cross-bus expansion capabilities, and data encapsulation and interaction capabilities. It is a communication framework widely compatible with current mainstream expansion cards and new intelligent nodes.

[0061] Furthermore, if the target expansion card lacks out-of-band communication capabilities due to product model limitations, or if out-of-band communication is actively disabled in the current firmware settings, the extracted status will directly appear as invalid. By clearly categorizing the extracted bus attributes into these three statuses, the host boot firmware can clearly define the message format to be encapsulated subsequently, and ensure that the out-of-band application management program, upon receiving the status, can quickly match the corresponding processing branch, thereby calling the corresponding bus driver or directly terminating the call process.

[0062] In an exemplary embodiment, the step of sending the actual operating mode from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol specifically includes any of the following sending methods:

[0063] Using the system's internal KCS or BT physical channel, an IPMI protocol command is initiated to direct a message encapsulating the actual operating mode to the baseboard management controller, which acts as the carrier of the out-of-band application management program; or,

[0064] Using the firmware-level Redfish interface specification, variable parameters carrying the actual working mode are sent to the out-of-band application management program.

[0065] Specifically, when using the first transmission method, the host boot firmware utilizes the system's internal KCS (Keyboard Controller Style) physical channel or BT (Block Transfer) physical channel to encapsulate the acquired actual operating mode as a data payload within a message, following the standard data structure of the IPMI protocol. After encapsulation, the host boot firmware initiates an IPMI protocol command, directing the message to the baseboard management controller, which acts as the carrier of the out-of-band application management program. The baseboard management controller, by listening to the corresponding hardware physical channel, parses the internally recorded actual operating mode upon receiving the message. This method relies on the inherent hardwired channels in the hardware architecture, enabling data interaction between the firmware layer and the baseboard management controller regardless of whether it relies on the byte-based KCS interface or the block-based BT interface.

[0066] Furthermore, when using the second transmission method, the host boot firmware combines the Redfish interface specification at the firmware level for data transmission. The host boot firmware converts the acquired actual operating mode into a format conforming to the Redfish data model and defines it as specific variable parameters. Subsequently, the host boot firmware calls the Redfish interface routine to send the variable parameters carrying this actual operating mode to the out-of-band application management program. The out-of-band application management program reads these variable parameters through a standard network application layer protocol interface, thereby determining the underlying actual operating mode. The above two transmission methods correspond to the underlying hardware control channel and the upper-layer standard management interface, respectively, enabling the status data acquired by the host boot firmware layer to be effectively transmitted to the out-of-band application management program.

[0067] In an exemplary embodiment, the target expansion card specifically includes a storage controller or a network controller. Specifically, the target expansion card, as a hardware component that expands the specific processing capabilities of a computing device, is typically deployed in a pluggable form within a bus slot inside the computing device. When the target expansion card is a storage controller, it is specifically manifested as a RAID controller card or a SAS controller card, such as Broadcom cards or PMC cards commonly found in mainstream architectures. RAID controller cards are primarily used to combine multiple physical disks into a logical array to provide data redundancy and improve read / write performance; SAS controller cards are used to provide a serially attached interface channel to enable data interaction between the computing device and the underlying storage media. These storage controllers are typically configured with independent out-of-band management firmware, allowing out-of-band application management programs to directly obtain the health status of physical disks, array topology, and perform logical disk configuration operations through sideband channels without relying on the host operating system.

[0068] Furthermore, when the target expansion card is a network controller, it is mainly used for sending and receiving network data packets. In this scenario, the network controller also integrates an out-of-band management module, enabling the out-of-band application management program to obtain hardware-level information such as the network controller's media access control address, port connection status, firmware version, or operating temperature through the out-of-band management interface when the operating system is not loaded or the main service network is interrupted.

[0069] Furthermore, the target expansion card is not limited to the aforementioned storage and network devices; any peripheral component interconnect standard expansion hardware with dual-mode or multi-mode out-of-band management interfaces in modern computing node architectures is applicable. For example, DPU (Data Processing Unit) cards used for infrastructure offloading, and GPU (Graphics Processing Unit) accelerator cards undertaking large-scale parallel computing tasks. The host boot firmware can also directly obtain the out-of-band interface modes of these various general computing and acceleration hardware during the device boot phase and notify the out-of-band application management program in advance. This solution achieves out-of-band communication adaptation for different types of expansion cards within the computing device, improving system compatibility.

[0070] In an exemplary embodiment, the step of triggering the out-of-band application management program to select the corresponding underlying interface based on the actual working mode to perform out-of-band management initialization operations on the target expansion card, or terminating the out-of-band initialization handshake when the actual working mode indicates an invalid state, specifically includes:

[0071] When the out-of-band application management program determines that the actual working mode is the first bus mode, it establishes a communication channel based on the first bus mode and performs an initialization operation.

[0072] When the out-of-band application management program determines that the actual working mode is the second bus mode, it establishes a communication channel based on the second bus mode and performs an initialization operation.

[0073] When the out-of-band application management program determines that the actual working mode is the invalid state, it terminates the out-of-band initialization handshake for the target expansion card and triggers the set exception handling process.

[0074] Specifically, after parsing the received actual operating mode, the out-of-band application management program enters the corresponding processing branch program based on the status identifier. When the actual operating mode is determined to be the first bus mode, the out-of-band application management program directly loads the underlying communication library matching the first bus mode and sends the mode identifier to the out-of-band management firmware of the target expansion card to complete the dual-end status alignment. Subsequently, the underlying pins are configured according to the timing requirements of the bus protocol, thereby establishing a communication channel with the target expansion card based on the first bus mode. After the link is established, the corresponding initialization command sequence is issued according to the protocol specification to complete the construction of the out-of-band management environment.

[0075] Furthermore, when the actual operating mode is determined to be the second bus mode, the out-of-band application management program calls the underlying driver and protocol stack corresponding to the second bus mode. It completes the handshake alignment for packet encapsulation and decapsulation on the hardware link, thereby establishing a communication channel based on the second bus mode and performing initialization operations. This method of directly routing branches based on the preceding state allows the out-of-band application management program to directly match the currently active interface of the target expansion card, avoiding the communication overhead caused by blindly sending packets for testing to identify the interface type.

[0076] Furthermore, when the actual operating mode is determined to be invalid, it indicates that the target expansion card has not enabled out-of-band management functionality under the current hardware configuration or does not support this function. In this case, the out-of-band application management program directly terminates the out-of-band initialization handshake with the target expansion card, thereby preventing the underlying communication bus from becoming blocked due to continuous waiting for a timeout response. Simultaneously, the out-of-band application management program triggers a pre-defined exception handling procedure. For example, this procedure may include recording the out-of-band disconnection status of the target expansion card in the system log of the baseboard management controller, or reporting the out-of-band unavailability status of the hardware node to the upper-level management platform, to ensure the continuous and stable operation of the entire device management background process.

[0077] In an exemplary embodiment, when the out-of-band application management program is triggered to establish a communication channel based on the instruction mode and perform initialization operations, it further includes triggering the program to call a dedicated out-of-band management library pre-set for the target expansion card, and in conjunction with the received actual working mode, to perform out-of-band function reading and configuration of the controller information, hard disk information and logical disk information inside the target expansion card.

[0078] Specifically, the target expansion card manufacturer typically provides a dynamic link library or static code library that encapsulates the underlying control logic; this is the aforementioned dedicated out-of-band management library. After identifying the communication channel, the out-of-band application management program actively loads this dedicated out-of-band management library and passes the received actual operating mode as a key parameter to the library function. By passing in this actual operating mode, the dedicated out-of-band management library can directly map the underlying transmit and receive actions to the corresponding bus driver routines, thus eliminating the need to probe the interface type again within the dedicated out-of-band management library itself. This allows the dedicated out-of-band management library to directly call the corresponding bus driver routines.

[0079] Furthermore, after the protocol stack integration is complete, the out-of-band application management program uses the dedicated out-of-band management library to perform initialization probing actions, scanning and obtaining the total number of target expansion cards connected to the current hardware system, and extracting the unique identifier of each target expansion card. Based on this, the out-of-band application management program uses this unique identifier as the addressing basis to establish independent communication with the corresponding target expansion card, and then issues standardized out-of-band control commands to obtain the operating status parameters of the target expansion card. For example, when reading controller information, it extracts the firmware version number, current operating temperature, cache status, or overall health indicator of the target expansion card; when reading hard disk information, it accesses the physical storage media connected to the target expansion card through its out-of-band channel to obtain physical attributes such as the manufacturer serial number, total capacity, media type, and link negotiation rate of each physical hard disk; when reading logical disk information, it reads the topology, stripe size, array operating status, and logical-level data such as whether any hard disks are offline in the currently constructed independent disk redundant array.

[0080] Furthermore, in addition to passive data reading, the out-of-band application management program can also rely on this dedicated out-of-band management library to perform active out-of-band function configuration. For example, even before the operating system is loaded, multiple idle physical hard drives can be configured directly through out-of-band commands to perform logical drive creation, deletion, capacity expansion, or array-level hot spare disk allocation operations.

[0081] In an exemplary embodiment, please refer to Figure 2 This application also provides an adaptive device with an out-of-band management interface, applied to a computing device, the device comprising:

[0082] The working mode acquisition module 110 is used to obtain the working mode currently actually supported by the out-of-band management interface of the target expansion card 250 through the host boot firmware when the computing device is in the power-on startup initialization phase and the device initialization firmware of the target expansion card 250 connected to the computing device is loaded.

[0083] The mode information sending module 120 is used to send the actual working mode from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol, so as to trigger the out-of-band application management program to select the corresponding underlying interface to perform out-of-band management initialization operation on the target expansion card 250 according to the actual working mode, or to stop the out-of-band initialization handshake when the actual working mode indicates an invalid state.

[0084] Specifically, the adaptive device for the out-of-band management interface corresponds to the aforementioned adaptive method in terms of logical architecture. It primarily achieves pre-emptive probing of the underlying interface state and cross-layer synchronization through a modular design. The operating mode acquisition module 110 relies on the underlying runtime environment of the host boot firmware. During the power-on self-test of the computing device, this module is responsible for monitoring the bus device enumeration process. After the device initialization firmware of the target expansion card 250 is loaded into memory, this module directly calls its open standard interface to accurately extract the currently configured and truly activated out-of-band operating mode attributes from the hardware layer. Through the design of this module, the timing of link state probing is moved forward to the underlying firmware stage before the operating system intervenes.

[0085] Furthermore, the mode information sending module 120 receives the link status obtained by the working mode acquisition module 110. The mode information sending module 120 calls the hardware sideband channel or standard management protocol interface inside the motherboard to encapsulate the actual working mode into a standard data packet and pushes it to the out-of-band application management program. Through the data relay of the mode information sending module 120, the out-of-band application management program can directly obtain the deterministic underlying hardware configuration, thereby accurately initiating the corresponding bus driver for communication connection, or directly terminating the invalid handshake process when an invalid status is received.

[0086] In an exemplary embodiment, please refer to Figure 3 This application also provides an electronic device system, which is a server, the electronic device system comprising:

[0087] The main processor 210 and the memory subsystem 220 coupled thereto;

[0088] At least one target expansion card 250 is connected to the electronic device system, and the target expansion card 250 has an out-of-band management interface;

[0089] A baseboard management controller 240 that independently runs out-of-band application management programs;

[0090] And a non-volatile memory 230 coupled to the main processor 210, wherein the non-volatile memory 230 stores host boot firmware, which is loaded and executed by the main processor 210 during the system power-on boot phase to implement the above-mentioned out-of-band management interface adaptive method, thereby triggering the baseboard management controller 240 to determine and initialize the out-of-band management communication channel with the target expansion card 250 before entering the host operating system.

[0091] Specifically, the aforementioned electronic equipment system is typically an enterprise-level server platform. In this system architecture, the main processor 210 is responsible for carrying out core business computing and system-level control logic. It and the memory subsystem 220 are coupled via a high-speed memory bus to jointly form the server's central processing environment. Simultaneously, at least one target expansion card 250 is plugged into the server motherboard to expand the server's storage array construction or network data throughput capabilities. In addition to the high-speed data link communicating with the main processor 210, the target expansion card 250 also has separate signal pins for out-of-band management or a sideband communication interface on its hardware traces.

[0092] Furthermore, the server is internally configured with a baseboard management controller 240. As an embedded management subsystem independent of the main processor 210, the baseboard management controller 240 has its own dedicated microprocessor unit and memory resources, and runs out-of-band application management programs independently within it. Even if the main processor 210 has not completed initialization, is in power-down standby, or has experienced a crash, the baseboard management controller 240 can still maintain continuous operation of low-level status monitoring, logging, and out-of-band access functions.

[0093] Furthermore, the non-volatile memory 230 coupled to the main processor 210 is typically a serial peripheral interface flash memory chip, which internally stores host boot firmware such as a basic input / output system or a unified extensible firmware interface. During the power-on boot phase when the server is powered on, the main processor 210 first reads and executes the code instructions of the host boot firmware from the non-volatile memory 230. When performing peripheral enumeration and board scanning, the host boot firmware actively calls the interface on the target expansion card 250 to obtain the out-of-band management working mode of the target expansion card, and pushes this mode status to the baseboard management controller 240. Through this cooperation between the hardware topology and the firmware operation logic, the baseboard management controller 240 can accurately determine the actual activated interface attributes of the expansion card before the server loads any operating system, and then directly call the corresponding communication protocol to complete the out-of-band channel handshake and establishment.

[0094] In an exemplary embodiment, this application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned adaptive method for out-of-band management interface. Specifically, the computer-readable storage medium can be an electrically erasable programmable read-only memory, a serial flash memory chip, or other firmware storage components with power-loss data retention capabilities. For application scenarios such as servers, the aforementioned storage medium is mainly used to burn and solidify the Basic Input / Output System code, the Unified Extensible Firmware Interface code, and the embedded operating system inside the baseboard management controller.

[0095] Furthermore, when the processor inside the computing device, such as the core processor on the motherboard or the microcontroller integrated within the baseboard management controller, receives a reset or power-on signal, it reads the aforementioned computer program from the computer-readable storage medium and puts it into operation. It can then initiate interactive operations in the underlying bus environment according to preset code logic. By executing these instruction sequences, the processor can perform pre-probing of the out-of-band operating status of the target expansion card, cross-level status data push, and initialization of the underlying communication channel. By stably storing the aforementioned adaptive method in code form in the underlying storage medium, it ensures that the relevant hardware scheduling logic can be reliably woken up in the earliest stage of device power-on boot, thereby giving the system stable and efficient out-of-band link management capabilities independent of the host operating system.

[0096] Any aspects not detailed in this application are well-known to those skilled in the art.

[0097] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. An adaptive method for an out-of-band management interface, characterized in that, Applied to a computing device, wherein the computing device runs host boot firmware responsible for system initialization, the method includes: When the computing device is in the power-on initialization phase and the device initialization firmware of the target expansion card connected to the computing device is loaded, the host boot firmware is used to obtain the current working mode actually supported by the out-of-band management interface of the target expansion card through the interface provided by the device initialization firmware. The actual working mode is sent from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol, so as to trigger the out-of-band application management program to select the corresponding underlying interface to perform out-of-band management initialization operation on the target expansion card according to the actual working mode, or to abort the out-of-band initialization handshake when the actual working mode indicates an invalid state.

2. The adaptive method for out-of-band management interfaces according to claim 1, characterized in that, The step of obtaining the currently supported operating modes of the out-of-band management interface of the target expansion card through the host boot firmware and the interface provided by the device initialization firmware specifically includes: Extract the out-of-band link attribute inside the controller chip of the target expansion card as the actual working mode; The device initialization firmware includes an Option ROM deployed on the target expansion card.

3. The adaptive method for the out-of-band management interface according to claim 1 or 2, characterized in that, The out-of-band management interface currently supports any of the following working modes: The first bus mode is an out-of-band management mode based on a basic bus protocol, including I2C or I3C. The second bus mode is an out-of-band management mode based on the MCTP protocol. The physical bus on which the MCTP protocol is based includes any one of PCIe, USB, I2C or I3C. Invalid state.

4. The adaptive method for out-of-band management interfaces according to claim 1, characterized in that, The transmission of the actual operating mode from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol specifically includes any of the following transmission methods: Using the system's internal KCS or BT physical channel, an IPMI protocol command is initiated to direct a message encapsulating the actual operating mode to the baseboard management controller, which acts as the carrier of the out-of-band application management program; or, Using the firmware-level Redfish interface specification, variable parameters carrying the actual working mode are sent to the out-of-band application management program.

5. The adaptive method for out-of-band management interfaces according to claim 1, characterized in that, The target expansion card specifically includes a storage controller or a network controller.

6. The adaptive method for out-of-band management interfaces according to claim 3, characterized in that, The step of triggering the out-of-band application management program to select the corresponding underlying interface based on the actual working mode to perform out-of-band management initialization operations on the target expansion card, or aborting the out-of-band initialization handshake when the actual working mode indicates an invalid state, specifically includes: When the out-of-band application management program determines that the actual working mode is the first bus mode, it establishes a communication channel based on the first bus mode and performs an initialization operation. When the out-of-band application management program determines that the actual working mode is the second bus mode, it establishes a communication channel based on the second bus mode and performs an initialization operation. When the out-of-band application management program determines that the actual working mode is the invalid state, it terminates the out-of-band initialization handshake for the target expansion card and triggers the set exception handling process.

7. The adaptive method for out-of-band management interfaces according to claim 6, characterized in that, When the out-of-band application management program is triggered to establish a communication channel based on the instruction mode and perform initialization operations, it also includes triggering the program to call a dedicated out-of-band management library pre-installed for the target expansion card, and in conjunction with the received actual working mode, to perform out-of-band function reading and configuration of the controller information, hard disk information and logical disk information inside the target expansion card.

8. An adaptive device with an external management interface, characterized in that, Applied to a computing device, the device includes: The working mode acquisition module is used to obtain the working mode currently actually supported by the out-of-band management interface of the target expansion card through the host boot firmware when the computing device is in the power-on startup initialization phase and the device initialization firmware of the target expansion card connected to the computing device is loaded. The mode information sending module is used to send the actual working mode from the host boot firmware layer to the out-of-band application management program inside the computing device via a preset out-of-band communication protocol, so as to trigger the out-of-band application management program to select the corresponding underlying interface to perform out-of-band management initialization operation on the target expansion card according to the actual working mode, or to stop the out-of-band initialization handshake when the actual working mode indicates an invalid state.

9. An electronic device system, characterized in that, The system is a server, and the electronic device system includes: The main processor and its data-coupled memory subsystem; At least one target expansion card is connected to the electronic device system, and the target expansion card has an out-of-band management interface; A baseboard management controller that runs its own out-of-band application management program; And a non-volatile memory coupled to the main processor, wherein the non-volatile memory stores host boot firmware, which is loaded and executed by the main processor during the system power-on boot phase, to implement the adaptive method of the out-of-band management interface as described in any one of claims 1 to 7, thereby triggering the baseboard management controller to determine and initialize the out-of-band management communication channel with the target expansion card before entering the host operating system.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the adaptive method for the out-of-band management interface as described in any one of claims 1 to 7.

Images