Firmware programming method and electronic device

Abstract

The application discloses a firmware programming method and an electronic device, and is applied to the technical field of storage, and comprises the following steps: generating general firmware data to be completed for parameter injection, and generating a programming parameter file corresponding to the model of a storage device for different models of the storage device; acquiring the model of a storage device to be programmed and obtaining the corresponding programming parameter file based on the model; obtaining the compiled target firmware by analyzing the programming parameter file and performing parameter injection on the general firmware data; and performing firmware programming on the storage device to be programmed by using the target firmware, and dynamically updating the actual programming voltage based on the reference programming voltage and the temperature offset during the programming process. By using the scheme of the application, the firmware compiling cost can be effectively reduced. The influence of temperature change on the programming process is reduced, and the reliability of programming is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of storage, and particularly relates to a firmware programming method and an electronic device. BACKGROUND

[0002] Firmware programming of a hard disk is a core link for determining product performance and reliability. With diversification of SSD (Solid State Disk) models, traditional programming technology faces challenges such as complex parameter configuration and insufficient abnormality processing capability. At present, hardware parameters are integrated into firmware through a hard coding mode, so that firmware needs to be compiled independently for different models of SSD, resulting in high firmware compilation cost and long research and development cycle.

[0003] To sum up, how to effectively realize firmware programming and reduce firmware compilation cost is a technical problem to be solved by the technical personnel in the field. SUMMARY

[0004] The present application provides a firmware programming method and an electronic device to at least solve the problem of effectively realizing firmware programming and reducing firmware compilation cost in the related art.

[0005] The present application provides a firmware programming method, comprising:

[0006] generating general firmware data to be completed with parameter injection, and generating a programming parameter file corresponding to a model of a storage device for the storage device of different models;

[0007] obtaining a model of a storage device to be programmed and obtaining a corresponding programming parameter file based on the model;

[0008] obtaining a model of a storage device to be programmed and obtaining a corresponding programming parameter file based on the model;

[0009] programming firmware of the storage device to be programmed through the target firmware, and dynamically updating an actual programming voltage based on a reference programming voltage and a temperature offset during the programming process.

[0010] The present application also provides an electronic device, comprising a memory for storing a computer program, and a processor for executing the computer program to realize the steps of the firmware programming method.

[0011] The application scheme considers that the firmware can be decoupled into general firmware data and a burning parameter file, the general firmware data is a core function module of the firmware, for example, the general firmware data can have basic functions such as data read-write control, ECC check algorithm, life cycle management, and the general firmware data has not been parameter-injected to have generality. For different models of storage devices, a burning parameter file corresponding to the model of the storage device is generated according to the burning requirements of the storage device of the model. Subsequently, in the burning process, the model of the storage device to be burned can be identified, and then the corresponding burning parameter file is obtained, and after the burning parameter file is parsed, the general firmware data can be parameter-injected to obtain the target firmware which is compiled and can be burned to the storage device to be burned.

[0012] As can be seen, in the application scheme, the general firmware data with generality + specific burning parameter file is used to obtain the required target firmware, which can effectively reduce the firmware compilation cost. In addition, in the burning process, the burning voltage is not fixed, but is dynamically updated based on the reference burning voltage and the temperature offset, which is beneficial to reduce the influence of temperature change on the burning process and ensure the reliability of the burning. BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0014] Figure 1 An implementation flowchart of the firmware burning method provided by a specific embodiment of the present application;

[0015] Figure 2 A structural schematic diagram of an electronic device provided by a specific embodiment of the present application;

[0016] Figure 3 A structural schematic diagram of a computer readable storage medium. DETAILED DESCRIPTION

[0017] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0018] It should be noted that in the description of the present application, the terms "comprising", "including" or any other variant thereof are intended to cover non-exclusive inclusion, so that processes, methods, articles or devices that include a series of elements not only include those elements, but also include other elements not explicitly listed, or further include elements inherent in such processes, methods, articles or devices. The terms "first", "second" and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0019] In order to better understand the present application, the present application will be further described in detail below in combination with the drawings and specific embodiments. Please refer to Figure 1 , Figure 1 The embodiment flowchart of the firmware burning method provided by the specific embodiment of the present application can include the following steps:

[0020] Step S101: generating general firmware data to be completed parameter injection, and generating a burning parameter file corresponding to the model of the storage device for different models of storage devices.

[0021] The present application considers that the firmware can be decoupled into general firmware data and burning parameter file. The general firmware data is the core functional module of the firmware, which can specifically include three modules of data link layer (such as supporting NVMe (Non-Volatile Memory Express, Non-Volatile Memory Express) / SATA (Serial Advanced Technology Attachment, Serial ATA) protocol), algorithm layer (such as ECC (Error-Correcting Code, Error-Correcting Code) error correction algorithm, wear leveling algorithm), control layer (power management, temperature regulation). The general firmware data can realize basic functions such as data read-write control, ECC algorithm, life cycle management, support cross-hardware platform compilation, and generate general firmware image. That is, the general firmware data in the present application can realize various functions required by the firmware, including most of the firmware content, but has not been parameter injected, so the general firmware data is universal, so that different models of storage devices can use the general firmware data.

[0022] For different models of storage devices, the configuration information of various parameters required in the burning process constitutes the burning parameter file of the storage device of this model. That is, in the present application, corresponding burning parameter files need to be generated for different models of storage devices. So that through the combination of general firmware data + burning parameter file, the final firmware is obtained.

[0023] In actual application, the burning parameter file can be in JSON / YMAL / HTML format, and can include multiple parameter configuration items such as a burning voltage (for example, 3.3V±2%), a programming time (for example, 500μs / page), an ECC check level (for example, L1 / L2 / L3), and the like.

