Flash memory firmware deployment method and system and flash memory

Abstract

The invention relates to the technical field of flash memories, and discloses a flash memory firmware deployment method and system and a flash memory, and the method comprises the following steps: in a first deployment stage, carrying out grade division on all firmware, and carrying out interval division on a storage space used for running the firmware in the flash memory, each section of subspace is used for designating to operate firmware of different grades; then, adding the level information of the firmware into the initial compiling file of the corresponding firmware, and packaging the firmware to obtain a firmware compiling package file; in a second deployment stage, burning the firmware compiling package file into the flash memory, and executing a firmware saving strategy according to the extracted firmware level information; and finally, detecting whether the firmware is successfully deployed. According to the method, the reliability of the flash memory can be guaranteed to the greatest extent, the probability of product failure caused by firmware loss is reduced, and the performance influence caused by firmware read return is reduced.

Description

Technical Field

[0001] The present application relates to the technical field of flash memory, and in particular to a flash memory firmware deployment method, system and flash memory. Background Art

[0002] Most flash memory-based storage products, such as EMMC (Embedded MultiMedia Card), UFS (Universal Flash Storage) embedded storage chips, and SSD (Solid State Disk), store the firmware on the SLC Block (single-level storage block) of NAND Flash. At startup, the flash controller that loads the firmware from NAND Flash to the memory runs to complete the memory function. Usually, NAND Flash will have bit flips due to various reasons, resulting in firmware loss or the need to retry to read the firmware. If the firmware is lost, the memory directly loses its basic functions. If the number of error bits in the firmware data is high, it will trigger a read retry, which will increase the firmware reading time, thereby affecting the performance of the memory, such as increasing the startup time and reducing IO performance.

[0003] From the perspective of firmware functions, the importance of firmware with different functions is different. For example, the firmware that completes the basic IO function is more important than the firmware responsible for log management. Losing the firmware for log management will not cause the storage to lose the basic IO function, but if the firmware that completes the basic IO function is lost, the storage will not work properly. However, the existing firmware storage solution does not take into account the difference in the importance of firmware, but puts all firmware together equally. If important firmware is stored in a storage space with poor reliability, this approach will increase the probability of firmware loss, thereby affecting the reliability of the entire storage. Summary of the invention

[0004] In view of this, in order to solve at least one of the above problems, an embodiment of the present application provides a flash memory firmware deployment method, system and flash memory.

[0005] In a first aspect, an embodiment of the present application provides a flash memory firmware deployment method, comprising:

[0006] In the first deployment phase, all firmwares are divided into levels, and the storage space in the flash memory used to run the firmware is divided into intervals to obtain a plurality of subspaces having the same number as the firmwares, wherein each subspace is designated to run firmwares of different levels;

[0007] Compile each firmware to obtain its own initial compiled file, add the level information of the corresponding firmware to the initial compiled file of the corresponding firmware, and then package all the firmware information to obtain a firmware compiled package file;

[0008] In a second deployment phase, the firmware compilation package file is transferred to the flash memory, and a firmware preservation strategy is executed according to the level information extracted from the firmware compilation package file;

[0009] It is detected whether the level information of the corresponding firmware matches the saved subspace, and when they match, it is confirmed that the corresponding firmware is deployed successfully.

[0010] In some embodiments, the step of dividing all firmware into levels and dividing the storage space used to run the firmware into intervals to obtain multiple subspaces with the same number of firmware includes:

[0011] All firmware are divided into different levels according to the importance of the firmware; the higher the importance, the higher the level;

[0012] The storage space used to run the firmware is divided into a plurality of subspaces equal to the number of the firmware, and the level of the firmware run by each subspace is specified.

[0013] In some embodiments, after the interval division, the method further includes:

[0014] Generate a firmware level description file based on the correspondence between the subspaces in each segment and the running firmware level;

[0015] The adding the level information of the corresponding firmware to the initial compiled file of the corresponding firmware includes:

[0016] According to the level information of all firmwares recorded in the firmware level description file, a description field of the level information of the corresponding firmware is added to the file name of the initial compiled file of the corresponding firmware.

[0017] In some embodiments, the file name of the initial compiled file of the firmware includes a start address field of a designated subspace for running the firmware, and a space length field;

[0018] The description field for adding the level information of the corresponding firmware includes:

[0019] A level field of the corresponding firmware is added before the start address field or after the space length field.

[0020] In some embodiments, the firmware compiled package file includes a header for describing overall information of the firmware compiled package file and update compiled files of each firmware obtained after adding level information.

[0021] In some embodiments, executing the firmware preservation strategy according to the level information extracted from the firmware compilation package file includes:

[0022] After receiving the firmware compilation package file, the flash memory extracts the level information of the corresponding firmware from the header; then, based on the level information of the corresponding firmware and in combination with the flash memory reliability description file, the error correction code rate of the storage unit used to store the corresponding firmware is determined, and then the corresponding firmware is saved.

[0023] In some embodiments, the flash memory reliability description file includes an error correction code rate required for each storage page in a target storage block for storing firmware under a specific reliability requirement;

[0024] The determining of the error correction code rate of the storage unit for storing the corresponding firmware includes:

[0025] According to the principle that the higher the firmware level, the lower the error correction rate, the error correction rate of the storage page corresponding to the firmware data with different reliability requirements is determined.

[0026] In some embodiments, the flash memory reliability description file also includes the number of storage pages in the target storage block. If the number of storage pages in the target storage block remains after the firmware is saved, the method further includes:

[0027] According to the level information of the current firmware, determine whether to back up the current firmware, and according to the principle that the higher the firmware level, the more backups there are, determine the number of backups according to the remaining number of the storage pages, and then perform firmware backup.

[0028] In some embodiments, when the flash memory does not support the configuration of the error correction code rate function, the method further includes:

[0029] According to the level information of the current firmware and in combination with the flash memory reliability description file, the firmware with a higher level is stored in a flash memory storage page with a higher reliability, and the firmware with a lower level is stored in a flash memory storage page with a lower reliability.

[0030] In some embodiments, the flash memory firmware deployment method further includes:

[0031] After all the firmware are saved, a firmware save map is generated; wherein the firmware save map includes error correction code rate configuration information of each flash memory storage page that has saved the corresponding firmware data, or error correction code rate configuration information and firmware backup information.

[0032] In some embodiments, detecting whether the level of the corresponding firmware matches the saved subspace, and confirming that the corresponding firmware is successfully deployed when they match, includes:

[0033] Performing an aging test on the flash memory, during which the corresponding firmware data is periodically read and a bit flip rate or a number of error bits of the corresponding firmware data is monitored;

[0034] It is determined whether the bit flip rate or the number of error bits matches the level of the corresponding firmware, and when it is determined that the corresponding firmware matches, it is confirmed that the corresponding firmware is deployed successfully.

[0035] In some embodiments, the flash memory firmware deployment method further includes:

[0036] If it is determined that there is no match, it is prompted that the corresponding firmware storage location is wrong or the error correction code rate configuration of the storage page storing the corresponding firmware data is wrong.

[0037] In a second aspect, an embodiment of the present application provides a flash memory firmware deployment system, which runs on a host computer, and the flash memory firmware deployment system includes:

[0038] A partitioning module is used to classify all firmwares into levels in the first deployment phase, and to partition the storage space in the flash memory used to run the firmware, so as to obtain a plurality of subspaces having the same number as the firmwares, wherein each subspace is used to specify the running of firmwares of different levels;

[0039] The firmware processing module is used to compile each firmware to obtain respective initial compiled files, add the level information of the corresponding firmware to the initial compiled file of the corresponding firmware, and then package the information of all firmware to obtain a firmware compiled package file;

[0040] a firmware saving module, used for transferring the firmware compilation package file to the flash memory in the second deployment stage, and executing a firmware saving strategy according to the level information extracted from the firmware compilation package file;

[0041] The firmware detection module is used to detect whether the level information of the corresponding firmware matches the saved subspace, and confirm that the corresponding firmware is deployed successfully if they match.

[0042] In a third aspect, an embodiment of the present application provides a flash memory device, wherein the flash memory device includes at least one firmware, wherein the at least one firmware is deployed using the flash memory device firmware deployment method.

[0043] In some embodiments, the flash memory is any one of a solid state drive, an embedded memory, and a universal flash memory.

[0044] The embodiments of the present application have the following beneficial effects:

[0045] The flash memory firmware deployment method of the present application is to classify all firmwares in the first deployment stage, and to divide the storage space in the flash memory used to run the firmware into intervals, wherein each subspace is used to specify the running of firmware of different levels; then, add the firmware level information to the initial compilation file of the corresponding firmware and package the firmware to obtain the firmware compilation package file; then, in the second deployment stage, burn the firmware compilation package file into the flash memory, and execute the firmware preservation strategy according to the extracted firmware level information; finally, detect whether the firmware is deployed successfully. This method can maximize the reliability of the flash memory, reduce the probability of product failure due to firmware loss, and reduce the performance impact caused by firmware read retry. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0047] Figure 1 A first flow chart of the flash memory firmware deployment method according to an embodiment of the present application is shown;

[0048] Figure 2 An application example of the flash memory firmware deployment method according to an embodiment of the present application is shown;

[0049] Figure 3 A second flow chart of the flash memory firmware deployment method according to an embodiment of the present application is shown;

[0050] Figure 4 A third flow chart of the flash memory firmware deployment method according to an embodiment of the present application is shown;

[0051] Figure 5 A schematic diagram of the structure of a flash memory firmware deployment system according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0052] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments.

[0053] The components of the embodiments of the present application generally described and shown in the drawings herein may be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0054] Hereinafter, the terms "including", "having" and their cognates that can be used in various embodiments of the present application are intended only to indicate specific features, numbers, steps, operations, elements, components or a combination of the foregoing items, and should not be understood as first excluding the existence of one or more other features, numbers, steps, operations, elements, components or a combination of the foregoing items or increasing the possibility of one or more features, numbers, steps, operations, elements, components or a combination of the foregoing items. In addition, the terms "first", "second", "third" and the like are only used to distinguish descriptions and cannot be understood as indicating or implying relative importance.

[0055] Unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meanings as those generally understood by those skilled in the art to which the various embodiments of the present application belong. The terms (such as those defined in generally used dictionaries) will be interpreted as having the same meanings as the contextual meanings in the relevant technical field and will not be interpreted as having idealized meanings or overly formal meanings unless clearly defined in the various embodiments of the present application.

[0056] In conjunction with the accompanying drawings, some embodiments of the present application are described in detail below. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0057] It can be understood that the importance of firmware with different functions is often different; moreover, the reliability of each storage page in the same flash memory block may also be different. The existing "equal treatment" preservation scheme for firmware will affect the reliability of the entire memory. In this regard, the present application proposes a flash memory firmware deployment method, which mainly considers distinguishing the importance of firmware and the reliability of different storage pages, and applies a preservation strategy that matches the reliability requirements of firmware of different importance, for example, setting different error correction code rates and different backup quantities, etc., so as to maximize the reliability of the memory product, reduce the probability of memory product failure due to firmware loss, and reduce the performance impact caused by firmware read retry, etc.

[0058] The flash memory firmware deployment method of the present application is described below in conjunction with some specific embodiments. It should be noted that the firmware deployment method of the present application is mainly aimed at flash memory-based memory products, for example, may include but not include solid-state drives (SSDs), embedded memory chips, such as eMMC memory chips, UFS (universal flash storage) memory chips, etc., which are not limited here.

[0059] Figure 1 A flow chart of the flash memory firmware deployment method of the embodiment of the present application is shown. Exemplarily, the flash memory firmware deployment method includes two stages, which are respectively recorded as the first deployment stage and the second deployment stage. Each stage performs different operations to jointly complete the deployment of the firmware. Among them, the first deployment stage mainly includes the firmware level division and the firmware compilation and packaging, and the second deployment stage mainly includes the firmware burning and firmware preservation detection. Figure 1 As shown, the steps of the two deployment stages are described in detail below.

[0060] S110, in the first deployment stage, all firmware are divided into levels, and the storage space in the flash memory used to run the firmware is divided into intervals to obtain a plurality of subspaces with the same number of firmware, wherein each subspace is designated to run firmware of a different level.

[0061] Exemplarily, for all firmware that needs to be saved in the flash memory, all firmware can be divided into different levels of firmware according to the importance of the firmware. For example, the higher the importance, the higher the level of the firmware; the lower the importance, the lower the level of the firmware. Figure 2 As shown, taking three firmware A, B and C as an example, if the importance of firmware A, B and C is decreasing in sequence, the levels of the divided firmware A, B and C are recorded as L0 and L1, respectively. A 、L1 B 、L2 C , among which, sorted by level, there are L0A >L1 B >L2 C .

