Boot verification method for emmc chip and related device

Abstract

The present application provides a Boot verification method for an eMMC chip and a related device. The method comprises: acquiring timing sequence verification data of multiple Boot platforms; constructing a verification platform on the basis of the multiple pieces of timing sequence verification data, so as to simulate, by means of the verification platform, first Boot timing sequences of an eMMC chip on multiple platforms; performing inter-command delay time adjustment on the multiple first Boot timing sequences to obtain multiple second Boot timing sequences; and designing multiple test cases on the basis of the multiple first Boot timing sequences and the multiple second Boot timing sequences, so as to execute the multiple test cases on the basis of a preset automation script to verify eMMC chips to be verified. In the present application, a verification platform can be constructed to simulate multiple Boot timing sequences, and a new timing sequence combination can be created by adjusting the inter-command delay time, so as to design test cases that can cover more scenarios, thereby improving the comprehensiveness and efficiency of verification.

Description

Boot verification methods and related equipment for eMMC chips Technical Field

[0001] This application relates to the field of chip testing technology, and in particular to a boot verification method and related equipment for eMMC chips. Background Technology

[0002] In embedded systems, eMMC (embedded Multi-Media Card) is a common storage solution used in mobile devices such as smartphones and tablets. The boot function of eMMC is crucial because it ensures that the host can quickly and efficiently read the BootLoader data in the eMMC during startup, thereby loading the operating system and other necessary boot programs. The boot process typically occurs during the host's Brok stage and relies on the BootLoader data within the Boot1 or Boot2 partition.

[0003] Existing boot testing methods, especially when using Android-based platforms (such as MediaTek, Qualcomm, and Unisoc), have the following problems: First, each restart test takes about 2 minutes, which greatly reduces testing efficiency. Second, since the boot mechanisms of different platforms may differ, existing testing methods cannot fully cover all possible combinations. This means that new platforms may still have compatibility issues, resulting in low efficiency and poor coverage of current eMMC chip boot testing. Summary of the Invention

[0004] The purpose of this application is to at least solve one of the technical problems existing in the prior art, and to provide a boot verification method and related equipment for eMMC chips. It can build a verification platform, simulate various boot timing sequences, and create new timing combinations by adjusting the delay time between commands, thereby designing test cases that can cover more scenarios, and ultimately improving the comprehensiveness and efficiency of verification.

[0005] In a first aspect, embodiments of this application provide a boot verification method for an eMMC chip, comprising: acquiring timing verification data from multiple boot platforms; constructing a verification platform based on the multiple timing verification data to simulate the first boot timing sequence of the eMMC chip on multiple platforms; adjusting the inter-command delay time of the multiple first boot timing sequences to obtain multiple second boot timing sequences; designing multiple test cases based on the multiple first boot timing sequences and the multiple second boot timing sequences, and executing the multiple test cases based on a preset automated script to verify the eMMC chip to be verified.

[0006] In some embodiments, obtaining timing verification data from multiple boot platforms includes: capturing boot timing data from multiple boot platforms, wherein the boot timing data at least includes the timing relationship between Vcc, Vccq, HwReset, and cmd.

[0007] In some embodiments, adjusting the inter-command delay time of the plurality of first boot timing sequences to obtain a plurality of second boot timing sequences includes: adjusting the time point at which the CMD0 command is sent after Vcc is powered on in the plurality of first boot timing sequences to simulate the first boot condition and obtain a plurality of second boot timing sequences.

[0008] In some embodiments, adjusting the inter-command delay time of the plurality of first boot boot sequences to obtain a plurality of second boot boot sequences includes: adjusting the delay time between different CMD0 commands in the plurality of first boot boot sequences to simulate a second boot condition and obtain a plurality of second boot boot sequences.

[0009] In some embodiments, designing multiple test cases based on multiple first boot timing sequences and multiple second boot timing sequences includes: obtaining multiple precondition configuration information, test scenario information, and command sending delay time information based on the multiple first boot timing sequences and multiple second boot timing sequences respectively; and designing multiple test cases based on the multiple precondition configuration information, the test scenario information, and the command sending delay time information.

[0010] In some embodiments, executing the plurality of test cases based on a preset automated script includes: executing the test cases based on the preset automated script according to the precondition configuration information, the test scenario information, and the command sending delay time information; during the execution of the test cases, detecting the correctness of the ACK signal and Boot data, and outputting the corresponding command sequence and time interval information when an error occurs.

