Method and apparatus for testing firmware of storage device

Abstract

Disclosed is a method for testing firmware for a storage device, comprising: setting a flag corresponding to a portion of storage blocks of the storage device; identifying both detected real bad storage blocks of the storage device and the portion of storage blocks corresponding to the flag as bad storage blocks; determining a plurality of reserved storage blocks for storing the firmware based on the identified bad storage blocks; loading the firmware into at least a portion of the plurality of reserved storage blocks; and processing a test command by the firmware and returning a processing result for the test command.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to a storage device, and more particularly, to a method and apparatus for testing firmware of a storage device. Background Art

[0002] Universal Flash Storage (UFS) memory cards are a mainstream storage device in computing devices, especially mobile devices. UFS storage devices, or UFS memory cards, contain a UFS controller and flash array. The UFS controller runs the firmware loaded on the UFS storage device to implement various UFS device operations and functions.

[0003] Before mass production of UFS storage devices, the firmware needs to be tested to discover as many problems as possible in the firmware and improve the firmware's performance through debugging. In practice, during the firmware testing process, due to the limited number of flash memory arrays (such as NAND flash memory arrays) used for testing, the distribution of bad blocks in the flash memory array that can be tested is also limited. Since the distribution of bad blocks in the flash memory array affects the operating logic of the firmware, the limited number of flash memory arrays used for testing leads to limited test coverage of the firmware. As a result, some firmware problems may not appear until after mass production, causing potential problems for computing devices (such as mobile phones) that use the storage device, and even affecting user experience. Summary of the Invention

[0004] To address the problem of low firmware test coverage in storage devices, this article discloses how to improve firmware test coverage by embedding various bad storage block distributions of the storage device's storage array into the card activation process for the storage device. This allows firmware problems to be discovered before mass production, helping to efficiently resolve and optimize the firmware's code logic and improve the performance of the storage device.

[0005] In one embodiment, a method for testing firmware for a storage device is disclosed, the method comprising: a method for testing firmware for a storage device, comprising: setting a flag corresponding to a portion of storage blocks of the storage device; identifying both the detected real bad storage blocks of the storage device and the portion of storage blocks corresponding to the flag as bad storage blocks; determining a plurality of reserved storage blocks for storing the firmware based on the identified bad storage blocks; loading the firmware into at least a portion of the plurality of reserved storage blocks; and processing a test command by the firmware and returning a processing result for the test command.

[0006] In another embodiment, a device for testing firmware for a storage device is disclosed, the device comprising: a flag setting module for setting a flag corresponding to a portion of storage blocks of the storage device; a detection module for detecting whether the storage blocks of the storage device are good storage blocks or bad storage blocks, wherein the actual bad storage blocks of the storage device detected by the detection module and the portion of storage blocks corresponding to the flag are both identified as bad storage blocks; a reservation module for determining a plurality of reserved storage blocks for storing the firmware based on the identified bad storage blocks; a firmware loading module for loading the firmware into at least a portion of the plurality of reserved storage blocks; and a firmware module for processing a test command through the firmware and returning a processing result for the test command.

[0007] In another embodiment, a device for testing firmware for a storage device is disclosed, which includes: one or more processing units; and a storage unit that stores instructions that, when executed by the one or more processing units, cause the one or more processing units to perform the above-mentioned method and the methods of each embodiment of the present disclosure.

[0008] In another embodiment, a machine-readable storage medium is disclosed, which stores executable instructions. When the instructions are executed, one or more processing units execute the above method and the methods of various embodiments of the present disclosure.

[0009] In another embodiment, a computer program product is disclosed, comprising executable instructions, which, when executed, cause one or more processing units to perform the above method and the methods of various embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The drawings of the embodiments of the present disclosure are briefly described as follows, in which the same or corresponding components are represented by the same or similar reference numerals.

[0011] Figure 1 A schematic block diagram of a storage device is shown according to an embodiment of the present disclosure.

[0012] Figure 2 According to one embodiment of the present disclosure, a schematic block diagram of a test system for testing firmware of a storage device is shown.

[0013] Figure 3 According to one embodiment of the present disclosure, a schematic flowchart of a process for testing firmware of a storage device is shown.

[0014] Figure 4A and 4B According to an embodiment of the present disclosure, examples of a storage block mapping table obtained on the same storage device with and without an error flag being implanted are respectively shown.

