An eSPI link recovery method and electronic equipment

Abstract

This application discloses an eSPI link recovery method and electronic device, relating to the field of computer communication technology. The method includes: a baseboard management controller detecting that the firmware upgrade of the eSPI bridge is complete, and writing a reset trigger value to the target register of the eSPI bridge; the eSPI bridge generating a reset signal and sending it to a central processing unit (CPU); the CPU resetting the eSPI master controller, and based on communication between the eSPI master controller and the eSPI slave controller, re-determining the input / output mode of the eSPI link, and configuring the eSPI master controller based on the input / output mode; the baseboard management controller configuring the eSPI slave controller based on the input / output mode; and the eSPI bridge listening to the communication information between the baseboard management controller and the CPU, determining the input / output mode of the eSPI link based on the communication information, and configuring the eSPI bridge controller based on the input / output mode.

Description

Technical Field

[0001] This application relates to the field of computer communication technology, and in particular to an eSPI link recovery method and electronic device. Background Technology

[0002] In server systems, Enhanced Serial Peripheral Interface (eSPI) bridges, such as Complex Programmable Logic Devices (CPLDs), are commonly used to bridge eSPI bus signals, enabling communication between the Central Processing Unit (CPU) and the Baseboard Management Controller (BMC). With the increasing demands for server intelligence and remote maintenance, in-system programming (ISP) firmware upgrades for eSPI bridges have become routine for system maintenance and feature iteration. During a firmware upgrade, the internal logic of the eSPI bridge is reset, restoring its internal eSPI bridge controller to its default single I / O mode, such as single-channel I / O. However, the CPU and BMC, without undergoing a system-wide reset, retain their original I / O modes, such as quad I / O, leading to inconsistent eSPI link I / O modes and communication interruption.

[0003] Currently, existing technologies typically force a system restart by shutting down the entire machine's AC power (AC OFF / ON) to reinitialize the CPU, BMC, and CPLD, and complete eSPI mode negotiation. However, this method leads to server service interruption, lengthy system restart time, and high manual intervention costs, failing to meet the high availability requirements of 24 / 7 uninterrupted server operation, and is particularly unsuitable for unattended data center scenarios. Summary of the Invention

[0004] In view of this, embodiments of this application provide an eSPI link recovery method and an electronic device.

[0005] According to a first aspect of this application, this application provides an eSPI link recovery method, comprising: The baseboard management controller detects that the firmware upgrade of the eSPI bridge is complete and writes a reset trigger value to the target register of the eSPI bridge; the eSPI bridge is used to bridge the eSPI link between the baseboard management controller and the central processing unit. The eSPI bridge generates a reset signal based on the reset trigger value and sends it to the central processing unit; The central processing unit (CPU) resets the eSPI master controller in the CPU based on the reset signal, and re-determines the input / output mode of the eSPI link based on the communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, and configures the eSPI master controller based on the input / output mode. The baseboard management controller configures the eSPI slave controller based on the input / output mode determined with the central processing unit.

[0006] The eSPI bridge monitors the communication information between the board management controller and the central processing unit, determines the input / output mode of the eSPI link based on the communication information, and configures the eSPI bridge controller in the eSPI bridge based on the input / output mode.

[0007] Furthermore, this application also proposes that the eSPI bridge includes at least one of complex programmable logic devices and field-programmable gate arrays.

[0008] Furthermore, this application also proposes writing a reset trigger value to the target register of the eSPI bridge, including: The baseboard management controller writes a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface.

[0009] Furthermore, this application also proposes that the baseboard management controller writes a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface, including: After a first preset time period, the baseboard management controller writes a reset trigger value to the target register of the eSPI bridge via the integrated circuit bus interface; After a second preset time period, the baseboard management controller writes a status value to the target register of the eSPI bridge via the integrated circuit bus interface. The status value indicates that the target register is in a read-only state and can only be written to by the baseboard management controller.

[0010] Furthermore, this application also proposes that the baseboard management controller sends firmware upgrade data to the eSPI bridge based on the integrated circuit bus interface; The eSPI bridge performs reset and firmware upgrade based on firmware upgrade data; The baseboard management controller monitors the firmware upgrade status of the eSPI bridge based on the integrated circuit bus interface, and determines whether the firmware upgrade of the eSPI bridge is complete based on the firmware upgrade status.

[0011] Furthermore, this application also proposes that the eSPI bridge generates a reset signal based on a reset trigger value and sends it to the central processing unit, including: When the eSPI bridge detects that a reset trigger value has been written to the target register, it generates a reset signal based on the reset trigger value and sends the reset signal to the central processing unit via the reset pin connected to the central processing unit.

[0012] Furthermore, this application also proposes communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, including: Based on the eSPI master controller and eSPI protocol, it communicates with the eSPI slave controller in the baseboard management controller.

[0013] Furthermore, this application also proposes to redetermine the input / output mode of the eSPI link based on communication between the eSPI master controller and the eSPI slave controller in the board management controller, including: The central processing unit sends a request to the eSPI slave controller of the baseboard management controller based on the eSPI master controller. The request is used to request the input / output modes supported by the baseboard management controller. The central processing unit (CPU) receives the parameters returned by the baseboard management controller based on the request, redetermines the input / output mode of the eSPI link based on the parameters and the input / output modes supported by the CPU, and sends the redetermined input / output mode to the baseboard management controller.

[0014] Furthermore, this application also proposes determining the input / output mode of the eSPI link based on communication information, including: The eSPI bridge determines the configuration instructions for the eSPI link based on communication information; The input / output mode of the eSPI link is determined based on configuration instructions.

[0015] According to a second aspect of this application, this application also proposes an electronic device, comprising: The baseboard management controller is used to detect when the firmware upgrade of the eSPI bridge is complete and write a reset trigger value to the target register of the eSPI bridge; the eSPI bridge is used to bridge the eSPI link between the baseboard management controller and the central processing unit. The eSPI bridge is used to generate a reset signal based on the reset trigger value and send it to the central processing unit. The central processing unit (CPU) is used to reset the eSPI master controller in the CPU based on a reset signal, and to re-determine the input / output mode of the eSPI link based on communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, and to configure the eSPI master controller based on the input / output mode. The baseboard management controller is also used to configure the eSPI slave controller based on the input / output mode determined with the central processing unit.