[0011] In some embodiments, adjusting the inter-command delay time of the multiple first boot timing sequences to obtain multiple second boot timing sequences includes: after Vcc is powered on in the first boot timing sequence, keeping the sending time of the F0 command fixed, and obtaining multiple second boot timing sequences by changing the sending time interval between the F0 and FA commands; or, after Vcc is powered on in the first boot timing sequence, keeping the sending time interval between the F0 and FA commands unchanged, and obtaining multiple second boot timing sequences by changing the sending time interval between Vcc power-on and the F0 command.

[0012] Secondly, embodiments of this application provide a boot verification device for eMMC chips, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the boot verification method for eMMC chips as described in the first aspect embodiment above.

[0013] Thirdly, embodiments of this application provide a mobile robot, including the Boot verification device for eMMC chips as described in the second aspect of the embodiments above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the Boot verification method for an eMMC chip as described in the first aspect embodiment above.

[0015] The boot verification method and related equipment for eMMC chips provided in this application have at least the following beneficial effects: This application can collect boot timing data from different platforms, including but not limited to the timing streams of power-on (Vcc), clock (Vccq), hardware reset (HwReset), and commands (cmd); further, using the collected boot timing data from different platforms, a verification platform is constructed. This platform can simulate the first boot timing of the eMMC chip on these platforms, which is the actual working timing. On this platform, this application can control and simulate the timing relationships of signals such as Vcc, Vccq, HwReset, and CMD0; further, based on simulating the boot timing of the real platform, the delay time between commands is further adjusted, such as the delay between CMD0 and CMD8. Multiple second boot timing sequences are created, and by changing the interval between commands, various combinations of conditions can be generated to cover more unknown combinations. Furthermore, based on the obtained first and second boot timing sequences, test cases are designed to cover various combinations of power management, initialization sequence, command delay, and other factors. The test case design should consider all variables that may affect the success of booting, such as the power-on to power-off transition and specified delay times. Further, a pre-set automated test script is used to execute the designed test cases to verify the eMMC chip. The automated script can systematically arrange test conditions and record the results of each test, including detailed information such as which commands were executed and the time intervals between commands. When problems occur during testing, it can output more effective information to help analyze the cause of the problem, such as the specific commands issued and their combinations, and the time intervals between commands. Through the above steps, this application's solution not only improves verification efficiency but also enhances the comprehensiveness of verification by increasing the coverage of test cases and provides more debugging information when problems occur.

[0016] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0017] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0018] The present application will be further described below with reference to the accompanying drawings and embodiments;

[0019] Figure 1 is a flowchart illustrating the Boot verification method for eMMC chips provided in an embodiment of this application;

[0020] Figure 2 is another flowchart illustrating the Boot verification method for eMMC chips provided in an embodiment of this application;

[0021] Figure 3 is another flowchart illustrating the Boot verification method for eMMC chips provided in an embodiment of this application;

[0022] Figure 4 is another flowchart illustrating the Boot verification method for eMMC chips provided in an embodiment of this application;

[0023] Figure 5 is another flowchart illustrating the Boot verification method for eMMC chips provided in an embodiment of this application;

[0024] Figure 6 is another schematic flowchart of the Boot verification method for eMMC chips provided in the embodiments of this application;

[0025] Figure 7 is another flowchart illustrating the Boot verification method for eMMC chips provided in an embodiment of this application;

[0026] Figure 8 is a schematic diagram of the structure of the Boot verification device for eMMC chips provided in the embodiments of this application. Detailed Implementation

[0027] This section will describe in detail the specific embodiments of this application. Preferred embodiments of this application are shown in the accompanying drawings. The purpose of the drawings is to supplement the textual description with graphics, so that people can intuitively and vividly understand each technical feature and the overall technical solution of this application, but they should not be construed as limiting the scope of protection of this application.

[0028] In the description of this application, "several" means one or more, "multiple" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the number itself, while "above," "below," "within," etc. are understood to include the number itself. "Any one" refers to one or more, and "at least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. If the terms "first" and "second" are used only to distinguish technical features, they should not be construed as indicating or implying relative importance, or implicitly indicating the number of technical features indicated, or implicitly indicating the order of the technical features indicated.

