System and method for monitoring and recovering heterogeneous components

Abstract

A system and method for monitoring and restoring a heterogeneous integrated circuit (IC), such as a field programmable gate array (FPGA) that operates with firmware. A firmware image file of the IC is stored in a storage device. The operating status of the IC is periodically determined by a controller, such as a baseboard management controller (BMC). The firmware image file is installed on the IC. The controller determines whether the installation of the firmware image file results in the restoration of the IC.

Description

Technical Field

[0001] The present disclosure relates generally to firmware recovery of a custom integrated circuit (IC). More specifically, aspects of the present disclosure relate to firmware recovery of a custom integrated circuit, such as a field programmable gate array (FPGA). Background Art

[0002] Servers are used extensively in high-demand applications such as network based systems or data centers. The advent of cloud computing applications has increased the demand for data centers and other heavy operational needs. Data centers have a large number of servers that store data and run applications accessed by users of remotely connected computer devices. A typical data center has a physical chassis structure with power and communication connections. Each rack can support multiple computing servers and storage servers.

[0003] Due to the increase in the variety of potential specialized applications, server design has moved towards heterogeneous computing architectures in recent years. Using heterogeneous computing architectures allows the CPU load in the system to be shared and data to be processed for specific tasks. As a result, heterogeneous architectures improve server performance by load sharing and sharing commands for multiple specialized functions. These improvements are prevalent in servers used in next-generation technologies such as artificial intelligence (AI), 5G, machine learning, and big data analytics applications.

[0004] Custom integrated circuits (ICs), such as field programmable gate arrays (FPGAs), are often used in heterogeneous computing architectures because FPGAs have the benefit of flexible design. FPGAs allow users to design different functions for multiple logic gates on the FPGA. The benefit of using an FPGA is that users can use software to "program" the logic gate hardware of the FPGA IC to perform a specific task or other tasks. Because FPGAs are hardware, FPGAs perform specialized tasks faster than homogeneous processors that execute software programs. Therefore, FPGAs can be "programmed" to perform multiple different tasks at hardware speeds, thereby eliminating the need for specialized hardware to perform such tasks.

[0005] Since such customized ICs are configured by users, there may be design flaws in the configuration software, which may cause system hang-ups or errors during IC execution. Therefore, an automatic recovery mechanism for customized ICs is needed to improve the reliability of such systems. However, in existing servers, there is no automatic recovery mechanism for customized ICs.

[0006] Therefore, there is a need for a system that includes an automatic recovery mechanism to monitor and recover the firmware of a customized IC. There is also a need for a system that can monitor and recover the baseboard management controller (BMC) while recovering the firmware of the customized IC. There is a further need for a system that does not require CPU cycles to process polling procedures to improve system performance. There is also a need for a system that improves system reliability by recovering the firmware despite side errors. Summary of the invention

[0007] The disclosed example is a system for providing monitoring and recovery of heterogeneous components. The system includes an integrated circuit operating with firmware. The system includes a storage device coupled to the integrated circuit. The storage device stores a firmware image file of the integrated circuit. A controller is coupled to the integrated circuit. The controller is operable to periodically determine the operating state of the integrated circuit and determine a fault of the integrated circuit based on the determined operating state. The controller sends the stored firmware image file to the integrated circuit and installs the firmware image file on the integrated circuit. The controller determines whether the installation of the firmware image file results in recovery of the integrated circuit.

[0008] In other embodiments of the disclosed example system, the controller is a baseboard management controller (BMC) or a field programmable gate array (FPGA). In another embodiment, the integrated circuit is one of the FPGA or the BMC. In another embodiment, the controller can be operated to reset the integrated circuit in response to detecting a fault. In another embodiment, the integrated circuit sends periodic commands to the controller, and the controller determines the fault based on the periodic commands. In another embodiment, the system includes a non-volatile random access memory (NVRAM) coupled to the integrated circuit and the controller. The integrated circuit periodically writes status data to the NVRAM. The controller determines the fault of the integrated circuit based on the status data. In another embodiment, the storage device is a flash memory. In another embodiment, the controller is in communication with one of an operating system or a basic input output system (BIOS). In another embodiment, if the installation of the firmware image does not result in the recovery of the integrated circuit, the operating system or the BIOS can be operated to disable a hardware port (hardwareport) connected to the integrated circuit.

