Method, device, equipment and medium for verifying firmware version change

Abstract

The present application relates to the field of firmware verification technology, and in particular to a method, apparatus, device and medium for verifying firmware version changes, the method comprising: introducing a predefined matrix algorithm into an acquired Linux verification system; performing version changes on the firmware to be deployed of the Linux verification system using the predefined matrix algorithm to obtain multiple version change paths, each version change path including a new version of firmware and an old version of firmware; traversing multiple version change paths to perform multiple rounds of verification to obtain a target verification result, each round of verification comprising: verifying whether the version change is successful according to a preset traversal rule to obtain a first verification result; verifying the new version of firmware and the old version of firmware based on the first verification result and the preset verification rule to obtain a second verification result; and deploying the firmware to be deployed based on the target verification result, aiming to verify all version change paths and ensure that the device can work normally between all firmware versions.

Description

Technical Field

[0001] The present application relates to the field of firmware verification technology, and in particular to a method, apparatus, device, and medium for verifying firmware version changes. Background Art

[0002] In modern electronic devices, eMMC (embedded MultiMediaCard) and UFS (Universal Flash Storage) are mainstream storage solutions, widely used in smartphones, tablets, embedded systems, and other devices. These storage devices often require firmware upgrades during their lifecycles to fix vulnerabilities, improve performance, or add new features. However, the firmware upgrade process presents complex version management and verification issues, which not only impact device stability and reliability but also increase the complexity of firmware management.

[0003] Specifically, when the firmware upgrade does not involve adjusting the data distribution of the NandFlash data block, a direct inherited upgrade can be implemented. However, if the firmware upgrade involves adjusting the data distribution, the inherited upgrade cannot be performed. Forced upgrades can cause abnormalities in the eMMC or UFS, and even cause abnormalities in the Android system. As the number of firmware versions continues to increase during the product lifecycle, the difficulty of version management increases significantly, and the corresponding verification work also faces greater challenges.

[0004] In addition, when verifying the upgrade and downgrade paths between multiple firmware versions, existing verification methods can only verify the upgrade or downgrade paths of adjacent versions, ignoring the upgrade and downgrade paths across multiple versions, and cannot ensure that the device can work properly between all possible firmware versions. Summary of the Invention

[0005] The main purpose of the embodiments of the present application is to propose a method, apparatus, device and medium for verifying firmware version changes, aiming to manage different types of firmware versions and fully verify the upgrade and downgrade paths between all versions to ensure that the device can work normally between all firmware versions.

[0006] To achieve the above objectives, a first aspect of an embodiment of the present application provides a method for verifying a firmware version change, the method comprising:

[0007] Obtaining a Linux verification system, wherein the Linux verification system introduces a predefined matrix algorithm;

[0008] Based on the Linux verification system, obtain the firmware to be deployed;

[0009] Using the predefined matrix algorithm to perform version upgrade or version downgrade on the firmware to be deployed, to obtain multiple version change paths, wherein each version change path includes a new version firmware and an old version firmware corresponding to the new version firmware;

[0010] Traversing the plurality of version change paths and performing multiple rounds of verification to obtain a target verification result, wherein each round of verification includes: using the predefined matrix algorithm and, according to a preset traversal rule, verifying whether the version upgrade or version downgrade is successful, to obtain a first verification result; and verifying the new version firmware and the old version firmware based on the first verification result and the preset verification rule, to obtain a second verification result;

[0011] The firmware to be deployed is deployed based on the target verification result.

[0012] Through the method provided in the first aspect, different firmware versions can be managed and the paths of all firmware versions can be traversed for verification. By fully verifying the upgrade and downgrade paths between all versions, it can be ensured that the device will not experience functional failure or system crash during the conversion between different firmware versions, which helps to timely discover and fix potential compatibility issues, thereby reducing the risk of system instability caused by firmware upgrades or downgrades and improving the reliability of the device.

[0013] In a possible implementation, the predefined matrix algorithm defines a bridging strategy and a degradation strategy;

[0014] The using the predefined matrix algorithm to perform version upgrade or version downgrade on the firmware to be deployed includes:

[0015] When upgrading the firmware to be deployed using the predefined matrix algorithm, if the old version of the firmware cannot be directly upgraded to the new version of the firmware, using the bridging strategy to change the old version of the firmware to a version of the firmware used for bridging, and then changing the version of the firmware used for bridging to the new version of the firmware;

[0016] When downgrading the firmware to be deployed using the predefined matrix algorithm, the downgrade strategy is used to change the old version firmware to the downgraded version firmware, and then the downgraded version firmware is changed to the new version firmware.

[0017] In a possible implementation, based on the Linux verification system, before obtaining the firmware file to be deployed, the following steps are further included:

[0018] Generate the firmware to be deployed on the host;

[0019] A communication connection is established between the host and the Linux verification system through the SDB protocol, so that after the host sends the firmware to be deployed to the Linux verification system, the Linux verification system stores the firmware to be deployed.

[0020] In one possible implementation, whether the version upgrade or downgrade is successful is verified according to a preset traversal rule, and obtaining a first verification result includes:

[0021] When the expected version change is successful, determining a version change type based on the old version firmware and the new version firmware;

[0022] When the version change type is the first type, verifying whether the version upgrade or downgrade is successful according to a preset first traversal rule to obtain the first verification result;

