Hardware recovery method and apparatus upon wake from low power state

Abstract

The application provides a hardware recovery method and device when a low-power state is woken up, the method comprising: in a UEFI stage of normal starting of an ARM PC platform, loading an S3 hardware recovery script generation driver, capturing and recording hardware operation instructions required for S3 state wake-up to generate a hardware recovery script; performing security protection processing on the hardware recovery script to obtain security protection information, and notifying a firmware execution unit of the ARM PC platform of storage location information of the hardware recovery script and the security protection information; when in an S3 state wake-up stage, reading the hardware recovery script and verifying the legality of the security protection information and the effectiveness of each hardware operation instruction in the hardware recovery script; and executing the hardware operation instructions in the hardware recovery script according to a preset execution sequence to complete ARM PC platform wake-up after hardware state is recovered. The application solves the problem of lack of a standardized hardware recovery mechanism in the existing ARM PC platform.

Description

Technical Field

[0001] This application relates to the field of ARM PC platform technology, and more specifically, to a hardware recovery method and apparatus for waking up from a low-power state. Background Technology

[0002] Currently, the ARM architecture is widely used in the mobile terminal field due to its high energy efficiency and is gradually penetrating the PC ecosystem. However, it still faces significant challenges in the hardware state recovery mechanism for low-power wake-up.

[0003] The S3 wake-up process on the ARM platform relies on the System Management Unit (SMU) or dedicated firmware within the System-on-Chip (SoC), completely skipping the UEFI phase. However, existing mature technologies record and execute hardware operation instructions for hardware recovery during S3 wake-up in the UEFI phase. This results in the ARM platform's S3 wake-up process lacking a UEFI execution environment and a unified hardware recovery scheme, leading to a lack of standardized hardware recovery mechanisms. Secondly, existing ARM platform hardware recovery mechanisms are mostly vendor-specific implementations. The firmware logic and register storage methods of different brands of SoCs vary significantly, making it difficult to create a unified scripting approach and resulting in poor compatibility of vendor-specific implementations. These shortcomings can easily lead to the incomplete recovery of complex devices such as PCIe controllers, I²C peripherals, and embedded controllers during the wake-up phase, easily causing device initialization failures and severely impacting the promotion and application of ARM SoCs in the PC ecosystem. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a hardware recovery method and apparatus for waking up from a low-power state, so as to solve at least one of the above-mentioned problems.

[0005] In a first aspect, embodiments of this application provide a hardware recovery method during low-power state wake-up, applied to an ARM PC platform, the method comprising:

[0006] During the UEFI phase of normal startup on the ARM PC platform, the S3 hardware recovery script generation driver is loaded. The S3 hardware recovery script generation driver is used to capture and record the hardware operation instructions required for S3 state wake-up to generate an executable hardware recovery script. The hardware recovery script is stored in a non-volatile memory area.

[0007] The S3 hardware recovery script generation driver is used to perform security protection processing on the hardware recovery script to obtain security protection information. Before exiting the UEFI stage, the S3 hardware recovery script generation driver is used to notify the firmware execution unit of the ARM PC platform of the storage location information of the hardware recovery script and the security protection information, so that the hardware recovery script enters the executable ready state.

[0008] When the ARM PC platform is in the S3 wake-up phase, the firmware execution unit of the ARM PC platform reads the hardware recovery script in the executable ready state according to the notified storage location information and verifies the legality of the security protection information and the validity of each hardware operation instruction in the hardware recovery script; wherein, the S3 wake-up phase does not include the UEFI phase.

[0009] When the security protection information is valid and all hardware operation instructions are effective, the firmware execution unit of the ARM PC platform executes the hardware operation instructions in the hardware recovery script in a preset execution order to complete the ARM PC platform wake-up after restoring the hardware state.

[0010] In one optional embodiment, during the UEFI phase of normal startup on the ARM PC platform, loading the S3 hardware recovery script generation driver, and using the S3 hardware recovery script generation driver to capture and record the hardware operation instructions required for S3 state wake-up to generate an executable hardware recovery script, includes:

[0011] During the UEFI phase of normal startup on the ARM PC platform, the S3 hardware recovery script generation driver is loaded. The S3 hardware recovery script generation driver is used to initialize the resources required for hardware recovery script recording and provide a hardware operation instruction recording interface to allocate memory areas in the non-volatile storage area and create script data structures.

[0012] The S3 hardware recovery script is used to generate a driver that captures and records the hardware operation instructions required for S3 state wake-up, and stores the hardware operation instructions in the memory area according to the script data structure to generate an executable hardware recovery script.

[0013] In one optional embodiment, the step of using the S3 hardware recovery script to generate a driver that captures and records the hardware operation instructions required for S3 state wake-up, and storing the hardware operation instructions in the memory area according to the script data structure to generate an executable hardware recovery script includes:

[0014] The S3 hardware recovery script is used to generate the driver to capture the hardware operation instructions required for S3 state wake-up. After each capture, it is determined whether the memory area has sufficient space.

[0015] If the memory area has sufficient space, the currently captured hardware operation instructions are stored in the memory area according to the script data structure to generate an executable hardware recovery script.

[0016] If the memory area is insufficient, an additional non-volatile storage area is requested through a dynamic expansion mechanism. Then, the currently captured hardware operation instructions are stored in the additional non-volatile storage area according to the script data structure to generate an executable hardware recovery script.

[0017] In one optional embodiment, the script data structure includes an instruction type area, an operation parameter area, a verification information area, and a management and control information area, wherein the management and control information includes the script version number, the number of instructions, and the storage address boundaries.

[0018] In one optional embodiment, the security protection process includes one of the following:

[0019] RSA signature method, ECDSA signature method, HMAC verification method, and TPM encapsulation method.

[0020] In an optional embodiment, the step of executing the hardware operation instructions in the hardware recovery script according to a preset execution order using the firmware execution unit of the ARM PC platform when the security protection information is legal and all hardware operation instructions are valid, so as to complete the ARM PC platform wake-up after restoring the hardware state, includes:

[0021] The hardware recovery script is parsed according to hardware dependencies and a preset execution order is determined.

[0022] The firmware execution unit of the ARM PC platform is invoked to execute the hardware operation instructions in the hardware recovery script according to the preset execution order. After the execution is completed, the status of key registers and peripherals is checked to verify the recovery result. After confirming that the hardware status has been restored to the target expected state, the ARM PC platform wake-up is completed.

