A firmware updating method and a firmware updating system of an electronic device

Abstract

The application provides a firmware updating method and system of an electronic device. The method comprises: in a standby state, downloading firmware files of an updating task from a cloud in blocks in response to the updating task from the cloud; writing the received firmware files into a firmware cache area of the electronic device in a preset manner; setting a start flag for the firmware cache area after performing security verification on the written firmware files and passing the verification; switching to a start state, and loading the firmware files from the firmware cache area to start up according to the start flag. The electronic device can realize firmware updating in the standby state, and the CPU, PCH and other devices of the electronic device can not need to start up and can not affect the electronic device to remain in the standby state.

Description

Technical Field

[0001] This application relates to the field of firmware update technology, and in particular to a firmware update method and firmware update system for an electronic device. Background Technology

[0002] Firmware updates (BIOS updates) for electronic devices (such as laptops) are a critical part of IT operations and maintenance, especially in enterprise environments where security patches need to be deployed in batches. Existing remote BIOS update solutions all have one or more limitations—requiring an operating system (OS) to be running, a PCH (Platform Controller Hub) to be running, or Intel ME (Intel Management Engine) to be activated.

[0003] However, existing BIOS update technologies cannot complete remote BIOS updates in a true S5 state (when the main CPU, PCH main logic, and ME are all inactive). Therefore, BIOS updates still require waiting for the electronic device to power on or rely on manual operation, which is inefficient in large-scale device management scenarios or prevents timely deployment of security patches. Summary of the Invention

[0004] This application provides a firmware update method for electronic devices to solve the technical problems of low firmware update efficiency and the inability to deploy security patches in a timely manner.

[0005] The first aspect of this application provides a firmware update method for an electronic device, comprising: in a standby state, in response to an update task from the cloud, downloading the firmware file of the update task in blocks from the cloud; writing the received firmware file into the firmware cache of the electronic device in a preset manner; after performing security verification on the written firmware file and passing the verification, setting a startup flag in the firmware cache; switching to a startup state, and booting the device by loading the firmware file from the firmware cache according to the startup flag.

[0006] In one embodiment of this application, responding to an update task from the cloud includes: establishing a communication connection with the cloud and identifying the device using the unique identifier of the electronic device; after successful identification, querying the cloud for update tasks through periodic polling; and receiving the update task pushed by the cloud when the cloud matches an update task corresponding to the unique identifier of the device.

[0007] In one embodiment of this application, querying the cloud for update tasks through periodic polling includes: the periodic polling method includes one of timed polling mode, keep-alive mode and listening mode, and the frequency of querying the cloud for update tasks corresponding to each periodic polling method is different; upon receiving a mode switching instruction issued by the cloud, the periodic polling method is switched according to the mode switching instruction.

[0008] In one embodiment of this application, the received firmware file is written to the firmware cache of an electronic device in a preset manner, including: obtaining the firmware file from the cloud in data blocks, wherein the size of each data block is a fixed value; calculating the hash value of the data block when each data block is received, and writing the data block to the address corresponding to the serial number of the data block in the firmware cache after the hash value is verified; wherein, during the process of writing the data block to the firmware cache, the data block is not cached in the storage area of ​​the electronic device.

[0009] In one embodiment of this application, each received data block includes: verifying the CRC32 checksum of the currently received data block; if the CRC32 checksum does not match the CRC32 field carried by the data block, requesting retransmission of the data block; verifying the continuity of the sequence number of the currently received data block; if the sequence number is greater than the expected sequence number, stopping the update and reporting an error to the cloud; if the sequence number is less than the expected sequence number, discarding the currently received data block and returning a continuation confirmation.

[0010] In one embodiment of this application, security verification is performed on the written firmware file, including: comparing the version number of the firmware file with the minimum allowed version number maintained; if the version number of the firmware file is lower than the minimum allowed version number, then the startup flag is not set and an error is reported to the cloud.

[0011] In one embodiment of this application, performing security verification on the written firmware file further includes: reading the firmware file written in the firmware cache and calculating the hash value of the firmware file; if the calculated hash value does not match the expected hash value of the firmware file, marking the firmware cache as invalid and reporting the error to the cloud.

[0012] In one embodiment of this application, writing the received firmware file into the firmware cache of an electronic device in a preset manner further includes: if a startup state is detected during the process of writing data blocks of the firmware file into the firmware cache of the electronic device, restoring control of the firmware cache to the operating system of the electronic device; suspending the current data block writing operation corresponding to the firmware file and recording the serial number of the data block; if a standby state is detected, rewriting the data block into the firmware cache of the electronic device according to the recorded serial number of the data block.

[0013] The beneficial effects of this application are: electronic devices can remotely update firmware through the EC module in S5 state. The CPU, PCH, ME and OS of the electronic devices are not started throughout the process. The EC module independently completes the receiving, signature verification and writing, and completes the remote firmware update in S5 state. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0015] In the attached diagram: Figure 1 A schematic diagram illustrating a firmware update scenario provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a firmware update system provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a firmware update method provided in an embodiment of this application. Figure 4 This is a flowchart illustrating the device discovery and remote update triggering mechanism implemented by the WiFi communication module in a firmware update system provided in this application embodiment; Figure 5 This is a flowchart illustrating a firmware update method provided in an embodiment of this application; Figure 6 This is a structural diagram of an electronic device providing a firmware update system in an embodiment of this application. Detailed Implementation

[0016] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0017] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0018] To facilitate a thorough understanding of the technical solutions of this application by those skilled in the art, some of the terms involved in this application will be explained in detail first.

[0019] An EC (Embedded Controller) is a microprocessor that runs independently of the CPU. An EC can implement low-level hardware register operations, ACPI (Advanced Configuration and Power Management Interface) specification implementations, and highly hardware-coupled logic such as keyboard matrix scanning, fan PWM (Pulse Width Modulation) speed control, and battery charging / discharging algorithms.

[0020] The Power Chipset (PCH) is a chip on the motherboard that connects to the CPU via a high-speed dedicated bus. The PCH manages the overall control and data routing for all low- to medium-speed I / O devices, including: Storage and Expansion: controlling SATA hard drive interfaces, USB ports, and the PCIe root port. Networking and Audio: integrating a built-in wired network card MAC layer and a high-definition audio controller (HD Audio). Firmware Storage Control: a hardware entity capable of directly reading and writing to the BIOS SPI Flash chip on the motherboard (unless eSPI Flash Sharing is enabled for indirect EC access). The PCH Master Domain is a specific voltage domain within the PCH used to power core I / O devices (such as Wi-Fi). The power supply state of the PCH Master Domain is synchronized with the main power domain and typically only operates during power-on.

[0021] BIOS SPI Flash Direct Read / Write Technology (SPI Bus Arbitration / eSPI Flash Sharing): SPI Flash Direct Read / Write: This refers to bypassing BIOS runtime protection mechanisms (such as BIOS Lock Enable) and directly erasing and programming the BIOS Flash memory storing the BIOS firmware through the SPI controller. SPI Bus Arbitration: Since the SPI bus may be connected to multiple master devices (such as CPU / PCH and EC), when both simultaneously initiate Flash access requests, hardware arbitration logic (based on request priority or time slice) is needed to determine the ownership of bus control. eSPI Flash Sharing: The eSPI bus specification allows the EC to access SPI Flash resources originally exclusively used by the PCH through the eSPI virtual channel, enabling shared BIOS access.

[0022] IoT Communication Technologies (WiFi / MQTT / HTTPS / TLS Encryption): WiFi: The foundation for physical and data link layer communication. MQTT: A lightweight messaging protocol based on a publish / subscribe model, designed for constrained devices and low-bandwidth, high-latency networks; QoS (Quality of Service) is its key feature. HTTPS and TLS Encryption: TLS (Transport Layer Security) provides an encrypted channel over TCP; HTTPS stands for HTTP over TLS. It involves a complete handshake process including certificate chain verification, pre-master key generation, and symmetric cipher suite negotiation.

