A BMC FRU failure recovery method and system

Abstract

The application provides a BMC FRU fault recovery method and system. The method provided by the application comprises the following steps: after the server is powered on, a communication link with the BMC is actively established by the BIOS, and FRU original data stored in the BMC is acquired; the BIOS performs a check processing on the FRU original data, and performs a corresponding synchronous updating or backup recovery operation according to a check result; when the check result is that the FRU original data is abnormal, the BIOS calls FRU backup data in an NVRAM encryption backup area, triggers the BMC to complete FRU data recovery, and synchronously updates FRU data in a dmidecode table; when the check result is that the FRU original data is normal, the BIOS compares the FRU original data with FRU backup data in the NVRAM, performs synchronous updating or keeping of the backup data, and synchronously updates FRU data in the dmidecode table.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a BMC FRU fault recovery method and system. Background Technology

[0002] As the core basis for server hardware asset management, fault location and compatibility verification, FRU covers key hardware data such as component model and serial number. Its validity directly determines the efficiency of server normal startup, asset identification and fault diagnosis. During server operation and startup, FRU information is prone to abnormalities due to various factors such as power failure, abnormal restart, firmware upgrade. Therefore, performing fault recovery on FRU is a necessary measure to ensure stable server operation and achieve efficient hardware management.

[0003] Currently, mainstream FRU fault handling solutions are led by the BMC (Browser Control Center). The BMC maintains and stores FRU information in EEPROM, while the BIOS passively reads FRU data and synchronizes it to the dmidecode table only during server power-on initialization. When an FRU malfunctions, recovery often relies on manual intervention to rewrite the FRU data, and FRU data detection is performed using only a single integrity check. Some solutions perform simple backups of the FRU data. However, existing methods have the following problems and shortcomings: not only is the reliance on the BMC component leading to low reliability of FRU detection and management, and the single verification mechanism is prone to misjudgment and missed detection of data anomalies, but there are also issues with imperfect FRU backup design, making it difficult to guarantee the security and validity of backup data. Furthermore, FRUs cannot achieve automated self-healing after malfunctions, and the manual recovery mode increases maintenance costs and reduces fault recovery efficiency. The lack of synchronization logic between the dmidecode table and FRU data can easily lead to errors in the system reading hardware information. In addition, there is a lack of efficient anomaly linkage mechanism between the BMC and BIOS, making it impossible to achieve automated notification and recovery after FRU damage. These problems make existing solutions unable to meet the requirements of high reliability and automated operation and maintenance for servers.

[0004] Therefore, there is an urgent need for a method to automate and reliably manage FRU information, reduce operation and maintenance costs, and improve the overall stability of server operation. Summary of the Invention

[0005] In view of this, this application provides a BMC FRU fault recovery method and system to achieve automated and highly reliable management of FRU information, reduce operation and maintenance costs, and improve the overall operational stability of the server.

[0006] Specifically, this application is implemented through the following technical solution:

[0007] The first aspect of this application provides a BMC FRU fault recovery method, the method comprising:

[0008] After the server is powered on, the BIOS actively establishes a communication link with the BMC and obtains the raw FRU data stored in the BMC;

[0009] The BIOS performs verification processing on the raw FRU data and performs corresponding synchronous update or backup recovery operations based on the verification result. Specifically, when the verification result indicates that the raw FRU data is abnormal, the BIOS calls the FRU backup data in the NVRAM encrypted backup area, triggers the BMC to complete the FRU data recovery, and synchronously updates the FRU data in the dmidecode table. When the verification result indicates that the raw FRU data is normal, the BIOS compares the raw FRU data with the FRU backup data in NVRAM, performs synchronous update or retention of the backup data, and synchronously updates the FRU data in the dmidecode table.

[0010] A second aspect of this application provides a BMC FRU fault recovery system, the system comprising a BMC module and a BIOS module;

[0011] The BIOS module is used to actively establish a communication link with the BMC module after the server is powered on, and to obtain the raw FRU data stored in the BMC module.

[0012] The BIOS module is also used to perform verification processing on the FRU raw data and perform corresponding synchronization update or backup recovery operations based on the verification results;