[0016] The eSPI bridge is also used to monitor the communication information between the baseboard management controller and the central processing unit, determine the input / output mode of the eSPI link based on the communication information, and configure the eSPI bridge controller in the eSPI bridge based on the input / output mode.

[0017] Furthermore, this application also proposes that the eSPI bridge includes at least one of complex programmable logic devices and field-programmable gate arrays.

[0018] Furthermore, this application also proposes that the baseboard management controller is used to write a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface.

[0019] Furthermore, this application proposes that the baseboard management controller is used to write a reset trigger value to the target register of the eSPI bridge via the integrated circuit bus interface after a first preset time period; and to write a status value to the target register of the eSPI bridge via the integrated circuit bus interface after a second preset time period, wherein the status value indicates that the status of the target register is read-only and can only be written through the baseboard management controller.

[0020] Furthermore, this application also proposes that the baseboard management controller is also used to send firmware upgrade data to the eSPI bridge based on the integrated circuit bus interface; The eSPI bridge is also used for reset and firmware upgrade based on firmware upgrade data; The baseboard management controller is also used to monitor the firmware upgrade status of the eSPI bridge based on the integrated circuit bus interface, and to determine whether the firmware upgrade of the eSPI bridge is complete based on the firmware upgrade status.

[0021] Furthermore, this application also proposes that when the target register is written with a reset trigger value, the eSPI bridge generates a reset signal based on the reset trigger value and sends the reset signal to the central processing unit via the reset pin connected to the central processing unit.

[0022] Furthermore, this application also proposes that the central processing unit is used to communicate with the eSPI slave controller in the baseboard management controller based on the eSPI master controller and the eSPI protocol.

[0023] Furthermore, this application also proposes that the central processing unit is used to send a request to the eSPI slave controller of the baseboard management controller based on the eSPI master controller, the request being used to request the input / output modes supported by the baseboard management controller; The system obtains the parameters returned by the baseboard management controller based on the request, redetermines the input / output mode of the eSPI link based on the parameters and the input / output modes supported by the central processing unit, and sends the redetermined input / output mode to the baseboard management controller.

[0024] Furthermore, this application also proposes that the eSPI bridge is used to determine the configuration instructions of the eSPI link based on communication information; The input / output mode of the eSPI link is determined based on configuration instructions.

[0025] The eSPI link recovery method and electronic device provided in this embodiment achieve automatic recovery of the eSPI link after an eSPI bridge firmware upgrade. This is accomplished by the baseboard management controller triggering an out-of-band partial reset of the eSPI master controller in the central processing unit (CPU), causing the CPU and baseboard management controller to renegotiate the eSPI link's input / output mode. Simultaneously, the eSPI bridge also configures its bridge controller. This enables automatic recovery of the eSPI link after an intermediate bridging device firmware upgrade, avoiding service interruptions and high maintenance costs associated with traditional whole-system power-off restarts, and significantly improving the availability and maintenance efficiency of the server system.

[0026] 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, specific embodiments of this application are given below. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating an eSPI link recovery method according to an embodiment of this application; Figure 2 This is a flowchart illustrating another eSPI link recovery method in an embodiment of this application; Figure 3 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0028] 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.

[0029] In traditional server eSPI links, during online firmware upgrades of intermediate bridging devices (such as complex programmable logic devices, CPLDs), the internal logic of the bridging device is reset. The eSPI bridge controller reverts to its default input / output mode, while the central processing unit and baseboard management controller maintain their original operating modes. This inconsistency in the eSPI link layer's input / output modes leads to communication interruption. Current eSPI protocol specifications do not provide an automatic recovery solution for such dynamic mode changes, typically requiring a complete AC power-off restart. This results in server service interruption, lengthy system restart times, and high manual intervention costs, failing to meet high availability requirements.

[0030] In response, this application proposes an eSPI link recovery method, such as... Figure 1 As shown, it includes: S101, the baseboard management controller detects that the firmware upgrade of the eSPI bridge is complete and writes a reset trigger value to the target register of the eSPI bridge; the eSPI bridge is used to bridge the eSPI link between the baseboard management controller and the central processing unit.

[0031] S102, the eSPI bridge generates a reset signal based on the reset trigger value and sends it to the central processing unit.

[0032] S103, the central processing unit resets the eSPI master controller in the central processing unit based on the reset signal, and re-determines the input / output mode of the eSPI link based on the communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, and configures the eSPI master controller based on the input / output mode.

[0033] S104, the baseboard management controller configures the eSPI slave controller based on the input / output mode determined with the central processing unit.

[0034] S105, the eSPI bridge monitors the communication information between the board management controller and the central processing unit, determines the input / output mode of the eSPI link based on the communication information, and configures the eSPI bridge controller in the eSPI bridge based on the input / output mode.

[0035] In this embodiment, the eSPI link refers to the serial peripheral interface link between the central processing unit and the baseboard management controller for data transmission. As a high-speed communication interface, it carries system management and control information.

[0036] An eSPI bridge is an intermediate bridging device, such as a complex programmable logic device (CPLD) or a field-programmable gate array (FPGA), configured between a central processing unit (CPU) and a baseboard management controller (BSC) to bridge the signal transmission of the eSPI link. The eSPI bridge controller is a logic module within the eSPI bridge responsible for managing the bridging function of the eSPI signals and configuring the I / O modes of the eSPI link. The target register is a specific memory location within the eSPI bridge used to receive external control commands or status information. The reset trigger value is a preset value written to the target register to instruct the eSPI bridge to generate a reset signal.

[0037] The Central Processing Unit (CPU) is the core processing unit of a computer system, responsible for executing instructions and processing data. It integrates an eSPI master controller. The eSPI master controller is a functional module within the CPU, responsible for initiating eSPI link communication and mode negotiation.

[0038] The Baseboard Management Controller (BMC) is an embedded controller responsible for hardware management, monitoring, and remote control functions of the server system. The eSPI slave controller is a functional module within the Baseboard Management Controller, responsible for responding to communication and mode negotiation initiated by the eSPI master controller.

[0039] Input / output mode (I / O mode) refers to the channel configuration method used by the eSPI link during data transmission, such as single-channel, dual-channel, or quad-channel mode.