[0023] In one optional embodiment, the firmware execution unit of the ARM PC platform includes one of the following: a system management unit, boot loading firmware, and secure execution environment firmware.

[0024] In an optional embodiment, when the firmware execution unit of the ARM PC platform is a system management unit, the method further includes:

[0025] After confirming that the hardware state has been restored to the target expected state, a completion signal for the S3 state wake-up phase is sent to the system management unit, and the completion signal indicates that the hardware state restoration is complete.

[0026] After receiving the completion signal, the system management unit notifies the ARM PC platform to continue the subsequent wake-up process to complete the wake-up of the ARM PC platform from the S3 state to the normal operation state.

[0027] In one optional embodiment, the non-volatile storage area includes one of the following: an advanced configuration and power interface non-volatile storage area, a reserved memory area, a persistent memory area, flash memory, non-volatile random access memory, a trusted platform module of the ARM PC platform, and a security element of the ARM PC platform.

[0028] Secondly, embodiments of this application also provide a hardware recovery device for low-power state wake-up, comprising:

[0029] The script building module is used to load the S3 hardware recovery script generation driver during the UEFI phase of normal startup on the ARM PC platform. The S3 hardware recovery script generation driver is used to capture and record the hardware operation instructions required for S3 state wake-up to generate an executable hardware recovery script; wherein, the hardware recovery script is stored in a non-volatile memory area.

[0030] The security processing module is used to perform security protection processing on the hardware recovery script using the S3 hardware recovery script generation driver to obtain security protection information, and before exiting the UEFI stage, use the S3 hardware recovery script generation driver to notify the firmware execution unit of the ARM PC platform of the storage location information of the hardware recovery script and the security protection information, so that the hardware recovery script enters the executable ready state.

[0031] The wake-up notification module, when the ARM PC platform is in the S3 wake-up phase, uses the firmware execution unit of the ARM PC platform to read the hardware recovery script in the executable ready state according to the notified storage location information and verify the legality of the security protection information and the validity of each hardware operation instruction in the hardware recovery script; wherein, the S3 wake-up phase does not include the UEFI phase.

[0032] The wake-up execution module is used to execute the hardware operation instructions in the hardware recovery script in a preset execution order using the firmware execution unit of the ARM PC platform when the security protection information is legal and all hardware operation instructions are valid, so as to complete the wake-up of the ARM PC platform after restoring the hardware state.

[0033] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the hardware recovery method for low-power state wake-up described above are performed.

[0034] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the hardware recovery method for low-power state wake-up described above.

[0035] The hardware recovery method and apparatus for low-power state wake-up provided in this application overcomes the limitation that the complete process of ARM architecture system-on-a-chip devices waking up from the S3 low-power state and restoring normal operation does not execute UEFI by generating a hardware recovery script during the UEFI phase of normal startup on the ARM PC platform and storing it in a non-volatile storage area. Combined with the execution of the script by the firmware execution unit during the S3 wake-up phase (skipping the UEFI phase), this solves the technical problems of existing ARM PC platforms lacking standardized hardware recovery mechanisms and having poor compatibility with vendor-specific implementations. At the same time, the integrity and immutability of the script are ensured through security protection processing. This not only achieves effective recovery of SoC hardware and platform devices, but also improves the system's compatibility, stability, and security, which is conducive to the promotion and application of ARM architecture system-on-a-chip devices on the PC platform.

[0036] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 A flowchart illustrating a hardware recovery method for low-power state wake-up provided in an embodiment of this application;

[0039] Figure 2 A schematic diagram illustrating the normal startup and wake-up process of an ARM PC platform provided in an embodiment of this application;

[0040] Figure 3A schematic diagram of a hardware recovery device for low-power wake-up provided in an embodiment of this application;

[0041] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0043] Please see Figure 1 , Figure 1 This is a flowchart illustrating a hardware recovery method for low-power state wake-up provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the method includes:

[0044] Step S101: During the UEFI phase of normal startup on the ARM PC platform, load the S3 hardware recovery script generation driver, use the S3 hardware recovery script generation driver to capture and record the hardware operation instructions required for S3 state wake-up, so as to generate an executable hardware recovery script; wherein, the hardware recovery script is stored in a non-volatile memory area.

[0045] Step S102: Use the S3 hardware recovery script generation driver to perform security protection processing on the hardware recovery script to obtain security protection information. Before exiting the UEFI stage, use the S3 hardware recovery script generation driver to notify the firmware execution unit of the ARM PC platform of the storage location information and security protection information of the hardware recovery script so that the hardware recovery script enters the executable ready state.

[0046] Step 103: When the ARM PC platform is in the S3 wake-up phase, the firmware execution unit of the ARM PC platform reads the hardware recovery script in the executable ready state according to the notified storage location information and verifies the legality of the security protection information and the validity of each hardware operation instruction in the hardware recovery script; wherein, the S3 wake-up phase does not include the UEFI phase.

[0047] Step S104: If the security protection information is legal and all hardware operation instructions are valid, the firmware execution unit of the ARMPC platform executes the hardware operation instructions in the hardware recovery script according to the preset execution order, so as to complete the ARMPC platform wake-up after restoring the hardware state.

[0048] The method provided in this application generates a hardware recovery script during the UEFI phase of a normal startup on an ARM PC platform and stores it in a non-volatile storage area. Combined with the execution of the script by the firmware execution unit during the S3 wake-up phase (skipping the UEFI phase), this method overcomes the limitation that the complete process of ARM architecture system-on-a-chip devices waking up from the S3 low-power state and resuming normal operation does not execute UEFI. This solves the technical problems of existing ARM PC platforms lacking standardized hardware recovery mechanisms and having poor compatibility with vendor-specific implementations. At the same time, the method ensures the integrity and immutability of the script through security protection processing. This not only achieves effective recovery of SoC hardware and platform devices but also improves the system's compatibility, stability, and security, which is conducive to the promotion and application of ARM architecture system-on-a-chip devices on PC platforms.

[0049] The steps described above are explained in detail below:

[0050] In step S101, during the UEFI phase of the ARM PC platform's normal startup, the S3 hardware recovery script generation driver is loaded. The S3 hardware recovery script generation driver is used to capture and record the hardware operation instructions required for S3 state wake-up to generate an executable hardware recovery script. The hardware recovery script is stored in a non-volatile memory area.

