Compatibility verification method and system of memory, terminal equipment and storage medium

Abstract

The invention belongs to the technical field of electronic product testing, and discloses a compatibility verification method and system of a memory, terminal equipment and a storage medium, and the method comprises the following steps: in a current test period, after sleep wake-up and first reset test are carried out on a target memory, judging a returned system attribute value, judging whether the first reset test is successful or not; if it is judged that resetting succeeds, read-write testing and erasing operation are carried out on the reset target memory; performing an IOzone test on the erased target memory, and ending the current test period; the test operation in the current test period is repeated until the test duration is met, and the target memory passing the IOzone test is obtained; and performing verification operation on the target memory passing the IOzone test to complete a compatibility test on the target memory, thereby improving the compatibility and stability of the chip test platform.

Description

Technical Field

[0001] The present application relates to the field of electronic product testing, and more specifically, to a method, system, terminal device, and storage medium for verifying the compatibility of a memory. Background Art

[0002] In the existing EMMC (EMMC: Embedded MultiMedia Card, Chinese name: Embedded Multimedia Card) and UFS (UFS: Universal Flash Storage, Chinese name: Universal Flash Storage, using serial data transmission technology) tests, the storage chip is generally used as the system disk to test the working stability on the Android platform. Among them, the embedded multimedia card is an embedded storage device that integrates a NAND Flash (non-volatile storage technology) storage chip and a control chip.

[0003] Since the functions tested on one platform are limited within a short period of time and the types of platforms covered are not comprehensive, there may be problems of incompatibility and low test efficiency. Summary of the Invention

[0004] In view of this, the purpose of the present application is to provide a method, system, terminal device, and storage medium for verifying the compatibility of a memory, aiming to solve the problems of poor stability test effect and low compatibility of the test platform for the storage chip in the existing technology.

[0005] To achieve the above purpose, the technical solutions adopted in the embodiments of the present application are as follows:

[0006] In a first aspect, an embodiment of the present application provides a method for verifying the compatibility of a memory, including:

[0007] During the current test cycle, after performing a sleep wake-up and a first reset test on the target memory, judge the returned system attribute value to determine whether the first reset test is successful;

[0008] If it is judged that the reset is successful, perform a read-write test and an erase operation on the reset target memory;

[0009] Perform an IOzone test on the erased target memory to end the current test cycle;

[0010] Repeat the test operations in the current test cycle until the test duration is met to obtain a target memory that passes the IOzone test;

[0011] Perform a verification operation on the target memory that passes the IOzone test to complete the compatibility test of the target memory.

[0012] In some embodiments, before performing the sleep wake-up and the first reset test on the target memory during the current test cycle, it further includes:

[0013] Obtain and run the mirror system file in the target memory to establish communication with the target memory;

[0014] Use the instruction to view the current device to check whether the communication with the target memory is successful.

[0015] In some embodiments, the IOzone test on the erased target memory includes:

[0016] Erase all data blocks in the erased target memory for a first preset number of times, and use the error correction code to check data integrity to check whether the second reset test is successful;

[0017] The IOzone test on the erased target memory includes:

[0018] Use the target memory after passing the second reset test to read and write several data blocks of preset sizes respectively to detect the read and write speeds.

[0019] In some embodiments, the verification operation on the target memory that has passed the IOzone test includes:

[0020] Verify the data blocks in the target memory after the IOzone test to screen out bad blocks;

[0021] Compare the output data of the target memory after the IOzone test with the expected data to check for error codes in the output data.

[0022] In some embodiments, the read and write test and the erase operation on the reset target memory include:

[0023] Perform read and write operations on the reset target memory according to a preset access mode and a preset number of data blocks to test and obtain the response time and voltage change conditions;

[0024] According to the preset erase parameters, after marking the data blocks in the target memory after the read and write test as target data blocks, erase the target data blocks to release storage space.

[0025] In some embodiments, after performing the sleep wake-up and the first reset test on the target memory during the current test cycle, judge the returned system attribute value to judge whether the first reset test is successful, including:

[0026] After performing the wake-up operation on the target memory for a second preset number of times within the current test cycle, perform a restart test on the target memory for a third preset number of times;

[0027] If it is determined that the returned system attribute value is a preset value, it is determined that the restart test is successful.

