Upgrade recovery method and device, computer program product and electronic equipment

Abstract

The invention belongs to the technical field of firmware upgrading, and particularly relates to an upgrading recovery method and device, a computer program product and electronic equipment. The method comprises the following steps: when the electronic equipment is started, determining a last upgrading result based on an upgrading flag bit; when the result of the last upgrade is that the upgrade fails, turning to a boot loader, and performing integrity verification on the local firmware based on the partition verification information of the local firmware; and if the integrity verification of the local firmware fails, downloading the to-be-updated firmware, and upgrading based on the to-be-updated firmware. According to the method, the upgrade result of the last upgrade can be accurately identified by identifying the upgrade flag bit and verifying the integrity of the local firmware, and the firmware can be re-downloaded for firmware upgrade under the condition that the last upgrade fails, so that first-aid recovery under the condition of abnormal upgrade can be realized, and the upgrade efficiency is improved. Normal operation of the electronic equipment is ensured, the user experience is improved, and the maintenance and rework cost of an enterprise is reduced.

Description

Technical Field

[0001] The present application belongs to the technical field of firmware upgrade, and in particular, relates to an upgrade recovery method, device, computer program product and electronic device. Background Art

[0002] In the field of IoT, software updates are crucial to ensure device security, improve user experience, and add new features. In order to avoid the difficulty of software upgrades, electronic devices in the field of IoT generally adopt remote upgrade (OTA) mode; OTA mode allows the latest firmware to be downloaded directly from the cloud and installed in storage media (such as FLASH) through the home network.

[0003] However, if the electronic device suddenly loses power or the storage medium malfunctions during the upgrade process, resulting in the firmware not being completely written to the FLASH, the upgrade will fail. In the event of such an upgrade failure, the firmware in the FLASH is damaged, the electronic device system cannot start, and cannot resume normal operation autonomously. It usually needs to be returned to the factory for repair, resulting in a poor user experience. Summary of the invention

[0004] In view of this, the embodiments of the present application provide an upgrade recovery method, device, computer program product and electronic device to solve the problem in the prior art that electronic devices cannot autonomously resume normal operation after an upgrade failure, resulting in a poor user experience.

[0005] A first aspect of an embodiment of the present application provides an upgrade recovery method, which may include:

[0006] When the electronic device is started, the result of the last upgrade is determined based on the upgrade flag bit; wherein the upgrade flag bit is used to mark the start and end of the firmware upgrade process;

[0007] If the result of the last upgrade is that the upgrade fails, the boot loader is entered, and the integrity check of the local firmware is performed based on the partition check information of the local firmware;

[0008] If the integrity check of the local firmware fails, the firmware to be updated is downloaded and upgraded based on the firmware to be updated.

[0009] A second aspect of the embodiments of the present application provides an upgrade recovery device, which may include:

[0010] A judgment module, used to determine the result of the last upgrade based on the upgrade flag bit when the electronic device is started; wherein the upgrade flag bit is used to mark the start and end of the firmware upgrade process;

[0011] A verification module, used for switching to a boot loader program and performing integrity verification on the local firmware based on the partition verification information of the local firmware when the result of the last upgrade is that the upgrade fails;

[0012] The upgrade module is used to download the firmware to be updated if the integrity check of the local firmware fails, and upgrade based on the firmware to be updated.

[0013] A third aspect of an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any one of the above-mentioned upgrade recovery methods are implemented.

[0014] The fourth aspect of an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the electronic device implements the steps of any one of the above-mentioned upgrade recovery methods.

[0015] A fifth aspect of an embodiment of the present application provides a computer program product, including a computer program, and when the computer program is run, any one of the above-mentioned upgrade recovery methods is executed.