[0015] Figure 5 According to one embodiment of the present disclosure, a schematic flowchart of a process for testing firmware of a storage device is shown.

[0016] Figure 6 According to one embodiment of the present disclosure, a schematic block diagram of an apparatus for testing firmware of a storage device is shown.

[0017] Figure 7 According to one embodiment of the present disclosure, a schematic flowchart of an apparatus for testing firmware of a storage device is shown. DETAILED DESCRIPTION

[0018] Specific embodiments of the present disclosure will be described below, and those skilled in the art will appreciate that obvious variations of the described embodiments may be used without departing from the scope of the present disclosure.

[0019] Figure 1 A schematic block diagram of a storage device 10 is shown according to an embodiment of the present disclosure.

[0020] In such Figure 1 In the example shown, the storage device 10 is a storage device that complies with the UFS standard, and is referred to as the UFS storage device 10. In one embodiment, the storage device 10 can be used as a storage component in various computing devices, such as computers, communication devices, multimedia devices, and gaming devices.

[0021] The storage device 10 includes a storage controller 110 and a storage array 120. The semiconductor storage array 120 may be a flash memory, a NAND type flash memory, or a 3D NAND flash memory. Figure 1 As shown, the storage array 120 may include multiple storage chips 1210, which may also be referred to as storage dies 1210. Each storage chip 1210 may include multiple storage blocks 1220, and some storage blocks 1220 may include firmware 1230. The firmware 1230 is generally loaded into the storage device 10 before it leaves the factory, so that the processing unit 1120 of the storage controller 110 executes the code instructions in the firmware 1230 to implement various operations and functions of the storage device 10. The storage controller 110 may implement various operations with the storage array 120 via the storage array interface 1140.

[0022] The storage controller 110 can control various operations of the storage device 10. As shown in FIG1 , the storage controller 110 can receive host instructions via the host interface 1110 and perform various operations based on the instructions. For example, in response to a write operation instruction, the storage controller 110 can write data from the host to the storage array 120, in response to a read operation instruction, the storage controller 110 can read data from the storage array 120 and transmit it to the host via the host interface, etc. The host can be any of the computing devices mentioned above, such as a computer, a communication device, a multimedia device, a gaming device, etc.

[0023] The storage unit 1130 may be a random access memory (RAM) that stores machine-executable instructions, and the processing unit 1120 may be a processor, such as a central processing unit (CPU), that controls the operation of the storage device 10 by executing the instructions in the storage unit 1130. The processing unit 1120 may also be implemented by a dedicated logic circuit (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.). The storage unit 1130 may also be used to store or cache data used for, for example, read or write operations. For example, when performing a write operation, the storage unit 1130 may cache the data to be written. In one example, after the instruction code of the firmware 1230 is loaded into the RAM 1130, the processing unit 1120 implements various operations or functions of the storage device 10 by executing the instructions loaded in the RAM 1130, such as read or write commands for the storage device, commands for updating or replacing the firmware 1230, commands for searching for the first good storage block, commands for remapping and updating the mapping table, commands related to power management of the storage device 200, commands related to power-off recovery of the storage device 200, commands for data error correction or reconstruction of the storage device 200, and the like.

[0024] Those skilled in the art will appreciate that the storage controller 110 and the storage device 200 may include more or fewer components. For ease of description, Figure 1 Not all details are shown.

[0025] Figure 2 According to one embodiment of the present disclosure, a schematic block diagram of a test system 20 for testing firmware of a storage device is shown.

[0026] The test system 20 includes a terminal computer 210, a UFS host 220, and a UFS storage device 230. The tester can perform various tests on the UFS firmware 2320 through operations on the computer 210. In order to implement the test of the UFS firmware 2320 of the storage device 230, scripts 2110 with different functions can be designed to test whether the UFS firmware 2320 has problems when performing the corresponding functions. In one example, the test script 2110 can be implemented using the Python programming language. In one example, the test script 2110 can simulate a mobile phone application.

[0027] As shown by arrow 1, the test script 2110 can send commands and data 2120 by calling the application programming interface (API) of the software development kit (SDK). In one example, the SDK can simulate the driver between the mobile phone application and the mobile phone system.