[0023] Firmware file security verification (ECDSA signature / SHA-256 hash value / anti-rollback): SHA-256 hash value: Maps the firmware binary file to a fixed-length (256-bit) digest value to ensure integrity (anti-tampering). ECDSA signature: A digital signature algorithm based on elliptic curve cryptography. The private key signs the firmware hash value, and the public key verifies the signature to ensure authenticity (anti-forgery). Anti-rollback: To prevent attackers from flashing vulnerable older firmware versions, the firmware version number is burned to memory. At boot, a forced comparison is made between the current version and the secure version register, prohibiting the boot of firmware versions below a certain threshold.

[0024] Intel platform boot security mechanism (Boot Guard compatible): Intel Boot Guard is a hardware root of trust built into the chipset and CPU microcode. It begins operating during the microcode loading phase after CPU reset, using the built-in OEM public key hash (Fuse Key) to verify the ECDSA signature of the initial boot block (IBB, i.e., the first piece of code in the BIOS). Compatibility typically means that the BIOS firmware or security scheme must comply with Intel's ACM (Authentication Code Module) verification process and be able to correctly parse and transmit the security status register information required by Intel ME (Management Engine).

[0025] An SPI Mux (SPI multiplexer) is a hardware switching device used to route and switch SPI (Serial Peripheral Interface) bus signals to resolve access conflicts between multiple master devices (such as PCH, EC) and a single slave device (such as BIOS Flash).

