Firmware upgrading method, electronic device, and storage medium

Abstract

The application provides a firmware upgrading method, an electronic device and a storage medium, and relates to the technical field of data processing. The device comprises a first partition, a second partition and a firmware partition, and the first partition and the second partition are redundant peer system partitions. The method comprises the following steps: receiving a new version of a firmware package; when the first partition is a standby partition and the second partition is a running partition, writing the firmware package into the first partition, switching to run the first partition, and monitoring the performance index of the first partition during running; determining a target partition with stable running state from the first partition and the second partition according to the performance index; and copying the firmware package in the target partition to the firmware partition in an atomic transaction mode, so that the updating of the firmware package in the firmware partition is realized, the integrity and consistency of the firmware partition updating process are ensured, and even if interruption occurs during the copying process, the target partition can still run normally, and the reliability of the device running is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a firmware upgrade method, electronic device, and storage medium. Background Technology

[0002] In fields with high availability requirements, such as intelligent connected vehicles and industrial IoT, devices typically employ an A / B partition mirroring redundancy mechanism. To enable recovery in extreme scenarios where both A and B partitions are damaged, a read-only static factory partition is usually retained.

[0003] However, since the factory partition is fixed on the production line and is no longer updated, when the device reverts to the factory version, it will lose network connectivity due to the aging of the factory partition, resulting in device disconnection. Related technologies update the factory partition by writing system image data, but if problems occur during the factory partition update process, the factory partition will be damaged and irreparable, potentially causing the device to fail to boot or recover. Summary of the Invention

[0004] This application provides a firmware upgrade method, an electronic device, and a storage medium to address the problem in related technologies where updating the factory partition by writing an image can lead to damage to the factory partition and make it unrepairable if problems occur during the factory partition update process, potentially causing the device to fail to boot or recover.

[0005] In a first aspect, embodiments of this application provide a firmware upgrade method, wherein the device includes a first partition, a second partition, and a firmware partition, and the first partition and the second partition are redundant peer system partitions; the method includes: Receive the new firmware package; When the first partition is a standby partition and the second partition is a running partition, the firmware package is written to the first partition, and the first partition is switched to run, and the performance indicators of the first partition are monitored during the running process. Based on performance metrics, a target partition with a stable operating status is determined from the first and second partitions; The firmware package in the target partition is copied to the firmware partition using atomic transactions.

[0006] Based on the above technical content, in this embodiment, upon receiving a new firmware package, if the first partition is a waiting partition and the second partition is a running partition, the firmware package is written to the first partition, and the running partition is switched. By monitoring the performance indicators of the first partition during operation, a target partition with a stable operating state is determined between the first and second partitions, thereby ensuring that a high-quality firmware package is copied to the firmware partition, avoiding the copying of firmware packages with hidden stability risks to the firmware partition, and preventing the spread of systemic failures at the backup layer. After determining the target partition, the firmware package of the target partition is copied to the firmware partition in an atomic transaction manner, realizing the updating of the firmware package in the firmware partition, enabling the firmware partition to dynamically evolve with business versions and security protocols. Through continuous firmware package version updates, even after the device has been used for a long time and a failure rollback occurs, the firmware partition still holds a newer and more valid security certificate and cloud communication protocol. This ensures that the device still has effective network access and authentication capabilities even in extreme disaster scenarios where both the first and second partitions are damaged, solving the problem of network authentication failure caused by the firmware package version in the firmware partition being too low after rollback, and improving the remote maintainability of the device. In addition, since the firmware package of the target partition is copied to the firmware partition in an atomic transaction manner, the copying operation is encapsulated as an indivisible atomic transaction, ensuring the integrity and consistency of the firmware partition update process. This avoids the risk of system boot failure due to uncertain data status within the firmware partition. Furthermore, even if an interruption occurs during the copying process, the device can still operate normally through the target partition, thus improving the reliability of device operation.

[0007] In one possible implementation, the firmware package is copied from the target partition to the firmware partition using atomic transactions, including: Based on hardware atomic transaction locks, the firmware package in the target partition is copied to the firmware partition in an atomic transaction manner; The hardware atomic transaction lock is implemented through a transaction status identifier, which is used to determine the integrity of the firmware package copied to the firmware partition.

[0008] In this embodiment, compared to methods relying on alternating switching of physical dual-redundant backup partitions to ensure firmware upgrade security, this embodiment uses a hardware atomic transaction lock mechanism to encapsulate the firmware package copying process in the target partition into an indivisible atomic transaction. This ensures the consistency of the copying operation's state, achieves logical identifiability of the firmware partition during the upgrade process, and effectively reduces the space occupied by the firmware partition on non-volatile storage media. This frees up more business storage space for resource-constrained embedded systems or enables a better redundancy strategy on hardware of the same capacity. Furthermore, even if the copying process is interrupted, the transaction status identifier can identify that the firmware package copied to the firmware partition is incomplete, thus avoiding the execution of incomplete firmware packages.

[0009] In one possible implementation, the transaction status identifier includes a transaction start identifier and a transaction end identifier; Based on hardware atomic transaction locks, the firmware package in the target partition is copied to the firmware partition in an atomic transaction manner, including: Write the transaction start identifier into the hardware security zone to lock the current operation state; Initiate a block-level copy process to copy the firmware package from the target partition to the firmware partition; After all firmware packages in the target partition are copied to the firmware partition, a transaction end flag is written to the hardware security area to unlock the current operation state and mark the completion of this atomic transaction.

[0010] Here, leveraging the authentication write capabilities of the hardware secure zone, the operation of copying the firmware package from the target partition to the firmware partition is encapsulated as an atomic transaction. By writing a transaction start identifier and a transaction end identifier into the hardware secure zone, the state of the atomic transaction is locked to the underlying hardware, resolving the issue of inconsistent states that can easily occur with software flags during abnormal power outages. Furthermore, the integrity of the firmware package within the firmware partition can be determined based on the transaction start identifier and transaction end identifier, i.e., whether there is physical damage such as tearing writes.

[0011] In one possible implementation, the firmware package contains system image data; After initiating the block-level copy process and copying the firmware package from the target partition to the firmware partition, the process also includes: Read the system image data copied to the firmware partition and determine the corresponding full hash value; If the full hash value matches the hash value corresponding to the system image data in the target partition, then all system image data in the target partition will be copied to the firmware partition.

[0012] Specifically, by comparing the full hash value of the firmware partition system image data with the hash value of the target partition system image data, the integrity of the system image data copied to the firmware partition is verified, providing a reliable basis for the write transaction end identifier.

[0013] In one possible implementation, the method further includes: After the system is powered on, read the transaction status identifier in the hardware security zone; Based on the result of reading the transaction status identifier, the corresponding logical status information is generated in memory; the logical status information is used to identify whether an interruption occurred during the process of copying the firmware package from the target partition to the firmware partition. If the logical status information identifier is interrupted, the firmware partition will be logically masked and a preset self-healing operation will be performed.

