Hardware detection method, apparatus and device

Abstract

The application discloses a hardware detection method, device and equipment, and relates to the technical field of testing, and comprises the following steps: being applied to a to-be-tested electronic device which has pre-installed a main operating system, detecting a mode selection signal after the to-be-tested electronic device is powered on and started; when the mode selection signal is in a first state, starting a detection operating system pre-stored in a test storage area of the to-be-tested electronic device to enter a hardware detection mode, wherein the test storage area is a storage area isolated from a main system storage area where the main operating system is located; in the hardware detection mode, a preset hardware detection item is executed by running a detection program in the detection operating system, and a hardware detection result of the to-be-tested electronic device is acquired. The application can effectively improve the efficiency of a hardware detection process of a production line.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to hardware testing methods, hardware testing devices, and electronic devices under test. Background Technology

[0002] In the mass production of smart electronic devices, comprehensive functional testing of the hardware must be performed before shipment to ensure the quality of the delivered products. Current testing processes rely on the commercial operating system pre-installed in the smart electronic devices. After the operating system is fully booted, it calls the testing programs running on it to perform hardware testing.

[0003] However, the boot processes of different commercial operating systems vary significantly, with varying boot times and a generally long overall time consumption. Each smart electronic device on the production line must wait for the commercial operating system to fully boot before entering the testing process. This waiting time directly accumulates into a fixed component of the testing cycle for each machine (i.e., each smart electronic device) on the production line. When mass production reaches tens or even hundreds of thousands of units, this severely restricts the hourly output rate of the production line. Furthermore, the hardware access interfaces and application programming interfaces of different commercial operating systems are incompatible. Testing programs developed for one commercial operating system cannot be ported to other commercial operating systems, requiring testing programs to be developed independently for each commercial operating system. This significantly increases the workload and R&D investment required for new product mass production.

[0004] The above factors together result in low hardware testing efficiency for smart electronic devices on existing production lines. Summary of the Invention

[0005] The main objective of this application is to provide a hardware testing method, a hardware testing device, and an electronic device under test, aiming to solve the technical problem of low efficiency in existing hardware testing for smart electronic devices.

[0006] To achieve the above objectives, this application proposes a hardware testing method applied to an electronic device pre-installed with a host operating system. The hardware testing method includes: After the electronic device under test is powered on, the detection mode selection signal is activated. When the mode selection signal is in the first state, the preset detection operating system in the test storage area of ​​the electronic device under test is started to enter the hardware detection mode. The test storage area is a storage area in the electronic device under test that is isolated from the main system storage area where the main operating system is located. In the hardware testing mode, the testing program in the testing operating system is run to execute preset hardware testing items and obtain the hardware testing results of the electronic device under test.

[0007] In one embodiment, prior to the step of detecting the mode selection signal after the electronic device under test is powered on, the method includes: In the electronic device under test, a test storage area is defined that is physically isolated from the main system storage area; The pre-written detection operating system containing the detection program is burned into the test storage area.

[0008] In one embodiment, after the step of obtaining the hardware test results of the electronic device under test, the following steps are included: If the hardware test results indicate that all hardware test items have passed, in response to a reset command, a data erasure operation is performed on the test storage area to clear the test operating system and the test program in the test storage area.

[0009] In one embodiment, after the step of performing a data erasure operation on the test storage area, the method further includes: Configure the bootloader of the electronic device under test to disable the boot path of the test storage area.

[0010] In one embodiment, after the step of detecting the mode selection signal after the electronic device under test is powered on, the method further includes: If the mode selection signal is not received or if the mode selection signal is in the second state, the main operating system in the main system storage area is started.

[0011] In one embodiment, the detected operating system is an operating system obtained by trimming an initial Linux kernel-based operating system using a preset trimming method, wherein the trimming method retains only the hardware device drivers and peripheral control programs of the initial operating system.

[0012] In one embodiment, prior to the step of activating the test operating system preset in the test storage area of ​​the electronic device under test, the method further includes: Calculate the integrity check value of the image file of the operating system being tested in the test storage area; When the integrity check value is equal to the preset check value, the step of starting the preset detection operating system in the test storage area of ​​the electronic device under test is executed; When the integrity check value is not equal to the preset check value, an error message is output, and a new detection operating system is burned to the test storage area.

[0013] In one embodiment, after the step of detecting the mode selection signal after the electronic device under test is powered on, the method further includes: When the electronic device under test establishes a network connection with the production line server and the mode selection signal is in the first state, the image file of the testing operating system and the testing program are downloaded online from the production line server. By running the detection program in the detection operating system, preset hardware detection items are executed, and the hardware detection results of the electronic device under test are obtained. When the electronic device under test is powered off, the downloaded image file of the detection operating system and the detection program are automatically cleared.

[0014] Furthermore, to achieve the above objectives, this application also proposes a hardware testing device for use in an electronic device to be tested that has a pre-installed main operating system. The hardware testing device includes: The signal detection module is used to detect the mode selection signal after the electronic device under test is powered on. The startup control module is used to start the preset detection operating system in the test storage area of ​​the electronic device under test when the mode selection signal is in the first state, so as to enter the hardware detection mode. The test storage area is a storage area in the electronic device under test that is isolated from the main system storage area where the main operating system is located. The hardware testing module is used to execute preset hardware testing items and obtain the hardware testing results of the electronic device under test by running the testing program in the testing operating system in the hardware testing mode.

[0015] In addition, to achieve the above objectives, this application also proposes an electronic device under test, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the hardware testing method described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the hardware detection method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the hardware detection method described above.

