CN110618903A - Electronic equipment testing method and device - Google Patents
Electronic equipment testing method and device Download PDFInfo
- Publication number
- CN110618903A CN110618903A CN201810630006.5A CN201810630006A CN110618903A CN 110618903 A CN110618903 A CN 110618903A CN 201810630006 A CN201810630006 A CN 201810630006A CN 110618903 A CN110618903 A CN 110618903A
- Authority
- CN
- China
- Prior art keywords
- test
- storage
- command
- platform descriptor
- electronic device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 383
- 238000012545 processing Methods 0.000 claims abstract description 41
- 238000000034 method Methods 0.000 claims abstract description 25
- 230000008569 process Effects 0.000 claims abstract description 23
- 238000010998 test method Methods 0.000 abstract description 11
- 239000003795 chemical substances by application Substances 0.000 description 87
- 230000004044 response Effects 0.000 description 20
- 238000010586 diagram Methods 0.000 description 18
- 238000012986 modification Methods 0.000 description 10
- 230000004048 modification Effects 0.000 description 10
- 230000006870 function Effects 0.000 description 5
- 238000012937 correction Methods 0.000 description 4
- 239000000835 fiber Substances 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- CXOXHMZGEKVPMT-UHFFFAOYSA-N clobazam Chemical compound O=C1CC(=O)N(C)C2=CC=C(Cl)C=C2N1C1=CC=CC=C1 CXOXHMZGEKVPMT-UHFFFAOYSA-N 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000011982 device technology Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 1
- 239000010931 gold Substances 0.000 description 1
- 229910052737 gold Inorganic materials 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 229940044442 onfi Drugs 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2273—Test methods
Abstract
The present application relates to a storage device, and more particularly, to a method and an apparatus for testing an electronic device, wherein the storage device includes: a storage interface, a test agent, a platform descriptor, and firmware; the test agent receives a test command of the test equipment through the test interface, acquires a platform descriptor according to the test command, and provides the platform descriptor to the test equipment through the test interface; the firmware receives a storage command generated by the test equipment according to the platform descriptor through the storage interface, processes the storage command according to the platform descriptor to obtain a processing result, and provides the processing result to the test equipment through the storage interface. Since the same platform descriptor is used by both the firmware and the test agent, it is ensured that the characteristics of the storage device known by the test software are consistent with the characteristics of the storage device provided by the firmware, thereby ensuring efficient performance of the test procedure.
Description
Technical Field
The present application relates to the field of storage device technologies, and in particular, to a method and an apparatus for testing software or firmware executed by a storage device.
Background
Referring to FIG. 1, a block diagram of a storage device is shown. The storage device 102 is coupled to a host for providing storage capabilities to the host. The host and the storage device 102 may be coupled by a variety of means including, but not limited to, connecting the host and the storage device 102 by, for example, SATA, IDE, USB, PCIE, NVMe (NVM Express), SAS, ethernet, fibre channel, wireless communication network, etc. The host may be an information processing device, such as a personal computer, tablet, server, portable computer, network switch, router, cellular telephone, personal digital assistant, etc., capable of communicating with the storage device in the manner described above. The storage device 102 includes an interface 103, a control unit 104, one or more NVM (Non-Volatile Memory) chips 105 and optionally a firmware Memory 110. The interface 103 may be adapted to exchange data with a host by means such as SATA, IDE, USB, PCIE, NVMe, SAS, ethernet, fibre channel, etc. The control unit 104 is used to control data transfer between the interface 103, the NVM chip 105, and the firmware memory 110, and also used for memory management, host logical address to flash physical address mapping, erase leveling, bad block management, and the like. The control component 104 can be implemented in a variety of ways including software, hardware, firmware, or a combination thereof. The control unit 104 may be in the form of an FPGA (Field-programmable gate array), an ASIC (Application Specific Integrated Circuit), or a combination thereof. The control component 104 may also include a processor or controller. Control unit 104 loads firmware from firmware memory 110 at runtime. Firmware memory 110 may be NOR flash, ROM, EEPROM, or may be part of NVM chip 105.
Control section 104 includes a flash interface controller (or referred to as a media interface controller, a flash channel controller) that is coupled to NVM chip 105 and issues commands to NVM chip 105 in a manner that conforms to an interface protocol of NVM chip 105 to operate NVM chip 105 and receive command execution results output from NVM chip 105. Known NVM chip interface protocols include "Toggle", "ONFI", etc.
The memory Target (Target) is one or more Logic Units (LUNs) of a shared Chip Enable (CE) signal within the NAND flash package. One or more dies (Die) may be included within the NAND flash memory package. Typically, a logic cell corresponds to a single die. The logical unit may include a plurality of planes (planes). Multiple planes within a logical unit may be accessed in parallel, while multiple logical units within a NAND flash memory chip may execute commands and report status independently of each other. The meaning for target, logical Unit, LUN, Plane (Plane) is provided in "Open NAND Flash Interface Specification (Revision 3.0)" available from http:// www.micron.com// media/Documents/Products/Other% 20Documents/ONFI3_0 Gold. ashx, which is part of the prior art.
Disclosure of Invention
The software or firmware running in the storage device (hereinafter collectively referred to as firmware for the sake of clarity and conciseness, and the sequence of instructions running in the computer or server accessing the storage device as software) needs to be adequately tested to ensure the quality and reliability of the storage device. The test software also tests the storage device including the hardware.
As the firmware of the storage device is iteratively developed, the function of the storage device becomes increasingly complex, and the target to be checked by the test software changes. The test software is required to have sufficient knowledge of the characteristics provided by the firmware of the currently tested memory device in order to know which features are tested for the currently tested memory device and the acceptance criteria for those features to be tested.
However, test software and storage device firmware are often developed by different teams. Due to the respective development schedules, there are often differences in the understanding of the characteristics of the currently tested storage devices among different teams, resulting in difficulties in the testing software to accurately know the test characteristics of the storage devices being tested, and/or setting of wrong acceptance criteria. For example, the test software tests the multi-namespace feature of the storage device, and the firmware of the tested storage device does not support the multi-namespace feature, in which case the test software prompts a test failure, but accordingly does not confirm any defects of the storage device. A solution to the above problem is needed.
According to a first aspect of the present application, there is provided a first storage device according to the first aspect of the present application, comprising: a storage interface, a test agent, a platform descriptor, and firmware; the test agent receives a test command of the test equipment through the test interface, acquires a platform descriptor according to the test command, and provides the platform descriptor to the test equipment through the test interface; the firmware receives a storage command generated by the test equipment according to the platform descriptor through the storage interface, processes the storage command according to the platform descriptor to obtain a processing result, and provides the processing result to the test equipment through the storage interface.
The first storage device according to the first aspect of the present application, wherein the platform descriptor is recorded in a platform descriptor space of the storage device.
The second storage device according to the first aspect of the present application, wherein the platform descriptor space is a partial memory space of a control part of the storage device.
One of the first to third storage devices according to the first aspect of the present application, wherein the platform descriptor records a version of the storage device hardware/firmware, a feature supported by the storage device, or configuration information of the storage device.
One of the first to fourth memory devices according to the first aspect of the present application, wherein the test agent is provided by a portion of the control section of the memory device or by a CPU of the control section of the memory device running a program.
One of the first to fifth storage devices according to the first aspect of the present application, wherein the test agent causes the storage device to provide the test interface.
One of the first to sixth storage devices according to the first aspect of the present application, wherein the firmware is run on a CPU of a control section of the storage device.
One of the first to seventh storage devices according to the first aspect of the present application, wherein the platform descriptor records a test method for the storage device, and the storage command is generated according to the test method.
One of the first to eighth storage devices according to the first aspect of the present application, wherein the storage command for accessing the range of storage space is generated according to the size of storage space of the storage device indicated by the platform descriptor.
One of the first to ninth storage devices according to the first aspect of the present application, wherein the storage command outside the range of the access storage space is generated according to the size of the storage space of the storage device indicated by the platform descriptor.
One of the first to tenth storage devices according to the first aspect of the present application, wherein the test agent further receives, through the test interface, a test command that the test device instructs to modify the platform descriptor, and updates the platform descriptor according to the test command; the firmware also receives a storage command generated by the test equipment according to the updated platform descriptor through the storage interface, processes the storage command according to the updated platform descriptor to obtain a processing result, and provides the processing result to the test equipment through the storage interface.
One of the first to eleventh memory devices according to the first aspect of the present application, wherein the test agent generates a reboot command instructing the control section of the memory device to reboot.
One of the first to eleventh storage devices according to the first aspect of the present application, wherein the firmware generates a reboot command instructing the control section of the storage device to reboot in response to the platform descriptor being updated.
One of the first to thirteenth storage devices according to the first aspect of the present application includes a CPU having local parameters, wherein the test agent receives a test command sent by the test device, sends a message to the target CPU instructing the target CPU to modify the local parameters according to the test command, and sends a processing result to the test device.
The fourteenth storage device according to the first aspect of the present application, wherein the test command includes a new value indicating the target CPU, the target local parameter, and the target CPU updates the target local parameter to the new value of the local parameter in response to the get message.
The fourteenth storage device according to the first aspect of the present application, wherein the test command indicates a modification form of the target local parameter, and the target CPU modifies the local parameter according to the indicated modification form to obtain a new value of the target local parameter in response to the obtaining message.
The fifteenth or sixteenth storage device according to the first aspect of the present application, wherein, in response to the target local parameter being successfully updated, the firmware receives a storage command generated from a new value of the target local parameter sent by the test device.
One of the first to eleventh storage devices according to the first aspect of the present application, wherein the test command indicates a target CPU, an operation code, a return value size, and/or one or more parameters.
The eighteenth storage device according to the first aspect of the present application, wherein the test agent further receives a reset packet sent by the test device before receiving the test command, and in response to receiving the reset packet, the test agent sets its status as not ready.
The nineteenth storage device according to the first aspect of the present application, wherein the test command is sent in accordance with a non-ready state of the test agent.
One of the eighteenth to twentieth storage devices according to the first aspect of the present application, wherein the test agent receives a commit packet sent by the test device, the commit packet instructing the test agent to start processing the test command.
The twenty-first storage device according to the first aspect of the present application, wherein the test agent sends the test command to the instructed target CPU according to the commit packet, and receives an execution result of the test command from the target CPU.
One of the eighteenth to twenty-second storage devices according to the first aspect of the present application, wherein the test agent sets its status to ready after completing the processing of the test command.
A twenty-third memory device according to the first aspect of the present application, wherein the test device obtains an execution result of the test command depending on the memory device being in a ready state.
According to a second aspect of the present application, there is provided a first electronic device testing method according to the second aspect of the present application, comprising the steps of: the electronic equipment receives a test command of the test equipment, acquires a platform descriptor according to the test command and provides the platform descriptor for the test equipment; the test equipment generates a storage command according to the platform descriptor and sends the storage command to the electronic equipment; the electronic equipment processes the storage command according to the platform descriptor to obtain a processing result, and provides the processing result to the testing equipment.
The first electronic device testing method according to the second aspect of the present application, wherein the platform descriptor is recorded in a platform descriptor space of the electronic device.
The second electronic device testing method according to the second aspect of the present application, wherein the platform descriptor space is a partial memory space of a control section of the electronic device.
One of the first to third electronic device testing methods according to the second aspect of the present application, wherein the platform descriptor records a version of hardware/firmware of the electronic device, a feature supported by the electronic device, or configuration information of the electronic device.
According to one of the first to third electronic device testing methods of the second aspect of the present application, the platform descriptor records a testing method for the electronic device, and the testing device generates the storage command according to the testing method set in the platform descriptor.
One of the first to third electronic device testing methods according to the second aspect of the present application, wherein the test device generates a storage command to access a range of the electronic device storage space according to the size of the electronic device storage space indicated in the platform descriptor.
One of the first to third electronic device testing methods according to the second aspect of the present application, wherein the test device generates a storage command to access outside the range of the electronic device storage space according to the size of the electronic device storage space indicated in the platform descriptor.
One of the first to seventh electronic device testing methods according to the second aspect of the present application, further comprising: the electronic equipment receives a test command of the test equipment for indicating to modify the platform descriptor, and updates the platform descriptor according to the test command; the test equipment generates a storage command according to the updated platform descriptor and sends the storage command to the electronic equipment; and the electronic equipment processes the storage command according to the updated platform descriptor to obtain a processing result, and provides the processing result for the test equipment.
An eighth electronic device testing method according to the second aspect of the present application, wherein the testing device instructs the electronic device to restart after updating the platform descriptor.
The eighth electronic device testing method according to the second aspect of the present application, further includes: the electronic equipment receives a test command sent by the test equipment, sends a message to a target CPU with local parameters according to the test command to instruct the target CPU to modify the local parameters, and sends a processing result to the test equipment.
The tenth electronic device testing method according to the second aspect of the present application, wherein the test command includes a new value indicating the target CPU, the target local parameter, and the target CPU updates the target local parameter to the new value of the local parameter in response to the get message.
According to the tenth electronic device testing method of the second aspect of the present application, the test command indicates a modification form of the target local parameter, and the target CPU modifies the local parameter according to the indicated modification form to obtain a new value of the target local parameter in response to the obtaining message.
The eleventh or twelfth electronic device testing method according to the second aspect of the present application, wherein in response to a successful update of the target local parameter, the test device sends a storage command generated from a new value of the target local parameter to the electronic device.
A thirteenth electronic device testing method according to the second aspect of the present application, wherein the test command indicates a target CPU, an operation code, a return value size, and/or one or more parameters.
According to one of the eighth to fourteenth electronic device testing methods of the second aspect of the present application, before the electronic device receives the test command, a reset packet sent by the test device is also received, and in response to receiving the reset packet, the electronic device sets its status as not ready.
A fifteenth electronic device testing method according to the second aspect of the present application, wherein the test device sends the test command in accordance with an unserviceable state of the electronic device.
The fifteenth or sixteenth electronic device testing method according to the second aspect of the present application, wherein the electronic device receives a submit packet sent by the testing device, the submit packet instructing the electronic device to start processing the test command.
The seventeenth electronic device testing method according to the second aspect of the present application, wherein the electronic device sends the test command to the instructed target CPU according to the commit packet, and receives an execution result of the test command from the target CPU.
According to one of the eighth to eighteenth electronic device testing methods of the second aspect of the present application, after the electronic device completes processing of the test command, the state thereof is set to ready.
According to the nineteenth electronic device testing method of the second aspect of the present application, the test device acquires the execution result from the electronic device in accordance with the electronic device being in the ready state.
According to a third aspect of the present application, there is provided a first electronic device testing method according to the third aspect of the present application, comprising: compiling the firmware code into firmware of the electronic device using the platform descriptor; the electronic equipment receives a storage command generated by the testing equipment according to the platform descriptor, processes the storage command by using the platform descriptor in the firmware to obtain a processing result, and provides the processing result for the testing equipment.
The first electronic device testing method according to the third aspect of the present application, wherein the firmware generated by compiling using the platform descriptor has a test agent.
According to the first or second electronic device testing method of the third aspect of the present application, the electronic device receives a test command sent by the testing device, and the test command instructs the electronic device to access the platform descriptor maintained therein.
According to the third electronic device testing method of the third aspect of the present application, accessing the platform descriptor maintained inside the electronic device includes obtaining the platform descriptor or modifying the platform descriptor.
According to one of the first to fourth electronic device testing methods of the third aspect of the present application, the platform descriptor records whether to generate the test agent, whether to enable the test agent, and/or whether to enable the test interface.
According to one of the first to fourth electronic device testing methods of the third aspect of the present application, the platform descriptor records a version of hardware/firmware of the electronic device, a feature supported by the electronic device, and/or configuration information of the electronic device.
According to one of the first to fourth electronic device testing methods of the third aspect of the present application, if the size of the storage space is described in the platform descriptor; selecting the corresponding firmware code segment according to the size of the storage space, and compiling the corresponding firmware.
According to one of the first to fourth electronic device testing methods of the third aspect of the present application, if the version of the firmware is described in the platform descriptor, the version described by the platform descriptor is marked in the compiled firmware.
According to one of the first to fourth electronic device testing methods of the third aspect of the present application, if the enabled condition of the storage device characteristic is described in the platform descriptor, the compiled firmware has the enabled characteristic; and wherein the received test equipment generated storage command is a test enable feature storage command.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings.
FIG. 1 illustrates a block diagram of a prior art storage device;
FIG. 2 is a schematic diagram of testing a memory device according to an embodiment of the present application;
FIG. 3 illustrates a flow diagram for testing a software test storage device according to an embodiment of the present application;
FIG. 4 illustrates a flow diagram for testing a software test storage device according to yet another embodiment of the present application;
FIG. 5 is a schematic diagram of testing a memory device according to another embodiment of the present application;
FIG. 6 is a schematic diagram of test software sending test commands to a test agent according to an embodiment of the present application;
FIG. 7 illustrates a flow diagram of a test agent processing a test command according to an embodiment of the application;
FIG. 8 is a schematic diagram of testing a memory device according to yet another embodiment of the present application;
FIG. 9 illustrates a flow diagram for testing a memory device according to the embodiment of FIG. 8 of the present application.
Detailed Description
The technical solutions in the embodiments of the present application are clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
FIG. 2 is a schematic diagram of testing a memory device according to an embodiment of the present application.
Referring to fig. 2, the firmware 214 of the storage device 210 is coupled to the storage interface 211 (e.g., NVMe interface) and processes storage commands received from the storage interface 211. Firmware 214 also accesses platform descriptor space 213 to obtain or update platform descriptors. The storage device 210 also includes a test agent 215. For example, the test agent 215 is part of the control unit of the storage device 210, or the test agent 215 is provided by a program run by the CPU of the control unit.
The test agent 215 causes the storage device 210 to provide a test interface 212 for receiving a test command provided by the test software, and based on the test command, obtains part or all of the platform descriptor from the platform descriptor space 213 and provides it to the test program.
According to an embodiment of the application, the storage device 210 provides two access interfaces to the outside. One access interface, referred to as storage interface 211, is for coupling to a host and receiving commands provided by the host for accessing storage functions of the storage device 210. For example, an interface supporting storage protocols such as NVMe, SATA, etc. Another access interface, referred to as a test interface 212, is used to couple to the test equipment 220 and provide the test equipment 220 with the description information of the storage device 210. The test interface 212 follows, for example, a KV (key-value) interface.
In the example of FIG. 2, the test device 220 is the same computer or server as the host computer accessing the storage device 210. And the storage interface 211 and the test interface 212 are carried by the same physical link, e.g., both are carried by a PCIe link. It will be appreciated that the test interface 212 and the storage interface 211 may use the same PCIe link, or separate PCIe links. Still alternatively, the test interface 212 uses one PCIe port of the storage device 210 and the storage interface 211 uses another PCIe port of the storage device 210.
Test software is run on the test equipment 220. In some cases, the test software is compiled executable code and is run by the test equipment 220. In still other cases, the test software is a test script that the test equipment 220 interprets for execution. By running the test software, the test device 220 generates test commands that are sent to the storage device 210 through the test interface 212 and storage commands that are sent to the storage device 210 through the storage interface 211.
A platform descriptor space 213 is maintained in storage device 210. For example, recording the platform descriptor in the memory of the control unit of the storage device 210. The storage space in which the platform descriptor is recorded is referred to as a platform descriptor space 213. The platform descriptor records the version of the current version of the storage device (including hardware and firmware), supported features, configuration, and other information. By way of example, the supported characteristics of the storage device include, for example, dual port, multiple namespaces, QoS, etc., and the configuration of the storage device includes storage space capacity, number of NVM chips, memory size, log area storage location, etc.
According to embodiments of the present application, the platform descriptor is used by both the firmware 214 and the test agent 215. Since the same platform descriptor is used by both firmware 214 and test agent 215, it is ensured that the characteristics of storage device 210 known by the test software are consistent with the characteristics of storage device 210 provided by firmware 214, thereby ensuring efficient performance of the testing process. For example, firmware 214 of storage device 210 initializes to know the size of the storage space that storage device 210 presents to the user, e.g., 1 TB. The firmware 214 obtains the size of the storage space presented to the user by the storage device 210 through the platform descriptor, and the testing software also obtains the size of the storage space from the platform descriptor, so that the testing software only generates the storage device access command for accessing the range of 0-1TB to test the storage device 210, thereby avoiding the error introduced by accessing the storage space larger than 1TB by the testing software.
Optionally, the testing agent 215 also updates the platform descriptor in response to a test command provided by the testing software.
In one embodiment, firmware 214 of storage device 210 also sets the platform descriptor. For example, an indication of the test method of the storage device 210 is set in the platform descriptor. For example, firmware 214 causes storage device 210 to provide 32 namespaces, firmware 214 further indicates that during the testing process, storage commands are sent to each namespace in turn, and then to each namespace simultaneously. In the test implementation process, the test software acquires the test method indicated by the firmware 214 from the platform descriptor through the test agent 215, generates 2 test cases according to the acquired test method, and executes the test cases, wherein the 1 st test case sends a storage command to each namespace in turn, and the 2 nd test case sends a storage command to each namespace simultaneously.
FIG. 3 illustrates a flow diagram for testing a software test storage device according to an embodiment of the present application.
According to the embodiment of the application, in order to test the storage device, the test software firstly obtains a platform descriptor (310) of the storage device through the test interface, and configuration information of the storage device firmware is recorded in the platform descriptor. The test software generates a storage command for testing the storage device according to the acquired platform descriptor, and sends the generated storage command to the storage device through the storage interface (320). By way of example, the test software knows the storage space size of the storage device from the retrieved platform descriptors and generates storage commands that are within (or outside) the storage space of the storage device for testing purposes.
The storage device processes the storage command sent by the test software and received from the storage interface according to the storage space size of the storage device obtained from the platform descriptor, and provides the processing result of the storage command to the test software through the storage interface (330).
The test software and the storage device firmware access the same platform descriptor to obtain the required information (such as the storage space size), and the inconsistency of the test software and the storage device firmware is avoided.
It should be noted that the test software obtains the size of the storage space through the platform descriptor, and may still generate a storage command for accessing the storage device outside the storage space, so as to test whether the response of the storage device firmware to such abnormal conditions meets the design requirements.
FIG. 4 illustrates a flow diagram for testing a software test storage device according to yet another embodiment of the present application.
According to the embodiment shown in fig. 4, in the process of testing the storage device by the testing software, the platform descriptor is modified, so that the characteristics of the storage device are changed, and the testing software also tests the storage device with the changed characteristics. Therefore, the inconvenience of installing different versions of firmware in the storage device and testing the different versions of firmware respectively is avoided.
According to the embodiment shown in fig. 4, in order for the testing software to test the storage device, the platform descriptor of the storage device is first obtained through the testing interface (410). The test software generates a storage command for testing the storage device according to the acquired platform descriptor, and sends the generated storage command to the storage device through the storage interface (420). In response to the received storage command, the storage device processes the storage command received from the storage interface and sent by the test software according to the size of the storage space of the storage device obtained from the platform descriptor, and provides the result of processing the storage command to the test software through the storage interface (430). And the test software identifies whether the storage equipment works normally or not according to the processing result of the storage command and the storage command sent to the storage equipment before.
Alternatively or additionally, the test software issues a test command to the test interface instructing some or all of the platform descriptors to be modified (440). The test agent receives the test command and updates the platform descriptor space according to the test command. Optionally, the test agent also generates a restart command to instruct the control component to restart to validate, for example, the updated platform descriptor. Still alternatively, the firmware generates the reboot command in response to the platform descriptor being updated.
For example, the size of the storage space provided by the storage device indicated by the platform descriptor is modified by the test command. As yet another example, a storage device is modified from supporting multiple command spaces to not supporting multiple namespaces.
Optionally, the firmware to be updated is also provided to the storage device by the test agent, for example, the firmware to be updated is written to a designated area of the NVM chip of the storage device, and the storage device is caused to run the updated firmware.
Because the test software indicates the updating of the platform descriptor, the test software knows the storage device characteristics corresponding to the updated platform descriptor. The test software generates a storage command from the modified platform descriptor and sends the storage command to the storage device through the storage interface (450).
In response to the received storage command, the storage device processes the storage command received from the storage interface and sent by the test software according to the storage device characteristics obtained from the updated platform descriptor, and stores the test software provided by the result of the processing of the command through the storage interface (460). And the test software identifies whether the storage equipment works normally or not according to the processing result of the storage command and the storage command sent to the storage equipment before.
FIG. 5 is a schematic diagram of testing a memory device according to another embodiment of the present application.
According to an embodiment of the present application, the storage device 510 provides the storage interface 511 and the test interface 512 to the outside.
A platform descriptor space 513 is maintained in the storage 510, in which platform descriptors are recorded.
The control components of the storage device 510 also include a plurality of CPUs and a test agent 515. Firmware runs on each CPU and firmware 514 runs on CPU 1. Optionally, the test agent 515 is also provided by the CPU running a sequence of instructions.
The platform descriptor is used by both the firmware 514 and the test agent 515. Since the same platform descriptor is used by both the firmware 514 and the test agent 515, it is ensured that the characteristics of the storage device 510 known by the test device 520 are consistent with the characteristics of the storage device 510 provided by the firmware 514, thereby ensuring efficient performance of the test procedure.
Referring to fig. 5, the firmware 514 executed by the CPU1 is coupled to the storage interface 511 (e.g., NVMe interface) and processes storage commands received from the storage interface 511. Firmware 514 also accesses platform descriptor space 513 to obtain or update platform descriptors.
The test agent 515 causes the storage device 510 to provide a test interface 512 for receiving a test command provided by the test device 520, and based on the test command, obtains part or all of the platform descriptor from the platform descriptor space 513 and provides it to the test device 520.
One or more CPUs (e.g., CPU 2 and CPU 3) of the control unit have local parameters. The local parameters of CPU 2 are used only by CPU 2 and the local parameters of CPU 3 are used only by CPU 3. In some cases, the test software wishes to modify the local parameters of the CPU. For example, the CPU 2 performs an error correction function on data. The test software verifies that the error correction function is functioning, and thus it is necessary to cause the CPU 2 to acquire data in which an error exists. Generally, the error of data in the memory is a small probability event, and the test software needs to artificially modify the data into error data to verify the correctness of the error correction function. To this end, the test software sends test commands to the test agent 515 through the test interface 512. The target CPU, the target local parameters, and the new values of the local parameters are indicated in the test command.
The test agent 515 sends a message to the target CPU instructing the target CPU to update the target local parameters to new values in response to receiving the test command. The target CPU updates the target local parameter to a new value in response to the fetch message. The target CPU continues to run the firmware 514 using the updated local parameters. Alternatively, the test command indicates other meanings. For example, the test command instructs the target CPU to perform a specified modification on the number indicated by the local parameter to obtain error data before performing error correction on the number.
Optionally, the target CPU also informs the test agent 515 that the target local parameter update was successful. The test agent 515 informs the test software that the target local parameter update of the target CPU was successful. The test software is thus able to send storage commands or test commands to the storage device 510 according to the updated target local parameters of the target CPU.
FIG. 6 is a schematic diagram of test software sending a test command to a test agent according to an embodiment of the application.
By way of example, the target CPU (node ID), operation code (cPCode), return value size (retSize), and one or more parameters (param0) are indicated in the test command. According to the test command, the test agent also sends the processing result (return value) of the test command to the test software. The return values of the test commands may have different sizes, and in a case where the size of a packet (e.g., TLP of PCIe protocol) carried on a link of the test interface is limited, a plurality of packets (Ret 0, Ret 1, Ret 2) jointly form a complete return value.
The test agent also provides test agent status to the test software to synchronize the various phases of sending test commands (and receiving return values) between the test software and the test agent. Referring to FIG. 6, the test software indicates to the test agent that a test command is to be initiated by sending a reset packet. In response to receiving the reset packet, the test agent cancels all test commands that have not been processed and sets the test agent status to "not ready". The test software can obtain the test agent status.
Next, the test software sends the target cpu (node id), the operation code (cpCode), the return value size (retSize) and one or more parameters (param0) in the test command to the test agent. Next, the test software also sends a "submit" packet to the test agent to indicate that the test command transmission is complete, and the test agent may begin processing the test command. After the test agent completes processing the test command, the test agent state is set to "ready". After the test agent status is acquired as 'ready' periodically or aperiodically, the test software acquires one or more return values provided by the test software for the test command from the test agent. Because the test software knows the return value size specified in the test command, the test software obtains a specified number of return values from the test agent according to the return value size.
With continued reference to FIG. 6, by way of example, each row in FIG. 6 represents a designated register or a designated memory space provided by the test agent through the test interface. For example, the test agent provides the start address A1 in memory space for receiving the reset and commit packets sent by the test software, which writes the reset or commit packets to the start address A1 of the memory space. The test agent provides a start address a2 in the memory space for receiving a test command packet (target cpu (node id), an operation code (cpCode), a return size (retSize), one or more parameters (param0), and the like) sent by the test software, and the test software writes the test command packet to the start address a2 of the memory space. Test agent provides memory space starting address A3 for indicating test agent status, and test agent writes test agent status to memory space starting address A3 for test software to read.
FIG. 7 shows a flow diagram of a test agent processing a test command according to an embodiment of the application.
The test agent begins to prepare to receive test commands and sets the test agent status to "not ready" (710) in response to receiving a "reset" packet provided by the test software. The test software may begin transmitting test commands to the test agent upon the test agent being in a "not ready" state, or may begin transmitting test commands randomly after sending a "reset" packet without checking the test agent state.
The test agent receives the first packet in the test command provided by the test software as an indication to the target CPU (node ID) (720). The test agent receives 730 a second packet of data in the test command provided by the test software as an indication operation code (cpCode). The test agent receives 740 the third packet in the test command provided by the test software as an indication of the return value size (retSize).
The test agent receives subsequent further data packets (750) in the test command provided by the test software as one or more parameters (param0) of the test command. Optionally, the test agent limits the number of test command parameters received (760), e.g., limits the test command parameters to no more than 16 packets. For packets received that exceed a specified threshold number, the test agent indicates that an erroneous test command was received and denies receipt (770).
The test agent knows that the receipt of a test command is complete in response to receiving a "submit" packet provided by the test software and begins processing the test command 780. For example, the test command is transmitted to a target CPU (nodeid) indicated by the test command, and the execution result of the test command is received from the target CPU. The test agent sets the test agent status to "ready" (790) in response to receiving the execution result of the test command provided by the target CPU.
The test software begins reading the processing results of the test commands from the test agent, depending on the test agent being in a "ready" state. The test software reads a specified number of packets according to the return value size (retSize) of the test command to obtain a processing result (711), and outputs the packets (712). Optionally, if the number of packets read by the test software exceeds the return size (retSize), the test agent may refuse to provide the test software with data exceeding the return size (retSize) (713).
FIG. 8 is a schematic diagram of testing a memory device according to yet another embodiment of the present application.
According to the embodiment shown in fig. 8, the platform descriptor is described in a platform descriptor file 810. The platform descriptor records the version of the current version of the storage device (including hardware and firmware), supported features, configuration, and other information. Compiler 830 compiles firmware code 820 to generate firmware 840. And the script engine 850 runs the test software described by the test software 860 to implement the test process.
Firmware code 820 references the platform descriptor to obtain the configuration information for the storage device being operated. For example, the firmware code 820 obtains the size of the storage space of the storage device described in the platform descriptor and selects a corresponding code segment according to the size of the storage space. For example, the size of the memory space is used as a basis for determining whether the branch condition is satisfied in the branch condition of the firmware code 820. In yet another example, compiler 830 references a platform descriptor to obtain a version of firmware 840 to be generated and marks the obtained version in generated firmware 840.
As another example, firmware code 820 references a platform descriptor to determine whether one or more storage device characteristics are enabled. For example, the storage device firmware 820 may support the feature F1, the feature F2, and the feature F3, and specify in the platform descriptor that the feature F1 and the feature F2 are enabled and the feature F3 is not enabled. The compiler 830 generates the firmware 840 from the firmware code 820 according to the platform descriptor, and includes the executable program segments corresponding to the property F1 and the property F2 in the generated firmware 840, but does not include the executable program segment corresponding to the property F3.
The test software also uses the platform descriptor according to embodiments of the present application. So that the test software gets the same configuration information of the storage device as the firmware code 820 or compiler 830 sees. So that the test software can perform the test procedure according to the configuration of the storage device. For example, the platform descriptor indicates the size of the storage space of the storage device, and the storage commands generated by the test software for testing access the inside and/or outside of the storage space according to the test purpose. As another example, the test software 860 generates a storage command for testing the features F1 and F2 according to the platform descriptor indicating that the features F1 and F2 are enabled, and avoids generating a storage command for testing the un-enabled features F3, so as to ensure that the testing process is performed smoothly.
In yet another embodiment, an indication of a method of testing a storage device is described in a platform descriptor. For example, the storage device provides 32 namespaces, and the platform descriptor indicates that the storage command is to be sent to each namespace in turn and then sent to each namespace simultaneously during the test. In the test implementation process, the test software 860 is run by the script engine 850 to obtain the test method from the platform descriptor, and according to the obtained test method, 2 test cases are generated and executed, a storage command is sent to each namespace in turn in the 1 st test case, and a storage command is sent to each namespace in the 2 nd test case.
FIG. 9 illustrates a flow diagram for testing a memory device according to the embodiment of FIG. 8 of the present application.
According to the embodiment of fig. 9, the compiler uses the platform descriptor to compile the firmware code into firmware as an executable program (910).
The test software also references the platform descriptor. The configuration information of the storage device recorded in the platform descriptor is acquired by executing the test software by the script engine to generate the storage command. And sending the generated storage command to the storage device (920) through the storage interface. The firmware of the storage device processes the received storage command using configuration information derived from the platform descriptor during compilation. And transmits the processing result of the storage command to the test software through the storage interface (930). The test software tests the storage device according to whether the issued storage command is consistent with the execution result received from the storage device.
In an alternative embodiment, the compiled firmware also maintains the platform descriptor inside the storage device when it is run. The storage device also includes a test agent, and a test interface. When the storage device runs, the test software sends a test command to the test agent through the test interface to instruct the test agent to access (acquire and/or modify) the platform descriptor maintained inside the storage device, so that the platform descriptor is updated when the storage device runs, and the storage command for testing the storage device is generated according to the updated platform descriptor. Still optionally, whether the test agent and test interface are enabled is also a storage device characteristic indicated in the platform descriptor. The compiler generates firmware with or without a test agent as directed by the platform descriptor. And the test software knows whether the currently tested storage device is provided with a test agent, whether the test command can be accepted, and/or which test command can be accepted according to the indication of the platform descriptor.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application. It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.
Claims (10)
1. A storage device, comprising: a storage interface, a test agent, a platform descriptor, and firmware; the test agent receives a test command of the test equipment through the test interface, acquires a platform descriptor according to the test command, and provides the platform descriptor to the test equipment through the test interface; the firmware receives a storage command generated by the test equipment according to the platform descriptor through the storage interface, processes the storage command according to the platform descriptor to obtain a processing result, and provides the processing result to the test equipment through the storage interface.
2. An electronic device testing method, comprising the steps of:
the electronic equipment receives a test command of the test equipment, acquires a platform descriptor according to the test command and provides the platform descriptor for the test equipment;
the test equipment generates a storage command according to the platform descriptor and sends the storage command to the electronic equipment;
the electronic equipment processes the storage command according to the platform descriptor to obtain a processing result, and provides the processing result to the testing equipment.
3. The electronic device testing method of claim 2, wherein the platform descriptor records a version of the electronic device hardware/firmware, a feature supported by the electronic device, or configuration information of the electronic device.
4. The electronic device testing method according to claim 2, wherein the platform descriptor records a testing method for the electronic device, and the testing device generates the storage command according to the testing method set in the platform descriptor.
5. The electronic device testing method according to one of claims 2 to 4, further comprising:
the electronic equipment receives a test command of the test equipment for indicating to modify the platform descriptor, and updates the platform descriptor according to the test command;
the test equipment generates a storage command according to the updated platform descriptor and sends the storage command to the electronic equipment;
and the electronic equipment processes the storage command according to the updated platform descriptor to obtain a processing result, and provides the processing result for the test equipment.
6. The electronic device testing method according to one of claims 2 to 4, further comprising:
the electronic equipment receives a test command sent by the test equipment, sends a message to a target CPU with local parameters according to the test command to instruct the target CPU to modify the local parameters, and sends a processing result to the test equipment.
7. An electronic device testing method, comprising:
compiling the firmware code into firmware of the electronic device using the platform descriptor;
the electronic equipment receives a storage command generated by the testing equipment according to the platform descriptor, processes the storage command by using the platform descriptor in the firmware to obtain a processing result, and provides the processing result for the testing equipment.
8. The electronic device testing method of claim 7, wherein the electronic device receives a test command sent by the testing device, the test command instructing the electronic device to access a platform descriptor maintained therein.
9. The electronic device testing method of claim 8, wherein the platform descriptor records whether a testing agent is generated, whether a testing agent is enabled, and/or whether a testing interface is enabled.
10. The electronic device testing method of claim 8, wherein if the enablement of the storage device feature is described in the platform descriptor, the compiled firmware has the enabled feature; and wherein the received test equipment generated storage command is a test enable feature storage command.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810630006.5A CN110618903A (en) | 2018-06-19 | 2018-06-19 | Electronic equipment testing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810630006.5A CN110618903A (en) | 2018-06-19 | 2018-06-19 | Electronic equipment testing method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110618903A true CN110618903A (en) | 2019-12-27 |
Family
ID=68920348
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810630006.5A Pending CN110618903A (en) | 2018-06-19 | 2018-06-19 | Electronic equipment testing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110618903A (en) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113468083A (en) * | 2021-07-02 | 2021-10-01 | 成都忆芯科技有限公司 | Dual-port NVMe controller and control method |
| CN113933627A (en) * | 2021-10-08 | 2022-01-14 | 网易有道信息技术（北京）有限公司 | Method for automatically testing and verifying electronic product and related product |
| JP2022115768A (en) * | 2020-03-31 | 2022-08-09 | 株式会社アドバンテスト | Enhanced auxiliary interface test systems and methods |
| US11493551B2 (en) | 2020-06-22 | 2022-11-08 | Advantest Test Solutions, Inc. | Integrated test cell using active thermal interposer (ATI) with parallel socket actuation |
| US11549981B2 (en) | 2020-10-01 | 2023-01-10 | Advantest Test Solutions, Inc. | Thermal solution for massively parallel testing |
| US11573262B2 (en) | 2020-12-31 | 2023-02-07 | Advantest Test Solutions, Inc. | Multi-input multi-zone thermal control for device testing |
| US11587640B2 (en) | 2021-03-08 | 2023-02-21 | Advantest Test Solutions, Inc. | Carrier based high volume system level testing of devices with pop structures |
| US11609266B2 (en) | 2020-12-04 | 2023-03-21 | Advantest Test Solutions, Inc. | Active thermal interposer device |
| US11650893B2 (en) | 2020-03-31 | 2023-05-16 | Advantest Corporation | Multiple name space test systems and methods |
| US11656273B1 (en) | 2021-11-05 | 2023-05-23 | Advantest Test Solutions, Inc. | High current device testing apparatus and systems |
| US11674999B2 (en) | 2020-11-19 | 2023-06-13 | Advantest Test Solutions, Inc. | Wafer scale active thermal interposer for device testing |
| US11733290B2 (en) | 2020-03-31 | 2023-08-22 | Advantest Corporation | Flexible sideband support systems and methods |
| US11808812B2 (en) | 2020-11-02 | 2023-11-07 | Advantest Test Solutions, Inc. | Passive carrier-based device delivery for slot-based high-volume semiconductor test system |
| US11821913B2 (en) | 2020-11-02 | 2023-11-21 | Advantest Test Solutions, Inc. | Shielded socket and carrier for high-volume test of semiconductor devices |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0009896D0 (en) * | 1999-05-18 | 2000-06-07 | Dell Usa Lp | A method of installing software on and/or testing a computer system |
| CN101145127A (en) * | 2006-09-12 | 2008-03-19 | 中兴通讯股份有限公司 | Software test automated system based on apparatus and the method |
| US20090055560A1 (en) * | 2007-08-22 | 2009-02-26 | Mimaki Engineering Co., Ltd. | Data transfer apparatus, method for manufacturing the data transfer apparatus, method for conducting connection test, and method for testing connection in the data transfer apparatus |
| US20090187366A1 (en) * | 2008-01-23 | 2009-07-23 | International Business Machines Corporation | Test apparatus and methods thereof |
| CN101789002A (en) * | 2010-01-22 | 2010-07-28 | 浪潮(北京)电子信息产业有限公司 | Database compatibility test device and method for server |
| US20120084759A1 (en) * | 2010-10-01 | 2012-04-05 | George Candea | System and method for in-vivo multi-path analysis of binary software |
| US20170220454A1 (en) * | 2016-01-29 | 2017-08-03 | Fujitsu Limited | Test device, network system, and test method |
| US20170329688A1 (en) * | 2016-05-11 | 2017-11-16 | International Business Machines Corporation | Replicating test code and test data into a cache with non-naturally aligned data boundaries |
| CN107544923A (en) * | 2016-06-28 | 2018-01-05 | Arm 有限公司 | For controlling to device of access of memory devices and associated method |
| CN107894952A (en) * | 2017-11-08 | 2018-04-10 | 中国平安人寿保险股份有限公司 | Generation method, device, equipment and the readable storage medium storing program for executing of interface testing use-case |
| CN107943635A (en) * | 2017-11-30 | 2018-04-20 | 郑州云海信息技术有限公司 | A kind of test method of storage device, device and medium |
-
2018
- 2018-06-19 CN CN201810630006.5A patent/CN110618903A/en active Pending
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0009896D0 (en) * | 1999-05-18 | 2000-06-07 | Dell Usa Lp | A method of installing software on and/or testing a computer system |
| CN101145127A (en) * | 2006-09-12 | 2008-03-19 | 中兴通讯股份有限公司 | Software test automated system based on apparatus and the method |
| US20090055560A1 (en) * | 2007-08-22 | 2009-02-26 | Mimaki Engineering Co., Ltd. | Data transfer apparatus, method for manufacturing the data transfer apparatus, method for conducting connection test, and method for testing connection in the data transfer apparatus |
| US20090187366A1 (en) * | 2008-01-23 | 2009-07-23 | International Business Machines Corporation | Test apparatus and methods thereof |
| CN101789002A (en) * | 2010-01-22 | 2010-07-28 | 浪潮(北京)电子信息产业有限公司 | Database compatibility test device and method for server |
| US20120084759A1 (en) * | 2010-10-01 | 2012-04-05 | George Candea | System and method for in-vivo multi-path analysis of binary software |
| US20170220454A1 (en) * | 2016-01-29 | 2017-08-03 | Fujitsu Limited | Test device, network system, and test method |
| US20170329688A1 (en) * | 2016-05-11 | 2017-11-16 | International Business Machines Corporation | Replicating test code and test data into a cache with non-naturally aligned data boundaries |
| CN107544923A (en) * | 2016-06-28 | 2018-01-05 | Arm 有限公司 | For controlling to device of access of memory devices and associated method |
| CN107894952A (en) * | 2017-11-08 | 2018-04-10 | 中国平安人寿保险股份有限公司 | Generation method, device, equipment and the readable storage medium storing program for executing of interface testing use-case |
| CN107943635A (en) * | 2017-11-30 | 2018-04-20 | 郑州云海信息技术有限公司 | A kind of test method of storage device, device and medium |
Non-Patent Citations (1)
| Title |
|---|
| 凌明胜;汪文娟;: "软件测试过程中风险的识别与预防方法", 信息化研究, no. 06, 20 December 2017 (2017-12-20) * |
Cited By (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11650893B2 (en) | 2020-03-31 | 2023-05-16 | Advantest Corporation | Multiple name space test systems and methods |
| JP2022115768A (en) * | 2020-03-31 | 2022-08-09 | 株式会社アドバンテスト | Enhanced auxiliary interface test systems and methods |
| TWI777405B (en) * | 2020-03-31 | 2022-09-11 | 日商愛德萬測試股份有限公司 | Enhanced auxiliary interface test systems and methods |
| JP7157197B2 (en) | 2020-03-31 | 2022-10-19 | 株式会社アドバンテスト | Enhanced Auxiliary Interface Test System and Method |
| US11733290B2 (en) | 2020-03-31 | 2023-08-22 | Advantest Corporation | Flexible sideband support systems and methods |
| US11493551B2 (en) | 2020-06-22 | 2022-11-08 | Advantest Test Solutions, Inc. | Integrated test cell using active thermal interposer (ATI) with parallel socket actuation |
| US11841392B2 (en) | 2020-06-22 | 2023-12-12 | Advantest Test Solutiions, Inc. | Integrated test cell using active thermal interposer (ATI) with parallel socket actuation |
| US11940487B2 (en) | 2020-10-01 | 2024-03-26 | Advantest Test Solutions, Inc. | Thermal solution for massively parallel testing |
| US11549981B2 (en) | 2020-10-01 | 2023-01-10 | Advantest Test Solutions, Inc. | Thermal solution for massively parallel testing |
| US11821913B2 (en) | 2020-11-02 | 2023-11-21 | Advantest Test Solutions, Inc. | Shielded socket and carrier for high-volume test of semiconductor devices |
| US11808812B2 (en) | 2020-11-02 | 2023-11-07 | Advantest Test Solutions, Inc. | Passive carrier-based device delivery for slot-based high-volume semiconductor test system |
| US11674999B2 (en) | 2020-11-19 | 2023-06-13 | Advantest Test Solutions, Inc. | Wafer scale active thermal interposer for device testing |
| US11774492B2 (en) | 2020-12-04 | 2023-10-03 | Advantest Test Solutions, Inc. | Test system including active thermal interposer device |
| US11846669B2 (en) | 2020-12-04 | 2023-12-19 | Advantest Test Solutions, Inc. | Active thermal interposer device |
| US11609266B2 (en) | 2020-12-04 | 2023-03-21 | Advantest Test Solutions, Inc. | Active thermal interposer device |
| US11754620B2 (en) | 2020-12-04 | 2023-09-12 | Advantest Test Solutions, Inc. | DUT placement and handling for active thermal interposer device |
| US11573262B2 (en) | 2020-12-31 | 2023-02-07 | Advantest Test Solutions, Inc. | Multi-input multi-zone thermal control for device testing |
| US11852678B2 (en) | 2020-12-31 | 2023-12-26 | Advantest Test Solutions, Inc. | Multi-input multi-zone thermal control for device testing |
| US11742055B2 (en) | 2021-03-08 | 2023-08-29 | Advantest Test Solutions, Inc. | Carrier based high volume system level testing of devices with pop structures |
| US11587640B2 (en) | 2021-03-08 | 2023-02-21 | Advantest Test Solutions, Inc. | Carrier based high volume system level testing of devices with pop structures |
| CN113468083A (en) * | 2021-07-02 | 2021-10-01 | 成都忆芯科技有限公司 | Dual-port NVMe controller and control method |
| CN113468083B (en) * | 2021-07-02 | 2024-01-26 | 成都忆芯科技有限公司 | Dual-port NVMe controller and control method |
| CN113933627A (en) * | 2021-10-08 | 2022-01-14 | 网易有道信息技术（北京）有限公司 | Method for automatically testing and verifying electronic product and related product |
| US11656273B1 (en) | 2021-11-05 | 2023-05-23 | Advantest Test Solutions, Inc. | High current device testing apparatus and systems |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110618903A (en) | Electronic equipment testing method and device | |
| US10120694B2 (en) | Embedded system boot from a storage device | |
| CN107766236B (en) | Test task automatic management method, device, equipment and storage medium | |
| CN102541469A (en) | Method, equipment and system for protecting data in firmware storage system | |
| US20240020256A1 (en) | Component firmware interaction using hardware registers | |
| US9934120B2 (en) | Method and apparatus for updating a system on chip (SOC) image from a host computer system without using DMA | |
| US20140032967A1 (en) | Sas self-test operations | |
| CN107273249B (en) | Mainboard test method, processor and mainboard test system | |
| CN108694052B (en) | Firmware upgrading method, firmware upgrading device and firmware upgrading system | |
| US7725806B2 (en) | Method and infrastructure for recognition of the resources of a defective hardware unit | |
| CN111176757B (en) | SoC starting method and device based on JTAG | |
| CN111666102A (en) | File format conversion method, chip verification method, related device and network chip | |
| KR20180110482A (en) | System and method for testing memory | |
| CN109491951B (en) | Data configuration method and computing equipment | |
| US9934045B1 (en) | Embedded system boot from a storage device | |
| US7168029B2 (en) | Method for testing a universal serial bus host controller | |
| CN107908418B (en) | Method for upgrading logic program of fiber channel node card and fiber channel bus equipment | |
| CN113535578B (en) | CTS test method, CTS test device and CTS test equipment | |
| CN104678292A (en) | Test method and device for CPLD (Complex Programmable Logic Device) | |
| US11586504B2 (en) | Electronic apparatus and boot method thereof | |
| CN115454896A (en) | SMBUS-based SSD MCTP control message verification method and device, computer equipment and storage medium | |
| CN114116337A (en) | Hard disk test method, system, terminal and storage medium based on PCIE link configuration | |
| US11269703B2 (en) | Information processing system and storage device control method to determine whether data has been correctly written into a storage device | |
| CN114328024A (en) | PCIe function level reset implementation method and device, computer equipment and storage medium | |
| CN115858256A (en) | Test method and device for Internet of things equipment and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 100192 room A302, building B-2, Dongsheng Science Park, Zhongguancun, 66 xixiaokou Road, Haidian District, Beijing Applicant after: Beijing yihengchuangyuan Technology Co.,Ltd. Address before: 100192 room A302, building B-2, Dongsheng Science Park, Zhongguancun, 66 xixiaokou Road, Haidian District, Beijing Applicant before: BEIJING MEMBLAZE TECHNOLOGY Co.,Ltd. |
|
| CB02 | Change of applicant information |