[0016] Compared with the prior art, the embodiments of the present application have the following beneficial effects: when the electronic device is started, the embodiments of the present application determine the result of the last upgrade based on the upgrade flag; wherein the upgrade flag is used to identify the start and end of the firmware upgrade process; when the result of the last upgrade is an upgrade failure, the boot loader is entered, and the integrity of the local firmware is checked based on the partition verification information of the local firmware; if the integrity check of the local firmware fails, the firmware to be updated is downloaded, and the upgrade is performed based on the firmware to be updated. In the embodiments of the present application, the upgrade result of the last upgrade can be accurately identified by identifying the upgrade flag and verifying the integrity of the local firmware, and the firmware can be re-downloaded for firmware upgrade when the last upgrade fails, so that the electronic device can autonomously perform emergency recovery in the event of an abnormal upgrade, without the need for manual maintenance, ensuring the normal operation of the electronic device, helping to improve user experience and reduce the cost of enterprise repair and rework. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 A schematic diagram of an application scenario in an embodiment of the present application;

[0019] Figure 2 A schematic diagram for establishing a communication connection between two chips in an electronic device;

[0020] Figure 3 This is a flow chart of an embodiment of an upgrade recovery method in an embodiment of the present application;

[0021] Figure 4 This is a schematic diagram of each partition in the local firmware;

[0022] Figure 5 This is a structural diagram of an embodiment of an upgrade recovery device in an embodiment of the present application;

[0023] Figure 6 This is a schematic block diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the purpose, features, and advantages of the invention of this application more obvious and easy to understand, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the embodiments described below are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

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

[0026] It should also be understood that the terms used in this application specification are only for the purpose of describing specific embodiments and are not intended to limit the application. As used in this application specification and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0027] It should be further understood that the term “and / or” used in the specification and appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0028] As used in this specification and the appended claims, the term "if" may be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if [described condition or event] is detected" may be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0029] In addition, in the description of the present application, the terms "first", "second", "third", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0030] In the field of IoT, software updates are crucial to ensure device security, improve user experience, and add new features. In order to avoid the difficulty of software upgrades, electronic devices in the field of IoT generally adopt remote upgrade (OTA) mode; OTA mode allows the latest firmware to be downloaded directly from the cloud and installed in storage media (such as FLASH) through the home network.

[0031] However, if the electronic device suddenly loses power or the storage medium malfunctions during the upgrade process, resulting in the firmware not being completely written to the FLASH, the upgrade will fail. In the event of such an upgrade failure, the firmware in the FLASH is damaged, the electronic device system cannot start, and cannot resume normal operation autonomously, often requiring manual on-site inspection and rework, resulting in a poor user experience.

[0032] In the prior art, an additional firmware backup area is usually set up in FLASH to store old firmware for emergency recovery; however, this method takes up more FLASH and usually requires the expansion of off-chip FLASH in hardware, resulting in higher hardware costs.

[0033] In view of this, the embodiments of the present application provide an upgrade recovery method, device, computer program product and electronic device to solve the problem in the prior art that electronic devices cannot autonomously resume normal operation after an upgrade failure, resulting in a poor user experience.

[0034] It should be noted that the executor of the method of the present application is an electronic device, specifically, it can be any IoT device such as a smart door lock, a video doorbell, a video surveillance, etc.

[0035] In the embodiment of the present application, the electronic device may be configured with at least two chips, one of which is used to execute the functions of the corresponding electronic device, and the other chip is used to establish a communication connection with the outside; for example, see Figure 1The electronic device may be a smart door lock, and the electronic device is configured with a first chip and a second chip. The first chip is a video chip, which is used for video monitoring of a specific area; the second chip is a WiFi (Wireless Fidelity) chip, which is used to establish a communication connection with a router, and the router can be connected to a server. When a firmware upgrade is required, the server can notify the second chip through this communication connection, and the second chip can download the firmware from the server after receiving the relevant notification to perform the firmware upgrade.

[0036] Before the normal upgrade, the first chip and the second chip of the electronic device can establish a communication connection through a serial peripheral interface (Serial Peripheral Interface, SPI), such as Figure 2 As shown, the second chip can transmit the downloaded firmware to the first chip through the communication connection, so that the first chip uses the downloaded firmware for firmware upgrade. Since SPI has a fast transmission speed and can support full-duplex communication, the first chip and the second chip can perform high-speed and simultaneous data reception and transmission; in addition, since the hardware interface of SPI is relatively simple, it can reduce the difficulty of its application in the chip, which helps to improve the ease of use and usability of electronic equipment.