[0018] One or more technical solutions proposed in this application have at least the following technical effects: This application establishes a test storage area isolated from the main system storage area in the electronic device under test (DUT), and pre-installs an independent testing operating system within this test storage area. It also introduces a mode selection signal detection mechanism, allowing the DUT to prioritize starting the testing operating system in the test storage area to enter hardware testing mode upon power-on, based on the state of the mode selection signal, instead of waiting for the pre-installed commercial operating system (i.e., the main operating system) in the main system storage area to fully boot. Because this testing operating system exists independently of the main operating system, its boot process does not require loading the complete services and framework of the main operating system. Therefore, it significantly shortens the preparation time required for the device to enter a testable state, effectively reducing the time spent waiting for the system to become ready in the single-machine testing cycle of the production line, and improving the hourly output rate of the production line. Meanwhile, because the testing operating system is independent of the main operating system pre-installed in the electronic device under test, all hardware testing items are executed through the testing program within this operating system. The operation of the testing program does not depend on the hardware access interface or application programming interface of any specific main operating system. Therefore, the same testing program can be used universally for electronic devices under test equipped with different main operating systems, eliminating the need for independent development and adaptation for different main operating systems. This significantly reduces the workload and R&D investment required for mass production of new products. This solution effectively improves the efficiency of the hardware testing process on the production line. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating an embodiment of the hardware testing method of this application. Figure 1 ; Figure 2 This is a schematic diagram provided for an embodiment of the hardware testing method of this application; Figure 3 A flowchart illustrating an embodiment of the hardware testing method of this application. Figure 2 ; Figure 4 This is a schematic diagram of the module structure of the hardware testing device of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the hardware testing method of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] In the mass production of smart electronic devices, comprehensive functional testing of the hardware must be performed before shipment. This includes verifying the display panel, audio input / output, external interface connectivity, button interaction, and power consumption to ensure the hardware quality of the delivered products. Current hardware testing processes rely on the pre-installed commercial operating system (also called the pre-installed system or main operating system) in smart electronic devices—such as Google TV (Google's smart TV operating system platform), Web OS (web operating system), Tizen, and other systems with different architectures found in smart TVs. After the pre-installed system boots up, it calls a testing program running on that system to perform hardware tests.

[0026] However, the startup processes and architectures of different pre-installed systems differ significantly, resulting in varying startup times and overall longer overall times. During production line testing, each intelligent electronic device must wait for its pre-installed system to fully start before entering the testing process. This waiting time accumulates as a fixed component of the single-machine testing cycle on the production line. When mass production reaches tens or even hundreds of thousands of units, the accumulated startup waiting time severely restricts the hourly output rate of the production line, leading to low efficiency in the testing process. Furthermore, the hardware access interfaces, driver frameworks, and application programming interfaces of different pre-installed systems are incompatible. Testing programs developed for one pre-installed system cannot be directly ported to other pre-installed systems. This lack of universality necessitates the independent adaptation and implementation of production line testing software for different pre-installed systems, significantly increasing the workload and R&D investment required for new product mass production.

[0027] The above factors together result in low hardware testing efficiency for smart electronic devices on existing production lines.

[0028] This application establishes a physically isolated test storage area within the storage medium of the electronic device under test (EDT), separate from the main system storage area. A lightweight testing operating system, independent of the main operating system, is pre-installed within this test storage area. In production line testing scenarios, a hardware-triggered mode selection signal controls the bootloader of the EDT to prioritize launching this testing operating system over the main operating system. Under this testing operating system, a testing program is run, which calls hardware drivers within the testing operating system to execute hardware testing tasks. After testing is complete, a data erasure operation is performed on the test storage area in response to a reset command, allowing the EDT to automatically return to the main operating system upon the next boot. This application allows hardware testing without waiting for the main operating system to boot, and a single testing operating system and testing program can be used with EDTs pre-installed with different main operating systems, improving testing efficiency and reducing the development and adaptation costs of production line testing software.

[0029] Furthermore, it should be noted that this application uses a testing operating system independent of the main operating system to perform hardware testing. The feasibility and effectiveness of this approach lie in the fact that hardware testing essentially involves reading and writing registers of various hardware components of the electronic device under test (such as display panels, audio codecs, external interface controllers, etc.) to verify their electrical characteristics and functional properness. Hardware testing relies solely on the low-level access interfaces provided by the hardware drivers, without depending on any upper-level frameworks (such as graphical user interfaces, application frameworks, system services, etc.) in the main operating system other than the driver layer. Regardless of whether the main operating system pre-installed on the electronic device under test is Google TV, WebOS, or Tizen, these operating systems are all based on the Linux kernel, and their underlying hardware driver interfaces are unified and standardized. Therefore, this application can gain control over all hardware components of the electronic device under test by pre-installing a trimmed Linux kernel and its accompanying testing program in an independent test storage area. Hardware testing performed under this testing operating system accesses the exact same hardware registers and executes the exact same driver layer instructions at the physical level as hardware testing performed under the main operating system. The only difference is that this application bypasses the large and slow-starting upper-level framework of the main operating system, completing the testing directly at the driver layer. Therefore, the difference between the detection operating system and the main operating system does not affect the validity of the hardware detection. This application tests the electrical characteristics and functional integrity of the physical hardware, not the software functions of the main operating system.

[0030] It should be noted that the execution subject of this embodiment can be the electronic device under test (also called an electronic device), such as a smart TV, smart set-top box, smart projector, in-vehicle central control display terminal, etc., which have a main operating system and require hardware testing in the production line stage; it can also be a computing service device with data processing, network communication, and program running functions, such as a tablet computer, personal computer, mobile phone, etc., or a testing device or control device capable of realizing the above functions. The following uses an electronic device as an example to describe this embodiment and the following embodiments.

[0031] Based on this, embodiments of this application provide a hardware detection method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the hardware testing method of this application.

[0032] In one feasible embodiment, the application scenario of the technical solution of this application can be the mass production manufacturing process of electronic devices such as smart TVs, smart set-top boxes, smart projectors, and in-vehicle central control display terminals that have a main operating system and require hardware testing on the production line. The application object of the technical solution of this application is the electronic device to be tested that has a pre-installed main operating system, which is the electronic device waiting to perform hardware testing on the production line.

[0033] In this embodiment, the method is applied to an electronic device under test that has a pre-installed main operating system. The hardware testing method includes steps S1 to S3: Step S1: After the electronic device under test is powered on, detect the mode selection signal; It should be noted that after the electronic device under test is assembled on the production line and powered on, the underlying bootloader in the electronic device under test begins to perform initialization operations.

[0034] Optionally, the electronic device to be tested is an electronic device waiting to undergo hardware testing on the production line. It can be an electronic device with a main operating system, such as a smart TV, smart set-top box, smart projector, or vehicle central control display terminal, which needs to undergo hardware testing on the production line.

[0035] Optionally, the electronic device under test is equipped with a non-volatile storage medium (such as NAND Flash, eMMC, etc.). This non-volatile storage medium (hereinafter referred to as the storage medium) has a test storage area that is physically isolated from the main system storage area. The test storage area is pre-installed with a test operating system and a test program, wherein the test program runs on the test operating system. The main system storage area contains the main operating system, which is a commercial operating system pre-installed on the electronic device under test at the factory. It can be a system with different architectures such as Google TV, WebOS, and Tizen.

[0036] Optionally, the mode selection signal is a signal used to indicate the current scenario of the electronic device under test. This signal is used to distinguish between mass production test scenario and terminal home scenario. It can be the level state of a specified general-purpose input / output pin on the motherboard of the electronic device under test (e.g., high level corresponds to mass production test scenario, low level corresponds to terminal home scenario), or it can be an on / off signal generated by the production line test fixture on the dedicated contact of the motherboard of the electronic device under test through physical contact, or it can be a software boot flag bit stored in the boot environment variable area.

[0037] Optionally, the mode selection signal can be detected by: the underlying bootloader reading the level value of a specified general-purpose input / output pin during power-on initialization, or detecting whether a dedicated contact is shorted, or reading the value of a specific flag bit in the boot environment variable area to obtain the current state of the mode selection signal.

[0038] Understandably, since mass production testing requires the electronic device under test to enter a dedicated operating mode for hardware detection, while in home terminal scenarios there is no need to perform hardware detection, the underlying bootloader needs to obtain the mode selection signal in the initial stage of the electronic device under test so as to determine the subsequent boot path based on the signal status.

[0039] Step S2: When the mode selection signal is in the first state, start the preset detection operating system in the test storage area of ​​the electronic device under test to enter the hardware detection mode. The test storage area is a storage area in the electronic device under test that is isolated from the main system storage area where the main operating system is located. It should be noted that after obtaining the current state of the mode selection signal, the underlying boot program of the electronic device under test determines whether the mode selection signal is in the first state.

[0040] Optionally, the first state is the signal state in the mode selection signal used to characterize the current mass production test scenario of the electronic device under test. It can be the state in which a specified general-purpose input / output pin is pulled high, the state in which a specified general-purpose input / output pin is pulled low, the state in which a dedicated contact is shorted, or the state in which the software boot flag in the boot environment variable area is set to a specific value (such as "1").

[0041] Optionally, when the underlying bootloader determines that the mode selection signal is in the first state, the underlying bootloader addresses the test storage area from the storage medium of the electronic device under test, and loads and starts the preset test operating system from the test storage area.

[0042] Optionally, the test storage area is a storage partition carved out of the storage medium of the electronic device under test. This storage partition is physically isolated from the main system storage area where the main operating system is stored, and the test operating system image and test program are only written during the production line testing stage.

[0043] Optionally, the main operating system is a commercial operating system pre-installed on the electronic device under test at the factory, which can be a system with different architectures such as Google TV, WebOS, Tizen, or Fire OS.

[0044] Optionally, the operating system to be detected is a lightweight operating system based on a modified Linux kernel.

[0045] Optionally, the specific method for starting the detection operating system can be as follows: the underlying bootloader loads the kernel image of the detection operating system from the test storage area into the memory of the electronic device under test, and transfers the execution control to the detection operating system, which then completes the subsequent initialization and loading of the detection program.

[0046] Optionally, the hardware detection mode is the working state that the electronic device under test enters after running the detection operating system, which is used to perform hardware detection.

[0047] Understandably, since the pre-installed testing operating system in the test storage area is a lightweight system independent of the main operating system, its boot process does not require loading the main operating system's large and slow-starting upper-level framework (such as graphical user interface, application framework, system services, etc.), so the electronic device under test can quickly enter the hardware testing mode.

[0048] Step S3: In the hardware detection mode, by running the detection program in the detection operating system, the preset hardware detection items are executed, and the hardware detection results of the electronic device under test are obtained.

[0049] It should be noted that after the detection operating system starts up, the detection operating system loads and runs the pre-installed detection program.

[0050] Optionally, the testing program is an application running on the testing operating system, which is pre-configured with a list of hardware testing items that the electronic device to be tested needs to perform and the corresponding testing logic.

[0051] Optionally, the specific method for running the detection operating system can be as follows: after the kernel of the detection operating system completes initialization, the binary file of the detection program is read from the test storage area, loaded into memory, and a corresponding process is created, which then starts executing the detection logic.

[0052] Optionally, the preset hardware testing items are functional verification items that the electronic device under test needs to perform before leaving the factory. These may include one or more of the following: display panel dead pixel detection and backlight uniformity adjustment; physical connectivity and electrical characteristics testing of external interfaces (including HDMI interface and USB interface); electroacoustic performance testing of audio output (speaker) and audio input (microphone); infrared remote control receiver key code value verification; and overall power consumption testing.

[0053] Optionally, the specific method for executing the preset hardware test items can be: the test program sends read and write instructions to the registers of each hardware component (such as display panel, audio codec, external interface controller, etc.) of the electronic device under test by calling the hardware driver, so as to verify whether the electrical characteristics and functions of each hardware are normal.

[0054] Optionally, the hardware driver is a low-level software module in the operating system used to control and communicate with specific hardware components. This hardware driver and the hardware driver at the bottom level of the main operating system are both Linux kernel driver frameworks and access the exact same physical hardware registers.

[0055] Optionally, the hardware test results can be obtained by the following method: after completing each hardware test item, the test program writes the test data (including test item identifier, test value, preset threshold range and pass / fail determination information, etc.) to a preset storage location, and finally generates summary information containing the results of all test items. This summary information is the hardware test result.

[0056] Understandably, since the essence of hardware testing is to read and write the registers of each hardware component of the electronic device under test to verify whether its electrical characteristics and functions are normal, this operation only relies on the low-level access interface provided by the hardware driver, and does not rely on any upper-level framework in the main operating system other than the driver layer. Therefore, hardware testing under the testing operating system and hardware testing under the main operating system access the exact same hardware registers and execute the exact same driver layer instructions at the physical level, ensuring the authenticity and validity of the test results.

[0057] This embodiment provides a hardware testing method. By setting up a test storage area isolated from the main system storage area in the electronic device under test, and pre-installing an independent testing operating system in this test storage area, a mode selection signal detection mechanism is introduced. This allows the electronic device under test to prioritize starting the testing operating system in the test storage area to enter hardware testing mode after power-on, based on the state of the mode selection signal, instead of waiting for the pre-installed commercial operating system (i.e., the main operating system) in the main system storage area to fully boot. Since this testing operating system exists independently of the main operating system, its startup process does not require loading the complete services and framework of the main operating system. Therefore, it can significantly shorten the preparation time required for the device to enter a testable state, thereby effectively reducing the time-consuming portion of the single-machine testing cycle on the production line caused by waiting for the system to be ready, and improving the hourly output rate of the production line. Meanwhile, because the testing operating system is independent of the main operating system pre-installed in the electronic device under test, all hardware testing items are executed through the testing program within this operating system. The operation of the testing program does not depend on the hardware access interface or application programming interface of any specific main operating system. Therefore, the same testing program can be used universally for electronic devices under test equipped with different main operating systems, eliminating the need for independent development and adaptation for different main operating systems. This significantly reduces the workload and R&D investment required for mass production of new products. This solution effectively improves the efficiency of the hardware testing process on the production line.

[0058] In one feasible implementation, before powering on the electronic device under test, an independent test environment needs to be established in the storage medium of the electronic device under test. This test environment is physically isolated from the storage area where the main operating system is located, and a dedicated test operating system and test program are pre-written to ensure that the device can quickly enter the hardware test mode after powering on without interfering with the data integrity of the main operating system.

[0059] Step S1, before the step of detecting the mode selection signal after the electronic device under test is powered on, includes: Step S11: In the electronic device under test, a test storage area is defined that is physically isolated from the main system storage area; It should be noted that before the electronic device under test completes hardware assembly but has not yet undergone production line hardware testing, a dedicated storage area needs to be allocated in the storage medium of the electronic device under test.

[0060] Optionally, the specific method for dividing the test storage area can be as follows: by modifying the partition table of the storage medium of the electronic device under test, a continuous address range is defined in the physical address space of the storage medium, the range is defined as an independent partition, and a unique partition identifier is assigned to it. This partition is the test storage area.

[0061] Optionally, physical isolation means that the test storage area and the main system storage area do not overlap in terms of physical address on the storage medium, and each has its own independent address space. Performing a write or erase operation on one area will not affect the data in the other area.

[0062] Understandably, since the test storage area is physically isolated from the main system storage area, subsequent writing of the test operating system, execution of the test program, or even erasure of all data in the test storage area will not touch any files in the main system storage area, thus ensuring the integrity and security of the main operating system from the physical storage level.

[0063] Step S12: Burn the pre-written detection operating system containing the detection program into the test storage area.

[0064] It should be noted that after the test storage area is partitioned, the pre-written test operating system image containing the test program is written into the test storage area.

[0065] Optionally, the detection program is an application pre-integrated into the file system of the detection operating system image. The detection program is packaged into a designated directory of the image file during the image building stage and burned to the test storage area along with the detection operating system. The detection program is pre-configured with a list of hardware detection items that the electronic device to be tested needs to perform and the corresponding detection logic.

[0066] Optionally, the specific method of burning can be as follows: at the burning station on the production line, the test operating system image file is written into the storage medium of the electronic device under test via a burner or a production line-specific burning tool through a JTAG (Joint Test Action Group) interface, a serial interface or a USB (Universal Serial Bus) interface, and the target address for writing is specified as the starting address of the test storage area divided in step S11.

[0067] Understandably, after the entire testing operating system containing the testing program is burned into the test storage area, the electronic device under test already has a complete testing operating environment independent of the main operating system. When the electronic device under test is powered on and the mode selection signal is in the first state, the underlying boot program can start the testing operating system from the test storage area and automatically run the testing program therein without any additional program writing steps.

[0068] For example, to help understand the implementation flow of the hardware detection method obtained by combining this embodiment with the above embodiments, please refer to... Figure 2Specifically, this application demonstrates the storage architecture of the electronic device under test in its hardware testing method, namely, the physical layout of "dual operating system partition isolation." Two independent storage areas are pre-defined within the non-volatile storage medium of the electronic device under test: The test storage area is specifically used to store the testing operating system and its accompanying testing programs, which are physically isolated from the main operating system. This testing operating system is a lightweight system based on the Linux kernel with significant modifications. It removes the cumbersome desktop environment, application store, and background network services from the main operating system, retaining only hardware device drivers and peripheral control programs to achieve a second-level fast startup after power-on.

[0069] The main system storage area is used to store the main operating system (such as commercial systems like Google TV, WebOS, or Tizen) that comes pre-installed on the electronic devices under test. The data in this main system storage area is completely preserved during the production line testing process and will not be modified or destroyed.

[0070] These two storage areas are completely isolated and do not overlap in physical address space. This physical isolation design ensures that during the mass production testing phase on the production line, when the electronic device under test is running the test operating system to perform hardware read / write and stress tests, all erase / write operations only apply to the test storage area and will not touch any data in the main system storage area, thus fundamentally protecting the security of the main operating system and factory data.

[0071] In one feasible implementation, after the electronic device under test completes all hardware testing items and obtains the hardware testing results, if all testing items are qualified, the testing operating system and testing program written during the production line testing stage need to be cleared from the electronic device under test, and the startup configuration of the electronic device under test needs to be restored to the terminal home mode. This ensures that after the electronic device under test is delivered to the end consumer, its startup behavior is completely consistent with that of a brand new original device, and it will not enter the production line testing mode, nor will it retain any production line testing data. After step S3, the step of obtaining the hardware testing results of the electronic device under test, the following steps are included: Step S31: If the hardware test result indicates that all hardware test items have passed, in response to the reset command, a data erasure operation is performed on the test storage area to clear the test operating system and the test program in the test storage area.

[0072] It should be noted that after the electronic device under test completes all the preset hardware test items and obtains the hardware test results, the first step is to determine whether the hardware test results indicate that all hardware test items have passed.

[0073] Optionally, the specific method for determining whether the hardware test results indicate that all tests have passed can be as follows: after completing each hardware test item, the test program writes the test data (including test item identifier, test value, preset threshold range, and pass / fail determination information) to a preset storage location, and finally generates summary information containing pass / fail markers for all test items. This summary information is the hardware test result. The electronic device under test reads the markers of each item in the summary information. If all markers are pass, then the hardware test items are determined to have passed.

[0074] Optionally, the reset command is a command issued by an external control device to trigger the electronic device under test to perform a cleaning operation. Optionally, the external control device can be a production line host computer, a production line industrial control computer, or a production line-specific reset signal generator.

[0075] Optionally, the communication method for issuing reset commands can be through a serial communication interface, a universal serial bus interface, or wireless communication.

[0076] Optionally, the specific method of responding to the reset command can be as follows: the process running on the testing operating system in the electronic device under test continuously listens to the data on the serial communication interface or the universal serial bus interface, and when it receives a reset command that conforms to the preset format, it immediately triggers the data erasure execution process.

[0077] Optionally, the data erasure operation is to perform an overwrite or full-area format operation on all physical storage space corresponding to the test storage area.

[0078] Optionally, the specific method for performing data erasure operations on the test storage area can be: calling the underlying erasure interface of the storage medium of the electronic device under test (such as executing a full block erasure command or executing a partition erasure command) to mark all physical blocks of the test storage area as reusable, thereby completely removing the test operating system image and test program from it.

[0079] Optionally, clearing the detection operating system and detection program in the test storage area means that the test storage area no longer contains any executable system image or application code, and its storage space is released to a usable state.

[0080] Understandably, since the test storage area and the main system storage area are physically isolated from each other, the data erasure operation only applies to the test storage area and will not affect the main operating system and user data stored in the main system storage area. Therefore, the erasure operation is safe and controllable.

[0081] In one feasible implementation, after step S31, which involves performing a data erasure operation on the test storage area, the method further includes: Step S32: Configure the bootloader of the electronic device under test to disable the boot path of the test storage area.

[0082] It should be noted that after the data erasure operation is completed in the test storage area of ​​the electronic device under test, in order to make subsequent security more secure, the configuration of the boot program of the electronic device under test can be modified so that the boot program will not attempt to load the operating system from the test storage area when it is powered on and started in the future.

[0083] Optionally, the bootloader is the first low-level software executed after the electronic device under test is powered on. It is responsible for initializing the hardware and loading the operating system from the specified storage medium. It is deployed in the starting address area or a dedicated boot partition of the storage medium of the electronic device under test.

[0084] Optionally, the bootloader of the electronic device under test can be configured in the following ways: during the bootloader's operation, it reads the configuration information in the environment variable area, which stores the storage media priority order in which the bootloader attempts to load the operating system; the electronic device under test removes the boot item corresponding to the test storage area from the boot device order list by writing a specific value to the environment variable area, or sets the priority of the boot item to an invalid / disabled state.

[0085] Optionally, disabling the boot path for the test storage area means that the bootloader will no longer consider the test storage area as a candidate boot path during subsequent power-on startups, nor will it attempt to read any data from the test storage area.

[0086] Optionally, the boot path can be disabled by setting a permanent disable flag in the environment variable area. Once the flag is written with a disable value, the bootloader will read the flag each time it is powered on and then skip the boot of the test storage area.

[0087] Understandably, since the boot path of the test storage area has been disabled, and this disabled configuration is persistent (the configuration in the environment variable area remains effective even if the electronic device under test is powered off and then powered on again), the electronic device under test will not enter the testing operating system again on any subsequent power-on startup. This ensures that the boot behavior of the electronic device under test is completely consistent with that of a brand new original equipment after it is delivered to the end consumer, and there will be no situation where it mistakenly enters the production line testing mode.

[0088] Optionally, the bootloader configuration operation can also be performed before the data erasure operation. That is, during the response process of the reset command, the electronic device under test first configures the bootloader to disable the startup path of the test storage area, and then performs the data erasure operation of the test storage area, or both can be processed at the same time. This application does not limit the order of steps S31 and S32.

[0089] Understandably, after the processing of steps S31 and S32, the production line testing environment in the electronic device under test has been completely cleared, and the startup behavior has been restored to the terminal home mode, so the electronic device under test can be delivered to the end consumer for normal use.

[0090] In one feasible implementation, the electronic device under test is not always in a production line testing scenario. When the electronic device under test is in a home terminal scenario or a non-production line testing scenario, the main operating system should be started normally for end users. Therefore, after the detection mode selection signal, different startup paths need to be guided according to different signal states. In step S1, after the electronic device under test is powered on and after the detection mode selection signal step, the following is also included: Step A11: If the mode selection signal is not obtained or the mode selection signal is obtained and is in the second state, start the main operating system in the main system storage area.

[0091] It should be noted that when the underlying bootloader detects the mode selection signal, there may be two situations in which the hardware detection mode is not triggered: either the mode selection signal is not obtained, or the mode selection signal is in a second state.

[0092] Optionally, the failure to obtain the mode selection signal means that: there is no physical contact between the production line test fixture and the motherboard of the electronic device under test, the specified general-purpose input / output pins are in the default level state, or there is no software boot flag bit in the boot environment variable area, that is, no signal is written. This situation corresponds to the electronic device under test being in a terminal home scenario.

[0093] Optionally, the second state is a signal state in the mode selection signal used to characterize the current home scenario of the electronic device under test. It can be a specified general-purpose input / output pin being pulled low (when the first state is high), or a specified general-purpose input / output pin being pulled high (when the first state is low), or a dedicated contact being detected to be in an open state, or a software boot flag in the boot environment variable area being set to a specific value (such as "0").

[0094] Optionally, the specific method for starting the main operating system can be as follows: the underlying bootloader reads the bootloader or kernel image of the main operating system from the main system storage area, loads it into the memory of the electronic device under test, and transfers the execution control to the main operating system, which then completes the subsequent full boot process (including loading the desktop environment, graphical user interface framework, system services and application framework, etc.).

[0095] Understandably, when the mode selection signal is absent or in the second state, it indicates that the electronic device under test is not currently in the production line testing scenario and does not need to perform hardware testing. Therefore, the bootloader guides the main operating system to start according to the normal startup process, ensuring that the electronic device under test can be provided to users as a normal terminal product.

[0096] For example, to help understand the implementation flow of the hardware detection method obtained by combining this embodiment with the above embodiments, please refer to... Figure 3 Specifically, the hardware testing method of this application demonstrates that after the electronic device under test is powered on and started, different paths are initiated based on the mode selection signal status: after the electronic device under test is powered on and started, the underlying boot program first performs the mode selection signal detection operation to determine the current signal status in order to determine the operating scenario of the electronic device under test.

[0097] Based on the signal detection results, the program enters different startup branches: When the mode selection signal is detected in the first state (representing a mass production test scenario), the bootloader starts a pre-installed test operating system in the test storage area, which is physically isolated from the main operating system. Under the test operating system, preset hardware test items are automatically executed, and the hardware test results are ultimately obtained. This branch ensures that the electronic device under test can quickly enter the hardware test state without waiting for the main operating system to start, significantly improving production line testing efficiency. When the bootloader does not obtain a mode selection signal, or when the obtained mode selection signal is in the second state (representing a non-production line test, home-use scenario), the main operating system (i.e., the pre-installed commercial operating system) in the main system storage area is started normally, guiding the electronic device under test into a normal terminal usage environment.

[0098] In one feasible implementation, the detected operating system is an operating system obtained by trimming an initial Linux kernel-based operating system using a preset trimming method, wherein the trimming method retains only the hardware device drivers and peripheral control programs of the initial operating system.

[0099] It should be noted that the operating system being tested is not a fully functional general-purpose operating system, but a lightweight operating system obtained by trimming down the initial operating system.

[0100] Optionally, the initial operating system is a complete Linux kernel and its supporting system components. This Linux kernel contains a wealth of functional modules and subsystems that can support a variety of hardware platforms and application scenarios.

[0101] Optionally, the default trimming method is to selectively remove unnecessary functional modules through configuration options when compiling the initial operating system.

[0102] Optionally, the trimming method is to retain only the hardware device drivers and peripheral control programs of the initial operating system, specifically including: when compiling the Linux kernel, disabling all subsystems and functional modules that are not related to hardware detection.

[0103] Optionally, the components to be removed may include: desktop environment (i.e., display protocols and services used to provide graphical user interfaces), graphical user interface framework (i.e., application framework used to build graphical interfaces), app store (i.e., software management tools used to download and install third-party applications), and network background service processes (such as network management services, printing services, and other persistent background processes).

[0104] Optionally, hardware device drivers are low-level software modules in the initial operating system used to control and communicate with specific hardware components, including framebuffer display drivers, I2C (Inter-Integrated Circuit) drivers, SPI (Serial Peripheral Interface) drivers, audio codec drivers, USB (Universal Serial Bus) host controller drivers, GPIO (General Purpose InputOutput) drivers, etc.

[0105] Optionally, the peripheral control program is an application or tool that runs on the operating system and is used to call hardware device drivers to complete specific hardware control operations, including screen backlight adjustment tools, audio gain control tools, interface power supply control tools, etc.

[0106] Optionally, the trimmed Linux kernel image can be deployed to the test storage area, which is the detection operating system in step S12 above.

[0107] Understandably, because the detection operating system only retains hardware device drivers and peripheral control programs, and removes all upper-level frameworks and background services unrelated to hardware detection, the image size of the detection operating system is much smaller than that of a complete commercial operating system. It does not need to load any redundant modules during the boot process, thus achieving a boot speed of seconds. At the same time, it has extremely low hardware resource consumption, and can concentrate all processing power on executing hardware detection projects.

[0108] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. On this basis, during the production line programming process, the image file of the testing operating system may be incomplete or corrupted due to programming abnormalities, bad blocks in the storage medium, or data bit flipping. If a corrupted testing operating system is directly started, it may cause the electronic device under test to fail to start, be unable to enter the hardware testing mode, or even crash. Therefore, it is necessary to verify the integrity of its image file before starting the testing operating system to ensure that the started operating system is a correct and undamaged version. Before step S2, which involves starting the testing operating system preset in the test storage area of ​​the electronic device under test, the following further step is included: Step S21: Calculate the integrity verification value of the image file of the operating system being tested in the test storage area; It should be noted that before the underlying bootloader decides to start the test operating system in the test storage area, it needs to calculate the integrity check value of the image file of the test operating system stored in the test storage area.

[0109] Optionally, the image file is a binary executable file for testing the operating system. This file contains the kernel code, hardware drivers, and testing program of the operating system, and the entire file is burned into the test storage area.

[0110] Optionally, the integrity check value is a digital digest used to verify whether the image file is complete, has not been tampered with, or has been damaged.

[0111] Optionally, the specific method for calculating the integrity check value can be as follows: the underlying bootloader reads all the binary data of the operating system image file stored in the test storage area, uses this data as input, performs a calculation using a preset hash algorithm, and generates a fixed-length hash value, which is the integrity check value. Optionally, the preset hash algorithm can be any one of MD5 (Message-Digest Algorithm 5), SHA-1 (Secure Hash Algorithm 1), SHA-256 (Secure Hash Algorithm 256), or SM3 (Chinese national cryptographic hash algorithm). For example, the underlying bootloader reads all the data of the image file byte by byte into a memory buffer, then performs a SHA-256 operation on the data in the buffer, outputting a 256-bit hash value as the integrity check value.

[0112] Understandably, due to the characteristics of hash algorithms, any change in any bit in the image file will cause a significant change in the calculated integrity check value. Therefore, by comparing the integrity check values, it is possible to accurately determine whether the image file is complete and error-free.

[0113] Step S22: When the integrity check value is equal to the preset check value, execute the step of starting the preset detection operating system in the test storage area of ​​the electronic device under test; It should be noted that after calculating the integrity check value of the operating system image file, the underlying bootloader compares the integrity check value with the preset check value.

[0114] Optionally, the preset verification value is a standard hash value pre-calculated using the same hash algorithm on the original complete image file after the test operating system image file is compiled and built. This preset verification value is written to a specified storage location (such as the boot environment variable area or a separate verification value storage partition) of the storage medium of the electronic device under test while the test operating system is burned to the test storage area.

[0115] Optionally, the specific method for comparing the integrity check value with the preset check value can be: the underlying bootloader reads the preset check value from the specified storage location and compares the calculated integrity check value with the preset check value byte by byte.

[0116] Optionally, if the integrity check value is equal to the preset check value, it indicates that the image file of the test operating system stored in the test storage area is complete, undamaged, and consistent with the original version. Therefore, the underlying bootloader continues to execute the process of starting the preset test operating system in the test storage area.

[0117] Understandably, the testing operating system is only allowed to start when the integrity verification passes. This ensures that the testing operating system can run stably after the electronic device under test enters the hardware testing mode, avoiding startup failure or testing anomalies caused by image file corruption.

[0118] Step S23: When the integrity verification value is not equal to the preset verification value, an error message is output, and the new detection operating system is burned to the test storage area.

[0119] It should be noted that when the underlying bootloader compares the calculated integrity check value with the preset check value, if the two are not equal, it indicates that the image file of the test operating system stored in the test storage area has been damaged or incomplete and cannot be booted safely.

[0120] Optionally, the reasons why the integrity check value is not equal to the preset check value may include: data writing errors during the burning process, bad blocks in the storage medium causing partial data loss, and data bit flipping caused by storage medium aging.

[0121] Optionally, the specific method for outputting error information may be: the underlying bootloader sends error information (such as "verification failed" or "operating system corruption detected") to the production line host computer through the serial communication interface or universal serial bus interface of the electronic device under test, and / or displays the error code on the display device of the electronic device under test.

[0122] Optionally, the specific method for burning the new testing operating system to the test storage area can be as follows: after receiving the error information, the production line host computer resends the complete and correct testing operating system image file to the electronic device under test through a serial communication interface or a universal serial bus interface. After receiving the image file, the electronic device under test writes the new image file to the starting address of the test storage area, overwriting the original damaged data; or the production line operator re-executes the burning operation in step S12.

[0123] Understandably, when integrity verification fails, instead of executing the step of starting the operating system for testing, an error message is output and the device is reprogrammed. This can prevent the electronic device under test from falling into an abnormal state due to starting a damaged operating system, thus ensuring the stability and reliability of the production line testing process. After reprogramming, the electronic device under test can execute the power-on startup process again to re-detect the mode selection signal and perform integrity verification until the verification passes and it enters the hardware testing mode normally.

[0124] In one feasible implementation, another hardware testing method is provided, wherein the testing operating system is not pre-burned into the local test storage area of ​​the electronic device under test, but is obtained online by the electronic device under test from the production line server in a production line testing scenario, and runs directly in memory after acquisition, and is automatically cleared after power failure. Step D1: When the electronic device under test establishes a network connection with the production line server and the mode selection signal is in the first state, download the image file of the testing operating system and the testing program online from the production line server. It should be noted that after the underlying bootloader detects that the electronic device under test has been powered on and has obtained the mode selection signal, if the electronic device under test has already established a network connection with the production line server and the mode selection signal is in the first state, the electronic device under test will download the test operating system online from the production line server. At this time, it can be assumed that there is no test operating system in the local test storage area.

[0125] Optionally, the specific method for the electronic device under test to establish a network connection with the production line server can be as follows: the electronic device under test accesses the production line local area network through its wired network interface (such as an Ethernet interface) or wireless network interface (such as a Wi-Fi module) and completes a TCP / IP (Transmission Control Protocol / Internet Protocol) handshake connection with the production line server.

[0126] Optionally, the production line server is a computing device deployed in the production line's local area network. This server stores the image file of the testing operating system and the latest version of the testing program, which can be downloaded simultaneously by multiple electronic devices under test on the production line.

[0127] Optionally, the specific meaning of the first state can be referred to the relevant explanation in step S2 above, and will not be repeated here.

[0128] Optionally, the online download can be performed as follows: the electronic device under test sends a download request to the production line server, which carries the model identifier of the electronic device under test; the production line server matches the corresponding testing operating system image file and testing program according to the model identifier, and transmits the file to the electronic device under test in the form of a data stream via protocols such as HTTP (Hypertext Transfer Protocol) or FTP (File Transfer Protocol); the electronic device under test stores the received data stream in a designated buffer in memory.

[0129] Understandably, the online download method eliminates the need to pre-burn the operating system image file and testing program onto the local storage medium of the electronic device under test. For small-batch production or high-end customized models, this can reduce the burning process on the production line and ensure that the latest version of the testing program is downloaded each time.

[0130] Step D2: By running the detection program in the detection operating system, the preset hardware detection items are executed, and the hardware detection results of the electronic device under test are obtained. When the electronic device under test is powered off, the downloaded image file of the detection operating system and the detection program are automatically cleared.

[0131] It should be noted that after the electronic device under test completes the download of the operating system image file and the testing program, the operating system image file downloaded to memory will be directly loaded and started.

[0132] Optionally, the specific method for directly loading the detection operating system in memory can be as follows: the underlying boot program loads the detection operating system kernel image stored in the memory buffer into the kernel running address space, transfers execution control to the kernel, and the kernel completes the subsequent initialization and reads the detection program from a specified location in memory.

[0133] Optionally, the specific content of the preset hardware detection items can be referred to the relevant explanation in step S3 above, and will not be repeated here. Optionally, the method for obtaining the hardware detection results can be referred to the relevant explanation in step S3 above, and will not be repeated here.

[0134] Optionally, the specific method for automatically clearing the downloaded operating system image file and testing program after the electronic device under test is powered off can be as follows: Since the operating system image file and testing program are only stored in the memory of the electronic device under test and are not written to non-volatile storage media (such as NAND Flash, eMMC, etc.), the data in the memory is naturally lost when the electronic device under test is powered off, and no additional erasure operation is required; or, when the electronic device under test performs a shutdown or reset operation after the test is completed, it actively releases the memory space occupied by the operating system image file and testing program stored in the memory buffer.

[0135] Understandably, the method of downloading and running the test operating system online and only in memory, compared to the method of pre-setting it in the local test storage area, eliminates the need to allocate a dedicated test storage area in the storage medium of the electronic device under test, and also eliminates the need to perform subsequent data erasure operations. The data is automatically lost after power failure, which simplifies the production line operation process and is especially suitable for high-end customized models or small-batch production scenarios.

[0136] In one feasible implementation, after step S3, which involves obtaining the hardware testing results of the electronic device under test, the method further includes: Step D31: When the hardware test result indicates that all hardware test items have passed, the device operating parameters in the hardware test result are written into the parameter storage area of ​​the electronic device under test, and a data erasure operation is performed on the test storage area. The parameter storage area is independent of the test storage area and the main system storage area. It should be noted that after the electronic device under test completes all the preset hardware test items and obtains the hardware test results, the first step is to determine whether the hardware test results indicate that all hardware test items have passed. Optionally, the specific method for determining whether the hardware test results indicate that all hardware test items have passed can refer to the relevant explanation in the aforementioned step S31, and will not be repeated here.

[0137] Optionally, the device operating parameters are the normal operating parameters of each hardware component obtained during the hardware testing process of the electronic device under test. These parameters may include the backlight brightness calibration value of the display panel, the gain parameters of the audio codec, the electrical characteristic calibration values ​​of the external interface, and the voltage threshold of the power management unit. These parameters are obtained by testing and calibrating each hardware component during the execution of the hardware testing project.

[0138] Optionally, the parameter storage area is a storage area specifically allocated in the non-volatile storage medium of the electronic device under test for persistent storage of device operating parameters. This parameter storage area is physically isolated from both the test storage area and the main system storage area, so that data erasure operations performed on the test storage area will not affect the data in the parameter storage area, and read / write operations performed on the main system storage area will not affect the data in the parameter storage area.

[0139] Optionally, the specific method for writing device operating parameters into the parameter storage area can be as follows: the electronic device under test encapsulates the device operating parameters of each hardware component acquired during the testing process according to a preset data structure, and writes them into the parameter storage area according to a specified address offset, so that the main operating system can read and apply them during subsequent startup. Optionally, the specific method for performing data erasure operations on the test storage area can refer to the relevant explanation in the aforementioned step S31, and will not be repeated here.

[0140] Understandably, when all hardware tests pass, it indicates that the hardware quality of the electronic device under test is qualified. At this time, the device operating parameters obtained during the test can be persistently saved so that the main operating system can apply these parameters to make each hardware component work in the best state when it starts up later. At the same time, the test operating system and test program in the test storage area need to be erased to free up storage space. Since the parameter storage area is independent of the test storage area, the erasure operation will not affect the device operating parameters that have been written.

[0141] Step D32: When the hardware test result indicates that there are failed hardware test items, the device operating parameters of the passed hardware test items are written into the parameter storage area of ​​the electronic device under test, and the hardware test steps of the failed hardware test items are automatically executed.

[0142] It should be noted that the hardware test results can indicate the presence of failed hardware test items in the following ways: the summary information of the hardware test results contains at least one hardware test item marked as "failed" or "not passed". Once the electronic device under test reads this mark, it is determined that there is a failed hardware test item.

[0143] Optionally, the hardware test items that have passed are those marked "passed" in the hardware test results. These items indicate that the electronic device under test meets the preset requirements in terms of the hardware function or performance corresponding to the item.

[0144] Optionally, the specific method for automatically executing the hardware testing steps for failed hardware testing items can be as follows: the testing program in the electronic device under test automatically calls back the hardware driver corresponding to the failed item, performs the same read / write operations and parameter measurements on the hardware component corresponding to the item again, so as to re-obtain the testing data of the hardware component and re-determine whether it passes or fails.

[0145] Understandably, when there are hardware test items that fail, items that have passed do not need to be retested. Instead, the operating parameters of the equipment that has passed should be saved, and the test should be automatically re-executed for the failed items to improve the efficiency of the production line. If the item passes after retesting, step D31 can be executed to complete the subsequent process. If the item still fails after repeated testing, the electronic device under test is marked as a defective product and handled by the production line operator.

[0146] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the hardware detection method of this application. Any simple variations based on this technical concept, such as the interaction and combination of various embodiments, are all within the protection scope of this application.

[0147] This application also provides a hardware testing device, please refer to... Figure 4 The hardware testing device, applied to electronic devices pre-installed with a main operating system, includes: Signal detection module 10 is used to detect the mode selection signal after the electronic device under test is powered on; The startup control module 20 is used to start the preset detection operating system in the test storage area of ​​the electronic device under test when the mode selection signal is in the first state, so as to enter the hardware detection mode. The test storage area is a storage area in the electronic device under test that is isolated from the main system storage area where the main operating system is located. The hardware detection module 30 is used to execute preset hardware detection items and obtain the hardware detection results of the electronic device under test by running the detection program in the detection operating system in the hardware detection mode.

[0148] The hardware testing device provided in this application, employing the hardware testing method described in the above embodiments, can solve the technical problem of low efficiency in existing hardware testing for smart electronic devices. Compared with the prior art, the beneficial effects of the hardware testing device provided in this application are the same as those of the hardware testing method provided in the above embodiments, and other technical features in the hardware testing device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0149] This application provides an electronic device under test, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the hardware testing method in the first embodiment described above.