[0029] It should be noted that the terms "setting," "installing," and "connecting" in the embodiments of this application should be interpreted broadly. Those skilled in the art can reasonably determine the specific meaning of the above terms in the embodiments of this application based on the specific content of the technical solution. For example, the term "connection" can be a mechanical connection, an electrical connection, or a connection that allows for mutual communication; it can be a direct connection or an indirect connection through an intermediate medium.

[0030] It should be noted that the technical features involved in the various embodiments of this application described below can be combined with each other as long as they do not conflict with each other.

[0031] In embedded systems, eMMC (embedded Multi-Media Card) is a common storage solution used in mobile devices such as smartphones and tablets. The boot function of eMMC is crucial because it ensures that the host can quickly and efficiently read the BootLoader data in the eMMC during startup, thereby loading the operating system and other necessary boot programs. The boot function typically occurs during the host's Brom phase and relies on the BootLoader data within the Boot1 or Boot2 partition. Existing boot testing methods, especially when using Android-based platforms (such as MediaTek, Qualcomm, and Unisoc), suffer from the following problems: First, each restart test takes approximately 2 minutes, significantly reducing testing efficiency. Second, because the boot mechanisms of different platforms may vary, existing testing methods struggle to comprehensively cover all possible combinations, meaning that compatibility issues may still exist with new platforms. This results in low efficiency and poor coverage in current eMMC chip boot testing.

[0032] The embodiments of this application will be further described below with reference to the accompanying drawings.

[0033] Referring to Figure 1, which is a flowchart illustrating a boot verification method for an eMMC chip provided in an embodiment of this application; in a first aspect, this application provides a boot verification method for an eMMC chip, including but not limited to the following steps:

[0034] Step S110: Obtain timing verification data from multiple Boot platforms;

[0035] Step S120: Construct a verification platform based on multiple timing verification data to simulate the first boot timing of the eMMC chip on multiple platforms through the verification platform;

[0036] Step S130: Adjust the inter-command delay time of multiple first boot timing sequences to obtain multiple second boot timing sequences;

[0037] Step S140: Design multiple test cases based on multiple first boot timing sequences and multiple second boot timing sequences, and execute multiple test cases based on preset automated scripts to verify the eMMC chip to be verified.

[0038] The Boot platform refers to the hardware platform that supports eMMC booting, such as smartphone motherboards and development boards, which have specific hardware configurations and boot logic. Timing verification data refers to the time point data of changes in various key signals (such as Vcc, Vccq, HwReset, etc.) during the boot process. These data reflect the state changes of various signals of the eMMC chip during the boot process.

[0039] In some embodiments, the verification platform is the environment used in this application to simulate the eMMC boot process. It can be a hardware emulator or a software simulation tool, used to reproduce the boot behavior of the eMMC chip on different platforms. The first boot timing refers to the actual timing flow of the eMMC chip during boot on a specific hardware platform, including the timing and duration of signal changes. The inter-command delay time refers to the time interval between the execution of different commands during the eMMC boot process; for example, after sending CMD0, waiting for a period of time before sending CMD8. The second boot timing refers to a new timing combination obtained by adjusting the first boot timing, such as adjusting the inter-command delay time. These combinations are used to test whether the eMMC chip can boot correctly under different conditions. Test cases are a series of operation sequences designed to verify the boot reliability of the eMMC chip; each test case represents a specific set of boot conditions. Pre-built automation scripts are pre-written program code used to automatically execute test cases and record results, simplifying the manual intervention process and improving testing efficiency. The eMMC chip to be verified refers to the target eMMC chip that needs to be boot verified using the above methods.

[0040] In this application embodiment, boot timing data from different platforms can be collected. This data includes, but is not limited to, the timing streams of power-on (Vcc), clock (Vccq), hardware reset (HwReset), and commands (cmd). Furthermore, using the collected boot timing data from different platforms, a verification platform is constructed. This platform can simulate the first boot timing of the eMMC chip on these platforms. The first boot timing is the timing during actual operation. On this platform, this application can control and simulate the timing relationships of signals such as Vcc, Vccq, HwReset, and CMD0. Furthermore, based on simulating the boot timing of the real platform, the delay time between commands is further adjusted, such as the delay between CMD0 and CMD8, to create multiple second boot timing sequences. The time interval between tests can generate various combinations of conditions to cover more unknown combinations. Furthermore, based on the first and second boot timing sequences obtained above, test cases are designed to cover various combinations of power management, initialization sequence, command delays, and other factors. The test case design should consider all variables that may affect the success of booting, such as the power-on to power-off transition and specified delay times. Further, using a pre-set automated test script, the designed test cases are executed to verify the eMMC chip. The automated script can systematically arrange test conditions and record the results of each test, including which commands were executed, the time intervals between commands, and other detailed information. When problems occur during testing, it can output more effective information to help analyze the cause of the problem, such as the specific commands issued and their combinations, and the time intervals between commands. Through the above steps, the proposed solution not only improves verification efficiency but also enhances the comprehensiveness of verification by increasing the coverage of test cases and provides more debugging information when problems occur.