[0009] Another disclosed example is a method for monitoring and restoring a heterogeneous integrated circuit that operates with firmware. A firmware image file of the integrated circuit is stored in a storage device. The operating state of the integrated circuit is periodically determined by a controller. A fault of the integrated circuit is determined. The stored firmware image file is sent to the integrated circuit. The firmware image file is installed on the integrated circuit. The controller determines whether the installation of the firmware image file results in the restoration of the integrated circuit.

[0010] In other embodiments of the disclosed exemplary method, the controller is a BMC or an FPGA. In another embodiment, the integrated circuit is one of an FPGA or a BMC. In another embodiment, the method includes resetting the integrated circuit in response to detecting a fault. In another embodiment, the fault is determined based on periodic commands sent by the integrated circuit to the controller. In another embodiment, the operating state of the integrated circuit is periodically determined, including the integrated circuit writing state data to NVRAM, and the controller reading the written state data. In another embodiment, the storage device is a flash memory. In another embodiment, the controller is directed by the OS or BIOS. In another embodiment, the method includes disabling a hardware port connected to the integrated circuit if the installation of the firmware image file does not result in the recovery of the integrated circuit.

[0011] Another disclosed example is a computing system including an FPGA integrated circuit that operates with firmware. The system includes a storage device coupled to the FPGA integrated circuit and storing a firmware image file of the FPGA integrated circuit. The system includes a BMC coupled to the FPGA integrated circuit. The BMC can operate to periodically determine the operating status of the FPGA integrated circuit. The BMC determines whether the FPGA integrated circuit is faulty based on the determined operating status. The BMC sends the stored firmware image file to the FPGA integrated circuit. The BMC installs the firmware image file on the FPGA integrated circuit. The BMC determines whether the installation of the firmware image file causes the FPGA integrated circuit to recover.

[0012] In other implementations of the disclosed operating system, the FPGA integrated circuit can operate to periodically determine the operating status of the BMC; determine the failure of the BMC based on the determined operating status; send a stored BMC firmware image file from a storage device to the BMC; install the BMC firmware image file on the BMC; and determine whether the installation of the BMC firmware image file causes the BMC to recover.

[0013] The above summary of the invention is not intended to represent every embodiment or every viewpoint of the present disclosure. On the contrary, the foregoing summary of the invention only provides examples of certain novel concepts and features listed here. The above features and advantages, as well as other features and advantages of the present disclosure, when associated with the accompanying drawings and the attached claims, will be easily apparent from the following detailed description of representative embodiments and modes for practicing the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The present disclosure will be better understood from the following description of exemplary embodiments in conjunction with the accompanying drawings, in which:

[0015] Figure 1 is a block diagram of an example FPGA-based system according to certain aspects of the present disclosure.

[0016] Figure 2 According to certain views of this disclosure, Figure 1 Flowchart of the firmware recovery routine for the example FPGA system in .

[0017] Figure 3 is a block diagram of another FPGA-based system according to certain aspects of the present disclosure.

[0018] Figure 4 According to certain views of this disclosure, Figure 3 Flowchart of the firmware recovery routine for the example system in FIG.

[0019] The present disclosure allows for a wide variety of modifications and alternative forms. Certain representative embodiments have been shown by way of example in the accompanying drawings and will be described in detail herein. However, it should be understood that the present invention is not intended to be limited to the particular form disclosed. On the contrary, the present disclosure is intended to cover all modifications, equivalents, and alternatives that fall within the spirit and scope of the present invention as defined by the appended claims. DETAILED DESCRIPTION

[0020] The present invention can be implemented in many different forms. Representative embodiments are shown in the accompanying drawings and will be described in detail herein. The present disclosure is an example or illustration of the principles of the present invention and is not intended to limit the broad viewpoints of the present disclosure to the illustrated embodiments. On this basis, elements and limitations disclosed in paragraphs such as the abstract, the content of the invention and the embodiments, but not explicitly listed in the claims, should not be incorporated into the claims individually, collectively, implicitly, inferentially or otherwise. For the purpose of this detailed description, unless specifically denied, the singular includes the plural, and vice versa; and the word "include" means "include without limitation". In addition, words that represent approximation, such as "about", "almost", "substantially", "approximately" and similar words, can be used here to mean "in", "near", "close to", "within the range of 3-5%" or "within an acceptable manufacturing tolerance", or any logical combination thereof.