[0023] When the version change type is the second type, verifying whether the version upgrade or downgrade is successful according to the preset second traversal rule to obtain the first verification result;

[0024] When the expected version change fails, whether the version upgrade or downgrade is successful is verified according to the preset third traversal rule to obtain the first verification result.

[0025] In one possible implementation, when the expected version change is successful, determining the version change type based on the old version firmware and the new version firmware includes:

[0026] Obtaining a difference between the version numbers of the old version firmware and the new version firmware;

[0027] When the difference is 1, determining whether the old version firmware can be directly changed to the new version firmware; if so, determining that the version change type is the first type; if not, determining that the version change type is the second type;

[0028] When the difference is not 1, the version change type is determined to be the second type.

[0029] In one possible implementation, verifying the new version of the firmware based on the first verification result and a preset verification rule to obtain a second verification result includes:

[0030] When the expected version change is successful, if the first verification result is that the change is successful, using the predefined matrix algorithm, based on the preset verification rules, to verify the new version of the firmware to obtain the second verification result;

[0031] When the expected version change fails, if the first verification result is change failure, the new version firmware is verified based on the preset verification rules using the predefined matrix algorithm to obtain the second verification result.

[0032] In one possible implementation, the verifying the new version firmware and the old version firmware based on the first verification result and a preset verification rule includes at least one of the following verification operations:

[0033] Verify whether the data of the new version firmware is consistent with the data of the old version firmware;

[0034] Verify whether each byte of the storage area of ​​the old version firmware to which no data was written before the version change is 0;

[0035] Verify whether the new version of the firmware functions normally;

[0036] Verify whether the reserved bit parameters of the new version firmware are consistent with the reserved bit parameters of the old version firmware.

[0037] To achieve the above-mentioned purpose, a second aspect of an embodiment of the present application provides a device for verifying a firmware version change, the device comprising:

[0038] Verification system acquisition module: used to obtain a Linux verification system, wherein the Linux verification system introduces a predefined matrix algorithm;

[0039] Firmware acquisition module: used to acquire the firmware to be deployed based on the Linux verification system;

[0040] A version change module is configured to upgrade or downgrade the firmware to be deployed using the predefined matrix algorithm to obtain multiple version change paths, wherein each version change path includes a new version firmware and an old version firmware corresponding to the new version firmware;

[0041] Verification module: configured to traverse the plurality of version change paths and perform multiple rounds of verification to obtain a target verification result, wherein each round of verification includes: using the predefined matrix algorithm and, according to preset traversal rules, verifying whether the version upgrade or version downgrade is successful to obtain a first verification result; and verifying the new version firmware and the old version firmware based on the first verification result and preset verification rules to obtain a second verification result;

[0042] Deployment module: used to deploy the firmware to be deployed based on the target verification result.

[0043] Through the device provided by the second aspect, different firmware versions can be managed and the paths of all firmware versions can be traversed for verification. By fully verifying the upgrade and downgrade paths between all versions, it can be ensured that the device will not experience functional failure or system crash during the conversion between different firmware versions, which helps to timely discover and fix potential compatibility issues, thereby reducing the risk of system instability caused by firmware upgrades or downgrades and improving the reliability of the device.

[0044] In a third aspect, an electronic device is provided, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method for verifying the firmware version change as described in any possible implementation method in the first aspect is implemented.

[0045] In a fourth aspect, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the method for verifying the firmware version change as described in any possible implementation manner in the first aspect is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate one or more embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the description of one or more embodiments or the prior art. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0047] Figure 1 This is a flowchart of a method for verifying firmware version changes provided by an embodiment of the present application;

[0048] Figure 2 This embodiment of the present application provides Figure 1 Flowchart of the method included before step S102;

[0049] Figure 3 This is a structural block diagram of a device for verifying firmware version changes provided in an embodiment of the present application;

[0050] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0051] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below in conjunction with the drawings in one or more embodiments of this specification. Obviously, the one or more embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on one or more embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this document.

[0052] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0053] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0054] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other. The embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0055] Existing verification methods can only verify the upgrade or downgrade paths between multiple firmware versions, ignoring the upgrade and downgrade paths across multiple versions, and cannot ensure that the device can work properly between all possible firmware versions.

[0056] Based on this, the embodiments of the present application provide a method, apparatus, device and medium for verifying firmware version changes, which can manage different types of firmware versions and fully verify the upgrade and downgrade paths between all versions to ensure that the device can work normally between all firmware versions.

[0057] The embodiments of the present application are further described below with reference to the accompanying drawings.

[0058] Figure 1 This is an optional flowchart of the method for verifying firmware version changes provided in an embodiment of the present application. Figure 1 The method may include but is not limited to steps S101 to S105.

[0059] First, as Figure 1As shown, a method for verifying a firmware version change is provided, the method comprising:

[0060] S101: Acquire a Linux verification system, wherein the Linux verification system introduces a predefined matrix algorithm.

[0061] S102: Based on the Linux verification system, obtain the firmware to be deployed.

