A method and apparatus for detecting corrupted FPGA firmware

Abstract

This application provides a method and apparatus for FPGA firmware corruption detection, belonging to the field of FPGA firmware management technology. The method provided includes: at BMC startup, acquiring remote access parameters; the BMC establishing an access entry for a remote file system locally on the electronic device managed by the BMC based on the remote access parameters; the BMC reading a verification benchmark value from the remote file system mounted locally; the BMC acquiring firmware data stored within the FPGA firmware based on the hardware interface of the electronic device, calculating a verification value based on the firmware data; comparing the verification benchmark value and the verification value to determine the verification result; and automatically repairing the FPGA firmware based on the verification result. The FPGA firmware corruption detection method and apparatus provided in this application are used to achieve FPGA firmware fault detection.

Description

Technical Field

[0001] This application relates to the field of FPGA firmware management technology, and in particular to an FPGA firmware corruption detection method and apparatus. Background Technology

[0002] Servers, storage devices, and high-end network equipment, as core carriers of data processing and transmission, place extremely high demands on the flexibility and efficiency of hardware functions. FPGAs (Field-Programmable Gate Arrays), with their highly parallel architecture and dynamically configurable logic functions, are widely used, undertaking key tasks such as accelerating data processing, implementing protocol conversion, and executing custom control logic, becoming one of the core components ensuring device performance and functional diversity. The stable operation of an FPGA depends entirely on its loaded firmware program, which is typically stored in onboard non-volatile memory such as SPI Flash. Its integrity and correctness directly determine the working state of the FPGA and even the entire device; therefore, firmware management and maintenance are crucial aspects of the device operation and maintenance system.

[0003] To ensure the proper functioning of FPGA firmware, existing technologies rely on the host operating system or manual inspection for firmware status monitoring. For example, the FPGA's operating status is read through the host operating system's drivers, or maintenance personnel periodically log in to the device to check the firmware version and operation logs. On the other hand, some solutions introduce a Baseboard Management Controller (BMC) to assist in firmware management. These solutions provide manual firmware update functionality through the BMC's web interface or command-line tools. Other solutions attempt to use watchdog or heartbeat mechanisms to determine FPGA viability for preliminary hardware fault identification. Furthermore, when firmware corruption is confirmed, traditional repair methods often require maintenance personnel to be physically present on-site, connect to the device via the JTAG debugging interface, manually erase the corrupted firmware, and flash the correct version to complete the firmware recovery operation.

[0004] However, storage media such as SPI Flash are susceptible to power fluctuations, impacts from high-energy particles in space, and physical degradation, leading to bit flips or area corruption in the firmware. The host operating system's detection methods become ineffective due to firmware corruption, which can cause the operating system to fail to boot or the PCIe link to disconnect. Manual inspection is inefficient, only able to respond passively after a fault occurs, failing to achieve preventative measures or rapid intervention during the fault process. Secondly, manually flashing firmware on-site requires significant manpower and time, resulting in long equipment downtime cycles. For scenarios requiring continuous operation, such as data centers, this can cause substantial business losses. In environments with multiple devices and multiple firmware versions, manual repair is prone to firmware version mismatches, leading to incompatibility between the repaired firmware and the hardware and software environment, introducing new factors that cause system instability. Summary of the Invention

[0005] In view of this, this application provides an FPGA firmware corruption detection method and apparatus to realize FPGA firmware fault detection.

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

[0007] The first aspect of this application provides a method for detecting corrupted FPGA firmware, the method comprising:

[0008] At the time of BMC startup, remote access parameters are obtained, and the BMC establishes an access point for the remote file system on the local electronic device managed by the BMC based on the remote access parameters.

[0009] The BMC reads the verification baseline value from the remote file system mounted locally;

[0010] The BMC obtains the firmware data stored in the FPGA firmware based on the hardware interface of the electronic device, and calculates the verification value based on the firmware data.

[0011] By comparing the benchmark value and the verification value, the verification result is determined.

[0012] The FPGA firmware is automatically repaired based on the verification results.

[0013] A second aspect of this application provides an FPGA firmware corruption detection device, the device comprising a setup module, a reading module, and a verification module; wherein...

[0014] The establishment module is used to obtain remote access parameters at the BMC startup time, and the BMC establishes a remote file system access entry locally on the electronic device managed by the BMC based on the remote access parameters.

[0015] The reading module is used by the BMC to read the verification baseline value from the remote file system mounted locally;

[0016] The verification module is used by the BMC to obtain the firmware data stored in the FPGA firmware based on the hardware interface of the electronic device, and to calculate the verification value based on the firmware data.

[0017] The verification module is also used to compare the verification benchmark value and the verification value to determine the verification result;

[0018] The verification module is also used to automatically repair the FPGA firmware based on the verification result.

[0019] The FPGA firmware corruption detection method and apparatus provided in this application directly use the BMC to obtain verification information from the information stored in the FPGA firmware itself during the startup phase, without using intermediate information stored in the intermediate cache mechanism. This improves the accuracy of detection, is not affected by any device status, improves the efficiency of firmware corruption detection, and optimizes the FPGA firmware fault management process. It also achieves significant improvements in reliability, automation, and adaptability to applicable scenarios. Specifically, by proactively acquiring remote access parameters and establishing a remote file system access entry at startup, the BMC can handle the entire process without relying on the host operating system or manual intervention. Even in extreme situations such as host OS failure or PCIe link disconnection, the BMC can still independently complete remote resource access, avoiding the failure of traditional OS-level detection methods due to firmware corruption and ensuring stable startup of the detection process. The BMC directly acquires FPGA firmware data and calculates checksums through the hardware interface, while simultaneously comparing standard checksum values ​​read from the remote file system. This allows for accurate identification of hidden problems such as bit flips and area damage caused by storage media degradation and power fluctuations, changing the passive fault response mode of manual inspection. It can proactively intercept fault risks and prevent faults from escalating and affecting equipment operation. Automatic repair is triggered based on the checksum results, forming a complete automated process that eliminates the need for on-site operation by maintenance personnel. This not only significantly shortens the response and repair time for firmware faults but also reduces manual maintenance costs. It is suitable for scenarios with high equipment continuity requirements, such as large-scale data centers, and can effectively ensure the continuous and stable operation of electronic equipment. Attached Figure Description

[0020] Figure 1 This is a flowchart of an embodiment of the FPGA firmware corruption detection method provided in this application;

[0021] Figure 2 This is a schematic diagram of the structure of Embodiment 2 of the FPGA firmware corruption detection device provided in this application. Detailed Implementation

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

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

[0024] 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."

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

[0026] Figure 1 This is a flowchart of an embodiment of the FPGA firmware corruption detection method provided in this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0027] S101. At the BMC startup time, remote access parameters are obtained, and the BMC establishes a remote file system access entry point locally on the electronic device managed by the BMC based on the remote access parameters.