[0014] This application embodiment reads the transaction status identifier within the hardware security zone and generates corresponding logical status information in memory. Based on this logical status information, it determines whether an interruption occurred during the copying of the firmware package from the target partition to the firmware partition. In the event of an interruption, the firmware partition is logically shielded, allowing the stable first or second partition to run, thus avoiding the risk of system failure due to corrupted system image data in the firmware partition. Then, a preset self-healing operation is executed to automatically repair the system after the interruption, requiring no manual intervention and improving the remote maintainability and reliability of the device in extreme disaster scenarios.

[0015] In one possible implementation, a pre-defined self-healing operation is performed, including: Retrieve the version information of the firmware package within the firmware partition; If the version information is consistent with the version of the firmware package in the currently running partition, or if the currently running partition has a corresponding historical stability determination record, then the currently running partition will be used as the target partition, and the step of copying the firmware package in the target partition to the firmware partition in an atomic transaction will be re-executed. If the version information is inconsistent with the version of the firmware package in the currently running partition, and there is no corresponding historical stability determination record in the currently running partition, then the performance indicators of the currently running partition during operation are monitored, and the running status of the currently running partition is determined based on the performance indicators.

[0016] Based on the above technical content, and using the version information of the firmware package in the firmware partition, the version of the firmware package in the currently running partition, and historical stability judgment records, a dual-path self-healing operation of rapid self-healing and re-verification is constructed. This avoids meaningless repeated monitoring, improves efficiency, and ensures that only firmware packages of running partitions with stable running status are written to the firmware partition, thereby improving reliability.

[0017] In one possible implementation, performance metrics include storage media wear metrics, memory resource health metrics, and business operation stability metrics. Based on performance metrics, target partitions with stable operating states are determined from the first and second partitions, including: Convergence determination is performed on storage media wear indicators, memory resource health indicators, and business operation stability indicators; If the results of the assessment of storage medium wear indicators, memory resource health indicators, and business operation stability indicators all converge, then the first partition will be used as the target partition; otherwise, the second partition will be used as the target partition.

[0018] In this application embodiment, long-term convergence analysis is performed on indicators of multiple core dimensions such as storage medium wear indicators, memory resource health indicators, and business operation stability indicators. This can effectively identify and intercept defective firmware packages that can start normally but have hidden stability risks, ensuring that the firmware package copied to the firmware partition is a verified stable version, and significantly reducing the risk of systemic failures spreading in the backup layer.

[0019] In one possible implementation, convergence determination is performed on storage media wear indicators, memory resource health indicators, and service operation stability indicators, including: The system obtains the number of bad blocks in the storage medium within a preset time period, determines the rate of change of bad block growth based on the number of bad blocks, and determines whether the storage medium wear index has converged based on the rate of change of bad block growth. Based on the sampling data of memory usage level, a moving average is obtained, and based on the moving average, it is determined whether the memory resource health index has converged. Monitor the restart frequency of the preset target process and determine the convergence of the business operation stability indicators based on the restart frequency.

[0020] This section provides quantifiable convergence criteria for multiple performance indicators, including storage media wear metrics, memory resource health metrics, and service operation stability metrics. Specifically, the convergence of the storage media wear metric is determined by the bad block growth rate to identify abnormal wear on the storage media. The convergence of the memory resource health metric is determined by the moving average of memory usage levels to effectively detect chronic memory leaks. The convergence of the service operation stability metric is determined by the restart frequency of the target process to detect hidden logical failures within the system. This provides quantifiable criteria for firmware package replication, effectively identifying hidden stability risks in new firmware versions and thus preventing the replication of firmware packages with hidden stability risks to the firmware partition.

[0021] Secondly, embodiments of this application provide a firmware upgrade device, the device including a first partition, a second partition, and a firmware partition, wherein the first partition and the second partition are redundant peer system partitions; the device includes: The receiving module is used to receive new firmware packages; The processing module is used to write the firmware package to the first partition when the first partition is a waiting partition and the second partition is a running partition, switch to running the first partition, and monitor the performance indicators of the first partition during operation. The processing module is also used to determine the target partition with a stable operating status from the first partition and the second partition based on performance indicators; The processing module is also used to copy the firmware package from the target partition to the firmware partition in an atomic transaction manner.

[0022] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement a firmware upgrade method as described in any of the first aspects.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements a firmware upgrade method as described in any of the first aspects.

[0024] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0025] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

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

[0027] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 This is a schematic flowchart of a firmware upgrade method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a firmware upgrade method provided in another embodiment of this application; Figure 4 This is a schematic diagram of the interaction process of copying a firmware package from a target partition to a firmware partition based on a hardware atomic transaction lock according to an embodiment of this application; Figure 5 This is a schematic diagram of the state transition cycle of a state machine provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a firmware upgrade device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The present application will be described more clearly below with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the function of the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0029] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0030] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0031] In the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0033] Furthermore, the term "multiple" mentioned in the embodiments of this application should be interpreted as two or more.

[0034] First, the terms used in the embodiments of this application will be explained: Hash-based Message Authentication Code - Secure Hash Algorithm 256 (HMAC-SHA256) signature verification: This is an encrypted authentication algorithm used to confirm that the initiator of the write request is a legitimate main control module of the device, and not an external malicious device or illegal software.

[0035] An increment-only counter is a register integrated within the storage medium's hardware controller that increments only. It is a physical characteristic defined by the Replay Protected Memory Block (RPMB) hardware specification. Its core significance lies in providing a reference system that cannot be tampered with by software and is strictly bound to physical timing, thereby ensuring that each opening and closing of the atomic lock is unique and non-replayable.

[0036] In fields with high availability requirements, such as intelligent connected vehicles and industrial IoT, devices typically employ an A / B partition mirroring redundancy mechanism. To enable disaster recovery in extreme scenarios where both A and B partitions are damaged, such as Flash physical loss or dual-partition upgrade failure, a read-only, static factory partition is usually retained.

[0037] However, since the factory partitions are fixed on the production line and not updated, and as the device ages, the Secure Sockets Layer (SSL), Transport Layer Security (TLS) root certificates, cloud communication protocol stacks, and security encryption algorithms in the factory image will gradually become invalid or obsolete. When the device is reverted to the factory version, it will be unable to connect to the network due to failure to pass security authentication, resulting in the device becoming disconnected.

[0038] Furthermore, traditional storage media are highly susceptible to tearing during system image data writing if an unexpected power outage occurs, leading to partition structure corruption. If a power outage occurs during factory partition updates, the device will lose its backup mechanism, resulting in irreversible hardware damage.