[0024] In addition, it can be understood that the general firmware data is a file for implementing firmware functions, and therefore has more content and higher compiling cost, but has general applicability, and different models of storage devices can use the same general firmware data. The burning parameter file carries configuration information about various parameters required in the burning process of the storage device, and although the burning parameter file needs to be generated for different models of storage devices, the generation of the burning parameter file is relatively simple and convenient and is not prone to errors. Therefore, in the present application, the general firmware data + the burning parameter file are adopted, and compared with the traditional scheme in which firmware is independently compiled for different models of SSDs through hard coding, the present application can effectively reduce the firmware compiling cost.

[0025] It should be further noted that in the present application, the burning parameter file corresponding to the model of the storage device needs to be generated for different models of storage devices, and the model of the storage device can usually be determined according to “host chip model + grain type + capacity”, that is, for any two storage devices, only when the host chip model, the grain type and the capacity of the two storage devices are consistent, the two storage devices are the same model of storage device. The storage device described in the present application is usually an SSD, and of course, in other specific embodiments, it can be other types of storage devices.

[0026] Step S102: obtaining the model of the storage device to be burned and obtaining the corresponding burning parameter file based on the model.

[0027] The storage device to be burned is a storage device that currently needs to be burned with firmware, and the model thereof needs to be identified, so that the burning parameter file generated for the storage device of the model can be obtained.

[0028] In one specific embodiment of the present application, obtaining the model of the storage device to be burned can include:

[0029] acquiring an image of the storage device to be burned through an image acquisition device;

[0030] recognizing the model label in the image to obtain the model of the storage device to be burned.

[0031] The embodiment considers that the image recognition technology is relatively mature and has been widely applied, and thus, when the burning of the storage device to be burned is performed, the image of the storage device to be burned can be acquired by an image acquisition device (for example, an industrial camera), and then the model label in the image is recognized, so that the model of the storage device to be burned can be determined conveniently and quickly. The model label can be in the form of a two-dimensional code, a bar code or the like. In actual application, a bar code used to reflect the model is usually pasted on the surface of the storage device to be burned, and thus, the model label in the acquired image is usually a bar code. By recognizing the model label, the model of the storage device to be burned can be obtained, for example, the model of the storage device to be burned obtained in one occasion is represented as "Model-X-512G".

[0032] After the model of the storage device to be burned is acquired, the required burning parameter file can be obtained according to the corresponding relationship between the model and the burning parameter file.

[0033] In one specific embodiment of the present application, the corresponding burning parameter file is acquired based on the model, which can include:

[0034] sending a parameter request carrying the model to a parameter server;

[0035] receiving the burning parameter file corresponding to the model fed back by the parameter server;

[0036] acquiring the hardware fingerprint of the storage device to be burned and verifying the model based on the hardware fingerprint;

[0037] when the verification is passed, the received burning parameter file is taken as the acquired burning parameter file corresponding to the model.

[0038] The embodiment considers that the present application generates the burning parameter file corresponding to the model of the storage device for different models of the storage device, and in order to facilitate the management of the burning parameter file, the burning parameter files can be uniformly stored in the parameter server, and when needed, the parameter request carrying the model can be sent to the parameter server, and the parameter server can feed back the burning parameter file corresponding to the model.

[0039] And the embodiment considers that the model of the storage device to be burned is obtained through image recognition. In actual application, due to unexpected situations such as the two-dimensional code pasted on the surface of the storage device to be burned being incorrectly pasted / replaced or the image recognition process being abnormal, the wrong model may be identified. To this end, in the embodiment, the hardware fingerprint of the storage device to be burned is also obtained. The hardware fingerprint is a unique identifier generated based on physical hardware features, so the hardware fingerprint can play a role in verifying the "hardware real identity" and the "external identification declaration". For example, in actual application, hardware detection can be performed through a voltage sensor and a resistance network (such as reading the values of related registers through I2C), and an N-bit hardware fingerprint (MD5 hash value) is generated. After obtaining the hardware fingerprint, the model can be checked based on the hardware fingerprint, that is, based on the hardware fingerprint, it is verified whether the identified model meets the relevant rules, so as to determine whether the model and the hardware fingerprint are matched. If they are matched, the check is passed, otherwise it can be determined that the check is not passed.

[0040] When the check is passed, the received burning parameter file can be taken as the obtained burning parameter file corresponding to the model of the storage device to be burned. When the check is not passed, the burning process can be paused and the staff can be notified to intervene in the processing. For example, after the staff checks the relevant information, it is found that the two-dimensional code pasted on the surface of the storage device to be burned is incorrectly pasted, and then the two-dimensional code can be replaced.

[0041] In a specific embodiment of the application, the burning parameter file corresponding to the model fed back by the parameter server includes:

[0042] The burning parameter file corresponding to the model fed back by the parameter server is received through a secure transmission protocol.

[0043] The integrity of the received burning parameter file is checked based on the secure transmission protocol.

[0044] When the integrity check is not passed, the burning parameter file is discarded and the parameter request carrying the model is re-sent to the parameter server.

[0045] The implementation considers that the process of receiving the programming parameter file fed back by the parameter server may cause the received programming parameter file to be incorrect due to network fluctuations and other factors. To this end, the implementation uses a secure transmission protocol to ensure the reliability and security of transmission. For example, in a specific implementation, a secure transmission protocol of HTTPS2.0+AES-256-GCM encryption is used. Before feeding back the programming parameter file, the parameter server performs AES block encryption (128-bit key, CBC mode) and adds an HMAC-SHA256 check code to ensure transmission integrity and prevent tampering with the parameters. After receiving the programming parameter file fed back by the parameter server, the received programming parameter file can be integrity-verified based on the secure transmission protocol. When the integrity verification is passed, it can be determined that the received programming parameter file is a correct programming parameter file and no data error or tampering has occurred. Conversely, if the integrity verification of the programming parameter file fails, the programming parameter file can be discarded directly, and the parameter server can be requested to resend the programming parameter file again.

[0046] Step S103: obtaining the compiled target firmware by analyzing the programming parameter file and performing parameter injection on the general firmware data.