[0040] In one implementation, the baseboard management controller (BMC) can periodically query the eSPI bridge's status register to obtain firmware upgrade progress information. When the status register indicates upgrade completion, the upgrade is considered complete. Alternatively, the eSPI bridge can proactively notify the BMC via a dedicated signal line after the firmware upgrade is complete. Another implementation is that the BMC can write firmware upgrade data to the eSPI bridge's flash memory via its own I2C interface, monitoring the ACK signal from the eSPI bridge in real time during the writing process to confirm data transmission accuracy. Once all firmware upgrade data has been written without any abnormalities, the BMC determines that the eSPI bridge's firmware upgrade is complete. When writing the reset trigger value, the BMC can send a specific level signal to the eSPI bridge via a separate communication interface (e.g., a general purpose input / output (GPIO) pin), which the eSPI bridge recognizes as the reset trigger value. Alternatively, the BMC can write a preset value to a specific address on the eSPI bridge via a serial peripheral interface (SPI), which the eSPI bridge interprets as the reset trigger value.

[0041] Furthermore, the eSPI bridge generates a reset signal based on the received reset trigger value and sends this reset signal to the central processing unit (CPU). Specifically, the eSPI bridge may internally include a logic gate that is activated when a reset trigger value is detected being written to the target register, thereby generating a low-level or high-level signal for a specific duration as the reset signal. Alternatively, the eSPI bridge can be configured with a timer that starts upon receiving a reset trigger value and outputs a pulse signal as the reset signal after a preset time. This reset signal can be directly connected to the CPU's reset input via a dedicated hardware pin. Alternatively, the eSPI bridge can broadcast the reset signal via a shared control bus.

[0042] Subsequently, the CPU resets its internal eSPI master controller based on the received reset signal. This reset operation can act solely on the eSPI master controller without affecting other core functions of the CPU. For example, upon receiving the reset signal, the CPU can trigger a dedicated internal reset logic unit that applies a reset operation only to the eSPI master controller module. Alternatively, the CPU can execute a sequence of microcode instructions specifically designed to initialize the eSPI master controller's internal status registers, restoring it to its default configuration. After the eSPI master controller resets, the CPU communicates with the eSPI slave controller in the board management controller to re-determine the input / output mode of the eSPI link. For example, the eSPI master controller can send a general query command to the eSPI slave controller, requesting the communication parameters currently supported by the eSPI slave controller. Alternatively, the eSPI master controller can periodically send a heartbeat packet, and the eSPI slave controller, upon receiving the heartbeat, returns its own configuration information. The CPU selects a compatible input / output mode based on the parameters returned by the eSPI slave controller and its own preset priority rules. For example, if the eSPI slave controller supports multiple modes, the CPU can default to trying one of them. Ultimately, the CPU configures the eSPI master controller based on the redefined input / output mode. For instance, the CPU can set its internal eSPI master controller registers to values ​​that match the redefined input / output mode.

[0043] Simultaneously, the baseboard management controller configures the eSPI slave controller based on the input / output mode determined with the central processing unit (CPU). Specifically, the baseboard management controller can adjust the relevant registers of its internal eSPI slave controller according to the input / output mode implicitly or explicitly indicated by the CPU during communication. For example, the baseboard management controller can listen for mode negotiation requests sent by the CPU and configure the eSPI slave controller according to the type of the request.

[0044] Furthermore, the eSPI bridge is configured to monitor communication between the baseboard management controller (BMD) and the central processing unit (CPU). Based on this communication, the eSPI bridge determines the input / output mode of the eSPI link and configures its internal eSPI bridge controller accordingly. For example, the eSPI bridge can be configured with an internal protocol analysis module that captures all data packets on the eSPI link in real time and parses the control commands and status information contained therein. Alternatively, the eSPI bridge can monitor only specific signal lines on the eSPI link, such as handshake signals related to mode negotiation. Based on the data exchange content between the CPU and the BMD it monitors, such as identifying specific mode configuration commands or mode acknowledgment responses, the eSPI bridge infers the current input / output mode of the eSPI link. Finally, based on the determined input / output mode, the eSPI bridge dynamically adjusts the hardware resource allocation of its internal eSPI bridge controller, such as activating or disabling specific data channels, to ensure consistency with the mode of the CPU and the BMD.

[0045] The eSPI link recovery method provided in this embodiment achieves automatic recovery of the eSPI link after an eSPI bridge firmware upgrade. This is accomplished by the baseboard management controller triggering an out-of-band partial reset of the eSPI master controller in the central processing unit (CPU), causing the CPU and baseboard management controller to renegotiate the eSPI link's input / output mode. Simultaneously, the eSPI bridge also configures its bridge controller. This enables automatic recovery of the eSPI link after an intermediate bridging device firmware upgrade, avoiding service interruptions and high maintenance costs associated with traditional whole-system power-off restarts, and significantly improving the availability and maintenance efficiency of the server system.

[0046] In an optional embodiment, this application further proposes that the eSPI bridge includes at least one of a complex programmable logic device and a field-programmable gate array.

[0047] Specifically, Complex Programmable Logic Devices (CPLDs) are programmable logic devices with relatively low integration density and a small number of logic gates, but possess non-volatile memory characteristics. They typically contain multiple macrocells and programmable interconnect resources, suitable for implementing high-speed, deterministic timing control logic and glue logic. Field-Programmable Gate Arrays (FPGAs), on the other hand, are programmable logic devices with higher integration density, a larger number of logic gates, and greater flexibility. They contain a large number of configurable logic blocks (CLBs), programmable interconnect resources, embedded memory, and DSP blocks, enabling complex digital circuit functions and parallel processing. Implementing an eSPI bridge as a CPLD or FPGA means that its internal logic function is not fixed but can be customized and modified through programming. For example, the register access logic, reset signal generation logic, and listening and parsing logic for communication between the eSPI master controller and the eSPI slave controller can be precisely designed according to the specific version of the eSPI protocol or the implementation details of a particular vendor. This programmability allows the eSPI bridge to flexibly adapt to different hardware platforms and eSPI protocol specifications, ensuring the accuracy and reliability of the eSPI link recovery process in various complex scenarios.