[0028] In some embodiments, the using the instruction to view the current device to view whether communication with the target memory is successful includes:

[0029] Execute the instruction to view the current device, and determine whether communication with the target memory is successful according to the returned execution result.

[0030] In a second aspect, an embodiment of the present application provides a compatibility verification system for a memory, including:

[0031] A test judgment module, configured to, within the current test cycle, after performing a sleep wake-up and a first reset test on the target memory, judge the returned system attribute value to judge whether the first reset test is successful;

[0032] A read / write and erase module, configured to, if it is judged that the reset is successful, perform a read / write test and an erase operation on the reset target memory;

[0033] An IOzone test module, configured to perform an IOzone test on the erased target memory to end the current test cycle;

[0034] A repetition module, configured to repeat the test operations within the current test cycle until a preset duration is satisfied, to obtain a target memory that passes the IOzone test;

[0035] A verification module, configured to perform a verification operation on the target memory that passes the IOzone test to complete the compatibility test of the target memory.

[0036] In a third aspect, an embodiment of the present application provides a terminal device, including a processor and a memory, where the memory stores machine-executable instructions that can be executed by the processor, and the processor can execute the machine-executable instructions to implement the above-mentioned compatibility verification method for the memory.

[0037] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the above-mentioned compatibility verification method for the memory is implemented.

[0038] The compatibility verification method, system, terminal device and storage medium of the memory provided by this application. The method realizes the compatibility and stability tests of the memory by repeatedly judging the system attribute value, successfully performing the first reset test on the target memory, and sequentially performing read and write tests, erase operations, and IOzone tests until a preset duration is reached, so as to improve the test accuracy and effect and improve the system compatibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions of the embodiments of this application, the following will briefly introduce the drawings required in the embodiments. It should be understood that the following drawings only show some embodiments of this application, so they should not be regarded as limiting the scope. For those of ordinary skill in the art, without creative efforts, other related drawings can also be obtained based on these drawings.

[0040] Figure 1 It is a flowchart of the wake-up operation in the compatibility verification method of the memory provided by this application;

[0041] Figure 2 It is a flowchart of the compatibility verification method of the memory provided by this application;

[0042] Figure 3 It is a schematic diagram for judging whether the first reset test is successful in the compatibility verification method of the memory provided by this application;

[0043] Figure 4 It is a schematic diagram of the read and write test and erase operation in the compatibility verification method of the memory provided by this application;

[0044] Figure 5 It is a flowchart of the second reset test and IOzone test in the compatibility verification method of the memory provided by this application;

[0045] Figure 6 It is a schematic diagram of the test process of the compatibility verification method of the memory provided by this application;

[0046] Figure 7 It is a schematic structural diagram of the compatibility verification system of the memory provided by this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0047] The following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. Usually, the components of the embodiments of this application described and shown in the drawings here can be arranged and designed in various different configurations.

[0048] Accordingly, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed present application, but merely represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative efforts fall within the scope of protection of the present application.

[0049] It should be noted that relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprising", "including" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising one..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.

[0050] Please refer to Figure 1 , a method for verifying the compatibility of a memory in an embodiment of the present application, including steps S80 - S90:

[0051] S80. Obtain and run the mirror system file in the target memory to establish communication with the target memory;

[0052] S90. Use the instruction to view the current device to check whether the communication with the target memory is successful.

[0053] Exemplarily, before performing the compatibility verification of the memory, it is necessary to first select a test platform according to requirements, and select according to the core architecture, frequency, application field and performance characteristics of different platforms. For example, the RK3568 platform is more inclined to industrial and embedded applications, while the MTK6833 is more inclined to consumer electronic products such as tablet computers.

[0054] Then, put the EMMC chip into the test platform, and flash the mirror system into the EMMC chip in the test platform through a USB cable to run the mirror system file for flashing, that is, the test platform is connected to the computer through a USB cable, and the compatibility test script is run on the computer. After the script recognizes the test platform device, it will push the test script to the test platform to test the EMMC chip. Because only when the flashing is successful can the test platform be powered on normally and the communication with the target memory be successfully established.

[0055] Secondly, use the current device viewing instruction to confirm whether the EMMC chip is correctly connected to the computer, that is, according to the adb devices command (i.e., the current device viewing instruction) entered in the computer, check whether the communication with the target memory is successful.