[0047] After obtaining the required programming parameter file, the programming parameter file can be analyzed to perform parameter injection on the general firmware data to obtain the compiled target firmware. For example, in a specific implementation, the hardware configuration parameters in the programming parameter file can be analyzed in real time by using a built-in Lua script, and the firmware compilation parameter interface reserved in the script can be used to perform parameter injection on the general firmware data to implement firmware compilation and finally obtain the compiled target firmware.

[0048] Step S104: performing firmware programming on the storage device to be programmed by using the target firmware, and dynamically updating the actual programming voltage based on the reference programming voltage and the temperature offset during the programming process.

[0049] After obtaining the target firmware, the target firmware can be used to perform firmware programming on the storage device to be programmed. In addition, the present application considers that the temperature of the storage device to be programmed may change during the programming process. If a fixed programming voltage is used, it cannot guarantee good programming results at different temperatures. Therefore, in the present application, the actual programming voltage is dynamically updated based on the reference programming voltage and the temperature offset during the programming process, thereby reducing the influence of temperature changes on the programming process and ensuring the reliability of the programming.

[0050] In one specific embodiment of the present application, during the burning process, the actual burning voltage is dynamically updated based on the reference burning voltage and the temperature offset, which can specifically include:

[0051] During the burning process, the actual burning voltage is dynamically updated according to the rule of V adj = V base × (1+k△T) based on the reference burning voltage and the temperature offset;

[0052] Wherein, V base is the reference burning voltage set in the burning parameter file. Different models of storage devices may have different reference voltages, that is, the reference voltage is determined by the hardware characteristics of the storage device (such as the model of the master control chip, the type of NAND particles, etc.). When the storage device to be burned is at the reference temperature, burning with V base can ensure normal read and write operations, that is, to ensure the reliability of burning.

[0053] K is the temperature coefficient set in the burning parameter file, which is used to measure the degree of influence of temperature change on the burning voltage. In different storage devices, due to differences in hardware materials and processes, the temperature coefficient may be different. For example, the k set in the burning parameter file of a certain model of storage device is 0.001 / ℃, which means that for every 1℃ change in temperature, the burning voltage will be adjusted by a certain percentage based on the reference voltage.

[0054] △T is the difference between the actual temperature of the storage device to be burned and the reference temperature. Taking the SSD as an example, △T reflects the temperature offset of the NAND particles of the SSD. During the burning process, the NAND particles will generate heat due to current passing through, etc., causing the temperature to change, of course, changes in ambient temperature will also cause the temperature of the NAND particles to change. For example, the reference temperature is 25℃, and the temperature of the NAND particles rises to 30℃ during the burning process, then △T is 30℃-25℃=5℃.

[0055] V adj is the actual burning voltage, that is, the burning voltage required after dynamic adjustment. The present application considers that the burning process of NAND flash memory is essentially to inject electrons into the floating gate transistor to change its threshold voltage, thereby encoding data (0 / 1) into the storage cell. However, temperature changes will significantly affect the efficiency of electron injection and the stability of the threshold voltage. Specifically, the carrier mobility of the semiconductor material increases, and electrons are more likely to escape from the channel region to the floating gate (or vice versa), resulting in the need for a higher injection voltage to reach the threshold voltage. If the voltage remains unchanged, it may result in insufficient electron injection, which is prone to misjudgment as "0" (missed reading) during subsequent reading. Therefore, in order to ensure the reliability of burning, the present application increases the value of the burning voltage when the temperature rises, that is, V adjWill increase.

[0056] Correspondingly, when the temperature decreases, the carrier mobility decreases, the electron injection becomes more difficult, and if the original voltage is still used, it may take longer to complete the injection, not only the efficiency is reduced, but also the floating gate may be broken (oxide damage) or adjacent cells may be disturbed (crosstalk) due to overvoltage. Therefore, when the temperature decreases, the value of the programming voltage in the scheme of the present application will be reduced, that is, V adj Will decrease.

[0057] In one specific embodiment of the present application, it can also include:

[0058] During the programming process, fault detection is performed based on the hardware sensor, and the obtained fault detection result is taken as the first fault detection result;

[0059] An execution log of the programming process is obtained, fault detection is performed based on the execution log, and the obtained fault detection result is taken as the second fault detection result;

[0060] During the programming process, fault detection is performed on the bus signal, and the obtained fault detection result is taken as the third fault detection result;

[0061] Based on the first fault detection result, the second fault detection result, and the third fault detection result, the final fault detection result of the firmware programming of the to-be-programmed storage device this time is obtained.

[0062] When determining whether the programming process is abnormal, the traditional abnormality detection scheme is not comprehensive and accurate. For example, it usually only relies on logs (such as ECC error correction failure) for determination, resulting in a high rate of missed detection, and it is difficult to detect hardware abnormalities, such as bus signal fluctuations caused by loose hardware connections, which cannot be detected. If multiple data are used to determine programming abnormalities, because they are multidimensional and heterogeneous observations of system state, each has its own limitations, making it difficult to accurately determine whether the programming process is abnormal when the conclusions of multiple data conflict.

[0063] To this end, the scheme of the present application considers that the detection system can be constructed by three types of data, such as detection data of hardware sensors (such as hardware state data collected by temperature sensors and voltage sensors in real time), execution logs in the burning process (operation logs and error codes generated in the burning process, such as ECC check results), and communication protocol data (protocol layer data such as bus signal integrity and transmission delay). In addition, because the three types of data all have "unknown" or "ambiguous" information (such as unreliable data caused by sensor drift, incomplete logs), and the data formats and dimensions are completely different (sensor is numerical value, log is text, and communication protocol is message), and reflect the system state from the physical layer, the logical layer, and the interaction layer, respectively, and when used alone, it may be misjudged (such as based on the detection data of hardware sensors, the burning process is normal, but the log reports a logical error, and actually the burning process is abnormal), therefore, when performing comprehensive analysis, the D-S evidence theory is used for evidence fusion in the embodiments hereinafter, which can effectively handle uncertainty, realize fusion of heterogeneous data, achieve comprehensive multi-source complementary information, and improve the accuracy and reliability of the burning abnormality detection.