[0062] Correspondingly, in the first deployment phase, the storage space (such as RAM space) in the flash memory used to run the firmware will also be divided into intervals, specifically into multiple subspaces equal to the number of firmware, where one subspace is used to run one firmware.

[0063] Considering that different storage subspaces may have different reliability or storage capacity, this application will also use a special description file to specify the level of firmware running in each of the above-divided subspaces. For example, for the first subspace, it can be specified as a firmware for running level L0, such as the above-mentioned firmware A; for the second subspace, it can be specified as a firmware for running level L1, such as the above-mentioned firmware B, etc.

[0064] The description file used above is also called a firmware level description file. It can be understood that the firmware level description file includes the correspondence between each subspace and the running firmware level. In actual application, developers can specify the firmware level running in different storage subspaces by modifying the firmware level description file.

[0065] S120, compile each firmware to obtain respective initial compiled files, add the level information of the corresponding firmware to the initial compiled file of the corresponding firmware, and then package the information of all firmware to obtain a firmware compiled package file.

[0066] Exemplarily, when compiling the firmware, a corresponding BIN (binary) file, i.e., the initial compiled file mentioned above, is generated for each firmware. In one embodiment, the file name of the initial compiled file of each firmware includes a start address field of a designated subspace for running the corresponding firmware, and a space length field, etc.

[0067] Taking the above three firmware A, B and C as examples, by compiling the firmware, a BIN file of each firmware is generated. In one implementation, Figure 2 As shown, their BIN file names can be described as: FW_x1_y1.bin, FW_x2_y2.bin and FW_x3_y3.bin, where x1, x2 and x3 respectively represent the starting addresses of the storage subspaces RAM0, RAM1 and RAM2 used to run the corresponding firmware; y1, y2 and y3 respectively represent the lengths of the storage subspaces RAM0, RAM1 and RAM2 used to run the corresponding firmware.

[0068] It can be understood that the above starting address and length can be used to determine the storage subspace where the BIN file of the corresponding firmware is stored. It is worth noting that the file name format shown above is only an example and is not the only limitation. In actual application, developers can make adaptive adjustments based on the description of the file name according to needs, such as adding a firmware serial number.

[0069] Then, we enter the firmware packaging process. Specifically, the entire packaging process can be divided into two parts. The first part is Figure 2 The packaging 0 stage in the process mainly adds the level information of the corresponding firmware to the initial compiled file of the corresponding firmware. Specifically, according to the level information of each firmware recorded in the above firmware level description file, a description field of the level information of the corresponding firmware is added to the file name of the initial compiled file of each firmware. For the convenience of the following description, the compiled file obtained after adding the level information operation is referred to as an updated compiled file.

[0070] Taking the above BIN file name as an example, the level field of the current firmware can be added before the start address field of the storage subspace or after the space length field of the storage subspace. For example, FW_x1_y1_L0.BIN means that the level of the firmware corresponding to the BIN is L0. Of course, the level field can also be added in other positions, which is not limited here.

[0071] The second part, namely Figure 2 The packaging 1 stage in the process mainly packages the information of each firmware to obtain the corresponding firmware compilation package file, that is, packages all the information related to the firmware into a firmware compilation package file (recorded as FW BIN package file).

[0072] Exemplarily, the packaged firmware compilation package file mainly includes two parts, namely, the header and the set of all update compilation files packaged in (i.e., the set of BIN files), wherein the Header file is used to describe the overall information of the firmware compilation package file and the description information of each update compilation file; and each BIN file in the firmware compilation package file corresponds to a sub-header that describes its information.

[0073] In one embodiment, the format of the header describing the overall information includes the following information and the byte size occupied by each information, for example, it may specifically include: 1) special mark, 4B; 2) version information, 8B; 3) package file size, 4B, where 1KB is aligned; 4) generation date, 8B; 5) check sum, 4B, i.e., CRC check sum of the entire package file, used to verify the integrity of the firmware compilation package file. 6) reserved field, 4B.