[0039] Furthermore, the relevant technologies are usually based on the assumption that the verification is passed or that the factory partition upgrade is successful. They cannot effectively identify system image data with hidden stability risks. If the system image data is synchronized to the factory partition, it will cause the fault to spread.

[0040] The applicant discovered that, in order to achieve factory partition updates, and even when problems occurred during the factory partition update process, the device could still operate normally. Therefore, it is necessary to consider a new method for firmware upgrades.

[0041] To enable dynamic updates to the factory partition while ensuring reliable device operation during the update process, this application proposes a firmware partition independent of the first and second partitions. This firmware partition serves as a replacement and upgrade for the factory partition, providing not only a backup function for system disaster recovery but also the ability to dynamically evolve with business versions. Furthermore, during the firmware partition update process, the target partition is determined by monitoring the performance metrics of the first partition where the new firmware package is written, thus avoiding copying firmware packages with hidden stability risks to the firmware partition. Additionally, copying the firmware package from the target partition to the firmware partition using atomic transactions ensures the integrity and consistency of the firmware partition update process, avoiding the risk of system boot failure due to uncertain data states within the firmware partition. Moreover, since the update process is executed after determining a stable target partition, even if an interruption occurs during the copying process, the device can still operate normally through the target partition, improving device reliability.

[0042] First refer to Figure 1 , Figure 1 The illustration schematically depicts an application scenario provided according to an embodiment of this application. The devices involved in this application scenario include a cloud server and electronic devices. The electronic devices may be embedded devices, including firmware upgrade managers and non-volatile storage media.

[0043] Cloud servers may include version control servers and security signing servers. Version control servers can distribute new firmware packages to the over-the-air (OTA) downloaders within the firmware upgrade manager. the Air (OTA) transaction manager.

[0044] The non-volatile storage medium includes a hardware security zone and a data zone. The data zone includes a first partition, a second partition, and a firmware partition. The first and second partitions are redundant peer system partitions. The firmware partition serves as a backup partition for this system. Unlike traditional read-only system images, the firmware partition is a dynamic storage space that lags behind the current stable version and has the ability to evolve. It serves as the final self-repair baseline for the system if both the first and second partitions fail.

[0045] If the first partition is currently the waiting partition and the second partition is the running partition, the OTA transaction manager can write the new firmware package to the first partition and boot the system to switch to the first partition for operation.

[0046] In addition to the OTA transaction manager, the firmware upgrade manager also includes a multi-dimensional metrics monitor and a stability arbitration engine. The multi-dimensional metrics monitor is used to monitor the health status of the kernel and hardware layer during the first partition's operation, including but not limited to physical block write / erase balance, memory level fluctuation trends, and critical task restart frequency, providing raw data support for stability arbitration.

[0047] The stability arbitration engine serves as the system's decision-making hub, integrating a first-order derivative convergence algorithm to monitor the rate of change of performance metrics. When the performance metrics exhibit statistical convergence over a long time dimension, the first partition can be used as the target partition; otherwise, the second partition is used.

[0048] Once the target partition is identified, the firmware package for the target partition can be copied to the firmware partition in an atomic transaction manner using hardware atomic transaction locks, thereby updating the firmware partition. Specifically, the OTA transaction manager can establish a secure handshake with the hardware secure zone using HMAC and mark the transaction start identifier in the RPMB within the hardware secure zone. Subsequently, the firmware package from the target partition is copied to the firmware partition. This indicates that the data source of the firmware partition is not an untrusted download from the external network, but rather data from the target partition whose operating status has been determined through performance index testing, thus ensuring the reliability of the firmware partition.

[0049] In one implementation scenario, the hardware secure zone includes the RPMB, which is physically isolated and protected. In this embodiment, the RPMB serves as the sole trusted source of the hardware atomic transaction lock, ensuring that information in the RPMB is not torn during the interruption of the process of copying the firmware package from the target partition to the firmware partition.

[0050] It should be noted here that, Figure 1 The logical partition boundaries within the non-volatile storage medium are marked with solid lines. The physical isolation between the hardware security zone and the data zone reflects the idea of ​​this application to protect the software upgrade logic through hardware security measures. This ensures that even if the data zone experiences logical errors due to power failure or other reasons, the transaction status identifier of the hardware security zone remains true and reliable, providing a solid physical foundation for fault self-healing after system restart.

[0051] The following is combined with Figure 1 Application scenarios, refer to Figures 2-5 This application describes a firmware upgrade method provided according to exemplary embodiments. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.

[0052] It should be noted that the embodiments of this application can be applied to vehicles, and the vehicle can be a server or the host of the vehicle, that is, the firmware upgrade method provided by the exemplary embodiments of this application can be executed on the server or the host of the vehicle.

[0053] The server can be a monolithic server or a distributed server spanning multiple computers or computer data centers. Servers can also be of various categories, such as, but not limited to, web servers, application servers, database servers, or proxy servers.

[0054] Optionally, a server may include hardware, software, or embedded logic components for performing suitable functions supported or implemented by the server, or a combination of two or more such components. For example, a server may be a blade server, a cloud server, or a server group consisting of multiple servers, which may include one or more of the above-mentioned categories of servers, etc.

[0055] It should be noted that the firmware upgrade method provided according to the exemplary embodiments of this application can be executed on the same device or on different devices.

[0056] refer to Figure 2 , Figure 2 This is a schematic flowchart of a firmware upgrade method provided in one embodiment of this application. The device includes a first partition, a second partition, and a firmware partition, wherein the first partition and the second partition are redundant peer system partitions. Figure 2 As shown, the method in the embodiments of this application may include: Step 201: Receive the new firmware package.

[0057] Typically, a firmware package may include metadata, system image data, and a security checksum. The metadata describes the attributes of the firmware package, including the target hardware platform identifier and the firmware package version identifier, which are used by the system to perform compatibility self-negotiation and version alignment before performing an update.

[0058] A security checksum is an integrity certificate generated based on an encryption algorithm, used to verify that the firmware package has not been tampered with or illegally injected during transmission and storage. The encryption algorithm can be HMAC or a digital signature, among others.

[0059] System image data, also known as a system image, is a collection of binary data containing the operating system kernel, file system, and business application logic, stored in a specific partition of the non-volatile storage medium of an embedded device. System image data has boot independence, meaning that if data in other partitions is corrupted, the bootloader can load and run the system image data independently, enabling the device to enter a stable working state and possessing the ability to self-heal by communicating with external platforms via a network.

[0060] Non-volatile storage media include, but are not limited to, embedded MultiMediaCard (eMMC) and Universal Flash Storage (UFS).

[0061] Step 202: When the first partition is the standby partition and the second partition is the running partition, write the firmware package to the first partition, switch to running the first partition, and monitor the performance indicators of the first partition during operation.