[0064] Of course, in addition to using the D-S evidence theory for evidence fusion, some simple fusion methods can also be selected, for example, in one occasion, based on hardware sensors for fault detection, the obtained fault detection result is taken as a first fault detection result, and the first fault detection result is specifically "burning abnormality", that is, according to the hardware sensor for fault detection, one or more hardware parameter abnormalities can be determined, and then according to the corresponding hardware fault judgment rule, the determination result of "burning abnormality" is obtained as the first fault detection result.

[0065] Similarly, for example, based on the execution log for fault detection, the obtained fault detection result is taken as a second fault detection result and specifically as "burning abnormality", that is, according to the execution log for fault detection, based on the corresponding execution log abnormality judgment rule, the determination result of "burning abnormality" is obtained as the second fault detection result.

[0066] For example, the obtained fault detection result is taken as a third fault detection result, and specifically as "burning normality", that is, after fault detection on the bus signal, it is confirmed that on the signal transmission layer, the determination result of "burning normality" is obtained as the third fault detection result.

[0067] Finally, when the first fault detection result (specifically "abnormal burning" in the above example), the second fault detection result (specifically "abnormal burning" in the above example), and the third fault detection result (specifically "normal burning" in the above example) are comprehensively analyzed to obtain the final fault detection result of the firmware burning of the storage device to be burned this time, it can be determined whether at least one of the first fault detection result, the second fault detection result, and the third fault detection result is "abnormal burning". If so, the final fault detection result obtained is that the firmware burning of the storage device to be burned this time is abnormal. Otherwise, if all three fault detection results are "normal burning", the final fault detection result obtained is that the firmware burning of the storage device to be burned this time is normal. This example can comprehensively analyze the first fault detection result, the second fault detection result, and the third fault detection result to obtain the final fault detection result, which is relatively simple. Of course, the implementation method using D-S evidence theory for evidence fusion in the following text has higher reliability.

[0068] In one specific embodiment of the present application, the first fault detection result, the second fault detection result, and the third fault detection result each include four confidence levels: a first confidence level for representing abnormal burning, a second confidence level for representing normal burning, a third confidence level for representing an empty set, and a fourth confidence level for representing uncertainty about whether it is abnormal.

[0069] Based on the first fault detection result, the second fault detection result, and the third fault detection result, the final fault detection result of the firmware burning of the storage device to be burned this time is obtained, including:

[0070] The first fault detection result and the second fault detection result are orthogonally synthesized in confidence level by evidence theory, and the synthesis result obtained is orthogonally synthesized in confidence level with the third fault detection result to obtain the final detection result of the firmware burning this time.

[0071] When the first confidence level for representing abnormal burning in the final detection result is greater than or equal to a target threshold, it is determined that the firmware burning of the storage device to be burned this time is abnormal, otherwise it is determined that the firmware burning of the storage device to be burned this time is normal.

[0072] This embodiment takes into account that the first fault detection result, the second fault detection result, and the third fault detection result respectively reflect the system state from the physical layer, the logical layer, and the interaction layer, and may be misjudged when used alone (for example, based on the detection data of the hardware sensor, the burning process is normal, but the log reports a logical error, and actually the burning process is abnormal). Therefore, when performing comprehensive analysis, this embodiment specifically uses D-S evidence theory for evidence fusion, which can effectively handle uncertainty, realize the fusion of heterogeneous data, achieve the comprehensive analysis of multi-source complementary information, and improve the accuracy and reliability of the burning abnormality detection.

[0073] In this embodiment, the first fault detection result, the second fault detection result and the third fault detection result are three pieces of evidence, each of which can include the confidence of four propositions, denoted as m i (H0), m i (H1), m i (Φ) and m i (Θ), the four propositions are "burning abnormality", "burning normality", "empty set" and "uncertain abnormality". The subscript i represents the ith piece of evidence (i = 1, 2, 3). Taking i = 1 as an example, m1(H0) is the confidence of the proposition "burning abnormality" in the first piece of evidence, i.e. the first confidence in the first piece of evidence, m1(H1) is the confidence of the proposition "burning normality" in the first piece of evidence, i.e. the second confidence in the first piece of evidence, m1(Φ) is the confidence of the proposition "empty set" in the first piece of evidence, i.e. the third confidence in the first piece of evidence, and the empty set represents meaningless. m1(Θ) is the confidence of the proposition "uncertain abnormality" in the first piece of evidence, i.e. the fourth confidence in the first piece of evidence. In addition, in order to normalize and facilitate subsequent calculation, it is limited that:

[0074] m i (H0) + m i (H1) + m i (Φ) + m i (Θ) = 1.

[0075] In the burning process, fault detection based on hardware sensors is needed, and the obtained fault detection result can be used as the first fault detection result. For example, in one specific embodiment, temperature collection (e.g. precision of ±1℃) can be performed through a temperature sensor, and power supply voltage collection (e.g. precision of ±0.1%) can be performed through a voltage sensor. When the chip temperature of the storage device >85℃ and / or the power supply voltage fluctuation >±5%, it can be determined that the burning is abnormal and a larger value of m1(H0) can be generated. The higher the chip temperature and the greater the power supply voltage fluctuation, the larger the value of m1(H0) can be. Of course, the specific value rules of m1(H0), m1(H1) and m1(Θ) can be set according to actual needs, and the fault condition based on the hardware sensor can be effectively reflected through the value of m1(H0), m1(H1) and m1(Θ). In addition, m1(Φ) can be set to 0.