[0028] As shown by arrow 2, commands and data from the test script 2110 are sent to the UFS host 220 via the interface between the UFS host 220 and the computer 210. In one example, the UFS host 220 can be a test board used to simulate a mobile phone system. The UFS host 220 and the terminal computer 210 can be connected via various suitable interfaces, such as a USB interface, a PCI interface, etc.

[0029] As shown by arrow 3, the UFS host 220 sends the received command and data to the UFS device 230 through the UFS interface. In one example, the UFS storage device 230 is an embedded UFS storage device installed on the UFS host 220, such as a solid-state memory card of the UFS host 220. The UFS storage device 230 may be Figure 1 The UFS storage device 10 shown in FIG. 1 includes a storage array 2310 storing UFS firmware 2320. The UFS firmware 2320 is used to implement various controls and operations of the UFS storage device 230, such as various storage controls and power management for the storage array 2310. The processing unit 1120 processes commands and data received from the host 220 by executing code instructions in the firmware 2320 and returns a processed result to the host 220, as indicated by arrow 4.

[0030] As indicated by arrow 5, UFS host 220 returns the processing result received from storage device 230 to SDK 2120. As indicated by arrow 6, SDK 2120 returns the processing result received from UFS host 220 to test script 2110. Test script 2110 verifies whether the returned processing result meets the requirements. If it does, the test based on the test script passes. If it does not, it means that there may be a problem with firmware 2320, and further debugging of firmware 2320 is required.

[0031] Because the distribution of bad memory blocks in storage array 2310 affects the operational logic of firmware 2320, the number of storage arrays 2310 used for testing affects the test coverage of firmware 2320. In practice, the number of storage arrays (such as NAND flash memory arrays) used for testing is limited, and the distribution of bad blocks in the flash memory array that can be tested is also limited, which affects the test coverage of firmware 2320 and may result in insufficient detection of firmware 2320 problems before storage device 230 goes into mass production.

[0032] Figure 3 According to one embodiment of the present disclosure, a schematic flowchart of a process for testing firmware of a storage device is shown.

[0033] To improve the test coverage of storage device firmware, Figure 3 The illustrated process adjusts the storage device's card activation process to implant bad memory block information related to a portion of the storage device's memory blocks during the card activation process (such as the process shown in 310-380). This ensures that, from the firmware's perspective, the artificially implanted bad memory blocks are identical to the actual bad blocks in the storage array, both during the firmware loading process and during the firmware's operation after loading. This effectively improves the firmware's test coverage. Generally speaking, the primary task of a storage device's card activation process is to load firmware into the storage device, enabling the storage device to perform various functions. Firmware is the code segment, typically binary code, that performs the underlying work of the storage device and determines the storage device's functions and performance.

[0034] At 310, the boot code is loaded and executed. In one example, the boot code can be loaded for the storage device by a host device connected to the storage device (eg, the UFS storage device 10). Figure 1 The illustrated processing unit 1120 may execute boot code.

[0035] At 320, the processing unit 1120 may execute the boot code to implant a flag corresponding to a portion of the storage blocks of the storage device. In one example, the boot code may set a global flag for a portion of the storage blocks of the storage device, which may be referred to as a global error flag.

[0036] At 330, the block detection code 330 is loaded and executed. In one example, the block detection code 330 is loaded and executed under the guidance of the boot code 310. In one example, the processing unit 1120 executes the block detection code to perform an erase operation on the memory blocks 1220 of the memory array 120. After performing the erase operation on each memory block, an indication of success or failure may be returned, which indicates whether the memory block is a good block or a bad block, respectively.

[0037] For each storage block 1220, as shown in 340, the block detection code can determine whether it has the above-mentioned global error flag. If the storage block has the global error flag, as shown in 345, it is identified as a bad storage block, regardless of whether the storage block is actually a good block or a bad block. As shown in 340, if the storage block does not have the global error flag, as shown in 350, it is identified as a good block or a bad block based on the result of the erase operation on the storage block. If the erase result of the storage block is failure, as shown in 345, it is identified as a bad block. If the erase result of the storage block is success, as shown in 355, it is identified as a good block.

