A cross-architecture ACPI testing method and device, electronic equipment and storage medium

Abstract

This invention discloses a cross-architecture ACPI testing method, apparatus, electronic device, and storage medium, relating to the field of computer hardware and operating system testing technology. The method includes: declaring multi-architecture support in the control file of the deb package using Debian-based multi-architecture fusion technology, and constructing a cross-platform ACPI testing tool using a dynamic architecture loader for differentiated driver deployment. It automatically identifies the target system architecture, operating system type, and kernel version, dynamically adjusting the ACPI table parsing logic and driver calls. ACPI function test items and automated parameters are configured through an interactive interface to generate test files and execute serial tests, generating test logs in real time. During testing, logs are transmitted to the UI process in real time, and device status is automatically refreshed upon monitoring file changes. If a device anomaly is detected, a pop-up alarm is immediately triggered, the test is paused, and an analysis report is generated. This invention effectively solves the shortcomings of existing technologies in terms of architecture compatibility and operating system adaptability.

Description

Technical Field

[0001] This invention relates to the field of computer hardware and operating system testing technology, and in particular to a cross-architecture ACPI testing method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development and popularization of domestic operating systems, and the widespread application of ARM architecture in servers and mobile devices, ACPI (Advanced Configuration and Power Management Interface) has become increasingly important as a core bridge between hardware and operating systems.

[0003] However, existing ACPI testing tools are mainly designed for x86 architecture and traditional Windows / Linux systems, and they have significant technical limitations when dealing with the diversity of domestic systems (such as UOS and Kylin system) and ARM architecture.

[0004] Traditional ACPI testing tools rely on ACPI tables provided by BIOS / UEFI (such as DSDT and SSDT) ​​for compatibility verification. However, these tools lack sufficient support for ARM architecture power management units (such as PSCI) and interrupt controllers (such as GIC), resulting in an inability to fully parse ARM platform-specific ACPI tables (such as GTDT and IORT), thus affecting the accuracy of test results. Furthermore, the unique characteristics of domestically developed systems in kernel customization and driver development frequently cause compatibility issues in traditional tools during runtime, such as the inability to correctly read ACPI tables or adapt to kernel interfaces.

[0005] Furthermore, traditional tools have complex interfaces and cumbersome operations, and their output information lacks visualization and analytical reports, increasing the barrier to entry for users. With the diversification of domestically produced system hardware platforms and operating systems, the cross-platform support capabilities of traditional tools are also proving inadequate. Users need to switch between different tools to cope with multi-platform environments, which greatly reduces testing efficiency.

[0006] Therefore, there is an urgent need for a cross-architecture ACPI testing method that is compatible with multiple architectures and operating systems, and is user-friendly, efficient, and flexible. Summary of the Invention

[0007] The embodiments of this invention provide a cross-architecture ACPI testing method to address the problems of insufficient compatibility with existing technical architectures, poor operating system adaptability, inadequate user-friendliness, and limited cross-platform support. The technical solution is as follows: According to one aspect of the present invention, a cross-architecture ACPI testing method is provided, the method comprising: declaring multi-architecture support in the control file of a deb package using Debian-based multi-architecture fusion technology, and obtaining an ACPI testing tool through differential driver loading using an architecture dynamic loader; deploying the ACPI testing tool as an architecture deployment component for the target system; identifying the operating system type and kernel version of the target system using the ACPI testing tool, adjusting the parsing logic of the ACPI table and the driver calling method according to the characteristics of the operating system type and kernel version, and updating the ACPI testing tool; obtaining ACPI function test items through an interactive interface, configuring automation parameters to generate test files, synchronously executing the test files and the ACPI testing tool for in-line testing, and generating test logs; the test items include S3 sleep and hot start; the automation parameters include test cycles and waiting time; transmitting the test logs to the UI process in real time, and automatically refreshing device status changes by monitoring files; if device loss or performance degradation is detected, immediately triggering a pop-up alarm and pausing the test, and generating an analysis report containing timestamps and exception types.

[0008] In one embodiment, the ACPI testing tool is obtained by declaring multi-architecture support in the control file of the deb package using Debian-based multi-architecture fusion technology and performing differentiated driver loading through a dynamic architecture loader. This is achieved through the following steps: using Debian-based multi-architecture fusion technology, a combination of Multi-Arch: foreign and Architecture: any declarations is used in the DEBIAN / control file of the deb package to construct an architecture-aware dependency tree; the corresponding kernel driver module is dynamically loaded according to the CPU type of the target system through a dynamic architecture loader for cross-platform deployment of a single deb package; the CPU types include x86_64 and aarch64; the kernel driver modules include ioctrl.ko for x86 and gic-interface.ko for ARM.