[0051] Here, the ARM PC platform is a personal computer hardware platform built using a system-on-a-chip (SoC) based on the ARM architecture. This platform integrates core hardware modules such as a processor, memory controller, and peripheral interfaces. Figure 2 As shown, its normal startup process is as follows: System Management Unit 201 initialization → Secondary Boot Loading Firmware 202 boot loading → Security Monitoring Firmware 203 execution → Unified Extensible Firmware Interface initialization phase 204 running → Operating System startup. For example, an ARM PC platform may include an ARM architecture processor, PCIe controller, I²C / SPI peripheral interface, embedded controller, etc., and has low-power operation and S3 sleep / wake-up capabilities.

[0052] The Unified Extensible Firmware Interface (UEFI) initialization phase is the system startup phase corresponding to the UEFI. This phase starts after the security monitoring firmware 203 is executed. Its main functions include hardware initialization, driver loading, and booting the operating system. It is a key link connecting the hardware and the operating system.

[0053] Optionally, the UEFI stage can achieve hardware management by running UEFI firmware. This stage provides standardized driver interfaces and memory management mechanisms, supporting the loading and running of third-party drivers. For example, the UEFI stage of the aforementioned ARM laptop initializes the memory controller, configures PCIe bus parameters, and loads UEFI drivers for peripherals such as the keyboard and graphics card, preparing for the operating system to boot.

[0054] Among them, the S3 hardware recovery script generation driver is a dedicated software module that runs in the UEFI stage. It is used to capture and record the hardware operation instructions required for S3 state wake-up, generate hardware recovery scripts, and provide relevant interfaces for script storage, security protection, and notification to the firmware execution unit.

[0055] In an optional implementation, after the S3 hardware recovery script generation driver is loaded during the UEFI phase, it initializes the memory resources required for script recording, creates script data structures, and provides an interface for recording operation instructions to the platform firmware and other peripheral drivers. For example, after the S3 hardware recovery script generation driver is loaded, it registers the supported hardware device types. When other drivers perform hardware configuration operations, they can write operation instructions into the hardware recovery script through this interface.

[0056] Specifically, the hardware operation instructions required for S3 state wake-up refer to the hardware configuration-related instructions that need to be executed when the ARM PC platform recovers from the S3 low-power state to the normal operating state. These instructions include, but are not limited to, register write instructions, bus configuration instructions, and peripheral initialization instructions. These instructions correspond to the configuration parameters and operation procedures required for the hardware device to resume normal operation.

[0057] It should be noted that in the Advanced Configuration and Power Interface (ACPI) standard, the S3 state is a low-power state that is suspended to RAM (STR). Alongside this, there are several other system power states, which are divided into six categories according to power consumption from high to low and wake-up speed from fast to slow: S0 (working state), S1~S4 (sleep / low power state), and S5 (power off state).

[0058] In an optional implementation, hardware operation instructions are a set of instructions describing the type of hardware operation, the target address of the operation, the data operation, and the timing requirements. Their function is to restore critical configurations such as the register state, bus communication parameters, and peripheral operating mode of the hardware device during S3 wake-up, ensuring that the hardware device can respond normally to the operating system. For example, hardware operation instructions for a PCIe controller may include instructions for writing to the PCIe configuration space register, instructions for setting link training parameters, and instructions for enabling the interrupt controller. These instructions are necessary for the PCIe controller to function normally after S3 wake-up. Similarly, hardware operation instructions for I²C peripherals may include instructions for configuring the I²C bus clock frequency, instructions for setting the slave device address, and instructions for controlling data transmission.

[0059] Furthermore, the hardware recovery script is a structured data set that stores hardware operation instructions. The hardware recovery script can organize the hardware operation instructions according to a preset format, so that the firmware execution unit can parse and execute these instructions to restore the hardware state.

[0060] In an optional implementation, the hardware recovery script can be an ordered data sequence containing multiple hardware operation instructions. Its format must meet the parsing requirements of the firmware execution unit, clearly indicating the operation type, target hardware, operation parameters, and execution order of each instruction. For example, the hardware recovery script can adopt a binary instruction stream format, where each instruction contains xx bytes of operation type field, xx bytes of target address field, xx bytes of data length field, and several bytes of data field. The firmware execution unit can determine and execute the corresponding hardware operation by reading these fields.

[0061] The non-volatile storage area is a storage medium that retains data even in the S3 low-power state. This area is independent of the system's running memory, and the data stored therein remains valid during platform hibernation and wake-up. Optionally, the non-volatile storage area is a storage medium with power-loss data retention capabilities. Its types can include Advanced Configuration and Power Interface Non-volatile Storage (ACPINVS), Reserved RAM, Persistent RAM, Flash memory, Non-Volatile Random Access Memory (NVRAM), Trusted Platform Module (TPM) for ARM PC platforms, and Security Units for ARM PC platforms. All these storage media ensure that the hardware recovery script does not lose data during S3 suspension and wake-up. For example, when ACPI NVS is used as the non-volatile storage area, this area is a dedicated memory area defined in the ACPI specification. It is allocated and marked as non-volatile by the UEFI firmware during initialization. Even if the system enters the S3 state, the data in this area will not be cleared. As another example, when Flash / NVRAM is used as the storage area, the script data is written to the flash memory chip. Its data retention characteristics after power failure ensure that it can be read normally upon wake-up.

[0062] In one optional embodiment, step S101 specifically includes the following steps:

[0063] Step S1011: During the UEFI phase of normal startup on the ARM PC platform, load the S3 hardware recovery script generation driver; the S3 hardware recovery script generation driver is used to initialize the resources required for hardware recovery script recording and provide a hardware operation instruction recording interface to allocate memory areas in the non-volatile storage area and create script data structures.

[0064] Step S1012: Use the S3 hardware recovery script to generate a driver to capture and record the hardware operation instructions required for S3 state wake-up, and store the hardware operation instructions in the memory area according to the script data structure to generate an executable hardware recovery script.