[0062] It's important to note that the Linux system utilizes a layered architecture, consisting of a kernel layer. The kernel is the core of the Linux system and is responsible for managing the system's hardware resources, process scheduling, memory management, file system, and network communication. The Linux kernel is highly customizable, allowing users to optimize it based on the hardware platform and application scenario. It also includes a user space layer, which contains various applications and services. These programs run within the kernel's environment. User space software can be categorized as system tools, programming languages, and graphical user interface applications. User space software interacts with the kernel through system calls to complete various tasks. The Linux system also includes hardware interfaces, with the Linux system communicating with hardware devices through device drivers. Device drivers are part of the kernel and are responsible for managing the input / output operations of hardware devices. Linux supports a wide range of hardware platforms, from x86-based personal computers to ARM-based embedded devices. Therefore, using the Linux system as a verification system allows for system customization based on specific needs. Incorporating predefined matrix algorithms into the Linux verification system increases the system's flexibility. Furthermore, because the Linux verification system provides a highly flexible directory structure, users can store multiple firmware to be deployed in different directories, facilitating firmware file management.

[0063] S103: Using a predefined matrix algorithm to perform version upgrade or version downgrade on the firmware to be deployed, to obtain multiple version change paths, wherein each version change path includes a new version firmware and an old version firmware corresponding to the new version firmware.

[0064] It should be noted that after obtaining the firmware to be deployed, a predefined matrix algorithm is used to upgrade or downgrade the firmware to be deployed, resulting in multiple version change paths, where each version change path includes a new version of firmware and an old version of firmware corresponding to the new version of firmware. In some embodiments, the predefined matrix algorithm includes the name of the firmware to be deployed, the file path of the firmware to be deployed, the firmware versions that can be upgraded to, and special firmware versions. Among them, the noun of the firmware to be deployed includes the name of the product, the major version number and the minor version number; the file path of the firmware to be deployed refers to the location where the firmware to be deployed is stored, and different products have different paths; the firmware version that can be upgraded to refers to which versions can be upgraded to this version; in addition, due to the complexity of the firmware upgrade strategy, as well as the dependencies and compatibility between different versions, the firmware is only allowed to be upgraded from a lower version to a higher version, and is not allowed to be downgraded from a higher version to a lower version, and there are situations where it cannot be directly upgraded from one version to another. Based on this, the predefined matrix algorithm provided in the embodiment of the present application sets a special firmware version as a transition version to achieve firmware downgrade from a higher version to a lower version, or to enable firmware versions that cannot be directly upgraded to the target firmware version to be smoothly upgraded to the target firmware version by using the special firmware version as a bridge version. Through the predefined matrix algorithm, the firmware versions of different types of firmware to be deployed can be managed, and the paths of all firmware versions can be traversed for verification, covering all upgradeable and non-upgradeable versions, so as to achieve different versions of different products, or upgrade verification of different versions of the same product.

[0065] S104. Traverse multiple version change paths and perform multiple rounds of verification to obtain a target verification result, wherein each round of verification includes: using a predefined matrix algorithm and, according to preset traversal rules, verifying whether the version upgrade or version downgrade is successful to obtain a first verification result; and verifying the new version firmware and the old version firmware based on the first verification result and the preset verification rules to obtain a second verification result.

[0066] It should be noted that when verifying the version change path, multiple rounds of verification are required to traverse multiple version change paths to obtain the target verification result. Each round of verification includes: using a predefined matrix algorithm and preset traversal rules to verify whether the version upgrade or version downgrade is successful, obtaining a first verification result; and verifying the new and old versions of the firmware based on the first verification result and the preset verification rules to obtain a second verification result. Traversing multiple version change paths and performing multiple rounds of verification fully verifies the upgrade and downgrade paths between all versions, ensuring that the device does not experience functional failures or system crashes during the transition between different firmware versions. This helps to promptly identify and fix potential compatibility issues, thereby reducing the risk of system instability caused by firmware upgrades or downgrades and improving device reliability. In addition, each round of verification first verifies whether the version upgrade or version downgrade is successful based on the preset traversal rules to obtain a first verification result. Then, based on the first verification result and the preset verification rules, the new and old versions of the firmware are verified to obtain a second verification result. Whether the version upgrade or downgrade is successful is verified through the first round, and then whether to proceed to the next round of verification is determined based on the first verification result. When the first verification result fails, the process can be terminated without starting the second round of verification to locate the basic fault, avoiding ineffective consumption of resources. When the first verification result passes, it can also lay the foundation for subsequent verification. When there are problems in the second round of verification, it can effectively avoid judgment deviations caused by errors in whether the version upgrade is successful, which helps maintenance personnel quickly divide the problem boundaries, shorten the troubleshooting time, and improve problem-solving efficiency.

[0067] S105: Deploy the firmware to be deployed based on the target verification result.

[0068] It should be noted that after obtaining the target verification results, it is necessary to decide whether to deploy the firmware to be deployed based on the target verification results. For example, when the target verification results pass, the firmware to be deployed is determined to be in a "deployable state" and enters the formal deployment process; when the target verification results partially pass, the firmware to be deployed is marked as "conditional deployment" and the deployment scope must be clearly limited before deployment; when the target verification results fail, the firmware to be deployed is determined to be in a "non-deployable state" and must be returned to the R&D stage for optimization. After repair, re-verification is required and the deployment process is prohibited. Deploying the firmware to be deployed based on the target verification results can reduce the risk of system instability caused by firmware upgrades or downgrades and improve device reliability.

[0069] Through the method provided in the first aspect, different firmware versions can be managed and the paths of all firmware versions can be traversed for verification. By fully verifying the upgrade and downgrade paths between all versions, it can be ensured that the device will not experience functional failure or system crash during the conversion between different firmware versions, which helps to timely discover and fix potential compatibility issues, thereby reducing the risk of system instability caused by firmware upgrades or downgrades and improving the reliability of the device.