[0074] In one embodiment, each BIN file corresponds to a subheader describing its information, including the following information and the byte size occupied by each information, for example, it may specifically include: 1) BIN index, 4B, used to record the BIN number of the corresponding BIN file in the firmware compilation package file; 2) Execute ram addr, 4B, used to record the starting address of the running subspace of the corresponding BIN file; 3) Lenth, 4B, used to record the length of the corresponding BIN file; 4) Level, 4B, used to record the level of the corresponding BIN file, such as L0, L1 and L2 mentioned above; 5) BIN Type, 2B, whether the corresponding BIN file is an executable BIN file or a configuration BIN file; 6) Load Type, 2B, used to record the load type of the corresponding BIN file, for example, 0 indicates that it needs to be written to the flash memory; 1 indicates that it does not need to be written to the flash memory, but is directly placed in a specific storage space (such as RAM); 7) Check sum, 4B, used to record the CRC check sum of the corresponding BIN file, so as to verify the integrity of the corresponding BIN file; 8) Reserved, 8B, that is, a reserved field.

[0075] It can be understood that by scanning the above header or sub-header, the information of the current BIN file can be obtained. Of course, it should be understood that the description format of the above header and sub-header is a feasible way, and the information contained in each can also be adjusted according to actual needs, which is not the only limitation here.

[0076] Therefore, after the firmware compilation package file is generated, the second deployment phase begins.

[0077] S130, in the second deployment stage, the firmware compilation package file is transferred to the flash memory, and the firmware preservation strategy is executed according to the level information extracted from the firmware compilation package file.

[0078] Exemplarily, the entire firmware compilation package file can be transferred to the flash memory through the card activation tool and saved in a pre-specified storage subspace, such as memory RAM.

[0079] In one embodiment, Figure 3 As shown, step S130 includes the following sub-steps:

[0080] S131, after receiving the firmware compilation package file, the flash memory extracts the level information of the corresponding firmware from the header.

[0081] For example, the level information of each firmware can be extracted from the above-mentioned Header file. Specifically, the level description field can be extracted from the file name of the update compilation file to obtain information such as the level of the current firmware, the starting address of the stored subspace, and the space length.

[0082] S132, determining the error correction code rate of the storage unit used to store the corresponding firmware according to the level information of the corresponding firmware and in combination with the flash memory reliability description file, and then storing the corresponding firmware.

[0083] Among them, the above-mentioned flash memory reliability description file can be generated after various product function tests are performed on the memory product. In the present application, the flash memory reliability description file at least includes the target storage block (Block) for storing the firmware, and the reliability information of each storage page (Page) inside different types of blocks. For example, the reliability information of each storage page can refer to the error correction code rate required under specific reliability requirements. Furthermore, it can also include the number of storage pages in the file target storage block, etc., which is not limited here.

[0084] Exemplarily, when determining the error correction code rate of a storage unit used to store corresponding firmware, based on the level information of the corresponding firmware and combined with the reliability information of the storage pages recorded in the flash memory reliability description file, the error correction code rate of the storage pages corresponding to the firmware data with different reliability requirements is determined in accordance with the principle that the higher the firmware level, the lower the error correction code rate.

[0085] It can be understood that for each storage page used to store firmware data, when it meets the reliability requirements of the corresponding firmware data, a corresponding error correction code rate is configured. Specifically, the higher the importance of the firmware data, the lower the error correction code rate is used, and the lower the importance of the firmware data, the higher the error correction code rate is used. Among them, compared with a large error correction code rate, a small error correction code rate has a higher error correction capability, in other words, it can tolerate a higher number of bit (bit) flips.

[0086] Further optionally, if Figure 3 As shown, the flash memory firmware deployment method also includes:

[0087] S133, determining whether to back up the corresponding firmware according to the level information of the corresponding firmware, and determining the number of backups according to the remaining number of storage pages according to the principle that the higher the firmware level, the more backups there are, and then backing up the firmware.

[0088] For example, if the storage block (i.e., Block) storing the firmware has extra space, then for the firmware of high importance, several more copies can be backed up in the storage block, wherein the specific number of backups can be set according to actual needs and is not limited here. It can be understood that by backing up the firmware, it is possible to avoid loading the fixed data backed up in other Pages for use when an abnormality occurs in a certain Page.

[0089] In addition, if the flash memory does not support the configuration of the error correction code rate function, as an optional solution, after extracting the level information of the corresponding firmware, the method also includes:

[0090] S134, according to the level information of the current firmware and in combination with the flash memory reliability description file, the firmware with a higher level is stored in the flash memory storage page with higher reliability, and the firmware with a lower level is stored in the flash memory storage page with lower reliability.