[0048] The above technical solution designs the eSPI bridge to include a CPLD or FPGA. Since the hardware logic of the CPLD or FPGA can be programmed and reconfigured as needed, the eSPI bridge can accurately implement all functions of the eSPI protocol, significantly improving the flexibility and adaptability of the eSPI link recovery method. Furthermore, it provides strong scalability and compatibility for the system, enabling the eSPI bridge to easily cope with the evolution of the eSPI protocol or the needs of different hardware platforms. This avoids compatibility issues or functional expansion limitations that may result from fixed hardware designs, ensuring the long-term effectiveness and stability of the eSPI link recovery method.

[0049] In an optional embodiment, this application further proposes a step of writing a reset trigger value to the target register of the eSPI bridge, comprising: the baseboard management controller writing the reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface.

[0050] The Inter-Integrated Circuit (I2C) interface is a widely used serial communication bus for short-distance, low-speed communication. It typically uses two lines: a serial data line (SDA) and a serial clock line (SCL), supporting communication between multiple master and slave devices. In this embodiment, the I2C interface serves as the physical and protocol layer foundation for data transmission between the baseboard management controller (BMDC) and the eSPI bridge, providing a standardized and reliable communication mechanism that allows the BMDC to accurately address and manipulate the registers within the eSPI bridge. The BMDC acts as the master device of the I2C interface, while the eSPI bridge acts as the slave device. The BMDC completes the write operation to the eSPI bridge's target register by sending the I2C interface's start signal, the slave device address, the target register address (e.g., 0x84), and the data to be written (i.e., the reset trigger value, e.g., 0x00). The I2C interface protocol's ACK / NACK mechanism ensures the reliability of data transmission.

[0051] Through the above technical solution, an integrated circuit bus interface is introduced as a communication mechanism for the baseboard management controller to write reset trigger values ​​to the target register of the eSPI bridge. An eSPI link self-healing mechanism based on the I2C out-of-band channel is established. It is independent of the eSPI protocol and does not rely on the interrupted eSPI bus. It solves the problem that the existing eSPI protocol specification only defines the mode negotiation mechanism when the device is powered on and initialized, and does not cover the dynamic change of link mode caused by firmware upgrade of intermediate bridging devices, thus realizing automatic link recovery.

[0052] In an optional embodiment, this application further proposes that the baseboard management controller writes a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface, including: after a first preset time period, the baseboard management controller writes a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface; simultaneously, after a second preset time period, the baseboard management controller writes a status value to the target register of the eSPI bridge based on the integrated circuit bus interface, the status value indicating that the status of the target register is read-only, and can only be written to through the baseboard management controller.

[0053] Specifically, the first preset duration refers to the time the baseboard management controller waits after detecting that the eSPI bridge's firmware upgrade is complete. This duration is designed to ensure that the eSPI bridge's internal state has stabilized after the firmware upgrade, or that the system has completed necessary initialization or cleanup before performing a write reset trigger value operation. By introducing this preset duration, write operations can be avoided before the eSPI bridge is fully ready, thereby improving the success rate of reset triggers and the stability of link recovery. This duration can be empirically set or determined through testing based on the specific hardware characteristics of the eSPI bridge, the time required for firmware upgrades, and the time required for system startup or stabilization; for example, 100ms.

[0054] The second preset duration refers to the waiting time after the baseboard management controller writes the reset trigger value to the target register of the eSPI bridge. The main purpose of this duration is to provide the necessary buffer time for the eSPI bridge to process the reset trigger value and generate a reset signal, or to ensure that the reset trigger value has been correctly recognized and processed by the eSPI bridge before the target register is set to read-only mode. By waiting for a period of time after writing the reset trigger value before locking the register, premature locking can prevent the reset trigger value from being effectively processed. This duration can also be adjusted according to the response speed of the eSPI bridge and system design requirements, for example, 10ms.

[0055] Furthermore, the status value indicates that the target register is in a read-only state, writable only by the baseboard management controller (BMD), designed to control access permissions to the eSPI bridge's target register. After the BMD writes the reset trigger value and a second preset time elapses, the BMD writes a specific status value, such as 0xFF, to the target register. This status value activates a protection mechanism within the target register or its control logic, making the register read-only in subsequent operations. This means that no component or software other than the BMD can write to it. This protection mechanism can be implemented through hardware logic (e.g., gating the write path via a control bit) or firmware logic (e.g., the firmware within the eSPI bridge rejects write requests from non-baseboard management controllers upon receiving the specific status value). Its core purpose is to prevent the target register from being accidentally or maliciously modified during the critical phase of eSPI link recovery, thereby ensuring the validity of the reset trigger value and the integrity of the eSPI link recovery process.

[0056] By employing the aforementioned technical solution, a reset trigger value is written after a first preset time interval, ensuring that the eSPI bridge only receives the reset command after the firmware upgrade is complete and stable, thus preventing reset failures due to system insecurity. Furthermore, after writing the reset trigger value and waiting for a second preset time interval, the baseboard management controller writes a status value to the target register, setting it to read-only mode and allowing only the baseboard management controller itself to write to it. This mechanism effectively prevents the target register from being accidentally or maliciously modified by other components during eSPI link recovery, thereby ensuring the integrity and validity of the reset trigger value. This significantly improves the robustness and reliability of the eSPI link recovery process, ensuring stable system operation after firmware upgrades and avoiding system instability or functional failures caused by abnormal register states.

[0057] In an optional embodiment, this application further proposes an eSPI link recovery method, such as... Figure 2 As shown, it also includes: S200, the baseboard management controller sends firmware upgrade data to the eSPI bridge based on the integrated circuit bus interface; S201, the eSPI bridge performs reset and firmware upgrade based on firmware upgrade data; S202, the baseboard management controller monitors the firmware upgrade status of the eSPI bridge based on the integrated circuit bus interface, and determines whether the firmware upgrade of the eSPI bridge is complete based on the firmware upgrade status.