[0076] When performing fault detection based on the execution log, for example, when the number of ECC correction times is greater than 1024 bits for N consecutive times and / or the programming timeout is greater than 500 ms / page, it is determined that the burning is abnormal, and a larger value of m2(H0) is generated. And the more the number of ECC correction times, the longer the programming timeout, the larger the value of m2(H0) can be. Of course, the specific value rules of m2(H0), m2(H1) and m2(Θ) can be set according to actual needs, and the value size of m2(H0), m2(H1) and m2(Θ) can effectively reflect the fault condition based on the execution log. In addition, m2(Φ) can be set to 0.

[0077] In the burning process, the fault detection result obtained by detecting the bus signal as the third fault detection result, for example, the bus error rate and the number of CRC check failures can be detected, when the bus error rate is greater than 0.1% and the number of CRC check failures is greater than 5 times per second, it can be determined that the burning is abnormal, and a larger value of m3(H0) is generated. The larger the bus error rate, the larger the number of CRC check failures, the larger the value of m3(H0) can be. Similarly, the specific value rules of m3(H0), m3(H1) and m3(Θ) can be set according to actual needs, and the value size of m3(H0), m3(H1) and m3(Θ) can effectively reflect the fault condition based on the bus signal. In addition, m3(Φ) can be set to 0.

[0078] Since there are three evidence bodies in the scheme of the present application, two evidences can be first orthogonally synthesized, and then the result is orthogonally synthesized with the third evidence. In this embodiment, the confidence of the first fault detection result and the second fault detection result is first orthogonally synthesized by evidence theory, and the obtained synthesis result is orthogonally synthesized with the third fault detection result to obtain the final confidence indicating that the firmware burning is abnormal this time.

[0079] Table 1: Principle diagram of orthogonal synthesis of two evidence bodies

[0080]

[0081] Next, taking Table 1 as an example, the process of orthogonally synthesizing the confidence of the first fault detection result and the second fault detection result is described. As described above, the first fault detection result (i.e. the first evidence body) can include four confidences (i.e. the confidences of the four propositions in the first evidence body): m1(H0), m1(H1), m1(Φ) and m1(Θ), and the second fault detection result (i.e. the second evidence body) can include four confidences (i.e. the confidences of the four propositions in the second evidence body): m2(H0), m2(H1), m2(Φ) and m2(Θ).

[0082] The orthogonal combination of the confidence degrees of the first fault detection result and the second fault detection result, that is, the orthogonal combination of the respective confidence degrees of the four propositions in the first evidence body and the respective confidence degrees of the four propositions in the second evidence body, the synthesis result obtained after the orthogonal combination includes four confidence degrees, that is, the synthesis result obtained after the orthogonal combination is the respective confidence degrees of the four propositions (H0, H1, Phi and Theta) after synthesizing the first fault detection result and the second fault detection result.

[0083] The synthesis formula can be expressed as: .

[0084] A, B, C in the formula all refer to the propositions (H0, H1, Phi and Theta), and A is the intersection of B and C. K is a conflict coefficient, reflecting the conflict degree of the two evidence bodies, so if the two evidence bodies are completely conflicting and cannot be combined, K = 1. In the scheme of the present application, the first fault detection result, the second fault detection result and the third fault detection result respectively represent three different detection directions (hardware sensor / log / communication), so there is no conflict between the three evidence bodies, and K can be directly set to 0.

[0085] For example, in a specific case, based on the fault detection result of the hardware sensor, it is determined that m1(H0) = 0.7, m1(H1) = 0, m1(Phi) = 0, m1(Theta) = 0.3, based on the execution log, it is determined that m2(H0) = 0.8, m2(H1) = 0, m2(Phi) = 0, m2(Theta) = 0.2, and based on the communication detection of the bus, it is determined that m3(H0) = 0.6, m3(H1) = 0, m3(Phi) = 0, m3(Theta) = 0.4.

[0086] When the orthogonal combination of the confidence degrees of the first fault detection result and the second fault detection result is performed, the calculation of the confidence degree of the proposition "H0" in the synthesis result can be expressed as:

[0087] m 1，2 (H0) = m1(H0)m2(H0) + m1(H0)m2(Theta) + m1(Theta)m2(H0) = 0.7x0.8 + 0.7x0.2 + 0.3x0.8 = 0.56 + 0.14 + 0.25 = 0.94, that is, when the orthogonal combination of the confidence degrees of the first fault detection result and the second fault detection result is performed, the confidence degree of the proposition "burning exception" in the synthesis result is 0.94. In order to facilitate viewing, the intersection of the proposition B and the proposition C as the proposition A (that is, H0) in Table 1 is marked in bold.

[0088] Similarly, m 1，2(H1) = m1(H1)m2(H1) + m1(H1)m2(Θ) + m1(Θ)m2(H1). Since m1(H1) = 0 and m2(H1) = 0 in the example above, therefore m 1，2 (H1) = 0. That is to say, when the confidence scores of the first fault detection result and the second fault detection result are orthogonally combined, the confidence score of the proposition "programming is normal" in the combined result is 0.

[0089] Similarly, we can obtain m 1，2 (Φ) = 0, m 1，2 (Θ) = m1(Θ)m2(Θ) = 0.3 × 0.2 = 0.06. That is to say, when the confidence of the first fault detection result and the second fault detection result are orthogonally synthesized, the confidence of the proposition "empty set" in the synthesized result is 0, and the confidence of the proposition "uncertain whether the burning is normal" in the synthesized result is 0.06.

[0090] At this point, the orthogonal synthesis of the confidence levels of the first and second fault detection results has been completed. Then, following the same principle, the synthesis result is orthogonally synthesized with the confidence level of the third fault detection result to obtain the final detection result of this firmware burning.

[0091] As can be seen in the example above, we can obtain m. 1，2，3 (H0) = m 1,2 (H0)m3(H0)+m 1,2 (H0)m3(Θ)+m 1,2 (Θ)m3(H0)=0.96×0.6+0.96×0.4+0.06×0.4=0.564+0.376+0.036=0.976, which means that the confidence level of the proposition "programming abnormality" in the final test result is 0.976.