[0009] In one embodiment, the deployment of the architecture components for the target system based on the ACPI testing tool is achieved through the following steps: In the postinst script, the ACPI testing tool is used to obtain the architecture identifier of the target system through the dpkg --print-architecture command, and the ACPI table parsing engine and dedicated driver are selectively deployed based on the architecture identifier.

[0010] In one embodiment, the ACPI testing tool identifies the operating system type and kernel version of the target system, and adjusts the ACPI table parsing logic and driver invocation method according to the characteristics of the operating system type and kernel version. Updating the ACPI testing tool is achieved through the following steps: dynamically detecting the operating system type and kernel version of the target system using the ACPI testing tool; obtaining system information through parsed target system version files and configuration files; adjusting the ACPI table parsing logic and driver invocation method based on the system information and the customized characteristics corresponding to the kernel version; the operating system type includes UOS and Kylin.

[0011] In one embodiment, ACPI functional test items are obtained through an interactive interface, and automated parameters are configured to generate test files. The test files are then synchronously executed with the ACPI testing tool to generate test logs. This is achieved through the following steps: ACPI functional test items are determined and automated parameters are set through human-computer interaction via a front-end configurator, and synchronization is performed through a real-time two-way binding mechanism. During testing, the test items and automated parameters are parsed into a test structure file in memory, and the serial tests are executed in the order of the test items in the test structure file.

[0012] In one embodiment, the test log is transmitted to the UI process in real time, and the device status is automatically refreshed by listening to file changes through the following steps: the test log is transmitted to the UI process in real time through named pipes, the device status comparison table is refreshed by listening to file changes, and the device status is reflected by the SIGUSR1 signal; the status comparison table includes keyboard status and Wi-Fi module status.

[0013] In one embodiment, if a device loss or performance degradation is detected, a pop-up alarm is immediately triggered and the test is paused. An analysis report containing timestamps and anomaly types is generated through the following steps: when the device status is abnormal, the test is paused; an analysis report containing timestamps and anomaly types is generated based on the device status comparison table and the test log, and formatted as a JSON or text file; the analysis report includes the device name, the time of the anomaly, and the specific problem.

[0014] According to one aspect of the present invention, a cross-architecture ACPI testing apparatus includes: a multi-architecture tool building module, configured to declare multi-architecture support in the control file of a deb package using Debian-based multi-architecture fusion technology, and to obtain an ACPI testing tool through differential driver loading via an architecture dynamic loader, and to deploy components for the target system based on the ACPI testing tool; and a system characteristic adaptation module, configured to identify the operating system type and kernel version of the target system through the ACPI testing tool, and to adjust the parsing logic of the ACPI table and the driver call based on the characteristics of the operating system type and kernel version. The ACPI testing tool is updated using the following method: a test item configuration execution module is used to obtain ACPI function test items through an interactive interface, configure automation parameters to generate test files, and synchronously execute the test files with the ACPI testing tool to generate test logs; the test items include S3 sleep and warm start; the automation parameters include test cycles and waiting time; and an anomaly real-time monitoring module is used to transmit the test logs to the UI process in real time and automatically refresh device status changes by listening to the file. If device loss or performance degradation is detected, a pop-up alarm is immediately triggered and the test is paused, generating an analysis report with timestamps and anomaly types.

[0015] According to one aspect of the present invention, an electronic device includes at least one processor and at least one memory, wherein computer-readable instructions are stored on the memory; the computer-readable instructions are executed by one or more of the processors to cause the electronic device to implement the cross-architecture ACPI testing method as described above.

[0016] According to one aspect of the invention, a storage medium stores computer-readable instructions thereon, which are executed by one or more processors to implement the cross-architecture ACPI testing method as described above.

