A method for backing up a memory and firmware

Abstract

The present invention provides a memory and a method for backing up firmware. The memory includes: a flash memory block, which includes a system block, a firmware block, and a data block. The system block is used to store relevant information of the data block. The data block is used to store user data. The firmware block is used to store firmware and other codes; and a main controller, which is used to select at least one free block from the data blocks. Wherein, the main controller is further used to select a block from the free blocks and represent it as a backup block. The storage space in the backup block is divided into a code storage area and a user data storage area. The main controller is further used to back up the firmware and other codes in the firmware block to the code storage area of the backup block, and write user data to the user data storage areas of the other free blocks and the backup block. The memory and the method for backing up firmware provided by the present invention can make full use of the storage resources of the memory.

Description

Technical Field

[0001] The present invention relates to the field of storage, and particularly to a method for backing up a memory and firmware. Background Art

[0002] For a small-capacity memory, since the number of internal flash blocks is small, flash block resources are very precious. One more or one less flash block will have a great impact on the life or performance of the memory. The firmware needs to be stored in a flash block. In order to protect the memory, multiple backups of the firmware are required, which will further reduce the number of available flash blocks, resulting in the inability to fully utilize the storage resources of the memory. Therefore, there is room for improvement. Summary of the Invention

[0003] An object of the present invention is to provide a method for backing up a memory and firmware, which can fully utilize the storage resources of the memory.

[0004] To solve the above technical problems, the present invention is implemented by the following technical solutions:

[0005] The present invention provides a memory, including:

[0006] Flash blocks, including a system block, a firmware block, and a data block. The system block is used to store relevant information of the data block, the data block is used to store user data, and the firmware block is used to store firmware and other codes; and

[0007] A main controller, configured to select at least one free block from the data blocks;

[0008] Wherein, the main controller is further configured to select one block from the free blocks and denote it as a backup block. The storage space in the backup block is divided into a code storage area and a user data storage area;

[0009] The main controller is further configured to back up the firmware and other codes of the firmware block to the code storage area of the backup block, and write user data to the user data storage areas of the other free blocks and the backup block.

[0010] In an embodiment of the present invention, the main controller is further configured to sort the data blocks according to the access order of the data blocks after the firmware is started, and obtain at least one data block with an address space far from the firmware block from the data blocks, which is denoted as the free block.

[0011] In an embodiment of the present invention, the main controller is further configured to obtain the block that is accessed latest from the free blocks, which is denoted as the backup block.

[0012] In an embodiment of the present invention, the main controller is further configured to monitor the status of the backup block. When a risk occurs in the backup block, it is marked as a risky block, and the metadata or status table in the system block is updated to record the risk status of the block.

[0013] In an embodiment of the present invention, after a risk occurs in the backup block, when the main controller determines that there are other free blocks, it selects one block from the free blocks as the new backup block, backs up the firmware and other codes of the firmware block to the code storage area of the new backup block, and writes user data to the user data storage area of the new backup block.

[0014] In an embodiment of the present invention, after a risk occurs in the backup block, when the main controller determines that there are no other free blocks, it performs a garbage collection operation on the data block. After erasing the invalid data in a certain data block, it is represented as the new backup block, and the firmware and other codes of the firmware block are backed up to the code storage area of the new backup block, and user data is written to the user data storage area of the new backup block.

[0015] In an embodiment of the present invention, when the main controller confirms that the user data in the backup block is invalid data, it erases the backup block. After the erasure is completed, it obtains a new backup block from the free block or data block, and backs up the firmware and other codes of the firmware block to the code storage area of the new backup block;

[0016] The main controller is further configured to, when performing a write operation, preferentially write user data to the user data storage area of the new backup block.

[0017] In an embodiment of the present invention, when an exception occurs in the firmware block, the main controller starts the firmware from the backup block and determines whether there are free blocks;

[0018] When there are free blocks, it obtains one block from them, backs up the firmware and other codes in the backup block to the code storage area of the block, and when the current data block is filled with user data, preferentially writes other user data to the user data storage area of the block;

[0019] When there are no free blocks, it performs a garbage collection operation on the data block. After erasing the invalid data in a certain data block, it backs up the firmware and other codes in the backup block to the code storage area of the block.

[0020] In an embodiment of the present invention, when backing up the firmware and other codes to the code storage area, the main controller is further configured to verify the integrity of the firmware and the codes. When the firmware and the codes in the code storage area are incomplete, the firmware and the codes are rewritten into the code storage area until the firmware and the codes in the code storage area are complete.

[0021] The present invention also provides a method for backing up the firmware of a memory, including:

[0022] Dividing the flash memory blocks into a system block, a firmware block, and a data block, where the system block is used to store the relevant information of the data block, the data block is used to store user data, and the firmware block is used to store the firmware and other codes;

[0023] Selecting at least one free block from the data blocks;

[0024] Selecting one block from the free blocks and designating it as a backup block, where the storage space in the backup block is divided into a code storage area and a user data storage area;

[0025] Backing up the firmware and other codes of the firmware block to the code storage area of the backup block, and writing user data into the user data storage areas of the other free blocks and the backup block.

[0026] As described above, the present invention provides a memory and a method for backing up the firmware. For a small-capacity memory, the utilization rate of each block becomes particularly important. By mixing backup blocks and data blocks, the limited storage space can be utilized more efficiently, thereby improving the overall storage capacity. At the same time, when the requirements change, some data blocks can be dynamically converted into backup blocks, or the backup blocks can be used as backup targets when data recovery is needed. This dynamic management can improve the utilization efficiency of the overall storage.

[0027] Of course, when implementing any product of the present invention, it is not necessarily required to achieve all the above-mentioned advantages simultaneously. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for describing the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0029] Figure 1 Schematic diagram of a backup block of a memory in an embodiment of the present invention;

[0030] Figure 2The flowchart of a method for backing up the firmware of a memory in an embodiment of the present invention.

[0031] In the figure: 100, backup block; 110, code storage area; 120, user data storage area. Detailed implementation manners

[0032] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0033] In one embodiment, with the popularization of embedded systems and mobile devices, the requirements for storage technology are continuously increasing. As a non-volatile storage technology widely used in modern storage systems, NAND flash memory has been widely used in various electronic devices due to its advantages of high density and low cost. For existing small-capacity memories, the number of available flash blocks inside is small. In the case where the number of flash blocks is limited, the flash blocks need to be divided into firmware blocks (Code Block), system blocks, backup blocks 100, and data blocks.

[0034] In one embodiment, the firmware block can be used to store firmware and other codes or read-only data. The system block can be used to store mapping tables, data structures, or indexes. The backup block 100 can be used to back up the firmware and other codes stored in the firmware block. The data block can be used to store host data. The data block refers to the block that can be correctly read and processed (rom code) in the read-only memory (rom).

[0035] Furthermore, since the number of backup blocks 100 is generally multiple, and each backup block 100 only stores firmware and other codes, this will cause a certain degree of waste of storage resources, and the memory cannot make full use of its internal limited storage resources.

[0036] Please refer to Figure 1 , in one embodiment, in order to make full use of the limited storage resources inside the memory and to improve the performance and lifespan of the small-capacity memory to a certain extent, the present invention discloses a memory that can make full use of the idle storage space inside the backup block 100 to make full use of the limited number of flash blocks. Among them, the memory can include a main controller and flash blocks.

[0037] In one embodiment, the main controller may be a microcontroller unit (MCU). The main controller can be used to perform specific control tasks, such as reading data, processing instructions from the host, etc. A flash memory block is the smallest erasable unit in the memory and consists of multiple pages. A page is the smallest write unit in the memory and consists of multiple rows. A row is a part within a page, and a page may be logically divided into multiple rows.

[0038] In one embodiment, the main controller may select at least one free block from multiple data blocks. In a normal scenario, the free block can be used as a data block. Among them, the address space of the free block is set to be far from the address space of the firmware block. Subsequently, the main controller needs to select a data block from the free blocks and use it as the backup block 100.

[0039] Specifically, during the selection process, it is necessary to first sort the multiple data blocks according to the access order of the data blocks after the firmware is started. Since the specific address of each data block in the physical memory is stored in the system block, the main controller can read the start address and end address of each data block in the system block. Subsequently, the main controller can sort according to the start address of the data block in ascending order from the low address to the high address to obtain the access order of the main controller to the multiple data blocks.

[0040] Furthermore, the main controller can obtain the data block that is accessed latest from multiple data blocks, denoted as the backup block 100. By setting the address space of the backup block 100 to be far from the address space of the firmware block, it is possible to prevent interference with the backup block 100 when the firmware block has problems, achieve risk dispersion, and ensure the reliability and security of the system in different situations. Storing the backed-up firmware and other codes in the data block that is accessed last can reduce the impact range in case of a hardware failure. Even when there is a problem with the data block that is accessed first, the data block that is accessed last will not completely fail due to a single failure point.