[0056] For example, in one embodiment, step S90, using the current device viewing instruction to check whether the communication with the target memory is successful, includes:

[0057] Execute the current device viewing instruction and judge whether the communication with the target memory is successful according to the returned execution result.

[0058] Exemplarily, after establishing the communication with the target memory, check whether the communication is successful:

[0059] Use the adb devices command in the cmd (Command Prompt) window on the computer. If the connection is correct, the first line will be returned: List of devices attached, and starting from the second line, each line of the device will display two fields: device ID and device name (default device), and one line represents one device.

[0060] If the connection is incorrect, only the line List of devices attached will be displayed. If the connection error is displayed, first ensure that the device is correctly connected to the computer via USB, and check that the device has enabled the USB debugging mode (click on the "Build number" in "About phone" in "Settings" multiple times to enable the "USB debugging" mode in the "Developer options"); if the device is correctly connected but adb still cannot detect it, it may be because the ADB driver is not correctly installed. On the computer, you can update or install the driver through the "Device Manager". If both of the above two steps are ensured to be correct and ADB still cannot recognize it, you can use netstat -ano|findstr:5037|| (port 5037 is the default port number used by ADB) to check whether there is any other process occupying the ADB port. If there is another process occupying it, use taskkill / F / PID [process ID] to close the process occupying the port. If none of the above methods can solve the problem, it may be that there is a problem with the device itself and manual device maintenance is required.

[0061] Please refer to Figure 2 , after step S90, using the current device viewing instruction to check whether the communication with the target memory is successful, steps S100 - S500 are further included:

[0062] S100, within the current test cycle, after performing the sleep wake-up and the first reset test on the target memory, judge the returned system attribute value to determine whether the first reset test is successful.

[0063] Exemplarily, after multiple wake-up operations are completed, in order to test compatibility issues caused by different reboot timeout times on different platforms, and after consecutive sleep_awake operations, problems such as system instability, inconsistent hardware states, and accumulation of software errors may occur. After the target memory is hibernated and awakened, the first reset test, that is, the reboot operation, can be performed to eliminate the influence of any possible caches and temporary files existing in the system.

[0064] Then, it is determined whether the system has started completely. This can be done by adding a judgment on the value of the sys.boot_completed attribute, that is, judging the returned system attribute value to determine whether the first reset test is successful.

[0065] Among them, sys.boot_completed is an Android system attribute value indicating whether the system has completed startup. When an Android device starts up, the system sets a value for this attribute, and this attribute is at the native layer of the Android system.

[0066] It can be understood that in this application, by providing a good error judgment and handling mechanism, that is, judging the system attribute value to determine whether the first reset test is successful, the test status can be checked in a timely manner to prevent the system from getting stuck after entering the recovery mode due to errors.

[0067] Please refer to Figure 3 , for example, in one embodiment, in step S100, after the target memory is hibernated and awakened and the first reset test is performed during the current test cycle, the returned system attribute value is judged to determine whether the first reset test is successful, including:

[0068] S110: After performing the wake-up operation on the target memory for the second preset number of times during the current test cycle, perform the reboot test on the target memory for the third preset number of times;

[0069] S120: If it is judged that the returned system attribute value is the preset value, it is judged that the reboot test is successful.

[0070] Exemplarily, the process of the first reset test is as follows:

[0071] After successful communication, the test starts. To ensure that the system does not crash or have errors due to frequent state switches, during the current test cycle, the target memory needs to be awakened first:

[0072] By performing consecutive sleep_awake operations for a second preset number of times, for example, setting the number of test loops to more than 100 rounds, it is possible to check whether the power management and wake-up functions of the system are normal, thereby exposing that there will be no memory leaks or resource conflicts when the memory management wakes up.

[0073] Among them, in the programming of sleep_awake, it is necessary to set the number of sleep_awake operations, that is, the number of test loops, which is also the second preset number.

[0074] Then, after performing the wake-up operation on the target memory, it is also necessary to perform a reboot test on the target memory for a third preset number of times (which can be the same as the second preset number, for example, 100 times). Among them, the average duration of each reboot is 60s. By frequently and continuously performing reboots, it is possible to test whether the storage and processor resources can be correctly managed during frequent power-on and power-off.