[0017] The beneficial effects of the technical solution provided by this invention are: In the above technical solution, this invention utilizes Debian-based multi-architecture integration technology, declaring multi-architecture support in the deb package's control file and employing a dynamic architecture loader for differentiated driver deployment to build a cross-platform ACPI testing tool. The tool automatically identifies the target system architecture, operating system type, and kernel version, dynamically adjusting the ACPI table parsing logic and driver calls to ensure testing accuracy. Through an interactive interface, users can flexibly configure ACPI functional test items and automation parameters, generate test files, execute serialized tests, and generate detailed test logs in real time. During testing, named pipes are used to transmit logs to the UI process in real time, automatically refreshing device status by monitoring file changes, and immediately triggering a pop-up alarm and pausing the test upon detecting a device anomaly, while simultaneously generating an analysis report with timestamps and anomaly types. This invention not only solves the shortcomings of traditional ACPI testing tools in terms of architecture compatibility and operating system adaptability but also significantly improves testing efficiency and user-friendliness, ensuring the accuracy and reliability of ACPI functional testing in domestically developed systems and multi-platform environments. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a cross-architecture ACPI testing method according to an exemplary embodiment; Figure 2 This is a block diagram illustrating a cross-architecture ACPI test apparatus according to an exemplary embodiment; Figure 3 This is a hardware structure diagram of an electronic device according to an exemplary embodiment; Figure 4 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0020] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0021] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this disclosure means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0022] This invention provides a cross-architecture ACPI testing method. Through multi-architecture fusion and dynamic loading technology, it enables the construction of a cross-platform ACPI testing tool, overcoming the shortcomings of traditional tools in architecture compatibility and operating system adaptation. This improves testing efficiency and user-friendliness, ensuring the accuracy and reliability of ACPI functional testing in multi-platform environments. This cross-architecture ACPI testing method is applicable to cross-architecture ACPI testing devices, which can be electronic devices. The cross-architecture ACPI testing method in this invention can be applied to various scenarios, such as cross-architecture ACPI testing.

[0023] Please see Figure 1 This invention provides a cross-architecture ACPI testing method applicable to electronic devices.

[0024] In the following method embodiments, for ease of description, the execution subject of each step of the method is an electronic device, but this does not constitute a specific limitation.

[0025] like Figure 1 As shown, the method may include the following steps: Step 110: Using Debian's multi-arch architecture integration technology, declare multi-architecture support in the control file of the deb package, and use the architecture dynamic loader to perform differentiated driving loading to obtain the ACPI testing tool. Deploy components for the target system's architecture based on the ACPI testing tool.

[0026] One possible implementation involves using Debian-based multi-arch architecture integration technology. In the DEBIAN / control file of the deb package, a combined declaration of Multi-Arch: foreign and Architecture: any is used to construct an architecture-aware dependency tree. The architecture dynamic loader then dynamically loads the corresponding kernel driver module based on the CPU type of the target system to perform cross-platform deployment of a single deb package.

[0027] The CPU types include x86_64, aarch64, etc., and the kernel driver modules include x86's ioctrl.ko, ARM's gic-interface.ko, etc., without any specific restrictions.

[0028] In one possible implementation, the postinst script uses the ACPI testing tool to obtain the architecture identifier of the target system via the dpkg --print-architecture command, and selectively deploys the ACPI table parsing engine and dedicated driver based on the architecture identifier.

[0029] Specifically, multi-architecture support is declared: The `DEBIAN / control` file of the deb package uses a combination of `Multi-Arch:foreign` and `Architecture: any` declarations to build an architecture-aware dependency tree. This step ensures that the deb package can automatically identify and install the required components on systems with different architectures. Dynamic loading of differentiated drivers: Through a self-developed architecture dynamic loader, the corresponding kernel driver module (such as `ioctrl.ko` for x86 and `gic-interface.ko` for ARM) is dynamically loaded based on the target system's CPU type (such as x86_64 and aarch64). This step enables cross-platform deployment of a single deb package without requiring users to manually select the version.

[0030] In building cross-architecture compatible tools, this invention ensures that the testing tools can run seamlessly on various hardware architectures through refined architecture declarations and dynamic loading mechanisms. This design not only simplifies the deployment process but also improves the versatility and flexibility of the tools.

[0031] In the above process, the embodiments of the present invention, by declaring multi-architecture support and dynamically loading differentiated drivers, enable the same deb package to automatically identify and install the required components on systems with different architectures, providing cross-platform compatibility and achieving seamless compatibility of "package once, run on multiple platforms".

[0032] Step 120: Identify the operating system type and kernel version of the target system using the ACPI testing tool, adjust the parsing logic of the ACPI table and the driver calling method according to the characteristics of the operating system type and kernel version, and update the ACPI testing tool.

[0033] In one possible implementation, the operating system type and kernel version of the target system are dynamically detected using ACPI testing tools, and system information is obtained by parsing the target system version file and configuration file; the ACPI table parsing logic and driver calling method are adjusted based on the customized features corresponding to the system information and kernel version.

[0034] The operating system types include UOS, Kylin, etc., without any specific restrictions.

[0035] Specifically, the system identifies the operating system type and kernel version: The ACPI testing tool dynamically detects the target system's operating system type (e.g., UOS, Kylin) and kernel version, obtaining detailed system information by parsing system version files and configuration files. The ACPI table parsing logic and driver invocation method are then adjusted: Based on the customized features corresponding to the system information and kernel version, the ACPI table parsing logic and driver invocation method are dynamically adjusted to ensure the testing tool can accurately adapt to different operating system environments.