[0062] In one possible implementation, upon receiving a new firmware package, a security verification can be performed on the firmware package. If the verification passes, the firmware package is further parsed, and the system image data is extracted and written to the first partition in a block-level write manner.

[0063] Here, to ensure the accuracy of the performance assessment of the first partition during operation, performance indicators may include, but are not limited to, multiple core observation dimensions such as storage media wear indicators, memory resource health indicators, and business operation stability indicators.

[0064] It should be noted that the firmware partition remains unchanged during the monitoring period.

[0065] Step 203: Based on performance indicators, determine the target partition with stable operating status from the first partition and the second partition.

[0066] Optionally, mathematical modeling analysis can be performed based on performance metrics. For example, the first derivative algorithm can be used to determine whether the performance metrics converge in the time dimension, thereby determining whether there are hidden stability risks in the new firmware package.

[0067] In one implementation scenario, if the performance metrics converge, it indicates that the new firmware package does not pose any hidden stability risks, and the first partition can be confirmed to be running stably.

[0068] In another implementation scenario, if performance metrics diverge, it indicates a hidden stability risk in the new firmware package. Here, since the second partition is the running partition before receiving the new firmware package, its stable operation can be assumed, and it can be used as the target partition. Alternatively, it can be determined whether the second partition has a corresponding historical stability record; if so, it can be used as the target partition. If no historical stability record exists, the performance metrics of the second partition during operation are monitored.

[0069] Among these, hidden stability risks include, but are not limited to, chronic memory leaks and abnormal wear and tear on storage media.

[0070] In some embodiments, in addition to the first derivative algorithm, the stability of performance indicators can also be determined by mathematical models such as Kalman filter prediction and linear regression slope analysis.

[0071] Step 204: Copy the firmware package from the target partition to the firmware partition using an atomic transaction.

[0072] Atomic transaction mode refers to encapsulating the operation of copying the firmware package from the target partition to the firmware partition as an indivisible atomic transaction.

[0073] In one possible implementation, block-level copying technology can be used to copy the firmware package from the target partition to the firmware partition.

[0074] In one possible implementation, before copying the firmware package from the target partition to the firmware partition, the version of the firmware package in the target partition can be compared with the version of the original firmware package in the firmware partition. In one implementation scenario, if the version of the firmware package in the target partition is the same as the version of the original firmware package in the firmware partition, then it is unnecessary to perform the step of copying the firmware package from the target partition to the firmware partition.

[0075] In another implementation scenario, if the version of the original firmware package in the firmware partition is lower than the version of the firmware package in the target partition, the firmware package in the target partition can be copied to the firmware partition in an atomic transaction, thereby achieving the version update of the firmware package in the firmware partition.

[0076] In this embodiment, upon receiving a new firmware package, if the first partition is a waiting partition and the second partition is a running partition, the firmware package is written to the first partition, and the running partition is switched. By monitoring the performance indicators of the first partition during operation, a target partition with a stable operating state is determined between the first and second partitions. This ensures that high-quality firmware packages are copied to the firmware partition, avoiding the copying of firmware packages with hidden stability risks, and preventing the spread of systemic failures at the backup layer. After determining the target partition, the firmware package of the target partition is copied to the firmware partition using atomic transactions, realizing the updating of firmware packages in the firmware partition. This enables the firmware partition to dynamically evolve with business versions and security protocols. Through continuous firmware package version updates, even after the device has been used for a long time and a failure rollback occurs, the firmware partition still holds a newer and more valid security certificate and cloud communication protocol. This ensures that even in extreme disaster scenarios where both the first and second partitions are damaged, the device still has effective network access and authentication capabilities. This solves the problem of network authentication failure caused by outdated firmware package versions in the firmware partition after rollback, improving the remote maintainability of the device. In addition, since the firmware package of the target partition is copied to the firmware partition in an atomic transaction manner, the copying operation is encapsulated as an indivisible atomic transaction, ensuring the integrity and consistency of the firmware partition update process. This avoids the risk of system boot failure due to uncertain data status within the firmware partition. Furthermore, even if an interruption occurs during the copying process, the device can still operate normally through the target partition, thus improving the reliability of device operation.

[0077] In addition, when determining the target partition with stable operating status from the first partition and the second partition based on performance indicators, this application embodiment needs to consider how to determine whether the operating status is stable and how to improve the accuracy of determining the target partition, so as to avoid writing firmware packages with hidden stability risks into the firmware partition. Figure 3 This is a flowchart illustrating a firmware upgrade method provided in another embodiment of this application, as shown below. Figure 3 As shown, the method includes: Step 301: Receive the new firmware package.

[0078] Step 302: When the first partition is a standby partition and the second partition is a running partition, write the firmware package to the first partition, switch to running the first partition, and monitor the performance indicators of the first partition during operation; the performance indicators include storage media wear indicators, memory resource health indicators, and business operation stability indicators.

[0079] For the implementation of steps 301-302, please refer to [link / reference]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.

[0080] Step 303: Convergence determination is performed on the storage medium wear index, memory resource health index, and business operation stability index.

[0081] In some embodiments, the convergence determination of storage medium wear indicators, memory resource health indicators, and service operation stability indicators includes: obtaining the number of bad blocks in the storage medium within a preset time period, determining the bad block growth rate based on the number of bad blocks, and determining whether the storage medium wear indicators have converged based on the bad block growth rate; obtaining a moving average based on the sampled data of memory occupancy level, and determining whether the memory resource health indicators have converged based on the moving average; and monitoring the restart frequency of a preset target process, and determining the convergence of service operation stability indicators based on the restart frequency.

[0082] Optionally, the first derivative of the number of bad blocks increasing with respect to time can be calculated to obtain the rate of change of bad block growth. In one implementation scenario, if the rate of change of bad block growth tends to 0, the storage medium wear index is considered to have converged. In another implementation scenario, if the rate of change of bad block growth is significantly greater than zero, the storage medium wear index is considered to have diverged, indicating that the driver or underlying logic of the new firmware package may be causing abnormal wear of the storage medium.

[0083] Memory usage levels characterize the health of memory resources and are used to identify chronic memory leaks. In one possible implementation, memory usage levels of the system kernel and critical processes can be collected. Then, a moving average is applied to the sampled memory usage data, and the slope of the moving average's growth is analyzed. Based on this slope, it can be determined whether the memory resource health indicator has converged. In one implementation scenario, if the growth slope flattens out, it indicates that system resource scheduling has entered a steady state, and the memory resource health indicator can be considered converged.

[0084] The moving average process smooths the sampled data through a preset sliding window to eliminate instantaneous random fluctuations during system operation, thereby constructing a smooth memory usage curve.

