A universal flash storage (UFS) test method, a storage device, and a medium

Abstract

This application discloses a testing method, storage device, and medium for Universal Flash Memory (UFS). First, a main thread and a sub-thread are created in the UFS application layer, and a queue status mapping table corresponding to the slot queue in the UFS driver layer is configured. Then, the main thread asynchronously sends an operation request containing a structure carrying the target operation instruction to the driver layer according to the mapping table. Next, the sub-thread receives the response result returned by the driver layer. Subsequently, the time taken for the target operation instruction is determined based on the response result and the corresponding structure. Then, based on a preset time threshold and the time taken, the timeout result of the target operation instruction is obtained. This application manages the slots through a queue status mapping table and traces the entire lifecycle information of commands through structures. This enables full coverage of the number of tasks in the UFS command queue to verify asynchronous read / write functionality, effectively determine whether each asynchronous command has timed out, and reduce the difficulty of analyzing device firmware problems, thereby effectively solving existing testing deficiencies.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to, but are not limited to, the technical field of storage technology, and in particular to a universal flash memory (UFS) testing method, a storage device, and a medium. BACKGROUND

[0002] Universal flash memory storage (UFS) chips are widely used in mobile products such as mobile phones and tablets that run the Android system. The UFS chips support the command queue function, and the command queue depth is usually 32, that is, the host is allowed to issue a maximum of 32 asynchronous commands. In the actual testing of the UFS chip, the above-mentioned asynchronous command issuing function needs to be implemented to verify whether the UFS command queue works normally. At the same time, since the Android system sets a specified timeout time for the UFS read and write commands, if the read and write commands frequently timeout, it will cause the upper application to lag, and in severe cases, it will even cause the system to crash. Therefore, it is also necessary to accurately determine whether each command issued asynchronously has a timeout problem. At present, the industry mainly uses the way of purchasing a complete machine with a target UFS chip at the customer's place and performing system-level testing for the UFS testing, but this way has obvious defects:

[0003] 1. It is difficult to accurately cover the number of tasks in the UFS command queue, and it is difficult to comprehensively verify the asynchronous command processing capability under the command queue depth;

[0004] 2. If the command queue exception or command timeout problem is found in the test, the subsequent problem analysis is extremely difficult. Not only the logs printed by the host need to be analyzed, but also the UFS driver code needs to be checked. However, the customer usually does not provide the driver source code, which causes the problem positioning and solving to be hindered. SUMMARY

[0005] The following is a summary of the subject matter described in detail in this document. This summary is not intended to limit the scope of the claims.

[0006] Embodiments of the present application provide a universal flash memory (UFS) testing method, a storage device, and a medium, which can realize full coverage of the number of UFS command queue tasks to verify the asynchronous read and write function, effectively determine whether each asynchronous command has a timeout, and reduce the difficulty of analyzing the device firmware problem, thereby effectively solving the existing testing defects.

[0007] In one aspect, the embodiment of the present application provides a test method of a universal flash memory (UFS), including: creating a main thread and a sub-thread of a UFS application layer; configuring a queue state mapping table corresponding to a card slot queue of a UFS driver layer; sending, by the main thread, an operation request to the UFS driver layer asynchronously according to the queue state mapping table, the operation request containing a structure carrying a target operation instruction; receiving, by the sub-thread, a response result returned by the UFS driver layer; determining a time consumption of the target operation instruction according to the response result through a corresponding structure; and obtaining a timeout result of the target operation instruction according to a preset time threshold and the time consumption of the target operation instruction.

[0008] In one embodiment of the present application, the determining of the time consumption of the target operation instruction according to the response result through the corresponding structure includes: determining the structure corresponding to the response result; obtaining a sending time and a completion time of the target operation instruction from the structure, wherein the sending time is a time written when the UFS driver layer receives the target operation instruction, and the completion time is a time written when the UFS driver layer receives a response of a corresponding operation completed by a UFS device according to the target operation instruction; and calculating a difference between the completion time and the sending time to obtain the time consumption of the target operation instruction.