[0028] Specifically, the BMC's operating phases include the startup initialization phase, the hardware status monitoring and data acquisition phase, the remote communication and command interaction phase, and the fault handling and maintenance phase. The startup initialization phase involves the BMC performing its own firmware initialization after power-on, completing self-tests and function activation of internal hardware modules, and simultaneously reading pre-stored configuration information from the device's local non-volatile memory to establish the basic operating environment. The hardware status monitoring and data acquisition phase, after the BMC has started, establishes communication connections with sensors, storage devices, power modules, and other hardware components on the motherboard through the device's hardware interfaces, collecting hardware operating data in real time, monitoring for hardware anomalies, and temporarily storing the collected raw data and anomaly information in a local cache or log file. The BMC provides data support for subsequent management operations. During the remote communication and command interaction phase, the BMC connects to the device management network through a network interface and establishes a stable communication link with the remote network management platform or management terminal based on standardized management protocols. On the one hand, the BMC can proactively report the collected hardware status data and abnormal alarm information to the network management platform to achieve remote visual monitoring of the device status. On the other hand, the BMC can receive remote management commands issued by the network management platform or management terminal, parse the commands and verify their permissions, and execute the corresponding operations after ensuring the legality of the commands, thereby achieving remote unmanned management of the devices. During the fault handling and maintenance phase, when the BMC detects device abnormalities through hardware monitoring, it judges the degree of abnormality based on the abnormal status and triggers the preset fault handling mechanism according to the degree of abnormality.

[0029] Furthermore, based on the above description, during its startup initialization phase, the BMC needs to complete self-checks and function activation of its own hardware modules to ensure that the basic hardware can operate normally, read the device's local basic configuration information, build the basic management environment based on the basic configuration information, establish communication links with electronic device hardware, and load the built-in communication links. Since establishing a remote file system access entry requires extracting remote access parameters from the FPGA's onboard non-volatile memory, this extraction must be performed after the BMC completes its own basic configuration to ensure that it has the hardware interface driver capability for parameter reading. At the same time, the access entry is a prerequisite for subsequently reading the verification benchmark value and obtaining the benchmark firmware. It needs to be built before the BMC performs other hardware monitoring or management operations to avoid subsequent processes being interrupted due to the lack of remote resource access, and to ensure that the FPGA firmware detection and repair process can be started first.

[0030] Furthermore, after completing its basic initialization at startup, the BMC establishes a communication connection with the non-volatile memory on the FPGA board through the hardware interface of the electronic device. It sends data read commands according to the interface protocol timing, locates the pre-stored configuration file in the non-volatile memory, and extracts the access parameters of the remote file system from the configuration file. The remote access parameters include at least connection basic information, authorization authentication information, and resource location information. Connection basic information may include remote file system type identifier, remote server address, communication port number, and local mount point path, etc. Authorization authentication information may include username / password, key file path, etc. Resource location information may include file storage path, metadata file identifier, etc. Based on the remote access parameters, the BMC completes the mounting configuration of the remote file system and the local electronic device through the network protocol, mapping the remote file system to a locally accessible directory path, which is the access entry point of the remote file system.

[0031] Furthermore, the remote file system access timing is set at the BMC startup time. BMC startup is independent of the host operating system and unaffected by the host OS's running state. The remote file system refers to a file system that centrally stores data, connected to the electronic device via a network, independent of the local storage of the electronic device managed by the BMC. Remote access parameters are retrieved from the onboard non-volatile memory after the BMC completes its hardware and basic function initialization. These parameters are extracted from a configuration file pre-stored in the onboard non-volatile memory. This configuration file is written to the BMC's local non-volatile memory by maintenance personnel or the device manufacturer using a preset method before BMC deployment or device shipment. Each subsequent BMC startup only needs to read parameters from this pre-stored file, without relying on external real-time transmission. Extracting parameters from the local configuration file ensures speed and stability of parameter acquisition, avoiding parameter loss due to network transmission delays or failures. Establishing a local access entry point localizes remote firmware resources, allowing the BMC to avoid repeatedly initiating remote connection requests when reading verification baseline values ​​or obtaining repair firmware, thus reducing network dependence.

[0032] Furthermore, during its startup, the BMC (Baseboard Management Controller) mounts the remote file system to the local device using the acquired remote access parameters, creating a directly accessible local directory entry. Mounting the remote file system means that the BMC, through specific technical operations, maps the remote file system, originally stored on a remote server, to a directly accessible virtual directory or local path on the managed electronic device. After mounting, the BMC can access the remote file system as quickly and conveniently as accessing a file directory stored locally on the electronic device. In this way, the BMC can independently read data from the remote file system without relying on the host operating system, providing a stable and centralized data source for subsequent firmware verification and automatic repair. It also enables unified management of verification benchmark values ​​and benchmark firmware files, reducing version maintenance costs in multi-device scenarios.

[0033] Furthermore, after BMC completes the entire process of mounting the local directory and confirms that the remote file system has been successfully mapped as the local access entry, BMC does not need to stay at this step. It will automatically enter the subsequent process, read the verification baseline value from the mounted remote file system, and the established access entry will be retained for reuse in subsequent operations such as reading the baseline firmware and downloading upgrade packages, until BMC restarts again or receives a manual unmount command.

[0034] Furthermore, the steps for the BMC to establish a remote file system access point locally on the BMC-managed electronic device based on the remote access parameters include:

[0035] (1) After the BMC starts, read the configuration file of the non-volatile memory in the FPGA and extract the access parameters of the remote file system from the configuration file;

[0036] Specifically, the BMC establishes a communication connection with the non-volatile memory in the FPGA through the hardware interface on the electronic device, sends data read commands according to the interface protocol timing, and locates the storage address of the pre-stored configuration file in the memory; it reads the complete content of the configuration file segment by segment, and extracts the access parameters of the remote file system from the configuration file through the built-in parsing logic. The access parameters are preset structured data, which usually contain core content such as the IP address of the server where the remote file system is located, the communication port number, the authentication information (such as username, password or key), and the storage path of the target file. After extraction, the data is temporarily stored in the local cache of the BMC.

[0037] Furthermore, the configuration file is stored in the FPGA's non-volatile memory, rather than the BMC's own storage medium. This allows for independent management of access parameters and the BMC; when the remote file system address or authentication information changes, only the configuration file in this memory needs to be updated, without requiring a firmware upgrade to the BMC. On the other hand, the FPGA's non-volatile memory and the BMC are directly connected via a hardware interface, resulting in fast data read speeds unaffected by the host operating system. Even if the host OS is not running, the BMC can still stably extract parameters, ensuring the independence of subsequent operations. It should be noted that when the BMC reads remote access parameters, it is only affected by hardware-related faults in the FPGA's non-volatile memory and the BMC itself, and is unaffected by faults in other host hardware or the host operating system. Whether it's a host OS crash, blue screen, inability to boot, or a host-level fault such as a PCIe link disconnection, it will not interfere with the direct hardware connection communication between the BMC and the FPGA's non-volatile memory. The BMC can still send read commands and locate the configuration file normally. The system reads remote access parameters from the memory address. If the local fault is a hardware failure unrelated to the communication link between the BMC and the FPGA non-volatile memory, such as a CPU, memory, or local hard drive failure, the BMC's parameter reading operation relies solely on its own hardware and the FPGA non-volatile memory, without needing to access host CPU, memory, or other resources. Therefore, such faults will not affect the BMC's reading of remote access parameters. Furthermore, when the BMC reads remote access parameters, it is only affected by faults in the power supply circuits of the BMC and the FPGA non-volatile memory, and is not affected by faults in other circuits of the host main power supply. In other words, even if the host main power supply fails, as long as the independent power supply circuits of the BMC and the FPGA non-volatile memory are normal, the BMC can still start normally and read the configuration file and extract parameters from the memory through the hardware interface. However, if a local power supply failure causes the BMC power supply circuit to be interrupted, or the FPGA non-volatile memory power supply circuit to be disconnected, the BMC will not be able to start or establish communication with the memory, and will not be able to read remote access parameters. The BMC reads the configuration file of the non-volatile memory in the FPGA through a hardware interface. This ensures the timeliness and stability of the BMC's acquisition of remote access parameters, avoiding the inability to access the remote file system due to missing parameters or acquisition failures. At the same time, direct reading through the hardware interface breaks the dependence on the host OS, laying a reliable data foundation for subsequent remote file system mounting and reducing the maintenance cost of parameter updates.