[0036] In the process of operating system adaptation and updates, this invention ensures the accuracy and reliability of the testing tool on different operating systems by dynamically detecting the system environment and adjusting the testing logic. This design not only improves test compatibility but also reduces testing errors caused by system differences.

[0037] In the above process, the embodiments of the present invention identify the operating system type and kernel version, and dynamically adjust the ACPI table parsing logic and driver calling method, so that the testing tool can accurately adapt to different operating system environments, providing high compatibility and accuracy, and ensuring reliable test results.

[0038] Step 130: Obtain ACPI functional test items through the interactive interface, configure automation parameters to generate test files, and perform synchronous and sequential testing with the ACPI testing tool to generate test logs.

[0039] The test items include S3 sleep, hot start, etc., and the automation parameters include the number of test cycles, waiting time, etc., none of which are specified here.

[0040] In one possible implementation, the ACPI functional test items are determined and automation parameters are set through human-computer interaction via a front-end configurator, and synchronization is achieved through a real-time two-way binding mechanism. During testing, the test items and automation parameters are parsed into a test structure file in memory, and the serial tests are executed in the order of the test items in the test structure file.

[0041] Specifically, the interactive interface obtains test items and parameters: Human-computer interaction is performed through the front-end configurator to determine ACPI functional test items (such as S3 sleep and warm start) and set automation parameters (such as test cycles and waiting time). Test files are generated and cascaded tests are executed: Test items and automation parameters are parsed into test structure files in memory, and cascaded tests are executed according to the order of test items in the test structure files, generating detailed test logs.

[0042] In the interactive test configuration and execution process, this invention enables users to easily customize test plans through an intuitive interface and flexible parameter configuration. Meanwhile, the sequential testing design ensures the continuity and efficiency of the test process, thereby improving testing efficiency.

[0043] In the above process, the embodiments of the present invention obtain test items and parameters through an interactive interface, and generate test files to execute serial tests, enabling users to flexibly customize test plans, providing an efficient test process, and achieving a significant improvement in test efficiency.

[0044] Step 140: The test logs are transmitted to the UI process in real time, and the device status is automatically refreshed by listening to the file. If a device is lost or its performance degrades, a pop-up alarm is immediately triggered and the test is paused, generating an analysis report with timestamps and exception types.

[0045] In one possible implementation, test logs are transmitted to the UI process in real time via named pipes, the device status comparison table is refreshed by listening for file changes, and the device status is reflected by the SIGUSR1 signal.

[0046] In one possible implementation, when the device status is abnormal, the test is paused, and an analysis report containing timestamps and exception types is generated based on the device status comparison table and test logs, and formatted as a JSON or text file.

[0047] The status comparison table includes keyboard status, Wi-Fi module status, etc., and the analysis report includes device name, abnormal time and specific problem, etc., without any restrictions.

[0048] Specifically, real-time log transmission to the UI process: Test logs are transmitted to the UI process in real time via named pipes, ensuring users can view test progress and results promptly. Automatic device status refresh upon file change monitoring: The device status comparison table file is monitored for changes, and the device status is automatically refreshed. A pop-up alarm is immediately triggered when a device anomaly is detected. Analysis reports with timestamps and anomaly types are generated: Analysis reports with timestamps and anomaly types are generated based on the device status comparison table and test logs, and formatted as JSON or text files for easy subsequent problem localization and analysis.

[0049] In the process of real-time log transmission and device monitoring, this invention ensures the transparency and controllability of the testing process through real-time log transmission and device status monitoring. Simultaneously, the anomaly detection and report generation mechanism enables users to quickly locate problems and take corresponding solutions, improving testing reliability and maintenance efficiency.

[0050] In the above process, the embodiments of the present invention transmit real-time logs to the UI process, automatically refresh the device status by monitoring file changes, and generate analysis reports containing timestamps and exception types, enabling users to understand the test progress and results in a timely manner, providing comprehensive test monitoring and problem localization capabilities, and improving the reliability and maintenance efficiency of the test process.

[0051] Through the above process, this embodiment of the invention achieves comprehensive testing of ACPI functionality in multi-architecture and multi-operating system environments by building cross-architecture compatible tools, adapting and updating operating systems, configuring and executing interactive tests, and transmitting real-time logs and monitoring devices. This method not only improves test compatibility and accuracy but also simplifies the testing process and increases testing efficiency, providing an effective solution for ACPI testing of domestically developed systems and ARM architectures.