[0058] Specifically, the baseboard management controller, as the core of system management, transmits pre-prepared firmware upgrade data to the eSPI bridge via an integrated circuit bus interface (such as I2C or SPI). Firmware upgrade data is a data packet used to update the eSPI bridge's internal program and configuration; reliable transmission is a prerequisite for initiating a firmware upgrade. Upon receiving the firmware upgrade data, the eSPI bridge enters a specific upgrade mode. Typically, it first performs an internal reset to clear the old firmware state, and then writes the received firmware upgrade data into its internal non-volatile memory (such as Flash). The reset operation ensures the purity of the upgrade process, while the firmware upgrade loads new features, fixed defects, or improved performance into the eSPI bridge. During this process, the baseboard management controller periodically reads specific status registers within the eSPI bridge based on the integrated circuit bus interface to obtain the current upgrade status information. This status information may include upgrade in progress, upgrade successful, upgrade failed, and verification error. Based on this status information, the baseboard management controller determines whether the firmware upgrade has been successfully completed; for example, when the status register displays "upgrade successful" or "upgrade complete," the upgrade is considered complete.

[0059] Through the above technical solution, this application ensures that the firmware upgrade process of the eSPI bridge is effectively controlled and verified. The baseboard management controller actively sends firmware upgrade data and continuously monitors the upgrade status of the eSPI bridge until it determines that the firmware upgrade has been successfully completed. This mechanism avoids erroneously triggering the eSPI link recovery process in the event of an incomplete or failed firmware upgrade, thereby significantly improving the reliability and success rate of eSPI link recovery. After the firmware upgrade is completed, the baseboard management controller can accurately know when it is safe to initiate subsequent reset and link reconfiguration steps, ensuring the smoothness and efficiency of the entire eSPI link recovery process, thereby improving the overall stability and maintainability of the system.

[0060] In an optional embodiment, this application further proposes an eSPI bridge that generates a reset signal based on a reset trigger value and sends it to a central processing unit, including: when the eSPI bridge detects that a reset trigger value has been written to the target register, it generates a reset signal based on the reset trigger value and sends the reset signal to the central processing unit via a reset pin connected to the central processing unit.

[0061] In this embodiment, when the baseboard management controller writes a reset trigger value to the eSPI bridge's target register, the eSPI bridge can immediately detect this write event. This monitoring mechanism can be implemented using an interrupt-driven approach, where a write operation to the target register triggers an interrupt signal, notifying the eSPI bridge to process it; alternatively, the eSPI bridge can detect changes by periodically reading the value of the target register, but the interrupt-driven approach typically offers faster response times and higher efficiency. Through this precise monitoring, the eSPI bridge can ensure that it immediately initiates the subsequent reset signal generation process upon receiving a reset command, avoiding unnecessary delays.

[0062] When the eSPI bridge detects that a reset trigger value has been written to the target register, it generates a specific reset signal, eSPI_RST_N, based on that trigger value. This reset signal is an instruction used by the CPU to perform an eSPI master controller reset operation. The reset signal can be generated by activating a dedicated hardware reset pin on the eSPI bridge connected to the CPU, for example, by pulling it low or high for a period of time, to comply with the CPU's electrical specifications and timing requirements for reset signals.

[0063] Through the above technical solution, the eSPI bridge can monitor the reset trigger value written by the board management controller in real time and accurately, thereby ensuring the timely response and accuracy of the reset operation; and the reset signal is sent to the central processing unit based on the reset pin connected to the central processing unit, which improves the reliability and compatibility of the reset signal transmission.

[0064] In an optional embodiment, this application further proposes communication between an eSPI master controller and an eSPI slave controller in a substrate management controller, including: communicating with an eSPI slave controller in a substrate management controller based on the eSPI master controller and the eSPI protocol.

[0065] Specifically, the eSPI master controller is a hardware module that is either inside or tightly integrated into the central processing unit. Its main function is to act as the master device of the eSPI link, responsible for initiating data transmission on the eSPI bus, controlling bus timing, data flow, and protocol interaction. During eSPI link recovery, the eSPI master controller is the core component that communicates with the eSPI slave controllers. It is responsible for sending requests, receiving responses, and configuring its own input / output modes according to the negotiation results.

[0066] The eSPI protocol is a serial peripheral interface protocol used for low-pin-count, high-bandwidth communication between a master (such as a central processing unit) and a slave (such as a board management controller). This protocol defines the physical layer, data link layer, and transaction layer specifications for data transmission, including timing, frame format, command set, and error handling mechanisms. When the eSPI master controller communicates with the eSPI slave controller, the eSPI protocol ensures the standardization, reliability, and interoperability of the communication. By adhering to the eSPI protocol, master and slave devices can correctly parse the data and commands sent to each other, thus successfully negotiating and configuring input / output modes. The purpose of communicating with the eSPI slave controller in the board management controller is to enable the eSPI master controller and the eSPI slave controller to negotiate and determine the optimal input / output mode for the eSPI link during eSPI link recovery. This includes exchanging information about the modes they support and ultimately reaching an agreement.

[0067] Through the above technical solution, during the link recovery phase after the eSPI bridge firmware upgrade, the central processing unit (CPU) can utilize its built-in eSPI master controller to interact with the eSPI slave controller in the baseboard management controller, strictly adhering to the eSPI protocol standard. This standard protocol-based communication method avoids mode negotiation failures caused by unclear or incompatible communication mechanisms, thus ensuring accurate determination and efficient configuration of the eSPI link input / output modes. This not only improves the success rate and stability of eSPI link recovery but also simplifies system integration and debugging, ensuring the normal operation of the system after the firmware upgrade.

[0068] In an optional embodiment, this application further proposes a specific method for re-determining the input / output mode of the eSPI link based on communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, including: the central processing unit (CPU) sends a request to the eSPI slave controller of the baseboard management controller based on the eSPI master controller, the request being used to request the input / output modes supported by the baseboard management controller; the CPU obtains the parameters returned by the baseboard management controller based on the request, re-determines the input / output mode of the eSPI link based on the parameters and the input / output modes supported by the CPU, and sends the re-determined input / output mode to the baseboard management controller.

[0069] Specifically, during eSPI link recovery, the eSPI master controller in the CPU needs to establish or re-establish the eSPI link communication mode with the eSPI slave controller in the board management controller. To ensure the compatibility and optimization of the selected mode, the CPU proactively initiates a request. This request is sent from the eSPI master controller to the eSPI slave controller of the board management controller, and its core purpose is to query the current or supported eSPI input / output modes of the board management controller. This request can be a predefined eSPI command, such as the "Get Capabilities" or "Query Mode" command, which encapsulates the CPU's intent to inquire about the board management controller's mode information. The eSPI master controller packages this command and sends it via the eSPI bus.