[0070] In one possible implementation, the predefined matrix algorithm defines a bridging strategy and a downgrade strategy; the use of the predefined matrix algorithm to perform version upgrade or version downgrade on the firmware to be deployed includes: when using the predefined matrix algorithm to perform version upgrade on the firmware to be deployed, when the old version firmware cannot be directly upgraded to the new version firmware, using the bridging strategy to change the old version firmware to a version firmware for bridging, and then changing the version firmware for bridging to the new version firmware; when using the predefined matrix algorithm to downgrade the firmware to be deployed, using the downgrade strategy to change the old version firmware to a version firmware for downgrading, and then changing the version firmware for downgrading to the new version firmware.

[0071] It should be noted that in conventional FFU (Field Firmware Update) mechanisms, there are situations where direct upgrades from one version to another are not possible. To address this, embodiments of the present application define a bridging strategy within a predefined matrix algorithm. When upgrading the deployed firmware using the predefined matrix algorithm, if the old version cannot be directly upgraded to the new version, the bridging strategy is used to change the old version to a bridging version, and then to the new version. Defining a bridging strategy within the predefined matrix algorithm introduces a special firmware version, namely, the bridging version, into the predefined matrix algorithm as a transition mechanism to address the limitations of direct cross-version upgrades. Bridging during firmware upgrades introduces an intermediate version as a "bridge," connecting two versions that would otherwise be inaccessible, enabling the upgrade process to complete. Furthermore, in conventional FFU mechanisms, firmware generally only supports upgrades from lower versions to higher versions, and does not allow direct downgrades from higher versions to lower versions. This is due to the limitations of storage media erasure and verification mechanisms, as well as version dependency constraints, associated with firmware upgrades. Based on this, the embodiment of the present application defines a downgrade strategy in a predefined matrix algorithm. When the predefined matrix algorithm is used to downgrade the version of the deployed firmware, the downgrade strategy is used to change the old version firmware to the version firmware for downgrade, and then the version firmware for downgrade is changed to the new version firmware, thereby avoiding the technical limitations of direct downgrade.

[0072] In some embodiments, when the firmware version of a product cannot be upgraded directly from version 10.7 to version 10.8, an upgrade path must be constructed through the version firmware used for bridging. The version firmware used for bridging of this product is version 10.230. The specific upgrade process is: first upgrade version 10.7 to version 10.230, and then upgrade from version 10.230 to version 10.8. Version 10.230 has the compatibility adaptation capability with the previous and next versions, and can resolve the technical conflicts between version 10.7 and version 10.8. Through this mechanism, the originally interrupted upgrade link is reconnected, ensuring the feasibility and stability of cross-version upgrades, and can effectively deal with complex version dependencies. In addition, after the product has been upgraded from version 10.1 to version 10.3, if it needs to be upgraded to version 10.5 based on version 10.1, since downgrading directly from version 10.3 to version 10.1 does not comply with normal upgrade rules, you can use version 10.255, the downgrade firmware, to complete the operation: first change version 10.3 to version 10.255, and then change from version 10.255 to version 10.1. After completing this process, the product can continue to upgrade from version 10.1 to version 10.5 along the normal path, forming a closed loop of cyclic upgrades, which not only avoids the technical limitations of direct downgrades but also meets the needs of cross-version upgrades.

[0073] In one possible implementation, Figure 2 As shown, based on the Linux verification system, before obtaining the firmware file to be deployed, the process further includes steps S301 to S302:

[0074] S301: Generate firmware to be deployed on a host.

[0075] S302 : Establish a communication connection between the host and the Linux verification system through the SDB protocol, so that after the host sends the firmware to be deployed to the Linux verification system, the Linux verification system stores the firmware to be deployed.

[0076] It should be noted that in a uboot-based operating environment, the transmission of firmware from the host to the SOC (System on Chip) can only be achieved through the Xmode method. Since uboot itself does not have a file system, the storage of firmware must rely on a mandatory physical address on a medium such as a TF card. This mechanism has significant limitations in practical applications: on the one hand, the Xmode transmission method is inefficient, making the firmware transfer process time-consuming; on the other hand, due to the fixed allocation of physical addresses and the storage characteristics of uboot itself, the number of firmware files it can accommodate is extremely limited. Based on this, the embodiment of the present application proposes that after the host generates the firmware to be deployed, a communication connection between the host and the Linux verification system is established through the SDB (Serial Debug Bridge Protocol) protocol, so that after the host sends the firmware to be deployed to the Linux verification system, the Linux verification system stores the firmware to be deployed. Among them, the Linux verification system has its own file system, which can store the firmware to be deployed generated by the host in different directories, thereby supporting the storage needs of more than 100 files. At the same time, a communication connection between the host and the Linux verification system is established through the SDB protocol, realizing the import of files from the host side to the SOC side Linux verification system. Compared with the existing technology, it improves the transmission efficiency and effectively breaks through the previous limitations on transmission speed and storage capacity.