[0150] The following is for reference. Figure 5 It shows a schematic diagram of the structure of the electronic device under test suitable for implementing the embodiments of this application. Figure 5 The electronic device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0151] like Figure 5 As shown, the electronic device under test may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device under test. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the electronic device under test to communicate wirelessly or wiredly with other devices to exchange data. Although the electronic device under test is shown in the figure with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0152] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0153] The electronic device under test provided in this application, employing the hardware testing method described in the above embodiments, can solve the technical problem of low efficiency in existing hardware testing for smart electronic devices. Compared with the prior art, the beneficial effects of the electronic device under test provided in this application are the same as those of the hardware testing method provided in the above embodiments, and other technical features in the electronic device under test are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0154] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0155] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0156] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the hardware detection method in the above embodiments.

[0157] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0158] The aforementioned computer-readable storage medium may be included in the electronic device under test; or it may exist independently and not assembled into the electronic device under test.

[0159] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0160] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0161] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0162] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described hardware detection method, thereby solving the technical problem of low efficiency in existing hardware detection methods for smart electronic devices. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the hardware detection method provided in the above embodiments, and will not be repeated here.

[0163] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the hardware detection method described above.

[0164] The computer program product provided in this application can solve the technical problem of low efficiency in existing hardware testing for smart electronic devices. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the hardware testing method provided in the above embodiments, and will not be repeated here.

