Flash memory firmware deployment method, system and flash memory

Abstract

The present application relates to the field of flash memory technology and discloses a flash memory firmware deployment method, system, and flash memory. The method comprises: in a first deployment phase, all firmware is classified into levels, and the storage space in the flash memory used to run the firmware is divided into sections, wherein each subspace is used to specify the running of firmware of a different level; then, the firmware level information is added to the initial compiled file of the corresponding firmware and the firmware is packaged to obtain a firmware compiled package file; in a second deployment phase, the firmware compiled package file is burned into the flash memory and the firmware preservation policy is executed according to the extracted firmware level information; finally, whether the firmware is successfully deployed is detected. 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.

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] Flash memory-based storage products, such as EMMC (Embedded MultiMedia Card), UFS (Universal Flash Storage) embedded storage chips, and SSDs (Solid State Disks), mostly store firmware on the SLC blocks (single-level storage blocks) of NAND Flash. During startup, the flash memory controller loads the firmware from NAND Flash into the memory, completing the memory function. Typically, NAND Flash may experience bit flips for various reasons, resulting in firmware loss or the need for a retry to read the firmware. If the firmware is lost, the memory directly loses its basic functionality. If the number of error bits in the firmware data is high, a read retry will be triggered, increasing the firmware read time, thereby affecting the memory performance, such as increased startup time and reduced IO performance.

[0003] From the perspective of firmware functionality, different firmware functions have different levels of importance. For example, firmware that performs basic IO functions is more important than firmware responsible for log management. Losing the firmware responsible for log management will not cause the storage to lose basic IO functions, but if the firmware that performs basic IO functions is lost, the storage will not work properly. However, existing firmware storage solutions do not take into account the differences in firmware importance and instead treat all firmware equally together. If important firmware is stored in storage space with poor reliability, this approach will increase the probability of firmware loss, which in turn affects 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, embodiments of the present application provide 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 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 equal in number to the number of firmware, wherein each subspace is designated to run firmware of a different level;

[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 compiled package file is transferred to the flash memory, and a firmware preservation strategy is executed according to the level information extracted from the firmware compiled package file;

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

[0010] In some embodiments, 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 equal in number to the 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 for running firmware is divided into a plurality of subspaces equal to the number of firmware, and the level of the firmware running in each subspace is specified.

[0013] In some embodiments, after dividing the intervals, 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 starting 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 corresponding to the 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 updated compiled files of various firmware files obtained by adding level information.

[0021] In some embodiments, executing the firmware preservation policy 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 combined 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 code rate, the error correction code 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 further 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 storage pages, and then perform firmware backup.

[0028] In some embodiments, when the flash memory does not support a configuration 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, firmware with a higher level is stored in a flash memory storage page with higher reliability, and firmware with a lower level is stored in a flash memory storage page with 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 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 if they match, includes:

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

[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 is matched, it is confirmed that the deployment of the corresponding firmware is successful.

[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, configured to, in a first deployment phase, classify all firmware into levels and to partition the storage space in the flash memory used to run the firmware into intervals, so as to obtain a plurality of subspaces having the same number of firmware, wherein each subspace is used to specify the running of firmware of a different level;

[0039] A firmware processing module is used to 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;

[0040] a firmware saving module, configured to, in a second deployment phase, transfer the firmware compiled package file to the flash memory and execute a firmware saving strategy according to the level information extracted from the firmware compiled 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, wherein the flash memory includes at least one firmware, wherein the at least one firmware is deployed using the flash memory 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 involves, in the first deployment phase, classifying all firmware into different levels and dividing the storage space in the flash memory used to run the firmware into different sections, where each section of the subspace is used to specify the running of firmware of a different level. The method then adds the firmware level information to the initial compiled file of the corresponding firmware and packages the firmware to obtain a firmware compiled package file. Furthermore, in the second deployment phase, the firmware compiled package file is burned into the flash memory and the firmware preservation policy is executed according to the extracted firmware level information. Finally, the method detects whether the firmware has been successfully deployed. 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 retries. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. 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 relevant drawings can be obtained based on these drawings without 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 structural diagram 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 the embodiments.

[0053] The components of the embodiments of the present application generally described and illustrated in the drawings herein may be arranged and designed in a variety of different 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 claimed application, but rather merely represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

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

[0055] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly 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 meaning as in the context of the relevant technical field and will not be interpreted as having an idealized meaning or an overly formal meaning unless clearly defined in the various embodiments of the present application.

[0056] The following describes some embodiments of the present application in detail with reference to the accompanying drawings. In the absence of conflict, the following embodiments and features in the embodiments may 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" storage solution 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. By applying a storage strategy that matches the reliability requirements of firmware of different importance, for example, setting different error correction code rates and different backup quantities, etc., the reliability of the memory product is maximized, the probability of memory product failure due to firmware loss is reduced, and the performance impact caused by firmware read retry is reduced.

[0058] The flash memory firmware deployment method of the present application is described below with reference to 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, which may include but not include solid-state drives (SSDs), embedded memory chips such as eMMC memory chips, UFS (Universal Flash Storage) memory chips, etc., and are not limited here.

[0059] Figure 1 A flow chart of the flash memory firmware deployment method of an embodiment of the present application is shown. Exemplarily, the flash memory firmware deployment method includes two stages, 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 firmware level division and firmware compilation and packaging, and the second deployment stage mainly includes firmware burning and firmware preservation detection. Figure 1 As shown, the following describes the steps of the two deployment phases.

[0060] S110, in the first deployment phase, 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 multiple subspaces with the same number of firmware, wherein each subspace is designated to run firmware of a different level.

[0061] For example, 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 firmwares 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 firmwares, 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 dedicated description file to specify the level of firmware running in each of the above-divided subspaces. For example, the first subspace can be specified to run firmware at level L0, such as the firmware A mentioned above; the second subspace can be specified to run firmware at level L1, such as the firmware B mentioned above, and so on.

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

[0065] S120 , 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.

[0066] Exemplarily, when compiling firmware, a corresponding BIN file, i.e., the aforementioned initial compilation file, is generated for each firmware. In one embodiment, the file name of each firmware initial compilation file includes a starting address field for a designated subspace used to run the corresponding firmware, a space length field, and the like.

[0067] Taking the above three firmwares A, B and C as an example, by compiling the firmware, a BIN file of each firmware is generated. In one embodiment, 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 corresponding firmware BIN file is stored. It is worth noting that the file name format shown above is only an example and is not intended to be the only limitation. In actual use, developers can make adaptive adjustments based on the description of the file name according to their needs, such as adding a firmware serial number.

[0069] Then, enter the firmware packaging process. Specifically, the entire packaging process can be divided into two parts. The first part is Figure 2 During the packaging phase 0, the firmware level information is added to the initial compiled file. Specifically, based on the firmware level information recorded in the firmware level description file, a description field containing the firmware level information is added to the file name of each initial compiled file. For ease of description, the compiled file resulting from this addition of level information is referred to as an updated compiled file.

[0070] Taking the BIN file name above as an example, the current firmware level field 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 indicates that the firmware level corresponding to this BIN is L0. Of course, the level field can also be added in other locations, and this is not limited here.

[0071] The second part, namely Figure 2 The packaging stage 1 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). 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 of each information. For example, it may include: 1) Special Flags (4 bytes); 2) Version Information (8 bytes); 3) Package File Size (4 bytes, with 1KB alignment); 4) Creation Date (8 bytes); 5) Check Sum (4 bytes), i.e., the CRC check sum of the entire package file, used to verify the integrity of the firmware compilation package file; and 6) Reserved Field (4 bytes).