[0070] Upon receiving a request from the central processing unit (CPU), the eSPI slave controller in the baseboard management controller (BMS) parses the request and, based on its hardware capabilities and current configuration, generates parameters containing information about the eSPI input / output modes it supports. These parameters can be a bitmask, a list, or a data structure, detailing the eSPI communication modes the BMS can use (e.g., single-channel, dual-channel, quad-channel modes, and different clock frequencies, data widths, etc.). The BMS then returns these parameters to the CPU via the eSPI link.

[0071] After receiving the parameters returned by the baseboard management controller, the central processing unit (CPU) compares and analyzes them with the input / output modes supported by its own eSPI master controller. In this way, the CPU can intelligently redetermine an optimal and compatible eSPI link input / output mode based on the actual capabilities of both parties. Once the new input / output mode is determined, the CPU sends this finalized mode information to the baseboard management controller, informing it to switch to that mode. Upon receiving this information, the baseboard management controller configures its eSPI slave controller accordingly, enabling the eSPI link to communicate between the CPU and the baseboard management controller in a unified and negotiated mode.

[0072] Through the above technical solution, the central processing unit actively queries the baseboard management controller for its supported modes and intelligently matches and selects the input / output modes based on its own supported modes. This solution ensures that the eSPI link recovers quickly and stably in a mode that is supported by both parties and is potentially optimal, significantly improving the reliability and efficiency of eSPI link recovery and guaranteeing the normal operation of the system after firmware upgrades.

[0073] In an optional embodiment, this application further proposes a method for determining the input / output mode of an eSPI link based on communication information, specifically including: the eSPI bridge determining the configuration instructions of the eSPI link based on the communication information; and determining the input / output mode of the eSPI link based on the configuration instructions.

[0074] Specifically, when monitoring communication between the eSPI controller and the central processing unit, the eSPI bridge does not directly infer the input / output mode of the eSPI link. Instead, it first identifies explicit instructions or data related to the eSPI link configuration from this communication information. These configuration instructions can be specific commands defined in the eSPI protocol, register write operations, or data packets containing mode parameters. For example, the eSPI bridge can have a built-in protocol parsing module that can analyze the data flow on the eSPI bus in real time, identifying specific command words or register addresses and write values ​​sent by the eSPI master controller to the eSPI slave controller to set the eSPI link operating mode (such as single-channel mode, dual-channel mode, quad-channel mode, etc.). In this way, the eSPI bridge can accurately capture key signals of eSPI link mode changes.

[0075] Through the above technical solution, the eSPI bridge can more accurately and efficiently identify key data related to the eSPI link input / output mode from complex communication information. This ensures that the eSPI bridge can accurately synchronize the input / output mode negotiated and determined between its internal eSPI bridge controller, eSPI master controller, and eSPI slave controller, thereby improving the reliability and efficiency of the eSPI link recovery process and avoiding communication failures caused by mode mismatch.

[0076] This application also provides an electronic device, such as... Figure 3 As shown, the system includes a baseboard management controller 31, which detects the completion of the firmware upgrade of the eSPI bridge 32 and writes a reset trigger value to the target register 321 of the eSPI bridge 32; the eSPI bridge 32 is used to bridge the eSPI link between the baseboard management controller 31 and the central processing unit 33; the eSPI bridge 32 is used to generate a reset signal based on the reset trigger value and send it to the central processing unit 33; the central processing unit 33 is used to reset the eSPI master controller 331 in the central processing unit 33 based on the reset signal, and to reset the eSPI master controller 331 and the baseboard management controller 32 based on the eSPI master controller 331 and the baseboard management controller 321. In step 1, the eSPI slave controller 311 communicates to redetermine the input / output mode of the eSPI link and configures the eSPI master controller 331 based on the input / output mode. The baseboard management controller 31 is also used to configure the eSPI slave controller 311 based on the input / output mode determined with the central processing unit 33. The eSPI bridge 32 is also used to listen to the communication information between the baseboard management controller 31 and the central processing unit 33, determine the input / output mode of the eSPI link based on the communication information, and configure the eSPI bridge controller 322 in the eSPI bridge 32 based on the input / output mode.

[0077] Electronic devices are intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.

[0078] In this embodiment, by combining the out-of-band triggering mechanism of the baseboard management controller with the precise reset function of the eSPI bridge, and introducing the partial reset and auto-negotiation process of the eSPI master controller, the input / output mode consistency of the eSPI link can be automatically restored without a system reboot after the eSPI bridge firmware upgrade. Specifically, the baseboard management controller writes a reset trigger value to the target register of the eSPI bridge through the integrated circuit bus interface, ensuring reliable transmission of the trigger signal even when the eSPI link is interrupted. The eSPI bridge generates a reset signal in response to the reset trigger value. This reset signal only acts on the eSPI master controller in the central processing unit (CPU), achieving a precise partial reset without affecting the CPU's core business. After resetting the eSPI master controller based on the reset signal, the CPU renegotiates the input / output mode with the baseboard management controller through the standard eSPI protocol process, restoring link communication. Simultaneously, the eSPI bridge dynamically determines and configures the operating mode of the eSPI bridge controller by monitoring the communication information between the CPU and the baseboard management controller. This technical solution effectively solves the link interruption problem caused by eSPI bridge firmware upgrades, achieving zero service interruption, rapid recovery, and no manual intervention, significantly improving the availability and maintenance efficiency of the server system.

[0079] It should be noted that this embodiment uses a CPLD as an example of an eSPI bridge, but it does not constitute a specific limitation on the eSPI bridge.

[0080] In an alternative embodiment, this application also proposes that the eSPI bridge includes at least one of complex programmable logic devices and field-programmable gate arrays.

[0081] In an optional embodiment, this application also proposes, as follows: Figure 3 As shown, the baseboard management controller 31 is used to write a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface 312 (I2C interface).