[0013] The BMC module is used to call the FRU backup data in the NVRAM encrypted backup area of ​​the BIOS module when the verification result shows that the FRU raw data is abnormal, trigger the BMC module to complete the FRU data recovery, and synchronously update the FRU data in the dmidecode table.

[0014] The BMC module is also used to compare the FRU original data with the FRU backup data in NVRAM when the verification result shows that the FRU original data is normal, perform synchronous update or retention of the backup data, and synchronously update the FRU data in dmidecodetable.

[0015] The BMC FRU fault recovery method and system provided in this application, firstly, establishes a communication link with the BMC and acquires raw FRU data through the BIOS, abandoning the existing management model where the BMC is dominant and the BIOS passively reads the data. By actively initiating data acquisition through the BIOS, the FRU detection becomes proactive, eliminating dependence on the single BMC component. Even if the BMC experiences transmission anomalies, the BIOS can proactively detect and initiate subsequent processing, significantly improving the overall reliability of FRU fault recovery. Secondly, the BIOS performs verification processing on the raw FRU data and then performs synchronous update or backup recovery operations based on the results. This incorporates a dual verification logic of "standardization check + backup data comparison," accurately distinguishing between "abnormal format" and "unsynchronized update" of the FRU data. In two scenarios, the problems of false positives and false negatives that are prone to occur in existing single verification are solved, making subsequent synchronization or recovery operations more targeted. Thirdly, the BIOS calls the FRU backup data in the NVRAM encrypted backup area to complete the relevant operations. Based on the design of separately allocating an encrypted backup area in the BIOS's NVRAM and using a preset encryption algorithm to store the FRU backup data, it not only ensures the storage security of the FRU backup data and prevents data leakage and tampering, but also achieves automatic synchronization between the backup data and the original FRU data through the backup data synchronization update operation when the verification is normal, ensuring the validity of the backup data and providing reliable data support for FRU fault recovery. Fourthly, by synchronously updating dmidecode in both abnormal and normal verification results... The FRU data in the table clarifies the synchronization timing between the dmidecode table and FRU data during backup recovery and data updates, ensuring that the FRU information read by the system and maintenance tools is always the latest and valid data, avoiding hardware information reading errors caused by untimely synchronization. Fifthly, a complete process is constructed, from the BIOS actively acquiring and verifying data, to automatically calling the backup to trigger the BMC to complete recovery and synchronize the dmidecode table in case of anomalies, and automatically comparing and executing backup synchronization or maintaining and synchronizing the dmidecode table in normal conditions. This realizes automated recovery when FRU data is corrupted and automated backup synchronization when data is updated, without the need for manual intervention throughout the process. It forms a complete FRU fault self-healing closed loop, solves the problem of needing manual intervention after FRU anomalies, significantly reduces maintenance costs, and improves fault recovery efficiency. Attached Figure Description

[0016] Figure 1 A flowchart of the BMC FRU fault recovery method provided in Embodiment 1 of this application;

[0017] Figure 2 This is a schematic diagram of the BMC FRU fault recovery system provided in Embodiment 2 of this application. Detailed Implementation

[0018] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0019] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0020] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0021] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0022] Figure 1 This is a flowchart of the BMC FRU fault recovery method provided in Embodiment 1 of this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0023] S101. After the server is powered on, the BIOS actively establishes a communication link with the BMC and obtains the raw FRU data stored in the BMC.

[0024] The BIOS and BMC establish a communication link based on the IPMI protocol or a dedicated communication protocol. The communication link includes data exchange format, transmission rate and verification specifications. The FRU raw data is stored in the EEPROM in the BMC. The FRU raw data includes the model, serial number, manufacturer information and hardware configuration parameters of the server motherboard and each hardware component.

[0025] The method is executed automatically during the BIOS initialization phase when the server is powered on, and the server includes servers with x86, AMD, and ARM architectures.