[0009] In one embodiment of the present application, the obtaining of the timeout result of the target operation instruction according to the preset time threshold and the time consumption of the target operation instruction includes: determining that the target operation instruction times out when the time consumption is greater than the time threshold; and determining that the target operation instruction does not time out when the time consumption is less than or equal to the time threshold.

[0010] In one embodiment of the present application, the sending of the operation request to the UFS driver layer by the main thread according to the queue state mapping table includes: querying, by the main thread, the queue state mapping table, and in response to the existence of an idle card slot of the card slot queue, associating, by the main thread, the structure carrying the target operation instruction with the idle card slot, and sending the corresponding operation request to the UFS driver layer.

[0011] In one embodiment of the present application, the sending of the operation request to the UFS driver layer by the main thread according to the queue state mapping table includes: querying, by the main thread, the queue state mapping table, and in response to the non-existence of an idle card slot of the card slot queue, querying, by the main thread, the queue state mapping table again after waiting for a preset time length, until an idle card slot is obtained and the operation request is sent.

[0012] In an embodiment of the present application, after the operation request corresponding to the UFS driving layer is sent, the method further comprises: updating the corresponding idle slot in the queue state mapping table to a busy state.

[0013] In an embodiment of the present application, the structure further comprises unique identification information, and the response result comprises the unique identification information; and the structure corresponding to the response result is determined according to the unique identification information in the response result.

[0014] In an embodiment of the present application, after the response result returned by the UFS driving layer is received, the method further comprises: updating the slot corresponding to the response result in the queue state mapping table to an idle state.

[0015] In another aspect, an embodiment of the present application provides a storage device, comprising: at least one processor; at least one memory for storing at least one program; and when the at least one program is executed by the at least one processor, a test method as described above is implemented.

[0016] In another aspect, an embodiment of the present application provides a computer readable storage medium, which stores computer executable instructions for executing a test method as described above.

[0017] The test method for a universal flash memory (UFS) provided by an embodiment of the present application first creates a main thread and a sub-thread of a UFS application layer, and configures a queue state mapping table corresponding to a slot queue of a UFS driving layer; then sends an operation request to the UFS driving layer asynchronously through the main thread according to the queue state mapping table, wherein the operation request comprises a structure carrying a target operation instruction; then receives a response result returned by the UFS driving layer through the sub-thread. Subsequently, the use time of the target operation instruction is determined through the corresponding structure according to the response result, and then a timeout result of the target operation instruction is obtained according to a preset time threshold and the use time of the target operation instruction. An embodiment of the present application manages the slots through the queue state mapping table, can fill the UFS command queue (such as 32 slots), realizes full coverage of the number of tasks to completely verify the asynchronous read-write function, records the command sending and completion time by means of the structure, accurately calculates the use time of a single command and compares it with the threshold to ensure that the timeout state of each command can be identified, and at the same time traces the command life cycle information through the structure, does not need to rely on the customer driving source code to quickly distinguish the problems of the host and the device, and reduces the difficulty of finding the device firmware problems. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 is a flowchart of a test method for a UFS provided by an embodiment of the present application;

[0019] Figure 2 is a whole architecture diagram of UFS provided by an embodiment of the present application;

[0020] Figure 3 is a UFS application layer architecture diagram provided by an embodiment of the present application;

[0021] Figure 4 is a process diagram of a main thread issuing a command provided by an embodiment of the present application; Figure 1 is a flow diagram of step 150 in the middle;

[0022] Figure 5 is a process diagram of a main thread issuing a command provided by an embodiment of the present application;

[0023] Figure 6 is a process diagram of a main thread issuing a command provided by an embodiment of the present application; DETAILED DESCRIPTION

[0024] In order to make the purpose, technical scheme and advantages of the present application clearer, the present application is further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not to limit the present application.