[0165] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A hardware testing method, characterized in that, The hardware testing method, applied to electronic devices pre-installed with a main operating system, includes: After the electronic device under test is powered on, the detection mode selection signal is activated. When the mode selection signal is in the first state, the preset detection operating system in the test storage area of ​​the electronic device under test is started to enter the hardware detection mode. The test storage area is a storage area in the electronic device under test that is isolated from the main system storage area where the main operating system is located. In the hardware testing mode, the testing program in the testing operating system is run to execute preset hardware testing items and obtain the hardware testing results of the electronic device under test.

2. The method as described in claim 1, characterized in that, Before the step of detecting the mode selection signal after the electronic device under test is powered on, the procedure includes: In the electronic device under test, a test storage area is defined that is physically isolated from the main system storage area; The pre-written detection operating system containing the detection program is burned into the test storage area.

3. The method as described in claim 1, characterized in that, Following the step of obtaining the hardware test results of the electronic device under test, the following steps are included: If the hardware test results indicate that all hardware test items have passed, in response to a reset command, a data erasure operation is performed on the test storage area to clear the test operating system and the test program in the test storage area.

4. The method as described in claim 3, characterized in that, After the step of performing a data erasure operation on the test storage area, the method further includes: Configure the bootloader of the electronic device under test to disable the boot path of the test storage area.