[0041] Understandably, on the verification platform, a new timing combination is generated by changing the delay time between commands, namely the so-called second boot timing. This step is to simulate different boot conditions in order to more comprehensively test the performance of the eMMC chip. Based on the first and second boot timings mentioned above, multiple test cases are designed, and automated scripts are written to execute these test cases, thereby comprehensively and effectively verifying the functionality of the eMMC chip under test.

[0042] In some embodiments, the step of acquiring timing verification data from multiple boot platforms further includes collecting additional environmental parameters from the multiple boot platforms, such as the impact data of environmental factors like temperature and humidity on the startup timing of the eMMC chip. These environmental parameters can help to more accurately simulate the startup performance of the eMMC chip under different environmental conditions, thereby improving the comprehensiveness and accuracy of the test. For example, key signal change time point data of the eMMC chip during startup in low temperature (-20°C) and high temperature (85°C) environments can be collected, and the stability of the eMMC chip under extreme temperature conditions can be evaluated by comparing the startup timing differences under different temperature conditions.

[0043] In some embodiments, the step of adjusting the inter-command delay time of multiple first boot timing sequences further includes: introducing random noise or jitter while adjusting the inter-command delay time to simulate interference factors that may exist in the actual environment. For example, when adjusting the delay time between CMD0 and CMD8, ±10% random noise can be added, which can more realistically simulate the impact of environmental factors such as electromagnetic interference that the eMMC chip may encounter in actual applications, thereby improving the reliability and practicality of the test results.

[0044] In some embodiments, the step of designing multiple test cases based on multiple first boot timing sequences and multiple second boot timing sequences further includes: designing test cases that include exception handling mechanisms to verify the eMMC chip's recovery capability in the face of abnormal situations. For example, test cases can be designed to intentionally introduce erroneous responses after certain critical commands (such as CMD0) are sent, and the eMMC chip can be observed to correctly handle these abnormal situations and resume normal operation. This not only tests the basic boot function of the eMMC chip but also evaluates its robustness and fault tolerance under abnormal conditions.

[0045] Referring to Figure 2, which is another flowchart illustrating the boot verification method for eMMC chips provided in an embodiment of this application; in some embodiments, timing verification data from multiple boot platforms are obtained, including but not limited to the following steps:

[0046] Step S210: Capture boot timing data from multiple boot platforms. The boot timing data shall include at least the timing relationship between Vcc, Vccq, HwReset, and cmd.

[0047] In some embodiments, this application can capture boot timing data from different boot platforms (such as MTK, Qualcomm, Unisoc, and other mobile phone platforms). This data mainly includes: Vcc (power supply voltage): a signal indicating the power supply to the eMMC chip; Vccq (power clock): the power supply providing the clock signal to the eMMC; HwReset (hardware reset): a signal used to reset the eMMC chip; and cmd (command): control commands sent to the eMMC. Based on these timing parameters, a dedicated code script can be designed to shorten the reboot interval from 2 minutes to 20 seconds.

[0048] Understandably, by obtaining boot timing data from multiple boot platforms (such as MTK, Qualcomm, and Unisoc), it is possible to ensure that the verification method covers as many real-world application scenarios as possible, thereby improving the comprehensiveness and effectiveness of the test. This data provides a solid foundation for subsequent verification, making the timing adjustments and test case design in subsequent steps more targeted and scientific.

[0049] Referring to Figure 3, which is another flowchart illustrating the boot verification method for eMMC chips provided in an embodiment of this application; in some embodiments, the inter-command delay time of multiple first boot timing sequences is adjusted to obtain multiple second boot timing sequences, including but not limited to the following steps:

[0050] Step S310: Adjust the timing of sending the CMD0 command after Vcc is powered on in multiple first boot timing sequences to simulate the first boot condition and obtain multiple second boot timing sequences.

[0051] In some embodiments, this application can simulate different boot conditions by adjusting the timing of sending the CMD0 command after Vcc power-on, thereby obtaining multiple second boot timing sequences. Specifically: by selecting Vcc power-on as the starting time point, the CMD0 command is sent at different times after Vcc power-on, for example, after 50 microseconds. Immediately after sending the CMD0 command, another variant command of CMD0 (such as CMD0+0xFFFFFFFA) is sent. By changing the time interval between these two commands, different combination conditions can be created, for example, from 5 microseconds to 1000 milliseconds.

[0052] Understandably, by adjusting the timing of sending the CMD0 command after Vcc power-on, various different startup conditions can be simulated. For example, changing the time interval between the CMD0 command and its variants (such as CMD0+0xFFFFFFFA), ranging from a few microseconds to a few milliseconds, can help identify behavioral differences in the eMMC chip under different conditions. This allows the present application to effectively identify the behavior of the eMMC under different startup conditions, thereby ensuring that the eMMC chip can operate stably under various circumstances.

[0053] Referring to Figure 4, which is another flowchart illustrating the boot verification method for eMMC chips provided in an embodiment of this application; in some embodiments, the inter-command delay time of multiple first boot timing sequences is adjusted to obtain multiple second boot timing sequences, including but not limited to the following steps:

[0054] Step S410: Adjust the delay time between different CMD0 commands in multiple first boot timing sequences to simulate the second boot conditions and obtain multiple second boot timing sequences.

[0055] In some embodiments, this step simulates a different boot condition by adjusting the delay time between different CMD0 commands, thereby obtaining multiple second boot timing sequences. Specifically, after Vcc is powered on, the sending time of the first CMD0 command is fixed, and the delay time between the first and second CMD0 commands is adjusted to simulate different boot conditions. For example, the first CMD0 command is kept sent 50 microseconds after Vcc is powered on, but the delay time of the second CMD0 command relative to the first CMD0 command is changed, ranging from a few microseconds to a few milliseconds.

[0056] Understandably, through the above steps, in addition to adjusting the timing of sending CMD0 after Vcc is powered on, this application can also further expand the scope of testing by changing the delay time between different CMD0 commands, thereby ensuring the performance of eMMC under more combined conditions and making the verification process more refined.

[0057] In some embodiments, this application can simulate multiple startup conditions and design multiple test cases based on these conditions. These test cases are then executed based on pre-built automated scripts to verify the startup behavior of the eMMC chip under test under different conditions. This approach not only improves testing efficiency but also covers a wider range of startup combinations, helping to identify potential problems and provide detailed debugging information.

[0058] Referring to Figure 5, which is another flowchart illustrating the boot verification method for eMMC chips provided in an embodiment of this application; in some embodiments, multiple test cases are designed based on multiple first boot timing sequences and multiple second boot timing sequences, including but not limited to the following steps:

[0059] Step S510: Obtain multiple precondition configuration information, test scenario information, and command sending delay time information based on multiple first boot timing sequences and multiple second boot timing sequences respectively;

[0060] Step S520: Design multiple test cases based on multiple precondition configuration information, test scenario information, and command sending delay time information.

[0061] In some embodiments, multiple precondition configuration information, test scenario information, and command sending delay time information are obtained based on multiple first boot timing sequences and multiple second boot timing sequences, respectively. In the above steps, this application can extract multiple precondition configuration information, test scenario information, and command sending delay time information based on boot timing data captured from different platforms (including the timing relationship between Vcc, Vccq, HwReset, and cmd) and multiple second boot timing sequences obtained by adjusting the delay time between commands.

[0062] The precondition configuration information refers to the environmental parameters that need to be set before executing test cases, such as power status and reset signal status. The test scenario information describes the specific steps to be followed during test execution, including which commands to send and the order in which they are sent. The command sending delay information refers to the time interval between different commands during the test; these intervals may be fixed or vary within a certain range. Specifically, the above configuration steps can be implemented by designing the function `Func_boot_verify(Pre_condition, Case, T1, T2, T3)`, where `Pre_condition` represents the precondition configuration information, `Case` represents different test scenario information, and `T1`, `T2`, and `T3` ​​represent different command sending delay times.