[0082] In an optional embodiment, this application also proposes that the baseboard management controller is used to write a reset trigger value to the target register of the eSPI bridge via the integrated circuit bus interface after a first preset time period; and to write a status value to the target register of the eSPI bridge via the integrated circuit bus interface after a second preset time period, wherein the status value indicates that the status of the target register is read-only and can only be written through the baseboard management controller.

[0083] In an optional embodiment, this application also proposes, as follows: Figure 3As shown, the baseboard management controller 31 is also used to send firmware upgrade data to the eSPI bridge 32 based on the integrated circuit bus interface 312; the eSPI bridge 32 is also used to perform reset and firmware upgrade based on the firmware upgrade data; the baseboard management controller 31 is also used to monitor the firmware upgrade status of the eSPI bridge 32 based on the integrated circuit bus interface, and determine whether the firmware upgrade of the eSPI bridge is complete based on the firmware upgrade status.

[0084] In specific implementation, such as Figure 3 As shown, the eSPI bridge 32 may also include an I2C upgrade module 323. The baseboard management controller 31 is also used to send firmware upgrade data to the I2C upgrade module 323 of the eSPI bridge 32 based on the integrated circuit bus interface 312. The I2C upgrade module 323 of the eSPI bridge 32 is also used to perform reset and firmware upgrade based on the firmware upgrade data.

[0085] In an optional embodiment, this application also proposes that the eSPI bridge is used to generate a reset signal based on the reset trigger value when it detects that the target register is written with a reset trigger value, and send the reset signal to the central processing unit via a reset pin connected to the central processing unit.

[0086] In specific implementation, such as Figure 3 As shown, the central processing unit 33 also includes an eSPI reset module 332, which is connected to the pin of the target register 321 of the eSPI bridge 32. The eSPI bridge 32 sends a reset signal eSPI_RST_N to the eSPI reset module 332 of the central processing unit 33 via the reset pin connected to the central processing unit 33. The eSPI reset module 332 resets the eSPI master controller based on the reset signal.

[0087] In an optional embodiment, this application also proposes that the central processing unit is used to communicate with the eSPI slave controller in the baseboard management controller based on the eSPI master controller and the eSPI protocol.

[0088] In an optional embodiment, this application also proposes that the central processing unit (CPU) sends a request to the eSPI slave controller of the baseboard management controller based on the eSPI master controller, the request being used to request the acquisition of input / output modes supported by the baseboard management controller; upon receiving parameters returned by the baseboard management controller based on the request, the CPU redetermines the input / output mode of the eSPI link based on the parameters and the input / output modes supported by the CPU, and sends the redetermined input / output mode to the baseboard management controller.

[0089] In an optional embodiment, this application also proposes that the eSPI bridge is used to determine the configuration instructions of the eSPI link based on communication information; and to determine the input / output mode of the eSPI link based on the configuration instructions.

[0090] The following example will provide a more detailed explanation of the above technical solution: In a server system, the central processing unit (CPU) communicates with the baseboard management controller (BMC) via an eSPI link, which is bridged by a complex programmable logic device (CPLD) acting as an eSPI bridge. Under normal operating conditions, to achieve high-bandwidth data transmission, the eSPI master controller in the CPU, the eSPI slave controller in the BMC, and the eSPI bridge controller in the CPLD are all configured in Quad I / O mode.

[0091] When a firmware upgrade is required for the CPLD, the BMC first sends firmware upgrade data to the CPLD via an integrated circuit bus interface (e.g., I2C bus). The CPLD receives and processes this data, performing an internal reset and firmware loading. During this process, the CPLD's internal eSPI bridge controller automatically reverts to its default Single I / O mode. Since the CPU and BMC are not reset, their eSPI controller remains in the Quad I / O mode before the upgrade. At this point, a mismatch occurs between the eSPI link's input / output modes and the CPU / BMC, causing eSPI communication to be interrupted and data transmission to be impossible. This is consistent with the link state mismatch problem after a CPLD firmware upgrade in existing technologies.

[0092] To automatically restore the eSPI link, this solution takes the following steps: First, the baseboard management controller detects that the firmware upgrade of the eSPI bridge is complete. Specifically, the BMC continuously monitors the firmware upgrade status of the CPLD through the integrated circuit bus interface. When all firmware data has been written and the CPLD has completed its internal logic loading, the BMC determines that the firmware upgrade is complete.

[0093] Subsequently, the baseboard management controller writes a reset trigger value to the target register of the eSPI bridge. To ensure the stability of the CPLD's internal logic, the BMC waits for a first preset duration (e.g., 100 milliseconds) after determining that the firmware upgrade is complete. Then, the BMC writes a preset reset trigger value (e.g., 0x00) to a specific target register (e.g., address 0x84) within the CPLD via the integrated circuit bus interface. After writing this value, the BMC waits for a second preset duration (e.g., 10 milliseconds) to ensure that the CPLD's reset trigger logic is fully activated, and then writes a status value (e.g., 0xFF) to the target register, setting it to read-only mode to prevent subsequent false triggers. This out-of-band triggering mechanism via the integrated circuit bus interface avoids reliance on an interrupted eSPI link and solves the problem of a lack of effective recovery mechanisms in existing technologies.

[0094] Next, the eSPI bridge generates a reset signal based on the reset trigger value and sends it to the central processing unit (CPU). The reset trigger logic module inside the CPLD monitors the value of the target register in real time. When it detects that the target register has been written with the reset trigger value (0x00), the CPLD immediately activates the reset logic, generates a reset signal (e.g., eSPI_RST_N, active low for 100 microseconds), and sends the reset signal to the CPU.

[0095] Upon receiving the reset signal, the central processing unit (CPU) resets the eSPI master controller within it. It's important to note that this reset signal only affects the eSPI master controller within the CPU and does not impact CPU core operations, memory data, or running applications. This contrasts with existing technologies that require a complete AC power-off restart, avoiding service interruption and high recovery costs.

[0096] After the eSPI master controller resets, the CPU communicates with the eSPI slave controller in the baseboard management controller (BMC) to re-determine the input / output mode of the eSPI link. Specifically, the CPU's eSPI master controller sends a request to the BMC's eSPI slave controller according to the standard eSPI protocol flow, requesting to obtain the input / output modes and channel capabilities supported by the BMC. Upon receiving the request, the BMC's eSPI slave controller returns its supported input / output modes (e.g., Single I / O, Dual I / O, Quad I / O) and other relevant parameters. Based on the parameters returned by the BMC and its own supported modes, the CPU negotiates and determines the final eSPI link input / output mode (e.g., re-determining Quad I / O mode) and sends the re-determined input / output mode to the BMC.