[0085] The preset restart frequency of the target process includes, but is not limited to, the unexpected restart frequency of critical middleware and core processes. Optionally, the standard deviation or volatility of the target process restart frequency can be calculated to assess the stability of business operations. In one implementation scenario, if the standard deviation or volatility of the restart frequency remains stable, it can be determined that the business operation stability index has converged. Here, by monitoring business stability indicators, implicit logic failures within the system can be detected, thereby ensuring the reliability of the new firmware package at the business logic level.

[0086] It should be noted that, in addition to storage media wear indicators, memory resource health indicators, and business operation stability, performance indicators may also include other preset custom indicators, which are not limited in this application.

[0087] This section provides quantifiable convergence criteria for multiple performance indicators, including storage media wear metrics, memory resource health metrics, and service operation stability metrics. Specifically, the convergence of the storage media wear metric is determined by the bad block growth rate to identify abnormal wear on the storage media. The convergence of the memory resource health metric is determined by the moving average of memory usage levels to effectively detect chronic memory leaks. The convergence of the service operation stability metric is determined by the restart frequency of the target process to detect hidden logical failures within the system. This provides quantifiable criteria for firmware package replication, effectively identifying hidden stability risks in new firmware versions and thus preventing the replication of firmware packages with hidden stability risks to the firmware partition.

[0088] Step 304: If the results of the determination of the storage medium wear index, memory resource health index and business operation stability index all converge, then the first partition is taken as the target partition; otherwise, the second partition is taken as the target partition.

[0089] The convergence of the results of the storage media wear index, memory resource health index, and business operation stability index indicates that there is no hidden stability risk in the firmware package in the first partition. Therefore, the first partition can be used as the target partition, and the firmware package in the first partition can be copied to the firmware partition.

[0090] In another implementation scenario, if one of the performance indicators, such as storage media wear indicators, memory resource health indicators, and business operation stability indicators, diverges or shows a continuous upward trend, the performance indicator can continue to be observed. Alternatively, the second partition can be used as the target partition, or the firmware upgrade process can be stopped to protect the firmware partition from potential risk contamination, thereby improving the system's survivability in extreme disaster scenarios.

[0091] In this application embodiment, long-term convergence analysis is performed on indicators of multiple core dimensions such as storage medium wear indicators, memory resource health indicators, and business operation stability indicators. This can effectively identify and intercept defective firmware packages that can start normally but have hidden stability risks, ensuring that the firmware package copied to the firmware partition is a verified stable version, and significantly reducing the risk of systemic failures spreading in the backup layer.

[0092] Step 305: Based on the hardware atomic transaction lock, the firmware package in the target partition is copied to the firmware partition in an atomic transaction manner; wherein, the hardware atomic transaction lock is implemented through a transaction status identifier, which is used to determine the integrity of the firmware package copied to the firmware partition.

[0093] Optionally, the transaction status identifier includes a transaction start identifier and a transaction end identifier; based on the hardware atomic transaction lock, the firmware package in the target partition is copied to the firmware partition in an atomic transaction manner, including: writing the transaction start identifier to the hardware secure area to lock the current operation state; starting a block-level copy process to copy the firmware package in the target partition to the firmware partition; after all the firmware packages in the target partition have been copied to the firmware partition, writing the transaction end identifier to the hardware secure area to release the current operation state lock and mark the completion of this atomic transaction.

[0094] In one implementation scenario, the hardware security zone may include the RPMB. Figure 4 This is a schematic diagram of the interaction process for copying a firmware package from a target partition to a firmware partition based on a hardware atomic transaction lock, according to an embodiment of this application. (Refer to...) Figure 4 As shown, the OTA transaction manager can send corresponding instructions to read the current count value of the internal increment counter of the RPMB, and then perform HMAC-SHA256 calculation based on the count value, the transaction start identifier, and the hash value to generate a signature. Finally, it generates an authentication write request based on the transaction start identifier, the hash value, and the signature and sends it to the RPMB in the hardware security zone.

[0095] Upon receiving an authentication write request, the RPMB recalculates the HMAC-SHA256 value based on its internal physical counter and compares the recalculated HMAC-SHA256 value with the signature carried in the authentication write request. If they match, the RPMB writes the transaction start identifier and hash value into the RPMB and acquires an atomic lock to lock the current operation state.

[0096] After receiving a write success message from RPMB, the OTA transaction manager can initiate a block-level copy process to copy the firmware package from the target partition to the firmware partition. Here, the writing of the transaction start identifier indicates that the hardware layer has officially locked the atomic transaction.

[0097] It should be noted that before copying the firmware package from the target partition to the firmware partition, the RPMB can be initialized and authenticated to ensure that the information stored in the RPMB cannot be illegally tampered with. Furthermore, this embodiment only illustrates the case where the hardware security zone includes the RPMB; in this case, the hardware security zone is located inside the storage medium. Besides the RPMB, a Trusted Execution Environment (TEE) secure storage partition, an external storage chip, or a microcontroller unit (MCU) independent of the System-on-Chips (SoC) can all serve as a hardware security zone.

[0098] Optionally, the firmware package in the target partition can be copied to the firmware partition through low-priority background IO scheduling. This ensures that the copying process is executed silently in the background and will not preempt the storage bandwidth of the first or second partition, thus guaranteeing a seamless update experience for the user.

[0099] Here, leveraging the authentication write capabilities of the hardware secure zone, the operation of copying the firmware package from the target partition to the firmware partition is encapsulated as an atomic transaction. By writing a transaction start identifier and a transaction end identifier into the hardware secure zone, the state of the atomic transaction is locked to the underlying hardware, resolving the issue of inconsistent states that can easily occur with software flags during abnormal power outages. Furthermore, the integrity of the firmware package within the firmware partition can be determined based on the transaction start identifier and transaction end identifier, i.e., whether there is physical damage such as tearing writes.

[0100] In one possible implementation, the firmware package contains system image data; after starting the block-level copy process and copying the firmware package from the target partition to the firmware partition, the process further includes: reading the system image data copied to the firmware partition and determining the corresponding full hash value; if the full hash value matches the hash value corresponding to the system image data in the target partition, then it is determined that all the system image data in the target partition has been copied to the firmware partition.

[0101] In one implementation scenario, the OTA transaction manager can utilize the hardware acceleration engine to calculate the full hash value corresponding to the system image data in the firmware partition.

[0102] When the full hash value matches the hash value corresponding to the system image data in the target partition, it indicates that the system image data in the firmware partition is the same as the system image data in the target partition. Therefore, it can be determined that the system image data in the target partition has been fully copied to the firmware partition, and no silent data corruption caused by physical flash memory failure, bus interference, etc. occurred during the copying process. The hash value corresponding to the system image data in the target partition is the hash value carried in the authentication write request received by the RPMB mentioned above.