[0063] In some embodiments, after obtaining the above information, this application can integrate this information to design multiple test cases. Each test case is a specific test scenario, which includes a series of steps from power management to initialization command sending, as well as the time interval between each step.

[0064] Referring to Figure 6, which is another flowchart illustrating the Boot verification method for eMMC chips provided in an embodiment of this application; in some embodiments, multiple test cases are executed based on a pre-set automated script, including but not limited to the following steps:

[0065] Step S610: Based on the pre-set automated script, execute test cases according to the precondition configuration information, test scenario information and command sending delay time information;

[0066] Step S620: During the execution of test cases, the correctness of the ACK signal and Boot data is checked, and the corresponding command sequence and time interval information are output when an error occurs.

[0067] In some embodiments, during test execution, this application may employ pre-built automated scripts to set preconditions according to designed test cases, and execute tests according to predetermined test scenario information and command sending delay time information. The automated scripts can automatically complete various tasks during the test process, including setting power status, sending initialization commands, and recording command execution time and results.

[0068] As can be imagined, during testing, this application can monitor the ACK signal (acknowledgment signal) and the correctness of Boot data. If a problem occurs during testing, the system will record the command sequence at the time of the problem (i.e., which commands were sent) and the time intervals between these commands, and output this information for debugging purposes. This information is crucial for debugging because it helps engineers quickly locate the problem and take corrective measures.

[0069] By following the steps above, we can ensure that the startup behavior of the eMMC chip can be fully tested under different boot timing conditions, and provide detailed debugging information when problems occur, thereby improving the comprehensiveness and efficiency of verification.

[0070] Referring to Figure 7, which is another flowchart illustrating the boot verification method for eMMC chips provided in an embodiment of this application; in some embodiments, the inter-command delay time of multiple first boot timing sequences is adjusted to obtain multiple second boot timing sequences, including but not limited to the following steps:

[0071] Step S710: After Vcc is powered on in the first boot sequence, keep the sending time of the F0 command fixed, and obtain multiple second boot sequences by changing the sending time interval between the F0 and FA commands.

[0072] Step S720, or, after Vcc is powered on in the first boot sequence, the time interval between the F0 and FA commands is kept constant, and multiple second boot sequences are obtained by changing the time interval between Vcc power-on and the F0 command.

[0073] In some embodiments, the inter-command delay time of multiple first boot timing sequences is adjusted to obtain multiple second boot timing sequences. After Vcc (power supply voltage) is powered on in the first boot timing sequence, the sending time of the F0 command is kept fixed. By changing the sending time interval between the F0 and FA commands, multiple second boot timing sequences are obtained. New startup conditions are constructed by changing the time interval between the F0 and FA commands. The specific operation is as follows: After Vcc (power supply voltage) is powered on, a fixed time is set to send the CMD0 command (F0 is an abbreviation of CMD0 0xF0F0F0F0). Immediately after sending CMD0 (e.g., after 5 microseconds), the CMD0 0xFFFFFFFA command (FA is an abbreviation of CMD0 0xFFFFFFFA) is sent. By changing this time interval (ranging from 5 microseconds to 1000 milliseconds), different combinations of startup conditions can be created. These adjusted time interval combinations form multiple new boot timing sequences, i.e., second boot timing sequences, for subsequent testing.

[0074] In some embodiments, after Vcc powers on in the first boot sequence, the time interval between sending the F0 and FA commands remains unchanged. By changing the time interval between Vcc power-on and the F0 command, multiple second boot sequences are obtained to construct new boot conditions by changing the time interval between Vcc power-on and the CMD0 (F0) command. Specifically, the time interval between the CMD0 (F0) command and the CMD0 0xFFFFFFFA (FA) command remains unchanged, while the time interval between Vcc power-on and the F0 command is changed. After Vcc powers on, the timing of sending the CMD0 command is changed. For example, CMD0 is sent 50 microseconds after Vcc powers on, but this time can be changed to other values, such as 100 microseconds, 500 microseconds, etc. These adjusted time interval combinations also form multiple new boot sequences, i.e., second boot sequences, for subsequent testing.

[0075] By following the steps above, multiple different boot conditions can be constructed, resulting in multiple second boot timing sequences. These new timing combinations can help verify the performance of the eMMC chip under different boot conditions, thereby improving the comprehensiveness and efficiency of the verification.