[0021] The present disclosure relates to providing a backup specialized integrated circuit image file in a storage device (such as flash memory). The integrated circuit is periodically tested, and if a failure is detected, the image file can be provided to reset the operation of the integrated circuit.

[0022] Figure 1A system 100 is shown that allows monitoring and recovery of heterogeneous components such as integrated circuits. Recovery can be automatically performed using existing controllers of the system 100 via integrated controller firmware images. The system 100 includes a baseboard management controller (BMC) 110, a specialized integrated circuit such as a field programmable gate array (FPGA) 120, and a storage device such as a flash memory 130. In this example, the FPGA 120 is an Intel Arria 10 FPGA System on a Chip (SoC), but other specialized heterogeneous integrated circuits, such as complex programmable logic devices (CPLDs), can apply the principles described herein. In this example, the flash memory 130 includes a firmware image 150 of the FPGA firmware and the BMC firmware. The BMC 110 and the FPGA 120 are coupled to the flash memory 130. In this example, an Intelligent Platform Management Interface (IPMI) bus 160 connects the BMC 110 and the FPGA 120.

[0023] The system 100 provides reliable operation procedures for the BMC 110 and the FPGA 120 through monitoring and recovery. The firmware image files in the firmware image file 150 are reliable backup firmware image files for restoring the operation of the BMC 110 or the FPGA 120. These image files are stored in the flash memory 130. A watchdog timer is set for both the FPGA 120 and the BMC 100.

[0024] FPGA 120 periodically sends information to BMC 110 via commands on IPMI bus 160 (170: send status command for verification). When receiving the command, BMC 110 responds to FPGA 120. The command includes status and error information from FPGA 120. BMC 110's response to the command includes BMC status information for FPGA 120 to verify. If there is an error message in the command to BMC 110, or the command is not received before the time set by the watchdog timer expires, BMC 110 will send a check status command to FPGA 120. In this example, the check status command will be sent three times by BMC 110. If no response to the check status command is received, or FPGA 120 responds with an error status, BMC 110 will record the fault status. Similarly, if no response to the command is received, or an error status is received in the response from BMC 110, FPGA 120 can send a check status command to BMC 110. If no response is received to the verify status command, or the response from BMC 110 indicates a failure, FPGA 120 may record a failure status for BMC 110 .

[0025] When no response is received to the check status command, or an error response is received, the FPGA 120 or BMC 110 will attempt a reset procedure (172: send a reset command). If the reset procedure is successful, the system will return to normal operation. If the reset procedure is unsuccessful, the check status command will be called again. If the check status command fails, or an error response is received, the FPGA 120 or BMC 110 will call a flash recovery procedure to restore the FPGA / BMC firmware image 150 from the flash memory 130 (174: send a flash command). The firmware image 150 is thus sent from the flash memory 130 to the BMC 110 or FPGA 120 (176: execute the flash procedure). If the firmware installation is successful, the BMC 110 or FPGA 120 notifies a system routine, such as a basic input output system (BIOS) or an operating system (OS), that the BMC 110 or FPGA 120 has been restored. The system 100 then communicates back to the FPGA 120 which periodically sends information to the BMC 110 .

[0026] If the response to the check status command is failure, and the flash firmware image is faulty, the system notifies the BIOS and OS that the hardware, such as BMC 110 or FPGA 120, has failed. The BIOS / OS then disables the hardware port connected to the BMC 110 or FPGA 120. The OS stops accessing the FPGA 120 or BMC 110 and sends an error message to the administrator.

[0027] Figure 2 is Figure 1 1. The flowchart of the recovery routine 200 executed by the operating system of the system 100 in FIG. The recovery routine 200 backs up reliable firmware images, such as the BMC and FPGA firmware images in the firmware image 150, for recovery of the FPGA / BMC (step 210). The FPGA / BMC watchdog timer is set (step 212). The FPGA 120 periodically sends status information to the BMC 110 via the IPMI command based on the watchdog timer (step 214). Upon receiving the IPMI command, the BMC 110 responds with the status information to the FPGA 120. If the response is normal (step 216, no), the routine returns and continues to send information to the BMC 110 via the IPMI command, and sends the response from the BMC 110 to the FPGA 120 (step 214). If the response or command contains an error message, or no response is received during the watchdog period (step 216, yes), the routine sends a check status command to the FPGA 120 or BMC 110 (step 218). The corresponding FPGA 120 or BMC 110 determines whether the response to the check status command is a failure, or no response is received (step 220). If the check status command indicates a failure, or no response is received, neither the BMC 110 nor the FPGA 120 provides a fail state log entry (step 222).