[0091] For flash memory that cannot support error correction code rate configuration, the reliability information of each storage page recorded in the flash memory reliability description file can be combined for storage, where high-importance firmware data is stored on the strong page, while low-importance firmware data is stored on the weak page. This can also minimize the loss of important firmware, thereby improving the reliability of the memory.

[0092] Further, after step S130, the flash memory firmware deployment method further includes:

[0093] After saving all the firmware BIN files, a firmware save map is generated, such as FWBIN Map. Then, the FWBIN Map file is written into the NAND flash memory. Furthermore, all data written into the NAND flash memory will carry special tag information, which is usually written into the spare data of the Page.

[0094] The firmware save map records the error correction code rate configuration information of each flash memory storage page that has saved the corresponding firmware data, or the error correction code rate configuration information and firmware backup information. In one embodiment, the relevant information of each BIN saved in the NAND Flash recorded by the FWBIN Map and the byte size occupied by the information may specifically include: 1) BIN index of the BIN file, which occupies 2B, by directly using the BIN index field value in the Header file in the firmware compilation package file; 2) the running address of the BIN, which occupies 4B, by directly using the value of Execute ram addr (address of the running subspace) in the Header file in the firmware compilation package file; 3) the length of the BIN, which 4B, by directly using the value of Lenth (length of the subspace) in the Header file in the firmware compilation package file; 4) the error correction code rate of the BIN, which 1B; 5) the number of backups of the BIN, which 1B; 6) the starting Page address of the BIN, which 2B; 7) Page count (storage page count), which 1B, i.e., how many Pages are needed to save the BIN; and 8) Reserved, which 8B, i.e., reserved fields, etc.

[0095] It can be understood that the information listed above is only an example. In actual application, the information content and occupied bytes can be adaptively adjusted according to actual needs, and no sole limitation is made here.

[0096] Therefore, when the flash memory starts, the flash memory controller will search and scan the FWBINMap file based on the special tag information, and then calculate where the BIN reads data from the NAND based on the information recorded in the FWBIN Map file, such as the starting Page address, Page count, number of backups, length, etc., and then put the read data into the RAM address recorded in the Map file.

[0097] S140, detecting whether the level information of the corresponding firmware matches the saved subspace, and confirming that the firmware is deployed successfully if they match.

[0098] Exemplarily, after each firmware is saved according to the saving strategy, an aging test can be performed on the flash memory to detect whether the saving or setting of these firmware is reasonable. Figure 4 As shown in FIG. 1 , the process of performing an aging test on a flash memory includes:

[0099] S141, periodically read corresponding firmware data.

[0100] S142, monitoring the bit flip rate or the number of error bits of the corresponding firmware data.

[0101] It can be understood that the monitored parameter may be the bit flip rate, the number of error bits, or other parameters, as long as they are directly or indirectly related to reliability, and are not specifically limited here.

[0102] S143, determining whether the bit flip rate or the number of error bits matches the level of the corresponding firmware.

[0103] For example, taking the number of error bits as an example, by determining whether the monitored number of error bits exceeds the number of error bits set under the corresponding error correction code rate, if not, it is determined to be a match, and if it is, it is determined to be a mismatch. Further, if it is determined to be a match, step S144 is executed, otherwise step S145 is executed.

[0104] S144, when a match is determined, confirm that the corresponding firmware is deployed successfully.

[0105] S145, when it is determined that there is no match, it is prompted that the firmware storage location is wrong or the error correction code rate configuration of the storage page storing the corresponding firmware data is wrong.

[0106] It is understood that the error content and form when there is a mismatch are not limited here. Further optionally, when an error is prompted, it can be further redeployed according to the specific error type. For example, if the error correction code rate is configured incorrectly, the memory can be used to re-open the card to set the correct error correction code rate. It is understood that this detection operation can intercept the incorrectly configured flash memory in advance during the aging test stage.

[0107] The flash memory storage firmware deployment method proposed in the present application distinguishes the importance of each firmware, and then divides these firmware into firmware of different levels. At the same time, by performing reliability testing and description on each storage page, each firmware can be stored in a storage subspace that matches its reliability requirements as much as possible. In particular, for firmware data with higher importance, it can be stored in a storage page with high reliability. This can minimize the probability of product failure due to firmware loss or the performance impact caused by firmware read retry, thereby maximizing the reliability of the flash memory. At the same time, since these firmware are pre-classified and then compiled and packaged into firmware compilation package files, when it is necessary to replace flash memory storage with different reliability, there is no need to recompile these firmware, which is flexible, efficient, and highly maintainable.