[0038] Although the block detection code ultimately identifies the storage block as a good block or a bad block in the operations 340 to 355 described above, the present disclosure is not limited to this. In another example, the block detection code may perform an erase operation on each storage block to identify each storage block as a real good block or bad block, and then the boot code may ultimately identify the storage block as a good block or bad block as shown in 345 and 355 based on whether the storage block has a global error flag. In another example, the block detection code may perform an erase operation on all storage blocks, or may only perform an erase operation on storage blocks without error flags. Those skilled in the art will understand that the judgment logic of 340 and 350 is to illustrate that the boot code or block detection code ultimately identifies both the detected real bad storage blocks and a portion of the storage blocks with error flags as bad storage blocks, and the present disclosure is not limited to the specific implementation order of the judgment logic.

[0039] At 360 , the boot code updates the memory block mapping table based on the identification of bad blocks and good blocks at 345 and 355 , identifying the identified bad blocks and good blocks therein.

[0040] At 370, a plurality of reserved memory blocks for storing the firmware 2320 is determined based on the updated block mapping table, the plurality of reserved memory blocks being selected from the good blocks identified in the mapping table. In one example, eight good blocks, for example, can be selected from the mapping table as the reserved memory blocks for storing the firmware. In one example, the firmware and its backup can be stored in a portion of the plurality of reserved memory blocks. In one example, code for selecting the plurality of reserved memory blocks can be loaded and executed under the guidance of the boot code.

[0041] In one example, the code for selecting the plurality of reserved memory blocks may be part of the firmware 2320. In this example, the firmware 2320 is loaded and executed under the guidance of the boot code, and the firmware 2320 performs the operations of updating the memory block mapping table in 360 and determining the reserved memory blocks in 370 based on the bad memory blocks and good memory blocks identified at 345 and 355. It will be appreciated that the operation of determining the reserved memory blocks in 370 may be completed in the operation of updating the memory block mapping table in 360. The firmware 2320 and its backup are then finally loaded into at least a portion of the plurality of reserved memory blocks, for example, into four of the eight reserved memory blocks, at 380.

[0042] At 380, firmware 2320 may be loaded into at least a portion of the reserved memory block, and the card activation process may be completed by executing operations of firmware 2320. For example, processing unit 1120 may configure a memory block mapping table by executing instructions of firmware 2320. In one example, firmware 2320 may be loaded and executed under the guidance of a boot code.

[0043] In one example, the boot code, storage block detection code, storage block reserved code, and firmware 2320 are all binary code. The boot code, storage block detection code, and storage block reserved code can also be referred to as temporary firmware, which is temporarily loaded into the storage device during the card activation process and can be deleted from the storage device after the card activation is completed. In another example, the storage block reserved code can also be part of firmware 2320.

[0044] At 390, the test program is processed by the firmware loaded at 380 and the processing result of the test program is returned. Figure 2 In the test process shown, at 390, processing unit 1120 executes commands and data received from a host test program with the help of UFS firmware 2320. For example, the test program can trigger firmware 2320 to search for the first good block and remap the storage block mapping table. For another example, the test program can trigger firmware 2320 to execute one or more of the following commands: read or write commands to the storage device; commands for updating or replacing firmware 2320; commands related to power loss recovery of the storage device; commands for data error correction or reconstruction of the storage device; and so on.

[0045] Figure 4A and 4B According to an embodiment of the present disclosure, examples of a storage block mapping table obtained on the same storage device with and without an error flag being implanted are respectively shown.

[0046] The memory mapping tables 4A and 4B are formed by the firmware 2320 during the card opening process, for example, in conjunction with Figure 3 In one example described, the firmware 2320 may be formed in step 380 in conjunction with Figure 3 In another example described, the firmware 2320 may be formed in step 360. It will be understood by those skilled in the art that Figure 4A and 4B The mapping table shown is only an illustrative example, and any mapping table formed in any specific step is within the scope of the present disclosure.

[0047] like Figure 4A and 4B As shown, VB represents a virtual block. For example, CE0PLN0 represents CellEnable0Plane0. Each element in the table corresponds to a storage block. goodBlk indicates that the block is a good block, and earlybb indicates that the block is a bad block. For example, cis1Blk indicates that the block is a reserved storage block for storing firmware 2320 and its backup. Other symbols are configuration information generated by firmware 2320 when updating the storage block mapping table and are not described in detail.

