Solid state disk firmware management method and device, electronic equipment and storage medium
By implementing a firmware management method that involves periodic inspections and multi-level verification in solid-state drives, the problems of performance degradation and limited error correction capabilities caused by firmware inspections are solved, thereby achieving efficient firmware repair and system stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG YUNHAI GUOCHUANG CLOUD COMPUTING EQUIP IND INNOVATION CENT CO LTD
- Filing Date
- 2026-01-16
- Publication Date
- 2026-06-02
Smart Images
Figure CN122132203A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data storage technology, and more specifically to firmware management methods, devices, electronic devices, and storage media in solid-state drives. Background Technology
[0002] Solid-state drives (SSDs) have become the mainstream choice for modern storage devices due to their advantages such as high-speed read / write speeds, low power consumption, and shock resistance. However, the core storage medium of SSDs, NAND flash memory, suffers from issues such as data retention and electron loss, which can lead to firmware (FW) data errors or loss. To address these issues, SSDs typically incorporate ECC (Error Correction Code) mechanisms. However, ECC's error correction capabilities are limited, and frequent use of ECC to correct faulty firmware can degrade SSD performance.
[0003] Therefore, the relevant technologies have the problem that checking firmware can reduce the performance of solid-state drives and that the ability to correct abnormal firmware is limited. Summary of the Invention
[0004] In view of this, the present invention provides a firmware management method, apparatus, electronic device and storage medium for solid-state drives (SSDs) to solve the problems that checking firmware will reduce the performance of SSDs and that the ability to correct faulty firmware is limited.
[0005] In a first aspect, this application provides a firmware management method for a solid-state drive, the method comprising: The firmware is read from the solid-state drive (SSD), and the presence of the target firmware is determined based on the SSD's status parameters, the firmware read results, and the firmware's verification information. The target firmware is firmware with complete data and a read success probability greater than a preset threshold. If the target firmware exists in the firmware, determine whether other firmware is abnormal based on the reading results of other firmware, the verification information of other firmware, and the status parameters. Other firmware refers to firmware other than the target firmware. If there are anomalies in other firmware, repair the firmware with anomalies based on the target firmware and the target firmware's verification information; If the target firmware is not present in the firmware, firmware exception information is generated, which indicates that the firmware is faulty and cannot be repaired.
[0006] Secondly, this application provides a firmware management device for a solid-state drive, the device comprising: The first firmware inspection module is used to read firmware from the solid-state drive and determine whether the target firmware exists in the firmware based on the status parameters of the solid-state drive, the firmware reading result and the firmware verification information. The target firmware is firmware with complete data and a read success probability greater than a preset threshold. The second firmware inspection module is used to determine whether other firmware is abnormal when the target firmware exists in the firmware, based on the reading results of other firmware, the verification information of other firmware, and the status parameters. Other firmware refers to firmware other than the target firmware. The firmware repair module is used to repair the firmware with abnormalities based on the target firmware and its verification information if abnormalities exist in other firmware. The information generation module is used to generate firmware exception information when the target firmware is not present in the firmware. The firmware exception information is used to indicate that the firmware is abnormal and cannot be repaired.
[0007] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the firmware management method in a solid-state drive as described in the first aspect or any corresponding embodiment.
[0008] Fourthly, this application provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the firmware management method in a solid-state drive according to the first aspect or any corresponding embodiment described above.
[0009] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to execute the firmware management method in a solid-state drive according to the first aspect or any corresponding embodiment described above.
[0010] This application addresses the problems of firmware checks reducing SSD performance and limited error correction capabilities for faulty firmware. By reading firmware from the SSD, analyzing its status parameters, reading results, and verification information, this method identifies target firmware and faulty firmware. It then repairs faulty firmware based on the target firmware and its verification information. If no target firmware exists, it generates firmware error information. This method proactively detects firmware anomalies and repairs them promptly, preventing system crashes or data loss due to firmware corruption. The firmware inspection based on SSD status parameters, reading results, and verification information ensures correct firmware reading from the SSD, improving firmware reliability. Repairing faulty firmware based on the target firmware and its verification information improves repair efficiency and accuracy while reducing SSD resource consumption during the repair process. Attached Figure Description
[0011] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0012] Figure 1 This is a flowchart illustrating a firmware management method in a solid-state drive according to an embodiment of this application. Figure 2 This is a flowchart of the state machine during inspection according to an embodiment of this application; Figure 3 This is a flowchart illustrating the repair state according to an embodiment of this application; Figure 4 This is a structural block diagram of a firmware management device in a solid-state drive according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0014] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0015] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0016] SSDs, with their advantages of high-speed read / write, low power consumption, and shock resistance, have become the mainstream choice for modern storage devices. However, the core storage medium of SSDs, NAND flash memory, suffers from data retention and electron loss issues, which can lead to firmware data errors or loss. To address these problems, SSDs typically incorporate error correction codes (ECCs), but ECC's error correction capabilities are limited, and frequent error correction can degrade SSD performance. Therefore, SSD firmware inspection functionality has emerged. By periodically scanning the storage area, it can proactively detect and repair potential data errors, thereby extending the data's "shelf life" and reducing unrecoverable errors. Firmware inspection is crucial because the SSD's firmware and its multiple backups are stored in NAND flash. To prevent firmware errors leading to power-on failure due to data corruption in the NAND flash over time, regular inspection and repair are necessary to ensure firmware integrity.
[0017] Based on the above, this application provides a firmware management method for solid-state drives (SSDs). By designing a timed inspection mechanism, it achieves periodic proactive inspection, multi-level verification, and intelligent repair of firmware, significantly improving firmware reliability and device availability. The inspection process involves first locating the correct firmware and recording its location, then checking from the beginning for any erroneous firmware. If erroneous firmware is found, it is immediately repaired. Through the timed inspection mechanism, this invention can proactively discover potential errors in the firmware and repair them promptly, avoiding system crashes or data loss due to firmware corruption. During the verification phase, the firmware is decompressed, decrypted, and verified to ensure its integrity and security, further improving firmware reliability. It integrates a triple mechanism of periodic inspection, spatial redundancy, and signature verification to construct a firmware integrity protection matrix. For firmware that cannot be repaired, its number and location are recorded to avoid repeated checks in subsequent inspections, reducing resource waste. The state machine-based design gives this invention good scalability. Future improvements in inspection and repair efficiency can be achieved by adding new states or optimizing existing state logic.
[0018] According to an embodiment of this application, a firmware management method embodiment in a solid-state drive is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, for example, a computer, a server, etc., and although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0019] This embodiment provides a firmware management method for solid-state drives. Figure 1 This is a flowchart of a firmware management method in a solid-state drive according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: Step S101: Read the firmware from the solid-state drive, and determine whether the target firmware exists in the firmware based on the status parameters of the solid-state drive, the firmware reading result and the firmware verification information. The target firmware is firmware with complete data and a read success probability greater than a preset threshold.
[0020] Specifically, taking the storage of four firmware files (Firmware 1, Firmware 2, Firmware 3, and Firmware 4) in the NAND Flash of a solid-state drive as an example, each firmware file undergoes compression and encryption before storage to ensure appropriate size and security. A unique signature is also generated for each firmware file using an integrity verification method. During verification, the firmware is decompressed, decrypted, and the signature is verified. In addition to the once-period power-on inspection, firmware inspections are performed according to a schedule, such as 12 hours, 24 hours, 48 hours, or other durations.
[0021] During the inspection process, first attempt is made to read the firmware from the solid-state drive (SSD) to determine if it can be successfully read from the SSD's NAND Flash, obtaining the read result, such as: Firmware 1 successfully read, Firmware 2 unable to be read, etc. The status parameters of the firmware in the SSD's NAND Flash are then obtained, including write / erase cycles (P / E cycles), bad block rate, and NAND Flash voltage. After successfully reading the firmware, the firmware verification information is obtained.
[0022] The presence of the target firmware is determined based on the SSD's status parameters, firmware read results, and firmware verification information. The target firmware must meet the following requirements: it can be read successfully, and the corresponding status parameters are: erase / write cycles ≤ 30% of the design life, bad block rate ≤ 0.1%, and voltage fluctuation ≤ ±5mV. If the target firmware is successfully verified based on the verification information, the target firmware data is complete and correct.
[0023] Step S102: If the target firmware exists in the firmware, determine whether other firmware is abnormal based on the reading results of other firmware, the verification information of other firmware, and the status parameters. Other firmware refers to firmware other than the target firmware.
[0024] Specifically, "other firmware" refers to firmware other than the target firmware. The status parameters of the other firmware in the NAND Flash of the solid-state drive are obtained, including write / erase cycles (P / E cycles), bad block rate, and data retention voltage stability. After successfully reading the firmware, the firmware's verification information is obtained.
[0025] Based on the status parameters of other firmware, the reading results of other firmware, and the verification information of other firmware, determine whether there are any abnormalities in other firmware. Firmware with abnormalities must meet the following conditions: cannot be read from solid-state drive, or, in the corresponding status parameters, the number of erase / write cycles > 30% of the design life, bad block rate > 0.1%, voltage fluctuation > ±5mV, or, according to the verification information, the target firmware fails to be verified, that is, the target firmware data is incomplete or contains erroneous data.
[0026] Step S103: If there are abnormalities in other firmware, repair the firmware with abnormalities based on the target firmware and the verification information of the target firmware.
[0027] Specifically, the faulty firmware is repaired using the target firmware and its verification information. For example, if the faulty firmware contains a large amount of erroneous data, it can be deleted, and the corresponding target firmware can be written to the location of the faulty firmware. If the faulty firmware contains a small amount of erroneous data, the target firmware and the faulty firmware can be compared to identify inconsistencies, and the data in the target firmware can be used to replace the inconsistencies. After the initial repair of the faulty firmware, the verification information of the target firmware is used to verify and determine whether the firmware repair was successful.
[0028] Step S104: If the target firmware does not exist in the firmware, generate firmware exception information, wherein the firmware exception information is used to characterize the firmware exception and cannot be repaired.
[0029] Specifically, if every firmware has an anomaly, and the target firmware is not present in the firmware, making it impossible to repair the anomaly firmware using the target firmware, a firmware anomaly message is generated to notify the operations and maintenance personnel to handle the fault. The firmware anomaly message is as follows: All firmware has an anomaly, please repair it in time.
[0030] The firmware management method for solid-state drives (SSDs) provided in this embodiment reads firmware from the SSD and performs firmware inspection based on SSD status parameters, firmware read results, and firmware verification information to identify target firmware and firmware with anomalies. It then repairs the abnormal firmware based on the target firmware and its verification information. If no target firmware is found, firmware anomaly information is generated. This method proactively detects firmware anomalies and repairs them promptly, preventing system crashes or data loss due to firmware corruption. The firmware inspection based on SSD status parameters, firmware read results, and firmware verification information ensures correct firmware reading from the SSD, improving firmware reliability. Repairing abnormal firmware based on the target firmware and its verification information improves repair efficiency and accuracy while reducing SSD resource consumption during the repair process. This method solves the problems of firmware inspection reducing SSD performance and having limited error correction capabilities for abnormal firmware.
[0031] As an optional embodiment, the method further includes, before reading the firmware from the solid-state drive: Set the firmware check complete flag to a first initial value, where the firmware check complete flag is used to determine whether to check the firmware; Set the firmware check status flag to the second initial value, whereby the firmware check status flag is used to determine whether there is an anomaly in the firmware; Set the first quantity of the target firmware to the first initial quantity; Set the current firmware identifier to the third initial value, where the current firmware identifier is used to determine the firmware to be inspected; Set the second number of successfully repaired firmware to the second initial number; Set the target firmware location to the initial location, where the target firmware location is used to obtain the target firmware from the solid-state drive.
[0032] Specifically, when the CPU detects that the firmware inspection process needs to be started, it enters the initialization phase.
[0033] Firmware check completion flag, for example: a single firmware check completion flag. Initial value, for example: incomplete (False). The firmware check completion flag is used to determine whether a particular firmware has been checked. Setting the firmware check completion flag to the initial value, for example: setting a single firmware check completion flag to incomplete (False).
[0034] Firmware check status flags, for example: a single firmware check status flag. Second initial value, for example: failure (0). A single firmware check status flag is used to determine if there is an anomaly in the firmware. Setting the firmware check status flag to the second initial value, for example: setting the single firmware check status flag to failure (0).
[0035] The first quantity of target firmware is, for example, the number of firmware that successfully passed verification. The first quantity is, for example, 0. Setting the first quantity of target firmware to the first initial quantity, for example, setting the number of firmware that successfully passed verification to 0. The second initial quantity is, for example, 0. Setting the second quantity of firmware that successfully repaired to the second initial quantity, for example, setting the number of firmware that successfully repaired to 0.
[0036] The currently checked firmware identifier is, for example, the firmware number being checked. The third initial value is, for example, 2. The currently checked firmware number is used to determine the firmware to be checked. Setting the currently checked firmware identifier to the third initial value, for example, setting the currently checked firmware number to 1.
[0037] The target firmware location is, for example, the NAND location where the successfully detected firmware is located. The initial location is, for example, 0. The NAND location of the successfully detected firmware is used to obtain the target firmware from the solid-state drive. Setting the target firmware location to the initial location, for example, setting the NAND location of the successfully detected firmware to 0.
[0038] In this embodiment, the initialization operation eliminates historical data interference by standardizing and pre-setting core inspection parameters, ensuring that the starting point of each inspection is consistent; it clarifies the starting object and judgment basis of the inspection; it provides accurate data support for baseline firmware calls, repair effect statistics and result review, reduces the complexity of state machine collaboration, improves response efficiency, and adapts to a variety of complex repair scenarios.
[0039] As an optional embodiment, determining whether the target firmware exists in the firmware based on the solid-state drive's status parameters, firmware read results, and firmware verification information includes: If it is determined from the current firmware identifier and read results that the first firmware can be read from the solid-state drive, the first firmware is verified according to the verification information; If the first firmware verification is successful, obtain the number of times the first firmware has been repaired and the failure frequency of the storage block where the first firmware is located, where the storage block is contained in the solid-state drive; If the status parameters are less than the first preset threshold, the number of repairs is less than the second preset threshold, and the failure frequency is less than the third preset threshold, the first firmware will be used as the target firmware.
[0040] Specifically, based on the current firmware identifier, it is found that firmware 1 has not been checked. Firmware 1 is then used as the first firmware and read from the NAND Flash of the solid-state drive.
[0041] If it is determined from the current firmware identification and reading results that the first firmware can be read from the solid-state drive, the first firmware is decompressed, decrypted and verified, the verification information of the first firmware is obtained from the first firmware, and the first firmware is verified according to the verification information to verify the correctness and data integrity of the first firmware.
[0042] Storage blocks, for example, are the NAND Flash memory of a solid-state drive. If the first firmware verification is successful, the number of times the first firmware has been repaired and the failure frequency of the storage block where the first firmware is located are obtained.
[0043] Solid-state drive (SSD) status parameters include: write / erase cycles, bad block rate, and NAND flash voltage. The corresponding first preset thresholds for these status parameters are, for example: 30% of the design life for write / erase cycles, 0.1% for the bad block rate, and 5mV for voltage fluctuation. These first preset thresholds are set according to actual needs. Second preset thresholds include, for example, 3, 4, or other values. Third preset thresholds include, for example, 1 time / 7 days, 1 time / 1 day, or other frequencies.
[0044] If the status parameters are less than the first preset threshold, the number of repairs is less than the second preset threshold, and the failure frequency is less than the third preset threshold, the first firmware will be used as the target firmware.
[0045] In this embodiment, high-risk candidate firmware is eliminated through multi-dimensional screening based on verification information, SSD status parameters, firmware repair count, and storage block failure frequency, ensuring high reliability of the target firmware; providing a high-quality benchmark for subsequent repairs and improving the stability and effectiveness of SSD firmware inspection and repair.
[0046] As an optional embodiment, determining whether other firmware is abnormal based on the read results of other firmware, the verification information of other firmware, and status parameters includes: If it is determined from the current firmware identification and reading results that the second firmware cannot be read from the solid-state drive, it is determined that the second firmware is abnormal and the first level is set as the fault level of the second firmware, wherein the second firmware is included in other firmware; If the second firmware can be read from the solid-state drive, and the data verification of the second firmware fails based on the verification information, it is determined that the second firmware is abnormal and the second level is set as the fault level of the second firmware. If the data verification of the second firmware passes based on the verification information, obtain the number of times the second firmware has been repaired and the failure frequency of the storage block where the second firmware is located. If the status parameter is greater than or equal to the first preset threshold, or the number of repairs is greater than or equal to the second preset threshold, or the fault frequency is greater than or equal to the third preset threshold, it is determined that the second firmware is abnormal and the third level is set as the fault level of the second firmware.
[0047] Specifically, this embodiment designs three firmware fault levels: Level 1 indicates firmware tampering, core functional module damage, or physical failure of the NAND block, marked as "unrepairable," and triggers a hardware alarm after isolation. Level 2 indicates non-core functional abnormalities or inadequate environmental adaptability, marked as "requires urgent repair," and the next inspection interval is shortened. Level 3 indicates excessive simulation operation time or risks associated with historical faults, marked as "requires monitoring and repair," and a special verification item is added to the next inspection.
[0048] Based on the current firmware identification, firmware 2 has not yet been checked. Firmware 2 will be used as the second firmware, and it will be read from the NAND Flash of the solid-state drive (SSD). The second firmware is a firmware other than the target firmware. If the second firmware cannot be read from the SSD, it is determined that the second firmware is faulty, and the first level is set as the fault level for the second firmware.
[0049] If the second firmware can be read from the solid-state drive, it is decompressed, decrypted, and verified using a signature. The verification information of the second firmware is used to verify its correctness and data integrity. If the data verification of the second firmware fails based on the verification information, it is determined that the second firmware is abnormal, and the second level is set as the fault level of the second firmware. If the data verification of the second firmware passes based on the verification information, the number of times the second firmware has been repaired and the failure frequency of the storage block where the second firmware is located are obtained.
[0050] Solid-state drive (SSD) status parameters include: write / erase cycles, bad block rate, and NAND Flash voltage. The first preset threshold for these status parameters is, for example, 30% of the design life for write / erase cycles, 0.1% for bad block rate, and 5mV for voltage fluctuation. These first preset threshold values are set according to actual needs. The second preset threshold is, for example, 3, 4, or other values. The third preset threshold is, for example, 1 time / 7 days, 1 time / 1 day, or other frequencies. If a status parameter is greater than or equal to the first preset threshold, or the number of repairs is greater than or equal to the second preset threshold, or the failure frequency is greater than or equal to the third preset threshold, the second firmware is determined to be abnormal, and the third level is set as the failure level of the second firmware.
[0051] As an optional embodiment, repairing the faulty firmware based on the target firmware and its verification information includes: The firmware with abnormalities is designated as the firmware to be repaired. The firmware to be repaired is compared with the target firmware. Based on the comparison results, the erroneous data in the firmware to be repaired is determined. The erroneous data is the data in the firmware to be repaired that is inconsistent with the target firmware. If the proportion of erroneous data in the firmware to be repaired is greater than the fourth preset threshold, determine the first firmware address of the firmware to be repaired, erase the firmware to be repaired, write the target firmware to the first firmware address, and obtain the repaired firmware. If the proportion of erroneous data in the firmware to be repaired is less than or equal to the fourth preset threshold, the target data corresponding to the erroneous data is obtained in the target firmware, and the erroneous data is replaced with the target data to obtain the repaired firmware. The repaired firmware is verified based on the verification information of the target firmware. If the verification of the repaired firmware passes, the verification information of the repaired firmware is updated based on the verification information of the target firmware, and the repaired firmware is recognized as the successfully repaired firmware.
[0052] Specifically, firmware with anomalies is identified as firmware to be repaired. The firmware to be repaired is compared with the target firmware, and the erroneous data in the firmware to be repaired is determined based on the comparison results. For example, a sliding window comparison algorithm (window size 1KB) is used to compare the binary data of the firmware to be repaired and the target firmware segment by segment to find data in the firmware to be repaired that is inconsistent with the target firmware, and this inconsistent data is identified as erroneous data.
[0053] The fourth preset threshold is, for example, 1%, 1.5%, or other percentages. If the proportion of erroneous data in the firmware to be repaired is greater than the fourth preset threshold, it indicates that the proportion of erroneous data is high. Repairing each erroneous data individually would take a long time. Therefore, a full erase and overwrite method is used to repair the abnormal firmware. The first firmware address of the firmware to be repaired is determined, the firmware to be repaired is erased, and the target firmware is written to the first firmware address to obtain the repaired firmware.
[0054] If the proportion of erroneous data in the firmware to be repaired is less than or equal to the fourth preset threshold, it indicates a low proportion of erroneous data. In this case, only the erroneous data in the firmware needs to be repaired, reducing NAND Flash write / erase wear and improving repair efficiency. The target data corresponding to the erroneous data is obtained from the target firmware, and the erroneous data is replaced with the target data to obtain the repaired firmware.
[0055] The repaired firmware is verified based on the verification information of the target firmware. If the verification of the repaired firmware passes, it means that the repaired firmware is consistent with the target firmware, and the firmware repair is confirmed to be successful. The verification information of the repaired firmware is updated according to the verification information of the target firmware, and the repaired firmware is regarded as the successfully repaired firmware.
[0056] In this embodiment, by comparing and accurately locating the erroneous data of the firmware to be repaired, the full coverage or partial replacement repair method is dynamically selected according to the error ratio to adapt to different damage scenarios; reduce NAND erase and write wear, balance repair efficiency and thoroughness, and ensure the effectiveness of repair by verification and verification information updates, thereby improving the reliability of firmware repair.
[0057] As an optional embodiment, after obtaining the repaired firmware, the method further includes: Create a firmware simulation partition and write the repaired firmware to the firmware simulation partition; Load the repaired firmware into the firmware simulation run partition, and use the repaired firmware to execute a preset number of firmware operation functions; If a default error occurs during the firmware operation process, the repaired firmware will be marked as an error. If no preset exception occurs during the execution of the firmware operation function, the second quantity will be increased by the preset step size.
[0058] Specifically, create a firmware simulation partition, such as an independent simulation partition (isolated main running area) created in the SSD. The preset number indicates multiple partitions; no specific limit is specified here.
[0059] The firmware simulation runs on a partition where the repaired firmware is loaded. The repaired firmware is then used to execute a preset number of firmware operation functions, such as the firmware boot process, instruction decoding, data read / write control logic, data read / write, error correction, and other core firmware functions. The simulation executes the firmware boot process, instruction decoding, and data read / write control logic, recording execution time (≤ 1.2 times the preset threshold), memory usage fluctuations (≤ ±10%), and the absence of infinite loops or abnormal interruptions. Preset anomalies include: exceeding the time limit, memory overflow, instruction execution errors, execution entering an infinite loop, and abnormal interruptions.
[0060] If a default error occurs during the firmware operation process, it means that the repaired firmware still has errors. The repaired firmware will be marked as error and needs to be repaired again.
[0061] If no preset exception occurs during the firmware operation, it means that the faulty firmware has been successfully repaired. Increase the second quantity by the preset step size, for example, 1.
[0062] In this embodiment, by creating an independent simulation running partition to isolate the main running area, the verification operation is prevented from affecting the normal use of the SSD; the core functions of the firmware are simulated and multi-dimensional indicators are monitored to accurately identify hidden anomalies and prevent the use of firmware that has not been thoroughly repaired; the criteria for judging the success or failure of the repair are clearly defined, and the repair success count is updated synchronously to provide reliable data support for subsequent result review, which significantly improves the effectiveness and reliability of firmware repair.
[0063] As an optional embodiment, after repairing the faulty firmware based on the target firmware and its verification information, the method further includes: The total amount of firmware is determined based on the current firmware identification. If the sum of the first and second quantities is less than the total amount of firmware, the firmware is determined to be unrepairable. Determine the address of the second firmware in the solid-state drive where the repaired firmware failed; The second firmware address is recorded in a global structure. The second firmware address in the global structure is used to indicate that the firmware at the second firmware address is not to be verified.
[0064] Specifically, the total number of firmware items is determined based on the current firmware identification. For example, if the current firmware identification is 5, it means that 5 firmware items were checked, and the total number of firmware items is 5. The first quantity is the number of target firmware items, i.e., the number of firmware items that were successfully verified. If the number of successfully verified firmware items is inconsistent with the total number of firmware items, it means that there are firmware items that need to be repaired. The second quantity is the number of firmware items that were successfully repaired. If the number of successfully repaired firmware items is 1, which is greater than zero, it means that at least one firmware item has been repaired.
[0065] If the sum of the first quantity and the second quantity is less than the total number of firmware, it means that the number of successfully repaired firmware plus the number of successfully verified firmware is not equal to the number of firmware inspected in this inspection, indicating that there are firmware that failed to be repaired. The firmware that failed to be repaired and its second firmware address in the solid-state drive are then determined.
[0066] A global structure, such as a log, records the number of firmware failures and the second firmware address. This log entry prevents subsequent checks from re-verifying this location, optimizing resource utilization. The second firmware address in the global structure indicates that firmware at that address will not be verified. For example, if the second firmware address is for firmware 3, the next check will not check firmware 3, further optimizing resource utilization.
[0067] In this embodiment, the failed firmware and its address are accurately identified and recorded in a global structure to skip subsequent inspections, avoiding wasted resources due to invalid verification; at the same time, the status of unrepaired firmware is clearly identified, providing a basis for result review, and significantly improving inspection efficiency and resource utilization.
[0068] As an optional embodiment, this embodiment can design a 5-state machine based on the above embodiments, such as... Figure 2 As shown, these include: IDLE (idle state), FIND (find correct firmware state), FIX (repair state), RESULT (result check state), and ERROR (error state).
[0069] Specifically, in IDLE (idle state): The CPU periodically checks for the need for inspection. When the set inspection cycle is reached, it performs initialization before entering the inspection phase, initializing the following flags: single firmware inspection completion flag, single firmware inspection status flag (success / repaired / repair failed), number of successfully repaired firmware, number of successfully verified firmware, currently inspected firmware number, and the location of successful firmware in the NAND flash. After initializing the above flags, the state machine is modified to the preparation phase.
[0070] The FIND (find phase) is used to read the firmware to be checked from the NAND Flash. After obtaining the read success flag, it enters the verification state. If the firmware is successfully verified, the current firmware position in the NAND is recorded. The correct firmware at this position is used during repair. Once a successful firmware is verified, the state can be exited and the subsequent FIX repair state can be entered.
[0071] FIX (Repair State): This stage is used to verify the correctness of the current firmware. If firmware verification fails, immediate repair is performed. Typically, firmware is compressed and encrypted before storage to ensure appropriate size and security. A unique signature is also generated for the firmware using integrity verification methods. In the verification state, the firmware is decompressed, decrypted, and the signature is verified. If all steps pass, a flag indicating successful firmware verification is recorded. If an error occurs during decompression, decryption, or signature verification, the correct firmware is immediately read from the location recorded in the FIND state, cached, the erroneous firmware is erased, and the correct firmware is written. A flag indicating successful firmware verification and repair is recorded, and subsequent firmware checks continue. After all firmware in the NAND flash memory has been verified, the RESULT state is entered to check the results of this inspection.
[0072] RESULT (Result Check Status): At this point, all firmware verifications have been completed. Check the status flags. If all firmware verifications are successful, return to the IDLE status and wait for the next inspection to trigger. If all firmware verifications fail, enter the ERROR status. If there are failed firmwares and they are successfully repaired, record the location and number of failed firmwares in the log and return to the IDLE status. If all repairs fail but there are successful firmwares, record the location of the failed firmwares. The next inspection will not check this location and will return to the IDLE status.
[0073] ERROR (Error Status): At this point, the inspection can no longer repair or detect the correct firmware, so it is meaningless and the inspection function will not be triggered again in subsequent runs.
[0074] The above content is as follows Figure 3As shown, in the repair state, the process first checks if the firmware was read successfully. If read successfully, decryption, decompression, and signature verification are performed. If all firmware passes, the verification is marked as successful. If any firmware fails, the repair process is triggered. If firmware read fails, the read failure is recorded, and the repair process is triggered again. If the repair operation is triggered, the erase verification is checked. If it passes, an image copy is written; if it fails, a bad block is marked, and the repair failure status is recorded. The write verification is checked. If it passes, the repair success status is updated; if it fails, the isolation process is entered, and the repair failure status is recorded. After all verifications are completed, the process enters the result check state to generate an inspection report.
[0075] In this embodiment, autonomous health management of the entire lifecycle of SSD firmware is achieved through state machine architecture and intelligent repair strategy, providing core technical protection for high-reliability storage systems.
[0076] This embodiment also provides a firmware management device for a solid-state drive, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0077] This embodiment provides a firmware management device for a solid-state drive, such as... Figure 4 As shown, it includes: The first firmware inspection module 401 is used to read firmware from the solid-state drive and determine whether there is target firmware in the firmware based on the status parameters of the solid-state drive, the firmware reading result and the firmware verification information. The target firmware is firmware with complete data and a read success probability greater than a preset threshold. The second firmware inspection module 402 is used to determine whether other firmware is abnormal when the target firmware exists in the firmware, based on the reading results of other firmware, the verification information of other firmware and the status parameters. Other firmware refers to firmware other than the target firmware. Firmware repair module 403 is used to repair the firmware with abnormalities based on the target firmware and the verification information of the target firmware if there are abnormalities in other firmware. The information generation module 404 is used to generate firmware exception information when the target firmware is not present in the firmware. The firmware exception information is used to characterize the firmware as abnormal and unrepairable.
[0078] In some alternative embodiments, the device further includes: The first setting module is used to set the firmware check completion flag to a first initial value, wherein the firmware check completion flag is used to determine whether to check the firmware; The second setting module is used to set the firmware check status flag to a second initial value, wherein the firmware check status flag is used to determine whether there is an anomaly in the firmware; The third setting module is used to set the first quantity of the target firmware to the first initial quantity; The fourth setting module is used to set the current firmware identifier to the third initial value, wherein the current firmware identifier is used to determine the firmware to be inspected; The fifth setting module is used to set the second number of successfully repaired firmware to the second initial number; The sixth setting module is used to set the target firmware location to the initial location, wherein the target firmware location is used to obtain the target firmware in the solid-state drive.
[0079] In some alternative implementations, the first firmware inspection module 401 includes: The verification unit is used to verify the first firmware based on the verification information when it is determined from the current firmware identifier and reading result that the first firmware can be read from the solid-state drive. The first acquisition unit is used to acquire the number of times the first firmware has been repaired and the failure frequency of the storage block where the first firmware is located if the first firmware verification is successful, wherein the storage block is contained in the solid-state drive. The setting unit is used to select the first firmware as the target firmware when the status parameter is less than the first preset threshold, the number of repairs is less than the second preset threshold, and the fault frequency is less than the third preset threshold.
[0080] In some alternative implementations, the second firmware inspection module 402 includes: The first determining unit is used to determine that the second firmware is abnormal and set the first level as the fault level of the second firmware when it is determined from the current firmware identifier and reading result that the second firmware cannot be read from the solid-state drive. The second firmware is included in other firmware. The second determining unit is used to determine that the second firmware is abnormal and set the second level as the fault level of the second firmware if the data verification of the second firmware according to the verification information fails when the second firmware can be read from the solid-state drive. The second acquisition unit is used to acquire the number of times the second firmware has been repaired and the failure frequency of the storage block where the second firmware is located if the data verification of the second firmware passes according to the verification information. The third determining unit is used to determine that the second firmware has an anomaly and set the third level as the fault level of the second firmware if the status parameter is greater than or equal to the first preset threshold, or the number of repairs is greater than or equal to the second preset threshold, or the fault frequency is greater than or equal to the third preset threshold.
[0081] In some alternative implementations, the firmware repair module 403 includes: The comparison unit is used to identify the firmware with abnormalities as the firmware to be repaired, compare the firmware to be repaired with the target firmware, and determine the erroneous data in the firmware to be repaired based on the comparison results. The erroneous data is the data in the firmware to be repaired that is inconsistent with the target firmware. The writing unit is used to determine the first firmware address of the firmware to be repaired if the proportion of erroneous data in the firmware to be repaired is greater than the fourth preset threshold, erase the firmware to be repaired, write the target firmware to the first firmware address, and obtain the repaired firmware. The repair unit is used to obtain the target data corresponding to the erroneous data in the target firmware if the proportion of erroneous data in the firmware to be repaired is less than or equal to the fourth preset threshold, and replace the erroneous data with the target data to obtain the repaired firmware. The verification unit is used to verify the repaired firmware based on the verification information of the target firmware. If the repaired firmware passes the verification, the verification information of the repaired firmware is updated according to the verification information of the target firmware, and the repaired firmware is regarded as the successfully repaired firmware.
[0082] In some alternative implementations, the firmware repair module 403 includes: A creation unit is used to create a firmware simulation partition and write the repaired firmware to the firmware simulation partition. The execution unit is used to load the repaired firmware in the firmware simulation running partition and use the repaired firmware to execute a preset number of firmware operation functions. The first judgment unit is used to mark the repaired firmware as abnormal if a preset abnormality occurs during the execution of firmware operation functions. The second judgment unit is used to increase the second quantity by a preset step if no preset abnormality occurs during the execution of the firmware operation function.
[0083] In some alternative embodiments, the device further includes: The first determining module is used to determine the total amount of firmware based on the currently inspected firmware identifier; The second determining module is used to determine the firmware that failed to be repaired when the sum of the first quantity and the second quantity is less than the total amount of firmware. The third determination module is used to determine the second firmware address in the solid-state drive where the repaired firmware failed to be repaired. The recording module is used to record the second firmware address into a global structure, wherein the second firmware address in the global structure is used to indicate that the firmware at the second firmware address is not to be verified.
[0084] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.
[0085] In this embodiment, the firmware management device in the solid-state drive is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.
[0086] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.
[0087] The following is a detailed reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from memory 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device. The processor 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.
[0088] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.
[0089] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a memory 508, or installed from a ROM 502. When the computer program is executed by the processor 501, it performs the functions defined in the firmware management method in the solid-state drive of the present invention.
[0090] Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.
[0091] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the firmware management method in the solid-state drive shown in the above embodiments is implemented.
[0092] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.
[0093] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.
Claims
1. A firmware management method for a solid-state drive, characterized in that, The method includes: Firmware is read from the solid-state drive, and the presence of target firmware is determined based on the status parameters of the solid-state drive, the reading result of the firmware, and the verification information of the firmware. The target firmware is firmware with complete data and a read success probability greater than a preset threshold. If the target firmware exists in the firmware, the system determines whether the other firmware is abnormal based on the reading results of other firmware, the verification information of the other firmware, and the status parameters, wherein the other firmware is firmware other than the target firmware. If there are any abnormalities in the other firmware, repair the abnormal firmware according to the target firmware and the verification information of the target firmware; If the target firmware is not present in the firmware, firmware exception information is generated, wherein the firmware exception information is used to characterize the firmware exception and the inability to be repaired.
2. The method according to claim 1, characterized in that, Prior to reading the firmware from the solid-state drive, the method further includes: Set the firmware check completion flag to a first initial value, wherein the firmware check completion flag is used to determine whether to check the firmware; Set the firmware check status flag to a second initial value, wherein the firmware check status flag is used to determine whether the firmware has any abnormalities; Set the first quantity of the target firmware to the first initial quantity; Set the current firmware identifier to a third initial value, wherein the current firmware identifier is used to determine the firmware to be inspected; Set the second number of successfully repaired firmware to the second initial number; Set the target firmware location to the initial location, wherein the target firmware location is used to obtain the target firmware in the solid-state drive.
3. The method according to claim 2, characterized in that, The step of determining whether the target firmware exists in the firmware based on the status parameters of the solid-state drive, the read result of the firmware, and the verification information of the firmware includes: If it is determined that the first firmware can be read from the solid-state drive based on the current firmware identifier and the read result, the first firmware is verified according to the verification information; If the first firmware verification is successful, obtain the number of times the first firmware has been repaired and the failure frequency of the storage block where the first firmware is located, wherein the storage block is contained in the solid-state drive; If the status parameter is less than a first preset threshold, the number of repairs is less than a second preset threshold, and the fault frequency is less than a third preset threshold, the first firmware will be used as the target firmware.
4. The method according to claim 2, characterized in that, The step of determining whether other firmware is abnormal based on the read results of other firmware, the verification information of other firmware, and the status parameters includes: If it is determined, based on the current firmware identifier and the read result, that the second firmware cannot be read from the solid-state drive, it is determined that the second firmware is abnormal and the first level is set as the fault level of the second firmware, wherein the second firmware is included in the other firmware; If the second firmware can be read from the solid-state drive, and the data verification of the second firmware according to the verification information fails, it is determined that the second firmware is abnormal and the second level is set as the fault level of the second firmware. If the data verification of the second firmware passes according to the verification information, the number of times the second firmware has been repaired and the failure frequency of the storage block where the second firmware is located are obtained. If the status parameter is greater than or equal to the first preset threshold, or the number of repairs is greater than or equal to the second preset threshold, or the fault frequency is greater than or equal to the third preset threshold, it is determined that the second firmware is abnormal and the third level is set as the fault level of the second firmware.
5. The method according to claim 2, characterized in that, The step of repairing the faulty firmware based on the target firmware and its verification information includes: The firmware with the abnormality is taken as the firmware to be repaired. The firmware to be repaired is compared with the target firmware. Based on the comparison result, the erroneous data in the firmware to be repaired is determined. The erroneous data is the data in the firmware to be repaired that is inconsistent with the target firmware. If the proportion of the erroneous data in the firmware to be repaired is greater than the fourth preset threshold, determine the first firmware address of the firmware to be repaired, erase the firmware to be repaired, write the target firmware into the first firmware address, and obtain the repaired firmware. If the proportion of the error data in the firmware to be repaired is less than or equal to the fourth preset threshold, the target data corresponding to the error data is obtained in the target firmware, and the error data is replaced with the target data to obtain the repaired firmware. The repaired firmware is verified based on the verification information of the target firmware. If the repaired firmware passes the verification, the verification information of the repaired firmware is updated based on the verification information of the target firmware, and the repaired firmware is recognized as the successfully repaired firmware.
6. The method according to claim 5, characterized in that, After obtaining the repaired firmware, the method further includes: Create a firmware simulation partition and write the repaired firmware into the firmware simulation partition; The repaired firmware is loaded into the firmware simulation running partition, and a preset number of firmware operation functions are executed using the repaired firmware. If a preset exception occurs during the execution of the firmware operation function, the repaired firmware will be marked as abnormal; If no preset abnormality occurs during the execution of the firmware operation function, the second quantity is increased by a preset step.
7. The method according to claim 2, characterized in that, After repairing the faulty firmware based on the target firmware and its verification information, the method further includes: The total amount of firmware is determined based on the currently inspected firmware identifier; If the sum of the first quantity and the second quantity is less than the total amount of firmware, then the firmware is determined to have failed to be repaired. Determine the second firmware address of the failed repair firmware in the solid-state drive; The second firmware address is recorded in a global structure, wherein the second firmware address in the global structure is used to indicate that the firmware at the second firmware address is not verified.
8. A firmware management device for a solid-state drive, characterized in that, The device includes: The first firmware inspection module is used to read firmware from the solid-state drive and determine whether there is target firmware in the firmware based on the status parameters of the solid-state drive, the reading result of the firmware and the verification information of the firmware. The target firmware is firmware with complete data and a read success probability greater than a preset threshold. The second firmware inspection module is used to determine whether other firmware is abnormal when the target firmware is present in the firmware, based on the reading results of other firmware, the verification information of the other firmware, and the status parameters, wherein the other firmware is firmware other than the target firmware. The firmware repair module is used to repair the firmware with abnormalities based on the target firmware and the verification information of the target firmware if there are abnormalities in the other firmware. An information generation module is used to generate firmware exception information when the target firmware is not present in the firmware, wherein the firmware exception information is used to characterize the firmware as abnormal and unrepairable.
9. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the firmware management method in a solid-state drive as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the firmware management method in the solid-state drive according to any one of claims 1 to 7.