[0092] Similarly, we can obtain m 1，2，3 (H1) = m 1,2 (H1)m3(H1)+m 1,2 (H1)m3(Θ)+m 1,2 (Θ)m3(H1), since m in the above example 1,2 (H1) = 0 and m3(H1) = 0, therefore m 1，2，3 (H1) = 0. In other words, the confidence level of the proposition "programming is normal" in the final test result is 0.

[0093] Similarly, we can obtain m 1，2，3 (Φ) = 0, m 1，2，3 (Θ) = m 1，2(H0) m3(0) = 0.06 * 0.4 = 0.024, that is, the confidence degree of the final detection result about the proposition of "empty set" is 0, and the confidence degree of the final detection result about the proposition of "uncertain whether the burning is normal" is 0.024.

[0094] If the first confidence degree for representing the burning abnormality in the final detection result is greater than or equal to the target threshold value, it can be determined that the firmware burning of the to-be-burned storage device is abnormal this time, and in the above example, the first confidence degree for representing the burning abnormality in the final detection result is m 1，2，3 (H0) which is specifically 0.976, is a very high value, and it can be determined that the firmware burning of the to-be-burned storage device is abnormal this time. In actual application, the specific value of the target threshold value can be set and adjusted according to actual needs, for example, the target threshold value is set to 0.6 in one occasion, and m 1，2，3 The value of (H0) is greater than 0.6, and it can be determined that the firmware burning of the to-be-burned storage device is abnormal this time, otherwise, it is determined that the firmware burning of the to-be-burned storage device is normal this time.

[0095] In one specific embodiment of the present application, if it is determined that the firmware burning of the to-be-burned storage device is abnormal this time, the first fault detection result and the second fault detection result are orthogonally synthesized in confidence degree by the evidence theory, and the target data is subtracted from the first confidence degree for representing the burning abnormality in the obtained synthesis result, as the contribution degree of the third fault detection result.

[0096] The second fault detection result and the third fault detection result are orthogonally synthesized in confidence degree by the evidence theory, and the target data is subtracted from the first confidence degree for representing the burning abnormality in the obtained synthesis result, as the contribution degree of the first fault detection result.

[0097] The first fault detection result and the third fault detection result are orthogonally synthesized in confidence degree by the evidence theory, and the target data is subtracted from the first confidence degree for representing the burning abnormality in the obtained synthesis result, as the contribution degree of the second fault detection result.

[0098] When the contribution degree of the first fault detection result is the largest, the hardware fault is taken as the fault contribution source.

[0099] When the contribution degree of the second fault detection result is the largest, the log is taken as the fault contribution source.

[0100] When the contribution degree of the third fault detection result is the largest, the bus communication is taken as the fault contribution source.

[0101] Wherein, the target data is the first confidence degree for representing the burning abnormality in the final detection result.

[0102] The implementation considers that in the D-S evidence theory fusion process, the "marginal contribution" refers to the independent influence degree of a single evidence body on the final fusion result, that is, the "evidence weight" of the D-S evidence theory can be inversely tracked according to the evidence contribution degree. In the implementation of the present application, the fault contribution source can be determined according to the "contribution degree" of each evidence body to the final abnormal result.

[0103] Specifically, for any one evidence body, its marginal contribution can be reflected in the contribution of the remaining evidence bodies to the final fusion result after it is removed. Taking the first evidence body of the present application scheme, that is, the first fault detection result, as an example, after removing the first fault detection result, the fusion of the second fault detection result and the third fault detection result is needed, that is, the confidence orthogonal synthesis of the second fault detection result and the third fault detection result is performed by the evidence theory, and the first confidence degree for representing the burning abnormality in the target data (the first confidence degree for representing the burning abnormality in the final detection result) is subtracted from the first confidence degree for representing the burning abnormality in the obtained synthesis result, as the contribution degree of the first fault detection result. It can be seen that the smaller the contribution degree of the first fault detection result, the smaller the influence of removing the first fault detection result on the m 2，3 (H0) in the final detection result. 1，2，3 The closer (H0) in the final detection result is, the smaller the influence of removing the first fault detection result on the m 1，2，3 (H0) is, and thus it is more explained that the first fault detection result is not the reason for leading to the conclusion of "burning abnormality". Conversely, the greater the contribution degree of the first fault detection result, the greater the influence of removing the first fault detection result on the m 2，3 (H0) in the final detection result. 1，2，3 The farther (H0) in the final detection result deviates, that is, the greater the influence of removing the first fault detection result, and thus it is more explained that the first fault detection result is the reason for leading to the conclusion of "burning abnormality".

[0104] Therefore, when the contribution degree of the first fault detection result is the largest, the hardware fault is taken as the fault contribution source, when the contribution degree of the second fault detection result is the largest, the log is taken as the fault contribution source, and when the contribution degree of the third fault detection result is the largest, the bus communication is taken as the fault contribution source.

[0105] Taking the numerical value in the above example as an example for calculation, after removing the third fault detection result, the confidence orthogonal synthesis of the first fault detection result and the second fault detection result is performed by the evidence theory, and the first confidence degree for representing the burning abnormality in the obtained synthesis result is m 1，2(H0) = m1(H0)m2(H0) + m1(H0)m2(Θ) + m1(Θ)m2(H0) = 0.7*0.8 + 0.7*0.2 + 0.3*0.8 = 0.56 + 0.14 + 0.25 = 0.94, subtracting 0.94 from the first confidence degree 0.976 representing the burning abnormality in the final detection result, 0.036 is obtained, and thus 0.036 can be taken as the contribution degree of the third fault detection result.