[0028] If there is a positive response to any of the check status commands (step 220, no), the routine returns to the watchdog state where FPGA 120 sends periodic commands to BMC 110 (step 214). If a response indicating a failure is received, or there is no response to the check status command, a failure status record entry is provided (step 222). FPGA 120 or BMC 110 then calls a reset procedure to restore FPGA 120 or BMC 110, respectively (step 224). The reset procedure is then initialized by FPGA 120 or BMC 110. If FPGA 120 or BMC 110 communicates, thereby indicating that the reset is successful (step 226, no), the routine notifies the BIOS or operating system (OS) that BMC 110 or FPGA 120 has been restored (step 228). The routine returns and continues to send information to BMC 110 via IPMI commands (step 214).

[0029] If the reset procedure fails to restore the FPGA 120 or BMC 110, respectively, the routine sends a series of check state commands to the FPGA 120 (step 230). The routine determines whether there is a positive response to any of the check state commands (step 232). If there is a positive response to any of the check state commands (step 232, no), the routine returns to the watchdog state where the FPGA 120 sends periodic commands to the BMC 110 (step 214). If there is no response to any of the check state commands, or a fault response is received (step 232, yes), the BMC 110 and FPGA 120 provide a fault state record entry (step 234). The FPGA 120 or BMC 110 then calls the flash procedure to restore the appropriate firmware image file from the firmware image file 150 stored in the flash memory 130 to the FPGA 120 or BMC 110 (step 236). The stored firmware image from firmware image 150 is installed on FPGA 120 or BMC 110. The routine then determines whether FPGA 120 or BMC 110 is operating correctly with the installed firmware image (step 238). If FPGA 120 or BMC 110 is operating correctly, the routine notifies BIOS or OS that BMC 110 or FPGA 120 has been restored (step 228). The routine returns and continues to send information to BMC 110 via IPMI commands (step 214).

[0030] If the flash process fails (step 238, yes), the routine notifies the BIOS and OS that the BMC 110 or FPGA 120 has failed (step 240). The BIOS or OS will disable the hardware port connected to the failed BMC 110 or failed FPGA 120 (step 242). The BIOS or OS will send an error message to the administrator (step 244).

[0031] Figure 3 3 is a block diagram of another example system 300 that allows monitoring firmware for heterogeneous integrated circuits. System 300 includes a baseboard management controller (BMC) 310, a specialized integrated circuit such as a field programmable gate array (FPGA) 320, and a flash memory 330. In this example, flash memory 330 includes a firmware image 340, which includes images of FPGA and BMC firmware. BMC 310 and FPGA 320 are coupled to flash memory 330.

[0032] BIOS 360 is coupled to flash memory 330 and BMC 310. Non-volatile random access memory (NVRAM) 370 is connected to BIOS 360, BMC 310 and FPGA 320. BIOS 360, BMC 310 and FPGA 320 each write status data to NVRAM 370. FPGA 320 and BMC 310 can read status data from NVRAM 370 and can determine the status of other components. BIOS status can also be monitored by FPGA 320 or BMC 310.

[0033] The system 300 provides a reliable operating program for the FPGA 320. The firmware image 340 stored in the flash memory 330 is a reliable backup firmware image file for restoring the operation of the BMC 310 or the FPGA 320. The watchdog timer is set for both the FPGA 320 and the BMC 310.

[0034] BMC 310, FPGA 320 and BIOS 360 each write status data to NVRAM 370 in a periodic manner (350: write status data to NVRAM; and 380: read / write status). BMC 310 reads the written status data about FPGA 320 and BIOS 360. FPGA 320 also reads the written status data about BMC 310 from BMC 310 (380: read / write status). If error information is found in the status data from FPGA 320, BMC 310 will send a check status command to FPGA 320. If error information is found in the status data from BMC 310, FPGA 320 will send a check status command to BMC 310. In this example, the check status command will be sent three times by BMC 310 or FPGA 320. If no response is received to the check status command, or the received response indicates a failure, BMC 310 or FPGA 320 will record the failure status.