[0108] Figure 5 A schematic diagram of the structure of the flash memory firmware deployment system of the embodiment of the present application is shown. Exemplarily, the system mainly runs in the host computer, which specifically includes:

[0109] The partitioning module 110 is used to classify all firmwares in the first deployment stage, and to partition the storage space in the flash memory used to run the firmware, so as to obtain a plurality of subspaces having the same number as the firmwares, wherein each subspace is used to specify the running of firmwares of different levels;

[0110] The firmware processing module 120 is used to generate a firmware level description file based on the level of each firmware and the configured subspace; and according to the firmware level description file, add the level information to the initial compilation file of the corresponding firmware, and then respectively package the information of each firmware to obtain the corresponding firmware compilation package file;

[0111] The firmware saving module 130 is used to burn the firmware compilation package file into the flash memory in the second deployment stage, and execute the firmware saving strategy according to the level information extracted from the firmware compilation package file;

[0112] The firmware detection module 140 is used to detect whether the level of the corresponding firmware matches the saved subspace, and confirm that the corresponding firmware is deployed successfully if they match.

[0113] It can be understood that the device of this embodiment corresponds to the flash memory firmware deployment method of the above embodiment, and the options in the above embodiment are also applicable to this embodiment, so they will not be described repeatedly here.

[0114] The present application also provides a computer terminal, such as a host computer, etc., which exemplarily includes a processor and a memory, wherein the memory stores a computer program, and the processor runs the computer program to enable the computer terminal to execute the functions of each module in the above-mentioned flash memory firmware deployment method or the above-mentioned flash memory firmware deployment system.

[0115] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including a central processing unit (CPU), a graphics processing unit (GPU) and a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. At least one of the general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc., which can implement or execute the disclosed methods, steps and logic block diagrams in the embodiments of the present application.

[0116] The memory may be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. The memory is used to store a computer program, and the processor may execute the computer program accordingly after receiving an execution instruction.

[0117] The present application also provides a readable storage medium for storing the computer program used in the above-mentioned computer terminal.

[0118] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and structure diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in an alternative implementation, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the structure diagram and / or the flow diagram, and the combination of boxes in the structure diagram and / or the flow diagram, can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0119] In addition, the functional modules or units in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0120] If the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art, and the computer software product is stored in a storage medium, including several instructions for a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk.

[0121] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A flash memory firmware deployment method, characterized in that: include: In the first deployment phase, all firmwares are divided into levels, and the storage space in the flash memory used to run the firmware is divided into intervals to obtain a plurality of subspaces having the same number as the firmwares, wherein each subspace is designated to run firmwares of different levels; Compile each firmware to obtain its own initial compiled file, add the level information of the corresponding firmware to the initial compiled file of the corresponding firmware, and then package all the firmware information to obtain a firmware compiled package file; In a second deployment phase, the firmware compilation package file is transferred to the flash memory, and a firmware preservation strategy is executed according to the level information extracted from the firmware compilation package file; It is detected whether the level information of the corresponding firmware matches the saved subspace, and when they match, it is confirmed that the corresponding firmware is deployed successfully.

2. The flash memory firmware deployment method according to claim 1, characterized in that: The step of dividing all firmware into different levels and dividing the storage space used to run the firmware into different intervals to obtain multiple subspaces with the same number of firmware includes: All firmware are divided into different levels according to the importance of the firmware; the higher the importance, the higher the level; The storage space used to run the firmware is divided into a plurality of subspaces equal to the number of the firmware, and the level of the firmware run by each subspace is specified.

3. The flash memory firmware deployment method according to claim 1, characterized in that: After the interval division, the method further includes: Generate a firmware level description file based on the correspondence between the subspaces in each segment and the running firmware level; The adding the level information of the corresponding firmware to the initial compiled file of the corresponding firmware includes: According to the level information of all firmwares recorded in the firmware level description file, a description field of the level information of the corresponding firmware is added to the file name of the initial compiled file of the corresponding firmware.

4. The flash memory firmware deployment method according to claim 3, characterized in that: The file name of the initial compiled file of the firmware includes a start address field of a designated subspace for running the firmware, and a space length field; The description field for adding the level information of the corresponding firmware includes: A level field of the corresponding firmware is added before the start address field or after the space length field.