[0075] Among them, in the programming of the reboot test, it is necessary to set the number of reboots, that is, set the third preset number, for example, 100, and the duration of a single reboot, for example, 60s.

[0076] However, if a stuck phenomenon occurs during the test, such as a stuck logo, but the script does not judge the Reboot state. At this time, the script can still identify the device through the adb devices command and continue to issue commands, so it is easy to cause the system to enter the recovery mode during Reboot and the system will eventually freeze.

[0077] Therefore, it is possible to add a system property value (sys.boot_completed) to judge whether the reboot test is successful:

[0078] Execute the script for the reboot test on the computer. When the system property value is the preset value (for example, "1"), it means that the Reboot starts normally. If it is other values, it means that there is an error in Reboot. The script will stop the test and record the test failure. Then, if the reboot fails, the problem can be located according to the error message. If the device cannot be recognized midway, reconnect and perform the test. If it is a chip problem, it is necessary to view the chip and platform logs to locate the problem. It is possible to view the chip logs and platform logs and manually try to reboot. If the reboot fails, further development and analysis are required to solve the problem.

[0079] S200. If it is determined that the reset is successful, perform a read / write test and an erase operation on the reset target memory.

[0080] Demonstratively, when judging whether the first reset test is successful according to the system property value, if the system property value is the preset value, it is determined that the reset is successful.

[0081] After that, to test the multi-tasking environment of the EMMC chip during actual use, different platforms may have compatibility issues due to different response times and voltages during multi-tasking processing. Perform read and write tests on multiple data blocks of the reset target memory. This can not only verify the basic read and write functions but also construct a scenario where the data blocks are unevenly distributed, with invalid data scattered across the storage blocks, preparing for verifying the Discard function later.

[0082] Moreover, the unused storage space may become fragmented after the read and write tests. To inform the storage device which data blocks are no longer needed, perform an erase operation on specific data blocks. In this way, the device will pre-erase these blocks in the background, thereby reducing unnecessary erase cycles, accelerating future write operations, and also improving the subsequent IOzone performance test results.

[0083] Please refer to Figure 4 , for example, in one embodiment, performing read and write tests and erase operations on the reset target memory includes:

[0084] S201. Perform read and write operations on the reset target memory according to a preset access mode and a preset number of data blocks to test the response time and voltage changes.

[0085] S202. After marking the data blocks in the target memory after the read and write tests as target data blocks according to preset erase parameters, erase the target data blocks to release the storage space.

[0086] Among them, the target data blocks are blocks that do not contain valid data.

[0087] Exemplarily, after determining that the reset is successful, to test the response time and voltage changes for testing different data blocks, multiple reads and writes can be executed simultaneously for stress testing. Set data blocks of different sizes (such as 4KB, 512KB, and 1MB, etc.) and different access modes (sequential read and write and random read and write) to perform read and write operations on the reset target memory.