[0077] In one possible implementation, according to a preset traversal rule, whether the version upgrade or version downgrade is successful is verified to obtain a first verification result, including: when the expected version change is successful, determining the version change type based on the old version firmware and the new version firmware; when the version change type is the first type, according to the preset first traversal rule, whether the version upgrade or version downgrade is successful is verified to obtain the first verification result; when the version change type is the second type, according to the preset second traversal rule, whether the version upgrade or version downgrade is successful is verified to obtain the first verification result; when the expected version change fails, according to the preset third traversal rule, whether the version upgrade or version downgrade is successful is verified to obtain the first verification result.

[0078] In some embodiments, the preset traversal rules include rules for expected version change success and expected version change failure. The expected version change success rule includes a first traversal rule and a second traversal rule, and the expected version change failure rule includes a third traversal rule. When the expected version change is successful, the version change type is determined based on the old version firmware and the new version firmware. When the version change type is the first type, the version upgrade or downgrade is successfully verified according to the preset first traversal rule to obtain a first verification result, wherein the preset first traversal rule is a sequential traversal. For example, when the firmware of a product provided in an embodiment of the present application confirms that the version change type of version 10.1 to version 10.2 and version 10.2 to version 10.3 is the first type, such version change path is sequentially traversed based on the preset first traversal rule. First, it is verified whether the change from version 10.1 to version 10.2 is successful. If the version change is successful, the next round of verification is performed. Then, it is verified whether the change from version 10.2 to version 10.3 is successful. If the version change is successful, the next round of verification is performed, and so on, until all traversals are completed. There is a version change path with a version change type of the first type; when the version change type is the second type, according to the preset second traversal rule, whether the version upgrade or version downgrade is successful is verified to obtain a first verification result, wherein the preset second traversal rule is a cross-version traversal. For example, when the firmware of a product confirms that the version change type of version 10.1 is changed to version 10.7 and version 10.5 is changed to version 10.7 is the second type, such version change path is traversed across versions based on the preset second traversal rule. First, whether the change from version 10.1 to version 10.7 is successful is verified. When the version change is successful, the next round of verification is performed. Then, whether the change from version 10.5 to version 10.7 is successful is verified. When the version change is successful, the next round of verification is performed. And so on, until all version change paths with the second type of version change are traversed. When the expected version change fails, the success of the version upgrade or downgrade is verified according to the preset third traversal rule to obtain a first verification result, wherein the preset third traversal rule is the traversal of the failed expected version change. For example, when the firmware of a product fails to confirm the expected version change from version 10.1 to version 10.8, the success of the change from version 10.1 to version 10.8 is verified according to the preset third traversal rule. When the version change fails, the next round of verification is performed. Differentiated verification rules are set for different situations to avoid operational confusion caused by complex version iteration logic. All firmware version paths can be traversed for verification, covering all upgradeable and non-upgradeable versions, so as to realize different versions of different products, or upgrade verification of different versions of the same product.

[0079] In one possible implementation, when the expected version change is successful, determining the version change type based on the old version firmware and the new version firmware includes: obtaining the difference between the version numbers of the old version firmware and the new version firmware; when the difference is 1, determining whether the old version firmware can be directly changed to the new version firmware, and if so, determining that the version change type is the first type; if not, determining that the version change type is the second type; when the difference is not 1, determining that the version change type is the second type.

[0080] It should be noted that in some embodiments, it is necessary to determine the version change type based on the old version firmware and the new version firmware to select the corresponding traversal rule. Specifically, it is necessary to obtain the difference between the version numbers of the old version firmware and the new version firmware. When the difference is 1, it is determined whether the old version firmware can be directly changed to the new version firmware. If so, the version change type is determined to be the first type. For example, the firmware of a product is changed from version 10.1 to version 10.2, the difference between the version numbers of version 10.1 and version 10.2 is 1, and version 10.1 can be directly upgraded to version 10.2, then the version change type is determined to be the first type; if not, then the version change type is determined to be the second type; when the difference is not 1, the version change type is determined to be the second type. For example, the firmware of a product is changed from version 10.1 to version 10.3, version 10.1 can be directly upgraded to version 10.3, but the difference between version 10.1 and version 10.3 is not 1, which is a cross-version upgrade, so the version change type is determined to be the second type. Differentiated verification rules are set for different situations to avoid operational confusion caused by complex version iteration logic. All firmware version paths can be traversed for verification, covering all upgradeable and non-upgradeable versions to achieve different versions of different products, or upgrade verification of different versions of the same product.

[0081] In one possible implementation, the verifying the new version of the firmware based on the first verification result and the preset verification rules to obtain the second verification result includes: when the expected version change is successful, if the first verification result is that the change is successful, using the predefined matrix algorithm, based on the preset verification rules to verify the new version of the firmware, to obtain the second verification result; when the expected version change fails, if the first verification result is that the change fails, using the predefined matrix algorithm, based on the preset verification rules to verify the new version of the firmware, to obtain the second verification result.

[0082] It should be noted that in some embodiments, when the expected version change is successful, if the first verification result is a successful change, that is, the version change is successful, a predefined matrix algorithm is used to verify the new version firmware based on preset verification rules to obtain a second verification result; when the expected version change fails, that is, the version change fails, if the first verification result is a failed change, a predefined matrix algorithm is used to verify the new version firmware based on preset verification rules to obtain a second verification result. By setting differentiated verification rules for different situations, all firmware version paths can be traversed for verification, covering all upgradeable and non-upgradeable versions, so as to achieve different versions of different products, or upgrade verification of different versions of the same product.