[0035] When no response to the check status is received, or a fault is indicated, the FPGA 320 or BMC 310 will attempt to reset the BMC 310 or FPGA 320 (382: send a reset command). If the reset procedure is successful, the system will return to normal operation. If the reset procedure is unsuccessful, the check status command will be called again. If the check status fails, the FPGA 320 or BMC 310 will call a flash procedure to restore the firmware of the FPGA / BMC by accessing the firmware image file from the firmware image file 340 stored in the flash memory 330 (384: send a flash command). The firmware image file is thus sent to the BMC 310 or FPGA 320 (386: execute the flash procedure). If the firmware is successfully installed, the BMC 310 or FPGA 320 notifies the system routines, such as the BIOS 360 or the operating system, that the BMC 310 or FPGA 320 has been restored. The system 300 then returns to normal operation.

[0036] If the response to the check status command is failure, and the flash firmware image is faulty, the system notifies BIOS 360 that the hardware has failed. The BIOS / operating system disables the hardware port connected to BMC 310 or FPGA 320, and the operating system stops accessing FPGA 320 or BMC 310, and sends an error message to the administrator. BMC 310 can also monitor the status of BIOS 360 independently from the status information written to NVRAM 370. If the status information indicates a BIOS failure, BMC 310 can attempt to send a reset command, and if sending the reset command fails, the BIOS firmware image can be restored from flash memory 330.

[0037] Figure 4 4 is a flow chart of a recovery routine 400 executed by the operating system of the system 300. The recovery routine 400 backs up a reliable firmware image file, such as the firmware image file 340 ( Figure 3 ) for the recovery of the FPGA / BMC (step 410). The FPGA / BMC watchdog timer is set (step 412). The BMC 310, FPGA 320, and BIOS 360 each periodically write the corresponding status data to the NVRAM 370 (step 414). The FPGA 320 and BMC 310 verify the written status data from the NVRAM 370 (step 416). If the status data indicates normal operation of the FPGA 320 and the BMC 310 (step 418, no), the routine returns, and the BMC 310, FPGA 320, and BIOS 360 continue to write the status data to the NVRAM 370 (step 414). If the status data contains error information, or no response is received during the watchdog period (step 418, yes), the routine sends a check status command to the FPGA 320 (step 420).

[0038] The routine determines whether there is a positive response to any of the check status commands (step 422). If there is a positive response (step 422, no), the routine returns to the watchdog state where the BMC 310, FPGA 320 and BIOS 360 write the status data to the NVRAM 370 (step 414). If no response is received for any of the check status commands, or a response indicating a failure is received (step 422, yes), the BMC 310 or FPGA 320 provides a failure status record entry (step 424). The FPGA 320 or BMC 310 then calls a reset procedure to restore the FPGA 320 or BMC 310, respectively (step 426). The reset procedure is then attempted by the BMC 310 or FPGA 320. If FPGA 320 or BMC 310 sends a response indicating that the reset was successful (step 428, no), the routine notifies the BIOS or operating system (OS) that BMC 310 or FPGA 320 has been restored (step 430). The routine returns, and BMC 310, FPGA 320, and BIOS 360 continue to write status data to NVRAM 370 (step 414).

[0039] If the reset procedure fails to restore FPGA 320 or BMC 310 respectively (step 428, yes), the routine sends a series of check status commands to FPGA 320 or BMC 310 (step 432). The routine then determines whether there is a positive response to any check status command (step 434). If there is a positive response to any check status command (step 434, yes), the routine returns to the watchdog state where BMC 310, FPGA 320 and BIOS 360 write the status data to NVRAM 370 (step 414). If there is no response to any check status command, or a fault response is received (step 434, yes), BMC 310 or FPGA 320 provides a fault status record entry (step 436). FPGA 320 or BMC 310 then calls the flash routine to restore the firmware image file from the firmware image file 340 stored in the flash memory 330 to FPGA 320 or BMC 310 (step 438). After the firmware image file has been installed on FPGA 320 or BMC 310, respectively, the routine then determines whether FPGA 320 or BMC 310 is running correctly (step 440). If FPGA 320 or BMC 310 is running correctly, the routine notifies BIOS or OS that BMC 310 or FPGA 320 has been restored (step 430). The routine then returns, and BMC 310, FPGA 320 and BIOS 360 continue to write status data to NVRAM 370 (step 414).