[0038] (2) The BMC initializes the remote file system through the configuration file and mounts the remote file system to the local directory, using the mount point as the access point.

[0039] Specifically, the BMC calls the built-in remote file system initialization module. Based on the protocol type in the access parameters, such as NFS or CIFS, it loads the corresponding communication driver, verifies the connectivity of the remote server's IP address and port, and completes permission verification with the remote file system through authentication information to ensure that the BMC has read and write permissions to access the file system. After successful initialization, the BMC specifies a fixed directory path, i.e., a local directory, on the electronic device it manages. It then uses a mount command to establish an association between the remote file system and the local directory, so that all resources of the remote file system can be mapped to the local directory. This local directory is set as the access entry point for the remote file system, and all subsequent operations of the BMC on the remote file system are implemented by accessing this local directory.

[0040] Furthermore, the core of the initialization process is to establish an effective communication link between the BMC and the remote file system. The permission verification process can prevent unauthorized devices from accessing the remote file system and ensure data security. Mounting to the local directory is essentially a local mapping of remote resources, transforming complex remote network access into simple local directory operations. This allows the BMC to operate on the specified directory as if it were a local file, without having to re-initiate a network connection and enter authentication information every time it accesses a remote file, thus indirectly calling remote resources and simplifying the operation logic.

[0041] Without relying on the host operating system, even if the host OS crashes or the PCIe link is disconnected, the BMC can still independently complete parameter extraction and remote connection establishment, breaking the dependence of traditional solutions on the host state. At the same time, the access parameters are stored in the FPGA's non-volatile memory with strong anti-interference capabilities, resulting in a low bit error rate during the extraction process. In addition, the initialization phase includes connectivity verification and permission verification, which can eliminate connection anomalies in advance and ensure the stability of remote resource access. Furthermore, the parameter extraction and mounting are completed during the BMC startup phase, and subsequent access to remote resources does not require repeated connection initiation, shortening data acquisition time. Parameter updates only require modifying the configuration file in the FPGA's non-volatile memory, without adjusting the BMC on a per-unit basis, significantly reducing operation and maintenance costs and providing efficient and reliable pre-emptive protection for subsequent FPGA firmware verification and repair.

[0042] S102, The BMC reads the verification base value from the remote file system mounted locally.

[0043] Specifically, BMC accesses the pre-stored verification benchmark file in the remote file system through the established access point. The verification benchmark file is uploaded in advance by the maintenance personnel and contains standard verification data (such as hash value and CRC value) that matches the target FPGA firmware. During the reading process, BMC performs integrity verification on the benchmark file, such as simple length verification and format verification, to ensure that the read benchmark value is not damaged due to network transmission or storage problems. Then, the verification benchmark value is temporarily stored in the BMC's local cache for easy retrieval in subsequent comparison operations.

[0044] Furthermore, the verification baseline value is stored in a remote file system rather than on a local device, which enables centralized management and unified updating of the baseline value. When the FPGA firmware version is iterated, only the baseline value file needs to be updated on the remote end, without having to modify the local configuration of each electronic device, thus reducing version management costs. The secondary verification during BMC reading can avoid deviations in subsequent verification results due to incorrect baseline values, ensuring the accuracy of the verification logic.

[0045] Furthermore, in FPGA firmware version iteration scenarios, after the equipment maintenance personnel complete the development, testing, and verification of the new generation FPGA benchmark firmware, they will first upload the new generation FPGA benchmark firmware to a designated directory in the remote file system. Based on the new generation FPGA benchmark firmware, the corresponding benchmark check value is regenerated using a hash algorithm consistent with the BMC's check value calculation, and the benchmark version number is updated synchronously. The maintenance personnel then use the remote file system's management interface or automated scripts to replace the old version of the check benchmark value stored in the remote file system with the new version of the check benchmark value, completing the update of the check benchmark value. Subsequently, the BMC reads the check benchmark value from the remote file system. The system automatically updates to the new verification baseline value without requiring local configuration modifications on each electronic device. In scenarios involving abnormal baseline value correction, if errors are found in the verification baseline value stored in the remote file system during maintenance, or if the baseline value file is corrupted due to abnormal data storage in the remote file system, maintenance personnel will first locate the storage path of the erroneous baseline value, calculate the compliant baseline verification value based on the correct baseline firmware, confirm the correct baseline version number, and overwrite the erroneous baseline value file or repair the corrupted file using the remote file system management tool. This achieves immediate correction and update of the verification baseline value, and subsequent read operations by the BMC can directly obtain the corrected baseline value, ensuring the accuracy of the verification logic.

[0046] This achieves centralized and standardized management of verification benchmark values, reducing the workload of manually configuring benchmark values ​​for each device; at the same time, the integrity verification during benchmark value reading improves the reliability of the verification logic and avoids the problem of misjudging firmware damage due to incorrect benchmark values.

[0047] Optionally, the verification baseline value includes the baseline verification value and baseline version number of the remote file system, and the verification result includes the integrity verification result and the version consistency verification result. When the verification value is inconsistent with the baseline verification value, the integrity verification result is determined to be a failure. When the current version number is inconsistent with the baseline version number, the version consistency verification result is determined to be a failure.

[0048] Specifically, the verification baseline value includes the baseline verification value and baseline version number of the remote file system. The verification result corresponds to the integrity verification result and the version consistency verification result, and the success or failure of the verification is determined by comparing the values. This is a refinement and improvement of the FPGA firmware status detection dimension. The verification baseline value is standard reference data stored in the remote file system, consisting of two parts: the baseline verification value and the baseline version number. These two parts correspond to the detection requirements of the FPGA firmware's integrity and version compliance, respectively. The baseline verification value is a standard integrity identifier in the remote file system that matches the target FPGA firmware. It is usually generated by hashing complete and correct baseline FPGA firmware data using hash algorithms such as SHA-256 and CRC32. Its value is unique and fixed, meaning that as long as the baseline firmware data remains unchanged, the baseline verification value will not change, accurately reflecting the integrity status of the firmware data. The baseline version number is a standard version identifier pre-stored in the remote file system, set by the maintenance personnel according to the iterative update of the FPGA firmware. It corresponds one-to-one with the baseline verification value and is used to determine the firmware version that should be loaded on the current device, ensuring the compatibility of the firmware with the hardware and software environment.

[0049] Furthermore, the BMC first reads the actual data of the FPGA firmware through the hardware interface and calculates the current check value using the same algorithm as the one used to generate the baseline check value. Then, it compares the current check value with the baseline check value read from the remote file system at the byte level. If they are completely identical, it indicates that the FPGA firmware data has not experienced bit flips, region corruption, or other issues, and the integrity check result is successful. If any byte difference exists, it indicates that the firmware data is corrupted, the integrity check result is failed, and the firmware repair process needs to be triggered. The BMC extracts the current version number from the FPGA firmware data. The current version number is usually stored in a specified field of the firmware data, such as the header version information area. Then, it compares the current version number with the baseline version number from the remote file system character by character. If they are completely identical, it indicates that the firmware version meets the maintenance requirements, and the version consistency check result is successful. If they are inconsistent, such as the current version being V1.0.1 and the baseline version being V2.1.0, the version consistency check result is determined to be failed, and the firmware upgrade process needs to be triggered. The two verification results are independent of each other and can be judged simultaneously, such as when the firmware is both damaged and outdated. Alternatively, they can be judged separately, such as when the firmware is complete but outdated. This ensures that BMC can accurately identify the specific problem type of the firmware and avoid a one-size-fits-all approach to repair.