[0037] When performing upgrade and recovery, the first chip and the second chip of the electronic device can also re-establish a communication connection through SPI, so that the second chip can promptly learn the need to re-download the firmware and actively obtain the firmware from the server, laying the foundation for upgrade and recovery. Compared with the prior art that requires an additional firmware backup area to be set up in FLASH to store old firmware, the embodiment of the present application can directly obtain the firmware to be updated through the second chip, thereby reducing the occupancy of FLASH and eliminating the need to expand the off-chip FLASH in hardware, completing the upgrade and recovery with a low degree of resource occupancy, which helps save hardware costs.

[0038] Specifically, when the electronic device is started (powered on), the first chip and the second chip can load and initialize their own SPI driver programs. After the initialization is completed, the first chip can actively send the driving status of the first chip to the second chip to synchronize the communication status between the two chips. After that, the firmware upgrade process can be carried out.

[0039] In the embodiment of the present application, an upgrade flag bit can be set in the partition corresponding to the boot loader (UBOOT) of the first chip to mark the start and end of the firmware upgrade process. Before performing the firmware upgrade, the value of the upgrade flag bit can be set to a preset upgrade start identification content to indicate that the firmware upgrade is in progress (or the firmware upgrade has not yet been completed).

[0040] Afterwards, the second chip can download the firmware for firmware upgrade (referred to as firmware to be updated) from the server, and can transmit the downloaded segments of the firmware to be updated to the first chip through the communication link established with the first chip. In the process of transmitting the firmware to be updated, the second chip can calculate the second segment verification code corresponding to the segment of the sent firmware to be updated; similarly, in the process of receiving the firmware to be updated, the first chip can also calculate the first segment verification code corresponding to the received segment of the firmware to be updated, and send the first segment verification code to the second chip, so that the second chip can compare the second segment verification code with the first segment verification code in real time, so as to determine the integrity of the segment of the firmware to be updated; after the transmission is completed, the second chip can calculate the second firmware verification code corresponding to the complete firmware to be updated, and the first chip can calculate the first firmware verification code corresponding to the complete firmware to be updated, and can send the calculated first firmware verification code to the second chip to determine whether the first firmware verification code and the second firmware verification code are the same.

[0041] If the first firmware verification code and the second firmware verification code are the same, it can be determined that the firmware to be updated is a complete firmware and has not been lost or tampered with during the transmission process. At this time, the first chip can use the firmware to be updated to perform firmware upgrade; if the first firmware verification code and the second firmware verification code are different, it can be determined that the firmware to be updated is an incomplete firmware, and the content has been lost or tampered with during the transmission process. At this time, there is no need to perform subsequent upgrade procedures.

[0042] The first fragment check code, the second fragment check code, the first firmware check code and the second firmware check code can be a message digest calculated based on the MD5 message digest algorithm, or a message digest calculated based on other message digest algorithms, which is not limited in the present embodiment of the application. Accordingly, the firmware integrity check can be performed on the downloaded firmware to be updated to ensure that the firmware used for updating is the correct firmware that has not been tampered with, thereby ensuring the security of the firmware upgrade.

[0043] After the firmware upgrade is successful, the value of the upgrade flag can be updated to the preset upgrade success identification content to indicate the end of the firmware upgrade. Among them, the above-mentioned upgrade start identification content and upgrade success identification content can be set according to actual needs, and the embodiments of the present application do not limit this; for example, the upgrade start identification content can be "TPLINK", and the upgrade success identification content can be the content after the upgrade start identification content is erased and reset. Usually, the corresponding content will be reset to 1 after erasing, that is, the upgrade success identification content can be "0xFFFFFF".

[0044] Accordingly, the electronic device can identify the result of the last upgrade based on the upgrade flag each time it is started, so that the electronic device can be upgraded and restored in time if the last upgrade fails, so that the electronic device can operate normally, which helps to ensure the user experience. Figure 3 , an embodiment of an upgrade recovery method in the embodiment of the present application may include:

[0045] Step S301: when the electronic device is started, the result of the last upgrade is determined based on the upgrade flag.

[0046] Each time the electronic device is started, the upgrade flag bit can be detected to determine the result of the last upgrade, so that the upgrade can be restored in time when the last upgrade fails.

[0047] If the upgrade flag is an upgrade success identification content, it can be determined that the result of the last upgrade was a successful upgrade. At this time, there is no need to execute subsequent steps and directly enter normal system operation; if the upgrade flag is an upgrade start identification content, it can be determined that the result of the last upgrade was a failed upgrade. At this time, step S302 and its subsequent steps can be executed.

[0048] Step S302: When the result of the last upgrade is that the upgrade fails, the boot loader is entered, and the integrity check of the local firmware is performed based on the partition check information of the local firmware.

[0049] When it is determined that the result of the last upgrade is an upgrade failure, the boot loader can be entered, and the local firmware can be checked for integrity during the boot loader operation to determine whether the local firmware is a complete firmware; only when the local firmware is not a complete firmware, it is necessary to re-download the firmware to be updated for upgrading; accordingly, repeated firmware download and upgrade can be avoided when the local firmware is a complete firmware.

[0050] If the local firmware is the same as the firmware downloaded during the last upgrade, it can be determined that the last upgrade has actually completed the firmware writing process, that is, the local firmware is a complete firmware, but a power outage occurred before the upgrade flag was updated, resulting in the upgrade flag failing to be updated to the upgrade success identification content. At this time, it can be determined that the integrity check of the local firmware is successful, and the upgrade flag is updated to the upgrade success identification content to indicate that the result of the last upgrade was actually a successful upgrade.

[0051] If the local firmware is different from the firmware downloaded during the last upgrade, it can be determined that the firmware writing process was not completed during the last upgrade. At this time, emergency recovery is required to ensure the normal operation of the electronic device.

[0052] In an embodiment of the present application, the integrity check of the local firmware can be performed based on the partition check information of the local firmware. Specifically, the local firmware can include various partitions, and different partitions can include different data contents. Here, a specific partition can be set in the local firmware to store the location of each partition in FLASH and the data content of a specific partition.

[0053] For the sake of ease of description, the location of each partition in FLASH and the data content of a specific partition can be referred to as partition verification information, and the partition storing partition verification information can also be referred to as an information recording partition; wherein, the location of the information recording partition in FLASH can be set according to actual needs, and this application does not limit this.

[0054] As an example only, the various partitions of the local firmware may be as follows Figure 4 As shown, specifically, the local firmware may include an Initial Program Load (IPL) partition, a chip identification (Chip Identification and Serial Number, CIS) partition, a custom IPL (IPL_CUST) partition, a boot loader (UBOOT) partition, an environment variable (ENV) partition, a related information (FACT_INFO) partition, a miscellaneous data (MISC) partition, a user configuration (USR_CFG) partition, a real-time operating system (Real-Time Operating System, RTOS) partition, a kernel (KERNEL) partition, a root file system (rootfs) partition and an information record (TP_HEADER) partition; wherein the TP_HEADER partition stores the partition verification information of the local firmware; since the actual required space of the RTOS partition is usually smaller than the space allocated to the RTOS partition, the information record partition may be located between the RTOS partition and the KERNEL partition; here, the length of the information record partition may be 0x1000.

[0055] In an embodiment of the present application, the partition verification information of the local firmware may include the partition structure information and partition data information of the local firmware; the partition structure information of the local firmware is specifically the length and starting address of each partition in the local firmware, and the partition data information of the local firmware is specifically the verification code of the upgrade partition of the local firmware; wherein, the upgrade partition is the partition in the local firmware that requires firmware upgrade; normally, only the RTOS partition and the KERNEL partition need to be upgraded, while the configuration of other partitions remains unchanged, so the upgrade partitions in the local firmware are usually the RTOS partition and the KERNEL partition.

