CN104731674B - Method and apparatus for storing electronic system firmware using MLC NVM - Google Patents
Method and apparatus for storing electronic system firmware using MLC NVM Download PDFInfo
- Publication number
- CN104731674B CN104731674B CN201510054992.0A CN201510054992A CN104731674B CN 104731674 B CN104731674 B CN 104731674B CN 201510054992 A CN201510054992 A CN 201510054992A CN 104731674 B CN104731674 B CN 104731674B
- Authority
- CN
- China
- Prior art keywords
- firmware
- copy
- area
- firmware image
- image
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
Methods and apparatus are provided for storing electronic system firmware using an MLC NVM. A method of storing electronic system firmware using MLC nonvolatile memory, wherein the MLC nonvolatile memory comprises a firmware storage area and a superblock area; the method comprises the following steps: s1: reading the super block area to obtain the information of the firmware image currently used; s2: acquiring a firmware area where a first copy of a currently used firmware image is located; s3: reading the first copy from a firmware area where the first copy is located; s4: if the reading process is wrong, selecting another copy of the currently used firmware image as the first copy, and repeating the steps S2-S4; and if the reading process is successful, finishing the reading process of the firmware image.
Description
Technical Field
The present invention relates to electronic devices, and more particularly, to a method and apparatus for storing electronic system firmware using MLC (Multi-level Cell) NVM (Non-Volatile Memory).
Background
Firmware is typically provided in the electronic device to provide underlying functionality of the electronic device, such as BIOS, operating system loading, and the like. The firmware is typically stored in ROM (read only memory), EEPROM or flash memory.
MLC NVM is a non-volatile memory capable of storing at least two bits of information in each memory cell. Compared with SLC (single Level cell) NVM, it has the characteristics of large storage capacity and low cost, but the storage reliability is not as good as SLC, and data damage or loss may occur.
Referring to fig. 1, fig. 1 shows a block diagram of a Solid-State Storage Device (SSD) as an example of an electronic Device. The storage device 102 includes a storage device 102 coupled to a host. The host and the storage device 102 can be coupled by various means including, but not limited to, connecting the host and the storage device 102 by, for example, SATA, IDE, USB, PCIE, NVMe (NVM Express), SCSI, ethernet, fibre channel, wireless communication network, etc. The host may be an information processing device, such as a personal computer, tablet, server, portable computer, network switch, router, cellular telephone, personal digital assistant, etc., capable of communicating with the storage device in the manner described above. Memory device 102 includes an interface 103, control circuitry 104, one or more NVM memory chips 105, and firmware memory 110. The interface 103 may be adapted to exchange data with a host by means such as SATA, IDE, USB, PCIE, NVMe, SCSI, ethernet, fibre channel, etc. Control circuitry 104 is used to control data transfer between interface 103, NVM memory chip 105, and firmware memory 110, as well as for memory management, host logical address to flash physical address mapping, erase leveling, bad block management, and the like. The control circuit 104 may be implemented in a variety of ways including software, hardware, firmware, or a combination thereof. The control Circuit 104 may be in the form of an FPGA (Field-programmable gate array), an ASIC (Application specific integrated Circuit), or a combination thereof. The control circuit 104 may also include a processor or controller. Control circuitry 104 loads firmware from firmware memory 110 at runtime. Firmware memory 110 may be NOR flash, ROM, EEPROM, etc.
The memory target is one or more Logic units (Logic units) of a shared Chip Enable (CE) signal within the NAND flash package. Each logical Unit has a Logical Unit Number (LUN). One or more dies (Die) may be included within the NAND flash memory package. Typically, a logic cell corresponds to a single die. The logical unit may include a plurality of planes (planes). Multiple planes within a logical unit may be accessed in parallel, while multiple logical units within a NAND flash memory chip may execute commands and report status independently of each other. The meaning for target, logical Unit, LUN, Plane (Plane) is provided in "Open NAND flash Interface Specification (Revision 3.0)" available from http:// www.micron.com// media/Documents/Products/Other% 20 Documents/ONFI 3_0gold.
Disclosure of Invention
NOR flash, ROM, EEPROM are all relatively expensive. The inventor wishes to utilize the MLC NVM with lower cost to store the firmware of the electronic device, and at the same time, solve the problem of low reliability of the data stored in the MLC NVM, so as to ensure reliable operation of the electronic device when the MLC NVM is used to store the firmware.
According to a first aspect of the present invention, there is provided a method of storing electronic system firmware using MLC non-volatile memory, wherein the MLC non-volatile memory comprises a firmware storage area in which at least two copies of a first firmware image and at least two copies of a second firmware image of an electronic system are stored, the firmware storage area comprising a plurality of firmware areas, each firmware area storing one copy of the first firmware image or one copy of the second firmware image; a firmware area occupying a plurality of memory blocks (blocks) of the MLC nonvolatile memory; the MLC nonvolatile memory further comprises a superblock, the superblock is used for recording the storage position of each firmware area, the superblock further stores a bad block table of the firmware area, the bad block table indicates the position of an unavailable storage block in the firmware area, and the superblock further stores information indicating the firmware currently in use; the method comprises the following steps: s1: reading the super block to obtain the information of the firmware image currently used; s2: acquiring a firmware area where a first copy of a currently used firmware image is located; s3: reading the first copy from a firmware area where the first copy is located; s4: if the reading process is wrong, selecting another copy of the currently used firmware image as the first copy, and repeating the steps S2-S4; and if the reading process is successful, finishing the reading process of the firmware image.
The method according to the first aspect of the present invention, wherein the firmware storage area and the super-blocks of the MLC non-volatile memory are accessed in a pseudo slc (pslc) mode.
The method according to the first aspect of the present invention, wherein multiple copies of the firmware image currently in use are read sequentially or in parallel.
The method according to the first aspect of the present invention, wherein the step S3 includes: s31: reading a bad block table of a firmware area where the first copy is located; s32: and sequentially reading available storage blocks of the firmware area where the first copy is located.
The method according to the first aspect of the present invention, wherein the firmware image copies are stored in physical address order in available memory blocks of the firmware area; and in the step S32, sequentially reading the available memory blocks of the firmware area where the first copy is located until the reading process is faulty or the end position of the first copy in the firmware area is read.
According to the method of the first aspect of the present invention, in step S4, the method further includes verifying the read firmware image.
The method according to the first aspect of the invention, wherein the MLC nonvolatile memory comprises a superblock area comprising multiple copies of the superblock.
According to a second aspect of the present invention, there is provided a method of storing electronic system firmware using MLC non-volatile memory, wherein the MLC non-volatile memory comprises a firmware storage area in which at least two copies of a first firmware image and at least two copies of a second firmware image of an electronic system are stored, the firmware storage area comprising a plurality of firmware areas, each firmware area storing one copy of the first firmware image or one copy of the second firmware image; a firmware area occupying a plurality of memory blocks (blocks) of the MLC nonvolatile memory; the MLC nonvolatile memory further comprises a superblock, wherein the superblock is used for recording the storage position of each firmware area, the superblock further stores a bad block table of the firmware area, the bad block table indicates the position of an unavailable storage block in the firmware area, and the superblock further stores information indicating a firmware image which is currently used; the method comprises the following steps: s1: reading the super block to obtain the information of the firmware image which is not used currently; s2: the method comprises the steps of obtaining a firmware area where a first copy of a firmware image which is not used currently is located, and updating the first copy; s3: acquiring another copy of the firmware image which is not currently used as a first copy, and repeating the steps S2-S3; until all copies of the firmware image not currently in use are updated.
The method according to the second aspect of the present invention, wherein the firmware image copies are stored in physical address order in available memory blocks of the firmware area, and wherein said step S2 comprises: s21: obtaining a firmware area where a first copy of a firmware image not currently in use is located, S22: reading a bad block table of a firmware area where the first copy is located; s23: determining an available storage block of the firmware area according to the bad block table and the erasing times of the storage block; s24: writing the firmware into an available storage block of a firmware area where the first copy is located in sequence; s25: and if the first copy is successfully written, recording the end position of the firmware area where the first copy is located and the current update time or the next update time of the first copy.
The method according to the second aspect of the invention, further comprising: updating the first copy after a preset time according to the current updating time; or updating the first copy when the next updating time comes according to the next updating time.
The method according to the second aspect of the present invention, wherein the firmware storage area and the super-blocks of the MLC non-volatile memory are accessed in a pseudo slc (pslc) mode.
According to the method of the second aspect of the present invention, the step S25 further includes: if the writing process has errors, the written storage block is marked as a bad block, and the bad block table of the first copy in the super block is updated, and the steps S22-S25 are repeated.
The method according to the second aspect of the present invention, wherein the currently used firmware image is the first firmware image, when the first firmware image is upgraded, the second firmware image is treated as a currently unused firmware image, and the steps S1-S3 are performed.
The method according to the second aspect of the invention, wherein multiple copies of the firmware image not currently in use are updated in parallel.
According to the method of the second aspect of the present invention, in step S24, the available memory blocks in the firmware area where the first copy is located are written in the order of physical addresses until the writing process goes wrong or the update of the first copy is completed.
The method according to the second aspect of the invention, wherein the MLC nonvolatile memory comprises a superblock area comprising multiple copies of the superblock.
According to a third aspect of the present invention, there is provided an apparatus for storing firmware of an electronic system using an MLC nonvolatile memory, wherein the MLC nonvolatile memory includes a firmware storage area in which at least two copies of a first firmware image and at least two copies of a second firmware image of the electronic system are stored, the firmware storage area including a plurality of firmware areas, each firmware area storing one copy of the first firmware image or one copy of the second firmware image; a firmware area occupying a plurality of memory blocks (blocks) of the MLC nonvolatile memory; the MLC nonvolatile memory further comprises a superblock, the superblock is used for recording the storage position of each firmware area, the superblock further stores a bad block table of the firmware area, the bad block table indicates the position of an unavailable storage block in the firmware area, and the superblock further stores information indicating the firmware currently in use; the device comprises: the first module is used for reading the super block and obtaining the information of the firmware image currently used; the second module is used for obtaining a firmware area where a first copy of the currently used firmware image is located; a third module, configured to read the first copy from a firmware area where the first copy is located; and the fourth module is used for selecting another copy of the currently used firmware image as the first copy if the reading process has errors, repeatedly executing the first module, the second module, the third module and the fourth module, and finishing the firmware image reading process if the reading process is successful.
According to a fourth aspect of the present invention, there is provided an electronic system comprising a control circuit and an MLC non-volatile memory for storing firmware of the electronic system, wherein the MLC non-volatile memory comprises a firmware storage area in which at least two copies of a first firmware image and at least two copies of a second firmware image of the electronic system are stored, the firmware storage area comprising a plurality of firmware areas, each firmware area storing one copy of the first firmware image or one copy of the second firmware image; a firmware area occupying a plurality of memory blocks (blocks) of the MLC nonvolatile memory; the MLC nonvolatile memory further comprises a superblock, the superblock is used for recording the storage position of each firmware area, the superblock further stores a bad block table of the firmware area, the bad block table indicates the position of an unavailable storage block in the firmware area, and the superblock further stores information indicating the firmware currently in use; the control circuit is used for executing the following steps: s1: reading the super block to obtain the information of the firmware image currently used; s2: acquiring a firmware area where a first copy of a currently used firmware image is located; s3: reading the first copy from a firmware area where the first copy is located; s4: if the reading process is wrong, selecting another copy of the currently used firmware image as the first copy, and repeating the steps S2-S4; and if the reading process is successful, finishing the reading process of the firmware image.
The electronic system according to the fourth aspect of the present invention, wherein the firmware storage area and the super-block of the MLC non-volatile memory are accessed in a pseudo slc (pslc) mode.
The electronic system according to the fourth aspect of the present invention, wherein a plurality of copies of the firmware image currently in use are read sequentially or in parallel.
The electronic system according to the fourth aspect of the present invention, wherein the step S3 includes: s31: reading a bad block table of a firmware area where the first copy is located; s32: and sequentially reading available storage blocks of the firmware area where the first copy is located.
The electronic system according to the fourth aspect of the present invention, wherein the firmware image copies are stored in physical address order in available memory blocks of the firmware area; and in the step S32, sequentially reading the available memory blocks of the firmware area where the first copy is located until the reading process is faulty or the end position of the first copy in the firmware area is read.
According to the electronic system of the fourth aspect of the present invention, in step S4, the method further includes verifying the read firmware image.
The electronic system according to a fourth aspect of the present invention, wherein the MLC nonvolatile memory comprises a superblock area comprising multiple copies of the superblock.
According to a fifth aspect of the present invention, there is provided an apparatus for storing firmware of an electronic system using an MLC nonvolatile memory, wherein the MLC nonvolatile memory includes a firmware storage area in which at least two copies of a first firmware image and at least two copies of a second firmware image of the electronic system are stored, the firmware storage area including a plurality of firmware areas, each firmware area storing one copy of the first firmware image or one copy of the second firmware image; a firmware area occupying a plurality of memory blocks (blocks) of the MLC nonvolatile memory; the MLC nonvolatile memory further comprises a superblock, wherein the superblock is used for recording the storage position of each firmware area, the superblock further stores a bad block table of the firmware area, the bad block table indicates the position of an unavailable storage block in the firmware area, and the superblock further stores information indicating a firmware image which is currently used; the device comprises: the first module is used for reading the super block and obtaining the information of the firmware image which is not used currently; the second module is used for obtaining a firmware area where a first copy of a firmware image which is not used currently is located and updating the first copy; and the third module is used for acquiring another copy of the firmware image which is not used currently as the first copy, and repeatedly executing the first module, the second module and the third module until all copies of the firmware image which is not used currently are updated.
According to a sixth aspect of the present invention, there is provided an electronic system comprising a control circuit and an MLC non-volatile memory for storing firmware of the electronic system, wherein the MLC non-volatile memory comprises a firmware storage area in which at least two copies of a first firmware image and at least two copies of a second firmware image of the electronic system are stored, the firmware storage area comprising a plurality of firmware areas, each firmware area storing one copy of the first firmware image or one copy of the second firmware image; the firmware area occupies a plurality of memory blocks of the MLC nonvolatile memory; the MLC nonvolatile memory further comprises a superblock, wherein the superblock is used for recording the storage position of each firmware area, the superblock further stores a bad block table of the firmware area, the bad block table indicates the position of an unavailable storage block in the firmware area, and the superblock further stores information indicating a firmware image which is currently used; the control circuit is used for executing the following steps: s1: reading the super block to obtain the information of the firmware image which is not used currently; s2: the method comprises the steps of obtaining a firmware area where a first copy of a firmware image which is not used currently is located, and updating the first copy; s3: acquiring another copy of the firmware image which is not currently used as a first copy, and repeating the steps S2-S3; until all copies of the firmware image not currently in use are updated.
The electronic system according to the sixth aspect of the present invention, further comprising: updating the first copy after a preset time according to the current updating time; or updating the first copy when the next updating time comes according to the next updating time.
The electronic system according to the sixth aspect of the present invention, wherein the firmware storage area and the super-block of the MLC non-volatile memory are accessed in a pseudo slc (pslc) mode.
According to the electronic system of the sixth aspect of the present invention, the step S25 further includes: if the writing process has errors, the written storage block is marked as a bad block, and the bad block table of the first copy in the super block is updated, and the steps S22-S25 are repeated.
The electronic system according to the sixth aspect of the present invention, wherein the firmware image currently in use is the first firmware image, when the first firmware image is upgraded, the second firmware image is treated as a currently unused firmware image, and the steps S1-S3 are performed.
The electronic system according to a sixth aspect of the present invention, wherein multiple copies of the firmware image not currently in use are updated in parallel.
According to the electronic system of the sixth aspect of the present invention, in step S24, the available memory blocks in the firmware area where the first copy is located are written in the order of physical addresses until the writing process goes wrong or the updating of the first copy is completed.
The electronic system according to a sixth aspect of the present invention, wherein the MLC nonvolatile memory comprises a superblock area comprising multiple copies of the superblock.
Drawings
The invention, as well as a preferred mode of use and further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
FIG. 1 is a block diagram of a prior art storage device;
FIG. 2 is a block diagram of a memory device according to an embodiment of the present invention;
FIG. 3 illustrates the data organization of firmware in an MLC NVM according to an embodiment of the present invention;
FIG. 4 is a flowchart of reading firmware from an MLC NVM according to an embodiment of the present invention;
FIG. 5 is a flow chart of writing firmware to an MLC NVM according to an embodiment of the present invention;
FIG. 6 is a flowchart for writing a firmware image copy to an MLC NVM according to a further embodiment of the present invention;
FIG. 7 illustrates the data organization of firmware in an MLC NVM according to a further embodiment of the present invention.
Detailed Description
FIG. 2 is a block diagram of a memory device according to an embodiment of the present invention. Memory device 202 in fig. 2 is similar to memory device 102 of fig. 1, and includes an interface 203 coupled to a host, control circuitry 204, and one or more NVM memory chips 205. The NVM memory chip 205 may be a NAND flash memory, a phase change memory (PCRAM), a resistive memory (RRAM), a ferroelectric memory (FeRAM), or other types of nonvolatile memory. The one or more NVM memory chips 205 are MLC NVMs, each memory cell of which is capable of storing at least 2 bits of information.
The memory device 202 in the embodiment of fig. 2 differs from the memory device 102 shown in fig. 1 in that a separate firmware memory 110 is not included, but rather firmware is stored in an NVM memory chip 205. Control circuitry 204 loads firmware from one or more NVM memory chips 205 at run time. The control circuit 204 may be implemented in a variety of ways including software, hardware, firmware, or a combination thereof. The control circuit 204 may be in the form of an FPGA, an ASIC, or a combination thereof. The control circuit 204 may also include a processor or controller. According to an embodiment of the present invention, the control circuit 204 is used to implement the flow shown in FIGS. 4-6 of reading or writing firmware from the MLC NVM.
FIG. 3 illustrates the data organization 300 of firmware in an MLC NVM according to an embodiment of the present invention. Super block 350 is provided in one or more NVM memory chips 205. Super block 350 is deposited in predetermined locations on one or more NVM memory chips 205. The storage device 202 first accesses the superblock 350 at startup. Although one or more NVM memory chips 205 are MLCNVMs, super block 350 is accessed in pseudo-SLC (pseudo-SLC) mode to improve reliability and extend data retention (dataretention) time. Basic boot information is stored in superblock 350, including, for example, metadata 360 for firmware image 1 and metadata 370 for firmware image 2. In one embodiment according to the present invention, a superblock area is included in one or more NVM memory chips 205, where superblock 350 and/or one or more copies of superblock 350 are included in the superblock area.
For firmware image 1 and firmware image 2, the same 1 st and 2 nd copies of firmware image 1 and the same 1 st and 2 nd copies of firmware image 2 are provided. To improve reliability, the number of firmware images may be greater than 2, and the number of copies of each firmware image may also be greater than 2. In superblock 350, metadata 360 for firmware image 1 includes a storage location or head address of the 1 st copy of firmware image 1, a bad block table for the 1 st copy, an update time for the 1 st copy, and an end location or tail address for the 1 st copy. Where the update time of a copy may be the time the copy was last updated or the time the copy should be updated next. The metadata 360 of firmware image 1 also includes a storage location or head address of the 2 nd copy of firmware image 1, a bad block table of the 2 nd copy, an update time of the 2 nd copy, and an end location or tail address of the 2 nd copy.
In superblock 350, metadata 370 for firmware image 2 includes a storage location or head address of the 1 st copy of firmware image 2, a bad block table for the 1 st copy, an update time for the 1 st copy, and an end location or tail address for the 1 st copy. The metadata 370 of firmware image 2 also includes a storage location or head address of the 2 nd copy of firmware image 2, a bad block table of the 2 nd copy, an update time of the 2 nd copy, an end location or tail address of the 2 nd copy.
Each time storage device 202 is powered up, superblock 350 may be traversed and the metadata for the firmware image currently in use may be found and the storage locations for the various copies of the firmware image may be obtained. In one embodiment, the firmware image currently in use is identified in the metadata of the firmware image. In another embodiment, a serial number is provided for the metadata of each firmware image, and the latest firmware image metadata is found based on the serial number to determine the firmware image currently in use. In one embodiment according to the present invention, when the storage device 202 is powered on, if an error occurs in reading the super block 350, one or more copies of the super block 350 in the super block area are read to obtain the correct super block.
Also included in super block 350 is firmware storage area 320. Firmware storage area 320 includes a plurality of firmware areas ( firmware areas 322, 324, 326, 328, 330, 332), each storing a copy of a firmware image. In one embodiment, firmware area 322 stores a 1 st copy of firmware image 1, firmware area 324 stores a 1 st copy of firmware image 2, firmware area 324 stores a 2 nd copy of firmware image 1, firmware area 326 stores a 2 nd copy of firmware image 1, and firmware area 328 stores a 2 nd copy of firmware image 2.
In firmware image 1 metadata 360, the 1 st copy storage location indicates a start storage location or head address of the firmware copy in firmware area 322, and the 1 st copy end location indicates a tail address of the firmware copy in firmware area 322. Firmware area 322 includes a plurality of memory blocks, and copy 1 of firmware image 1 is stored contiguously in available memory blocks of firmware area 322. A portion of the memory blocks in firmware area 322 may be corrupted and a bad block table for copy 1 is stored in firmware image 1 metadata 360 to identify bad blocks in firmware area 322. Since the 1 st copy of firmware image 1 is stored contiguously in the available memory blocks of firmware area 322, the 1 st copy of firmware image 1 in firmware area 322 may be read or written to depending on the head and tail addresses of firmware area 322 and the bad block table of the 1 st copy stored in firmware image 1 metadata 360.
In firmware image 1 metadata 360, the 2 nd copy storage location indicates a start storage location or head address of the firmware copy in firmware area 326, and the end location of the 2 nd copy indicates a tail address of the firmware copy in firmware area 326. A bad block table for copy 2 is stored in firmware image 1 metadata 360 to identify bad blocks in firmware area 326.
In firmware image 2 metadata 370, the 1 st copy storage location indicates a starting storage location or first address of the firmware copy in firmware area 324, and the 2 nd copy storage location indicates a starting storage location or first address of the firmware copy in firmware area 328.
In one embodiment, firmware image 1 and firmware image 2 each have more than 2 copies. The mth copy of firmware image 1 is stored in firmware area 330 and the mth copy of firmware image 2 is stored in firmware area 332.
In one embodiment, firmware storage area 320 includes n logical units, and firmware image 1 and firmware image 2 each have m copies, each occupying n/2m logical units. In a further embodiment, the physical storage locations of the 2m firmware sections of the firmware storage area 320 are contiguous.
FIG. 4 is a flow chart of reading out firmware from an MLC NVM according to an embodiment of the present invention. At power-up or startup of memory device 202 of fig. 2, controller 204 reads firmware from one or more NVM chips 205. The controller 204 implements the method shown in the embodiment of fig. 4 to read out the firmware.
At step 400, the controller determines the firmware image currently in use, e.g., firmware image 1, from superblock 350 (see FIG. 3). In one embodiment, the firmware image currently in use is identified in the metadata of the firmware image. In another embodiment, a serial number is provided for the metadata of each firmware image, and the latest firmware image metadata is found based on the serial number to determine the firmware image currently in use. In one embodiment, super block 350 is deposited in a predetermined location on one or more NVM memory chips 205. The controller, upon startup, may scan or access the predetermined location to access the super block 350.
At step 410, a variable i is set to 1 to begin looking up the 1 st copy of firmware image 1 (in the case where firmware image 1 is the currently in use firmware image) of superblock 350, where variable i indicates the i-th copy of the firmware image.
At step 420, accessing the firmware image 1 metadata 360 of the superblock 350, resulting in the storage location (e.g., the first address) of the ith (e.g., i ═ 1) copy, and the end location of the ith copy; in step 430, firmware image 1 metadata 360 is accessed to obtain a bad block table of a firmware area (e.g., firmware area 322) where the ith (e.g., i ═ 1) copy is located, and then to determine the distribution of the bad blocks of firmware area 322. In step 435, using the storage location of the ith copy obtained in step 420 and the bad block distribution information obtained in step 430, the available blocks of the firmware area (e.g., firmware area 322) are determined, and the available blocks of the firmware area (e.g., firmware area 322) are sequentially read in the order of physical addresses until the end location of the firmware area (e.g., firmware area 322) is read or the reading process is in error. In one embodiment, although one or more NVM memory chips 205 are MLCNVMs, firmware region 320 is accessed in a pseudo-SLC (pseudo-SLC) mode to improve reliability.
If the read process is faulty at step 450, step 460 is executed to increment the variable i to continue reading another copy of the firmware image currently in use. At step 470, a determination is made as to whether all copies of the firmware image currently in use have been read. If all copies of the currently in-use firmware image have been read, then proceed to step 480 where the firmware read process fails because the read process for each copy is in error. If, at step 470, it is determined that all copies of the currently used firmware image have not been read, then the process goes to step 420 to continue reading the ith copy of the currently used firmware image.
If the read process is not in error, at step 450, the process goes to step 455 to verify the read firmware. If the firmware checks for errors or the read firmware fails the check at step 465, then the process goes to step 460 to increment the variable i to continue reading another copy of the firmware image currently in use. If the firmware verification passes, proceed to step 490 where the firmware read is successfully completed.
FIG. 5 is a flow chart of writing firmware to an MLC NVM according to an embodiment of the present invention. The process of writing to the MLC NVM firmware is performed when the new version firmware is released. Or after writing the firmware for a period of time for improving reliability, reading the firmware and rewriting the read firmware into the MLC NVM, a process also referred to as firmware refresh. The firmware refresh may occur after a predetermined time interval of writing the firmware, which may be a fixed value or a value that varies with the number of erasures of the NVM. Firmware refreshes may also be initiated in response to a host or other externally sourced commands.
Referring to FIG. 5, the process of writing firmware begins at step 500 by obtaining a firmware image (e.g., firmware image 1) that is not currently in use according to superblock 350 (see also FIG. 3). In one embodiment, firmware updates are performed for firmware images that are not currently in use, thereby avoiding corruption of the firmware being used due to errors in the firmware write process. The writing process of NVM is a time consuming process, wherein if a power failure occurs, etc., it may result in an error in the writing process or incomplete firmware update, resulting in firmware damage.
At step 510, a variable i is set to 1 to begin looking up the 1 st copy of firmware image 1 (in the case where firmware image 1 is a firmware image not currently in use) of superblock 350, where variable i indicates the i-th copy of the firmware image. At step 520, an update is performed on the ith copy of the firmware image that is not currently in use. By accessing superblock 350 (see FIG. 3), a firmware region storing the ith copy of the firmware image that is not currently in use may be obtained. At step 530, the set variable i is incremented to continue updating another copy of the firmware image not currently in use. At step 540, a determination is made as to whether updates have been made to all copies of the currently unused firmware image, and if there are more copies of the currently unused firmware image that have not been updated, then return is made to step 520. In one embodiment, by accessing superblock 350 (see FIG. 3), the number of copies of the firmware image that are not currently in use may be obtained. In one embodiment, during the writing of firmware, all copies of firmware not currently in use are updated so that firmware image 1 has multiple identical copies, wherein the firmware of storage device 202 is successfully loaded as long as any one copy can be successfully read.
At step 550, a determination is made as to whether all copies of the firmware image that are not currently in use have failed writes. If the writing of all copies of the firmware image not currently in use fails, then the process goes to step 560 where the firmware writing process fails; if the write to any copy of the firmware image not currently in use is successful, then the firmware write is successful, proceeding to step 570. One skilled in the art will also appreciate that while a successful write of any one copy is considered a successful firmware write, a failure to write a copy of the firmware image will reduce the number of copies of the firmware image available, thereby reducing the reliability of the firmware storage. In one embodiment, at step 570, the case of a firmware copy write failure is also prompted, such as information of the number of firmware copy write failures, the number of bad blocks of the firmware area storing the firmware copy, or the reliability of the firmware storage area 320 of the storage device 202 or the corresponding firmware area is evaluated based on the information of the number of firmware copy write failures, the number of bad blocks of the firmware area storing the firmware copy, or the like. Based on the resulting reliability of the firmware storage area 320 or firmware area, the NVM storage chip 205 may be replaced or a further firmware update operation may be performed.
FIG. 6 is a flow chart of writing a firmware image to an MLC NVM according to yet another embodiment of the present invention. The flowchart shown in fig. 6 is a detailed description of step 520 in fig. 5. Those skilled in the art will recognize that the flow of writing the firmware image in fig. 6 is not intended to limit step 520 in fig. 5 to this particular manner, but rather is an example of a flow of writing firmware to an MLC NVM, and those skilled in the art will recognize other processes for writing firmware to an MLC NVM.
At step 600, metadata for the ith copy of the firmware image not currently in use is obtained from superblock 350 (see FIG. 3). The metadata includes a storage location (e.g., a head address), a bad block table, an end location (e.g., a tail address), or an update time of the ith copy, etc. It is noted that the step of obtaining metadata for the ith copy from superblock 350 of step 600 may be omitted if relevant metadata information has already been obtained (e.g., at step 500 of FIG. 5).
In step 610, the storage location of the next write is determined according to the bad block table of the ith copy and the storage location of the firmware area currently being written. In the firmware area, available blocks of the firmware area are sequentially written in the order of physical addresses. For example, if the current written storage location of the i-th copy firmware area (e.g., firmware area 322) is the k-th block, and it is known from the bad block table that the (k + 1) th and (k + 2) th blocks of firmware area 322 are bad blocks, the (k + 3) th block is determined to be the next written storage location. In this manner, the available blocks of firmware area 322 are written sequentially in physical address order, which enables wear of the memory blocks of firmware area 322 to be balanced, i.e., the erase times of each memory block of firmware area 322 are substantially the same. In one embodiment, the determined next written storage location may be a storage page in the storage block, e.g., the current written storage location is the p-th page of the k-th block, and the next written storage location is the p + 1-th page of the k-th block.
At step 620, it is determined whether the writing of the ith copy of the firmware image is complete. If the write is complete, then flow is directed to step 625, which represents a successful write of the ith copy of the firmware image. At step 625, the metadata corresponding to the ith copy in the metadata 360 of firmware image 1 of superblock 350 (in the case where firmware image 1 is a currently unused firmware image, and firmware image 1 is updated) is also updated, including the storage location (e.g., head address), bad block table, end location (e.g., tail address) or update time of the ith copy, etc. Where the update time of the ith copy may be the current time or the time when the copy should be updated next. If, at step 620, it is determined that the writing of the ith copy of the firmware image is not complete, then the process goes to step 630.
At step 630, a determination is made as to whether a firmware area (e.g., firmware area 322) has a memory block available. If there are no memory blocks already available in firmware area 322, then go to step 635 to identify that the writing of the ith copy of the firmware image failed because there are no memory blocks already available in firmware area 322 to write the ith copy of the firmware image. If it is determined at step 630 that there are memory blocks available in firmware area 322, the process returns to step 640.
At step 640, it is determined whether to begin writing to a new memory block. In a memory block, memory pages are sequentially written in the order of physical addresses. And if the blank page does not exist in the currently written storage block, starting to write a new storage block. If it is determined in step 640 that a new memory block needs to be written, the process proceeds to step 650, where the new memory block to be written is erased. And determines whether the erase operation was successful at step 660. If the erase is successful, go to step 645, write the data of the ith copy of the firmware image to the newly erased memory block. If it is determined in step 660 that the erase operation failed, then step 665 is diverted and a bad block table of firmware area 322 corresponding to the ith copy in metadata 360 of firmware image 1 in superblock 350 (in the case where firmware image 1 is a currently unused firmware image and firmware image 1 is updated) is updated to mark the memory block as a bad block. Turning to step 610, the next memory location to be written is found.
If it is determined in step 640 that a new memory block does not need to be written, then the process proceeds to step 645, where data is written to the next memory page of the currently written memory block. And determines whether the data write was successful at step 655. If it is determined at step 655 that the data write failed, then step 665 is diverted to update the bad block table of firmware area 322 corresponding to the ith copy in metadata 360 of firmware image 1 in superblock 350 (in the case where firmware image 1 is a firmware image that is not currently in use, and is updated for firmware image 1) to mark the memory block as a bad block. Turning to step 610, the next memory location to be written is found. If the data write is successful, as determined in step 655, then the process goes to step 610 to find the next memory location to be written.
FIG. 7 illustrates the data organization of firmware in an MLC NVM according to a further embodiment of the present invention. Similar to the data organization 300 of firmware in MLC NVM shown in fig. 3, the data organization 700 of firmware in MLC NVM is shown in fig. 7. Super block 350 is provided in one or more NVM memory chips 205. Basic boot information is stored in superblock 350, including, for example, metadata 360 for firmware image 1 and metadata 370 for firmware image 2. A firmware storage area 320 is also provided in the one or more NVM storage chips 205, the firmware storage area 320 including a plurality of firmware areas ( firmware areas 322, 324, 326, 328, 330, 332), each firmware area storing a copy of the firmware image.
In one embodiment, one or more NVM memory chips 205 are organized into multiple channels ( channels 710, 720, 730), which may be accessed in parallel. Multiple copies of the firmware image are placed on multiple channels, e.g., a 1 st copy of firmware image 1 is placed on channel 710, a 2 nd copy of firmware image 1 is placed on channel 720, and an nth copy of firmware image 1 is placed on channel 730; while the 1 st copy of firmware image 2 is placed on channel 710, the 2 nd copy of firmware image 2 is placed on channel 720, and the nth copy of firmware image 2 is placed on channel 730. In this manner, multiple copies of the firmware image may be read or written in parallel, which may reduce the time required for the firmware copy read or write process. When one copy is read or written from one channel and an error occurs, the copy reading or writing processes of other channels are also carried out, so that the reading and writing time of a plurality of copies is shortened. In one embodiment, multiple copies of the firmware image are accessed in a RAID fashion. In one embodiment, different portions of firmware image 1 are read out in parallel from the copies of the various channels and combined into firmware image 1, thereby further reducing the read time of the copies.
In the above, the storage device is taken as an example to describe a method for storing electronic system firmware by using the MLC nonvolatile memory, and a method for reading firmware from the MLC nonvolatile memory and writing firmware into the MLC nonvolatile memory. Those skilled in the art will appreciate that the methods disclosed in the present invention are applicable not only to memory devices, but also to other electronic devices that include MLC nonvolatile memory and control circuitry. Those skilled in the art will also recognize that the methods or operational procedures disclosed in this disclosure may be implemented by software, firmware, hardware, and any combination thereof. The invention also provides electronic systems and/or control circuits that implement the disclosed methods or operational procedures.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art.
Claims (8)
1. A method of storing electronic system firmware using MLC non-volatile memory, wherein the MLC non-volatile memory comprises a firmware storage area in which at least two copies of a first firmware image and at least two copies of a second firmware image of an electronic system are stored, the firmware storage area comprising a plurality of firmware areas, each firmware area storing one copy of the first firmware image or one copy of the second firmware image; a firmware area occupying a plurality of memory blocks (blocks) of the MLC nonvolatile memory; the MLC nonvolatile memory further comprises a superblock, wherein the superblock is used for recording the storage position of each firmware area, the superblock also stores a bad block table of the firmware area, the bad block table indicates the position of an unavailable storage block in the firmware area, and the superblock also stores information indicating a firmware image which is currently used; in the superblock, the metadata of the first firmware image and the metadata of the second firmware image both include a storage location or a head address, a bad block table, an update time, and an end location or a tail address of each copy of each firmware image;
the method comprises the following steps:
s1: reading the super block to obtain the information of the firmware image currently used;
reading the superblock to obtain the information of the firmware image currently used, including identifying the firmware image currently used in the metadata of the firmware image or providing a serial number for the metadata of each firmware image, and finding the latest firmware image metadata according to the serial number to determine the firmware image currently used;
s2: acquiring a firmware area where a first copy of a currently used firmware image is located;
s3: reading the first copy from a firmware area where the first copy is located;
s4: if the reading process is wrong, selecting another copy of the currently used firmware image as the first copy, and repeating the steps S2-S4; if the reading process is successful, the firmware image reading process is completed;
the steps S2 and S3 specifically include:
searching the ith copy of the firmware image of the superblock;
accessing firmware mirror pixel data of the super block to obtain a storage position of an ith copy and an end position of the ith copy;
accessing firmware mirror pixel data to obtain a bad block table of a firmware area where the ith copy is located, and further determining the distribution of bad blocks of the firmware area;
and determining the usable blocks of the firmware area by using the storage position of the ith copy and the bad block distribution information, and sequentially reading the usable blocks of the firmware area according to the physical address sequence until the end position of the firmware area is read or the reading process is in error.
2. The method of claim 1, wherein the firmware storage areas and super-blocks of the MLC nonvolatile memory are accessed in a pseudo slc (pslc) mode.
3. A method according to claim 1 or 2, wherein multiple copies of the firmware image currently in use are read sequentially or in parallel.
4. The method of claim 1, wherein the step S3 includes:
s31: reading a bad block table of a firmware area where the first copy is located;
s32: and sequentially reading available storage blocks of the firmware area where the first copy is located.
5. The method of claim 4, wherein the firmware image copies are stored in physical address order in available memory blocks of the firmware area; and in the step S32, sequentially reading the available memory blocks of the firmware area where the first copy is located until the reading process is faulty or the end position of the first copy in the firmware area is read.
6. The method of claim 1, wherein the step S4 further comprises verifying the read firmware image.
7. The method of claim 1, wherein the MLC nonvolatile memory comprises a superblock area, the superblock area comprising multiple copies of the superblock.
8. An apparatus for storing electronic system firmware using MLC nonvolatile memory, wherein the MLC nonvolatile memory comprises a firmware storage area in which at least two copies of a first firmware image and at least two copies of a second firmware image of an electronic system are stored, the firmware storage area comprising a plurality of firmware areas, each firmware area storing one copy of the first firmware image or one copy of the second firmware image; a firmware area occupying a plurality of memory blocks (blocks) of the MLC nonvolatile memory; the MLC nonvolatile memory further comprises a superblock, wherein the superblock is used for recording the storage position of each firmware area, the superblock further stores a bad block table of the firmware area, the bad block table indicates the position of an unavailable storage block in the firmware area, and the superblock further stores information indicating a firmware image which is currently used; in the superblock, the metadata of the first firmware image and the metadata of the second firmware image both include a storage location or a head address, a bad block table, an update time, and an end location or a tail address of each copy of each firmware image;
the device comprises:
the first module is used for reading the super block and obtaining the information of the firmware image currently used;
reading the superblock to obtain the information of the firmware image currently used, including identifying the firmware image currently used in the metadata of the firmware image or providing a serial number for the metadata of each firmware image, and finding the latest firmware image metadata according to the serial number to determine the firmware image currently used;
the second module is used for obtaining a firmware area where a first copy of the currently used firmware image is located;
a third module, configured to read the first copy from a firmware area where the first copy is located;
the fourth module is used for selecting another copy of the currently used firmware image as the first copy if the reading process has errors, and repeatedly executing the first module, the second module, the third module and the fourth module, and completing the firmware image reading process if the reading process is successful;
the second module and the third module specifically include:
searching the ith copy of the firmware image of the superblock;
accessing firmware mirror pixel data of the super block to obtain a storage position of an ith copy and an end position of the ith copy;
accessing firmware mirror pixel data to obtain a bad block table of a firmware area where the ith copy is located, and further determining the distribution of bad blocks of the firmware area;
and determining the usable blocks of the firmware area by using the storage position of the ith copy and the bad block distribution information, and sequentially reading the usable blocks of the firmware area according to the physical address sequence until the end position of the firmware area is read or the reading process is in error.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510054992.0A CN104731674B (en) | 2015-02-02 | 2015-02-02 | Method and apparatus for storing electronic system firmware using MLC NVM |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510054992.0A CN104731674B (en) | 2015-02-02 | 2015-02-02 | Method and apparatus for storing electronic system firmware using MLC NVM |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104731674A CN104731674A (en) | 2015-06-24 |
| CN104731674B true CN104731674B (en) | 2020-09-01 |
Family
ID=53455586
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510054992.0A Active CN104731674B (en) | 2015-02-02 | 2015-02-02 | Method and apparatus for storing electronic system firmware using MLC NVM |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104731674B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106354615B (en) * | 2015-07-21 | 2021-06-01 | 北京忆恒创源科技有限公司 | Solid state disk log generation method and device |
| CN105302479A (en) * | 2015-09-29 | 2016-02-03 | 联想(北京)有限公司 | Data management method and storage device |
| CN108932175B (en) * | 2017-05-24 | 2022-01-11 | 建兴储存科技(广州)有限公司 | Control method of solid state storage device |
| CN109582239B (en) * | 2018-12-03 | 2022-02-18 | 郑州云海信息技术有限公司 | SSD bad block table storage method, device, equipment and storage medium |
| US10777297B2 (en) * | 2018-12-10 | 2020-09-15 | Micron Technology, Inc. | Age-based refresh of firmware |
| CN110517124A (en) * | 2019-07-09 | 2019-11-29 | 咪咕文化科技有限公司 | Transaction control method and device, insert arrangement, computer readable storage medium |
| CN110471625B (en) * | 2019-08-15 | 2021-04-20 | 深圳忆联信息系统有限公司 | Bad block information protection method and device, computer equipment and storage medium |
| CN111104256A (en) * | 2019-11-30 | 2020-05-05 | 浪潮电子信息产业股份有限公司 | Data reading method, device, equipment and storage medium |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7594135B2 (en) * | 2003-12-31 | 2009-09-22 | Sandisk Corporation | Flash memory system startup operation |
| US7774596B2 (en) * | 2005-02-02 | 2010-08-10 | Insyde Software Corporation | System and method for updating firmware in a secure manner |
| JP5221332B2 (en) * | 2008-12-27 | 2013-06-26 | 株式会社東芝 | Memory system |
| CN104166558B (en) * | 2013-05-16 | 2018-06-15 | 群联电子股份有限公司 | Firmware code loading method, Memory Controller and memory storage apparatus |
-
2015
- 2015-02-02 CN CN201510054992.0A patent/CN104731674B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN104731674A (en) | 2015-06-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104731674B (en) | Method and apparatus for storing electronic system firmware using MLC NVM | |
| US10373693B2 (en) | Storage device and method of operating the storage device | |
| US10372603B2 (en) | Handling of unaligned writes | |
| US11862263B2 (en) | Storage device and method of operating the same | |
| US9460006B2 (en) | Nonvolatile memory system, system including the same, and method of adaptively adjusting user storage region in the same | |
| US9672942B2 (en) | Data decoding method of non-volatile memory device and apparatus for performing the method | |
| US9747170B2 (en) | Non-volatile multi-level cell memory system and method of performing adaptive data back-up in the system | |
| JP5585919B2 (en) | Power shutdown management | |
| JP4524309B2 (en) | Memory controller for flash memory | |
| JP5649742B2 (en) | Transaction log restore | |
| US7477547B2 (en) | Flash memory refresh techniques triggered by controlled scrub data reads | |
| US9251891B1 (en) | Devices and methods to conditionally send parameter values to non-volatile memory | |
| KR102564774B1 (en) | Apparatus for diagnosing memory system or data processing system and operating method of memory system or data processing system based on diagnosis | |
| EP3520106B1 (en) | Memory management | |
| US20140281158A1 (en) | File differentiation based on data block identification | |
| TW201931366A (en) | Data storage device and control method for non-volatile memory | |
| KR20160074025A (en) | Operating method for data storage device | |
| CN112015329A (en) | Storage system and operation method thereof | |
| WO2008118705A1 (en) | Flash memory refresh techniques triggered by controlled scrub data reads | |
| US11113202B2 (en) | Operating method forcing the second operation to fail using a scatter-gather buffer and memory system thereof | |
| US10942678B2 (en) | Method of accessing data in storage device, method of managing data in storage device and storage device performing the same | |
| CN110389907B (en) | electronic device | |
| KR20200139913A (en) | Memory system, memory controller and meta infomation storage device | |
| US20180341605A1 (en) | Programming interruption management | |
| US11586379B2 (en) | Memory system and method of operating the same |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP03 | Change of name, title or address | ||
| CP03 | Change of name, title or address |
Address after: 100192 room A302, building B-2, Dongsheng Science Park, Zhongguancun, 66 xixiaokou Road, Haidian District, Beijing Patentee after: Beijing yihengchuangyuan Technology Co.,Ltd. Address before: Room A302, building B-2, Dongsheng Science Park, No. 66, xixiaokou Road, Haidian District, Beijing 100192 Patentee before: MEMBLAZE TECHNOLOGY (BEIJING) Co.,Ltd. |