[0050] S103. The BMC obtains the firmware data stored in the FPGA firmware based on the hardware interface of the electronic device, and calculates the verification value based on the firmware data.

[0051] Specifically, the BMC, as an independent hardware management module, is integrated and deployed on the motherboard of the electronic device. It is the core management unit of the electronic device's hardware system. Its power supply and communication rely on the hardware architecture of the electronic device itself. It can directly interact with various hardware components on the motherboard of the electronic device. The hardware interface between the BMC and the non-volatile memory storing the FPGA firmware in the electronic device is a permanent hardware connection preset at the factory. The hardware interface maintains a physical connection state throughout the normal operation cycle of the electronic device. It is used for the BMC to quickly inspect the initial state of the FPGA firmware during the power-on self-test phase of the electronic device, and for the BMC to periodically monitor the health status of the firmware storage medium during normal operation of the FPGA firmware. It is only used during physical disassembly and hardware maintenance of the electronic device. The connection is only disconnected in extreme scenarios such as repair. After the task is completed, there is no need to actively disconnect it to ensure the BMC's continued management needs of the FPGA firmware. Furthermore, the BMC and FPGA on the electronic device motherboard are usually configured with only one dedicated hardware interface. The hardware interface is a standardized interface that is pre-determined during the electronic device design stage according to the FPGA model and BMC chip specifications. Its hardware address and communication timing parameters are already fixed in the BMC's underlying driver. The BMC will directly call the control logic corresponding to the hardware interface in the built-in driver, locate and activate the interface connected to the FPGA firmware memory through the fixed hardware address, without the need to scan or select other interfaces. This ensures the accuracy and uniqueness of each data read and avoids data acquisition failure due to incorrect interface selection.

[0052] Specifically, the BMC identifies the type of hardware interface on the electronic device that connects to the FPGA firmware storage medium. Through this interface, it sends data read commands to the storage medium, reading the complete FPGA firmware data byte-by-byte or in blocks according to the interface protocol timing. After reading, the BMC calls its built-in verification algorithm to perform a full operation on the acquired firmware data, generating a fixed-length string, which is the verification value of the current FPGA firmware. The FPGA firmware data includes logic configuration data, parameter configuration data, and version and identification information. The logic configuration data is circuit logic information compiled from a hardware description language, used to define the connection relationships of internal FPGA hardware resources such as programmable logic units, input / output units, and digital signal processing units. Operating mode; parameter configuration data includes basic parameters for FPGA operation, such as clock frequency, I / O port level standards, interrupt trigger conditions, and interaction configuration information with other hardware in electronic devices, ensuring that the FPGA can adapt to the overall hardware environment of the electronic device; version and identification information includes metadata such as firmware version number, compilation time, compatible FPGA model, and verification identifier, used by the BMC to identify firmware version compliance and hardware compatibility; the first writing of FPGA firmware data occurs during the electronic device manufacturing stage. Before the device leaves the factory, the manufacturer connects to the FPGA's debugging interface using a dedicated programming tool to burn the verified initial baseline firmware data to the onboard non-volatile memory, completing the basic adaptation between the FPGA and the electronic device hardware.

[0053] Furthermore, once the equipment maintenance team completes the functional iteration or vulnerability fix of the FPGA firmware, it will upload the verified new firmware to the remote file system and simultaneously update the corresponding verification baseline value and baseline version number. When the electronic device starts up, the BMC reads the new baseline version number from the remote file system and compares it with the current firmware version number of the FPGA. If the versions are inconsistent, the old firmware data in the non-volatile memory will be updated to the new version data. In addition, if hidden defects are found in the FPGA firmware of a specific batch of devices during routine maintenance, the maintenance team will also release targeted repair firmware, update the baseline resources through the remote file system, and the BMC will automatically update the firmware data on the device side.

[0054] Furthermore, the hardware interface directly connects to the firmware storage medium. Compared to indirectly reading data through the host OS, this bypasses the intermediate links of the OS driver layer and application layer, avoiding data read failures or data tampering caused by intermediate link failures. It uses full data computation to generate checksums, rather than sampling verification, covering every byte of the firmware. This allows for accurate identification of hidden corruption such as bit flips in certain areas, avoiding misjudgments caused by sampling omissions. This achieves direct and accurate reading of FPGA firmware data, ensuring consistency between the acquired firmware data and the actual stored data. The checksums generated by full computation comprehensively reflect firmware integrity, enabling earlier and more accurate detection of firmware corruption compared to traditional heartbeat mechanisms that only determine FPGA liveness.

[0055] Furthermore, the specific implementation steps for calculating the verification value based on the firmware data include:

[0056] (1) The BMC establishes a data communication connection with the non-volatile memory storing the FPGA firmware through the SPI hardware interface, and reads the FPGA firmware data stored in the non-volatile memory according to the SPI protocol timing.

[0057] Specifically, the BMC identifies the SPI hardware interface on the electronic device connected to the FPGA firmware storage medium. It sends a chip select signal to the memory through this interface to activate the target memory chip, adhering to the timing specifications defined by the SPI protocol. This timing includes the frequency of the clock signal SCK, the data transmission direction, and the byte transmission order. The SPI protocol timing is a prerequisite for ensuring the accuracy of data reading between the BMC and the FPGA firmware non-volatile memory. If the timing parameters do not match, the memory may not be able to correctly parse the read command sent by the BMC, or the BMC may not be able to accurately receive the firmware data returned by the memory, leading to read failures or errors / missing bits in the read data. This, in turn, causes deviations in subsequent checksum calculations, affecting the accuracy of firmware corruption detection results. Timing conforming to the protocol standard... The sequential configuration ensures that instruction interaction and data transmission between the BMC and the memory are executed synchronously according to preset logic, avoiding communication anomalies caused by asynchronous timing and guaranteeing the full and error-free reading of firmware data. During the reading process, the BMC confirms the clock signal frequency parameters, data transmission direction parameters, and byte transmission order parameters through the SPI protocol timing, and sends the read command and the starting address of the target data to the non-volatile memory. After receiving the read command, the non-volatile memory outputs the complete FPGA firmware data byte by byte or block by block starting from the specified address. The complete data includes the firmware program code, configuration parameters, version information, and other full content. The BMC receives the data through the MISO pin of the SPI interface and temporarily stores it in the local cache to ensure that there is no data loss during the data transmission process.

[0058] The SPI interface, as a high-speed synchronous serial communication interface, features full-duplex communication, high transmission rate, and strong anti-interference capabilities. It is suitable for data transmission between short-distance hardware devices. The length of data read by the SPI interface is mainly constrained by the non-volatile memory storing the FPGA firmware and the buffering and data processing capabilities of the BMC itself. If the FPGA firmware data is too long, a block-based reading combined with data concatenation is used to read the FPGA firmware data. The BMC divides the complete firmware data into several fixed-size blocks according to the firmware data storage address in the non-volatile memory, and determines the start and end addresses of each block. The BMC initiates a read request block by block through the SPI interface. After each block of data is read, it is immediately temporarily stored in the local buffer and the block number is marked, while the data block is released. The corresponding cache space is called upon when the full data is assembled later. After all block data has been read, the BMC assembles the data into complete firmware data according to the block sequence number and the original storage order. This ensures that the assembled data is completely consistent with the firmware data stored in the memory, meeting the requirements for subsequent calculation of checksums based on the full data. This avoids the hardware and software capability mismatch problem caused by excessively long single reads and ensures the integrity of the firmware data. The BMC is directly connected to the non-volatile memory in hardware, without going through intermediate links such as the host operating system and PCIe link. It can directly obtain the original firmware data, avoiding data read failures or tampering caused by intermediate layer failures. At the same time, it strictly follows the SPI protocol timing transmission, which can ensure the accuracy of data reading and writing and reduce transmission error problems caused by timing mismatch.