[0056] When upgrading the local firmware, the firmware to be updated can be written into FLASH, and the partition verification information of the local firmware can be updated; specifically, the length and starting address of each partition of the upgraded local firmware can be used as the updated partition structure information, and the verification code of the upgraded partition of the upgraded local firmware can be calculated. Here, the verification code (such as MD5 code) of the data content of the upgraded upgrade partition (usually the RTOS partition and the KERNEL partition) can be calculated, and the verification code can be used as the updated partition data information.

[0057] If the current partition verification information of the local firmware is the same as the partition verification information in the information recording partition of the local firmware, it means that the firmware writing process has been completed during the last upgrade and the local firmware is a complete firmware; if the current partition verification information of the local firmware is different from the partition verification information in the information recording partition of the local firmware, it means that the firmware writing process has not been completed during the last upgrade and the local firmware is not a complete firmware.

[0058] In an embodiment of the present application, when performing an integrity check on the local firmware, the partition structure information can be used to first perform a structural integrity check on the local firmware. If the structural integrity check on the local firmware is successful, the partition data information can be used to further perform a data integrity check on the local firmware.

[0059] Specifically, the current structural information of each partition in the local firmware can be obtained. Here, the length and starting address of each partition in the local firmware can be detected to obtain the current structural information of each partition in the local firmware; then, the current structural information of each partition in the local firmware can be compared with the partition structural information in the information recording partition.

[0060] If the current structure information is different from the partition structure information, it can be considered that the firmware writing process was not completed during the last upgrade, and a power outage may have occurred during the erasing of the original partition verification information or the writing of the updated partition verification information. At this time, it can be determined that the integrity check of the local firmware has failed, and step S303 can be executed directly.

[0061] If the current structure information is the same as the partition structure information, it can be determined that the structural integrity check of the local firmware is successful, and the local firmware can be further checked for data integrity. Specifically, the current data information of the upgrade partition in the local firmware can be obtained. Here, the data content of the upgrade partition of the local firmware can be obtained, and the check code corresponding to the data content can be calculated, and the check code can be used as the current data information of the local firmware; then, the current data information of the local firmware can be compared with the partition data information in the information recording partition.

[0062] For example, if the partition data information is the MD5 code of the upgrade partition, when performing data integrity check on the local firmware, the MD5 code corresponding to the data content of the upgrade partition in the local firmware can be calculated, and the calculated MD5 code can be compared with the MD5 code in the partition data information.

[0063] If the current data information of the local firmware is different from the partition data information, it can be considered that the firmware writing process was not completed during the last upgrade, and power failure may have occurred during the erasing of the original firmware or the writing of the firmware to be updated. At this time, it can be determined that the integrity check of the local firmware has failed, and step S303 can be executed; if the current data information of the local firmware is the same as the partition data information, it can be determined that the integrity check of the local firmware is successful.

[0064] If the integrity check of the local firmware is successful when the result of the last upgrade was a failure, it can be considered that the firmware writing process was completed during the last upgrade, that is, the local firmware is complete firmware, but the power was lost before the upgrade flag was updated. At this time, there is no need to re-download the firmware for upgrade recovery. The upgrade flag can be directly updated to the upgrade success identification content and the electronic device can be restarted to avoid entering the boot loader again due to the failure to update the upgrade flag, resulting in unnecessary integrity check of the local firmware.

[0065] Through firmware integrity verification, problems that occurred during the last upgrade process can be accurately identified and reasonable emergency measures can be taken. This can avoid repeated firmware upgrades when the local firmware is complete, thereby shortening the upgrade recovery time and improving the efficiency of upgrade recovery.

[0066] Step S303: If the integrity check of the local firmware fails, the firmware to be updated is downloaded and upgraded based on the firmware to be updated.

[0067] In the embodiment of the present application, if the integrity check of the local firmware fails, it is necessary to re-download the firmware to be updated and upgrade it. Specifically, in the case of the last upgrade failure, the first chip can no longer start normally. At this time, the first chip can try to re-establish a communication connection with the second chip during the operation of the boot loader; here, the first chip and the second chip can initialize their own SPI drivers. After the initialization is completed, the first chip can send the driving status of the first chip to the second chip to synchronize the communication status of the two chips.