5. The flash memory firmware deployment method according to claim 1, characterized in that: The firmware compiled package file includes a header file for describing the overall information of the firmware compiled package file and an update compiled file of each firmware obtained by adding level information.

6. The flash memory firmware deployment method according to claim 5, characterized in that: The executing the firmware preservation strategy according to the level information extracted from the firmware compilation package file includes: After receiving the firmware compilation package file, the flash memory extracts the level information of the corresponding firmware from the header file; According to the level information of the corresponding firmware and in combination with the flash memory reliability description file, the error correction code rate of the storage unit used to store the corresponding firmware is determined, and then the corresponding firmware is stored.

7. The flash memory firmware deployment method according to claim 6, characterized in that: The flash memory reliability description file includes the error correction code rate required for each storage page in the target storage block for storing the firmware under a specific reliability requirement; The determining of the error correction code rate of the storage unit for storing the corresponding firmware includes: According to the principle that the higher the firmware level, the lower the error correction rate, the error correction rate of the storage page corresponding to the firmware data with different reliability requirements is determined.

8. The flash memory firmware deployment method according to claim 7, characterized in that: The flash memory reliability description file also includes the number of storage pages in the target storage block. If the number of storage pages in the target storage block remains after the firmware is saved, the method further includes: According to the level information of the current firmware, determine whether to back up the current firmware, and according to the principle that the higher the firmware level, the more backups there are, determine the number of backups according to the remaining number of the storage pages, and then perform firmware backup.

9. The flash memory firmware deployment method according to claim 6, characterized in that: When the flash memory does not support a function of configuring an error correction code rate, the method further includes: According to the level information of the current firmware and in combination with the flash memory reliability description file, the firmware with a higher level is stored in a flash memory storage page with a higher reliability, and the firmware with a lower level is stored in a flash memory storage page with a lower reliability.

10. The flash memory firmware deployment method according to any one of claims 6 to 9, characterized in that: The method further comprises: After all the firmware are saved, a firmware save map is generated; wherein the firmware save map includes error correction code rate configuration information of each flash memory storage page that has saved the corresponding firmware data, or error correction code rate configuration information and firmware backup information.

11. The flash memory firmware deployment method according to claim 1, characterized in that: The detecting whether the level of the corresponding firmware matches the saved subspace, and confirming that the corresponding firmware is deployed successfully when they match, includes: Performing an aging test on the flash memory, during which the corresponding firmware data is periodically read and a bit flip rate or a number of error bits of the corresponding firmware data is monitored; It is determined whether the bit flip rate or the number of error bits matches the level of the corresponding firmware, and when it is determined that the corresponding firmware matches, it is confirmed that the deployment of the corresponding firmware is successful.

12. The flash memory firmware deployment method according to claim 11, characterized in that: Also includes: If it is determined that there is no match, it is prompted that the corresponding firmware storage location is wrong or the error correction code rate configuration of the storage page storing the corresponding firmware data is wrong.

13. A flash memory firmware deployment system, characterized in that: Running on a host computer, the flash memory firmware deployment system includes: A partitioning module is used to classify all firmwares into levels in the first deployment phase, and to partition the storage space in the flash memory used to run the firmware, so as to obtain a plurality of subspaces having the same number as the firmwares, wherein each subspace is used to specify the running of firmwares of different levels; The firmware processing module is used to compile each firmware to obtain respective initial compiled files, add the level information of the corresponding firmware to the initial compiled file of the corresponding firmware, and then package the information of all firmware to obtain a firmware compiled package file; a firmware saving module, used for transferring the firmware compilation package file to the flash memory in the second deployment stage, and executing a firmware saving strategy according to the level information extracted from the firmware compilation package file; The firmware detection module is used to detect whether the level information of the corresponding firmware matches the saved subspace, and confirm that the corresponding firmware is deployed successfully if they match.

14. A flash memory, characterized in that: The flash memory includes at least one firmware, wherein the at least one firmware is deployed using the flash memory firmware deployment method according to any one of claims 1 to 12.

15. The flash memory according to claim 14, characterized in that: The flash memory is a solid state drive or an embedded memory; wherein the embedded memory is an eMMC memory chip or a UFS memory chip.

Images