[0059] (2) Perform a hash operation on the FPGA firmware data based on the hash algorithm to generate a fixed-length string, and use the string as the verification value of the FPGA firmware data.

[0060] Specifically, the BMC retrieves the complete FPGA firmware data from its local cache, calls the built-in hash algorithm module, which can include standardized algorithms such as SHA-256 and CRC32, and performs a full hash operation on the firmware data. The hash algorithm iterates through every byte of the firmware data and converts firmware data of arbitrary length into a fixed-length string through specific mathematical logic. For example, SHA-256 generates a 64-bit hexadecimal string. After the operation is completed, the BMC defines this fixed-length string as the checksum of the current FPGA firmware data and temporarily stores it locally for later comparison with the benchmark checksum in the remote file system.

[0061] Furthermore, after retrieving the FPGA firmware data, data integrity preprocessing is performed. Based on the generation algorithm type of the verification benchmark value in the remote file system, the corresponding built-in hash algorithm module is matched and activated. If the firmware data length exceeds the single processing limit of the hash algorithm module, the BMC evenly divides the preprocessed firmware data according to the maximum block size supported by the algorithm module, generating an ordered data block sequence and marking the block number. Data blocks are sequentially input into the hash algorithm module according to their block numbers. After each data block is processed, the algorithm module outputs an intermediate hash value and temporarily stores it in the BMC's temporary computation cache. When the next data block is input, the module continues the computation based on the intermediate hash value of the previous block until all data blocks have been calculated. The hash algorithm module outputs the final raw hash result. The BMC calls the format conversion module to convert the binary raw hash result into a standardized hexadecimal string, ensuring that the format is consistent with the benchmark verification value in the remote file system. The BMC marks the standardized string as the current FPGA firmware verification value, stores it in the local verification result cache, and associates it with metadata such as generation time and algorithm type used, preparing for subsequent comparison with the benchmark verification value.

[0062] Hash algorithms possess two core characteristics: uniqueness and irreversibility. Firstly, any minute change in the FPGA firmware data (such as a bit flip in a single byte or partial data corruption) will result in a completely different hash value, accurately identifying firmware data integrity anomalies. Secondly, the original firmware data cannot be deduced from the hash value, ensuring firmware data security. Furthermore, the fixed-length hash value facilitates storage and transmission, simplifying subsequent comparisons with benchmark values; only a fixed-length string needs to be compared, eliminating the need to compare massive amounts of original firmware data. This allows for quantitative detection of FPGA firmware integrity. Compared to traditional sampling verification or heartbeat mechanisms, full hashing covers every byte of firmware data, preventing missed detections of hidden corruption due to sampling omissions. The uniqueness and fixed length of the hash value ensure the accuracy of the verification results and improve the efficiency of subsequent verification comparisons, providing a clear and objective basis for quickly determining whether the firmware is corrupted.

[0063] S104. Compare the verification benchmark value and the verification value to determine the verification result.

[0064] Specifically, the BMC retrieves the verification baseline value from the local cache and compares it byte-by-byte with the calculated current firmware verification value. If the two are completely identical, the verification result is determined to be that the firmware is complete and undamaged, requiring no further repair operations. If there is any difference between the two, the verification result is determined to be that the firmware is damaged or the version is incompatible, triggering an automatic repair process. At the same time, the BMC records the comparison process and results, such as the position of the difference bytes and the comparison time, and stores them in the local log for easy traceability in subsequent operations and maintenance.

[0065] Furthermore, byte-level comparison is crucial for ensuring verification accuracy, eliminating misjudgments caused by approximate matching. Verification results are directly linked to subsequent repair operations, avoiding subjective biases from manual judgment through explicit consistency or inconsistency determination logic. Log recording provides a basis for fault tracing, facilitating maintenance personnel to analyze the frequency and timing patterns of firmware corruption and investigate common problems. Objective and precise comparison logic clarifies firmware status, preventing missed or incorrect damage detections. The logging function enhances the traceability of fault management and provides data support for equipment maintenance optimization.

[0066] S105. Automatically repair the FPGA firmware based on the verification result.

[0067] Specifically, when the verification result indicates firmware corruption or version mismatch, the BMC reads the verification baseline value from the remote file system. The verification baseline value includes a baseline checksum and a baseline version number, which are one-to-one correspondences. The baseline checksum is generated by the baseline firmware version using a specified hash algorithm. The BMC retrieves the locally calculated current firmware checksum and simultaneously extracts the current version number from the specified metadata area of ​​the current FPGA firmware data. The current firmware checksum is compared with the baseline checksum. If they are inconsistent, the current version number is further verified against the baseline version number. If the current version number matches the baseline version number, it indicates that although the current firmware is the correct version, the data has experienced bit flipping due to storage media degradation, power fluctuations, etc. If the firmware is corrupted or the region is damaged, it is determined to be firmware corruption. If the current version number is inconsistent with the base version number, and the base checksum corresponding to the current version number is confirmed by searching the remote file system, and the current firmware checksum is found to be consistent with the base checksum corresponding to the current version number, it means that the current firmware data is complete but the version is behind or ahead of the target base version, and it is determined to be a version mismatch. If the current firmware checksum is inconsistent with both the base checksum and the base checksum corresponding to the current version number, it is determined to be firmware corruption and version mismatch. The firmware corruption trigger repair process is prioritized. After the firmware data is fully restored, the version consistency is checked again to confirm whether further upgrade is needed.

[0068] Furthermore, the BMC automatically triggers the repair process, downloads the complete benchmark FPGA firmware file corresponding to the verification benchmark value through the remote file system access entry, and temporarily stores it in the BMC's local memory; then the BMC sends control commands to the FPGA to put it into programming mode. At this time, the FPGA pauses its current operation and only receives firmware burning commands; finally, the benchmark firmware file in the local memory is written to the storage medium through the hardware interface, overwriting the original damaged firmware data, and the repair is completed.

[0069] Furthermore, obtaining the required baseline firmware file from a remote file system ensures a perfect match between the repair file and the verification baseline value, avoiding version mismatches. The firmware is temporarily stored in local memory; since memory read / write speeds are much higher than storage media, this accelerates the burning process and prevents file corruption due to storage media failure. Entering programming mode before burning the firmware prevents the FPGA from running the old program during the firmware writing process, which could lead to program conflicts or data writing errors. This enables automated repair of corrupted firmware, eliminating the need for on-site maintenance personnel, significantly shortening fault response time and reducing labor costs. Version matching and mode control during the repair process ensure that the repaired firmware runs normally, avoiding issues where the device remains unusable after repair and guaranteeing a rapid return to stable operation of electronic devices.

[0070] Furthermore, the specific steps for automatically repairing the FPGA firmware based on the verification results include:

[0071] (1) The BMC reads the benchmark FPGA firmware file corresponding to the verification benchmark value from the remote file system through the access entry, and temporarily stores the benchmark FPGA firmware file in the local memory of the BMC;