[0041] Please refer to Figure 1 , in one embodiment, the storage space within the backup block 100 can be divided into a code storage area 110 and a user data storage area 120. Among them, the main controller can back up the firmware and other codes in the firmware block to the code storage area 110 of the backup block 100 to back up the firmware and other codes.

[0042] In one embodiment, after the main controller backs up the firmware and other codes to the backup block 100, it is also necessary to verify the integrity of the firmware and other codes written in the backup block 100. For example, the integrity of the firmware and other codes can be verified by using cyclic redundancy check (CRC). CRC check is performed by performing binary division of the firmware and other codes by a predefined polynomial, and the remaining result is the CRC check code. This check code is usually appended to the end of the data.

[0043] Specifically, during the writing process of the firmware and other codes, a specific CRC algorithm is used to process the data in the firmware and other codes (except for the last few bytes reserved for verification). This process generates a CRC check code, usually a 4-byte value, which is then appended to the end of the firmware and other codes.

[0044] Furthermore, after the main controller backs up the firmware and other codes to the backup block 100, the main controller separates the last 4 bytes (storing the CRC check code) from the firmware and other code package, and then performs the same CRC calculation on the rest of the file again. The calculated CRC value is compared with the CRC check value appended to the end of the firmware and other codes. If the two are consistent, it indicates that the firmware and other codes have not been tampered with during the writing process, and the data integrity is verified. If they are inconsistent, it indicates that the firmware and other codes may be damaged or tampered with during the writing process, and the main controller needs to rewrite the firmware and other codes until the firmware and other codes stored in the code storage area 110 of the backup block 100 are complete.

[0045] In one embodiment, when the main controller is performing a write operation, the main controller can write user data to the data block. Since the amount of data of the firmware and other codes is small, it may not be able to fill the entire backup block 100. At this time, there is still a certain amount of free storage space in the backup block 100, that is, the user data storage area 120. In order to make full use of the limited storage space, therefore, the main controller can also write user data to the user data storage area 120 in the backup block 100.

[0046] In one embodiment, during the use of the memory, since the backup block 100 also needs to perform read and write operations, the backup block 100 may also have a high number of error bits (Err Bit) or other risks, resulting in errors or failures in the backup block 100, affecting the reliability of the data and the stability of the storage. Among them, the error bit refers to the bit error found in the read and write operations of the flash memory. For example, when the read operation finds that the stored bit value is inconsistent with the expected value, it will be marked as an error bit. If the number of error bits in the flash memory is too high, it means that there are many errors in the storage cells of the flash memory, which may lead to data corruption or incorrect reading. At the same time, the number of write operations of the flash memory is limited, and frequent write operations will cause wear and aging of the flash memory cells, thus increasing the probability of the appearance of error bits. The aging phenomenon that gradually appears during the use of the flash memory will affect its reliability.

[0047] Furthermore, when risks occur in the backup block 100, the main controller needs to migrate the user data in the backup block 100 to other data blocks and discard the backup block. Specifically, the main controller can identify whether risks occur by monitoring the health status of the backup block 100. When the error rate of the backup block 100 exceeds the preset threshold or other abnormal conditions occur, the backup block 100 can be marked as a risk block. Before the main controller marks the backup block 100 as a risk block, it is necessary to try to migrate the user data stored in the backup block 100 to other data blocks.

[0048] In one embodiment, after risks occur in the backup block 100, at this time, only the firmware and other codes are stored in the firmware block. In order to improve the security of the storage, the main controller needs to determine whether there are idle blocks to obtain a new backup block.

[0049] In one embodiment, when there are multiple idle blocks, the latest accessed idle block can be obtained from the multiple idle blocks and represented as the new backup block. When there is only one idle block, it can be directly represented as the new backup block.

[0050] Furthermore, since the new backup block may store user data, at this time, the main controller can migrate the user data in the new backup block to other data blocks. Subsequently, the main controller can back up the firmware and other codes in the firmware block to the code storage area 110 of the new backup block.

[0051] In one embodiment, when there are no idle blocks, the main controller can trigger a garbage collection (GC) operation on the remaining data blocks to clear the invalid data in a certain data block and then represent it as the new backup block. Subsequently, the main controller can back up the firmware and other codes in the firmware block to the code storage area 110 of the new backup block.

[0052] In one embodiment, after the main controller backs up the firmware and other codes to the code storage area 110 of the new backup block, it is also necessary to verify the integrity of the firmware and other codes backed up in the new backup block. In this embodiment, the cyclic redundancy check (CRC) method can be used to verify the integrity of the firmware and other codes. When the main controller confirms that the firmware and other codes in the new backup block are complete, it indicates a successful write. When the main controller confirms that the firmware and other codes in the new backup block are incomplete, the firmware and other codes need to be rewritten until the firmware and other codes written into the new backup block are complete.