[0052] In one application scenario, testers used the cross-architecture ACPI testing method of this invention to conduct cross-architecture ACPI testing on a domestically produced computer (running the UOS operating system) equipped with a Phytium ARM processor.

[0053] Specifically, it may include the following steps: Step S1: Environment preparation and tool installation.

[0054] Specifically, download the multi-architecture compatible ACPI testing tool .deb package from official channels. Install the package through the UOS system's software center or the command-line tool dpkg. During the installation process, the postinst script automatically detects the current system architecture as ARM64 and deploys the corresponding ACPI table parsing engine (such as GTDT or IORT table parser) and PSCI call interface driver.

[0055] The ACPI testing tool employs multi-architecture technology, supporting both x86 and ARM architectures within a unified .deb package. In the DEBIAN / control file of the .deb package, a combination of `Multi-Arch: foreign` and `Architecture: any` is used to declare and construct an architecture-aware dependency tree, ensuring that the tool can automatically deploy the necessary binaries and drivers on different architectures.

[0056] Furthermore, the self-developed architecture-specific driver loader dynamically loads the corresponding kernel driver at runtime based on the current system architecture (such as by detecting it through the uname -m command). For example, it loads ioctrl.ko for x86 architecture and gic-interface.ko for ARM architecture, achieving seamless compatibility.

[0057] In the above process, the embodiments of the present invention achieve seamless deployment of a single deb package across architectures through multi-arch technology and conditional installation logic.

[0058] Step S2: Test configuration.

[0059] Specifically, testers open the front-end configuration interface of the testing tool, select test items according to requirements, including S3 sleep, S4 hibernation, and Reboot restart tests. They set the automated test cycle to 5 times, the waiting time in S0 state to 30 seconds, and enable continuous test mode. After configuration, all parameters are synchronized to the test_profile.yml file via a real-time two-way binding mechanism.

[0060] This tool is deeply adapted for domestic operating systems (such as UOS and Kylin OS). During installation, the postinst script uses the `dpkg --print-architecture` command to obtain the current system architecture information and deploys a differentiated ACPI table parsing engine based on the architecture. For example, on the ARM64 architecture, it deploys an engine that supports GTDT, IORT, and BGRT table parsing and loads the ARM64-specific PSCI call interface driver.

[0061] Furthermore, the tool dynamically detects the operating system environment (such as reading the / etc / os-release file) and automatically adapts to different system versions and kernel features, ensuring the accuracy and reliability of the test results.

[0062] Step S3: Perform tests and monitoring.

[0063] Specifically, after clicking the "Start Test" button, the testing tool executes the test sequence according to the configuration file test_runner.c. The test execution monitor receives test logs in real time via named pipes and displays the test progress and results on the interface. A device inventory comparison mechanism automatically checks the status of devices such as the keyboard, mouse, and Wi-Fi before and after each round of testing to ensure consistency of the test environment. If a device anomaly is detected, an error report is immediately generated and the test is paused.

[0064] Users can flexibly select test items through the front-end configurator interface, including but not limited to ACPI function tests such as S3 sleep, S4 hibernation, Reboot restart, WarmBoot power on / off, and ColdBoot power off / off.

[0065] Furthermore, users can configure automated testing parameters, such as the number of automated test cycles (supporting multiple consecutive tests), the waiting time in S0 state (simulating real-world usage scenarios), and the continuous testing mode (supporting the automatic sequential execution of multiple test items). After configuration, all parameters are synchronized to the test_profile.yml file via a real-time two-way binding mechanism, driving test_runner.c to execute the test sequence.

[0066] Step S4: Results Analysis and Reporting.

[0067] Specifically, after the test is completed, the testers review the automatically generated test log file, which contains basic information about the entire device, test records for each round, and device comparison results. Based on the anomalies in the log, they locate the cause of the problem. For example, if the Wi-Fi module fails to load properly after a certain S3 sleep test, further analysis using the device comparison table reveals a driver compatibility issue. A detailed test report is then generated and submitted to the development team for fixing.

[0068] During the testing process, the tool automatically generates test log files containing rich information, including basic information about the whole machine (such as operating system version, kernel version, and hardware configuration), test records (number of rounds, time, results, and abnormal information for each test round), and a device comparison table (comparison of the status of key devices before and after the test).

[0069] Furthermore, the tool has a built-in device list comparison mechanism that monitors the status of devices such as keyboards, mice, Wi-Fi, Bluetooth, hard drives, and network cards in real time. Once a device abnormality is detected (such as a device being lost or its performance degrading), an error report is immediately generated and the test is paused to avoid further risks.