[0072] Specifically, through the previously established remote file system access point, the BMC locates the benchmark FPGA firmware file that uniquely corresponds to the verification benchmark value in the remote file system. The benchmark FPGA firmware file is a verified complete and correct version, fully compatible with the FPGA hardware and software environment. The BMC initiates a file read request through the mounted local directory, transferring the benchmark FPGA firmware file from the remote file system to the local machine in the form of a data stream, and temporarily storing it in its own local memory. During the temporary storage process, the BMC performs a simple integrity check on the file, such as checking whether the file size is consistent with the remote end and whether there is any file incompleteness caused by transmission interruption, to ensure that the temporarily stored benchmark firmware file is not damaged.

[0073] Choosing to read the baseline firmware file from a remote file system instead of relying on local storage enables centralized management and unified updates of the baseline firmware. When the FPGA firmware version iterates, only the baseline file needs to be replaced on the remote end, without having to update the local storage on each device, thus reducing version management costs. Temporarily storing the file in local memory instead of onboard storage takes advantage of the fact that memory read and write speeds are much faster than storage media, laying the foundation for rapid programming in the future. On the other hand, it avoids secondary damage to the baseline file caused by failure of onboard storage media, ensuring the reliability of the repair source file.

[0074] (2) The BMC controls the hardware interface of the electronic device to enable the FPGA to enter the programming mode, and burns the reference FPGA firmware file in the local memory to the non-volatile memory storing the FPGA firmware through the hardware interface, overwriting the original firmware data.

[0075] Specifically, the BMC sends a programming mode enable command to the FPGA through the hardware interface of the electronic device. This command triggers the control logic inside the FPGA, causing it to suspend all current business functions and switch to a programming mode that only receives firmware burning commands, thus avoiding conflicts between firmware data and business data during the burning process. Through the same hardware interface, the BMC divides the baseline FPGA firmware file temporarily stored in local memory into fixed block sizes and sends write commands to the non-volatile memory storing the FPGA firmware block by block, overwriting the original damaged firmware data with the baseline firmware data. During the burning process, the BMC provides real-time feedback on the writing status of each block of data, indicating success or failure. If a block fails to write, it is resent to ensure that all data is burned completely.

[0076] Entering programming mode is a prerequisite for successful firmware burning. During normal FPGA operation, its firmware storage area is in read-only mode to ensure service stability. Only by switching to programming mode will the storage area be unlocked and made writable, allowing new firmware data to overwrite existing data. Burning directly to non-volatile memory via the hardware interface bypasses intermediate steps such as the host operating system, avoiding burning interruptions caused by intermediate layer failures and ensuring that firmware data can be directly written to the storage medium without secondary forwarding, reducing the risk of data tampering or loss. Burning in blocks and verifying the write status in real time allows for timely detection and repair of anomalies during the burning process, preventing the entire firmware from becoming unusable due to a single block's data write failure. This enables automated repair of corrupted firmware, eliminating the need for manual burning via the JTAG interface by maintenance personnel, significantly shortening fault repair time and reducing manual maintenance costs. Mode switching before burning and real-time verification during burning ensure the safety and integrity of the burning process, preventing FPGA hardware damage or partial firmware corruption due to improper burning operations. Ultimately, this ensures that the repaired FPGA can load the complete firmware and restore service functionality.

[0077] Furthermore, the specific implementation steps for automatically repairing the FPGA firmware based on the verification results also include:

[0078] (1) The BMC rereads the firmware data in the non-volatile memory after burning through the hardware interface and calculates the verification value after burning;

[0079] Specifically, after completing the programming of the baseline FPGA firmware file, BMC will initiate a data read request to the non-volatile memory storing the FPGA firmware again through the same hardware interface as in the programming stage. During the reading process, it strictly follows the hardware interface protocol timing, reading the entire firmware data stored after programming from the start address to the end address of the memory to ensure that the complete data after programming is obtained. After the reading is completed, BMC calls the same hash algorithm as the first calculation of the checksum to perform a full calculation on the re-acquired firmware data to generate a fixed-length string. This string is the checksum after programming and is temporarily stored in the BMC's local cache for comparison.

[0080] Choosing the same hardware interface as the burning stage to read data eliminates the problem of data reading deviation caused by interface differences, ensuring that the acquired burned data can truly reflect the actual storage state in the memory; full reading instead of sampling reading can cover every byte of firmware, avoiding verification omissions due to partial data not being read; using the same hash algorithm as the initial calculation is a prerequisite for ensuring the comparability of verification values. Only when the algorithm is consistent can the same firmware data generate the same verification value, laying the foundation for subsequent comparison with the verification benchmark value.

[0081] (2) The BMC performs a second verification between the burned verification value and the verification benchmark value, and repairs the FPGA firmware based on the second verification result.

[0082] Specifically, the BMC retrieves the verification value after burning from the local cache, and at the same time retrieves the verification baseline value previously obtained from the remote file system, and performs a byte-by-byte comparison. If the two are completely consistent, the second verification result is determined to be successful, indicating that the burned firmware data is complete and consistent with the standard baseline, and the firmware repair is effective. If there is any byte difference between the two, the second verification result is determined to be a failure. The BMC automatically triggers the re-burning process, reads the corresponding baseline FPGA firmware file from the remote file system again, repeats the operation of temporary storage in memory - controlling the FPGA to enter programming mode - overwrite burning, and executes the reading and verification value calculation in step (1) again after burning is completed, until the second verification result is consistent. If the verification still fails after multiple re-burnings, the BMC will record the fault information, such as the number of failures and the failure time, and trigger the alarm mechanism to prompt manual intervention for troubleshooting.

[0083] The hardware interface allows for direct reading of the programmed data, accurately reflecting the actual storage status of the firmware. Combined with the same algorithm used in the initial verification, the verification value is calculated to ensure accurate data comparison. Secondary verification compares the programmed verification value with a standard baseline value, precisely identifying hidden data deficiencies caused by electromagnetic interference or bad blocks in the memory during the programming process. This avoids the hidden danger of incomplete firmware despite no errors reported during programming. Furthermore, automatic reprogramming is triggered when verification fails, and successful reprogramming confirms effective repair, forming a complete closed loop from programming to repair. This significantly improves firmware repair reliability, reduces manual intervention due to occasional problems, and records and alarms after multiple failures, providing a basis for hardware fault diagnosis and ensuring stable loading and expected functionality of the repaired FPGA firmware.

[0084] Furthermore, BMC performs a secondary verification between the programmed verification value and the verification benchmark value. The specific implementation steps for repairing the FPGA firmware based on the secondary verification result include:

[0085] 2.1 Compare the verified value after burning with the verified baseline value. If the results of the two verifications are consistent, the repair is considered successful; if the results of the two verifications are inconsistent, the burning process is repeated.

[0086] Specifically, the BMC first retrieves the post-burning verification value calculated from the previously re-read and burned firmware data, and compares it byte-by-byte with the verification baseline value obtained from the remote file system. If there is no difference between the two, the firmware repair is directly determined to be successful, and the repair process ends. If any byte mismatch exists, the secondary verification is determined to have failed. Without manual triggering, the BMC automatically repeats the complete burning process from reading the corresponding baseline FPGA firmware file from the remote file system to overwriting and burning it to the non-volatile memory. After burning is completed, the operation of re-reading the firmware data and performing a secondary comparison is performed again until the two verification values ​​are completely consistent.