[0053] In one embodiment, after the main controller marks the above-mentioned backup block 100 as a risky block, it can update the metadata or status table in the system block to record the risk status of this block. In future read / write and other operations, the main controller will skip the use of the risky block.

[0054] Furthermore, since there is still a certain amount of free storage space in the new backup block, that is, the user data storage area 120. In order to make full use of the limited storage space, therefore, the main controller can also write user data into the user data storage area 120 of the new backup block.

[0055] In one embodiment, when all the user data stored in the user data storage area 120 of the backup block 100 is invalid data, at this time, the backup block 100 needs to be erased. After the erasure is completed, a new backup block can be obtained from the free blocks or data blocks according to preset conditions. Among them, the preset conditions can be expressed as when there are multiple free blocks, the latest accessed free block can be obtained from the multiple free blocks and represented as the new backup block; when there is only one free block, it can be directly represented as the new backup block; when there are no free blocks, a new backup block is obtained from the data blocks. After obtaining the new backup block, it is necessary to write the firmware and other codes into its code storage area 110, and after verifying its integrity and when the main controller executes a write operation, user data can be preferentially written into the user data storage area 120 of the new backup block.

[0056] In one embodiment, during the use of the memory, when extreme situations occur, the firmware block may also become abnormal, resulting in the inability to use the firmware block. For example, extreme high or low temperatures can affect the performance and stability of the firmware block. Another example is that the instability or voltage fluctuation of the power supply may affect the normal operation of the firmware block. For another example, in a high-load working condition (such as high-concurrency read / write operations), the firmware block may bear too much pressure, affecting its stability and reliability.

[0057] Further, when an exception occurs in the firmware block, at this time, the main controller can restart the firmware from the backup block 100 or the new backup block to restart the memory and discard the firmware block. After the main controller 100 marks the firmware block as unavailable, the metadata or status table in the system block can be updated to record the risk status of the block.

[0058] In one embodiment, after a risk occurs in the firmware block, the firmware and other codes can be loaded from the backup block or the new backup block at this time. Since only the backup block or the new backup block stores the firmware and other codes, in order to improve the security of storage, the main controller needs to check whether there is an idle block.

[0059] Further, when there are multiple idle blocks, the idle block that was last accessed can be obtained from the multiple idle blocks. When there is only one idle block, directly obtain the idle block. After obtaining the idle block, the firmware and other codes in the backup block or the new backup block can be backed up to the idle block and its integrity can be verified. At this time, the main controller may be performing a write operation. When the main controller is writing user data to other data blocks and after the data block is full, the remaining user data can be written to the above-mentioned idle block. Among them, when the above data block is not full of user data, invalid data can be written to it to force the entire storage space to be full.

[0060] Still further, when there is no idle block, a GC operation can be triggered for the remaining data blocks to clear the invalid data in a certain data block and represent it as an idle block. Subsequently, the firmware and other codes in the backup block or the new backup block can be backed up to the code storage area 110 of the idle block and its integrity can be verified. Subsequently, user data can be written to the user data storage area 120 of the idle block.

[0061] It can be seen that in the above solution, for a small-capacity memory, the utilization rate of each block becomes particularly important. By mixing backup blocks and data blocks, the limited storage space can be utilized more efficiently, thereby improving the overall storage capacity. At the same time, when the requirements change, some data blocks can be dynamically converted into backup blocks, or the backup blocks can be used as backup targets when data needs to be restored. This dynamic management can improve the utilization efficiency of the overall storage.

[0062] Please refer to Figure 2 , the present invention also provides a method for backing up the firmware of a memory. This backup method can be applied to the above-mentioned memory to back up the firmware inside the memory. The backup method may include the following steps:

[0063] Step S10: Divide the flash memory blocks into system blocks, firmware blocks, and data blocks. Among them, the relevant information of the data blocks is saved in the system blocks. The data blocks are used to store user data, and the firmware blocks are used to store firmware and other codes;

[0064] Step S20: Select at least one free block from the data blocks;

[0065] Step S30: Select one block from the free blocks and denote it as the backup block. Among them, the storage space in the backup block is divided into a code storage area and a user data storage area;

[0066] Step S40: Back up the firmware and other codes of the firmware blocks to the code storage area of the backup block, and write user data to the user data storage areas of other free blocks and the backup block.