[0097] Meanwhile, the baseboard management controller configures the eSPI slave controller based on the input / output mode determined with the central processing unit. The BMC configures its internal eSPI slave controller to the Quad I / O mode negotiated with the CPU.

[0098] Furthermore, the eSPI bridge monitors the communication between the eSPI controller and the central processing unit (CPU), determines the input / output mode of the eSPI link based on this communication information, and configures the eSPI bridge controller within the eSPI bridge accordingly. During mode negotiation between the CPU and the BMC, the mode synchronization logic built into the CPLD's eSPI bridge controller listens for and parses the configuration instructions exchanged between the CPU and the BMC in real time. Based on this communication information and configuration instructions, the CPLD determines the input / output mode of the eSPI link (e.g., Quad I / O mode) and configures its eSPI bridge controller to that mode.

[0099] The electronic device provided in this embodiment, after an eSPI bridge firmware upgrade, triggers an out-of-band partial reset of the eSPI master controller in the central processing unit (CPU) by the baseboard management controller. This causes the CPU and the baseboard management controller to renegotiate the input / output mode of the eSPI link, while the eSPI bridge also synchronously configures its bridge controller. This achieves automatic recovery of the eSPI link after an intermediate bridging device firmware upgrade, avoiding service interruptions and high maintenance costs associated with traditional whole-machine power-off restarts, and significantly improving the availability and maintenance efficiency of the server system.

[0100] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0101] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0102] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for eSPI link recovery, characterized in that, include: The baseboard management controller detects that the firmware upgrade of the eSPI bridge is complete and writes a reset trigger value to the target register of the eSPI bridge; The eSPI bridge is used to bridge the eSPI link between the baseboard management controller and the central processing unit. The eSPI bridge generates a reset signal based on the reset trigger value and sends it to the central processing unit; The central processing unit resets the eSPI master controller in the central processing unit based on the reset signal, and re-determines the input / output mode of the eSPI link based on the communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, and configures the eSPI master controller based on the input / output mode. The baseboard management controller configures the eSPI slave controller based on the input / output mode determined with the central processing unit; The eSPI bridge monitors the communication information between the baseboard management controller and the central processing unit, determines the input / output mode of the eSPI link based on the communication information, and configures the eSPI bridge controller in the eSPI bridge based on the input / output mode.

2. The eSPI link recovery method according to claim 1, characterized in that, The eSPI bridge includes at least one of complex programmable logic devices and field-programmable gate arrays.

3. The eSPI link recovery method according to claim 1, characterized in that, Writing a reset trigger value to the target register of the eSPI bridge includes: The baseboard management controller writes a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface.

4. The eSPI link recovery method according to claim 3, characterized in that, The baseboard management controller writes a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface, including: After a first preset time period, the baseboard management controller writes a reset trigger value to the target register of the eSPI bridge based on the integrated circuit bus interface; After a second preset time period, the baseboard management controller writes a status value to the target register of the eSPI bridge via the integrated circuit bus interface. The status value indicates that the target register is in a read-only state and can only be written to by the baseboard management controller.

5. The eSPI link recovery method according to claim 1, characterized in that, Also includes: The baseboard management controller sends firmware upgrade data to the eSPI bridge via the integrated circuit bus interface; The eSPI bridge performs a reset and firmware upgrade based on the firmware upgrade data; The baseboard management controller monitors the firmware upgrade status of the eSPI bridge based on the integrated circuit bus interface, and determines whether the firmware upgrade of the eSPI bridge is complete based on the firmware upgrade status.

6. The eSPI link recovery method according to claim 1, characterized in that, The eSPI bridge generates a reset signal based on the reset trigger value and sends it to the central processing unit, including: When the eSPI bridge detects that the target register has been written with the reset trigger value, it generates a reset signal based on the reset trigger value and sends the reset signal to the central processing unit via the reset pin connected to the central processing unit.

7. The eSPI link recovery method according to claim 1, characterized in that, Based on the communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, the following is included: Based on the eSPI master controller and the eSPI protocol, it communicates with the eSPI slave controller in the baseboard management controller.

8. The eSPI link recovery method according to claim 1, characterized in that, Based on the communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, the input / output mode of the eSPI link is redefined, including: The central processing unit sends a request to the eSPI slave controller of the baseboard management controller based on the eSPI master controller. The request is used to request the input / output modes supported by the baseboard management controller. The central processing unit obtains the parameters returned by the baseboard management controller based on the request, redetermines the input / output mode of the eSPI link based on the parameters and the input / output modes supported by the central processing unit, and sends the redetermined input / output mode to the baseboard management controller.

9. The eSPI link recovery method according to claim 1, characterized in that, Determining the input / output mode of the eSPI link based on the communication information includes: The eSPI bridge determines the configuration instructions for the eSPI link based on the communication information; The input / output mode of the eSPI link is determined based on the configuration instructions.

10. An electronic device, characterized in that, include: The baseboard management controller is used to detect when the firmware upgrade of the eSPI bridge is completed and write a reset trigger value to the target register of the eSPI bridge. The eSPI bridge is used to bridge the eSPI link between the baseboard management controller and the central processing unit. An eSPI bridge is used to generate a reset signal based on the reset trigger value and send it to the central processing unit; The central processing unit is configured to reset the eSPI master controller in the central processing unit based on the reset signal, and to re-determine the input / output mode of the eSPI link based on the communication between the eSPI master controller and the eSPI slave controller in the baseboard management controller, and to configure the eSPI master controller based on the input / output mode. The baseboard management controller is also configured to configure the eSPI slave controller based on the input / output mode determined with the central processing unit; The eSPI bridge is also used to monitor the communication information between the baseboard management controller and the central processing unit, determine the input / output mode of the eSPI link based on the communication information, and configure the eSPI bridge controller in the eSPI bridge based on the input / output mode.

11. The electronic device according to claim 10, characterized in that, The eSPI bridge includes at least one of complex programmable logic devices and field-programmable gate arrays.

Images