[0088] Then, by using the Discard parameter and specifying the Discard parameter (i.e., the preset erasure parameter) when mounting the file system, when a file is deleted in the file system, the Trim (also known as disabledelete notify, Chinese name is disable delete notification) / Discard operation will be automatically triggered. First, the data blocks in the target memory after the read-write test are marked as target data blocks. For example, the data blocks are marked as "no longer in use" to obtain the target data blocks, that is, the data blocks that are no longer in use, so as to notify the block device to erase the blocks (target data blocks) in the target memory after the read-write test that do not contain valid data, and release the unused Blocks (data blocks), thereby reducing unnecessary erase-write cycles and increasing the service life of the target memory, so as to verify that although the support for the erase operation varies on each platform, it can work stably. Among them, Discard is a parameter of the mount command (the mount command is one of the core components or key parameters of the Linux system, mainly used for automated management of the space recycling of storage devices. The file system can send data block invalidation instructions to the underlying storage device (such as SSD, Ceph RBD (RADOS Block Device, which is a block storage service provided by the Ceph distributed storage system)) through this parameter.

[0089] S300. Perform an IOzone test on the erased target memory to end the current test cycle.

[0090] Among them, IOzone is an open-source file system benchmark tool used to test the read-write performance of the file system and can also test the disk read-write performance.

[0091] Exemplarily, after performing a read-write test and an erase operation on the reset target memory, a second reset test, that is, a reboot test, is performed on the erased target memory to detect the data integrity and security of the EMMC chip.

[0092] Then, an IOzone test is performed on the target memory that has passed the second reset test. Since IOzone can continuously perform read-write operations on the EMMC chip, the performance stability of the EMMC chip on the Android platform and whether there is performance degradation can be observed through long-term testing. If the performance is poor, it may indicate that there are problems with the storage chip when processing large blocks of data. Thus, the current test cycle ends.

[0093] For example, in one embodiment, before performing an IOzone test on the erased target memory, it further includes:

[0094] S299. Erase all data blocks in the target memory after erasure for a first preset number of times, and use error correction code to perform data integrity check to check whether the second reset test is successful.

[0095] However, performing an IOzone test on the erased target memory includes:

[0096] S301. Use the target memory after passing the second reset test to perform read and write operations on several data blocks of preset sizes respectively to detect the read and write speeds.

[0097] Among them, the preset size is the maximum data volume of the system's data output port.

[0098] Exemplarily, after performing the erasure operation, perform multiple Reset operations (i.e., restore to factory settings) on all data blocks in the erased target memory, that is, perform erasure operations on all data blocks for a first preset number of times (which can be the same as the second preset number of times, for example, 100 times), used to simulate the EMMC chip data clearing test after the user client has been used for a long time, which can eliminate the influence of user data and application settings on the test and ensure that the device is in the factory state.

[0099] Among them, during the process of restoring to factory settings, the system will execute a data erasure command to erase the data in the user data partition. The operating system will read the data in the erased partition of the EMMC chip without residue and the system data is not erased, perform data integrity check, and ensure that it has been securely erased and cannot be recovered to ensure security. And, the system will use the ECC (error correction code) in the EMMC chip to detect whether errors occur during the read and write process, that is, use error correction code to perform data integrity check. If an error occurs in the middle, it will cause the failure of restoring to factory settings.

[0100] Among them, the number of times of restoring to factory settings needs to be set in the programming of the second reset test, that is, set the first preset number of times, for example, 100.

[0101] Then, use the target memory after passing the second reset test to perform read and write operations on several data blocks of preset sizes (the maximum data of the system's data output port, for example, 512K, which is the maximum data transfer volume of the I / O port of the Android system) respectively. And, set the test cycle according to the EMMC capacity to try to fill the entire disk as much as possible. The file size is adjusted according to the memory size of the device, for example, 1G. Because the RAM (memory) of Android devices is usually limited, setting a file size of 1GB can not only ensure that the test data size does not exceed the cache size of the device, but also can more accurately test the actual read and write speeds of the file system, rather than just testing the cache performance.

[0102] Among them, the encoding of the IOzone test requires the size of the data block, such as 512K, and the file size, such as 1G.

[0103] S400. Repeat the test operations within the current test cycle until the test duration is met, and obtain the target memory that passes the IOzone test.

[0104] Exemplarily, one round of the current cycle test has ended above. To test the stability and reliability of the data, a loop test can be performed, that is, repeat the test operations within the current test cycle until the test duration is met, such as looping for 120h. This duration can be determined according to the chip capacity and the number of test cases. The entire process should be executed at least 2 rounds. The longer the time, the easier it is to expose the performance and stability of the chip under different conditions. Among them, the schematic diagram of the test process is as Figure 5 shown.

[0105] Furthermore, in another embodiment of the present application, the test duration can be replaced by the preset number of test cycles, that is, repeat the test operations within the current test cycle until the preset number of test cycles is met.

[0106] S500. Perform a verification operation on the target memory that passes the IOzone test to complete the compatibility test of the target memory.

[0107] Exemplarily, after the target memory passes the IOzone test, since there are certain programming and erasing times limits for the flash memory cells in the memory. Each write or erase operation will cause certain physical damage to the flash memory cells. After long-term read-write and Discard (erase) operations, these damages may cause the cells to fail and form bad blocks. Therefore, bad block and UECC (i.e., "uncorrectable error code", ECC is the abbreviation of Error correction code (error correction code), and U is the abbreviation of Uncorrectable. If the output data has a 0 and 1 inversion in the binary code relative to the expected data, the output code is called an error code) verification needs to be performed.

[0108] Please refer to Figure 6 , for example, in one embodiment, performing a verification operation on the target memory that passes the IOzone test includes:

[0109] S501. Verify the data blocks in the target memory after the IOzone test to screen out bad blocks;

[0110] S502. Compare the output data of the target memory after the IOzone test with the expected data to check for error codes in the output data.

[0111] Exemplarily, the specific process of the verification operation is as follows:

[0112] Perform bad block screening on the data blocks in the target memory after the IOzone test, and compare the output data with the expected data: whether there is an inversion of 0 and 1 in the binary code to separately check for bit errors in the data blocks and the output data.

[0113] Please refer to Figure 7 , an embodiment of the present application provides a memory compatibility verification system, including:

[0114] A test judgment module 10, configured to judge the returned system attribute value after performing a sleep wake-up and a first reset test on the target memory within the current test cycle, so as to judge whether the first reset test is successful.

[0115] A read-write and erase module 20, configured to perform a read-write test and an erase operation on the reset target memory if the reset is successful.

[0116] An IOzone test module 30, configured to perform an IOzone test on the erased target memory to end the current test cycle.

[0117] A repeat module 40, configured to repeat the test operations within the current test cycle until the test duration is met, to obtain a target memory that passes the IOzone test.

[0118] A verification module 50, configured to perform a verification operation on the target memory that passes the IOzone test to complete the compatibility test of the target memory.

[0119] Among them, the memory compatibility verification system is applicable to platforms under various Adroid systems, such as: RK series (Rockchip), MTK series (MediaTek, MediaTek platform), T606 platform (T606: All-netcom 8-core LTE platform. T606 is a new 8-core LTE mobile platform of Unisoc, designed based on the DynamlQ new generation big and small core architecture, and adopting the advanced 12nm process to achieve a balance between performance and power consumption), etc.

[0120] Exemplarily, the memory compatibility verification system is applicable to the memory compatibility verification method. Then, the implementation process of the memory compatibility verification system is as follows:

[0121] Perform the following tests within the current cycle: First, perform a restart operation (the first reset test) on the target memory after a sleep wake-up, and judge whether the restart is successful according to the returned system attribute value:

[0122] If the system property value is the preset value, it means that the restart is successful, because when the restart is successful, the system will return a specific system property value, that is, the preset value.

[0123] Then, the reset target memory is used to perform read and write tests on multiple data blocks, and then the target data blocks are erased. Next, the erased target memory is restored to factory settings (second reset test), and then the IOzone test is performed, and the current test cycle ends.

[0124] However, in order to test the stability and reliability of the data, the test operation in the last test cycle is repeated until the test duration is reached, and the target memory that passes the IOzone test is obtained.

[0125] Finally, the target memory that has passed the IOzone test is verified to complete the entire compatibility test of the target memory, thereby achieving a comprehensive evaluation of multiple aspects of the system, including the stability, performance and compatibility of hardware and software, and improving test efficiency and system compatibility.

[0126] For example, in one embodiment, the present application also provides a terminal device. Exemplarily, the terminal device includes an Android device, which includes a processor and a memory, wherein the memory stores a computer program, and the processor runs the computer program to enable the terminal device to execute the functions of the various modules in the above-mentioned memory compatibility verification method or the above-mentioned memory compatibility verification system.

[0127] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including a central processing unit (CPU), a graphics processing unit (GPU) and a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or at least one of other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc., which can implement or execute the disclosed methods, steps and logic block diagrams in the embodiments of the present application.

[0128] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electric Erasable Programmable Read-Only Memory (EEPROM), etc. Among them, the memory is used to store a computer program, and after receiving an execution instruction, the processor can execute the computer program accordingly.

[0129] This application also provides a computer-readable storage medium for storing the computer program used in the above terminal device. For example, the computer-readable storage medium may include, but is not limited to: various media such as USB flash drives, mobile hard disks, Read-Only Memory (ROM), Random Access Memory (RAM), magnetic disks, or optical discs that can store program codes.

[0130] In several embodiments provided by this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and structure diagrams in the drawings show the possible architectures, functions, and operations of the devices, methods, and computer program products according to multiple embodiments of this application. In this regard, each block in the flowchart or block diagram can represent a module, program segment, or part of the code, and the module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in an alternative implementation, the functions marked in the blocks may occur in a different order than marked in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and they can sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the structure diagram and / or flowchart, and the combination of blocks in the structure diagram and / or flowchart, can be implemented by a dedicated hardware-based system that executes the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0131] In addition, in each embodiment of this application, each functional module or unit can be integrated together to form an independent part, or each module can exist alone, or two or more modules can be integrated to form an independent part.

[0132] When the above-mentioned functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art or a part of this technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application.

[0133] As described above, the above are only specific embodiments of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed by this application can easily think of changes or substitutions, which should all be covered within the protection scope of this application.

Claims

1. A method for verifying the compatibility of a memory, characterized in that: include: In the current test cycle, after performing a sleep wake-up and a first reset test on the target memory, the returned system attribute value is judged to determine whether the first reset test is successful; If the reset is judged to be successful, a read / write test and an erase operation are performed on the reset target memory; Performing an IOzone test on the erased target memory, and ending the current test cycle; Repeat the test operation in the current test cycle until the test duration is met, and obtain the target storage that passes the IOzone test; A verification operation is performed on the target memory that passes the IOzone test to complete a compatibility test on the target memory.

2. The memory compatibility verification method according to claim 1, characterized in that: In the current test cycle, after the target memory is woken up from sleep and reset for the first time, the following are also included: Acquire and run the mirror system file in the target storage to establish communication with the target storage; Use the command to check the current device to check whether the communication with the target memory is successful.

3. The memory compatibility verification method according to claim 1, characterized in that: The IOzone test is performed on the erased target memory, and the following steps are previously included: Erasing all data blocks in the erased target memory for a first preset number of times, and performing a data integrity check using an error correction code to check whether the second reset test is successful; The IOzone test on the erased target memory includes: The target memory that has passed the second reset test is used to read and write data blocks of a plurality of preset sizes respectively to detect the reading and writing speed.

4. The memory compatibility verification method according to claim 1, characterized in that: The verifying operation on the target memory that passes the IOzone test includes: Verify the data blocks in the target storage after the IOzone test to filter out bad blocks; The output data of the target memory after the IOzone test is compared with the expected data to check the bit errors of the output data.

5. The memory compatibility verification method according to claim 1, characterized in that: The performing of read / write test and erase operation on the reset target memory includes: According to a preset access mode and a preset number of data blocks, read and write operations are performed on the reset target memory to test and obtain response time and voltage change; According to preset erasing parameters, after the data blocks in the target memory after the read and write tests are marked as target data blocks, the target data blocks are erased to release storage space.

6. The memory compatibility verification method according to claim 1, characterized in that: The step of judging the returned system property value after performing the sleep wake-up and the first reset test on the target memory in the current test cycle to judge whether the first reset test is successful includes: In the current test cycle, after performing a wake-up operation on the target memory a second preset number of times, performing a restart test on the target memory a third preset number of times; If the returned system property value is determined to be a preset value, then the restart test is determined to be successful.

7. The memory compatibility verification method according to claim 2, characterized in that: The checking of the current device instruction to check whether the communication with the target memory is successful includes: Execute the check current device instruction, and determine whether the target memory communicates successfully based on the returned execution result.

8. A memory compatibility verification system, characterized in that: include: A test judgment module is used to judge the returned system attribute value after performing a sleep wake-up and a first reset test on the target memory in the current test cycle to judge whether the first reset test is successful; The read / write and erase module is used to perform read / write test and erase operation on the reset target memory if the reset is judged to be successful; An IOzone test module, used for performing an IOzone test on the erased target memory, and ending the current test cycle; A repeating module, used for repeating the test operation in the current test cycle until the test duration is met, and obtaining a target memory that passes the IOzone test; The verification module is used to perform a verification operation on the target memory that passes the IOzone test to complete the compatibility test of the target memory.

9. A terminal device, characterized in that: It comprises a processor and a memory, wherein the memory stores machine executable instructions that can be executed by the processor, and the processor can execute the machine executable instructions to implement the memory compatibility verification method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the compatibility verification method of a memory according to any one of claims 1 to 7 is implemented.

Images