[0106] After removing the first fault detection result, the second fault detection result and the third fault detection result are orthogonally synthesized in the confidence degree by the evidence theory, and in the synthesis result, the first confidence degree representing the burning abnormality is m 2，3 (H0) = m2(H0)m3(H0) + m2(H0)m3(Θ) + m2(Θ)m3(H0) = 0.8*0.6 + 0.8*0.4 + 0.2*0.6 = 0.48 + 0.32 + 0.12 = 0.92, subtracting 0.92 from the first confidence degree 0.976 representing the burning abnormality in the final detection result, 0.056 is obtained, and thus 0.056 can be taken as the contribution degree of the first fault detection result.

[0107] After removing the second fault detection result, the first fault detection result and the third fault detection result are orthogonally synthesized in the confidence degree by the evidence theory, and in the synthesis result, the first confidence degree representing the burning abnormality is m 1，3 (H0) = m1(H0)m3(H0) + m1(H0)m3(Θ) + m1(Θ)m3(H0) = 0.7*0.6 + 0.7*0.4 + 0.3*0.6 = 0.42 + 0.28 + 0.18 = 0.88, subtracting 0.88 from the first confidence degree 0.976 representing the burning abnormality in the final detection result, 0.096 is obtained, and thus 0.096 can be taken as the contribution degree of the second fault detection result.

[0108] In this embodiment, the contribution degree of the second fault detection result is 0.096, which is the maximum value among 0.036, 0.096 and 0.056, and thus it is indicated that the influence of removing the second fault detection result is the largest, and thus it is indicated that the second fault detection result is the reason leading to the conclusion of the burning abnormality. Therefore, in this example, it can be determined that the log is the fault contribution source, and thus it is indicated that the fault condition determined by executing the log is most likely the fault reason actually leading to the burning abnormality.

[0109] It can be seen that in this embodiment, the most likely fault source can be effectively determined based on the first fault detection result, the second fault detection result and the third fault detection result, and the fault positioning and the fault type determination are realized.

[0110] In one specific embodiment of the present application, the following can also be included:

[0111] After the hardware failure is taken as the fault contribution source, the fault is repaired through the first repair strategy and in combination with the fault detection data of the hardware sensor data, and the firmware burning is re-performed after the fault repair;

[0112] After the log is taken as the fault contribution source, the firmware burning version is switched according to the second repair strategy, and the firmware burning is re-performed after the switching;

[0113] After the bus communication is taken as the fault contribution source, the bus communication diagnosis and the particle health degree detection are performed according to the third repair strategy, and the results are output.

[0114] This embodiment considers that, for the hardware failure, many times are temporary failures, so after the hardware failure is taken as the fault contribution source, the fault repair can be attempted through the first repair strategy in combination with the fault detection data of the hardware sensor data, and the firmware burning is re-performed after the fault repair. The specific means of repairing the fault can be set according to actual needs, for example, the supply voltage can be increased when the actual voltage is lower than the required supply voltage, and the chip temperature is cooled down when the chip temperature is too high, to repair some temporary faults. Of course, if it is determined to be an unrepairable hardware failure according to the fault detection data of the hardware sensor data, manual repair can be notified.

[0115] This embodiment considers that, after the log is taken as the fault contribution source, for some failures reported by the execution log, the firmware burning version can be switched for processing, for example, in one embodiment, when it is determined that the ECC check fails continuously (more than 5 times) according to the second repair strategy, the firmware burning version can be switched, at this time, the historical adaptation parameters of the same type are called from the parameter server, and the firmware burning is re-performed after the switching, so as to solve the compatibility problem of the firmware and the hardware.

[0116] This embodiment considers that, after the bus communication is taken as the fault contribution source, it is usually not automatically repaired, but the bus communication diagnosis and the particle health degree detection can be performed according to the third repair strategy, and the results are output to assist subsequent processing of the staff.

[0117] For example, the NAND particle health degree detection can be performed by reading the bad block table in the reserved block in combination with the erase count, to realize the calculation of the remaining life parameters of the particle.

[0118] When performing bus communication diagnosis, a test data packet of a specified data size (such as 128 KB) can be sent, an eye diagram of the bus is analyzed, signal integrity problems (such as impedance mismatch and crosstalk) are located, fault information containing pin coordinates is generated, and the fault information is pushed to the operation and maintenance terminal through the WebSocket.

[0119] The application scheme considers that the firmware can be decoupled into general firmware data and a burning parameter file. The general firmware data is a core function module of the firmware. For example, the general firmware data can have basic functions such as data read-write control, ECC check algorithm, and life cycle management, and the general firmware data has not been parameter-injected to have general applicability. For different models of storage devices, a burning parameter file corresponding to the model of the storage device is generated according to the burning requirements of the storage device of the model. Subsequently, in the burning process, the model of the storage device to be burned can be identified, and then the corresponding burning parameter file is acquired. After the burning parameter file is parsed, the general firmware data can be parameter-injected to obtain a target firmware that is compiled and can be burned to the storage device to be burned.

[0120] As can be seen, in the application scheme, the general firmware data with general applicability + the specific burning parameter file are used to obtain the required target firmware, which can effectively reduce the firmware compilation cost. In addition, in the burning process, the burning voltage is not fixed, but is dynamically updated based on the reference burning voltage and the temperature offset, which is beneficial to reduce the influence of temperature change on the burning process and ensure the reliability of the burning.

[0121] Corresponding to the above method and system embodiments, the application embodiments also provide an electronic device, a computer readable storage medium, and a computer program product, which can be mutually corresponding and referred to above.

[0122] Referring to Figure 2 As shown in the figure, the device can include:

[0123] The memory 201 is configured to store a computer program.

[0124] The processor 202 is configured to execute the computer program to implement the steps of the firmware burning method in any of the above embodiments.

[0125] The computer program product includes computer programs / instructions that are executed by the processor to implement the steps of the firmware burning method in any of the above embodiments.

[0126] Referring to Figure 3The computer readable storage medium 30 stores a computer program 31, which, when executed by the processor, implements the steps of the firmware programming method in any of the above embodiments. The computer readable storage medium 30 mentioned herein includes a RAM (Random Access Memory), an internal memory, a ROM (Read-Only Memory), an EEPROM (Electrically Erasable Programmable Read-Only Memory), a register, a hard disk, a removable disk, or any other form of storage medium known in the art.