[0026] EC GPIO (General Purpose Input / Output) are general purpose input / output pins on the EC, supporting configurable multiplexed pins. For example, they can be configured as digital inputs (reading external voltage levels), digital outputs (driving external voltage levels), or interrupt inputs (detecting voltage edge transitions and triggering the EC's internal interrupt service routine). GPIO can also be configured as the EC's standby domain, maintaining its state in S5 mode for wake-up detection.

[0027] S5 (Standby or Soft Shutdown) State: A normal shutdown at the operating system level is performed, the system completely stops running and memory data is cleared, but the motherboard still retains the +5VSB standby domain (standby power) to support functions such as keyboard power-on, Wake-on-LAN (WoL) or RTC (Real Time Clock) timed startup.

[0028] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating a firmware update scenario provided in one embodiment of this application, as shown below. Figure 1 As shown, the first electronic device 10 can be a laptop deployed in an enterprise environment. The enterprise IT administrator creates a BIOS update task through the management platform 11 (cloud). This update task typically requires that the first electronic device 10 be in a boot (power-on) state and that its operating system (OS) is running normally. For ordinary users of the first electronic device 10, if they happen to switch the first electronic device 10 to standby (S5) state, the BIOS update will be delayed, further preventing the deployment of BIOS security patches and potentially causing system failures. If the enterprise IT administrator has to issue a "system needs to restart to install BIOS update" prompt every time, it will result in a large workload of prompting and affect the real-time performance of the BIOS update task.

[0029] It can be seen that, Figure 1 In the described scenario, firmware updates encounter the following technical issues: Remote BIOS updates are impossible in S5 state. In S5 state, the main CPU, PCH main logic, memory, and OS are all inactive, and WiFi is powered off. This prevents security patches from being deployed, requiring a boot process. Although the EC (Electronic Control Center) can operate, it cannot directly access the BIOS Flash because the BIOS SPI Flash is connected to the PCH's SPI bus. With the PCH master domain powered off in S5 state, the EC cannot access the Flash via the PCH. A mechanism is needed to allow the EC to gain read / write access to the BIOS Flash in S5 state, while simultaneously ensuring normal PCH access to the Flash in S0 state (boot state).

[0030] Meanwhile, even if the EC can access the BIOS Flash, BIOS updates involve file network transfers and Flash writing, posing security risks such as attacks, malicious firmware injection, and firmware rollback attacks. Given the limited computing power of the EC (without hardware encryption accelerators), a complete signature verification and anti-rollback mechanism needs to be implemented to ensure the security of remote updates. In S5 mode, if WiFi loses power, the cloud server cannot push update tasks to electronic devices through conventional methods. An OS-independent network communication channel and device discovery mechanism are needed to enable the cloud to deliver update tasks to electronic devices in S5 mode, while simultaneously achieving network communication and device discovery in S5 mode through enterprise NAT and firewalls. BIOS updates in S5 mode can be interrupted by power loss at any time (e.g., battery depletion, power disconnection). If power is lost during Flash writing, it may lead to BIOS corruption and device boot failure. The entire update process also needs to be configured with a power loss protection mechanism to ensure that the device can still boot normally even if the update is interrupted.

[0031] To solve the above problems, such as Figure 2 As shown in the figure, this application embodiment proposes a firmware update system 20, which includes a second electronic device 21 and a cloud 22. The second electronic device 21 includes a WiFi communication module 211, an EC module 212, a BIOS Flash module 213, and an SPI Mux module 214. The cloud 22 can be an enterprise IT management server.

[0032] The WiFi communication module 211 is powered via EC GPIO control and is used to implement HTTPS / MQTT connections, TLS encryption / decryption, and BIOS firmware reception between electronic device 21 and the cloud 22. The EC module 212 is configured for standby domain power supply and is used to implement constant firmware update logic control, signature verification, and read / write operations on the BIOS Flash module 213. The BIOS Flash module 213 is configured for constant power supply and is used to store firmware, supporting direct read / write operations by the EC module 212. The SPI Mux module 214 is configured for standby domain power supply and is used to implement PCH / EC access arbitration for the BIOS Flash module 213. In contrast, the cloud 22 is used for firmware storage, firmware version management, and issuing update tasks to various electronic devices based on firmware version updates.

[0033] In other words, the electronic device 21 responds to the update quality of the cloud 22 through the WiFi communication module 211, receives the firmware, performs firmware verification through the EC module 212, and then writes it directly to the BIOS Flash module 213 through the SPI Mux module 214. The entire firmware update process does not rely on the CPU, PCH module, or operating system of the electronic device 21.

[0034] It is understood that in the description of the embodiments of this application, the WiFi communication module 211 can be simply referred to as WiFi, the EC module 212 can be simply referred to as EC, the SPI Mux module can be simply referred to as SPI Mux, and the BIOS Flash module can be simply referred to as BIOSFlash.

[0035] like Figure 3 As shown in the figure, this application embodiment proposes a firmware update method, which can be executed by an electronic device and includes the following steps.

[0036] S301: In standby mode, in response to update tasks from the cloud, downloads the firmware file for the update task in chunks from the cloud.

[0037] S302: Write the received firmware file to the firmware cache of the electronic device in a preset manner.

[0038] S303: After performing security verification on the written firmware file and passing the verification, set the boot flag in the firmware cache.

[0039] S304: Switch to boot state and load the firmware file from the firmware cache to boot according to the boot flag.

[0040] As can be seen, the above firmware update method supports firmware updates for electronic devices in standby mode. The CPU, PCH, ME, and OS of the electronic device do not need to be started or involved in the process. The EC independently completes the receiving, signature verification, and writing to achieve firmware updates.

[0041] In order to achieve the above Figure 2 The described firmware update system needs to implement the power supply domains of each module of the electronic device (such as a laptop) in the firmware update system under S5 state. Referring to Table 1, the power supply domains of each module are divided as follows.

[0042]

[0043] Table 1 Referring to Table 1, it can be seen that the Always-On domain (3.3V_ALW) is continuously powered in S5 state, covering EC, RTC, SPI Mux, and BIOS Flash. This embodiment utilizes this domain to ensure the EC's operation and update logic. The standby domain (3.3V_S5) is also powered, but only used for some PCH standby logic, and this embodiment does not rely on it. The main power domain (VCC_CORE / VCC_SA) is powered off in S5, involving the CPU, PCH main logic, and memory, and this embodiment does not rely on these components. The peripheral domain (3.3V / 5V_RUN) is also powered off, covering WiFi, USB, hard disk, etc., but this embodiment provides power to the WiFi communication module separately through EC, enabling it to still connect to the network independently in S5.

[0044] In other words, the core of this power domain division lies in the following: the Always-On domain provides continuous power to the EC and BIOS Flash, enabling the EC to operate in S5 and directly access the Flash; although the peripheral domain is powered off, the WiFi is independently powered by the EC, thus enabling remote firmware updates in S5 state without relying on the main power domain and the peripheral domain. This hardware structure solves the dual problems of the EC being able to run but unable to access the BIOS Flash and the WiFi being powered off.

[0045] The WiFi communication module can operate without external domain power. Instead, it is powered independently by a low-dropout regulator (LDO) controlled by the EC module's GPIO. This ensures that the WiFi communication module can be woken up by the EC or autonomously in S5 state. This gives the WiFi communication module independent network communication capabilities in S5 state, without relying on other components of the electronic device.

[0046] In some embodiments, since the BIOS Flash module 213 is connected to the PCH SPI bus, and the PCH master domain is powered off in state S5, the EC cannot access the BIOS Flash through the PCH. To achieve the above... Figure 2 The described firmware update system also needs to implement an access channel between the EC module and the BIOS Flash module.

[0047] This application proposes two feasible solutions, Solution A and Solution B. Solution A includes an EC module combined with an independent SPI bus, with access arbitration implemented through an SPI Mux module. In the PCB design, the EC module leads out a set of SPI buses, which are connected to the CS# / CLK / MOSI / MISO pins of the BIOS Flash module through the SPI Mux module. The strobe signals of the SPI Mux module are controlled by the EC module, as shown in Table 2.

[0048]

[0049] Table 2 Referring to Table 2, a 2:1 SPI Mux module is added before the CS# pin of the BIOS Flash module. The inputs of the SPI Mux module are connected to PCH SPI_CS# and EC SPI_CS#, respectively, and the output is connected to FlashCS#. CLK / MOSI / MISO can be handled similarly or with bus isolation. In some embodiments, Scheme B includes eSPI FlashSharing, and some EC modules support eSPI Flash Sharing Mode. The EC module connects to the PCH as an eSPI Slave, and its Flash Channel can be configured as a Flash Master, taking over the SPI Flash when the PCH enters a low-power state. It can be seen that Scheme B requires the PCH platform to support eSPI Flash Sharing, and the BIOS needs to be configured with the EC as the Flash Sharing Master. Scheme B is less compatible than Scheme A. For the SPI Mux module, the available SPIMux module types can be found in Table 3 below.

[0050]

[0051] Table 3 In some embodiments, the technical solutions in Tables 2 and 3 above can enable the EC module to access the BIOS Flash module. However, when the EC module accesses the BIOS Flash module, it may encounter an access conflict with the PCH (in non-S5 states, such as during power-on). Therefore, a PCH power-off detection and Mux switching safety mechanism is required. That is, before the EC module switches to SPI Mux to access the BIOS Flash module, it must be confirmed that the PCH master domain is completely powered off; otherwise, simultaneous driving of the SPI bus by the EC and PCH will cause a bus conflict, potentially damaging the Flash chip or the PCH. Referring to Table 4 below, embodiments of this application can employ a dual detection mechanism to ensure safe switching between the EC and PCH.

[0052]

[0053] Table 4 In some embodiments, the dual detection mechanism may include the switching timing and safety interlocking mechanism implemented by the EC module controlling the SPI Mux module. Specifically, the EC module confirms that the main control chipset of the electronic device is powered off through the dual detection mechanism, which includes: the EC module detecting that the first power status signal is low for more than a preset duration; and the EC module sampling the core voltage through the analog-to-digital converter to confirm that the core voltage is below a preset threshold. In response to both detection mechanisms being satisfied, the EC module controls the switching unit via GPIO to take over the bus of the firmware buffer; and reads the hardware identity identifier of the firmware buffer to confirm that bus communication is normal.

[0054] As shown in Table 4, the switching timing that the EC module can control the SPI Mux module to achieve includes: detecting that SLP_S5# is pulled low (the system enters the S5 state, that is, the PCH is powered off), waiting for a preset time (100ms debouncing to eliminate transition glitches from the S3 state to the S5 state), sampling VCC_CORE through the built-in ADC to confirm that the CPU core voltage has dropped below the preset threshold (0.5V) (the main domain VR (Voltage Regulator) has been turned off), confirming again that SLP_S5# is still low (excluding transition state misjudgment), switching the SPI Mux module to connect to the EC side (MUX_SEL is pulled high), taking over the Flash bus, reading the Flash JEDEC ID (the serial BIOS Flash module hardware identifier) ​​to confirm that the bus communication is normal, and starting the firmware update process.

[0055] The safety interlock mechanism includes: continuously monitoring the RSMRST# signal (PCH power reset state) during BIOS Flash module takeover. If RSMRST# changes (due to unexpected system power-on or power failure of the electronic device), the following operations are performed: releasing the SPI Mux module to the PCH (MUX_SEL pulled low), restoring the PCH's control over the BIOS Flash module, aborting the current Flash write operation (by forcibly interrupting by pulling Flash CS# high), and recording the interrupt point (current SEQ_NUM and stage state) in the EC module's NVRAM (Non-Volatile Random Access Memory). If the BIOS area of ​​the BIOS Flash module (also known as the firmware cache area, which may include a Backup area and an Active area, or only an Active area) has been partially written to and failed verification, the Active area is unaffected, and the electronic device can still boot normally.

[0056] As can be seen, when the electronic device enters the S5 state again, the EC module can read the interrupt point from the NVRAM and request a resume download from the cloud via the WiFi communication module 211 (continuing to download and write from the breakpoint SEQ_NUM). VCC_CORE sampling is implemented using the EC module's built-in ADC (e.g., a 12-bit ADC or a 10-bit ADC), requiring no additional components to be configured for the EC module. The sampling voltage divider resistor network can be configured in the motherboard VRM design (for voltage monitoring), and the EC module can sample using existing voltage divider points. SLP_S5# and RSMRST# are both PCH standard GPIO signals, already used for power state management in the EC module's firmware, requiring no additional wiring costs.

[0057] In some embodiments, for Intel Flash Descriptor and Region access control, Intel SPIFlash (Intel platform) uses the Flash Descriptor mechanism to divide regions and control access permissions. When the EC module directly takes over the Flash bus through the SPIMux module, the PCH is not in the data path, the hardware access control of the Descriptor (FRAP register) is no longer effective, and the EC has original read and write permissions for the entire Flash address space. Therefore, the above-mentioned dual detection mechanism cannot be implemented, and software-level Region protection needs to be implemented through the EC module firmware to prevent system damage to electronic devices caused by accidental writing to non-BIOS Flash module regions. Table 5 describes a region division of BIOS Flash (e.g., Intel SPI Flash) (taking 64MB Flash as an example).

[0058]

[0059] Table 5 As shown in Table 5, the Flash Descriptor region (0x000000~0x000FFF, 4KB) is protected by PCH FRAP lockout, and the EC firmware hardcodes and prohibits writing to it; the ME Region (0x001000~0x3FFFFF, approximately 4MB) is protected by PCH / ME hardware, and the EC firmware also prohibits writing to it; the BIOS Region (0x400000~0x3FFFFFF, approximately 60MB) is controlled by PCH FRAP, but the EC firmware is allowed to perform write operations in this region, and both the Active Region and Backup Region are located within this range; the GbE / Platform Data (optional region, variable size) is controlled by PCH FRAP, and the EC firmware hardcodes and prohibits writing to it.

[0060] In other words, when the electronic device is in operation, the EC module can read the registers of the firmware cache area, obtain the base address and limit address of the firmware area, and store them in the non-volatile memory of the EC module; when performing firmware updates in standby mode, before each write operation, the EC module checks whether the target address is within the base address and limit address of the firmware area; if the target address falls outside the firmware area, the write operation is rejected.

[0061] Therefore, the EC module can implement a software-level Region protection mechanism (four layers of protection). Protection layer 1 involves BIOS region boundary pre-reading (one-time during S0 phase). When the electronic device's system is running normally in S0, the EC module reads the FREG (Flash Region) register in the Flash Descriptor via eSPI or LPC to obtain the base address (BIOS_Base) and limit address (BIOS_Limit) of the BIOS region in the BIOS Flash module, forming the BIOS region boundary, and storing it in the EC NVRAM. When the electronic device subsequently enters S5 state for firmware updates, the EC module only allows writing within the range [BIOS_Base, BIOS_Limit]. The operation of protection layer 1 is completed in the S0 state phase and does not affect the S5 update process. Protection layer 2 involves address range verification (before each write operation). The EC module's firmware is configured to check whether the target address to be written to the firmware file is within the pre-stored BIOS region boundary before each firmware update (before the Flash write operation). (For example, the verification logic if(target_addr...)<BIOS_Base)or(target_addr+write_len> BIOS_Limit)thenREJECT. If the target address falls within the Descriptor, ME, or GbE region, write is directly rejected and an error (address out of bounds) is reported to the cloud via the WiFi communication module. The verification of protection layer 2 is implemented in hard-coded form in the firmware code of the EC module and cannot be bypassed by external instructions. Protection layer 3, Backup region boundary constraint. Both Active and Backup regions are divided within the BIOS region. The firmware configuration of the EC module is to calculate the Backup region address based on the pre-read BIOS region boundary: Backup_Base = BIOS_Base + BIOS_Size / 2 (or calculated according to the actual layout of the electronic device), ensuring that the Backup region does not exceed the BIOS region boundary. If the BIOS region is insufficient to accommodate both regions (BIOS_Size < 2 × BIOS file size), the EC falls back to a single-region scheme. Protection layer 4, Flash Descriptor write protection. The firmware configuration of the EC module is to increment the Flash write address from Backup_Base by SEQ_NUM during firmware update in S5 state, never reaching the Descriptor region (0x000000~0x000FFF). Even if an exception such as SEQ_NUM overflow causes an address calculation error, it will be blocked by the address range check in protection layer 2. Furthermore, the EC module firmware does not modify any configuration registers except for write-enable operations on the BIOSFlash module's status register, thus preventing accidental modification of the BIOSFlash module's protection bits.

[0062] In some embodiments, the EC module can also collaborate with Intel Boot Guard, including: the BootGuard verification key hash value is stored in PCH Fuses, corresponding to the OEM public key hash value in the Flash Descriptor. Firmware files written by the EC module to the BIOS Flash module must be signed with the same OEM Boot Guard private key to ensure the BootGuard verification chain is not broken. The Intel Flash Descriptor itself does not need to be modified; the EC module only needs to perform Active / Backup switching within the BIOS area, while the Descriptor and ME areas remain unchanged.

[0063] As can be seen, the security of the EC module directly writing to Flash is ensured by software-level region protection, rather than relying on the PCH hardware, through the aforementioned software-level region protection mechanism. The EC module's firmware code area lock bit prevents runtime tampering with the protection logic. The software-level region protection mechanism ensures that even if the EC module's firmware has defects, the Descriptor / ME area cannot be accidentally written to.

[0064] After introducing the technical solution corresponding to the EC module in the firmware update system, the WiFi communication module in the firmware update system will be introduced below.

[0065] First, in this embodiment, a WiFi communication module with the hardware parameters shown in Table 6 can be selected. This module is powered by EC GPIO in S5 state and operates independently of the system WiFi.

[0066]

[0067] Table 6 As can be seen, regarding the WiFi communication module mentioned above, in terms of WiFi protocol, the WiFi communication module can support 802.11 b / g / n, meeting the requirements of HTTPS / MQTT transmission; its built-in mbedTLS (TLS 1.2 / 1.3) allows the EC to operate independently without participating in encryption calculations, with TLS encryption and decryption handled entirely by the module; the MCU core is a single-core RISC-V 160MHz, capable of independently running HTTPS / MQTT clients without relying on the CPU or OS of the electronic device; the standby power consumption is only about 5μA (Deep Sleep), and the working power consumption in S5 state is about 120mA, only working briefly when receiving firmware files or heartbeat polling, which is beneficial to battery life; in terms of interfaces, it supports UART / SPI / I2C, with UART connection to the EC being the simplest; it has built-in 4MB Flash and 400KB RAM, which is sufficient to cache BIOS block data.

[0068] The connection between the EC module and the WiFi communication module can be achieved in the following ways: SPI: The EC module's SPI channel connects to the WiFi communication module's SPI slave interface, with a 40MHz clock speed; a 32MB transfer takes only ~6.7 seconds. SPI is the main data channel between the EC module and the WiFi communication module, used for high-speed BIOS file transfer. UART: The EC module's UART TX / RX connects to the WiFi communication module's UART RX / TX, with a baud rate of 115200, used for control command interaction and status reporting (small data volume). GPIO Power Control: The EC module's GPIO connects to the WiFi communication module's EN pin, controlling its power-on / power-off, enabling the EC module to manage the WiFi communication module's power. GPIO Wake-up Interrupt: The WiFi communication module's GPIO connects to the EC module's interrupt pin, used to wake up the EC module after the WiFi communication module receives an update task from the cloud.

[0069] Next, the functions that the selected WiFi communication module can perform are described, referring to the above. Figure 1 The functional description of the WiFi communication module shows that it mainly implements device discovery and remote update triggering mechanisms. When the electronic device is in S5 state, that is, when the electronic device's system is powered off (WiFi is powered off), how does the cloud deliver update tasks to the electronic device? Specifically, the cloud does not need to know the electronic device's IP address. The WiFi communication module actively connects to the cloud via an outbound connection. The device identity is identified by a unique ID, not a network address (similar to the principle of push notifications for IoT devices and mobile phones).

[0070] like Figure 4 As shown in the figure, this application embodiment proposes a process for implementing a device discovery and remote update triggering mechanism in a WiFi communication module of a firmware update system, such as... Figure 4 As shown, it includes the following steps.

[0071] Step S401: Accept device registration.

[0072] Specifically, the electronic device performs a one-time configuration of the WiFi communication module in the S0 state. When the electronic device is first deployed in the application environment (enterprise) or joined to the management domain (enterprise domain), the system-side management (OS Agent: Windows service or Linux daemon) of the electronic device writes the following configuration as described in Table 7 to the WiFi communication module through UART.

[0073]

[0074] Table 7 As shown in Table 7, the electronic device performs a one-time configuration of various parameters for the WiFi communication module in the S0 state. Among these, the WiFi credentials include the SSID and password (WPA2-PSK) or the 802.1X certificate (WPA2-Enterprise), written to the WiFi communication module's Flash by the OSAgent via UART; the cloud address includes the MQTT Broker URL and HTTPS API URL, also written by the OS Agent; the device's unique identifier consists of the electronic device's serial number (e.g., laptop serial number) and the WiFi communication module's MAC address, stored in the WiFi communication module's Flash and the cloud registry for subsequent device identification; the current BIOS version is read by the OS Agent from the SMBIOS and stored in the EC's internal Flash; and the mTLS certificate (client certificate and private key, used for optional bidirectional TLS) is written by the OS Agent to the WiFi communication module's Flash security area via UART.

[0075] After the write operation is complete, the WiFi communication module sends a registration request to the cloud via HTTPS. The cloud then stores information such as the device's unique identifier, MAC address, and current BIOS version in the device registry configured on the cloud. Afterward, the electronic device in S5 state can independently connect to the cloud via the WiFi communication module, without the need for the electronic device's operating system (OS).

[0076] Step S402: Complete device identification.

[0077] Specifically, the cloud identifies electronic devices through a three-layer mechanism described in Table 8 below, which can do so without relying on the IP address of the electronic device.

[0078]

[0079] Table 8 As shown in Table 8, the cloud can identify electronic devices through a three-layer mechanism, without relying on the device's IP address. The first layer is the MQTT Client ID, where the device serial number serves as the MQTT Client ID. The cloud routes messages based on this Client ID to achieve basic identity verification. The second layer is the mTLS client certificate, where the WiFi communication module displays a factory-programmed client certificate to prevent device identity forgery and provide two-way TLS authentication-level security. The third layer is the application layer token, where the WiFi communication module carries a cloud-issued device token in the request. This token supports revocation and rotation, further enhancing the flexibility and security of identity authentication.

[0080] Upon each wake-up, the WiFi communication module obtains an arbitrary IP address via DHCP and then proactively initiates an outbound TCP connection (MQTT over TLS or HTTPS) to the cloud. Since the connection is outbound, enterprise NAT gateways and firewalls will not block it, eliminating the need to open inbound ports on the firewall. The cloud detects that the socket is being proactively connected by the electronic device and does not verify the device's IP address.

[0081] As can be seen, steps S401 and S402 above can be executed on the cloud side.

[0082] Step S403: Execute heartbeat polling in state S5.

[0083] Specifically, the WiFi communication module does not maintain a continuous online connection with the cloud in S5 state, but instead actively contacts the cloud by periodically waking up. The complete heartbeat polling cycle is shown in Table 9 below.

[0084]

[0085] Table 9 Referring to Table 9, the complete heartbeat polling cycle of the WiFi communication module in S5 state can be divided into six steps. Step ① Deep Sleep: WiFi enters deep sleep, waiting for the timer or DTIM to wake it up, taking 1~5 minutes (configurable), consuming approximately 5μA; Step ② WiFi Association: Reads the SSID / password from Flash to associate with the AP, taking approximately 300ms, consuming approximately 50mA; Step ③ DHCP: Broadcasts to obtain an IP address, taking approximately 200ms, consuming approximately 50mA; Step ④ MQTT Connection: Outbound TLS connection to the cloud MQTT Broker, using the device ID as the Client ID, taking approximately 500ms, consuming approximately 50mA; Step ⑤ Reporting + Querying: Reports the current BIOS version and S5 state, and queries pending tasks, taking approximately 100ms, consuming approximately 50mA; Step ⑥ Judgment: If there are pending tasks, wakes up the EC; otherwise, disconnects and returns to Step ①, taking less than 1ms.

[0086] In other words, a single heartbeat poll (steps ② to ⑤) takes approximately 1.1 seconds, with an average current of ~50mA (e.g., WiFi transmission peak ~120mA, reception ~45mA, weighted average). With a 5-minute polling interval, this equates to an average of 288 heartbeats per day, having minimal impact on the battery configuration of electronic devices (using a standard 50Wh battery as an example).

[0087] Step S404: Perform WiFi compatibility test.

[0088] Specifically, the application network environment of electronic devices (such as enterprise environments) typically deploys WPA2-Enterprise (802.1X) authentication. The ESP-IDF framework of the WiFi communication module supports EAP-PEAP (username + password), EAP-TLS (client certificate), and EAP-TTLS. In S0 state, the OS Agent writes the enterprise WiFi's EAP credentials to the WiFi communication module's cache (Flash). In S5 state, the WiFi communication module uses the stored EAP credentials to complete 802.1X authentication, without requiring the involvement of the electronic device's OS.

[0089] Step S405: Configure heartbeat polling mode to achieve power consumption trade-off.

[0090]

[0091] Table 10 Specifically, referring to the power consumption required for the four heartbeat polling modes listed in Table 10, the Deep Sleep timed polling mode with a polling interval of 5 minutes (lowest power consumption) can be configured with the WiFi communication module by default. The cloud can also mark priorities in update tasks. For emergency security patch update tasks, the WiFi communication module of the electronic device can be temporarily controlled to switch to Light Sleep+MQTT keep-alive mode. When the next heartbeat polling is triggered, the mode switching command is sent from the cloud to the electronic device.

[0092] Step S406: Receive mode switching instruction.

[0093] Specifically, in order to balance the power consumption of electronic devices and the response speed of firmware updates in S5 state, referring to Table 11, the cloud can configure a three-level response strategy mode switching command, which is dynamically switched by the cloud according to the priority of firmware updates and sent to the electronic devices.

[0094]

[0095] Table 11 Referring to Table 11, the Normal mode is used during daily standby without urgent tasks. The WiFi communication module is configured as Deep Sleep + 5-minute (min) polling, with a response latency of ≤5 minutes. The S5 power consumption is approximately 4.5mAh / day, and it operates as the default mode. The Urgent mode is triggered when an urgent security patch is available in the cloud. The WiFi communication module switches to DTIM=3 WiFi monitoring or Light Sleep + MQTT keep-alive mode, reducing the response latency to <1 second or <5 seconds. The S5 power consumption increases to approximately 20~48mAh / day. The switching method is achieved by the cloud sending a mode switching command during the next heartbeat. The Scheduled mode is suitable for IT administrators to set batch update windows (e.g., 2 AM). The WiFi communication module wakes up periodically via RTC, with a response latency of 0 seconds (timed wake-up). The power consumption is the same as in Normal mode, and the switching is achieved by the cloud sending a wake-up schedule during daily heartbeats.

[0096] The Normal→Urgent switching process involves the cloud responding with a "URGENT mode" command when the electronic device next polls for heartbeats. The WiFi communication module then switches to DTIM=1 keep-alive or LightSleep+MQTT keep-alive, allowing the cloud to immediately push update tasks to the electronic device. Once the update is complete, the WiFi communication module automatically switches back to the previous heartbeat polling mode.

[0097] In Scheduled mode, the cloud sends a timed wake-up schedule (e.g., "Daily 02:00 Wake-up Check") during heartbeat polling. The WiFi communication module is set to a clock reminder, and automatically wakes up the check task at the scheduled time, proactively contacting the cloud without waiting for heartbeat polling. This is suitable for planned batch BIOS updates within an enterprise.

[0098] Step S407: Update progress report.

[0099] Specifically, since the screen of the electronic device is off in S5 state, users or IT administrators cannot directly observe the firmware update progress. The EC module controls the WiFi communication module to report the update progress to the cloud in real time. Simultaneously, referring to Table 13, the EC module controls LED indicators to provide visual feedback on the update progress based on the electronic device. The real-time update progress reporting process includes: after the EC module completes processing a 4KB data block, it sends a status frame to the WiFi communication module via UART. The WiFi communication module collects this data and reports the update progress to the cloud every 10 seconds via MQTT progress messages.

[0100]

[0101] Table 12 Referring to Table 12, the EC reports the firmware update progress at each stage to the cloud in real time via the WiFi communication module. After processing each data block, the EC sends a status frame to the WiFi communication module via UART, and the WiFi communication module reports this information to the cloud in batches every 10 seconds via MQTT.

[0102] The reporting phase includes six states: ERASING (0x01), indicating that the Flash erase Backup area is being erased, with a progress granularity of 1 incremented every 64KB block, typically taking about 77 seconds; WRITING (0x02), indicating that streaming data reception, incremental SHA-256 calculation, and Flash programming are being performed, with a progress granularity of 1 incremented every 4KB block, typically taking about 60 seconds; VERIFYING_SIG (0x03), indicating ECDSA signature verification, which is a single-step process, taking about 1 second; VERIFYING_WRITE (0x04), indicating that Flash data is being read back and SHA-256 checksum is being recalculated, with a progress granularity of 1 incremented every 4KB block, taking about 13 seconds; DONE (0x05), indicating that the update is complete and the progress is 100%; ERROR (0xFF), indicating that the update failed and carrying an error code.

[0103] An example of an MQTT progress message is shown below: {"task_id":"TASK-20250701-001", "device_sn":"SN5CG1234XYZ","stage":"writing","progress_pct":45.2","chunks_done":3700","chunks_total":8192","elapsed_sec":62","est_remaining_sec":75","error_code":0}, where device_sn is the unique identifier of the electronic device.

[0104] Similarly, Table 13 describes the process of indicating the firmware update progress via LED indicator (EC module control power LED).

[0105]

[0106] Table 13 Referring back to Table 13, the EC provides users with local visual feedback on the firmware update progress by controlling LED indicators (such as the power LED). Since the screen is off in S5 mode, users cannot directly observe the update status through the display; therefore, LED indicators become the most intuitive human-computer interaction method. Five LED modes correspond to different stages: slow flashing (1Hz) indicates that Flash is being erased (ERASING stage); fast flashing (2Hz) indicates that firmware data is being received and written to Flash (WRITING stage); constant light indicates that verification (signature verification or readback verification) is being performed; three flashes followed by extinguishing indicate a successful update; three consecutive flashes in a cycle indicate an update failure, and the specific error code can be obtained by the user or IT administrator through the cloud.

[0107] Step S408: Perform exception handling.

[0108] Specifically, during the firmware update process, various abnormalities may occur in electronic devices. The WiFi communication module can be configured to handle abnormal scenarios according to the abnormal scenarios described in Table 14.

[0109]

[0110] Table 14 Referring to Table 14, the WiFi communication module handles various abnormal scenarios to ensure the robustness and reliability of firmware updates in S5 state. Electronic devices not within WiFi coverage: The WiFi communication module retryes 3 times and then gives up, returning to Deep Sleep. It will automatically trigger again upon entering WiFi coverage, avoiding unnecessary power consumption. Weak / unstable WiFi signal: After MQTT connection timeout (30 seconds), it disconnects and retryes, up to 3 times, with the interval increasing exponentially to prevent frequent retries from exacerbating network congestion. Cloud unreachable: After DNS resolution failure or TCP connection timeout, it returns to Deep Sleep, waiting for the next heartbeat polling retry to avoid infinite waiting. Electronic devices repeatedly fail to execute heartbeat polling: The WiFi communication module reports an error counter to the EC. The EC alerts the IT administrator via OSAgent upon the next S0 startup, enabling traceability and manual intervention for anomalies. NB-IoT backup channel: If an NB-IoT module is deployed, the WiFi communication module can be woken up via SMS, providing a cellular-level backup wake-up path and enhancing reachability in extreme scenarios.

[0111] Step S409: Process expired 802.1X certificates.

[0112] Specifically, electronic devices deployed in the application network environment need to pass 802.1X authentication with the enterprise WiFi to connect to the cloud and perform firmware updates. 802.1X authentication relies on client certificates, which typically have a validity period of 1-2 years. If the certificate expires, the WiFi communication module of the electronic device cannot complete 802.1X authentication, will be unable to connect to the enterprise WiFi, and will cause the firmware update function to fail in S5 state. Therefore, the following lifecycle certificate management mechanism needs to be configured for the WiFi communication module: Phase 1: Certificate validity monitoring. Each time the WiFi communication module wakes up and polls, it checks the NotAfter field (X.509 validity period) of the local certificate. When the remaining validity period of the certificate is less than the preset period (less than 30 days), it reports a "certificate is about to expire" alarm to the cloud via MQTT, triggering the cloud to execute the certificate renewal process (if less than 7 days, it can be upgraded to an emergency alarm). Phase 2: Pre-expiration cloud push renewal (when the certificate is still valid). After generating a new certificate in the cloud, it is pushed to the WiFi communication module of the electronic device via MQTT. The WiFi communication module stores the new certificate in the Flash security area of ​​the electronic device's WiFi communication module (coexisting with the old certificate), and sets the automatic switchover time to the NotAfter time of the old certificate. When the old certificate expires, it automatically switches to the new certificate, thus renewing the certificate. This can be completed in S5 mode without the involvement of the electronic device's OS.

[0113]

[0114] Table 15 Processing expired 802.1X certificates may also include: Phase 3: Certificate expiration downgrade processing (renewal window has been missed).

[0115] If the certificate has expired and has not been renewed in time (e.g., the electronic device is not within WiFi coverage for a long time), the WiFi communication module will execute the downgrade process described in Table 16 after detecting the EAP authentication failure.

[0116]

[0117] Table 16 Phase 4: S0 Recovery Process. When the electronic device boots up and enters S0 state again, the OS Agent reads the CERT_EXPIRED flag in the EC module's NVRAM via UART. If the flag is true, the OS Agent displays an IT administrator notification (or automatically requests a new certificate via the enterprise IT API) and writes the new certificate to the WiFi communication module's Flash security area via UART. After writing is complete, the error flag is cleared, restoring the electronic device's firmware update capability in S5 state.

[0118] In other words, the WiFi communication module checks the remaining validity period of the local 802.1X client certificate each time it wakes up. If the remaining validity period is less than the first preset threshold (30 days), the WiFi communication module reports a certificate expiration alarm to the cloud via MQTT. It also receives new certificates pushed by the cloud, stores the new certificates in the Flash security area of ​​the WiFi communication module, and sets an automatic switching time. When the automatic switching time arrives, it automatically switches to the new certificate.

[0119] As can be seen, renewing certificates via MQTT while they are still valid avoids a deadlock due to network connectivity issues after expiration. The cloud should maintain a certificate validity dashboard that can automatically trigger the renewal process. For devices that are offline for extended periods, it is recommended to configure a WPA2-PSK backup network or an EAP-PEAP downgraded authentication method to reduce manual intervention by IT administrators.

[0120] After introducing the technical solution corresponding to the WiFi communication module in the firmware update system, the following section introduces the communication and security architecture between the EC module and the WiFi communication module in the firmware update system.

[0121] In some embodiments, firmware updates require ensuring the security of firmware files to prevent unauthorized firmware updates from causing malfunctions in electronic devices. The firmware update system in this embodiment employs a layered security architecture between the EC module and the WiFi communication module. Referring to Table 17, TLS encryption is performed by the WiFi communication module (mbedTLS), and signature verification is performed by the EC module.

[0122]

[0123] Table 17 Specifically, the EC module's firmware is configured with the OEM's HMAC-SHA256 and ECDSA P-256 public keys (burned into the EC module's OTP Flash at the factory and cannot be modified). The firmware file signature verification process includes the steps described in Table 18 below.

[0124]

[0125] Table 18 In some embodiments, for EC modules without a hardware SHA-256 accelerator, a pure software streaming SHA-256 calculation method is configured via firmware (an 8MB firmware file takes approximately 60-120 seconds to perform SHA-256 calculation, and a 32MB file takes approximately 240-480 seconds). The EC module also has rollback protection configured, and its firmware maintains a "minimum allowed version number" counter. Each time the firmware is updated, the EC module checks if the firmware file's version number is greater than or equal to the minimum allowed version; if it is lower, the write operation is rejected. After a successful firmware file write, the minimum allowed version number is updated (only incremented, never decremented). The rollback protection counter is stored in a protected area of ​​the EC module, writable only by the EC module's firmware and cannot be tampered with externally.

[0126] like Figure 5 As shown, this application proposes a firmware update method applicable to electronic devices and the cloud, such as... Figure 5 As shown, the firmware update method can be performed unilaterally by the electronic device and includes the following steps.

[0127] Step S501: Trigger the update task.

[0128] Specifically, the WiFi communication module of the electronic device receives firmware update tasks from the cloud via heartbeat polling. That is, the IT administrator creates an update task in the cloud (specifying the device serial number and BIOS version), and sets the task status to pending. The electronic device's WiFi communication module wakes up according to a three-level response strategy (Normal / Urgent / Scheduled) and establishes an MQTT connection with the cloud. The cloud matches the pending task based on the MQTT Client ID and pushes an update notification. Upon receiving the notification, the WiFi communication module wakes up the EC module via a GPIO interrupt. After confirming that the electronic device is in S5 state, the EC module executes the update task.

[0129] Step S502: Firmware file download and streaming.

[0130] Specifically, the WiFi communication module establishes an HTTPS connection with the cloud, downloads the firmware file in chunks (4KB each), and forwards it to the EC module via SPI. The EC module uses a streaming write method, which involves calculating the incremental SHA-256 and directly writing it to the Backup area of ​​the BIOS Flash module every 4KB of data received, without caching the firmware file internally within the EC module. For example, with a 32MB firmware file, it is streamed through the EC module in 4KB units. At any given moment, the EC module only occupies approximately 4.5KB of memory (e.g., 4KB receive buffer + 256B Flash page buffer + 100B SHA-256 state), regardless of the actual file size of the firmware file.

[0131] Step S503: Signature verification.

[0132] Specifically, after the firmware file is streamed into the Backup area, the EC module assembles the final SHA-256 hash value, verifies the signature using the configured ECDSA P-256 public key, and compares the version number (to prevent rollback) and device ID (to prevent accidental flashing). If either check fails, the EC module does not switch the Active flag and reports the error to the cloud via the WiFi communication module. Since the data is written to the Backup area, the Active area is unaffected and will not cause the electronic device to fail to boot.

[0133] Step S504: Read back the verification.

[0134] Specifically, the EC module rereads the firmware file recently written to the Backup area of ​​the BIOS Flash module, calculates the SHA-256 hash, and compares it with the hash value from step S403. If the verification fails, the Backup area is marked as invalid, while the Active area remains unaffected, and the electronic device can still boot through the Active area.

[0135] Step S505: Power-on verification.

[0136] Specifically, the EC module switches the Active flag (pointing to the Backup area of ​​the BIOS Flash module), releases the SPIMux module to the PCH, and allows normal power-on. The PCH then verifies the signature (if enabled) from the Backup area of ​​the updated BIOS Flash module using Boot Guard.

[0137] Step S506: Progress report.

[0138] Specifically, if the boot is successful, the EC module reports a successful update, and firmware synchronization can be completed between the Backup area and the Active area. If the boot fails, the EC module switches back to the Active area of ​​the BIOS Flash module and reports a recovery.

[0139] As can be seen, taking a 32MB firmware file as an example, with the SPI configured as a 40MHz interface and 64KB block erasure as an example, Table 19 describes the time consumption and execution content of each stage in the firmware update method.

[0140]

[0141] Table 19 As can be seen, the update time (excluding heartbeat polling) during the entire update process can be determined based on the EC module model. For example, for hardware SHA-256, it's approximately 151 seconds ≈ 2.5 minutes, and for software SHA-256, it's approximately 510 seconds ≈ 8.5 minutes. If the average heartbeat wait (5-minute polling) is included: for hardware SHA-256, it's approximately 301 seconds ≈ 5.0 minutes; for software SHA-256, it's approximately 660 seconds ≈ 11.0 minutes. In other words, using Urgent mode (DTIM monitoring) eliminates the heartbeat wait, and for hardware SHA-256, the time can be reduced to 156 seconds.

[0142] The following addresses the above. Figure 5 The steps in the described firmware update method are described in detail. The update notification (MQTT message) in step S401 may contain the following metadata as described in Table 20.

[0143]

[0144] Table 20 The 4KB bulk transfer protocol between the EC module and the WiFi communication module can use 4KB (one Flash Sector) as the basic transmission unit. The transmission frames from the WiFi communication module to the EC module are shown in Table 21 below.

[0145]

[0146] Table 21 The format of the response frame from the EC module to the WiFi communication module is shown in Table 22 below.

[0147]

[0148] Table 22 The transmission process between the EC module and the WiFi communication module is as follows: After receiving a 4KB transmission frame, the EC module verifies the continuity of CRC32 and SEQ_NUM. If the verification is successful, it writes the frame to the Backup area of ​​the BIOS Flash module and sends an ACK response frame. Upon receiving the ACK, the WiFi communication module sends the next frame. If the CRC check fails, the EC module sends an ACK response frame, and the WiFi communication module retransmits the same transmission frame. After three consecutive NACKs, the EC module sends an ABORT response frame, and the WiFi communication module stops updating and reports an error.

[0149] As can be seen from Table 23 below, 4KB reduces the number of handshakes by 16 times compared to page-by-page (256B) transmission.

[0150]

[0151] Table 23 During the streaming write process in step S402, there may also be a risk of data corruption. Multi-layer protection is configured for the EC module to ensure data integrity, as shown in Table 24. Protection layer 1: CRC32 check combined with retransmission, where each 4KB data block is accompanied by a CRC32 check. After receiving the data, the EC module verifies the CRC32 first. If they do not match, it replies with a NACK to request retransmission, ensuring no bit errors in the transmission layer. The update is aborted if retransmission fails for 3 consecutive times. Protection layer 2: SEQ_NUM continuity check. The EC module maintains an expected sequence number expected_seq (incrementing from 0). After receiving each transmission frame, it checks whether SEQ_NUM is equal to expected_seq: if SEQ_NUM==expected_seq, it indicates a normal condition, the frame is written to the Backup area of the BIOS Flash module, and then expected_seq is incremented, that is, the value of expected_seq increases by itself; if SEQ_NUM<expected_seq, it indicates that the transmission frame is a duplicate frame (possibly a retransmission), an ACK is replied but the frame is not written to the Backup area of the BIOS Flash module; if SEQ_NUM>expected_seq, it indicates a sequence number jump and intermediate data blocks are lost, an ABORT is replied to abort the update. The write address of the Backup area of the BIOS Flash module is accurately calculated by SEQ_NUM: flash_address=backup_base+SEQ_NUM×4096, ensuring each data block is written to the correct position in the Backup area of the BIOS Flash module. Flash Page Program address alignment: the Page Program of SPINOR Flash has an address wrap-around trap. If the write address is not aligned by 256 bytes, data exceeding the page boundary will wrap around to the page start and overwrite existing data. In this protocol, each 4KB block is split into 16 Page Program operations, and the address is strictly calculated as base+page_index×256, which is naturally 256-byte aligned to eliminate the wrap-around risk. WIP bit polling: after each Flash erase or Page Program operation, the EC module must poll the WIP (Write In Progress) bit of the status register of the BIOS Flash module, and wait for the BIOS Flash module to complete the internal operation before sending the next command. If the WIP polling is skipped, the BIOS Flash module in a busy state will ignore new commands, resulting in data loss.

[0152] In some embodiments, the EC module can also perform SHA-256 combined with readback verification. Even if all four layers of protection fail, the following verifications can still be performed: ① If the SHA-256 hash value does not match after writing, the ECDSA signature verification fails; ② The hash value is recalculated after reading back the Flash data to ensure that the written content is consistent with the received content. The Active flag of the BIOS Flash module is switched only after all the above verifications pass.

[0153]

[0154] Table 24 In some embodiments, power failure during firmware updates in S5 state poses the greatest risk. To mitigate this risk, the dual-region write strategy described in Table 25 can be adopted, dividing the BIOS Flash module's Flash area into two regions (the capacity of the Flash area is greater than or equal to twice the size of the firmware file; for example, for a 32MB firmware file, the Flash area must be at least 64MB).

[0155]

[0156] Table 25 The EC module writes the new BIOS firmware to the Backup area. After successful verification, it switches the Active flag of the BIOS Flash module (stored in the Flash area header or EC NVRAM), and the next boot starts from the Backup area. If power is lost during the writing process, the Active area is unaffected, and the electronic device can still boot normally. After booting, the Backup area is restored through the Active area. Compared to the single-area solution, the EC module maintains and updates the status flag in the EC NVRAM (IDLE→WRITING (streaming reception + erasure + programming)→VERIFYING (signature verification + readback verification)→DONE). If the EC module is powered off and restarted while in the WRITING state, and the flag is still WRITING, it enters recovery mode (re-downloading and rewriting from the WiFi communication module).

[0157] It can be seen that the embodiments of this application have the following beneficial effects: 1. Supports remote firmware updates for electronic devices in S5 mode via the EC module. The CPU, PCH, ME, and OS of the electronic device remain unstarted throughout the process, with the EC module independently handling receiving, signature verification, and writing. This truly enables remote firmware updates in S5 mode, completely seamless for the user.

[0158] 2. The EC module directly reads and writes to the BIOS Flash. Through the SPI Mux arbitration mechanism, the EC module takes over the Flash bus in S5 state and accesses the PCH normally in S0 state. Existing solutions all access the Flash indirectly through the PCH or OS, while the embodiment of this application realizes direct physical access of the BIOS Flash by the EC module, eliminating the dependence on the PCH / OS.

[0159] 3. The WiFi communication module handles TLS encryption calculations, while the EC module handles ECDSA signature verification, each utilizing its own computing power. Even if an attacker gains complete control of the WiFi communication module, they cannot bypass the EC module's signature verification to write malicious firmware.

[0160] 4. Electronic devices actively connect outbound, with automatic NAT traversal. The WiFi communication module periodically and actively connects to the cloud (MQTT / HTTPS). Electronic devices are authenticated by their unique device identifier rather than their IP address. No configuration changes are required for enterprise NAT / firewalls; no public IP address or port forwarding is needed. Deployment costs are low, and compatibility is excellent.

[0161] 5. The BIOS Flash is configured with an Active / Backup dual-region write strategy, ensuring that power outages during the write process do not affect the currently running region. This guarantees that electronic devices can boot from the complete region even in the event of a power outage.

[0162] 6. Only a WiFi communication module, SPI Mux module, and LDO need to be added, resulting in low cost.

[0163] 7. Natively compatible with enterprise WiFi.

[0164] The WiFi communication module supports WPA2-Enterprise (802.1X: EAP-PEAP / EAP-TLS / EAP-TTLS). In S0 state, the OS Agent writes the enterprise WiFi credentials, and in S5 state, the WiFi communication module completes authentication independently without OS involvement.

[0165] 8. Through a key alignment mechanism, the EC module verifies that the public key used for signing matches the hash value of the Boot Guard public key in PCH Fuses. Firmware files written by the EC module must be signed with the OEM Boot Guard private key, ensuring that the boot security chain across various platforms is not compromised.

[0166] In some embodiments, particularly for the firmware update method of this application, the time consumption of each step is analyzed in detail using a 32MB firmware file as an example, through the following table. 32MB = 33,554,432 bytes = 131,072 pages (256 bytes per page) = 8,192 blocks (4KB per block) = 512 blocks (64KB per block). Flash operation parameters are shown in Table 26 below.

[0167]

[0168] Table 26 The breakdown of processing time per page (256B) (SPI 40MHz interface) is shown in Table 27 below.

[0169]

[0170] Table 27 The time taken for each stage (SPI 40MHz + 64KB block erase) is summarized in Table 28 below.

[0171]

[0172] Table 28 Flash erasure and programming are mutually exclusive operations on the same chip and cannot be performed in parallel. Whether erase-then-write or interleaved, the total time is the same. WiFi download (26 seconds) is much faster than EC processing speed. In the software solution, SHA-256 is the performance bottleneck (accounting for 82% of the total time), which can be optimized by parallelizing SHA-256 with the Flash programming pipeline: After the EC sends the Page Program command, the EC is idle during the Flash chip's internal programming period (0.40ms), and can begin receiving the next page and calculating SHA-256, reducing the effective time per page from 3.20ms to approximately 2.80ms, and the time for programming on the 32MB receiving channel from 419s to approximately 367s (saving approximately 52s). A comparison of different configuration schemes is shown in Table 29 below.

[0173]

[0174] Table 29 As can be seen, using an EC with hardware SHA-256 reduces SHA-256 time from 360 seconds to 1.3 seconds, and receive + program from 419 seconds to 60 seconds (saving 359 seconds). Updates of 32MB firmware files are shortened from 8.5 minutes to 2.5 minutes. SPI 40MHz replacing UART reduces page reception from 2.78ms to 0.05ms (saving 357 seconds). 64KB block erase replacing 4KB sector erase reduces erase time from 369 seconds to 77 seconds (saving 292 seconds). Using a faster Flash chip for erasing: some chips erase 64KB in just 50ms, reducing erase time to 26 seconds (saving 51 seconds). SHA-256 and Flash programming pipelines in parallel (software method): utilizing the EC's idle time during Flash programming to calculate the next page's SHA-256 saves approximately 52 seconds. 4KB bulk transfer protocol: reduces ACK handshakes by 16 times, saving approximately 2.5 seconds of protocol overhead.

[0175] It is understood that Intel Boot Guard is a pre-boot signature verification mechanism for the BIOS at the PCH level. The compatibility of the technical solution in this application embodiment with Boot Guard is shown in Table 30 below.

[0176]

[0177] Table 30 If Boot Guard is enabled with Verified Boot, the firmware file delivered from the cloud must be signed by the OEM using the Boot Guard private key. The verification public key in the EC configuration firmware must match the public key hash value in the PCH Fuses. Power consumption and cost estimates are shown in Table 31 below.

[0178]

[0179] Table 31 Update process power consumption (hardware solution): ~30mA (average) × 3.3V × 151 seconds ≈ 4mWh, with no significant impact on the 50Wh battery (0.008%). Software solution: ~30mA × 3.3V × 510 seconds ≈ 14mWh (0.028%). Note: ~30mA is the average current intensity during the update process (EC full speed + Flash erase / write + ESP32 intermittent transmit / receive), and the peak current only appears briefly during transmission.

[0180] In some embodiments, the total material cost required for the firmware update system of this application can be shown in Table 32 below.

[0181]

[0182] Table 32 like Figure 6 As shown, the present invention provides a method for running Figure 2 The third electronic device 60 of the firmware update system 20 shown may include a memory 601, a processor 602 and a bus, and may also include a computer program stored in the memory 601 and executable on the processor 602.

[0183] The integrated units implemented as software functional modules described above can be stored in a computer-readable storage medium, which can be non-volatile or volatile. The software functional modules stored in the storage medium include several instructions to cause a computer device (which may be a personal computer, computer equipment, or network device, etc.) or processor to execute part of the functions of the data processing methods of the electronic devices in the data processing systems of the various embodiments of this application.

[0184] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A firmware update method for an electronic device, characterized in that, include: In standby mode, in response to an update task from the cloud, the firmware file for the update task is downloaded from the cloud in chunks; The received firmware file is written to the firmware cache area of ​​the electronic device in a preset manner; After the firmware file that has been written is successfully verified, a startup flag is set in the firmware cache area; Switch to startup state and boot the device by loading the firmware file from the firmware cache according to the startup flag.

2. The firmware update method according to claim 1, characterized in that, The response to the update task from the cloud includes: Establish a communication connection with the cloud and use the unique device identifier of the electronic device for identification; After the identity verification is completed, the update task is queried from the cloud through periodic polling. When the cloud matches an update task corresponding to the unique identifier of the device, the update task pushed by the cloud is received.

3. The firmware update method according to claim 2, characterized in that, The step of querying the cloud for the update task through periodic polling includes: The periodic polling method includes one of the following: timed polling mode, keep-alive mode, and listening mode, and the frequency of querying the update task from the cloud is different for each of the periodic polling methods; Upon receiving the mode switching instruction from the cloud, the periodic polling method is switched according to the mode switching instruction.

4. The firmware update method according to claim 1, characterized in that, The step of writing the received firmware file into the firmware cache of the electronic device in a preset manner includes: The firmware file is obtained from the cloud in data blocks, wherein the size of each data block is a fixed value; Upon receiving each data block, the hash value of the data block is calculated. After verification of the hash value is successful, the data block is written to the address corresponding to the serial number of the data block in the firmware cache. During the process of writing the data block to the firmware cache, the data block is not cached in the storage area of ​​the electronic device.

5. The firmware update method according to claim 4, characterized in that, Each received data block includes: Verify the CRC32 checksum of the currently received data block; If the CRC32 checksum does not match the CRC32 field carried by the data block, request a retransmission of the data block; Verify the continuity of the sequence number of the currently received data block. If the sequence number is greater than the expected sequence number, stop the update and report the error to the cloud. If the sequence number is less than the expected sequence number, discard the currently received data block and return a continuation confirmation.

6. The firmware update method according to claim 1, characterized in that, The security verification performed on the firmware file after writing is completed includes: The firmware file version number is compared with the minimum allowed version number. If the firmware file version number is lower than the minimum allowed version number, the startup flag is not set and an error is reported to the cloud.

7. The firmware update method according to claim 1, characterized in that, The step of performing security verification on the firmware file after it has been written also includes: Read the firmware file written in the firmware cache and calculate the hash value of the firmware file; If the calculated hash value does not match the expected hash value of the firmware file, the firmware cache is marked as invalid, and an error is reported to the cloud.

8. The firmware update method according to claim 4, characterized in that, The step of writing the received firmware file into the firmware cache area of ​​the electronic device in a preset manner further includes: During the process of writing the data blocks of the firmware file into the firmware cache of the electronic device, if the boot state is detected, the control of the firmware cache is restored to the operating system of the electronic device. Abort the current data block write operation corresponding to the firmware file and record the sequence number of the data block; If a standby state is detected, the data block is rewritten into the firmware cache of the electronic device according to the recorded serial number of the data block.

9. A firmware update system for an electronic device, characterized in that, include: The WiFi communication module is used, in standby mode, to download the firmware file of the update task from the cloud in chunks in response to the update task from the cloud; EC module, the EC module is used to write the received firmware file into the firmware cache area of ​​the BIOS Flash module of the electronic device in a preset manner; The EC module is used to set a startup flag in the firmware cache area after the firmware file has been written and security verification is passed. The PCH module is used to switch to the boot state and boot the device by loading the firmware file from the firmware cache according to the boot flag via the SPI Mux module.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the firmware update method as described in any one of claims 1 to 8.

Images