[0070] Through the above process, this embodiment of the invention describes the entire process of performing ACPI functional testing using a multi-architecture compatible ACPI testing tool on a domestically produced computer equipped with a Phytium ARM processor. From environment preparation and tool installation, test configuration, test execution and monitoring to result analysis and reporting, each step demonstrates the advantages of this embodiment of the invention in cross-architecture compatibility, automated testing, and device status monitoring. Through multi-architecture technology and conditional installation logic, seamless deployment of a single deb package on different architecture systems is achieved; the combination of the front-end configurator and the test execution monitor improves testing efficiency and user experience; detailed test logs and device comparison mechanisms provide strong support for problem localization and repair.

[0071] The following are embodiments of the apparatus of the present invention, which can be used to execute the cross-architecture ACPI testing method involved in the present invention. For details not disclosed in the embodiments of the apparatus of the present invention, please refer to the method embodiments of the cross-architecture ACPI testing method involved in the present invention.

[0072] Please see Figure 2 This invention provides a cross-architecture ACPI testing device 800.

[0073] The cross-architecture ACPI testing device 800 includes, but is not limited to: a multi-architecture tool building module 810, a system feature adaptation module 830, a test item configuration execution module 850, and an anomaly real-time monitoring module 870.

[0074] Among them, the multi-architecture tool building module 810 is used to declare multi-architecture support in the control file of the deb package through the Debian-based multi-architecture fusion technology, and to obtain the ACPI test tool through differential driving loading by the architecture dynamic loader, and to deploy components for the target system architecture based on the ACPI test tool.

[0075] The system feature adaptation module 830 is used to identify the operating system type and kernel version of the target system through the ACPI testing tool, adjust the parsing logic of the ACPI table and the driver calling method according to the characteristics of the operating system type and kernel version, and update the ACPI testing tool.

[0076] The test item configuration execution module 850 is used to obtain ACPI functional test items through the interactive interface, configure automation parameters to generate test files, and synchronously execute the test files with the ACPI testing tool to generate test logs. Test items include S3 sleep and warm start; automation parameters include test cycle count and waiting time.

[0077] The 870 real-time anomaly monitoring module transmits test logs to the UI process in real time and automatically refreshes device status changes by listening to files. If device loss or performance degradation is detected, it immediately triggers a pop-up alarm and pauses the test, generating an analysis report containing timestamps and anomaly types.

[0078] It should be noted that the cross-architecture ACPI test provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the cross-architecture ACPI test device will be divided into different functional modules to complete all or part of the functions described above.

[0079] Furthermore, the cross-architecture ACPI testing apparatus and the cross-architecture ACPI testing method provided in the above embodiments belong to the same concept, and the specific way in which each module performs its operation has been described in detail in the method embodiments, and will not be repeated here.

[0080] Figure 3 A schematic diagram of the structure of an electronic device according to an exemplary embodiment is shown.

[0081] It should be noted that this electronic device is merely an example adapted to the present invention and should not be construed as providing any limitation on the scope of use of the present invention. Furthermore, this electronic device should not be interpreted as requiring or depending on having... Figure 3 One or more components of the exemplary electronic device 2000 shown.

[0082] The hardware structure of electronic devices 2000 can vary significantly due to differences in configuration or performance, such as... Figure 3 As shown, the electronic device 2000 includes: a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0083] Specifically, power supply 210 is used to provide operating voltage for various hardware devices on electronic device 2000.

[0084] Interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. Of course, in other examples adapted to this invention, interface 230 may further include at least one serial-to-parallel conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc. Figure 3 As shown, this does not constitute a specific limitation.

[0085] The memory 250 serves as a carrier for resource storage and can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it include the operating system 251, application programs 253, and data 255, etc., and the storage method can be temporary storage or permanent storage.