[0103] Still referencing Figure 4 As shown, after confirming that all system image data in the target partition has been copied to the firmware partition, the OTA transaction manager can initiate another authentication write request to write the transaction end identifier and the version number of the new firmware package to the RPMB. Here, writing the transaction end identifier marks the physical closure of the atomic transaction, at which point the firmware partition switches from an update state to a valid and usable state. Furthermore, since the firmware partition in this application will be upgraded with business updates, storing the version number of the firmware package corresponding to the current firmware partition in the RPMB allows the bootloader to obtain the version of the firmware package within the current firmware partition without mounting a complex file system. Simultaneously, it provides the system with hardware-level version information, effectively preventing the device from being maliciously downgraded to an older firmware package with vulnerabilities.

[0104] In one possible implementation, the RPMB includes a Physical Transaction Control Block (PTCB), in which information such as transaction start identifier, transaction end identifier, hash value, and version number can be stored.

[0105] In another implementation scenario, if the full hash value is inconsistent with the hash value corresponding to the system image data in the target partition, it indicates that the system image data in the target partition has not been fully copied to the firmware partition, and the copying process has been interrupted. At this time, the process can be terminated and no transaction end marker will be written.

[0106] Here, by comparing the full hash value of the firmware partition system image data with the hash value of the target partition system image data, the integrity of the system image data copied to the firmware partition is verified, providing a reliable basis for the write transaction end marker.

[0107] In some embodiments, during the copying of system image data from the target partition to the firmware partition, there is a risk of power failure, which could lead to copying interruption. In one implementation scenario, the transaction status flag within the hardware security zone can be used to determine whether the copying process was interrupted due to unexpected reasons.

[0108] In one possible implementation, after the system is powered on, the transaction status identifier in the hardware security zone is read; based on the result of reading the transaction status identifier, corresponding logical status information is generated in memory; the logical status information is used to identify whether an interruption occurred during the process of copying the firmware package from the target partition to the firmware partition; if the logical status information indicates an interruption, the firmware partition is logically masked and a preset self-healing operation is performed.

[0109] Optionally, the bootloader can be used to read the transaction status identifier in the hardware security zone, and after reading, the corresponding logical status information can be generated in the memory reserved area.

[0110] In one implementation scenario, if the transaction status identifier within the hardware security zone only includes a transaction start identifier and lacks a transaction end identifier, it indicates that an interruption occurred during the previous copying of the firmware package from the target partition to the firmware partition. The system image data in the firmware partition is incomplete, therefore the logical status information generated by the bootloader can be invalid. In this case, logical masking can be implemented on the firmware partition. Here, logical masking means cutting off the logical path to the firmware partition and booting directly from the normal first partition and / or second partition to prevent the booting of corrupted system image data.

[0111] In another implementation scenario, if the transaction status identifier within the hardware security zone includes a transaction start identifier and a transaction end identifier, it indicates that the firmware package in the target partition has been completely copied to the firmware partition without interruption during the copying process. The system image data in the firmware partition is complete, therefore the logical status information generated by the bootloader can be valid. In this case, the bootloader can mark the firmware partition as a valid backup image. In extreme disaster scenarios, such as simultaneous failure of the first and second partitions, the system can safely and reliably switch to the firmware partition for booting.

[0112] Here, based on the hardware handshake and two-phase commit protocol between the hardware security zone and the OTA transaction manager, it is ensured that during the process of copying the firmware package from the target partition to the firmware partition, even if an interruption occurs at any time, the system can maintain the consistency of its logical state, thereby absolutely avoiding corrupted system image data. Utilizing the unidirectional nature of the PRMB's internal incrementing counter and transaction status identifier, the bootloader is forced to perform atomic checks, ensuring that the boot chain can achieve logical decoupling in a timely manner when physical damage occurs. This ensures that the determination of the firmware partition's state does not depend on vulnerable partitions or file systems, thus guaranteeing the device's robustness in complex power environments, such as under vehicle voltage fluctuations, at the lowest level.

[0113] This application embodiment reads the transaction status identifier within the hardware security zone and generates corresponding logical status information in memory. Based on this logical status information, it determines whether an interruption occurred during the copying of the firmware package from the target partition to the firmware partition. In the event of an interruption, the firmware partition is logically shielded, allowing the stable first or second partition to run, thus avoiding the risk of system failure due to corrupted system image data in the firmware partition. Then, a preset self-healing operation is executed to automatically repair the system after the interruption, requiring no manual intervention and improving the remote maintainability and reliability of the device in extreme disaster scenarios.

[0114] In one possible implementation, a preset self-healing operation is performed, including: obtaining the version information of the firmware package within the firmware partition; if the version information matches the version of the firmware package in the currently running partition, or if the currently running partition has a corresponding historical stability determination record, then the currently running partition is used as the target partition, and the step of copying the firmware package from the target partition to the firmware partition in an atomic transaction is re-executed. If the version information does not match the version of the firmware package in the currently running partition, and the currently running partition does not have a corresponding historical stability determination record, then the performance indicators of the currently running partition during operation are monitored, and based on the performance indicators, it is determined whether the operating state of the currently running partition is stable.

[0115] In one implementation scenario, the version information of the firmware package within the firmware partition can be obtained from the metadata.

[0116] The currently running partition can be either the first partition or the second partition. If the version information of the firmware package in the firmware partition matches the version of the firmware package in the currently running partition, it indicates that the firmware package copied before the interruption was from the currently running partition. Since the firmware package in the currently running partition has already started copying, it indicates that the performance indicators of the currently running partition have been monitored and the running status is stable. Therefore, the currently running partition can be directly used as the target partition, and the steps of copying the firmware package from the target partition to the firmware partition in an atomic transaction manner can be re-executed until the copying is complete.

[0117] In another implementation scenario, if the current running partition has a corresponding historical stability record, it also indicates that the performance indicators of the current running partition have been monitored and the running status is stable. Therefore, the current running partition can be directly used as the target partition, and then the step of copying the firmware package in the target partition to the firmware partition in an atomic transaction mode can be re-executed until the copying is completed.

[0118] In another implementation scenario, if the version information of the firmware package in the firmware partition is inconsistent with the version of the firmware package in the currently running partition and there is no corresponding historical stability determination record in the currently running partition, it indicates that the firmware package in the currently running partition is a new version of the firmware package and the performance indicators have not been monitored. Therefore, it is necessary to monitor the performance indicators of the currently running partition, and then further determine the target partition based on the performance indicators, and copy the firmware package in the target partition to the firmware partition in an atomic transaction manner.

[0119] Based on the above technical content, and using the version information of the firmware package in the firmware partition, the version of the firmware package in the currently running partition, and historical stability judgment records, a dual-path self-healing operation of rapid self-healing and re-verification is constructed. This avoids meaningless repeated monitoring, improves efficiency, and ensures that only firmware packages of running partitions with stable running status are written to the firmware partition, thereby improving reliability.