[0074] In one embodiment, each BIN file has a corresponding subheader that describes its information, including the following information and the byte size occupied by each information, for example, it may specifically include: 1) BIN index (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, used to record 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 is 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 only one feasible way, and the information contained in each can also be adjusted according to actual needs, and this is not the only limitation.

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

[0077] S130 , in the second deployment phase, 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-designated 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 for storing 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] 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) used to store the firmware, and the reliability information of each storage page (Page) within 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 page recorded in the flash memory reliability description file, the error correction code rate of the storage page corresponding to the firmware data with different reliability requirements is determined according to 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, a corresponding error correction rate is configured if it meets the reliability requirements of the corresponding firmware data. Specifically, the more important the firmware data is, the lower the error correction rate is used, and the less important the firmware data is, the higher the error correction rate is used. A lower error correction rate has a higher error correction capability than a higher error correction rate; in other words, it can tolerate a higher number of bit flips.

[0086] Further optionally, as 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 based on 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 firmware has extra space, multiple copies of the important firmware can be backed up in the same storage block. The specific number of copies can be set based on actual needs and is not limited here. It can be understood that by backing up the firmware, it is possible to avoid having to load fixed data backed up in other Pages when a Page encounters an exception.

[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 corresponding firmware level information, the method further includes:

[0090] S134, according to the level information of the current firmware and in combination with the flash memory reliability description file, the higher level firmware is stored in the flash memory storage page with higher reliability, and the lower level firmware 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. High-importance firmware data is stored on strong pages, while less important firmware data is stored on weak pages. This can also minimize the loss of important firmware, thereby improving memory reliability.

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

[0093] After saving all the firmware's BIN files, a firmware save map, such as the FWBIN Map, is generated. This FWBIN Map file is then written to the NAND flash memory. Furthermore, all data written to the NAND flash memory carries special tag information, typically written to the spare data section of the page.

[0094] The firmware save map records error correction code rate configuration information of each flash memory storage page that has saved corresponding firmware data, or error correction code rate configuration information and firmware backup information. In one embodiment, the FWBIN Map records the relevant information of each BIN saved in the NAND Flash and the byte size occupied by the information, which may specifically include: 1) the 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 Execute ram addr (address of the running subspace) value in the Header file in the firmware compilation package file; 3) the length of the BIN, which 4B, by directly using the Lenth (length of the subspace) value 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 required to save the BIN; and 8) Reserved, which 8B, which is a reserved field, 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 this is not a sole limitation.