[0086] The operating system 251 is used to manage and control the various hardware devices and application programs 253 on the electronic device 2000, so as to enable the central processing unit 270 to perform calculations and processing on the massive data 255 in the memory 250. It can be Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0087] Application 253 is a computer-readable instruction based on operating system 251 that performs at least one specific task, and may include at least one module ( Figure 3 (Not shown), each module may contain computer-readable instructions for electronic device 2000. For example, a cross-architecture ACPI test apparatus can be considered as application 253 deployed on electronic device 2000.

[0088] Data 255 may be signal information, etc., and is stored in memory 250.

[0089] The central processing unit 270 may include one or more processors and is configured to communicate with the memory 250 via at least one communication bus to read computer-readable instructions stored in the memory 250, thereby performing operations and processing on massive amounts of data 255 stored in the memory 250. For example, a cross-architecture ACPI testing method can be performed by having the central processing unit 270 read a series of computer-readable instructions stored in the memory 250.

[0090] Furthermore, the present invention can also be implemented through hardware circuits or a combination of hardware circuits and software. Therefore, the implementation of the present invention is not limited to any specific hardware circuit, software, or combination thereof.

[0091] Please see Figure 4 This invention provides an electronic device 4000, which may include: a desktop computer, a laptop computer, a server, etc., with sensor recognition capabilities.

[0092] exist Figure 4 In this context, the electronic device 4000 includes at least one processor 4001 and at least one memory 4003.

[0093] The data interaction between the processor 4001 and the memory 4003 can be achieved through at least one communication bus 4002. This communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0094] Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0095] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0096] The memory 4003 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program instructions or code in the form of instructions or data structures and accessible by the electronic device 4000, but not limited thereto.

[0097] The memory 4003 stores computer-readable instructions, and the processor 4001 can read the computer-readable instructions stored in the memory 4003 through the communication bus 4002.

[0098] The computer-readable instructions are executed by one or more processors 4001 to implement the cross-architecture ACPI testing methods in the above embodiments.

[0099] Furthermore, this embodiment of the invention provides a storage medium storing computer-readable instructions that are executed by one or more processors to implement the cross-architecture ACPI testing method described above.

[0100] This invention provides a computer program product including computer-readable instructions stored in a storage medium. One or more processors of an electronic device read the computer-readable instructions from the storage medium, load and execute the computer-readable instructions, thereby enabling the electronic device to implement the cross-architecture ACPI testing method as described above.

[0101] Compared with related technologies, the beneficial effects of the present invention are: 1. This invention improves testing efficiency and compatibility. By employing multi-architecture technology, it supports both x86 and ARM architectures within a unified .deb package, resolving the insufficient ARM architecture support issue of existing ACPI testing tools. Users only need to install one package to run tests on different hardware architectures and operating systems without manually selecting versions, achieving seamless compatibility of "one-time packaging, multi-platform operation" and significantly improving testing efficiency.

[0102] 2. This invention has broad operating system compatibility; by dynamically detecting the operating system environment and automatically adapting to different system versions and kernel features, this tool is fully compatible with domestic operating systems (such as UOS and Kylin system); this feature ensures the accuracy and reliability of test results and solves the compatibility problems that may occur when existing tools run on domestic systems.

[0103] 3. This invention provides flexible and user-friendly testing options; it supports various ACPI function tests, including S3 sleep, S4 hibernation, and Reboot, and allows users to set automated testing parameters according to their needs, such as the number of test cycles, waiting time, and continuous testing mode. Meanwhile, the front-end configurator interface is simple and intuitive, lowering the barrier to entry for ordinary users and improving the user experience.

[0104] 4. This invention enables detailed test logs and equipment status monitoring; during testing, it automatically generates test log files containing rich information, including basic information about the entire machine, test records, and equipment comparison tables. The built-in equipment list comparison mechanism can monitor the status of key equipment in real time, and immediately generate an error report and pause the test upon detecting an anomaly, effectively avoiding test risks and improving the stability and security of the test.

[0105] 5. This invention promotes cross-platform unified testing capabilities; with the diversified development of domestically produced systems, the differences between different hardware platforms and operating systems are becoming increasingly apparent. This tool achieves cross-platform unified testing through a single deb package, avoiding the hassle of users switching between different tools in multi-platform environments, reducing testing costs, and improving testing efficiency.

[0106] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0107] The above description is only a partial embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A cross-architecture ACPI testing method, characterized in that, The method includes: By using Debian's multi-arch architecture integration technology, multi-architecture support is declared in the control file of the deb package, and ACPI testing tools are obtained through differential driving loading via architecture dynamic loader. The ACPI testing tools are then used as the architecture deployment components for the target system. The ACPI testing tool identifies the operating system type and kernel version of the target system, adjusts the parsing logic of the ACPI table and the driver calling method according to the characteristics of the operating system type and kernel version, and updates the ACPI testing tool. The ACPI functional test items are obtained through the interactive interface, and the automation parameters are configured to generate test files. The test files are then synchronously executed with the ACPI testing tool for in-line testing, generating test logs. The test items include S3 sleep and warm start. The automation parameters include the number of test cycles and the waiting time. The test logs are transmitted to the UI process in real time, and the device status is automatically refreshed by listening to the file. If a device is lost or its performance degrades, a pop-up alarm is immediately triggered and the test is paused, generating an analysis report with timestamps and exception types.