[0065] In step S1011 above, the resources required for hardware recovery script recording are the basic resources needed for the S3 hardware recovery script generation driver to implement instruction capture and script storage. These include memory space in the non-volatile storage area, initialization parameters for the script data structure, and communication resources for the instruction recording interface, such as shared memory buffers and interrupt semaphores. For example, the resources required for hardware recovery script recording are requested by the S3 hardware recovery script generation driver through the UEFI memory allocation service. These resources may include 64KB of non-volatile memory space (for storing the script), a 4KB shared memory buffer (for receiving instruction recording requests from other drivers), and one interrupt semaphore (for synchronizing instruction recording operations). This ensures that the memory space is not released in the S3 state, providing a stable storage foundation for hardware recovery script generation.

[0066] The hardware operation instruction recording interface is a standardized communication interface (compliant with UEFI protocol specifications) provided by the S3 hardware recovery script generation driver. It is used to receive hardware operation instructions sent by the platform firmware and other peripheral drivers, supports synchronous / asynchronous instruction recording, and ensures the integrity and timing consistency of instruction transmission.

[0067] Furthermore, the memory area is a contiguous storage space specifically allocated within the non-volatile storage area for storing hardware recovery scripts. It has a fixed starting address, clear size boundaries, supports random read / write and dynamic expansion, ensuring orderly storage and fast access to script data.

[0068] The script data structure is the organization format for hardware recovery scripts. It defines the order of instruction storage, field meanings, verification rules, and management control information, enabling the driver to write instructions in a unified format and the firmware execution unit to parse instructions in a unified format.

[0069] In one optional embodiment, the script data structure includes an instruction type area, an operation parameter area, a verification information area, and a management and control information area. The management and control information includes the script version number, the number of instructions, and the storage address boundaries.

[0070] The script data structure is divided into several sections. The instruction type section identifies the type of hardware operation instruction, informing the firmware execution unit of the current instruction's operation category, such as register writing, bus configuration, or peripheral initialization. This ensures the execution unit executes the instruction according to the corresponding logic. The field format can be binary encoding, ASCII identification, etc. The operation parameter section stores specific hardware operation parameters, corresponding to the instruction type section. It includes core execution parameters such as target address, operation data, and timing requirements, serving as the core data for instruction execution. The verification information section ensures the integrity of a single instruction or the entire script, storing verification values ​​to prevent errors during instruction data storage or transmission, ensuring the accuracy of the instruction parameters obtained by the execution unit. The management and control information section stores overall script management information, enabling the firmware execution unit to obtain basic script attributes (version, size, storage range). This supports the overall process control of script loading and parsing, providing crucial assurance for script integrity and scalability.

[0071] Specifically, the script version number, located in the management control information area, identifies the script format version and is used to adapt to the parsing logic of different firmware execution units. When the script format is upgraded, the version number is used to distinguish between the old and new versions, ensuring compatibility and preventing script parsing failures due to format differences. The instruction count, located in the management control information area, identifies the total number of hardware operation instructions contained in the script. This information is used by the firmware execution unit to calculate the script size, plan parsing and execution time, and also serves as an auxiliary basis for script integrity verification. The storage address boundaries, located in the management control information area, identify the start and end addresses of the script's storage. This information is used by the firmware execution unit to locate the script's storage range in the non-volatile storage area, avoiding reading invalid data outside the script's range, and supporting dynamically expanded script address management.

[0072] Optionally, step S1012 specifically includes the following steps:

[0073] Step S1012a: Use the S3 hardware recovery script to generate the hardware operation instructions required for driver capture and S3 state wake-up, and determine whether there is enough space in the memory area after each capture.

[0074] Step S1012b: If there is sufficient space in the memory area, the currently captured hardware operation instructions are stored in the memory area according to the script data structure to generate an executable hardware recovery script.

[0075] In step S1012c, if the memory area space is insufficient, an additional non-volatile storage area is requested through a dynamic expansion mechanism, and the currently captured hardware operation instructions are stored in the additional non-volatile storage area according to the script data structure to generate an executable hardware recovery script.

[0076] In step S1012a above, after each capture of a hardware operation instruction, the hardware recovery script generation driver in step S3 calculates the difference between the current script data length and the total size of the memory region. If the difference is greater than or equal to the storage length required by the current instruction, it is determined that the space is sufficient; otherwise, it is determined that the space is insufficient. This judgment process can guarantee real-time performance and takes ≤1us.

[0077] In step S1012c above, the dynamic expansion mechanism is the process by which the S3 hardware recovery script generation driver requests additional storage space from the UEFI firmware or non-volatile storage controller when the memory area space is insufficient. It supports expansion in preset steps. After expansion, the memory area size field and verification information of the script data structure need to be updated to ensure script integrity. For example, when insufficient space is detected for the first time, additional non-volatile storage area, such as ACPI NVS extended pages or Flash / NVRAM partitions, is requested, and the memory area size field in the script file header is updated. If insufficient space occurs again subsequently, expansion continues in preset steps, up to a maximum of 256KB.

[0078] The additional non-volatile storage area is a non-volatile storage space allocated through a dynamic expansion mechanism to supplement the storage hardware recovery script. It is logically contiguous with the initial memory area and can be associated with it via an address list in the script data structure. Physically, it can be located on the same storage medium, such as ACPI NVS, or on different storage media, such as initially ACPI NVS and expanded to Flash / NVRAM. For example, the additional non-volatile storage area preferentially selects a storage medium of the same type as the initial memory area (such as ACPI NVS). If the storage medium has no remaining space, a dedicated partition of Flash / NVRAM is selected. After expansion, the starting address and size of the additional area are recorded in the extended address list field of the script file header.

[0079] The above steps ensure that all hardware operation instructions necessary for S3 wake-up are completely recorded, preventing the omission of critical instructions due to space limitations and solving the problem of device initialization failure caused by incomplete instruction recording in traditional ARM proprietary recovery mechanisms. By capturing instructions through a standardized driver interface and combining it with a dynamic memory expansion mechanism, it ensures that all recovery instructions for complex hardware such as PCIe controllers and I²C peripherals are recorded; a unified script data structure standardizes the instruction storage format, avoiding differences in instruction recording between different manufacturers' SoCs.

[0080] In this way, the hardware recovery script is generated during the normal UEFI startup phase and stored in a non-volatile area. The script generation process is moved forward to the stage where the ARM platform can still run UEFI, without relying on the UEFI execution environment during the wake-up phase.

[0081] In step S102, the S3 hardware recovery script generation driver is used to perform security protection processing on the hardware recovery script to obtain security protection information. Before exiting the UEFI stage, the S3 hardware recovery script generation driver is used to notify the firmware execution unit of the ARM PC platform of the storage location information and security protection information of the hardware recovery script so that the hardware recovery script enters the executable ready state.