[0025] It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described in the flowchart can be performed in an order different from that in the flowchart. The terms "first", "second", etc. in the specification and claims and the above drawings are used to distinguish similar objects and do not necessarily describe a specific order or sequence. It should be understood that the structures, proportions, sizes, etc. shown in the drawings of the present specification are only used to illustrate the content disclosed in the specification, so as to be understood and read by those skilled in the art, and do not limit the conditions for implementing the present application, therefore, any modification, change of proportion relationship or adjustment of size, without affecting the effect and purpose of the present application, should still fall within the scope of the technical content disclosed by the present application. At the same time, the terms such as "up", "down", "left", "right", "middle" and "one" used in the specification are only for the convenience of clear description, and are not intended to limit the scope of the present application, and the change or adjustment of the relative relationship, without substantially changing the technical content, is also regarded as the scope of the present application.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0027] Universal Flash Storage (UFS) chips are widely used in mobile products such as mobile phones and tablets that run the Android system. UFS chips support the command queue function, and the command queue depth is usually 32, that is, the host can issue a maximum of 32 asynchronous commands. "Asynchronous" means that after the host issues command A, it does not need to wait for the UFS device to respond to command A before issuing command B.

[0028] In the actual testing of UFS chips, the above-mentioned asynchronous command issuing function needs to be implemented to verify whether the UFS command queue is working properly. At the same time, since the Android system has a specified timeout time for UFS read and write commands, if the read and write commands frequently timeout, it will cause the upper layer application to lag, and in severe cases, it will even cause the system to crash, so it is also necessary to accurately determine whether each command issued asynchronously has a timeout problem.

[0029] Currently, the industry mainly uses the method of purchasing a complete machine equipped with the target UFS chip at the customer's place and performing system-level testing for UFS testing, but this method has obvious defects:

[0030] 1. It is difficult to accurately cover the number of tasks in the UFS command queue, and it is difficult to fully verify the asynchronous command processing capability under the command queue depth (such as 32);

[0031] 2. If the command queue exception or command timeout problem is found in the test, the subsequent problem analysis is extremely difficult. Not only does it need to analyze the logs printed on the host side, but it also needs to troubleshoot in combination with the UFS driver code. However, customers usually do not provide the driver source code, which hinders problem positioning and solving.

[0032] In view of this, the embodiment of the present application provides a universal flash memory (UFS) test method, a storage device and a computer readable storage medium. In the method, first, a main thread and a sub-thread of a UFS application layer are created, and a queue state mapping table corresponding to a card slot queue of a UFS driver layer is configured; then, an operation request is asynchronously sent to the UFS driver layer by the main thread according to the queue state mapping table, wherein the operation request includes a structure carrying a target operation instruction; then, a response result returned by the UFS driver layer is received by the sub-thread. Subsequently, the time of the target operation instruction is determined according to the response result through the corresponding structure, and then a timeout result of the target operation instruction is obtained according to a preset time threshold and the time of the target operation instruction. The embodiment of the present application can fill the UFS command queue (such as 32 card slots) by managing the card slots through the queue state mapping table, realize full coverage of the number of tasks to completely verify the asynchronous read-write function, record the command sending and completion time by means of the structure, accurately calculate the time of a single command and compare it with the threshold value to ensure that the timeout state of each command can be identified, and at the same time, the structure is used to trace the whole life cycle information of the command, so that the problems of the host and the device can be quickly distinguished without relying on the customer driver source code, and the difficulty of finding the device firmware problem is reduced.

[0033] The embodiment of the present application will be further described below with reference to the accompanying drawings.

[0034] Reference Figure 1 , Figure 1 is a flowchart of the UFS test method provided by the embodiment of the present application. The flowchart can specifically include but is not limited to steps 110 to 160.

[0035] Step 110: creating a main thread and a sub-thread of a UFS application layer;

[0036] Step 120: configuring a queue state mapping table corresponding to a card slot queue of a UFS driver layer;

[0037] Step 130: asynchronously sending an operation request to the UFS driver layer by the main thread according to the queue state mapping table, wherein the operation request includes a structure carrying a target operation instruction;