2. The cross-architecture ACPI testing method as described in claim 1, characterized in that, The aforementioned multi-architecture integration technology, utilizing Debian-based architectures, declares multi-architecture support in the control file of the deb package and uses a dynamic architecture loader to perform differentiated loading to obtain the ACPI testing tool, including: By using Debian-based multi-arch architecture integration technology, an architecture-aware dependency tree is constructed by combining the declarations of Multi-Arch: foreign and Architecture: any in the DEBIAN / control file of the deb package. A single deb package is used for cross-platform deployment by dynamically loading the corresponding kernel driver module according to the CPU type of the target system using an architecture dynamic loader; the CPU types include x86_64 and aarch64; the kernel driver modules include ioctrl.ko for x86 and gic-interface.ko for ARM.

3. The cross-architecture ACPI testing method as described in claim 1, characterized in that, The architecture deployment components for the target system based on the ACPI testing tool include: In the postinst script, the ACPI testing tool is used to obtain the architecture identifier of the target system through the dpkg --print-architecture command, and the ACPI table parsing engine and dedicated driver are selectively deployed according to the architecture identifier.

4. The cross-architecture ACPI testing method as described in claim 1, characterized in that, The step of identifying the operating system type and kernel version of the target system using the ACPI testing tool, adjusting the ACPI table parsing logic and driver calling method according to the characteristics of the operating system type and kernel version, and updating the ACPI testing tool includes: The ACPI testing tool dynamically detects the operating system type and kernel version of the target system, and obtains system information by parsing the target system version file and configuration file. The ACPI table parsing logic and driver invocation method are adjusted based on the system information and the customized features corresponding to the kernel version; the operating system type includes UOS and Kylin.

5. The cross-architecture ACPI testing method as described in claim 1, characterized in that, The process involves obtaining ACPI functional test items through an interactive interface, configuring automated parameters to generate test files, synchronously executing the test files and the ACPI testing tool for in-line testing, and generating test logs, including: The ACPI function test items are determined and automation parameters are set through human-computer interaction via the front-end configurator, and synchronization is performed through a real-time two-way binding mechanism. During testing, the test items and automation parameters are parsed into a test structure file in memory, and the serial tests are executed in the order of the test items in the test structure file.

6. The cross-architecture ACPI testing method as described in claim 1, characterized in that, The step of transmitting the test logs to the UI process in real time and automatically refreshing device status changes by listening to file updates includes: The test logs are transmitted to the UI process in real time via named pipes. The device status comparison table is refreshed by listening for file changes, and the device status is reflected by the SIGUSR1 signal. The status comparison table includes keyboard status and Wi-Fi module status.

7. The cross-architecture ACPI testing method as described in claim 6, characterized in that, If device loss or performance degradation is detected, a pop-up alarm will be triggered immediately, the test will be paused, and an analysis report containing timestamps and anomaly types will be generated, including: When the device status is abnormal, the test is paused. An analysis report containing timestamps and abnormality types is generated based on the device status comparison table and the test log, and formatted as a JSON or text file. The analysis report includes the device name, abnormal time, and specific problem.

8. A cross-architecture ACPI testing device, characterized in that, The device includes: The multi-architecture tool building module is used to declare multi-architecture support in the control file of the deb package through the Debian-based multi-architecture integration technology, and to obtain the ACPI test tool through differential driving loading by the architecture dynamic loader. The ACPI test tool is then used as the architecture deployment component for the target system. The system feature adaptation module is used to identify the operating system type and kernel version of the target system through the ACPI testing tool, adjust the parsing logic of the ACPI table and the driver calling method according to the characteristics of the operating system type and kernel version, and update the ACPI testing tool. The test item configuration execution module is used to obtain ACPI functional test items through an interactive interface, configure automation parameters to generate test files, and perform synchronous and serial testing with the ACPI testing tool to generate test logs; the test items include S3 sleep and warm start; the automation parameters include test cycle number and waiting time; The real-time anomaly monitoring module is used to transmit the test logs to the UI process in real time and automatically refresh the device status changes by listening to the file. If a device loss or performance degradation is detected, a pop-up alarm is immediately triggered and the test is paused, generating an analysis report containing timestamps and anomaly types.

9. An electronic device, characterized in that, include: At least one processor and at least one memory, wherein, The memory stores computer-readable instructions; The computer-readable instructions are executed by one or more of the processors, causing the electronic device to implement the cross-architecture ACPI test method as described in any one of claims 1 to 7.

10. A storage medium having computer-readable instructions stored thereon, characterized in that, The computer-readable instructions are executed by one or more processors to implement the cross-architecture ACPI testing method as described in any one of claims 1 to 7.

Images