[0083] In one possible implementation, the verification of the new version firmware and the old version firmware based on the first verification result and the preset verification rules includes at least one of the following verification operations: verifying whether the data of the new version firmware is consistent with the data of the old version firmware; verifying whether each byte of the storage area of ​​the old version firmware where no data is written before the version change is 0; verifying whether the function of the new version firmware is normal; and verifying whether the reserved bit parameters of the new version firmware are consistent with the reserved bit parameters of the old version firmware.

[0084] It should be noted that the verification of the new version firmware and the old version firmware based on the first verification result and the preset verification rules includes at least one of the following verification operations: verifying whether the data of the new version firmware is consistent with the data of the old version firmware, that is, the data written before the version change cannot be wrong; verifying whether each byte of the storage area of ​​the old version firmware where data was not written before the version change is 0, that is, verifying that the data content involved in the storage area where data was not written before the version change must all be composed of hexadecimal values ​​0x00; verifying whether the function of the new version firmware is normal; verifying whether the reserved bit parameters of the new version firmware are consistent with the reserved bit parameters of the old version firmware, that is, descriptors such as EXT_CSD and other reserved bit parameters cannot be modified. In addition, it is understandable that the verification operation of verifying the new version firmware and the old version firmware based on the first verification result and the preset verification rules is not limited to the above-mentioned operation content and is not limited here. By verifying the new version firmware and the old version firmware, the correctness of the data and functions can be verified, vulnerabilities in the firmware can be discovered in advance, and problems such as crashes and freezes of the device after the upgrade can be avoided, thereby reducing after-sales maintenance costs.

[0085] To achieve the above purpose, the second aspect of the embodiment of the present application proposes a verification device for firmware version change, such as Figure 3 As shown, the device includes:

[0086] Verification system acquisition module: used to obtain a Linux verification system, wherein the Linux verification system introduces a predefined matrix algorithm.

[0087] Firmware acquisition module: used to acquire the firmware to be deployed based on the Linux verification system.

[0088] It's important to note that the Linux system utilizes a layered architecture, consisting of a kernel layer. The kernel is the core of the Linux system and is responsible for managing the system's hardware resources, process scheduling, memory management, file system, and network communication. The Linux kernel is highly customizable, allowing users to optimize it based on the hardware platform and application scenario. It also includes a user space layer, which contains various applications and services. These programs run within the kernel's environment. User space software can be categorized as system tools, programming languages, and graphical user interface applications. User space software interacts with the kernel through system calls to complete various tasks. The Linux system also includes hardware interfaces, with the Linux system communicating with hardware devices through device drivers. Device drivers are part of the kernel and are responsible for managing the input / output operations of hardware devices. Linux supports a wide range of hardware platforms, from x86-based personal computers to ARM-based embedded devices. Therefore, using the Linux system as a verification system allows for system customization based on specific needs. Incorporating predefined matrix algorithms into the Linux verification system increases the system's flexibility. Furthermore, because the Linux verification system provides a highly flexible directory structure, users can store multiple firmware to be deployed in different directories, facilitating firmware file management.

[0089] Version change module: used to use the predefined matrix algorithm to upgrade or downgrade the firmware to be deployed to obtain multiple version change paths, wherein each version change path includes a new version firmware and an old version firmware corresponding to the new version firmware.

[0090] It should be noted that after obtaining the firmware to be deployed, a predefined matrix algorithm is used to upgrade or downgrade the firmware to be deployed, resulting in multiple version change paths, where each version change path includes a new version of firmware and an old version of firmware corresponding to the new version of firmware. In some embodiments, the predefined matrix algorithm includes the name of the firmware to be deployed, the file path of the firmware to be deployed, the firmware versions that can be upgraded to, and special firmware versions. Among them, the noun of the firmware to be deployed includes the name of the product, the major version number and the minor version number; the file path of the firmware to be deployed refers to the location where the firmware to be deployed is stored, and different products have different paths; the firmware version that can be upgraded to refers to which versions can be upgraded to this version; in addition, due to the complexity of the firmware upgrade strategy, as well as the dependencies and compatibility between different versions, the firmware is only allowed to be upgraded from a lower version to a higher version, and is not allowed to be downgraded from a higher version to a lower version, and there are situations where it cannot be directly upgraded from one version to another. Based on this, the predefined matrix algorithm provided in the embodiment of the present application sets a special firmware version as a transition version to achieve firmware downgrade from a higher version to a lower version, or to enable firmware versions that cannot be directly upgraded to the target firmware version to be smoothly upgraded to the target firmware version by using the special firmware version as a bridge version. Through the predefined matrix algorithm, the firmware versions of different types of firmware to be deployed can be managed, and the paths of all firmware versions can be traversed for verification, covering all upgradeable and non-upgradeable versions, so as to achieve different versions of different products, or upgrade verification of different versions of the same product.

[0091] Verification module: used to traverse multiple version change paths and perform multiple rounds of verification to obtain a target verification result, wherein each round of verification includes: using the predefined matrix algorithm, according to the preset traversal rules, verifying whether the version upgrade or version downgrade is successful to obtain a first verification result; based on the first verification result and the preset verification rules, verifying the new version firmware and the old version firmware to obtain a second verification result.

