Storage and firmware backup method

Abstract

The invention provides a memory and a firmware backup method, and the memory comprises a flash memory block which comprises a system block, a firmware block and a data block, the system block is used for storing related information of the data block, the data block is used for storing user data, and the firmware block is used for storing firmware and other codes; the main controller is used for selecting at least one free block from the data blocks; wherein the main controller is further used for selecting one block from the free blocks and representing the selected block 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 further used for backing up firmware and other codes of the firmware block to a code storage area of a backup block and writing user data into user data storage areas of other free blocks and the backup block. According to the memory and the firmware backup method provided by the invention, storage resources of the memory can be fully utilized.

Description

Technical Field

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

[0002] For small-capacity memory, since the number of internal flash blocks is small, the flash block resources are very precious. One more or one less flash block will have a greater 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, the firmware needs to be backed up multiple times, which will further reduce the number of available flash blocks and make it impossible to fully utilize the storage resources of the memory. Therefore, there is room for improvement. Summary of the invention

[0003] The 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] In order to solve the above technical problems, the present invention is achieved through the following technical solutions: The present invention provides a memory, comprising: A flash memory block, including 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; and 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 into the user data storage areas of the other free blocks and the backup block.

[0005] In one embodiment of the present invention, the main controller is further 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.

[0006] In one embodiment of the present invention, 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.

[0007] In one embodiment of the present invention, the main controller is also used to monitor the status of the backup block, mark it as a risk block when the backup block is at risk, and update the metadata or status table in the system block to record the risk status of the block.

[0008] In one embodiment of the present invention, after the backup block is at risk, the main controller selects a block from the free blocks when it determines that there are other free blocks, 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.

[0009] In one embodiment of the present invention, after the backup block is at risk, the main controller performs a garbage collection operation on the data block when it determines that there are no other free blocks, and after erasing invalid data in a data block, 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.

[0010] In one embodiment of the present invention, 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 erasure 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.

[0011] In one embodiment of the present invention, when an abnormality occurs in the firmware block, the main controller starts the firmware from the backup block and determines whether the free block exists; 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.

[0012] In one embodiment of the present invention, 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.

[0013] The present invention also provides a method for backing up firmware of a memory, comprising: Divide the flash memory block 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; 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; The firmware and other codes of the firmware block are backed up in the code storage area of ​​the backup block, and user data is written into the user data storage area of ​​the other free blocks and the backup block.

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

[0015] Of course, any product implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for describing the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0017] Figure 1 A schematic diagram of a backup block of a memory in one embodiment of the present invention; Figure 2 The present invention is a flowchart of a method for backing up firmware of a memory according to an embodiment of the present invention.

[0018] In the figure: 100, backup block; 110, code storage area; 120, user data storage area. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0020] In one embodiment, with the popularity of embedded systems and mobile devices, the requirements for storage technology are constantly 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 flash memory blocks available inside is small. In the case of a limited number of flash memory blocks, the flash memory blocks need to be divided into firmware blocks (Code Block), system blocks, backup blocks 100, and data blocks.

[0021] 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 a block in a read-only memory (ROM) that can be correctly read and processed (ROM code).

[0022] Furthermore, since there are generally multiple backup blocks 100, each backup block 100 only stores firmware and other codes, which will cause a certain degree of waste of storage resources, and the memory cannot fully utilize its limited internal storage resources.

[0023] See also Figure 1 In one embodiment, in order to fully utilize the limited storage resources inside the memory and improve the performance and life of the small-capacity memory to a certain extent, the present invention discloses a memory that can fully utilize the limited number of flash memory blocks in the backup block 100. The memory may include a main controller and a flash memory block.

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

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

[0026] 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 the data blocks in order from low address to high address according to the start address of the data blocks to obtain the access order of the main controller to the multiple data blocks.

[0027] Furthermore, the main controller can obtain the latest accessed data block from multiple data blocks, which is represented as backup block 100. By setting the address space of backup block 100 to be far away from the address space of the firmware block, it is possible to prevent interference with backup block 100 when a problem occurs in the firmware block, thereby dispersing risks and ensuring the reliability and security of the system under different circumstances. Storing the backed-up firmware and other codes in the last accessed data block can reduce the scope of impact when a hardware failure occurs. Even if a problem occurs in the first accessed data block, the last accessed data block will not be completely ineffective due to a single point of failure.

[0028] See also Figure 1 In one embodiment, the storage space in the backup block 100 can be divided into a code storage area 110 and a user data storage area 120. 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.

[0029] In one embodiment, after backing up the firmware and other codes to the backup block 100, the main controller also needs 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 a cyclic redundancy check (CRC). The CRC check is performed by binary division of the firmware and other codes with a predefined polynomial, and the remaining result is the CRC check code. This check code is usually attached to the end of the data.

[0030] Specifically, during the writing process of 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 checksum, usually a 4-byte value, which is then appended to the end of the firmware and other codes.