[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 FWBINMap 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] For example, 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 firmwares is reasonable. Figure 4 As shown in FIG, the process of performing an aging test on a flash memory includes:

[0099] S141, periodically reading corresponding firmware data.

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

[0101] It is understandable 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, it is determined whether the monitored number of error bits exceeds the number of error bits set at the corresponding error correction code rate. If it does not exceed, it is determined to be a match; if it exceeds, 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 content and form of the error message when a mismatch occurs are not limited here. Furthermore, when an error message is displayed, further redeployment can be performed based on the specific error type. For example, if the error correction code rate is misconfigured, the memory can be used to re-activate the card and set the correct error correction code rate. It is understood that this detection operation can intercept misconfigured flash memory in the burn-in test phase.

[0107] The flash memory firmware deployment method proposed in this application distinguishes the importance of each firmware and then divides these firmware into different levels of firmware. 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 storage pages 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 flash memory storage with different reliability needs to be replaced, 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] A partitioning module 110 is configured to, during a first deployment phase, classify all firmware into different levels and to partition the storage space in the flash memory used to run the firmware into different intervals, thereby obtaining a plurality of subspaces having the same number of firmware, wherein each subspace is used to specify the running of firmware of a different level;

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

[0111] a firmware saving module 130 configured to burn the firmware compilation package file into the flash memory in a second deployment phase and execute a firmware saving strategy according to the level information extracted from the firmware compilation package file;

[0112] The firmware detection module 140 is configured to detect whether the level of the corresponding firmware matches the stored 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 optional items in the above embodiment are also applicable to this embodiment, so they will not be described again 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), an off-the-shelf programmable gate array (FPGA) or at least one of other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc., which can implement or execute the various methods, steps and logic block diagrams disclosed 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 the several embodiments provided in this 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 architectures, functions and operations of the devices, methods and computer program products according to the 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 the code, and the module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in an alternative implementation, the functions marked in the box can also occur in an order different from that 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 flowchart, and the combination of boxes in the structure diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

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

[0120] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to execute 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 magnetic disk or an optical disk.

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

Claims

1. A flash memory firmware deployment method, characterized in that: include: In the first deployment phase, 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 equal in number to the number of firmware, wherein each subspace is designated to run firmware of a different level; 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 based on the level information extracted from the firmware compilation package file and a flash memory reliability description file; 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 specific reliability requirements; wherein the firmware preservation strategy includes: determining the error correction code rate for storage pages corresponding to firmware data with different reliability requirements based on the principle that the higher the firmware level, the lower the error correction code rate; It is detected whether the level information of the corresponding firmware matches the saved subspace, and if so, it is confirmed that the corresponding firmware is deployed successfully.

2. The flash memory firmware deployment method according to claim 1, wherein: 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 for running firmware is divided into a plurality of subspaces equal to the number of firmware, and the level of the firmware running in each subspace is specified.

3. The flash memory firmware deployment method according to claim 1, wherein: 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, wherein: 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 corresponding to the 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, wherein: The firmware compiled package file includes a header file for describing 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, wherein: The step of executing the firmware preservation strategy according to the level information extracted from the firmware compilation package file and the flash memory reliability description 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, wherein: 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 storage pages, and then perform firmware backup.

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

9. The flash memory firmware deployment method according to any one of claims 6 to 8, 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 corresponding firmware data, or error correction code rate configuration information and firmware backup information.

10. The flash memory firmware deployment method according to claim 1, wherein: The detecting whether the level of the corresponding firmware matches the saved subspace, and confirming that the corresponding firmware is successfully deployed if they match, includes: Performing an aging test on the flash memory, periodically reading corresponding firmware data during the aging test, and monitoring a bit flip rate or a number of error bits of the corresponding firmware data; 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 is matched, it is confirmed that the deployment of the corresponding firmware is successful.

11. The flash memory firmware deployment method according to claim 10, wherein: 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.

12. A flash memory firmware deployment system, characterized in that: Running on a host computer, the flash memory firmware deployment system includes: a partitioning module, configured to, in a first deployment phase, classify all firmware into levels and to partition the storage space in the flash memory used to run the firmware into intervals, so as to obtain a plurality of subspaces having the same number of firmware, wherein each subspace is used to specify the running of firmware of a different level; A firmware processing module is used to 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; a firmware preservation module, configured to, in a second deployment phase, transfer the firmware compiled package file to the flash memory and execute a firmware preservation strategy based on the level information extracted from the firmware compiled package file in combination with a flash memory reliability description file; the flash memory reliability description file including the error correction code rate required for each storage page in a target storage block for storing firmware under specific reliability requirements; wherein the firmware preservation strategy includes: determining the error correction code rate for storage pages corresponding to firmware data with different reliability requirements, based on the principle that higher firmware levels have lower error correction code rates; 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.

13. 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 11.

14. The flash memory according to claim 13, wherein: 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