[0092] It should be noted that when verifying the version change path, multiple rounds of verification are required to traverse multiple version change paths to obtain the target verification result. Each round of verification includes: using a predefined matrix algorithm and preset traversal rules to verify whether the version upgrade or version downgrade is successful, obtaining a first verification result; and verifying the new and old versions of the firmware based on the first verification result and the preset verification rules to obtain a second verification result. Traversing multiple version change paths and performing multiple rounds of verification fully verifies the upgrade and downgrade paths between all versions, ensuring that the device does not experience functional failures or system crashes during the transition between different firmware versions. This helps to promptly identify and fix potential compatibility issues, thereby reducing the risk of system instability caused by firmware upgrades or downgrades and improving device reliability. In addition, each round of verification first verifies whether the version upgrade or version downgrade is successful based on the preset traversal rules to obtain a first verification result. Then, based on the first verification result and the preset verification rules, the new and old versions of the firmware are verified to obtain a second verification result. Whether the version upgrade or downgrade is successful is verified through the first round, and then whether to proceed to the next round of verification is determined based on the first verification result. When the first verification result fails, the process can be terminated without starting the second round of verification to locate the basic fault, avoiding ineffective consumption of resources. When the first verification result passes, it can also lay the foundation for subsequent verification. When there are problems in the second round of verification, it can effectively avoid judgment deviations caused by errors in whether the version upgrade is successful, which helps maintenance personnel quickly divide the problem boundaries, shorten the troubleshooting time, and improve problem-solving efficiency.

[0093] Deployment module: used to deploy the firmware to be deployed based on the target verification result.

[0094] It should be noted that after obtaining the target verification results, it is necessary to decide whether to deploy the firmware to be deployed based on the target verification results. For example, when the target verification results pass, the firmware to be deployed is determined to be in a "deployable state" and enters the formal deployment process; when the target verification results partially pass, the firmware to be deployed is marked as "conditional deployment" and the deployment scope must be clearly limited before deployment; when the target verification results fail, the firmware to be deployed is determined to be in a "non-deployable state" and must be returned to the R&D stage for optimization. After repair, re-verification is required and the deployment process is prohibited. Deploying the firmware to be deployed based on the target verification results can reduce the risk of system instability caused by firmware upgrades or downgrades and improve device reliability.

[0095] Through the device provided by the second aspect, different firmware versions can be managed and the paths of all firmware versions can be traversed for verification. By fully verifying the upgrade and downgrade paths between all versions, it can be ensured that the device will not experience functional failure or system crash during the conversion between different firmware versions, which helps to timely discover and fix potential compatibility issues, thereby reducing the risk of system instability caused by firmware upgrades or downgrades and improving the reliability of the device.

[0096] The present application also provides an electronic device, such as Figure 4 As shown, the electronic device 1400 includes:

[0097] one or more processors 1410;

[0098] The memory 1420 stores one or more programs. When the one or more programs are executed by the one or more processors 1410, the one or more processors 1410 implement the firmware version change verification method provided in any embodiment of the present application.

[0099] The memory 1420 is a non-transient network system that can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory 1420 may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1420 may optionally include a memory 1420 remotely located relative to the processor 1410, and these remote memories 1420 may be connected to the processor 1410 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0100] The memory 1420 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1420 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1420 and is called by the processor 1410 to execute the methods of the embodiments of this application.

[0101] The processor 1410 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0102] In some embodiments, the electronic device further comprises:

[0103] Input / output interface, used to realize information input and output;

[0104] Communication interface, used to realize communication interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.);

[0105] A bus that transmits information between various components of the device (e.g., the processor 1410 , memory 1420 , input / output interfaces, and communication interfaces);

[0106] The processor 1410 , the memory 1420 , the input / output interface, and the communication interface can be communicatively connected to each other within the device via a bus.

[0107] An embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions, which are used to execute the verification method for implementing the firmware version change provided in any embodiment of the present application.

[0108] An embodiment of the present application also provides a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, so that the computer device executes the verification method for firmware version changes provided in any embodiment of the present application.

[0109] The system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0110] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0111] Those skilled in the art will appreciate that all or some of the steps and systems disclosed above can be implemented as software, firmware, hardware, or any suitable combination thereof. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is well known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0112] The above description of some embodiments of the present application with reference to the accompanying drawings does not limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention shall be within the scope of the present application.

[0113] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0114] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0115] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0116] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0117] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0118] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.

Claims