[0038] Step 140: receiving a response result returned by the UFS driver layer by the sub-thread;

[0039] Step 150: determining the time of the target operation instruction according to the response result through the corresponding structure;

[0040] Step 160: obtaining a timeout result of the target operation instruction according to a preset time threshold and the time of the target operation instruction.

[0041] The steps 110 to 160 will be described in detail below.

[0042] Understandably, the UFS application layer (also known as the UFS use case layer) is the upper-level software module in the UFS storage system responsible for initiating test requirements, issuing operation commands, and processing feedback results. It primarily performs functional and performance tests on UFS devices by writing test cases, such as initiating read and write commands and verifying command execution results. Figure 2 As shown, the testing method for this general-purpose UFS flash memory can be implemented based on the Linux system. Its overall architecture, from top to bottom, includes the UFS application layer (i.e., the UFS use case layer), the UFS kernel layer (also known as the UFS driver layer, which is a self-developed UFS driver), and the UFS hardware layer (i.e., the actual UFS hardware device, such as the UFS flash memory chip and its matching controller). The core functional division of each layer is as follows: The UFS use case layer, serving as the execution entry point for test requirements, is primarily responsible for issuing SCSI commands (standardized storage operation instructions, such as reading data, writing data, and querying device information) to the UFS driver layer. It also receives and processes the response results (resp, i.e., the execution result of the UFS device on the SCSI command, such as success, failure, and error reason) from the driver layer. The UFS driver layer, acting as the intermediary connecting the application layer and the hardware layer, can encapsulate operation requests from the application layer into UPIU packets (UFS Protocol Information Units, the standard format for data and instruction transmission in the UFS system, containing commands, data, and responses) and send them to the UFS hardware device. Furthermore, it can receive the response results (resp) returned by the UFS hardware device and forward them to the UFS application layer, achieving efficient communication between the upper and lower layers.