[0026] Specifically, the server is the hardware device that undertakes core computing tasks and is the core carrier for data processing, storage, and interaction, covering mainstream architecture types such as x86, AMD, and ARM. The BIOS, or Basic Input / Output System, is the server's foundational firmware; in this application, its core role is to guide the detection, verification, backup, and recovery process of FRU data. The BMC, or Baseboard Management Controller, is a dedicated management chip for the server, primarily responsible for server hardware status monitoring, firmware management, and other maintenance-related tasks. In this application, it is responsible for maintaining and storing raw FRU data and cooperating with the BIOS to complete FRU fault recovery.

[0027] Furthermore, the communication link is a dedicated connection channel for data transmission and command interaction between the BIOS and BMC in this application. Established based on the IPMI protocol or a dedicated communication protocol, it is not a simple physical connection. The data interaction format, transmission rate, and verification specifications are pre-defined to ensure the reliability and standardization of information transmission such as FRU data, exception notifications, and recovery commands between the BIOS and BMC, preventing data loss or errors during transmission. FRU, or Field Replaceable Unit, contains raw FRU data, which is core asset information of the server motherboard and various hardware components. Stored in the BMC's EEPROM, it includes key information such as component model, serial number, manufacturer information, and hardware configuration parameters. It is the core basis for server hardware asset management, fault location, and compatibility verification, and is also the core object of fault recovery in this application. EEPROM, or Electrically Erasable Programmable Read-Only Memory, is a dedicated storage medium used by the BMC to store raw FRU data. It features electrically erasable and rewritable characteristics, ensuring data retention even after power loss. It can stably store raw FRU data and allows the BMC to erase and update the raw FRU data after receiving backup data from the BIOS, thus completing fault recovery.

[0028] It should be noted that the FRU fault recovery method of this application is fully automated. Its core applicable scenario is the BIOS initialization stage of power-on for servers of various architectures. It is specifically adapted to servers with x86, AMD, and ARM architectures. No additional hardware components need to be added to the server. It can be achieved by simply optimizing the firmware logic of the BIOS and BMC. It can cover the FRU fault recovery needs of various mainstream servers such as enterprise-level servers, cloud computing servers, and industrial servers.

[0029] In practice, after the server powers on and triggers the boot process, it enters the BIOS initialization stage. During this stage, the BIOS actively initiates a communication connection with the BMC and establishes a communication link between the BIOS and the BMC according to preset communication rules (such as the IPMI protocol). After the communication link is established, the BIOS sends a request to the BMC to obtain the FRU raw data. After receiving the request, the BMC retrieves the FRU raw data stored in its own memory and feeds the FRU raw data back to the BIOS through the established communication link. The BIOS then completes the reception and acquisition of the FRU raw data.

[0030] S102, the BIOS performs verification processing on the FRU raw data, and performs corresponding synchronization update or backup recovery operations based on the verification result.

[0031] Specifically, when the verification result indicates that the FRU raw data is abnormal, the BIOS calls the FRU backup data in the NVRAM encrypted backup area, triggers the BMC to complete the FRU data recovery, and synchronously updates the FRU data in the dmidecode table; when the verification result indicates that the FRU raw data is normal, the BIOS compares the FRU raw data with the FRU backup data in the NVRAM, performs synchronous update or retention of the backup data, and synchronously updates the FRU data in the dmidecode table.

[0032] The NVRAM is a separately allocated encrypted backup area in the BIOS. The FRU backup data is stored using a symmetric encryption algorithm, and the encryption key is preset in the BIOS firmware. The symmetric encryption algorithm is the AES algorithm.

[0033] Specifically, NVRAM, or Non-Volatile Random Access Memory, is a separately allocated encrypted backup area in the BIOS in this step. The data stored in it will not be lost after power failure. It is specifically used to encrypt and store FRU backup data, and the FRU backup data in this area is encrypted using the AES symmetric encryption algorithm. The encryption key is preset in the BIOS firmware, which can effectively prevent backup data from being leaked or tampered with.

[0034] FRU backup data is a copy of FRU data stored in the NVRAM encrypted backup area of ​​the BIOS. It is generated and stored by encrypting the valid FRU data under normal server conditions using the AES algorithm. It serves as the valid data basis for restoring FRU data in the BMC and synchronizing and updating the dmidecode table when the original FRU data is abnormal. It can also be used as reference data to compare and determine whether the original FRU data is the latest version when it is normal.