1. A method for verifying a firmware version change, characterized in that: The method comprises: Obtaining a Linux verification system, wherein the Linux verification system introduces a predefined matrix algorithm; Based on the Linux verification system, obtain the firmware to be deployed; Using the predefined matrix algorithm to perform version upgrade or version downgrade on the firmware to be deployed, to obtain multiple version change paths, wherein each version change path includes a new version firmware and an old version firmware corresponding to the new version firmware; Traversing the plurality of version change paths and performing multiple rounds of verification to obtain a target verification result, wherein each round of verification includes: using the predefined matrix algorithm and, according to a preset traversal rule, verifying whether the version upgrade or version downgrade is successful, to obtain a first verification result; and verifying the new version firmware and the old version firmware based on the first verification result and the preset verification rule, to obtain a second verification result; Deploying the firmware to be deployed based on the target verification result; The predefined matrix algorithm defines a bridging strategy and a downgrade strategy; and using the predefined matrix algorithm to perform version upgrade or version downgrade on the firmware to be deployed includes: When upgrading the firmware to be deployed using the predefined matrix algorithm, if the old version of the firmware cannot be directly upgraded to the new version of the firmware, using the bridging strategy to change the old version of the firmware to a version of the firmware used for bridging, and then changing the version of the firmware used for bridging to the new version of the firmware; When downgrading the firmware to be deployed using the predefined matrix algorithm, using the downgrade strategy to change the old version of the firmware into the downgraded version of the firmware, and then changing the downgraded version of the firmware into the new version of the firmware; The verification of whether the version upgrade or downgrade is successful according to the preset traversal rule to obtain the first verification result includes: When the expected version change is successful, determining a version change type based on the old version firmware and the new version firmware; When the version change type is the first type, verifying whether the version upgrade or downgrade is successful according to a preset first traversal rule to obtain the first verification result; When the version change type is the second type, verifying whether the version upgrade or downgrade is successful according to the preset second traversal rule to obtain the first verification result; When the expected version change fails, verify whether the version upgrade or downgrade is successful according to the preset third traversal rule to obtain the first verification result; Wherein, when the expected version change is successful, determining the version change type based on the old version firmware and the new version firmware includes: Obtaining a difference between the version numbers of the old version firmware and the new version firmware; When the difference is 1, determining whether the old version firmware can be directly changed to the new version firmware; if so, determining that the version change type is the first type; if not, determining that the version change type is the second type; When the difference is not 1, the version change type is determined to be the second type.

2. The method according to claim 1, characterized in that Based on the Linux verification system, before obtaining the firmware file to be deployed, the following steps are also included: Generate the firmware to be deployed on the host; A communication connection is established between the host and the Linux verification system through the SDB protocol, so that after the host sends the firmware to be deployed to the Linux verification system, the Linux verification system stores the firmware to be deployed.

3. The method according to claim 1, characterized in that The step of verifying the new version of the firmware based on the first verification result and a preset verification rule to obtain a second verification result includes: When the expected version change is successful, if the first verification result is that the change is successful, using the predefined matrix algorithm, based on the preset verification rules, to verify the new version of the firmware to obtain the second verification result; When the expected version change fails, if the first verification result is change failure, the new version firmware is verified based on the preset verification rules using the predefined matrix algorithm to obtain the second verification result.

4. The method according to claim 1, wherein The verifying the new version firmware and the old version firmware based on the first verification result and a preset verification rule includes at least one of the following verification operations: Verify whether the data of the new version firmware is consistent with the data of the old version firmware; Verify whether each byte of the storage area of ​​the old version firmware to which no data was written before the version change is 0; Verify whether the new version of the firmware functions normally; Verify whether the reserved bit parameters of the new version firmware are consistent with the reserved bit parameters of the old version firmware.

5. A device for verifying firmware version changes, characterized in that: The device comprises: Verification system acquisition module: used to obtain a Linux verification system, wherein the Linux verification system introduces a predefined matrix algorithm; Firmware acquisition module: used to acquire the firmware to be deployed based on the Linux verification system; Version change module: used to use the predefined matrix algorithm to perform version upgrade or version downgrade on the firmware to be deployed, and obtain multiple version change paths, wherein each version change path includes a new version firmware and an old version firmware corresponding to the new version firmware, and the predefined matrix algorithm defines a bridging strategy and a downgrade strategy; the use of the predefined matrix algorithm to perform version upgrade or version downgrade on the firmware to be deployed includes: when using the predefined matrix algorithm to perform version upgrade on the firmware to be deployed, when the old version firmware cannot be directly upgraded to the new version firmware, using the bridging strategy to change the old version firmware to a version firmware for bridging, and then changing the version firmware for bridging to the new version firmware; when using the predefined matrix algorithm to perform version downgrade on the firmware to be deployed, using the downgrade strategy to change the old version firmware to a version firmware for downgrading, and then changing the version firmware for downgrading to the new version firmware; Verification module: used for traversing multiple version change paths to perform multiple rounds of verification to obtain a target verification result, wherein each round of verification includes: using the predefined matrix algorithm, according to the preset traversal rules, verifying whether the version upgrade or version downgrade is successful, and obtaining a first verification result; verifying the new version firmware and the old version firmware based on the first verification result and the preset verification rules, and obtaining a second verification result; wherein, verifying whether the version upgrade or version downgrade is successful according to the preset traversal rules to obtain the first verification result includes: when the expected version change is successful, determining the version change type based on the old version firmware and the new version firmware; when the version change type is the first type, verifying whether the version upgrade or version downgrade is successful according to the preset first traversal rule, and obtaining the first verification result; when The version change type is the second type, and according to the preset second traversal rule, whether the version upgrade or version downgrade is successful is verified to obtain the first verification result; when the expected version change fails, according to the preset third traversal rule, whether the version upgrade or version downgrade is successful is verified to obtain the first verification result; wherein, when the expected version change is successful, determining the version change type based on the old version firmware and the new version firmware includes: obtaining the difference between the version numbers of the old version firmware and the new version firmware; when the difference is 1, judging whether the old version firmware can be directly changed to the new version firmware, if so, determining that the version change type is the first type, if not, determining that the version change type is the second type; when the difference is not 1, determining that the version change type is the second type; Deployment module: used to deploy the firmware to be deployed based on the target verification result.

6. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the firmware version change verification method according to any one of claims 1 to 4 when executing the computer program.

7. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the firmware version change verification method according to any one of claims 1 to 4.

Images