[0040] If the flash process fails (step 440, yes), the routine notifies the BIOS 360 and OS that the BMC 310 or FPGA 320 has failed (step 442). The BIOS 360 or OS disables the hardware port connected to the failed BMC 310 or FPGA 320 (step 444). The BIOS 360 or OS sends an error message to the administrator (step 446).

[0041] The benefit of this procedure is that it allows a system with a third-party customized integrated circuit to automatically recover a faulty integrated circuit. Therefore, this procedure improves system reliability by avoiding system downtime on run time operations involving the integrated circuit. The above example routine does not require CPU cycle time to process the polling procedure, and does not require additional hardware for recovery because components that already exist in the heterogeneous computing architecture are used for the recovery routine. Therefore, the automatic recovery of the faulty integrated circuit does not rely on the network administrator to handle the error. Therefore, the system with the integrated circuit can be recovered in a short time. In addition, the system allows simultaneous monitoring of the BMC and allows the BMC to record and monitor more third-party integrated circuit information.

[0042] According to certain aspects of this disclosure, Figure 2 and Figure 4 For example, those in Figure 1 and Figure 3 , a flow chart of an automatic recovery routine for a system including specialized integrated circuits. Figure 2 and Figure 4 The flowchart in is representative of example machine readable instructions for an automatic recovery process for a specialized integrated circuit. In this example, the machine readable instructions include an algorithm for execution by (a) a processor; (b) a controller; and / or (c) one or more other suitable processing devices. The algorithm may be implemented in software stored on a physical medium such as a flash memory, a CD-ROM, a floppy disk, a hard disk, a digital video disk / digital versatile disk (DVD), or other memory device. However, a person of ordinary skill in the art will readily appreciate that the entire algorithm and / or portions thereof may alternatively be executed by a device other than a processor, and / or implemented in firmware or dedicated hardware in a well-known manner (e.g., may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), a field programmable gate array (FPGA), discrete logic, etc.). For example, any or all elements of the interface may be implemented by software, hardware, and / or firmware. Furthermore, some or all of the machine-readable instructions represented by the flowchart may be implemented manually. In addition, although the example algorithm is referenced Figure 3-4 Although the flowchart shown in the figure is not used for description, a person of ordinary skill in the art will readily understand that many other methods of implementing the example machine-readable instructions may be used alternatively. For example, the execution order of the blocks may be changed, and / or some of the described blocks may be changed, deleted or combined.

[0043] As used in this application, "component", "module", "system" or similar terms generally refer to a computer-related entity, which can be hardware (such as a circuit), a combination of hardware and software, software, or an entity related to an operating machine and having one or more specific functions. For example, a component can be, but is not limited to, a program executed on a processor (such as a digital signal processor), a processor, an object, an executable file, a thread of execution, a program, and / or a computer. As an example, an application executed on a controller, as well as the controller itself, can be a component. One or more components can be resident within a program and / or thread of execution, and a component can be confined to one computer and / or distributed between two or more computers. In addition, a "device" can be in the form of specially designed hardware; general-purpose hardware specially made by executing software on it that enables the hardware to perform specific functions; software stored on a computer-readable medium; or a combination thereof.

[0044] The terminology used herein is for the purpose of describing specific embodiments only and is not intended to limit the present invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. In addition, if the words "including," "having," or variations thereof, are used in the detailed description and / or claims, such words are intended to be included in a manner similar to the word "comprising."

[0045] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. In addition, terms such as those defined in commonly used dictionaries should be interpreted as having the same meaning as they do in the context of the relevant art, and unless explicitly defined as such herein, such terms will not be interpreted as idealized or overly formal concepts.