[0043] In a feasible embodiment, in step 110, to achieve asynchronous SCSI command issuance while ensuring high performance in command issuance and timely processing of device response (resp), this embodiment employs a dual-thread design at the UFS application layer (e.g., Figure 3 As shown in the diagram, a main thread and a child thread are created. The main thread focuses on sending SCSI commands to the driver layer, handling command scheduling and distribution. The child thread is dedicated to listening for and receiving the response results (resp) returned by the UFS device through the driver layer, and parsing and processing the responses. This clearly defined dual-thread architecture avoids the mutual blocking between "sending commands" and "processing responses" that can occur in a single thread. Specifically, the main thread can continuously send new commands without waiting for the response to the previous command, effectively improving the efficiency of asynchronous command delivery; simultaneously, the child thread is on standby to process responses in real time, ensuring that the response returned by the device can be captured and processed promptly.

[0044] In a feasible embodiment, in step 120, the UFS application layer can configure a queue state mapping table, which forms a one-to-one correspondence with the card slot queue of the UFS drive layer. The card slot queue of the drive layer is a hardware resource queue for temporarily storing commands to be issued (usually containing 32 independent card slots, and each card slot can carry one SCSI command), and the queue state mapping table of the application layer is a logical mirror record of the real-time state of the card slot of the drive layer. In other words, the mapping table can synchronously record the current state of each card slot of the drive layer (whether it is "idle" to receive a new command or "busy" to process an issued command), such as the table can explicitly mark "card slot 1: idle" and "card slot 2: busy" and other information, so that the UFS application layer can master the availability of each card slot in real time without frequent interaction with the drive layer, and provide a state basis for the subsequent main thread to efficiently issue asynchronous commands.

[0045] In a feasible embodiment, in step 130, the main thread can send an operation request to the UFS drive layer asynchronously according to the real-time information of the queue state mapping table. Asynchronous sending means that after the main thread sends an operation request, it does not need to wait for the response result of the request to return, and can continue to send the next request, so as to improve the efficiency of command issuing. Each operation request contains a structure body carrying a target operation instruction, and in this embodiment, a structure body named "struct ats_ufs_upiu" is used to specifically represent an independent SCSI request. The structure definition is as follows:

[0046] struct ats_ufs_upiu {

[0047] unsigned long send_time; / * Sending time * /

[0048] unsigned long complete_time; / * Completion time * /

[0049] struct ufs_upiu upiu; / * Encapsulate SCSI command UPIU package: according to the UFS protocol, all SCSI requests must be packaged in UPIU format to be transmitted * /

[0050] };

[0051] The design of this structure realizes complete recording of the full life cycle of SCSI requests. Specifically, the "structufs_upiu upiu" field is the core data area, encapsulates SCSI commands such as reading and writing into the standard UPIU (UFS protocol information unit) format according to the requirements of the UFS protocol, and ensures that the commands can be correctly identified by the UFS device; "send_time" and "complete_time" are two timestamp fields, which are automatically filled in by the driver layer when the request is received and when the device execution result is received, respectively, for subsequent calculation of the command execution time; in addition, the structure can also be extended to include unique identification information (such as command number), so that each request can be accurately distinguished, providing a basis for subsequent response result matching, timeout judgment (through timestamp calculation), and problem tracing (through unique identification association with full-process data).

[0052] In a feasible embodiment, the process of the main thread asynchronously sending operation requests to the UFS driver layer can be implemented based on the queue state mapping table. Step 130 asynchronously sends operation requests to the UFS driver layer by the main thread according to the queue state mapping table, including the following steps: the main thread queries the queue state mapping table, in response to the existence of a free slot in the slot queue, the main thread associates the structure carrying the target operation instruction with the free slot, and sends the corresponding operation request to the UFS driver layer. Specifically, first, the main thread can actively query the queue state mapping table (which records the state of each slot in the UFS driver layer slot queue in real time, such as "free" or "busy"). When it is found that there is a free slot in the slot queue (i.e., there is a slot resource available for receiving new commands), the main thread can associate the structure carrying the target operation instruction with the free slot, which is equivalent to allocating a dedicated hardware processing channel for the current operation request to be sent, ensuring that the command can be accurately identified and processed after being issued. After the association is completed, the main thread can send the corresponding operation request to the UFS driver layer. Since the asynchronous sending mechanism is adopted, the main thread does not need to wait for the response result of the operation request to return, and can continue to query the queue state mapping table, allocate a new free slot for the next operation request and send it, so as to realize efficient and continuous issuance of multiple commands.

[0053] In a feasible embodiment, the step 130 sends the operation request to the UFS driver layer asynchronously according to the queue state mapping table by the main thread, and further includes the following steps: querying the queue state mapping table by the main thread, in response to the fact that there is no idle card slot in the card slot queue, making the main thread wait for a preset time length and then querying the queue state mapping table again, and until an idle card slot is obtained and the operation request is sent. Specifically, when the main thread queries the queue state mapping table, if it is found that there is no idle card slot in the card slot queue (i.e., all card slots are in the "busy" state and are processing the previously issued command), the main thread will not be terminated or an error will not be reported immediately, but will enter a waiting state according to a preset waiting time (for example, 50 milliseconds, which can be adjusted according to actual test requirements). After the waiting time is over, the main thread can query the queue state mapping table again to check whether a card slot has been converted from "busy" to "idle" (i.e., the previous command has been processed and the card slot resource has been released). If there is still no idle card slot, the main thread can repeat the "waiting-querying" process until at least one idle card slot is detected, and then immediately associate the new operation request with the idle card slot and send it. This mechanism ensures that the main thread can dynamically adjust the command issuing rhythm according to the actual availability of the card slot, so that the command issuing process will not be interrupted due to the full occupation of the card slot, and the system resources will not be wasted due to excessive frequent queries, thereby efficiently utilizing the command queue depth (such as 32 card slots) of the UFS and realizing the continuous asynchronous issuing of commands.

[0054] In a feasible embodiment, after the main thread asynchronously issues the operation request in step 140, a sub-thread of the UFS application layer can be specially responsible for receiving the response result returned by the UFS driver layer (such as the execution result fed back by the driver layer to the upper layer after the UFS hardware device executes the corresponding SCSI command, such as command execution success, failure and specific failure reason, etc.). The sub-thread can continuously monitor the response channel of the UFS driver layer, and once the driver layer receives the response returned by the UFS hardware device, the response can be forwarded to the sub-thread.

[0055] In a feasible embodiment, step 150 determines the execution process of the time used by the target operation instruction according to the response result through the corresponding structure, as shown in Figure 4 The process can include but is not limited to steps 410 to 430.

[0056] Step 410: determining the structure corresponding to the response result;

[0057] Step 420: obtaining the sending time and completion time of the target operation instruction from the structure, wherein the sending time is the time written by the UFS driver layer when the target operation instruction is received, and the completion time is the time written by the UFS driver layer when the response of the UFS device according to the target operation instruction is completed;

[0058] Step 430: Calculate the difference between the completion time and the sending time to obtain the time consumption of the target operation instruction.

[0059] In a feasible embodiment, in step 410, the association between the response result (i.e. the feedback of the UFS device to the execution of the operation instruction) and the structure (the carrier recording the operation instruction information) can be established through unique identification information. Specifically, the structure can pre-include a unique identification (such as a specific number or character string), and the response result returned by the driver layer also carries the same identification. Therefore, after receiving the response result, the sub-thread will extract the unique identification information therefrom, and then match the identification in all issued structures to finally find the structure corresponding to the response result. For example, if the identification of the response result is "001", the structure with the identification "001" will be matched.

[0060] In a feasible embodiment, in step 420, after the corresponding structure is found, two key times, the sending time and the completion time of the target operation instruction, can be read from the structure. Specifically, when the UFS driver layer receives the target operation instruction issued by the application layer, the time when the instruction is received can be automatically recorded in the structure, which is the sending time (representing the time when the transmission of the instruction from the application layer to the driver layer is completed); when the UFS driver layer receives the response returned by the UFS hardware device after the execution of the instruction, the time when the response is received can be recorded in the structure, which is the completion time (representing the time when the device executes the instruction and returns the result).

[0061] In a feasible embodiment, in step 430, the difference between the completion time and the sending time in the structure is the total time consumption of the target operation instruction from the reception of the instruction by the driver layer to the completion of the execution by the device and the return of the response (for example, the sending time is 10:00:00, and the completion time is 10:00:05, so the time consumption is 5 seconds).

[0062] In a feasible embodiment, in the process of judging whether the instruction is timed out according to the preset time threshold and the time consumption of the target operation instruction, the specific rules are as follows: first, a time threshold (i.e. the maximum time allowed for the normal completion of the operation instruction, for example, 100 milliseconds, which is considered as the execution delay if exceeded) is pre-set; then, the actual time consumption of the target operation instruction calculated in step 430 is compared with the preset time threshold, if the actual time consumption is greater than the time threshold, it is determined that the target operation instruction is timed out; if the actual time consumption is less than or equal to the time threshold, it is determined that the target operation instruction is not timed out.

[0063] In a feasible embodiment, after the main thread sends the corresponding operation request to the UFS driver layer, the queue state mapping table also needs to be updated synchronously, i.e., the state of the idle card slot associated with the operation request in the mapping table is marked from "idle" to "busy". The purpose of this update operation is to reflect the actual use of the card slot in the driver layer in real time. Since the card slot has been occupied by the current operation request (waiting for the UFS device to process the command), the mapping table changes the state to explicitly indicate to the main thread that the card slot is temporarily unavailable for new command issuance. This real-time synchronization mechanism can ensure that the card slot state obtained by the main thread when querying the mapping table is always consistent with the actual situation, avoiding the problem of repeated command issuance or card slot resource conflict caused by asynchronous information.

[0064] In a feasible embodiment, after receiving the response result returned by the UFS driver layer, the method further comprises: updating the card slot corresponding to the response result in the queue state mapping table to an idle state. Specifically, after the sub-thread receives the response result returned by the UFS driver layer (i.e., the UFS device has completed the corresponding operation and fed back the result), a key operation needs to be performed: updating the state of the card slot corresponding to the response result from "busy" to "idle" in the queue state mapping table. Updating the state of the corresponding card slot to "idle" means that the card slot has completed the processing of the previous operation request and released the resource, which can be used to receive new operation requests again. This update step ensures that the queue state mapping table can reflect the actual availability of the card slot in the driver layer in real time and accurately, providing a reliable state basis for the main thread to query and issue new operation requests subsequently, avoiding the problem of resource waste or issuance block caused by the state of the card slot not being updated in time.

[0065] Referring to Figure 5 , Figure 5is a process diagram of a main thread issuing a command provided by an embodiment of the present application. The specific process is as follows: in the UFS driver layer, there is a queue containing 32 card slots (numbered 0-31), and each card slot can independently carry a command request. When the main thread of the application layer needs to issue an operation request (such as initiating SCSI read command R0, R1), it will first assemble the request into ufs upiu (that is, according to the UFS protocol, encapsulate the SCSI command into “struct ufs_upiu” format), and then hand it over to the driver layer for processing. The logic of the driver layer for issuing commands is: the main thread checks the card slot queue state, and if there is a free card slot (not occupied by other commands), it selects the card slot, on the one hand, sets “send_time” in “struct ufs_upiu” to the current timestamp (records the command sending time), and on the other hand, marks the card slot as “busy” (the red filled card slot in the figure represents the busy state), and then starts the hardware transmission process to send the encapsulated command request to the UFS device (device end). If all 32 card slots in the queue are in the busy state (no free card slot), the main thread will not terminate, but will wait according to the preset mechanism (such as retrying after a short delay), until a card slot becomes free due to the completion of the command and the release of resources, and then repeat the above process of “occupying card slot → recording sending time → marking busy → issuing command”. This process takes advantage of the UFS32 deep queue capability, so that the main thread does not need to wait for the previous command to be executed, and can continuously issue new commands according to the free state of the card slot (such as first issuing R0 to occupy card slot 0, and then issuing R1 to occupy card slot 1), realizing continuous asynchronous transmission of commands and improving data interaction efficiency.

[0066] Referring to Figure 6 , Figure 6The processing flow of returning a response result (resp) of a UFS device (device end) in the embodiment of the application is shown, mainly from device response triggering, to driving layer, application layer sub-thread processing in turn, and solving the command timeout misjudgment problem through a timestamp mechanism. Specifically, when the UFS device completes command execution and returns resp, a kernel interrupt is triggered. The driving layer performs key operations in the interrupt function: on the one hand, the current system timestamp is recorded to the "complete_time" field of the "struct ats_ufs_upiu" structure, marking the time when the command completes response; on the other hand, the card slot corresponding to the resp is "emptied", that is, the card slot state is restored from "busy" to "idle", and resources are released for new commands. After interrupt processing is completed, the sub-thread of the application layer obtains the resp returned by the device, and then carries out the following work: extracting command execution result and other information from "struct ufs_upiu", calculating the actual time consumption of the SCSI command from sending to response by using "complete_time" and "send_time" (the timestamp recorded when the command is sent), and comparing the actual time consumption with a preset timeout threshold (such as 5 seconds) to determine whether a single command is timed out. It is worth noting that if a simple logic is used, that is, the sub-thread receives the resp within 5 seconds to determine that it is not timed out, a loophole will appear. For example, the main thread asynchronously sends 100 commands (numbered 0-99), and if the command numbered 0 returns after 6 seconds (has timed out), but other commands respond normally within 5 seconds, the sub-thread will misjudge that all commands are not timed out due to receiving all resps, resulting in the timeout problem of the command numbered 0 being missed. To avoid this situation, the embodiment realizes accurate single command timeout detection by means of the "struct ats_ufs_upiu" structure, specifically: when sending a command, the driving layer records "send_time" to mark the timestamp of the time when the command is sent; when receiving resp, the interrupt function is triggered to record "complete_time" to mark the timestamp of the time when the command completes response, and when processing, the sub-thread calculates the time consumption of a single command by "complete_time-send_time", and compares it with the threshold to determine the timeout situation. This design binds an independent timestamp for each command, and can accurately detect the actual time consumption of a single command even if the command response order is chaotic (like the command numbered 0 responding last), avoiding the problem of "command starvation but cannot be detected", and ensuring accurate timeout judgment. It should be noted that the interrupt function is a "trigger" for the kernel to perceive device response, and it is actively triggered when the device returns resp, and the driving layer records the completion time and releases the card slot in time by means of this, which is the core mechanism of asynchronous response processing.

[0067] The embodiment of the present application further discloses a storage device, wherein the storage device comprises a processor, a memory, and a computer program stored in the memory and executable by the processor, and when the computer program is executed by the processor, the test method of the general flash memory UFS is realized.

[0068] The embodiment of the present application further discloses a computer readable storage medium, wherein a processor executable program is stored, and the processor executable program is used for executing the test method of the general flash memory UFS when executed by the processor.

[0069] The above description of disclosed embodiments enables those skilled in the art to carry out or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A test method for universal flash memory (UFS), characterized in that, include: Create the main thread and child threads for the UFS application layer; Configure a queue status mapping table corresponding to the card slot queues in the UFS driver layer; The main thread asynchronously sends an operation request to the UFS driver layer according to the queue state mapping table. The operation request contains a structure carrying the target operation instruction. The sub-thread receives the response returned by the UFS driver layer; Based on the response result, the timing of the target operation instruction is determined through the corresponding structure; Based on the preset time threshold and the duration of the target operation instruction, the timeout result of the target operation instruction is obtained; The step of asynchronously sending operation requests to the UFS driver layer via the main thread based on the queue state mapping table includes: The main thread queries the queue status mapping table. In response to the existence of an empty slot in the slot queue, the main thread associates the structure carrying the target operation instruction with the empty slot and sends the corresponding operation request to the UFS driver layer. The main thread queries the queue status mapping table. If there is no free card slot in the card slot queue, the main thread waits for a preset time and then queries the queue status mapping table again until a free card slot is found and the operation request is sent. After sending the corresponding operation request to the UFS driver layer, the method further includes: updating the corresponding idle slot in the queue status mapping table to a busy state.

2. The test method according to claim 1, characterized in that, The step of determining the time required to execute the target operation instruction based on the response result and the corresponding structure includes: Determine the structure corresponding to the response result; The sending time and completion time of the target operation instruction are obtained from the structure, wherein the sending time is the time when the UFS driver layer receives the target operation instruction and writes it, and the completion time is the time when the UFS driver layer receives the response from the UFS device to complete the corresponding operation according to the target operation instruction and writes it. The time taken to obtain the target operation instruction is obtained by calculating the difference between the completion time and the sending time.

3. The test method according to claim 1, characterized in that, The step of obtaining the timeout result of the target operation instruction based on a preset time threshold and the duration of the target operation instruction includes: If the time taken exceeds the time threshold, the target operation instruction is determined to have timed out. If the time taken is less than or equal to the time threshold, it is determined that the target operation instruction has not timed out.

4. The test method according to claim 2, characterized in that, The structure also includes unique identification information, and the response result contains the unique identification information; The determination of the structure corresponding to the response result specifically involves: determining the corresponding structure based on the unique identifier information in the response result.

5. The test method according to claim 1, characterized in that, After receiving the response result returned by the UFS driver layer, the method further includes: Update the slot in the queue status mapping table corresponding to the response result to an idle state.

6. A storage device, characterized in that, include: At least one processor; At least one memory for storing at least one program; The test method of any one of claims 1 to 5 is implemented when at least one of the programs is executed by at least one of the processors.

7. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to execute the test method according to any one of claims 1 to 5.

Images