[0068] Afterwards, the first chip can notify the second chip through the established communication connection that the firmware needs to be upgraded again.

[0069] The second chip can then re-download the firmware to be updated from the server, and based on the established communication connection with the first chip, transmit the firmware to be updated from the second chip to the first chip; after the transmission is completed, the firmware to be updated can be integrity checked. The specific process of checking the firmware to be updated can be referred to the previous description and will not be repeated here.

[0070] After the integrity check of the firmware to be updated is successful, the firmware to be updated can be used to upgrade the firmware; if the upgrade still fails, the electronic device will identify this result according to the above process when it is started next time and re-upgrade the firmware. Accordingly, the embodiment of the present application can automatically identify problems that occur during the upgrade process and perform upgrade recovery, without the need to rework and burn the electronic device, which can reduce maintenance costs and improve the user experience.

[0071] By re-establishing the communication connection between the first chip and the second chip, the second chip can promptly learn the need to re-download the firmware to be updated and actively obtain the firmware to be updated from the server, laying the foundation for upgrade recovery. Compared with the prior art that requires an additional firmware backup area to be set up in FLASH to store old firmware, the embodiment of the present application can directly obtain the firmware to be updated through the second chip, thereby reducing the occupancy of FLASH and eliminating the need to expand the off-chip FLASH in hardware, completing the upgrade recovery with a low degree of resource occupancy, which helps save hardware costs.

[0072] In summary, when the electronic device is started, the embodiment of the present application determines the result of the last upgrade based on the upgrade flag; wherein the upgrade flag is used to identify the start and end of the firmware upgrade process; when the result of the last upgrade is an upgrade failure, the boot loader is entered, and the local firmware is checked for integrity based on the partition verification information of the local firmware; if the integrity check of the local firmware fails, the firmware to be updated is downloaded, and the upgrade is performed based on the firmware to be updated. In the embodiment of the present application, the upgrade result of the last upgrade can be accurately identified by identifying the upgrade flag and verifying the integrity of the local firmware, and the firmware can be re-downloaded for firmware upgrade when the last upgrade fails, so that the electronic device can autonomously perform emergency recovery in the event of an abnormal upgrade, without the need for manual maintenance, ensuring the normal operation of the electronic device, helping to improve user experience and reduce the cost of enterprise repair and rework.

[0073] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean 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 the present application.

[0074] Corresponding to an upgrade recovery method described in the above embodiment, Figure 5A structural diagram of an embodiment of an upgrade recovery device provided in an embodiment of the present application is shown.

[0075] In an embodiment of the present application, an upgrade recovery device may include:

[0076] The judgment module 501 is used to determine the result of the last upgrade based on the upgrade flag when the electronic device is started; wherein the upgrade flag is used to mark the start and end of the firmware upgrade process;

[0077] Verification module 502, used for switching to the boot loader and performing integrity verification on the local firmware based on the partition verification information of the local firmware when the result of the last upgrade is that the upgrade fails;

[0078] The upgrade module 503 is used to download the firmware to be updated and perform an upgrade based on the firmware to be updated if the integrity check of the local firmware fails.

[0079] In a specific implementation of the embodiment of the present application, the upgrade recovery device may further include:

[0080] The update module is used to update the upgrade flag to upgrade success identification content if the integrity check of the local firmware is successful; wherein the upgrade success identification content is used to indicate that the result of the last upgrade is a successful upgrade.

[0081] In a specific implementation of the embodiment of the present application, the partition verification information includes partition structure information and partition data information;

[0082] The verification module comprises:

[0083] A structure check submodule, used for performing a structure integrity check on each partition of the local firmware based on the partition structure information of the local firmware when the result of the last upgrade is that the upgrade fails;

[0084] A data verification submodule is used to perform data integrity verification on the upgrade partition of the local firmware based on the partition data information of the local firmware if the structural integrity verification of each partition of the local firmware is successful; wherein the upgrade partition is the partition to be upgraded during the upgrade process.

[0085] In a specific implementation of the embodiment of the present application, the structure check submodule includes:

[0086] A structure information acquisition unit, used to acquire current structure information of each partition in the local firmware;

[0087] a failure determination first unit, configured to determine that the integrity check of the local firmware fails if the current structure information is different from the partition structure information;

[0088] A successful determination first unit is used to determine that the structural integrity check of the local firmware is successful if the current structural information is the same as the partition structural information;

[0089] The data check submodule comprises:

[0090] A data information acquisition unit, used to acquire current data information of the upgrade partition in the local firmware;

[0091] a failure determination second unit, configured to determine that the integrity check of the local firmware fails if the current data information is not identical to the partition data information;

[0092] The second unit is used to successfully determine that the integrity check of the local firmware is successful if the current data information is the same as the partition data information.

[0093] In a specific implementation of the embodiment of the present application, the upgrade module includes:

[0094] A download submodule, configured to download the firmware to be updated if the integrity check of the local firmware fails;

[0095] A check submodule, used to perform integrity check on the firmware to be updated;

[0096] The upgrade submodule is used to upgrade the firmware to be updated if the integrity check of the firmware to be updated is successful.

[0097] In a specific implementation of the embodiment of the present application, the download submodule includes:

[0098] A communication connection establishing unit, used to establish a communication connection between a first chip and a second chip in the electronic device during the operation of the boot loader; wherein the first chip is a chip in the electronic device that needs to perform a firmware upgrade, and the second chip is a chip in the electronic device that downloads the firmware to be updated;

[0099] A downloading unit, configured to download the firmware to be updated by using the second chip;

[0100] A transmission unit is used to transmit the firmware to be updated from the second chip to the first chip based on the communication connection.

[0101] In a specific implementation of the embodiment of the present application, the syndrome module includes:

[0102] A first calculation unit, configured to calculate a first firmware check code of the firmware to be updated in the first chip;

[0103] A second calculating unit, used for calculating a second firmware check code of the firmware to be updated in the second chip;

[0104] A third unit for successfully determining that the integrity check of the firmware to be updated is successful if the first firmware verification code is the same as the second firmware verification code;

[0105] The third failure determination unit is configured to determine that the integrity check of the firmware to be updated has failed if the first firmware verification code is different from the second firmware verification code.

[0106] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices, modules and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0107] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0108] Figure 6 A schematic block diagram of an electronic device provided in an embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0109] like Figure 6 As shown, the electronic device 6 of this embodiment includes: a processor 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processor 60. When the processor 60 executes the computer program 62, the steps in the above-mentioned upgrade recovery method embodiments are implemented, for example Figure 3 Alternatively, when the processor 60 executes the computer program 62, the functions of each module / unit in the above-mentioned device embodiments are realized, for example Figure 5 The functions of modules 501 to 503 are shown.

[0110] Exemplarily, the computer program 62 may be divided into one or more modules / units, which are stored in the memory 61 and executed by the processor 60 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 62 in the electronic device 6.

[0111] Those skilled in the art will understand that Figure 6It is only an example of the electronic device 6 and does not constitute a limitation of the electronic device 6. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device 6 may also include input and output devices, network access devices, buses, etc.

[0112] The processor 60 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0113] The memory 61 may be an internal storage unit of the electronic device 6, such as a hard disk or memory of the electronic device 6. The memory 61 may also be an external storage device of the electronic device 6, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 6. Further, the memory 61 may also include both an internal storage unit of the electronic device 6 and an external storage device. The memory 61 is used to store the computer program and other programs and data required by the electronic device 6. The memory 61 may also be used to temporarily store data that has been output or is to be output.

[0114] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by 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 embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0115] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0116] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example 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 performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0117] In the embodiments provided in the present 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 schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0119] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0120] If the integrated module / unit is implemented in the form of 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, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable storage medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable storage medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable storage media do not include electric carrier signals and telecommunication signals.