[0048] contrast Figure 4A and Figure 4B It can be seen that in Figure 3 In the illustrated process, 6 example bad blocks are implanted, as shown in the gray shading portion. Accordingly, the distribution of the 8 reserved storage blocks determined for storing the firmware is also different, as shown in the grid shading portion. The distribution of bad blocks in the storage array has an impact on the operation of the firmware 2320. For example, the firmware 2320 may subsequently perform firmware updates and replacements based on these 8 reserved blocks. For different distributions of these 8 blocks, the logic of firmware updates and replacements may be different. Figure 4A As shown, by injecting errors in advance, it helps to fully expose various problems of the firmware 2320, thereby improving the firmware 2320 before mass production.

[0049] Figure 4AA memory block distribution for implanting errors is shown. In other examples, various memory block distributions may be used to implant errors. For example, a memory block to be implanted with an error is randomly selected from the memory blocks of a storage device. The memory blocks to be implanted with an error include consecutive memory blocks. The memory blocks to be implanted with an error include a consecutive row of memory blocks. Here, a row of memory blocks corresponds to Figure 4A The storage block in a VB shown, and so on.

[0050] Figure 5 According to one embodiment of the present disclosure, a schematic flowchart of a process for testing firmware of a storage device is shown.

[0051] At 510 , a flag corresponding to a portion of a memory block of a memory device is set.

[0052] At 520 , both the detected actual bad memory blocks of the storage device and a portion of the memory blocks corresponding to the flag are identified as bad memory blocks.

[0053] At 530 , a plurality of reserved memory blocks for storing firmware is determined based on the identified bad memory blocks.

[0054] At 540, the firmware is loaded into at least a portion of the plurality of reserved memory blocks.

[0055] At 550 , the test command is processed by the firmware and a processing result for the test command is returned.

[0056] In one embodiment, before step 530 , the identified bad memory blocks are marked as bad memory blocks in a block mapping table, and in step 530 , a plurality of reserved memory blocks for storing firmware are determined based on the block mapping table.

[0057] In one embodiment, in step 510 , a flag corresponding to a portion of storage blocks of a storage device is set by running a boot code.

[0058] In one embodiment, in step 510, a flag corresponding to a portion of the storage blocks of the storage device is set as a global parameter by running the boot code. For example, the boot code segment may include logic or a code segment for injecting an error flag, which is used to set the flag of a portion of the storage blocks of the storage device as an error block or a bad block.

[0059] In one embodiment, before step 520, a memory block detection code may be run to detect the memory blocks of the storage device to identify the real bad memory blocks of the storage device. In one example, the memory detection code may be run under the guidance or control of the boot code.

[0060] In one embodiment, the memory block detection code detects memory blocks whose flags are not set and identifies them as bad memory blocks or good memory blocks based on the detection, and identifies memory blocks whose flags are set as bad memory blocks.

[0061] In one embodiment, the memory block detection code is a code for performing an erase operation on a memory device, and is used to detect whether a memory block is a bad memory block or a good memory block based on a result of the erase operation on the memory block.

[0062] In one embodiment, in step 550, processing the test command by the firmware includes executing one or more of the following commands: a read or write command for the storage device; a command for updating or replacing the firmware; a command for searching for the first good storage block; a command for remapping and updating the mapping table; a command related to power-off recovery of the storage device; and a command for data error correction or reconstruction of the storage device.

[0063] In one embodiment, the distribution of the portion of storage blocks corresponding to the set flag is one of a plurality of different distributions. For example, the plurality of different distributions is obtained based on one or more of the following: randomly selecting the portion of storage blocks from the storage blocks of the storage device; making the portion of storage blocks include consecutive storage blocks; making the portion of storage blocks include a consecutive row of storage blocks.

[0064] In one embodiment, the storage device is a Universal Flash Storage (UFS) compliant storage device.

[0065] Those skilled in the art will understand that although the technical solution of the present disclosure is mainly described in conjunction with USF storage devices in the example embodiments of the present disclosure, the technical solution of the present disclosure can also be applied to other types of storage devices, such as embedded multimedia card (eMMC, Embedded Multi Media Card) type storage devices, and various solid state drive (SSD, Solid State Disk) type storage devices.

[0066] Figure 6 According to an embodiment of the present disclosure, a schematic block diagram of an apparatus 60 for testing firmware of a storage device is shown.

[0067] The device 60 includes: a flag setting module 6110, used to set a flag corresponding to a part of the storage blocks of the storage device; a detection module 620, used to detect whether the storage blocks of the storage device are good storage blocks or bad storage blocks, wherein the real bad storage blocks of the storage device detected by the detection module 620 and the part of the storage blocks corresponding to the flag are both identified as bad storage blocks; a reservation module 630, used to determine multiple reserved storage blocks for storing firmware based on the identified bad storage blocks; a firmware loading module 6130, used to load firmware into at least a part of the multiple reserved storage blocks; and a firmware module 640, used to process a test command through the firmware and return a processing result for the test command.