[0035] The dmidecode table, or DMI decoding table, is the core carrier in the server used to store valid FRU data, allowing the system and various maintenance tools to read hardware asset information. In this step, it will be updated in real time according to the FRU data verification results: when the original FRU data is abnormal, the decrypted FRU backup data in NVRAM is synchronized; when the original FRU data is normal, the latest original FRU data is synchronized to ensure that it always stores valid FRU information of the server hardware.

[0036] In specific implementation, the BIOS performs verification processing on the FRU raw data, including: the BIOS performs a full-dimensional standardization check on the FRU raw data according to a preset FRU data industry standard. The standardization check includes at least verifying whether the format of the FRU raw data conforms to the industry standard, whether key information fields are complete and without missing information, whether the hardware configuration parameters meet the corresponding hardware specifications, and whether the CRC / checksum values ​​are valid. After the standardization check, a verification result is generated; the verification result includes whether the check passes or fails.

[0037] Specifically, after receiving the raw FRU data from the BMC, the BIOS initiates its built-in compliance check logic. Following pre-defined industry standards for FRU data, it performs a comprehensive compliance check on the raw FRU data. First, it verifies whether the overall data format strictly conforms to the industry standard. Then, it checks whether key information fields in the data are complete and without missing information. Next, it verifies whether the various hardware configuration parameters in the data match the specifications of the corresponding hardware. Finally, it verifies whether the CRC checksum and checksum values ​​of the raw FRU data are valid. After completing all the above verification tasks, a unique verification result is generated based on the overall verification results. The verification result is categorized into only two types: pass or fail.

[0038] Optionally, when the verification result indicates that the FRU raw data is abnormal, the method includes: the BIOS retrieving the FRU backup data stored in the NVRAM encrypted backup area and decrypting it, and synchronously updating the decrypted FRU backup data to the dmideco detable; the BIOS sending an FRU data abnormality notification and the decrypted FRU backup data to the BMC through a pre-established communication link with the BMC; after receiving the FRU data abnormality notification and the FRU backup data, the BMC writes the FRU backup data into its own EEPROM that maintains the FRU raw data.

[0039] Specifically, when the compliance check determines that the FRU raw data is abnormal, the BIOS first triggers the built-in backup read / write and encryption / decryption module. This module retrieves the pre-stored FRU backup data from its separately partitioned NVRAM encrypted backup area. Using a proprietary encryption key preset in the BIOS firmware, the module employs the AES symmetric encryption algorithm to decrypt the retrieved FRU backup data, obtaining directly usable plaintext FRU backup data. After decryption, the BIOS immediately starts the synchronization update module, completely updating the dmidecode table with the decrypted plaintext FRU backup data, overwriting any existing abnormal FRU data in the table, thus completing the dmidecode process. The BIOS performs an FRU data update operation on the table. Following this, the BIOS sends a dedicated notification command indicating an FRU data anomaly to the BMC via a pre-established communication link. Simultaneously, it transmits the decrypted plaintext FRU backup data to the BMC completely and reliably, according to the preset data interaction format and transmission rate specifications of the communication link. Upon receiving the FRU data anomaly notification command and the decrypted plaintext FRU backup data from the BIOS, the BMC performs an integrity verification on the received data. If the verification passes, the BMC writes the plaintext FRU backup data into its dedicated EEPROM for maintaining and storing original FRU data, overwriting the original abnormal FRU data in the EEPROM, thus completing the overall replacement of the original FRU data in the EEPROM.

[0040] Optionally, before the BIOS retrieves and decrypts the FRU backup data stored in the NVRAM encrypted backup area, the method further includes: performing a validity check on the FRU backup data; when the FRU backup data is detected to be corrupted and unusable, the BIOS encrypts the FRU raw data with a normal verification result obtained from the BMC and writes it into the NVRAM encrypted backup area to restore the FRU backup data in the NVRAM.