[0121] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. An upgrade recovery method, characterized in that: include: When the electronic device is started, the result of the last upgrade is determined based on the upgrade flag bit; wherein the upgrade flag bit is used to mark the start and end of the firmware upgrade process; If the result of the last upgrade is that the upgrade fails, switching to the boot loader and performing integrity check on the local firmware based on the partition check information of the local firmware; If the integrity check of the local firmware fails, the firmware to be updated is downloaded and upgraded based on the firmware to be updated.

2. The upgrade recovery method according to claim 1, characterized in that: Also includes: If the integrity check of the local firmware is successful, the upgrade flag is updated to upgrade success identification content; wherein the upgrade success identification content is used to indicate that the result of the last upgrade is a successful upgrade.

3. The upgrade recovery method according to claim 1, characterized in that: The partition verification information includes partition structure information and partition data information; When the result of the last upgrade is that the upgrade fails, the integrity check of the local firmware is performed based on the partition check information of the local firmware, including: In the case where the result of the last upgrade is an upgrade failure, performing a structural integrity check on each partition of the local firmware based on the partition structure information of the local firmware; If the structural integrity check of each partition of the local firmware is successful, a data integrity check is performed on the upgrade partition of the local firmware based on the partition data information of the local firmware; wherein the upgrade partition is the partition that is upgraded during the upgrade process.

4. The upgrade recovery method according to claim 3, characterized in that: In the case where the result of the last upgrade is that the upgrade fails, the boot loader is entered, and based on the partition structure information of the local firmware, a structural integrity check is performed on each partition of the local firmware, including: Obtaining current structure information of each partition in the local firmware; If the current structure information is different from the partition structure information, determining that the integrity check of the local firmware fails; If the current structure information is the same as the partition structure information, determining that the structure integrity check of the local firmware is successful; If the structural integrity check of each partition of the local firmware is successful, then based on the partition data information of the local firmware, a data integrity check is performed on the upgrade partition of the local firmware, including: Obtaining current data information of the upgrade partition in the local firmware; If the current data information is different from the partition data information, determining that the integrity check of the local firmware fails; If the current data information is the same as the partition data information, it is determined that the integrity check of the local firmware is successful.

5. The upgrade recovery method according to claim 1, characterized in that: If the integrity check of the local firmware fails, downloading the firmware to be updated, and upgrading based on the firmware to be updated, including: If the integrity check of the local firmware fails, then downloading the firmware to be updated; Performing integrity check on the firmware to be updated; If the integrity check of the firmware to be updated is successful, the upgrade is performed based on the firmware to be updated.

6. The upgrade recovery method according to claim 5, characterized in that: The downloading of the firmware to be updated includes: Establishing a communication connection between a first chip and a second chip in the electronic device; wherein the first chip is a chip in the electronic device that needs to perform a firmware upgrade, and the second chip is a chip in the electronic device that downloads the firmware to be updated; Downloading the firmware to be updated using the second chip; The firmware to be updated is transmitted from the second chip to the first chip based on the communication connection.

7. The upgrade recovery method according to claim 6, characterized in that: The performing integrity check on the firmware to be updated includes: Calculating a first firmware check code of the firmware to be updated in the first chip; Calculating a second firmware verification code of the firmware to be updated in the second chip; If the first firmware verification code is the same as the second firmware verification code, it is determined that the integrity check of the firmware to be updated is successful; If the first firmware verification code is different from the second firmware verification code, it is determined that the integrity check of the firmware to be updated has failed.

8. An upgrade recovery device, characterized in that: include: A judgment module, used to determine the result of the last upgrade based on the upgrade flag bit when the electronic device is started; wherein the upgrade flag bit is used to mark the start and end of the firmware upgrade process; A verification module, used for switching to a boot loader and performing integrity verification on the local firmware based on the partition verification information of the local firmware when the result of the last upgrade is that the upgrade fails; The upgrade module is used to download the firmware to be updated if the integrity check of the local firmware fails, and upgrade based on the firmware to be updated.

9. A computer program product, characterized in that The invention comprises a computer program, which enables the upgrade recovery method according to any one of claims 1 to 7 to be executed when the computer program is executed.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the electronic device implements the steps of the upgrade recovery method according to any one of claims 1 to 7.

Images