[0120] In this embodiment, compared to methods relying on alternating switching of physical dual-redundant backup partitions to ensure firmware upgrade security, this embodiment uses a hardware atomic transaction lock mechanism to encapsulate the firmware package copying process in the target partition into an indivisible atomic transaction. This ensures the consistency of the copying operation's state, achieves logical identifiability of the firmware partition during the upgrade process, and effectively reduces the space occupied by the firmware partition on non-volatile storage media. This frees up more business storage space for resource-constrained embedded systems or enables a better redundancy strategy on hardware of the same capacity. Furthermore, even if the copying process is interrupted, the transaction status identifier can identify that the firmware package copied to the firmware partition is incomplete, thus avoiding the execution of incomplete firmware packages.

[0121] In some embodiments, a state machine corresponding to the firmware partition can also be set. Figure 5 This is a schematic diagram of the state transition cycle of a state machine provided in an embodiment of this application. Figure 5 This demonstrates the entire logical process of how the system drives the firmware partition system image data to evolve from its initial factory state to a stable business state while ensuring security. Figure 5 The state machine shown overcomes the drawback of static immutability of factory partitions. By monitoring performance indicators, determining convergence, and updating based on atomic transactions, the firmware partition has a lifecycle that evolves synchronously with the business. At the same time, hardware atomic transaction locks ensure physical-level reliability of the evolution process, forming the theoretical basis for the system to maintain network self-healing capability throughout its entire lifecycle.

[0122] Specifically, in combination Figure 5 As shown, the state machine includes a factory baseline state, an observation running state, a termination synchronization state, an atomic evolution state, and an evolution baseline state. In one implementation scenario, the state machine's switching logic can run within the OTA transaction manager.

[0123] Among them, the factory baseline state is the initial state corresponding to the device when it leaves the factory. The firmware partition can store the system image data of v1.0. This state is the original protection baseline of the system.

[0124] The observation running state refers to the state the system enters after completing the service update of the first or second partition. This involves writing the new firmware package to the first or second partition and running it, monitoring the status of performance metrics during the running process. If it is confirmed that the performance metrics converge or the firmware partition version is lower than the target partition version, the system can switch to the atomic evolution state.

[0125] The termination synchronization state can be entered if performance metrics fail to converge or the firmware partition version is the same as the target partition version. The termination synchronization state acts as a security firewall, forcibly abandoning the upgrade, maintaining the current firmware partition status, and ensuring the reliability of the firmware partition.

[0126] The atomic evolution state corresponds to the system image data copying stage. It is protected by hardware atomic transaction locks. Its process consists of three atomic steps: writing a transaction start identifier to the hardware safe zone to lock the current operation state, then starting the block-level copy process to copy the firmware package in the target partition to the firmware partition, and finally writing a transaction end identifier to the hardware safe zone to unlock the state. This ensures the indivisibility of the copying process.

[0127] For the evolutionary baseline state, if the firmware partition is successfully upgraded, for example, from version v1.0 to version v2.0, it can enter the evolutionary baseline state. At this time, the system has established a new backup baseline and enters the next firmware upgrade cycle.

[0128] In this embodiment, after the new firmware package is written to the first partition, the system switches from the second partition to the first partition for operation. Multiple performance metrics of the first partition during operation are monitored, including storage media wear, memory resource health, and service stability. When all performance metrics converge, the first partition is selected as the target partition; otherwise, the second partition is selected. This effectively identifies and intercepts defective firmware packages that, while booting normally, pose hidden stability risks, ensuring that the firmware package copied to the firmware partition is a verified stable version, significantly reducing the risk of systemic failures spreading at the backup layer. After determining the target partition, the firmware package from the target partition is copied to the firmware partition using atomic transactions, enabling the firmware partition to be updated dynamically with service versions and security protocols. Simultaneously, hardware atomic transaction locks in the hardware security zone provide the bootloader with physical criteria for the integrity of the system image data in the firmware partition. Combined with the monitoring of performance metrics during the operation of the first partition, this achieves consistent state and controlled quality evolution of the single-copy backup system image data during the physical overlay process. The aforementioned closed-loop mechanism, which first verifies the stability of the first partition's operational status and then replicates it using atomic transactions, ensures that the device maintains a reliable backup system with the latest version throughout its entire lifecycle. Through continuous firmware updates, even after prolonged use and subsequent rollback due to a fault, the firmware partition retains valid network access and authentication capabilities. This resolves the issue of network authentication failures caused by outdated firmware versions within the firmware partition after rollback, thus improving the device's remote maintainability.

[0129] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0130] Figure 6 This is a schematic diagram of the structure of a firmware upgrade device provided in an embodiment of this application. Figure 6 As shown, the firmware upgrade device provided in this embodiment may include a receiving module 601 and a processing module 602.

[0131] Among them, the receiving module 601 is used to receive the new version of the firmware package; The processing module 602 is used to write the firmware package to the first partition and switch to run the first partition when the first partition is a waiting partition and the second partition is a running partition, and to monitor the performance indicators of the first partition during operation. The processing module 602 is also used to determine the target partition with a stable operating state from the first partition and the second partition based on performance indicators; The processing module 602 is also used to copy the firmware package from the target partition to the firmware partition in an atomic transaction manner.

[0132] In one possible implementation, processing module 602 is specifically used for: Based on hardware atomic transaction locks, the firmware package in the target partition is copied to the firmware partition in an atomic transaction manner; The hardware atomic transaction lock is implemented through a transaction status identifier, which is used to determine the integrity of the firmware package copied to the firmware partition.

[0133] In one possible implementation, the transaction status identifier includes a transaction start identifier and a transaction end identifier; Processing module 602 is specifically used for: Write the transaction start identifier into the hardware security zone to lock the current operation state; Initiate a block-level copy process to copy the firmware package from the target partition to the firmware partition; After all firmware packages in the target partition are copied to the firmware partition, a transaction end flag is written to the hardware security area to unlock the current operation state and mark the completion of this atomic transaction.

[0134] In one possible implementation, the firmware package contains system image data; Processing module 602 is also used for: Read the system image data copied to the firmware partition and determine the corresponding full hash value; If the full hash value matches the hash value corresponding to the system image data in the target partition, then all system image data in the target partition will be copied to the firmware partition.

[0135] In one possible implementation, the processing module 602 is further configured to: After the system is powered on, read the transaction status identifier in the hardware security zone; Based on the result of reading the transaction status identifier, the corresponding logical status information is generated in memory; the logical status information is used to identify whether an interruption occurred during the process of copying the firmware package from the target partition to the firmware partition. If the logical status information identifier is interrupted, the firmware partition will be logically masked and a preset self-healing operation will be performed.