[0076] In summary, this application captures boot timing data from multiple boot platforms (such as MTK, Qualcomm, and Unisoc mobile platforms) during the acquisition of timing verification data. This data primarily includes the timing relationships between Vcc (power supply voltage), Vccq (power clock), HwReset (hardware reset), and cmd (command). By acquiring boot timing data from different platforms, the verification method can be ensured to cover as many real-world application scenarios as possible, thereby improving the comprehensiveness and effectiveness of the testing.

[0077] During the construction of the verification platform, based on the acquired timing verification data, a verification platform was built that can simulate the first boot timing of the eMMC chip on multiple platforms. The first boot timing is the timing during actual operation, including the timing points and durations of signal changes. On this platform, the startup behavior of the eMMC chip on different platforms can be reproduced by controlling and simulating the timing relationships of signals such as Vcc, Vccq, HwReset, and CMD0.

[0078] During the adjustment of command delay times, based on the simulated boot sequence of a real platform, the delay times between commands are further adjusted, such as the delay between CMD0 and CMD8, to create multiple secondary boot sequences. By changing the interval between commands, various combinations of conditions can be generated to cover more unknown combinations. Specifically, the command delay times can be adjusted in the following two ways:

[0079] By adjusting the timing of sending the CMD0 command after Vcc power-on, the CMD0 command can be sent at different points after Vcc power-on, such as 50 microseconds later, followed immediately by another variant of CMD0 (e.g., CMD0+0xFFFFFFFA). Different combinations of conditions can be created by changing the time interval between these two commands, ranging from 5 microseconds to 1000 milliseconds.

[0080] By adjusting the delay time between different CMD0 commands, the sending time of the first CMD0 command is fixed after Vcc is powered on, and the delay time between the first and second CMD0 commands is adjusted to simulate different startup conditions. For example, the first CMD0 command is sent 50 microseconds after Vcc is powered on, but the delay time of the second CMD0 command relative to the first CMD0 command is changed, ranging from a few microseconds to a few milliseconds.

[0081] During the test case design process, multiple test cases were designed based on multiple first boot sequence numbers and multiple second boot sequence numbers. Each test case is a specific test scenario, including a series of steps from power management to initialization command sending, as well as the time intervals between each step. The test case design should take into account all variables that may affect the success of booting, such as the power-on to power-off transition and specified delay times.

[0082] Based on the first and second boot sequence numbers, multiple precondition configuration information, test scenario information, and command sending delay information are extracted. Precondition configuration information refers to the environmental parameters that need to be set before executing test cases, such as power status and reset signal status. Test scenario information describes the specific steps to be followed during test execution, including which commands to send and the order in which they are sent. Command sending delay information refers to the time interval between different commands during the test. By integrating the above information, multiple test cases are designed, each covering a specific set of startup conditions.

[0083] During test case execution, pre-defined automated test scripts are used to execute the designed test cases and verify the eMMC chip. The automated scripts can systematically arrange test conditions and record the results of each test, including detailed information such as which commands were executed and the time intervals between commands. During testing, the ACK signal (acknowledgment signal) and the correctness of the Boot data are monitored. If a problem occurs during testing, the system records the command sequence at the time of the problem (i.e., which commands were sent) and the time intervals between these commands, outputting this information for debugging purposes. This information is crucial for debugging because it helps engineers quickly locate the problem and take corrective action.

[0084] Through the above steps, this application can not only improve verification efficiency, but also enhance the comprehensiveness of verification by increasing the coverage of test cases, and provide more debugging information when problems occur, thereby ensuring the stability and reliability of the eMMC chip under various startup conditions.

[0085] Secondly, referring to Figure 8, which is a schematic diagram of the structure of a Boot verification device 800 for an eMMC chip provided in an embodiment of this application, the operation control device 800 includes: a memory 810, a processor 820, and a computer program stored in the memory 810 and executable on the processor 820. When the processor 820 executes the computer program, it implements the Boot verification method for an eMMC chip as described in the above embodiment.

[0086] The memory 810, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs, such as the boot verification method for eMMC chips in the above embodiments of this application. The processor 820 implements the boot verification method for eMMC chips in the above embodiments of this application by running the non-transitory software programs and instructions stored in the memory 810.