[0031] Furthermore, after the main controller backs up the firmware and other codes to the backup block 100, the main controller will separate the last 4 bytes (storing the CRC check code) from the firmware and other code packages, and then perform the same CRC calculation on the rest of the file again. The calculated CRC value will be compared with the CRC check value attached to the end of the firmware and other codes. If the two are consistent, it means 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 means 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 in the code storage area 110 backed up to the backup block 100 are complete.

[0032] In one embodiment, when the main controller performs a write operation, the main controller can write user data into the data block. Since the amount of data of the firmware and other codes is small, it may not be possible 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 fully utilize the limited storage space, the main controller can also write user data into the user data storage area 120 in the backup block 100.

[0033] 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 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, it will be marked as an error bit. If the number of error bits of the flash memory is too high, it means that there are many errors in the storage unit of the flash memory, which may cause data corruption or inability to read correctly. At the same time, the number of writes to the flash memory is limited, and frequent write operations will cause wear and aging of the flash memory unit, thereby increasing the probability of error bits. The aging phenomenon that gradually occurs in the flash memory during use will affect its reliability.

[0034] Furthermore, when a risk occurs in the backup block 100, the main controller needs to migrate the user data in the backup block 100 to other data blocks and abandon the backup block. Specifically, the main controller can identify whether a risk occurs by monitoring the health status of the backup block 100. When the error rate of the backup block 100 exceeds a 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 migrate the user data stored in the backup block 100 to other data blocks as much as possible.

[0035] In one embodiment, after the backup block 100 is at risk, only the firmware block stores the firmware and other codes. In order to improve the security of storage, the main controller needs to determine whether there is a free block to obtain a new backup block.

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

[0037] Further, 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.

[0038] In one embodiment, when there are no free blocks, the main controller can trigger a garbage collection (GC) operation on the remaining data blocks to clear invalid data in a data block and represent it as a 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.

[0039] 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 integrity of the firmware and other codes can be verified by a cyclic redundancy check (CRC). When the main controller confirms that the firmware and other codes in the new backup block are complete, it indicates that the write is successful. 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 to the new backup block are complete.

[0040] In one embodiment, after the main controller marks the backup block 100 as a risk block, the metadata or status table in the system block can be updated to record the risk status of the block. In future read and write operations, the main controller will skip the use of the risk block.

[0041] Furthermore, since there is still some free storage space in the new backup block, namely the user data storage area 120, in order to fully utilize the limited storage space, the main controller may also write user data into the user data storage area 120 of the new backup block.

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

[0043] In one embodiment, during the use of the memory, when an extreme condition occurs, the firmware block may also be abnormal, causing the firmware block to be unusable. For example, extremely high or low temperatures may affect the performance and stability of the firmware block. For another example, power supply instability or voltage fluctuations may affect the normal operation of the firmware block. For another example, under high-load working conditions (such as high concurrent read and write operations), the firmware block may be subjected to excessive pressure, affecting its stability and reliability.

[0044] Further, when an abnormality occurs in a firmware block, the main controller can restart the firmware from the backup block 100 or a 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.

[0045] In one embodiment, after a firmware block is at risk, the firmware and other codes can be loaded from a backup block or a new backup block. 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 a free block.

[0046] Furthermore, when there are multiple free blocks, the free block that is accessed the latest can be obtained from the multiple free blocks. When there is only one free block, the free block is directly obtained. After the free block is obtained, the firmware and other codes in the backup block or the new backup block can be backed up to the free block, and the integrity check can be performed on it. 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 free block. Among them, when the above-mentioned data block is not full of user data, invalid data can be written to it to force the entire storage space to be filled.

[0047] Furthermore, when there is no free block, a GC operation can be triggered for the remaining data blocks, so that after the invalid data in a data block is cleared, it is indicated as a free 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 free block, and the integrity check is performed on it. Subsequently, user data can be written to the user data storage area 120 of the free block.

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

[0049] See also Figure 2 The present invention also provides a method for backing up the firmware of a memory, which can be applied to the above-mentioned memory to back up the firmware inside the memory. The backup method may include the following steps: Step S10, dividing the flash memory block into a system block, a firmware block and a data block, wherein the relevant information of the data block is stored in the system block, the data block is used to store user data, and the firmware block is used to store firmware and other codes; Step S20, selecting at least one free block from the data block; Step S30, 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; Step S40: 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 other free blocks and the backup block.

[0050] 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. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only 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; 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 into the user data storage areas of the other free blocks and the 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: The main controller is also used to monitor the status of the backup block, and when a risk occurs to the backup block, 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.

5. The memory according to claim 4, characterized in that: After the backup block is at risk, the main controller selects a block from the free blocks when it determines that there are other free blocks, 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.

6. The memory according to claim 4, characterized in that: 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.

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

8. 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.

9. The memory according to any one of claims 1, 5, 7 and 8, 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.

10. A method for backing up firmware of a memory, characterized in that: include: Divide the flash memory block 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; 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; The firmware and other codes of the firmware block are backed up in the code storage area of ​​the backup block, and user data is written into the user data storage area of ​​the other free blocks and the backup block.

Images