[0082] Here, security protection processing refers to the operation of performing integrity verification or anti-tampering processing on the hardware recovery script. Its purpose is to ensure that the hardware recovery script is not tampered with during storage and transmission, and to guarantee the integrity and security of the hardware recovery script executed during the wake-up phase.

[0083] In an optional implementation, security protection processing can be a process of processing the hardware recovery script through encryption, signing, or checksum calculation. Its core function is to add security verification criteria to the script, enabling the firmware execution unit to verify the script's legitimacy before execution. Optionally, the security protection processing methods include one of the following: RSA signature, ECDSA signature, HMAC verification, and TPM encapsulation. Specifically, when the security protection processing uses RSA digital signature, the script data is signed with a private key to generate signature information. The firmware execution unit verifies the signature using the corresponding public key to confirm that the hardware recovery script has not been tampered with. Alternatively, ECDSA signature, HMAC verification, or TPM encapsulation can also be used; all of these methods can achieve script security protection.

[0084] The security protection information consists of data generated after security protection processing to verify the legitimacy of the hardware recovery script. This data may include signature data, checksum, and encryption key. This security protection information is used in conjunction with the hardware recovery script to verify the script's integrity and tamper-proof nature by the firmware execution unit. For example, when using RSA signing, the security protection information is the RSA signature result; when using HMAC verification, it is the HMAC hash value; and when using TPM encapsulation, it is the encapsulation data generated by TPM and the verification key. For instance, after signing the hardware recovery script using the RSA algorithm, the generated signature data is the security protection information, which, along with the storage location information of the hardware recovery script, is communicated to the firmware execution unit.

[0085] Here, "before exiting the UEFI phase" refers to the critical moment when the UEFI firmware has completed hardware initialization and driver loading, and is about to boot the operating system. At this point, the core tasks of the UEFI phase have been completed, and the generation and storage of the hardware recovery script have also ended. Specifically, at this moment, UEFI has completed the initialization and configuration of memory and peripherals, and the operating system kernel has been loaded into memory, about to take over hardware management privileges. For example, before exiting the UEFI phase, the aforementioned ARM laptop will check the running status of all loaded drivers, confirm that the hardware recovery script has been generated, signed, and stored, and then perform the exit operation.

[0086] Among them, the firmware execution unit refers to the firmware module in the ARM PC platform that has independent execution capabilities. It can run independently during the S3 wake-up phase and has the ability to read data from non-volatile memory areas, verify security protection information, and execute hardware operation instructions.

[0087] In an alternative implementation, the firmware execution unit is a dedicated firmware module integrated within the ARM SoC. The firmware execution unit of the ARM PC platform includes one of the following: a system management unit, boot loading firmware, and secure execution environment firmware.