[0068] In one embodiment, the apparatus 60 further comprises a mapping table updating module 6120 for marking the identified bad storage blocks as bad storage blocks in the block mapping table. The reservation module 630 determines a plurality of reserved storage blocks for storing firmware based on the mapping table.

[0069] In one embodiment, Figure 6 As shown, the boot module 610 may include a flag setting module 6110, a mapping table updating module 6120, and a firmware loading module 6130. In another embodiment, see the above combined Figure 3 In the described example, the mapping table update module 6120 and the reservation module 630 may also be included in the firmware module 640 .

[0070] In one embodiment, the flag setting module 6110 sets a flag by setting a flag corresponding to a portion of storage blocks of the storage device as a global parameter.

[0071] In one embodiment, the detection module 620 identifies both the actual bad storage blocks of the detected storage device and a portion of storage blocks corresponding to the flag as bad storage blocks.

[0072] In one embodiment, the detection module 620 performs an erase operation on the storage device, and detects whether a storage block is a bad storage block or a good storage block based on a result of the erase operation on the storage block.

[0073] In one embodiment, the test commands processed by the firmware module 640 through the firmware 2320 include one or more of the following commands: a read or write command for the storage device; a command for updating or replacing the firmware 2320; a command for searching for the first good storage block; a command for remapping and updating the mapping table; a command related to power-off recovery of the storage device; and a command for data error correction or reconstruction of the storage device.

[0074] In one embodiment, the device 60 can be implemented as a software module, wherein the boot module 610, flag setting module 6110, mapping table update module 6120, firmware loading module 6130, detection module 620, reserved module 630, and firmware module 640 correspond to the above-mentioned boot code, flag setting code, mapping table update code, firmware loading code, detection code, reserved code, and firmware, respectively.

[0075] Figure 7 According to one embodiment of the present disclosure, a schematic flowchart of an apparatus 70 for testing firmware of a storage device is shown.

[0076] The apparatus 70 includes one or more processing units 710 and one or more storage units 720 . The storage unit 720 may store computer-executable instructions that, when executed, cause the one or more processing units to perform the methods described in the present disclosure.

[0077] In one embodiment, the device 70 may include Figure 1 As shown in the storage device 10, the processing unit 710 may include Figure 1 The processing unit 1120 shown, the storage unit 720 may include Figure 1 The storage unit 1130 shown may also include Figure 1 The read-only memory ROM and the memory array 120 are not shown.

[0078] In another embodiment, the processing unit 710 may further include Figure 2 The processing unit in the host, such as the UFS host 220, shown, the storage unit 720 may further include Figure 2 A storage unit in a host, such as UFS host 220, is shown.

[0079] In another embodiment, the processing unit 710 may further include Figure 2 The processing unit in the computer shown, such as the client computer 210, the storage unit 720 may further include Figure 2 A storage unit in a computer, such as client computer 210, is shown.

[0080] In one embodiment, the technical solution of the present disclosure may be implemented as a machine-readable storage medium storing executable instructions that, when executed, enable one or more processing units to execute the method described in the present disclosure.

[0081] In one embodiment, the technical solution of the present disclosure may be implemented as a computer program product, which includes executable instructions that, when executed, enable one or more processing units to perform the method described in the present disclosure.

[0082] The detailed description described above, in conjunction with the accompanying drawings, describes exemplary embodiments and is not intended to represent all possible embodiments that may be implemented or fall within the scope of the claims. The detailed description includes specific details to provide an understanding of the described techniques. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the described embodiments.

[0083] The foregoing description of the present disclosure is provided to enable any person skilled in the art to implement or use the present disclosure. Various modifications to the present disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but is intended to be consistent with the widest range of principles and novel features disclosed herein.

Claims

1. A method for testing firmware for a storage device, comprising: Setting a flag corresponding to a portion of storage blocks of the storage device; Identify both the detected real bad storage blocks of the storage device and the portion of storage blocks corresponding to the flag as bad storage blocks; determining a plurality of reserved memory blocks for storing the firmware based on the identified bad memory blocks; loading the firmware into at least a portion of the plurality of reserved memory blocks; as well as The firmware processes the test command and returns a processing result for the test command.