5. The method as described in claim 1, characterized in that, After the step of detecting the mode selection signal after the electronic device under test is powered on, the method further includes: If the mode selection signal is not received or if the mode selection signal is in the second state, the main operating system in the main system storage area is started.

6. The method as described in claim 1, characterized in that, The operating system being tested is an operating system obtained by trimming an initial Linux kernel-based operating system using a preset trimming method, wherein the trimming method retains only the hardware device drivers and peripheral control programs of the initial operating system.

7. The method as described in claim 1, characterized in that, Before the step of activating the test operating system preset in the test storage area of ​​the electronic device under test, the method further includes: Calculate the integrity check value of the image file of the operating system being tested in the test storage area; When the integrity check value is equal to the preset check value, the step of starting the preset detection operating system in the test storage area of ​​the electronic device under test is executed; When the integrity check value is not equal to the preset check value, an error message is output, and a new detection operating system is burned to the test storage area.

8. The method as described in claim 1, characterized in that, After the step of detecting the mode selection signal after the electronic device under test is powered on, the method further includes: When the electronic device under test establishes a network connection with the production line server and the mode selection signal is in the first state, the image file of the testing operating system and the testing program are downloaded online from the production line server. By running the detection program in the detection operating system, preset hardware detection items are executed, and the hardware detection results of the electronic device under test are obtained. When the electronic device under test is powered off, the downloaded image file of the detection operating system and the detection program are automatically cleared.

9. A hardware testing device, characterized in that, The hardware testing device is applied to electronic devices pre-installed with a main operating system and includes: The signal detection module is used to detect the mode selection signal after the electronic device under test is powered on. The startup control module is used to start the preset detection operating system in the test storage area of ​​the electronic device under test when the mode selection signal is in the first state, so as to enter the hardware detection mode. The test storage area is a storage area in the electronic device under test that is isolated from the main system storage area where the main operating system is located. The hardware testing module is used to execute preset hardware testing items and obtain the hardware testing results of the electronic device under test by running the testing program in the testing operating system in the hardware testing mode.

10. An electronic device to be tested, characterized in that, The electronic device under test includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the hardware testing method as described in any one of claims 1 to 8.

Images