[0127] Those skilled in the art will further appreciate that the individual steps of the example methods described in connection with the embodiments disclosed herein can be embodied in electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various examples have been described herein in terms of their general functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

[0128] The above provides a detailed description of the firmware programming method and electronic device provided by the present application. The principles and implementation modes of the present application are described herein by applying specific examples, and the above description of the examples is only applicable to help understand the method of the present application and its core idea. It should be pointed out that, for those skilled in the art, without departing from the principles of the present application, a number of improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the present application.

Claims

1. A firmware burning method, characterized in that, include: Generate general firmware data for parameter injection to be completed, and generate burning parameter files corresponding to the model of the storage device for different models of storage devices; Obtain the model number of the storage device to be programmed and obtain the corresponding programming parameter file based on the model number; By parsing the burning parameter file and injecting parameters into the general firmware data, the compiled target firmware is obtained; The target firmware is used to flash the firmware onto the storage device to be flashed, and during the flashing process, the actual flashing voltage is dynamically updated based on the reference flashing voltage and temperature offset. During the programming process, the actual programming voltage is dynamically updated based on the reference programming voltage and temperature offset, including: During the programming process, based on the reference programming voltage and temperature offset, according to V adj =V base The rule of ×(1+k△T) is used to dynamically update the actual programming voltage; Among them, V base The reference programming voltage is set in the programming parameter file, k is the temperature coefficient set in the programming parameter file, ΔT is the difference between the actual temperature of the storage device to be programmed and the reference temperature, and V is the reference programming voltage. adj This is the actual programming voltage; Also includes: During the programming process, fault detection is performed based on hardware sensors, and the obtained fault detection result is used as the first fault detection result. Obtain the execution log of the burning process, perform fault detection based on the execution log, and use the obtained fault detection result as the second fault detection result; During the programming process, fault detection is performed on the bus signal, and the obtained fault detection result is used as the third fault detection result. Based on the first fault detection result, the second fault detection result, and the third fault detection result, the final fault detection result of the firmware burning of the storage device to be burned is obtained.

2. The firmware burning method according to claim 1, characterized in that, Obtain the model number of the storage device to be programmed, including: The image of the storage device to be burned is acquired using an image acquisition device; The model label in the image is identified to obtain the model of the storage device to be burned.

3. The firmware burning method according to claim 1, characterized in that, Based on the aforementioned model, obtain the corresponding programming parameter file, including: Send a parameter request carrying the model number to the parameter server; Receive the programming parameter file corresponding to the model from the parameter server; Obtain the hardware fingerprint of the storage device to be programmed and verify the model based on the hardware fingerprint; When the verification is successful, the received programming parameter file will be used as the programming parameter file corresponding to the model.

4. The firmware burning method according to claim 3, characterized in that, The parameter server receives the programming parameter file corresponding to the model number, including: The system receives the programming parameter file corresponding to the model number from the parameter server via a secure transmission protocol. Based on the aforementioned secure transmission protocol, the integrity of the received programming parameter file is verified. If the integrity check fails, discard the burning parameter file and resend the parameter request carrying the model number to the parameter server.

5. The firmware burning method according to claim 1, characterized in that, The first fault detection result, the second fault detection result, and the third fault detection result all include four confidence levels: a first confidence level representing abnormal burning, a second confidence level representing normal burning, a third confidence level representing an empty set, and a fourth confidence level representing uncertainty about whether it is abnormal. Based on the first fault detection result, the second fault detection result, and the third fault detection result, the final fault detection result of this firmware burning process for the storage device to be burned is obtained, including: The confidence scores of the first fault detection result and the second fault detection result are orthogonally synthesized using evidence theory, and the synthesized result is orthogonally synthesized with the confidence score of the second fault detection result to obtain the final detection result of this firmware burning. When the first confidence level used to represent the burning anomaly in the final detection result is greater than or equal to the target threshold, it is determined that the firmware burning of the storage device to be burned is abnormal; otherwise, it is determined that the firmware burning of the storage device to be burned is normal.

6. The firmware burning method according to claim 5, characterized in that, Also includes: If it is determined that the firmware burning of the storage device to be burned is abnormal, then the confidence of the first fault detection result and the second fault detection result are orthogonally synthesized using evidence theory, and the first confidence of the synthesized result representing the burning abnormality is subtracted from the target data as the contribution of the third fault detection result. The confidence levels of the second fault detection result and the third fault detection result are orthogonally synthesized using evidence theory, and the first confidence level representing the burning anomaly in the synthesized result is subtracted from the target data, which is then used as the contribution of the first fault detection result. The confidence scores of the first fault detection result and the third fault detection result are orthogonally synthesized using evidence theory. The first confidence score representing the burning anomaly in the synthesized result is subtracted from the target data, and this is taken as the contribution of the second fault detection result. When the contribution of the first fault detection result is the greatest, the hardware fault is taken as the fault contribution source. When the contribution of the second fault detection result is the greatest, the log is used as the source of fault contribution; When the contribution of the third fault detection result is the greatest, bus communication is taken as the source of fault contribution. The target data is the first confidence level used to represent the burning anomaly in the final detection result.

7. The firmware burning method according to claim 6, characterized in that, Also includes: After identifying hardware failure as the source of failure, the first repair strategy is used in conjunction with the fault detection data from hardware sensors to repair the failure, and then the firmware is re-flashed after the failure is repaired. After identifying the logs as the source of the fault, the firmware flashing version was switched according to the second repair strategy, and the firmware was flashed again after the switch. After identifying bus communication as a source of fault contribution, bus communication diagnostics and particle health checks are performed according to the third repair strategy, and the results are output.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the firmware burning method as described in any one of claims 1 to 7 when executing the computer program.

Images