[0088] For example, the firmware execution unit may include a system management unit (SMU), boot loading firmware such as a secondary boot loader stage 2 (BL2), a security monitoring firmware (Boot Loader Stage 31 (BL31), and a secure execution environment firmware (Boot Loader Stage 32 (BL32)). These modules can run independently during the S3 wake-up phase without relying on the UEFI phase. For instance, when using the SMU as the firmware execution unit, this unit is a dedicated hardware management module within the ARM SoC, possessing an independent processor core and memory space. During the S3 wake-up phase, it will be the first to start and execute a preset program. Similarly, when using the BL31 as the firmware execution unit, it will be executed first in the S3 wake-up process, possessing the authority to access non-volatile memory areas and perform hardware operations.

[0089] The storage location information includes the specific storage address and data length of the hardware recovery script in the non-volatile storage area. This information is used by the firmware execution unit to accurately read the hardware recovery script. Specifically, the storage location information may include parameters such as the starting physical address of the script storage, data length, and storage medium type identifier. These parameters are determined and organized by the S3 hardware recovery script generation driver after the script storage is completed. The firmware execution unit can directly access the corresponding storage area to read the hardware recovery script based on the storage location information.

[0090] Furthermore, the executable-ready state indicates that the hardware recovery script has completed storage and security protection processing, and its storage location information and security protection information have been successfully notified to the firmware execution unit, making it ready to be read, verified, and executed by the firmware execution unit during the S3 wake-up phase. In other words, when the S3 hardware recovery script generation driver completes script storage and security protection processing, and sends the storage location information and security protection information to the firmware execution unit via a preset notification method, and the firmware execution unit confirms successful reception, the hardware recovery script enters the executable-ready state. For example, the driver sends the storage location information and security protection information to the SMU via a shared register. After the SMU reads the register data and verifies the format, it returns an acknowledgment signal to the driver. At this point, the hardware recovery script is in the executable-ready state, waiting to be executed during the S3 wake-up phase.

[0091] In step S103, when the ARM PC platform is in the S3 wake-up phase, the firmware execution unit of the ARM PC platform reads the hardware recovery script according to the notified storage location information and verifies the legality of the security protection information and the validity of each hardware operation instruction in the hardware recovery script; wherein, the S3 wake-up phase does not include the UEFI phase.

[0092] In the above steps, the S3 state wake-up stage is the process stage in which the ARM PC platform recovers from the S3 low-power state to the normal operating state. The core task of this stage is to restore the hardware device state so that the system can operate normally.

[0093] In an optional implementation, when the firmware execution unit of the ARM PC platform is a System Management Unit (SMU), the S3 state wake-up phase is triggered by a hardware wake-up signal (such as when the user presses the power button). The process is as follows: SMU startup, reading the hardware recovery script, verifying the script's validity, executing hardware operation instructions, BL2 booting, BL31 execution, and operating system recovery. This phase does not require running UEFI firmware; the hardware state recovery is directly led by the firmware execution unit (such as the SMU). For example, in the aforementioned ARM laptop in S3 hibernation mode, after the user presses the power button, the SMU is first woken up and started, then enters the S3 state wake-up phase and begins executing the hardware recovery process.

[0094] For example, such as Figure 2As shown, in the S3 wake-up process of this application embodiment, only the system management unit 201 initialization → script executor 205 reading and executing the script → secondary boot loading firmware 202 boot loading → security monitoring firmware 203 execution → operating system startup are executed, skipping the UEFI stage. Therefore, at the end of the UEFI stage, this application notifies the system management unit (SMU) of the ARM PC platform of the storage location information and security protection information of the hardware recovery script. When the S3 state wake-up stage is triggered, the SMU will obtain and call the BootScript executor integrated inside the SMU to parse and execute the hardware operation instructions in the hardware recovery script, thereby completing the ARM PC platform wake-up after restoring the hardware state.

[0095] The verification of the legality of security protection information involves the firmware execution unit using a verification algorithm corresponding to the security protection process to check the security protection information and confirm that the hardware recovery script has not been tampered with and its source is legitimate. Specifically, the verification of the legality of security protection information involves the firmware execution unit calling the corresponding verification module to perform a verification operation based on the type of security protection information. If the verification result is consistent with the preset standard, the security protection information is deemed legitimate; otherwise, it is deemed illegitimate. For example, if the security protection information is RSA signature data, the firmware execution unit will call the built-in RSA public key verification module, use the preset public key to decrypt the signature data to obtain the script hash value, and then calculate the hash value of the read hardware recovery script. If the two are consistent, the security protection information is deemed legitimate. If HMAC verification is used, the firmware execution unit will use the preset key to calculate the HMAC value of the read script and compare it with the HMAC value in the security protection information. If they are consistent, the information is deemed legitimate.

[0096] Furthermore, verifying the validity of each hardware operation instruction in the hardware recovery script refers to the process by which the firmware execution unit performs syntax checks, permission checks, and target hardware matching checks on each instruction in the hardware recovery script to confirm that the instruction can be executed and will not cause any abnormalities to the system.

[0097] Optionally, verifying the validity of hardware operation instructions can include three dimensions: first, syntactic validity, checking whether the format of the hardware operation instruction conforms to the script definition specification, such as whether the operation type field is valid and whether the data length matches; second, permission validity, checking whether the operation corresponding to the hardware operation instruction is within the permission scope of the firmware execution unit, such as whether modification of the target register is allowed; and third, hardware matching validity, checking whether the target hardware address of the hardware operation instruction exists in the hardware architecture of the current ARM PC platform. For example, when the firmware execution unit reads a register write hardware operation instruction, it first checks whether the operation type field is a preset valid value, then verifies whether the target register address belongs to the configurable register range of the current SoC, and finally confirms that the firmware execution unit has write permission to the register. If all conditions are met, the hardware operation instruction is deemed valid.

[0098] In step S104, if the security protection information is valid and all hardware operation instructions are effective, the firmware execution unit of the ARM PC platform executes the hardware operation instructions in the hardware recovery script according to the preset execution order, so as to complete the ARM PC platform wake-up after restoring the hardware state.

[0099] Here, the preset execution order is the order in which hardware operation instructions in the hardware recovery script are executed. This order can be determined based on the dependencies between hardware devices, ensuring that core hardware is initialized first, followed by peripherals that depend on it, thus avoiding hardware recovery failure due to incorrect execution order. For example, the preset execution order can be an instruction execution order based on the hierarchical and dependency relationships of hardware devices, with core bus (e.g., PCIe bus) configuration instructions executed first, followed by core peripheral (e.g., memory controller) initialization instructions, and finally ordinary peripheral (e.g., I²C sensor) configuration instructions. For instance, the preset execution order could be: memory controller register configuration instructions, PCIe bus link training instructions, PCIe peripheral initialization instructions, I²C bus configuration instructions, I²C peripheral initialization instructions, and embedded controller configuration instructions. This order ensures that peripherals dependent on the PCIe bus are initialized only after the PCIe bus configuration is complete.

[0100] In the above steps, by executing hardware operation instructions, the register parameters, bus configuration, and operating mode of the hardware device are restored to their state before S3 hibernation, enabling the hardware device to respond normally to the operating system's control commands. The process of restoring the hardware state involves the firmware execution unit executing hardware operation instructions one by one to configure key parameters of the hardware device, including restoring register values, configuring the bus communication rate, and enabling peripheral interrupt functions. For example, executing the memory controller's register configuration instructions restores the memory's timing parameters and address mapping to their state before hibernation; executing the PCIe peripheral initialization instructions restores the PCIe device's configuration space parameters and enables the device's DMA function, allowing the device to transfer data with memory; executing the I²C peripheral configuration instructions restores the I²C bus clock frequency and slave device address, ensuring that the peripheral can normally receive operating system control commands.

[0101] In this way, once the hardware device state of the ARM PC platform is restored, the firmware execution unit can notify the bootloader to continue the subsequent wake-up process, ultimately restoring the operating system to its running state before hibernation, allowing the user to continue using the ARM PC platform.

[0102] In one optional embodiment, step S104 specifically includes the following steps:

[0103] Step S1041: Parse the hardware recovery script according to the hardware dependency relationship and determine the preset execution order;

[0104] Step S1042: Call the firmware execution unit of the ARM PC platform to execute the hardware operation instructions in the hardware recovery script according to the preset execution order. After the execution is completed, check the status of key registers and peripherals to verify the recovery result. After confirming that the hardware status has been restored to the target expected state, the ARM PC platform wake-up is completed.

[0105] In the above steps, hardware dependencies refer to the startup or configuration dependency logic between different hardware modules (such as buses, controllers, and peripherals) in the ARM PC platform. That is, the normal operation of one piece of hardware requires the prior configuration of another piece of hardware; for example, a peripheral depends on the bus controller for initialization, and the bus controller depends on the memory controller for configuration. Optionally, hardware dependencies can employ both hierarchical and direct dependencies. Specifically, hierarchical dependencies divide hardware into a core layer (e.g., memory controller, SMU), a bus layer (e.g., PCIe, I²C bus), and a peripheral layer (e.g., network card, sound card, sensors), executed in the order of core layer, bus layer, and peripheral layer. Direct dependencies are dependencies within the same layer; for example, a PCIe peripheral depends on a PCIe controller, executed in the order from controller to peripheral.

[0106] Here, the default execution order is the script instruction execution order determined by the firmware execution unit based on hardware dependencies. This ensures that the configuration instructions of the basic hardware are executed first, followed by the subsequent instructions that depend on that hardware. This avoids hardware initialization failures due to incorrect execution order and ensures efficient script execution.

[0107] In the above steps, the critical registers are those in the ARM PC platform that determine the core functions of the hardware. Their status directly affects whether the hardware can function properly and is the core object for verifying the recovery result. These critical registers include the timing configuration register of the memory controller, the link training register of the PCIe controller, the clock configuration register of the I²C controller, and the operating mode register of the embedded controller. The configuration parameters of these registers are fundamental to the normal operation of the hardware. Peripheral status refers to the working status of peripherals in the ARM PC platform. By detecting the peripheral status, it can be determined whether the hardware recovery has achieved the expected results, ensuring that the peripherals can respond normally to subsequent operations. Peripheral status detection is achieved by reading the peripheral's status register or sending probe commands. The firmware execution unit determines the recovery result by detecting the status values.

[0108] The target expected state is the working state that the hardware should reach after being woken up by S3, that is, the same hardware configuration state as before hibernation, including the preset values ​​of key registers, the ready state of peripherals, the communication capability of the bus, etc., which is the standard basis for verifying the recovery result.

[0109] Specifically, the expected target state is generated and synchronously stored during instruction recording by the S3 hardware recovery script driver. This includes expected values ​​of critical registers and expected status codes of peripherals, stored in the script's management and control information area. During firmware execution unit verification, the actual state is compared with the expected target state; if they match, the recovery is considered successful. For example, if the expected target value of the memory controller timing configuration register is 'a', and the execution unit reads the actual value of the register as 'a', it determines that the recovery meets expectations.

[0110] In an optional embodiment, when the firmware execution unit of the ARM PC platform is a system management unit (SMU), the method provided in this application further includes:

[0111] After confirming that the hardware state has been restored to the target expected state, a completion signal for the S3 state wake-up phase is sent to the system management unit. The completion signal indicates that the hardware state restoration is complete. After the system management unit receives the completion signal, it notifies the ARMPC platform to load the firmware to continue the subsequent wake-up process, so as to complete the wake-up of the ARMPC platform from the S3 state to the normal operating state.

[0112] In the above steps, the completion signal refers to a notification signal indicating that the hardware state recovery is complete. It is used to inform the SMU that the script execution and hardware recovery have been fully completed, triggering the subsequent wake-up process. The signal format can be a level signal, register identifier, interrupt request, etc., possessing clear uniqueness and identifiability. Optionally, the completion signal can use a register identifier. After confirming that the hardware recovery meets expectations, the firmware execution unit writes 'b' to the SMU's dedicated status register. This value is the completion signal. The SMU detects whether the signal has arrived by polling this register.

[0113] The boot loading firmware can include secondary boot loading firmware BL2 and security monitoring firmware BL31, which are used to complete platform security initialization, load and boot the subsequent execution environment. In the S3 wake-up process, after the SMU completes hardware wake-up, it transfers control to BL2. BL2 completes the basic initialization of the secure world and loads BL31. After receiving control, BL31 restores the highest privilege level exception level EL3 runtime context, configures the secure / unsecure world memory mapping, and then jumps to the wake-up entry point preset by the operating system kernel to guide the system to resume operation from hibernation.

[0114] The subsequent wake-up process follows the hardware recovery process after the S3 wake-up phase, including CPU core initialization, memory mapping configuration, operating system kernel wake-up, and user-mode process recovery, ultimately restoring the ARM PC platform from the S3 low-power state to normal operation. For example, the execution order of the subsequent wake-up process could be: BL31 initializes the CPU core, configures the memory mapping table, wakes the operating system kernel, the kernel restores the system context, starts user-mode processes, and the system resumes normal operation. For instance, after receiving the SMU completion signal, the BL31 completes CPU core initialization within a certain time. Then, the operating system kernel reads the system context from memory before hibernation, restores all running applications, and finally, the ARM laptop screen lights up, entering normal operation.

[0115] Based on the same inventive concept, this application also provides a hardware recovery device for low-power wake-up corresponding to the hardware recovery method for low-power wake-up. Since the principle of the device in this application is similar to the hardware recovery method for low-power wake-up described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0116] Please see Figure 3 , Figure 3 This is a schematic diagram of a hardware recovery device for low-power state wake-up provided in an embodiment of this application. Figure 3 As shown, the device 300 includes:

[0117] The script building module 301 is used to load the S3 hardware recovery script generation driver during the UEFI phase of normal startup of the ARM PC platform, and use the S3 hardware recovery script generation driver to capture and record the hardware operation instructions required for S3 state wake-up to generate an executable hardware recovery script; wherein, the hardware recovery script is stored in a non-volatile storage area.

[0118] The security processing module 302 is used to perform security protection processing on the hardware recovery script using the S3 hardware recovery script generation driver to obtain security protection information, and before exiting the UEFI stage, use the S3 hardware recovery script generation driver to notify the firmware execution unit of the ARM PC platform of the storage location information of the hardware recovery script and the security protection information, so that the hardware recovery script enters the executable ready state.

[0119] The wake-up notification module 303, when the ARM PC platform is in the S3 wake-up phase, uses the firmware execution unit of the ARM PC platform to read the hardware recovery script in the executable ready state according to the notified storage location information and verify the legality of the security protection information and the validity of each hardware operation instruction in the hardware recovery script; wherein, the S3 wake-up phase does not include the UEFI phase.

[0120] The wake-up execution module 304 is used to execute the hardware operation instructions in the hardware recovery script in a preset execution order using the firmware execution unit of the ARM PC platform when the security protection information is legal and all hardware operation instructions are valid, so as to complete the wake-up of the ARM PC platform after restoring the hardware state.

[0121] The apparatus provided in this application generates a hardware recovery script during the UEFI phase of a normal startup on an ARM PC platform and stores it in a non-volatile storage area. Combined with the execution of the script by the firmware execution unit during the S3 wake-up phase (skipping the UEFI phase), it overcomes the limitation that the complete process of ARM architecture system-on-a-chip devices waking up from the S3 low-power state and resuming normal operation does not execute UEFI. This solves the technical problems of existing ARM PC platforms lacking standardized hardware recovery mechanisms and having poor compatibility with vendor-specific implementations. At the same time, the integrity and immutability of the script are ensured through security protection processing. This not only achieves effective recovery of SoC hardware and platform devices, but also improves the system's compatibility, stability, and security, which is conducive to the promotion and application of ARM architecture system-on-a-chip devices on PC platforms.