[0046] Although various embodiments of the present invention have been described above, it should be understood that the embodiments are presented only as examples and not limitations. Even though the present invention has been illustrated and described with reference to one or more embodiments, equivalent substitutions and modifications will be thought of or known by others skilled in the art when reading and understanding this specification and the accompanying drawings. In addition, although a specific feature of the present invention may be disclosed in only one of several embodiments, such feature may be combined with one or more other features of other embodiments, and such other features may be desirable or advantageous for any given or specific application. Therefore, the breadth and scope of the present invention should not be limited to any of the embodiments described above. Instead, the scope of the present invention should be defined according to the following claims and their equivalents.

[0047]

Explanation of symbols

[0048] 100: System

[0049] 110: BMC

[0050] 120: FPGA

[0051] 130: Flash memory

[0052] 150: Firmware image file

[0053] 160: IPMI bus

[0054] 170: Send status command for verification

[0055] 172: Send reset command

[0056] 174: Send flash command

[0057] 176: Execute flash program

[0058] 200: Recovery routine

[0059] 210-244: Steps

[0060] 300: System

[0061] 310: BMC

[0062] 320: FPGA

[0063] 330: Flash memory

[0064] 340: Firmware image file

[0065] 350: Write status data to NVRAM

[0066] 360: BIOS

[0067] 370: NVRAM

[0068] 380: Read / Write status

[0069] 382: Send reset command

[0070] 384: Send flash command

[0071] 386: Execute flash program

[0072] 400: Recovery routine

[0073] 410-446: Steps

Claims

1. A system for monitoring and recovering heterogeneous components, comprising: An integrated circuit that operates with firmware, wherein the integrated circuit is a baseboard management controller BMC or a field programmable gate array FPGA; A storage device is coupled to the integrated circuit, and the storage device stores a firmware image file of the integrated circuit and a firmware image file of a basic input and output system BIOS; a controller coupled to the integrated circuit, wherein when the integrated circuit is an FPGA, the controller is a BMC, or when the integrated circuit is a BMC, the controller is an FPGA; and A non-transitory random access memory NVRAM is coupled to the integrated circuit, the controller and the BIOS, wherein the integrated circuit and the BIOS periodically write status data to the NVRAM; The controller operates the following steps: Periodically reading the written state data of the integrated circuit, and determining the operation state of the integrated circuit based on the state data; Determine the fault of the integrated circuit based on the determined operating status; In response to determining that the integrated circuit is faulty, sending the stored firmware image file of the integrated circuit to the integrated circuit; installing the firmware image file of the integrated circuit on the integrated circuit; and determining whether installation of the firmware image file of the integrated circuit causes recovery of the integrated circuit; The controller also monitors the status data of the BIOS, and in response to determining that the BIOS fails based on the status data of the BIOS, sends the stored firmware image file of the BIOS to the BIOS for recovery.

2. The system according to claim 1, wherein the controller is in communication with an operating system (OS) or a basic input and output system (BIOS).

3. The system of claim 2, wherein if the installation of the firmware image of the integrated circuit does not result in recovery of the integrated circuit, the OS or the BIOS operates to disable a hardware port connected to the integrated circuit.

4. A method for monitoring and restoring a heterogeneous component, comprising the following steps: storing a firmware image file of an integrated circuit and a firmware image file of a basic input and output system BIOS in a storage device, wherein the integrated circuit is a baseboard management controller BMC or a field programmable gate array FPGA; The integrated circuit and the BIOS periodically write status data to a non-transitory random access memory NVRAM; Periodically reading the written state data of the integrated circuit via a controller to determine the operation state of the integrated circuit, wherein when the integrated circuit is an FPGA, the controller is a BMC, or when the integrated circuit is a BMC, the controller is an FPGA; determining a fault of the integrated circuit based on the status data of the integrated circuit; In response to determining that the integrated circuit is faulty, sending the stored firmware image file of the integrated circuit to the integrated circuit; installing a firmware image file of the integrated circuit on the integrated circuit; and determining whether installation of the firmware image file of the integrated circuit results in recovery of the integrated circuit, and The method further includes: The controller monitors the status data of the BIOS, and in response to determining that the BIOS fails based on the status data of the BIOS, sends a stored firmware image file of the BIOS to the BIOS for recovery. The method according to claim 4 , wherein the controller is directed by an operating system (OS) or BIOS. 6 . The method of claim 5 , further comprising disabling a hardware port connected to the integrated circuit if the installation of the firmware image of the integrated circuit does not result in a recovery of the integrated circuit.

Images