[0041] Specifically, before retrieving and decrypting the FRU backup data stored in the NVRAM encrypted backup area, the BIOS first activates its built-in backup data validity detection logic. This logic checks the integrity, encryption validity, and decryptability of the FRU backup data, determining whether it is corrupted and usable. If the detection result indicates that the FRU backup data is corrupted and unusable, the BIOS immediately retrieves the previously verified and deemed normal FRU raw data from the BMC. It then encrypts the raw FRU data using the AES symmetric encryption algorithm pre-installed in the BIOS firmware. After encryption, the encrypted raw FRU data is written to the NVRAM encrypted backup area, overwriting the corrupted FRU backup data and restoring the FRU backup data in the NVRAM. Only then does the BIOS execute the subsequent steps of retrieving and decrypting the FRU backup data stored in the NVRAM encrypted backup area. If the detection result indicates that the FRU backup data is not corrupted and usable, the BIOS directly executes the steps of retrieving and decrypting the FRU backup data stored in the NVRAM encrypted backup area.

[0042] The method provided in this embodiment adds a validity check step before the BIOS retrieves and decrypts the FRU backup data in the NVRAM encrypted backup area. When the backup data is detected to be corrupted and unusable, the method automatically encrypts and rewrites the verified BMC-side FRU raw data into the NVRAM encrypted backup area to complete the backup data recovery. On the one hand, this breaks the one-way dependency mode of the traditional solution that relies solely on NVRAM backup to repair BMC FRU data, realizing a two-way mutual backup relationship between the FRU raw data stored in the BMC and the FRU backup data in the BIOS NVRAM, greatly improving the redundancy and reliability of the overall FRU data protection. On the other hand, it can automatically complete the reconstruction of the damaged backup data without manual intervention, avoiding the problem of FRU anomalies that cannot be self-healed due to backup failure. At the same time, the rewrite operation is only triggered when the backup is corrupted, which does not increase the operating overhead of the normal process and can also significantly reduce the probability of simultaneous corruption of data on both ends in extreme scenarios. This ensures that the system can still autonomously complete the repair and synchronization of FRU data in most failure scenarios, further improving the fully automated self-healing closed loop from detection, backup, recovery to reconstruction, effectively improving the stability and operation and maintenance efficiency of server FRU management.

[0043] Optionally, when the verification result indicates that the FRU raw data is normal, the method includes: the BIOS retrieving the FRU backup data stored in the NVRAM encrypted backup area and decrypting it; comparing the FRU raw data with the decrypted FRU backup data to determine whether the FRU raw data is an updated version; if it is determined to be an updated version, the BIOS encrypts the FRU raw data and synchronously updates it to the NVRAM encrypted backup area, and simultaneously synchronizes the FRU raw data to the dmidecode table; if it is determined that the FRU raw data is consistent with the decrypted FRU backup data, the FRU data in the NVRAM encrypted backup area and the dmidecode table remains unchanged.

[0044] Specifically, when the compliance check determines that the FRU raw data is normal, the BIOS first triggers the built-in backup read / write and encryption / decryption module to retrieve the FRU backup data stored in its separately partitioned NVRAM encrypted backup area. Using a proprietary encryption key preset in the BIOS firmware, the BIOS decrypts the FRU backup data using the AES symmetric encryption algorithm, obtaining plaintext FRU backup data. Subsequently, the BIOS starts the data comparison module, comparing the FRU raw data obtained from the BMC with the decrypted plaintext FRU backup data field by field. Based on the comparison result, it determines whether the FRU raw data is an updated version. If the comparison determines that the FRU raw data is an updated version, the BIOS encrypts the FRU raw data using the aforementioned AES symmetric encryption algorithm, synchronously updates the encrypted FRU raw data to the NVRAM encrypted backup area, overwriting the original backup data. Simultaneously, it starts the synchronization update module to completely synchronize the FRU raw data to dmidecode. In the table, update the FRU data in the table; if the comparison determines that the original FRU data is completely consistent with the decrypted FRU backup data, the BIOS will not perform any data update operation, and keep the FRU backup data in the NVRAM encrypted backup area and the FRU data in the dmidecode table unchanged.