2. The method of claim 1, further comprising: Marking the identified bad memory block as a bad memory block in a block mapping table, The step of determining a plurality of reserved storage blocks for storing the firmware further comprises: determining the plurality of reserved storage blocks for storing the firmware based on the block mapping table.

3. The method according to claim 1, wherein The setting of a flag corresponding to the portion of storage blocks of the storage device includes: The flag corresponding to the portion of the storage blocks of the storage device is set as a global parameter by running the boot code.

4. The method of claim 1 , further comprising: A memory block detection code is run to detect memory blocks of the memory device to identify the actual bad memory blocks of the memory device.

5. The method according to claim 4, wherein: The memory block detection code detects memory blocks for which the flag is not set and identifies them as bad memory blocks or good memory blocks based on the detection, and identifies memory blocks for which the flag is set as bad memory blocks.

6. The method according to claim 5, wherein: The memory block detection code is a code for performing an erase operation on the memory device, and is used to detect whether a memory block is a bad memory block or a good memory block based on a result of the erase operation on the memory block.

7. The method of claim 1, wherein: Processing the test command by the firmware includes executing one or more of the following commands: a read or write command for the storage device; commands for updating or replacing the firmware; Commands for searching for the first good storage block; Commands for remapping and updating mapping tables; Commands related to power failure recovery of the storage device; A command for correcting or rebuilding data on the storage device.

8. The method of claim 1, wherein: The distribution of the portion of storage blocks corresponding to the set flag is one of a plurality of different distributions.

9. The method of claim 8, wherein: The multiple different distributions are based on one or more of the following: Randomly selecting the portion of storage blocks from the storage blocks of the storage device; causing the portion of memory blocks to include consecutive memory blocks; The portion of memory blocks includes a continuous row of memory blocks.

10. The method of claim 1, wherein: The storage device is a storage device compliant with Universal Flash Storage (UFS).

11. An apparatus for testing firmware for a storage device, comprising: a flag setting module, configured to set flags corresponding to a portion of storage blocks of the storage device; a detection module, configured to detect whether a storage block of the storage device is a good storage block or a bad storage block, wherein both the actual bad storage block of the storage device detected by the detection module and the portion of storage blocks corresponding to the flag are identified as bad storage blocks; a reservation module, configured to determine a plurality of reserved storage blocks for storing the firmware based on the identified bad storage blocks; a firmware loading module, configured to load the firmware into at least a portion of the plurality of reserved storage blocks; and The firmware module is used to process the test command through the firmware and return the processing result for the test command.

12. The apparatus of claim 11, further comprising: a mapping table updating module, configured to mark the identified bad storage block as a bad storage block in the block mapping table, The reservation module determines a plurality of reserved storage blocks for storing the firmware based on the mapping table.

13. The device according to claim 11, wherein The flag setting module sets the flag by setting the flag corresponding to the portion of storage blocks of the storage device as a global parameter.

14. The device according to claim 11, wherein The detection module is used to identify the detected real bad storage blocks of the storage device and the part of storage blocks corresponding to the flag as bad storage blocks.

15. The apparatus of claim 11, wherein: The detection module is used to perform an erase operation on the storage device, and detect whether a storage block is a bad storage block or a good storage block based on a result of the erase operation on the storage block.

16. The apparatus of claim 11, wherein: The test commands processed by the firmware module include one or more of the following commands: a read or write command for the storage device; commands for updating or replacing the firmware; Commands for searching for the first good storage block; Commands for remapping and updating mapping tables; Commands related to power failure recovery of the storage device; A command for correcting or rebuilding data on the storage device.

17. The apparatus of claim 11, wherein: The distribution of the portion of storage blocks corresponding to the flag is one of a plurality of different distributions.

18. An apparatus for testing firmware for a storage device, comprising: one or more processing units; as well as A storage unit storing instructions which, when executed by the one or more processing units, cause the one or more processing units to perform the method according to any one of claims 1 to 10.

19. A machine-readable storage medium storing executable instructions which, when executed, cause one or more processing units to perform the method of any one of claims 1 to 10.

20. A computer program product comprising executable instructions which, when executed, cause one or more processing units to perform the method of any one of claims 1 to 10.

Images