[0087] The memory 810 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data required for executing the Boot verification method for the eMMC chip in the above embodiments. Furthermore, the memory 810 may include high-speed random access memory 810, and may also include non-transitory memory 810, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. It should be noted that the memory 810 may optionally include memory 810 remotely located relative to the processor 820, and these remote memories 810 can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0088] The non-transitory software program and instructions required to implement the boot verification method for eMMC chips in the above embodiments are stored in memory. When executed by one or more processors, the boot verification method for eMMC chips in the above embodiments is executed. For example, the method steps S110 to S140 in FIG1, S210 in FIG2, S310 in FIG3, S410 in FIG4, S510 to S520 in FIG5, S610 to S620 in FIG6, and S710 to S720 in FIG7 are executed.

[0089] Thirdly, this application provides a mobile robot that includes a boot verification device for an eMMC chip as described in the second aspect.

[0090] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the boot verification method for an eMMC chip as described in the first aspect embodiment above. For example, performing method steps S110 to S140 in FIG1, method step S210 in FIG2, method step S310 in FIG3, method step S410 in FIG4, method steps S510 to S520 in FIG5, method steps S610 to S620 in FIG6, and method steps S710 to S720 in FIG7 of the above embodiments.

[0091] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to the output requirements.

[0092] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which may include computer storage media or non-transitory media and communication media or transient media. As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc DVD or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0093] The embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of this application.

Claims

1. A boot verification method for eMMC chips, characterized in that, include: Obtain timing verification data from multiple boot platforms; A verification platform is constructed based on multiple timing verification data to simulate the first boot timing of the eMMC chip on multiple platforms. Adjust the inter-command delay time of multiple first boot timing sequences to obtain multiple second boot timing sequences; Multiple test cases are designed based on multiple first boot timing sequences and multiple second boot timing sequences, and the multiple test cases are executed based on preset automated scripts to verify the eMMC chip to be verified.

2. The boot verification method for eMMC chips according to claim 1, characterized in that, The acquisition of timing verification data from multiple boot platforms includes: Boot timing data is captured from multiple boot platforms, and the boot timing data includes at least the timing relationship between Vcc, Vccq, HwReset, and cmd.

3. The boot verification method for eMMC chips according to claim 1, characterized in that, The step of adjusting the inter-command delay time of multiple first boot timing sequences to obtain multiple second boot timing sequences includes: Adjust the timing of sending the CMD0 command after Vcc power-on in multiple first boot timing sequences to simulate the first boot condition and obtain multiple second boot timing sequences.

4. The boot verification method for eMMC chips according to claim 1, characterized in that, The step of adjusting the inter-command delay time of multiple first boot timing sequences to obtain multiple second boot timing sequences includes: Adjust the delay time between different CMD0 commands in multiple first boot timing sequences to simulate second boot conditions and obtain multiple second boot timing sequences.

5. The boot verification method for eMMC chips according to claim 1, characterized in that, The design of multiple test cases based on multiple first boot sequence numbers and multiple second boot sequence numbers includes: Multiple precondition configuration information, test scenario information, and command sending delay time information are obtained based on multiple first boot timing sequences and multiple second boot timing sequences, respectively. Design multiple test cases based on the aforementioned precondition configuration information, test scenario information, and command sending delay time information.

6. The boot verification method for eMMC chips according to claim 5, characterized in that, The execution of the multiple test cases based on pre-configured automated scripts includes: Based on the pre-set automated script, the test cases are executed according to the precondition configuration information, the test scenario information, and the command sending delay time information; During the execution of the test cases, the correctness of the ACK signal and Boot data is checked, and the corresponding command sequence and time interval information are output when an error occurs.

7. The boot verification method for eMMC chips according to claim 1, characterized in that, The step of adjusting the inter-command delay time of multiple first boot timing sequences to obtain multiple second boot timing sequences includes: After Vcc is powered on in the first boot sequence, the sending time of the F0 command is kept fixed. By changing the sending time interval between the F0 and FA commands, multiple second boot sequences are obtained. Alternatively, after Vcc is powered on in the first boot sequence, the time interval between sending F0 and FA commands remains unchanged, and multiple second boot sequences are obtained by changing the time interval between Vcc power-on and F0 commands.

8. A boot verification device for eMMC chips, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the Boot verification method for an eMMC chip as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, Includes the Boot verification device for eMMC chips as described in claim 8.

10. A computer-readable storage medium storing computer-executable instructions for performing a boot verification method for an eMMC chip as described in any one of claims 1 to 7.

Images