[0045] Optionally, the BIOS encrypts the FRU raw data and synchronously updates it to the encrypted backup area of ​​NVRAM, including: dividing the FRU raw data into four fixed areas according to storage function; the four fixed areas include the Header area, the Chassis area, the Board area, and the Product area; when the BIOS compares the areas, it first determines the difference between the FRU raw data and the FRU backup data area by area, and then performs the corresponding area update according to preset rules; wherein, when it is determined that only the Chassis area has changed data, the data of all four fixed areas are synchronously updated; when it is determined that only the Board area has changed data, the data of the other three areas besides the Chassis area are synchronously updated; when it is determined that only the Product area has changed data, the data of the Header area and the Product area are synchronously updated.

[0046] Specifically, the Header area is the header information area of ​​the FRU data. It is mainly used to record the storage address range of the entire FRU data structure, the starting offset position and length information of each area, and also carries the overall FRU format identification and verification association information. Its data size and content are calculated from the data volume of the other three areas. It does not store business-related hardware information separately, nor does it change data independently. The Chassis area is the chassis information area, used to store hardware information related to the server chassis, including chassis model, serial number, manufacturer, physical specifications, chassis type, and other FRU data related to the external structure of the entire machine. Changes in this area will affect the overall FRU structure association, so all four areas need to be updated synchronously when changes occur. The Board area is the motherboard / printed board information area, mainly storing hardware parameter information of the server motherboard or core function boards, including board model, manufacturer, serial number, hardware version, production time, onboard configuration, and other core component-related data. It is a key area for server hardware identification, and changes to it require synchronous updates to the Header, itself, and Product areas. The Product area is the product information area, used to store server-wide product-level information, including product model, product name, manufacturer information, version information, asset number, configuration description, and other data related to the attributes of the server-wide product. Changes to this area only require updating the Header area and its own area simultaneously.

[0047] In practice, when the BIOS encrypts the raw FRU data and synchronizes it to the NVRAM encrypted backup area, it first divides the raw FRU data into four fixed areas according to storage function: Header area, Chassis area, Board area, and Product area. Then, it compares the raw FRU data with the FRU backup data area by area to determine the location of the data difference, and then performs the update operation of the corresponding area according to preset rules. When it is determined that only the data in the Chassis area has changed, the data in all four fixed areas is synchronized and updated. When it is determined that only the data in the Board area has changed, the data in the other three areas besides the Chassis area is synchronized and updated. When it is determined that only the data in the Product area has changed, only the data in the Header area and the Product area is synchronized and updated, thus completing the differentiated synchronization update by area.

[0048] The method provided in this embodiment divides FRU data into four fixed regions: Header, Chassis, Board, and Product. It employs differentiated local update rules based on changes in each region, abandoning the traditional full-coverage update method. This approach accurately identifies data differences, effectively reducing unnecessary data read / write and encrypted transmission overhead. When the Chassis region changes, it updates completely according to the rules; when the Board region changes, it skips irrelevant Chassis regions; and when the Product region changes, it only updates the necessary regions. This ensures the consistency and integrity of data associations between FRU regions, avoiding data structure corruption caused by local updates. It also significantly reduces NVRAM write pressure and BIOS computational load, improves backup synchronization speed and system operating efficiency, extends storage media lifespan, and further optimizes the stability and reliability of the FRU data automatic synchronization mechanism, making the entire self-healing closed loop more lightweight and efficient.