[0087] During the flashing process, occasional factors such as transient electromagnetic interference and single read / write deviations of non-volatile memory may cause firmware data to be written but have hidden defects. Such problems cannot be identified by simply relying on the absence of error reports during the flashing process. The automatic re-flashing mechanism can specifically solve such verification failures caused by non-hardware faults, avoid triggering manual intervention due to single occasional problems, and balance repair efficiency and reliability.

[0088] 2.2 After determining that the repair is successful, the BMC controls the FPGA to power on again, and the FPGA loads the burned-in reference FPGA firmware.

[0089] Specifically, after confirming the secondary verification is successful and the repair is deemed complete, the BMC, through its hardware control interface connected to the FPGA, sends a power-on command to the FPGA, triggering a hardware reset process. After resetting, the FPGA follows the default startup logic, reading the newly programmed baseline FPGA firmware data from non-volatile memory to complete firmware loading and initialization. It then enters normal operating mode, resuming preset functions such as data processing and protocol conversion. During normal FPGA operation, the loaded firmware resides in an internal cache. Without a restart, even if the firmware in the non-volatile memory is updated, the FPGA will still use the old firmware data in the cache, rendering the new firmware ineffective. The BMC's proactive restart control ensures timely firmware loading, preventing the disconnect between successful repair and unupdated functionality.

[0090] By performing secondary verification and automatic reprogramming, the integrity and correctness of firmware repair are ensured from the data level; by controlling the FPGA restart and loading through BMC, the new firmware is ensured to take effect in a timely manner from the functional level. The combination of the two completely solves the problems of incomplete repair and failure to update functions after repair, greatly improving the reliability and efficiency of FPGA firmware repair, while minimizing manual intervention and providing key guarantees for the continuous and stable operation of electronic devices.

[0091] In addition, the implementation steps for automatically repairing the FPGA firmware based on the verification results also include:

[0092] (1) When the verification result is that the versions are inconsistent, the BMC downloads the FPGA upgrade firmware package that matches the base version number from the remote file system through the access entry;

[0093] Specifically, when the verification result indicates a version mismatch—that is, the current firmware version number of the FPGA does not match the base version number in the remote file system—the BMC directly accesses the remote file system entry point, retrieves the pre-stored firmware resource library on the remote end based on the base version number, and locates the FPGA upgrade firmware package uniquely corresponding to that base version number. The FPGA upgrade firmware package contains complete base firmware files, version documentation, and verification information. The BMC initiates a file download request, transmitting the upgrade firmware package as a data stream to its local memory for temporary storage. During the download process, the integrity of the firmware package is simultaneously verified to ensure that the downloaded upgrade firmware package is not damaged or missing due to network transmission. The upgrade firmware package is stored in the remote file system and bound to the base version number. On the one hand, this achieves centralized management of firmware versions; maintenance personnel only need to maintain firmware resources by version on the remote end, without needing to update the local firmware library for each device. On the other hand, the BMC's precise version number matching during download avoids version mismatch issues, ensuring that the downloaded upgrade firmware package is fully compatible with the target FPGA's hardware model and software environment, and preventing device malfunctions caused by firmware version incompatibility.

[0094] (2) The BMC calls the upgrade script, controls the hardware interface of the electronic device to make the FPGA enter the upgrade mode, erases the specified partition of the non-volatile memory storing the current firmware through the hardware interface, and writes the base firmware file in the FPGA upgrade firmware package in blocks.

[0095] Specifically, the BMC calls the built-in upgrade script, which is pre-stored locally on the BMC and contains a standardized process script including FPGA upgrade mode activation instructions, memory partition erasure logic, and firmware write timing control. The script sends an upgrade mode enable signal to the FPGA through the electronic device's hardware interface, causing the FPGA to suspend its current business functions and switch to a dedicated mode that only receives upgrade instructions, avoiding conflicts between business data and firmware data during the upgrade process. The script controls the hardware interface to perform an erase operation on the designated partition of the non-volatile memory storing the current firmware, clearing the old version firmware data. After erasure, the BMC writes the base firmware file from the upgrade firmware package in local memory to the designated memory partition block by block, according to the block size set in the upgrade script. During the writing process, the script monitors the writing status of each block in real time. If a block writing fails, a retry mechanism is triggered to ensure that all data is written completely.

[0096] By ensuring the compliance of firmware upgrades through remote version matching and downloading, and by automating and securing the upgrade process through scripted control, the system solves the problems of low efficiency and version mismatch in traditional manual upgrades, while also ensuring the stability and data security of the upgrade process. Ultimately, this achieves efficient and compliant updates of FPGA firmware versions, improving the overall compatibility and operational stability of the device.

[0097] Furthermore, after automatically repairing the FPGA firmware based on the verification results, the method provided in this embodiment also includes:

[0098] (1) The BMC collects information from the automatic repair process and generates a repair report;

[0099] Specifically, in the automated repair process, BMC collects full operation information in real time at each key node, including firmware verification, remote file reading, flashing, and secondary verification. This information includes: the reason for the repair (such as integrity verification failure, version inconsistency), operation time (verification start time, flashing start time, repair completion time), core operation data (remote file system address, base version number, verification value comparison result, flashing count), and process status (success / failure, failure reason such as exceeding the flashing retry limit). After collection, BMC organizes the information according to a preset format (such as structured text format, JSON format) to generate a complete repair report containing the repair object (device identifier, FPGA model), repair process, and repair result. The report is also temporarily stored in BMC's local storage to avoid data loss.

[0100] (2) The BMC reports the repair report to the network management platform based on the management protocol.

[0101] Specifically, after generating a repair report, the built-in communication module is automatically invoked to establish a communication connection with the remote network management platform based on standardized management protocols such as IPMI, SNMP, and Redfish. After the connection is established, the structured repair report is encapsulated into compliant data frames according to the data packet format specified in the protocol and sent to the network management platform through the device network interface. During the reporting process, the BMC will listen for the platform's reception feedback signal. If no feedback is received or a reception failure signal is received, a retransmission mechanism will be automatically triggered (e.g., retrying every 30 seconds, with a maximum of 3 retries). If the retransmission still fails, the BMC will record the reporting failure status in the local log and trigger a local alarm (e.g., lighting up the device alarm indicator light) to prompt maintenance personnel to investigate network or platform issues.

[0102] Full-node information collection and structured report generation ensure that the repair process is traceable and analyzable; standardized protocol reporting and retransmission mechanisms ensure that reports can be stably delivered to the network management platform, enabling centralized monitoring of the repair status of multiple devices; ultimately, it not only solves the black-box operation problem of traditional firmware repair, but also improves the efficiency and precision of large-scale equipment operation and maintenance, providing operation and maintenance support for the long-term stable operation of electronic equipment.