[0122] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0123] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, they can perform the operations described above. Figure 1 The steps of the hardware recovery method during low-power state wake-up in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0124] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the hardware recovery method during low-power state wake-up in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0125] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0126] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0127] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0128] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0129] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0130] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered 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.

Claims

1. A hardware recovery method during low-power state wake-up, characterized in that, Applied to the ARM PC platform, the method includes: During the UEFI phase of normal startup on the ARM PC platform, the S3 hardware recovery script generation driver is loaded. The S3 hardware recovery script generation driver is used to capture and record the hardware operation instructions required for S3 state wake-up to generate an executable hardware recovery script. The hardware recovery script is stored in a non-volatile memory area. The S3 hardware recovery script generation driver is used to perform security protection processing on the hardware recovery script to obtain security protection information. Before exiting the UEFI stage, the S3 hardware recovery script generation driver is used to notify the firmware execution unit of the ARM PC platform of the storage location information of the hardware recovery script and the security protection information, so that the hardware recovery script enters the executable ready state. When the ARM PC platform is in the S3 wake-up phase, the firmware execution unit of the ARM PC platform reads the hardware recovery script in the executable ready state according to the notified storage location information and verifies the legality of the security protection information and the validity of each hardware operation instruction in the hardware recovery script; wherein, the S3 wake-up phase does not include the UEFI phase. When the security protection information is valid and all hardware operation instructions are effective, the firmware execution unit of the ARM PC platform executes the hardware operation instructions in the hardware recovery script in a preset execution order to complete the ARM PC platform wake-up after restoring the hardware state.

2. The method according to claim 1, characterized in that, During the UEFI phase of normal startup on the ARM PC platform, an S3 hardware recovery script generation driver is loaded. This driver captures and records the hardware operation instructions required for S3 state wake-up to generate an executable hardware recovery script, including: During the UEFI phase of normal startup on the ARM PC platform, the S3 hardware recovery script generation driver is loaded. The S3 hardware recovery script generation driver is used to initialize the resources required for hardware recovery script recording and provide a hardware operation instruction recording interface to allocate memory areas in the non-volatile storage area and create script data structures. The S3 hardware recovery script is used to generate a driver that captures and records the hardware operation instructions required for S3 state wake-up, and stores the hardware operation instructions in the memory area according to the script data structure to generate an executable hardware recovery script.

3. The method according to claim 2, characterized in that, The process of using an S3 hardware recovery script to generate a driver that captures and records the hardware operation instructions required for S3 state wake-up, and storing the hardware operation instructions in the memory area according to the script data structure to generate an executable hardware recovery script includes: The S3 hardware recovery script is used to generate the driver to capture the hardware operation instructions required for S3 state wake-up. After each capture, it is determined whether the memory area has sufficient space. If the memory area has sufficient space, the currently captured hardware operation instructions are stored in the memory area according to the script data structure to generate an executable hardware recovery script. If the memory area is insufficient, an additional non-volatile storage area is requested through a dynamic expansion mechanism. Then, the currently captured hardware operation instructions are stored in the additional non-volatile storage area according to the script data structure to generate an executable hardware recovery script.

4. The method according to claim 3, characterized in that, The script data structure includes an instruction type area, an operation parameter area, a verification information area, and a management and control information area. The management and control information includes the script version number, the number of instructions, and the storage address boundaries.

5. The method according to claim 1, characterized in that, The security protection process includes one of the following: RSA signature method, ECDSA signature method, HMAC verification method, and TPM encapsulation method.

6. The method according to claim 1, characterized in that, When the security protection information is legal and all hardware operation instructions are valid, the firmware execution unit of the ARM PC platform executes the hardware operation instructions in the hardware recovery script according to a preset execution order to complete the ARM PC platform wake-up after restoring the hardware state, including: The hardware recovery script is parsed according to hardware dependencies and a preset execution order is determined. The firmware execution unit of the ARM PC platform is invoked to execute the hardware operation instructions in the hardware recovery script according to the preset execution order. After the execution is completed, the status of key registers and peripherals is checked to verify the recovery result. After confirming that the hardware status has been restored to the target expected state, the ARM PC platform wake-up is completed.

7. The method according to claim 6, characterized in that, The firmware execution unit of the ARM PC platform includes one of the following: system management unit, boot loading firmware, and secure execution environment firmware.

8. The method according to claim 7, characterized in that, When the firmware execution unit of the ARM PC platform is a system management unit, the method further includes: After confirming that the hardware state has been restored to the target expected state, a completion signal for the S3 state wake-up phase is sent to the system management unit, and the completion signal indicates that the hardware state restoration is complete. After receiving the completion signal, the system management unit notifies the ARM PC platform to continue the subsequent wake-up process to complete the wake-up of the ARM PC platform from the S3 state to the normal operation state.

9. The method according to claim 1, characterized in that, The non-volatile storage area includes one of the following: an advanced configuration and power interface non-volatile storage area, a reserved memory area, a persistent memory area, flash memory, non-volatile random access memory, the trusted platform module of the ARM PC platform, and the security element of the ARM PC platform.

10. A hardware recovery device for low-power state wake-up, characterized in that, include: The script building module is used to load the S3 hardware recovery script generation driver during the UEFI phase of normal startup on the ARM PC platform. The S3 hardware recovery script generation driver is used to capture and record the hardware operation instructions required for S3 state wake-up to generate an executable hardware recovery script; wherein, the hardware recovery script is stored in a non-volatile memory area. The security processing module is used to perform security protection processing on the hardware recovery script using the S3 hardware recovery script generation driver to obtain security protection information, and before exiting the UEFI stage, use the S3 hardware recovery script generation driver to notify the firmware execution unit of the ARM PC platform of the storage location information of the hardware recovery script and the security protection information, so that the hardware recovery script enters the executable ready state. The wake-up notification module, when the ARM PC platform is in the S3 wake-up phase, uses the firmware execution unit of the ARM PC platform to read the hardware recovery script in the executable ready state according to the notified storage location information and verify the legality of the security protection information and the validity of each hardware operation instruction in the hardware recovery script; wherein, the S3 wake-up phase does not include the UEFI phase. The wake-up execution module is used to execute the hardware operation instructions in the hardware recovery script in a preset execution order using the firmware execution unit of the ARM PC platform when the security protection information is legal and all hardware operation instructions are valid, so as to complete the wake-up of the ARM PC platform after restoring the hardware state.

Images