[0049] The method provided in this embodiment has two aspects. First, by having the BIOS actively establish a communication link with the BMC and acquire raw FRU data, it abandons the existing management model where the BMC is in control and the BIOS passively reads the data. By having the BIOS actively initiate data acquisition, it achieves proactive FRU detection, eliminating dependence on the single component of the BMC. Even if the BMC experiences transmission anomalies, the BIOS can proactively detect and initiate subsequent processing, significantly improving the overall reliability of FRU fault recovery. Second, by explicitly defining that the BIOS performs verification processing on the raw FRU data and then performs synchronous update or backup recovery operations based on the results, it incorporates a dual verification logic of "standardization check + backup data comparison," which can accurately distinguish between "abnormal format" and "unsynchronized update" FRU data. The system addresses several key aspects: First, it solves the problems of misjudgment and missed judgment that easily occur with existing single-verification methods, making subsequent synchronization or recovery operations more targeted. Second, the BIOS uses FRU backup data in the NVRAM encrypted backup area to complete related operations. This design, which allocates a separate encrypted backup area in the BIOS's NVRAM and uses a preset encryption algorithm to store FRU backup data, ensures the storage security of FRU backup data, preventing data leakage and tampering. Furthermore, the system automatically synchronizes backup data with the original FRU data through the backup data synchronization update operation when the verification is normal, ensuring the validity of the backup data and providing reliable data support for FRU fault recovery. Third, it updates dmidecode synchronously in both abnormal and normal verification results. The FRU data in the table clarifies the synchronization timing between the dmidecode table and FRU data during backup recovery and data updates, ensuring that the FRU information read by the system and maintenance tools is always the latest and valid data, avoiding hardware information reading errors caused by untimely synchronization. Fifthly, a complete process is constructed, from the BIOS actively acquiring and verifying data, to automatically calling the backup to trigger the BMC to complete recovery and synchronize the dmidecode table in case of anomalies, and automatically comparing and executing backup synchronization or maintaining and synchronizing the dmidecode table in normal conditions. This realizes automated recovery when FRU data is corrupted and automated backup synchronization when data is updated, without the need for manual intervention throughout the process. It forms a complete FRU fault self-healing closed loop, solves the problem of needing manual intervention after FRU anomalies, significantly reduces maintenance costs, and improves fault recovery efficiency.

[0050] Corresponding to the aforementioned embodiment of a BMC FRU fault recovery method, this application also provides an embodiment of a BMC FRU fault recovery system.

[0051] Figure 2 This is a schematic diagram of the BMC FRU fault recovery system provided in Embodiment 2 of this application. Please refer to... Figure 2The BMC FRU fault recovery system provided in this embodiment includes a BMC module and a BIOS module;

[0052] The BIOS module is used to actively establish a communication link with the BMC module after the server is powered on, and to obtain the raw FRU data stored in the BMC module.

[0053] The BIOS module is also used to perform verification processing on the FRU raw data and perform corresponding synchronization update or backup recovery operations based on the verification results;

[0054] The BMC module is used to call the FRU backup data in the NVRAM encrypted backup area of ​​the BIOS module when the verification result shows that the FRU raw data is abnormal, trigger the BMC module to complete the FRU data recovery, and synchronously update the FRU data in the dmidecode table.

[0055] The BMC module is also used to compare the FRU original data with the FRU backup data in NVRAM when the verification result shows that the FRU original data is normal, perform synchronous update or retention of the backup data, and synchronously update the FRU data in dmidecodetable.

[0056] The system in this embodiment can be used to execute Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.

[0057] The implementation process of the functions and roles of each unit in the above system is detailed in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0058] For the system embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0059] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A BMC FRU fault recovery method, characterized in that, The method includes: After the server is powered on, the BIOS actively establishes a communication link with the BMC and obtains the raw FRU data stored in the BMC; The BIOS performs verification processing on the raw FRU data and performs corresponding synchronous update or backup recovery operations based on the verification result. Specifically, when the verification result indicates that the raw FRU data is abnormal, the BIOS calls the FRU backup data in the NVRAM encrypted backup area, triggers the BMC to complete the FRU data recovery, and synchronously updates the FRU data in the dmidecode table. When the verification result indicates that the raw FRU data is normal, the BIOS compares the raw FRU data with the FRU backup data in NVRAM, performs synchronous update or retention of the backup data, and synchronously updates the FRU data in the dmidecode table.

2. The method according to claim 1, characterized in that, The BIOS performs verification processing on the raw FRU data, including: The BIOS performs a full-dimensional compliance check on the FRU raw data according to the preset FRU data industry standard. The compliance check includes at least the verification of whether the format of the FRU raw data conforms to the industry standard, whether the key information fields are complete and without missing information, whether the hardware configuration parameters meet the corresponding hardware specifications, and whether the CRC / checksum values ​​are valid. After the compliance check, a verification result is generated. The verification result includes whether the check passes or fails.