[0103] The FPGA firmware corruption detection method provided in this embodiment optimizes the FPGA firmware management process from multiple dimensions, including reliability, automation, accuracy, and operational efficiency. Relying on the BMC to independently execute the entire process, it extracts remote access parameters from the FPGA's non-volatile memory at startup and establishes a local access entry point to the remote file system. It is completely independent of the host operating system. Even if the host OS crashes or the PCIe link is disconnected, it can still stably access remote resources, avoiding the failure problem of traditional OS-level detection. This solves the pain point of existing detection methods that rely on the host OS failing at the most critical moment, laying a stable foundation for subsequent operations. The BMC directly reads the full data of the FPGA firmware through a hardware interface, generates a checksum using a hash algorithm, and compares it with the baseline checksum and version number of the remote file system. It does not simply check if the FPGA is frozen, but delves into its storage medium to verify the firmware binary content itself. This capability enables the detection of bit flip errors that have not yet caused complete functional interruption, achieving precise and proactive fault detection. It shifts from post-fault handling to immediate damage management, accurately identifying hidden issues such as firmware bit flips and regional corruption, while also determining version compliance. This overcomes the limitations of traditional heartbeat mechanisms, which can only determine FPGA viability and where manual inspection may miss potential problems. In terms of automated repair and closed-loop management, when an anomaly is detected, the BMC automatically retrieves the matching firmware remotely, controls the FPGA to enter programming / upgrade mode to complete the flashing process, performs a second verification after flashing, and automatically retryes. Upon successful flashing, the FPGA restarts to load the new firmware, forming a closed loop of detection and effectiveness. This eliminates the need for manual on-site operation, significantly shortening fault response time and avoiding version mismatches and flashing errors. Centralized management of firmware and baseline values ​​is achieved through a remote file system. Repair process information is collected in real-time and reports are generated, which are then reported to the network management platform via protocols such as IPMI. This supports centralized monitoring of multiple device statuses and fault tracing, reducing the operational costs of large-scale data centers, ensuring the long-term stable operation of servers and storage devices, and meeting the requirements of high-availability scenarios.

[0104] Corresponding to the aforementioned embodiment of an FPGA firmware corruption detection method, this application also provides an embodiment of an FPGA firmware corruption detection device.

[0105] Figure 2 This is a schematic diagram of the structure of Embodiment 2 of the FPGA firmware corruption detection device provided in this application. Please refer to... Figure 2 The apparatus provided in this embodiment includes an establishment module 210, a reading module 220, and a verification module 230; wherein,

[0106] The establishment module 210 is used to obtain remote access parameters at the BMC startup time, and the BMC establishes a remote file system access entry locally on the electronic device managed by the BMC based on the remote access parameters.

[0107] The reading module 220 is used for the BMC to read the verification base value from the remote file system mounted locally;

[0108] The verification module 230 is used for the BMC to obtain firmware data stored in the FPGA firmware based on the hardware interface of the electronic device, and to calculate the verification value based on the firmware data.

[0109] The verification module 230 is also used to compare the verification benchmark value and the verification value to determine the verification result;

[0110] The verification module 230 is also used to automatically repair the FPGA firmware based on the verification result.

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

[0112] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0113] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device 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.

[0114] 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 method for detecting corrupted FPGA firmware, characterized in that, The method includes: At the time of BMC startup, remote access parameters are obtained. Based on the remote access parameters, BMC establishes an access entry point for the remote file system on the local electronic device managed by BMC. The remote file system is accessed at the time of BMC startup. BMC startup is independent of the host operating system. After BMC completes its own hardware and basic function initialization, it performs a read operation on the onboard non-volatile memory, extracts the remote access parameters from the configuration file pre-stored in the onboard non-volatile memory, and mounts the remote file system to the local electronic device to form a directory entry that can be directly accessed locally. The BMC reads the verification baseline value from the remote file system mounted locally; The BMC obtains the firmware data stored in the FPGA firmware based on the hardware interface of the electronic device, and calculates the verification value based on the firmware data. By comparing the benchmark value and the verification value, the verification result is determined. The FPGA firmware is automatically repaired based on the verification results.

2. The method according to claim 1, characterized in that, The automatic repair of the FPGA firmware based on the verification result includes: The BMC reads the benchmark FPGA firmware file corresponding to the verification benchmark value from the remote file system through the access entry, and temporarily stores the benchmark FPGA firmware file in the local memory of the BMC. The BMC controls the hardware interface of the electronic device to put the FPGA into programming mode. Through the hardware interface, the reference FPGA firmware file in the local memory is burned to the non-volatile memory storing the FPGA firmware, overwriting the original firmware data.

3. The method according to claim 1, characterized in that, The automatic repair of the FPGA firmware based on the verification result also includes: The BMC rereads the firmware data in the non-volatile memory after burning through the hardware interface and calculates the verification value after burning. The BMC performs a secondary verification between the programmed verification value and the verification benchmark value, and repairs the FPGA firmware based on the secondary verification result.

4. The method according to claim 1, characterized in that, The step of calculating the verification value based on the firmware data includes: The BMC establishes a data communication connection with the non-volatile memory storing the FPGA firmware through the SPI hardware interface, and reads the FPGA firmware data stored in the non-volatile memory according to the SPI protocol timing. The FPGA firmware data is hashed using a hash algorithm to generate a fixed-length string, which is then used as the verification value of the FPGA firmware data.

5. The method according to claim 1, characterized in that, The verification baseline value includes the baseline verification value and baseline version number of the remote file system. The verification result includes the integrity verification result and the version consistency verification result. When the verification value is inconsistent with the baseline verification value, the integrity verification result is determined to be a failure. When the current version number is inconsistent with the baseline version number, the version consistency verification result is determined to be a failure.

6. The method according to claim 1, characterized in that, The automatic repair of the FPGA firmware based on the verification result also includes: When the verification result indicates a version mismatch, the BMC downloads the FPGA upgrade firmware package matching the base version number from the remote file system through the access entry. The BMC calls the upgrade script, controls the hardware interface of the electronic device to put the FPGA into upgrade mode, erases the specified partition of the non-volatile memory storing the current firmware through the hardware interface, and writes the base firmware file in the FPGA upgrade firmware package in blocks.

7. The method according to claim 3, characterized in that, The BMC performs a secondary verification between the programmed verification value and the verification benchmark value, and repairs the FPGA firmware based on the secondary verification result; including: Compare the verified value after burning with the verified baseline value. If the results of the two verifications are consistent, the repair is considered successful; if the results of the two verifications are inconsistent, the burning process is repeated. After determining that the repair was successful, the BMC controls the FPGA to power on again, and the FPGA loads the burned-in reference FPGA firmware.

8. The method according to claim 1, characterized in that, The BMC establishes a remote file system access point locally on the electronic device managed by the BMC based on the remote access parameters; including: After the BMC starts, it reads the configuration file of the non-volatile memory in the FPGA and extracts the access parameters of the remote file system from the configuration file. The BMC initializes the remote file system through a configuration file and mounts the remote file system to the local directory, using the mount point as the access point.

9. The method according to claim 1, characterized in that, After automatically repairing the FPGA firmware based on the verification results, the process includes: The BMC collects information from the automatic repair process and generates a repair report; The BMC reports the repair report to the network management platform based on the management protocol.

10. An FPGA firmware corruption detection device, characterized in that, The device includes an establishment module, a reading module, and a verification module; wherein... The establishment module is used to obtain remote access parameters at the BMC startup time. Based on the remote access parameters, the BMC establishes an access entry for the remote file system on the local electronic device managed by the BMC. The remote file system is accessed at the BMC startup time. The BMC startup is independent of the host operating system. After the BMC completes its own hardware and basic function initialization, it performs a read operation on the onboard non-volatile memory, extracts the remote access parameters from the configuration file pre-stored in the onboard non-volatile memory, and mounts the remote file system to the local electronic device to form a directory entry that can be directly accessed locally. The reading module is used by the BMC to read the verification baseline value from the remote file system mounted locally; The verification module is used by the BMC to obtain the firmware data stored in the FPGA firmware based on the hardware interface of the electronic device, and to calculate the verification value based on the firmware data. The verification module is also used to compare the verification benchmark value and the verification value to determine the verification result; The verification module is also used to automatically repair the FPGA firmware based on the verification result.

Images