[0136] In one possible implementation, processing module 602 is specifically used for: Retrieve the version information of the firmware package within the firmware partition; If the version information is consistent with the version of the firmware package in the currently running partition, or if the currently running partition has a corresponding historical stability determination record, then the currently running partition will be used as the target partition, and the step of copying the firmware package in the target partition to the firmware partition in an atomic transaction will be re-executed. If the version information is inconsistent with the version of the firmware package in the currently running partition, and there is no corresponding historical stability determination record in the currently running partition, then the performance indicators of the currently running partition during operation are monitored, and the running status of the currently running partition is determined based on the performance indicators.

[0137] In one possible implementation, performance metrics include storage media wear metrics, memory resource health metrics, and business operation stability metrics. Processing module 602 is specifically used for: Convergence determination is performed on storage media wear indicators, memory resource health indicators, and business operation stability indicators; If the results of the assessment of storage medium wear indicators, memory resource health indicators, and business operation stability indicators all converge, then the first partition will be used as the target partition; otherwise, the second partition will be used as the target partition.

[0138] In one possible implementation, processing module 602 is specifically used for: The system obtains the number of bad blocks in the storage medium within a preset time period, determines the rate of change of bad block growth based on the number of bad blocks, and determines whether the storage medium wear index has converged based on the rate of change of bad block growth. Based on the sampling data of memory usage level, a moving average is obtained, and based on the moving average, it is determined whether the memory resource health index has converged. Monitor the restart frequency of the preset target process and determine the convergence of the business operation stability indicators based on the restart frequency.

[0139] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0140] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 7 As shown, the electronic device 700 of this embodiment includes a processor 710 and a memory 720, wherein the memory 720 stores a computer program 721 that can run on the processor 710. When the processor 710 executes the computer program 721, it implements the steps in any of the above-described method embodiments, for example... Figure 2 Steps 201 to 204 are shown. Alternatively, when processor 710 executes computer program 721, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 6 The functions of modules 601 to 602 are shown.

[0141] For example, computer program 721 may be divided into one or more modules / units, one or more of which are stored in memory 720 and executed by processor 710 to complete this application. One or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 721 in electronic device 700.

[0142] Those skilled in the art will understand that Figure 7 This is merely an example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than shown, or combinations of certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0143] The processor 710 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0144] The memory 720 can be an internal storage unit of the electronic device, such as a hard drive or memory, or an external storage device, such as a plug-in hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, or Flash Card. The memory 720 can also include both internal and external storage units. The memory 720 is used to store computer programs and other programs and data required by the electronic device. The memory 720 can also be used to temporarily store data that has been output or will be output.

[0145] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0146] An embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the firmware upgrade method described above.

[0147] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0148] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0150] 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.

[0151] Furthermore, 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0152] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0153] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications 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 included within the protection scope of this application.

Claims

1. A firmware upgrade method, characterized in that, The device includes a first partition, a second partition, and a firmware partition, wherein the first partition and the second partition are redundant peer system partitions; the method includes: Receive the new firmware package; When the first partition is a standby partition and the second partition is a running partition, the firmware package is written to the first partition, and the first partition is switched to run, and the performance indicators of the first partition are monitored during the running process. Based on the performance metrics, a target partition with a stable operating state is determined from the first partition and the second partition; The firmware package in the target partition is copied to the firmware partition using an atomic transaction.

2. The firmware upgrade method according to claim 1, characterized in that, The step of copying the firmware package from the target partition to the firmware partition using an atomic transaction includes: Based on hardware atomic transaction locks, the firmware package in the target partition is copied to the firmware partition in an atomic transaction manner; The hardware atomic transaction lock is implemented through a transaction status identifier, which is used to determine the integrity of the firmware package copied to the firmware partition.

3. The firmware upgrade method according to claim 2, characterized in that, The transaction status identifier includes a transaction start identifier and a transaction end identifier; The method of copying the firmware package from the target partition to the firmware partition using an atomic transaction lock, based on hardware atomic transaction locks, includes: Write the transaction start identifier into the hardware security zone to lock the current operation state; Initiate a block-level copy process to copy the firmware package from the target partition to the firmware partition; After all firmware packages in the target partition are copied to the firmware partition, the transaction end identifier is written to the hardware security zone to unlock the current operation state and mark the completion of this atomic transaction.

4. The firmware upgrade method according to claim 3, characterized in that, The firmware package contains system image data; After initiating the block-level copy process and copying the firmware package from the target partition to the firmware partition, the process further includes: Read the system image data copied to the firmware partition and determine the corresponding full hash value; If the full hash value matches the hash value corresponding to the system image data in the target partition, then it is determined that all the system image data in the target partition is copied to the firmware partition.

5. The firmware upgrade method according to claim 3 or 4, characterized in that, The method further includes: After the system is powered on, the transaction status identifier in the hardware security zone is read; Based on the result of reading the transaction status identifier, corresponding logical status information is generated in memory; the logical status information is used to identify whether an interruption occurred during the process of copying the firmware package from the target partition to the firmware partition; If the logical status information identifier is interrupted, the firmware partition is logically masked and a preset self-healing operation is performed.

6. The firmware upgrade method according to claim 5, characterized in that, The execution of the preset self-healing operation includes: Obtain the version information of the firmware package within the firmware partition; If the version information is consistent with the version of the firmware package in the current running partition, or if the current running partition has a corresponding historical stability determination record, then the current running partition is used as the target partition, and the step of copying the firmware package in the target partition to the firmware partition in an atomic transaction manner is re-executed. If the version information is inconsistent with the version of the firmware package in the current running partition, and the current running partition does not have a corresponding historical stability determination record, then the performance indicators of the current running partition during operation are monitored, and the running status of the current running partition is determined to be stable based on the performance indicators.

7. The firmware upgrade method according to any one of claims 1 to 4, characterized in that, The performance indicators include storage media wear indicators, memory resource health indicators, and service operation stability indicators. The step of determining a target partition with a stable operating state from the first partition and the second partition based on the performance indicators includes: Convergence determination is performed on the storage medium wear index, the memory resource health index, and the service operation stability index; If the results of the determination of the storage medium wear index, the memory resource health index, and the service operation stability index all converge, then the first partition is taken as the target partition; otherwise, the second partition is taken as the target partition.

8. The firmware upgrade method according to claim 7, characterized in that, The convergence determination of the storage medium wear index, the memory resource health index, and the service operation stability index includes: The number of bad blocks in the storage medium within a preset time period is obtained, and the rate of change of bad block growth is determined based on the number of bad blocks. The storage medium wear index is then determined to converge based on the rate of change of bad block growth. Based on the sampled data of memory usage level, a moving average is obtained, and based on the moving average, it is determined whether the memory resource health index has converged. Monitor the restart frequency of the preset target process, and determine the convergence of the service operation stability index based on the restart frequency.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the firmware upgrade method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the firmware upgrade method as described in any one of claims 1 to 8.

Images