3. The method according to claim 1, characterized in that, When the verification result indicates that the FRU raw data is abnormal, the method includes: The BIOS retrieves the FRU backup data stored in the NVRAM encrypted backup area and decrypts it, then synchronously updates the decrypted FRU backup data to the dmidecode table. The BIOS sends an FRU data anomaly notification and the decrypted FRU backup data to the BMC via a pre-established communication link with the BMC. After receiving the FRU data anomaly notification and FRU backup data, the BMC writes the FRU backup data into the EEPROM that maintains the original FRU data.

4. The method according to claim 3, characterized in that, Before the BIOS retrieves and decrypts the FRU backup data stored in the NVRAM encrypted backup area, the method further includes: Perform validity checks on the FRU backup data; When the FRU backup data is detected to be corrupt and unusable, the BIOS obtains the FRU raw data with a normal verification result from the BMC, encrypts it, and writes it to the encrypted backup area of ​​the NVRAM to restore the FRU backup data in the NVRAM.

5. The method according to claim 1, characterized in that, When the verification result indicates that the original FRU data is normal, the method includes: The BIOS retrieves the FRU backup data stored in the NVRAM encrypted backup area and decrypts it. It then compares the original FRU data with the decrypted FRU backup data to determine whether the original FRU data is an updated version. If it is determined to be an updated version, the BIOS encrypts the FRU raw data and synchronizes it to the encrypted backup area of ​​NVRAM, and at the same time synchronizes the FRU raw data to the dmidecode table; If it is determined that the original FRU data is consistent with the decrypted FRU backup data, the FRU data in the NVRAM encrypted backup area and the dmidecode table remains unchanged.

6. The method according to claim 5, characterized in that, The BIOS encrypts the raw FRU data and synchronously updates it to the encrypted backup area of ​​NVRAM, including: The FRU raw data is divided into four fixed areas according to storage function; the four fixed areas include the Header area, the Chassis area, the Board area, and the Product area. When the BIOS performs a region comparison, it first determines the differences between the original FRU data and the FRU backup data region by region, and then performs the corresponding region update according to preset rules. Specifically, when it is determined that only the Chassis region has changed data, the data of all four fixed regions are updated synchronously. When it is determined that only the Board region has changed data, the data of the other three regions besides the Chassis region are updated synchronously. When it is determined that only the Product region has changed data, the data of the Header region and the Product region are updated synchronously.

7. The method according to claim 1, characterized in that, The BIOS and BMC establish a communication link based on the IPMI protocol or a dedicated communication protocol. The communication link includes data exchange format, transmission rate and verification specifications. The FRU raw data is stored in the EEPROM in the BMC. The FRU raw data includes the model, serial number, manufacturer information and hardware configuration parameters of the server motherboard and each hardware component.

8. The method according to claim 1, characterized in that, The NVRAM is a separately allocated encrypted backup area in the BIOS. The FRU backup data is stored using a symmetric encryption algorithm, and the encryption key is preset in the BIOS firmware. The symmetric encryption algorithm is the AES algorithm.

9. The method according to claim 1, characterized in that, The method is executed automatically during the BIOS initialization phase when the server is powered on, and the server includes servers with x86, AMD, and ARM architectures.

10. A BMC FRU fault recovery system, characterized in that, The system includes a BMC module and a BIOS module; The BIOS module is used to actively establish a communication link with the BMC module after the server is powered on, and to obtain the raw FRU data stored in the BMC module. The BIOS module is also used to perform verification processing on the FRU raw data and perform corresponding synchronization update or backup recovery operations based on the verification results; The BMC module is used to call the FRU backup data in the NVRAM encrypted backup area of ​​the BIOS module when the verification result shows that the FRU raw data is abnormal, trigger the BMC module to complete the FRU data recovery, and synchronously update the FRU data in the dmidecode table. The BMC module is also used to compare the FRU original data with the FRU backup data in NVRAM when the verification result shows that the FRU original data is normal, perform synchronous update or retention of the backup data, and synchronously update the FRU data in the dmidecode table.

Images