[0067] The embodiments of the present invention disclosed above are only used to help illustrate the present invention. The embodiments do not describe all the details in detail, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and changes can be made according to the content of this specification. These embodiments are selected and specifically described in this specification to better explain the principle and practical application of the present invention, so that those skilled in the art can well understand and utilize the present invention. The present invention is only limited by the claims and their full scope and equivalents.

Claims

1. A memory, characterized in that: include: Flash memory blocks, including system blocks, firmware blocks and data blocks, wherein the system blocks are used to store relevant information of the data blocks, the data blocks are used to store user data, and the firmware blocks are used to store firmware and other codes; The data block refers to a flash memory block that can be correctly read and processed by the read-only memory; as well as A main controller, configured to select at least one free block from the data blocks; The main controller is further used to select a block from the free blocks and indicate it as a backup block, and the storage space in the backup block is divided into a code storage area and a user data storage area; The main controller is also used to back up the firmware and other codes of the firmware block to the code storage area of ​​the backup block, and write user data to the user data storage area of ​​the other free blocks and the backup block; The main controller is also used to monitor the status of the backup block, and when the backup block is at risk, mark it as a risk block, and update the metadata or status table in the system block to record the risk status of the block; After the backup block is at risk, the main controller selects a block from the free blocks when determining that there are other free blocks, represents the block as a new backup block, backs up the firmware and other codes of the firmware block to the code storage area of ​​the new backup block, and writes user data to the user data storage area of ​​the new backup block; After the backup block is at risk, the main controller determines that when there are no other free blocks, it performs garbage collection on the data block, and after erasing invalid data in a data block, it represents it as a new backup block, and backs up the firmware and other codes of the firmware block to the code storage area of ​​the new backup block, and writes user data to the user data storage area of ​​the new backup block.

2. The memory according to claim 1, characterized in that: The main controller is also used to sort the data blocks according to the access order of the data blocks after the firmware is started, and obtain at least one data block in the address space away from the firmware block from the data blocks, which is represented as the free block.

3. The memory according to claim 2, characterized in that: The main controller is further configured to obtain the block that is accessed the latest from the free blocks, which is represented as the backup block.

4. The memory according to claim 1, characterized in that: When the main controller confirms that the user data in the backup block is invalid data, the main controller erases the backup block, and after the erasing is completed, obtains a new backup block from the free block or the data block, and backs up the firmware and other codes of the firmware block to the code storage area of ​​the new backup block; The main controller is also used to preferentially write user data into the user data storage area of ​​the new backup block when executing a write operation.

5. The memory according to claim 1, characterized in that: When an abnormality occurs in the firmware block, the main controller starts the firmware from the backup block and determines whether there is the free block; When the free block exists, a block is obtained therefrom, and the firmware and other codes in the backup block are backed up to the code storage area of ​​the block, and when the current data block is filled with user data, other user data is preferentially written to the user data storage area of ​​the block; When the free block does not exist, a garbage collection operation is performed on the data block, and after invalid data in a data block is erased, the firmware and other codes in the backup block are backed up to the code storage area of ​​the block.

6. The memory according to any one of claims 1, 4 and 5, characterized in that: When backing up the firmware and other codes to the code storage area, the main controller is also used to verify the integrity of the firmware and code. When the firmware and code in the code storage area are incomplete, the firmware and code are rewritten into the code storage area until the firmware and code in the code storage area are complete.

7. A method for backing up firmware of a memory, characterized in that: include: The flash memory block is divided into a system block, a firmware block and a data block, wherein the system block is used to store relevant information of the data block, the data block is used to store user data, and the firmware block is used to store firmware and other codes; the data block refers to a flash memory block that can be correctly read and processed by a read-only memory; Selecting at least one free block from the data blocks; Selecting a block from the free blocks and indicating it as a backup block, wherein the storage space in the backup block is divided into a code storage area and a user data storage area; Backing up the firmware and other codes of the firmware block into the code storage area of ​​the backup block, and writing user data into the user data storage areas of the other free blocks and the backup block; Monitor the status of the backup block, mark it as a risk block when a risk occurs to the backup block, and update the metadata or status table in the system block to record the risk status of the block; determine whether there are other free blocks: When there are other free blocks, select a block from the free blocks to represent it as a new backup block, back up the firmware and other codes of the firmware block to the code storage area of ​​the new backup block, and write user data to the user data storage area of ​​the new backup block; When there are no other free blocks, garbage collection is performed on the data block, and after invalid data in a data block is erased, it is represented as a new backup block, and the firmware and other codes of the firmware block are backed up to the code storage area of ​​the new backup block, and user data is written to the user data storage area of ​​the new backup block.

Images