Method, device, equipment and readable storage medium for resolving device abnormalities

Abstract

The present invention discloses a method, apparatus, device, and computer-readable storage medium for recovering a brick when a device has an abnormal flashing problem. The method is applied to an embedded device and includes: after the embedded device is powered on, entering a boot and startup area in a storage area to run to detect whether a rescue triggering condition is met; when it is determined that the rescue triggering condition is met, running the rescue firmware stored in the rescue firmware area; when it is determined that the rescue triggering condition is not met, overwriting the old version of the inherent firmware stored in the firmware running area in the storage area with the new version of the inherent firmware, and then jumping to the firmware running area to run. The present invention implements a rescue solution for recovering a brick when a device has an abnormal flashing problem, so that when an embedded device has an abnormal flashing problem, the device can be restored to normal by executing the rescue process without the need for disassembly and repair, thereby reducing the scrap rate of embedded devices.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded device upgrades, and in particular to a method, apparatus, device, and computer-readable storage medium for recovering a device from a flashing anomaly. Background Art

[0002] Embedded devices, such as headphones, typically don't have a dedicated flash port for flashing firmware after assembly. Subsequent firmware updates require flashing the device. If a sudden power outage or other issues during flashing prevent the device from booting properly or the flashed firmware from running properly, the device is said to be "bricked," meaning it's unusable. Currently, users cannot fix a bricked device themselves and must return it to after-sales service for disassembly and repair, which compromises the device's integrity and renders it useless. Summary of the Invention

[0003] The main purpose of the present invention is to provide a method, device, equipment and computer-readable storage medium for recovering bricks when a device has an abnormal flashing problem, aiming to provide a solution for recovering bricks when a device has an abnormal flashing problem, so that the embedded device can be restored to normal when the flashing problem occurs, thereby reducing the scrap rate of embedded devices.

[0004] To achieve the above object, the present invention provides a method for recovering a bricked device due to abnormal flashing. The method is applied to an embedded device, and a recovery firmware area is set in a storage area of ​​the embedded device. The method includes the following steps:

[0005] After the embedded device is powered on, it enters the boot area in the storage area to run to detect whether the trigger conditions for brick recovery are met;

[0006] When it is determined that the brick recovery trigger condition is met, the brick recovery firmware stored in the brick recovery firmware area is run to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware;

[0007] When it is determined that the brick recovery trigger condition is not met, if it is detected that a new version of the inherent firmware is stored in the flash firmware backup area, the new version of the inherent firmware is used to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area, and then jump to the firmware running area to run.

[0008] Optionally, after the embedded device is powered on, the steps of entering the boot area in the storage area to run and detecting whether the triggering condition for recovering from a brick is satisfied include:

[0009] After the embedded device is powered on, it enters the boot area in the storage area to run to detect whether a brick recovery indication message sent by an external device connected to the embedded device is received. If the brick recovery indication message sent by the external device connected to the embedded device is detected, it is determined that the brick recovery trigger condition is met; or

[0010] After the embedded device is powered on, the boot area in the storage area is entered to run to detect whether a brick recovery register set in the embedded device is set. If it is detected that the brick recovery register is set, it is determined that the brick recovery trigger condition is met, wherein a setting circuit set in the embedded device sets the brick recovery register when receiving a preset signal sent by an external device electrically connected to the embedded device; or

[0011] After the embedded device is powered on, it enters the boot area in the storage area to run a data integrity check on the inherent firmware stored in the firmware running area. If the check fails, it is determined that the brick recovery trigger condition is met.

[0012] Optionally, the brick recovery firmware is obtained by cutting out functions other than the firmware upgrade function in the inherent firmware and retaining the firmware upgrade function.

[0013] Optionally, when it is determined that the brick recovery trigger condition is met, the step of running the brick recovery firmware stored in the brick recovery firmware area to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware includes:

[0014] When it is determined that the brick recovery triggering condition is met, the compressed brick recovery firmware stored in the brick recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area;

[0015] Decompress the compressed brick-saving firmware in the firmware running area to obtain the decompressed brick-saving firmware, and jump to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

[0016] Optionally, before the step of using the compressed brick recovery firmware stored in the brick recovery firmware area to overwrite the old version of the inherent firmware in the firmware running area, the method further includes:

[0017] Calculate the first MD5 checksum of the compressed brick recovery firmware stored in the brick recovery firmware area;

[0018] Compare the first MD5 checksum with the second MD5 checksum stored in the recovery firmware area;

[0019] If the first MD5 checksum is consistent with the second MD5 checksum, the compressed recovery firmware stored in the recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area.

[0020] Optionally, before jumping to the firmware running area to run and downloading the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of decompressing the brick-recovering firmware, the method further includes:

[0021] Verify the data integrity of the decompressed recovery firmware in the firmware running area;

[0022] If the verification is passed, the execution jumps to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

[0023] Optionally, the brick recovery firmware is pre-burned in the brick recovery firmware area; or,

[0024] After receiving the brick recovery firmware sent by the external device connected to the embedded device during operation, the embedded device stores the brick recovery firmware in the brick recovery firmware area.

[0025] To achieve the above-mentioned object, the present invention further provides a device for recovering a brick when a device flashes abnormally. The device is deployed in an embedded device, and a recovery firmware area is set in a storage area of ​​the embedded device. The device comprises:

[0026] The detection module is used to enter the boot area in the storage area after the embedded device is powered on to detect whether the trigger condition for rescuing the brick is met;

[0027] The brick recovery module is used to run the brick recovery firmware stored in the brick recovery firmware area when it is determined that the brick recovery trigger condition is met, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware;

[0028] The upgrade module is used to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area with the new version of the inherent firmware when it is determined that the trigger condition for brick recovery is not met. Then, if it is detected that a new version of the inherent firmware is stored in the firmware backup area, the new version of the inherent firmware will be used to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area, and then jump to the firmware running area to run.

[0029] To achieve the above-mentioned purpose, the present invention also provides a device for recovering bricks due to abnormal flashing of a device. The device for recovering bricks due to abnormal flashing of a device comprises: a memory, a processor, and a device for recovering bricks due to abnormal flashing of a device stored in the memory and runnable on the processor. When the device for recovering bricks due to abnormal flashing of a device is executed by the processor, the steps of the device for recovering bricks due to abnormal flashing of a device are implemented as described above.

[0030] In addition, to achieve the above-mentioned purpose, the present invention also proposes a computer-readable storage medium, on which a device brick recovery program for abnormal flashing is stored. When the device brick recovery program for abnormal flashing is executed by a processor, the steps of the above-mentioned device brick recovery method for abnormal flashing are implemented.

[0031] In the present invention, a brick recovery firmware area is set in the storage area of ​​the embedded device. After the embedded device is powered on, the boot and start area in the storage area is entered to run to detect whether the brick recovery trigger condition is met; when it is determined that the brick recovery trigger condition is met, the brick recovery firmware stored in the brick recovery firmware area is run to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware; when it is determined that the brick recovery trigger condition is not met, if it is detected that the flash firmware backup area stores a new version of the inherent firmware, the new version of the inherent firmware is used to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area, and then jump to the firmware running area to run. The present invention realizes a brick recovery solution for abnormal flashing of the device, so that when the embedded device flashes abnormally, the device can be restored to normal by executing the brick recovery process, without the need to disassemble the device for repair, thereby reducing the scrap rate of the embedded device. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 A schematic diagram of the hardware operating environment involved in an embodiment of the present invention;

[0033] Figure 2 This is a flow chart of the first embodiment of the method for recovering a brick due to abnormal flashing of a device according to the present invention;

[0034] Figure 3 A schematic diagram of a storage format of a brick recovery firmware according to an embodiment of the present invention;

[0035] Figure 4 This is a functional module diagram of a preferred embodiment of the device for recovering bricks due to abnormal flashing of the device of the present invention.

[0036] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0037] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0038] like Figure 1 As shown, Figure 1 It is a schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention.

[0039] It should be noted that the device for recovering a brick after an abnormal flashing operation in the embodiment of the present invention can be a headset, a smart phone, a personal computer, etc., without any specific limitation. A recovery firmware area is set in the storage area of ​​the embedded device.

[0040] like Figure 1As shown, the device for resetting the device from abnormal flashing may include: a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may optionally be a storage device independent of the aforementioned processor 1001.

[0041] Those skilled in the art will understand that Figure 1 The device structure shown in the figure does not constitute a limitation on the device for resolving device bricking problems, and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0042] like Figure 1 As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device flash abnormality recovery program. The operating system is a program that manages and controls the hardware and software resources of the device, and supports the operation of the device flash abnormality recovery program and other software or programs. Figure 1 In the device shown, the user interface 1003 is mainly used to communicate data with the client; the network interface 1004 is mainly used to establish a communication connection with the server; and the processor 1001 can be used to call the device flash abnormality recovery program stored in the memory 1005 and perform the following operations:

[0043] After the embedded device is powered on, it enters the boot area in the storage area to run to detect whether the trigger conditions for brick recovery are met;

[0044] When it is determined that the brick recovery trigger condition is met, the brick recovery firmware stored in the brick recovery firmware area is run to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware;

[0045] When it is determined that the brick recovery trigger condition is not met, if it is detected that a new version of the inherent firmware is stored in the flash firmware backup area, the new version of the inherent firmware is used to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area, and then jump to the firmware running area to run.

[0046] Furthermore, after the embedded device is powered on, the boot area in the storage area is entered to run to detect whether the triggering conditions for recovering the brick are met. The operations include:

[0047] After the embedded device is powered on, it enters the boot area in the storage area to run to detect whether a brick recovery indication message sent by an external device connected to the embedded device is received. If the brick recovery indication message sent by the external device connected to the embedded device is detected, it is determined that the brick recovery trigger condition is met; or

[0048] After the embedded device is powered on, the boot area in the storage area is entered to run to detect whether a brick recovery register set in the embedded device is set. If it is detected that the brick recovery register is set, it is determined that the brick recovery trigger condition is met, wherein a setting circuit set in the embedded device sets the brick recovery register when receiving a preset signal sent by an external device electrically connected to the embedded device; or

[0049] After the embedded device is powered on, it enters the boot area in the storage area to run a data integrity check on the inherent firmware stored in the firmware running area. If the check fails, it is determined that the brick recovery trigger condition is met.

[0050] Furthermore, the brick recovery firmware is obtained by cutting out functions other than the firmware upgrade function in the inherent firmware and retaining the firmware upgrade function.

[0051] Further, when it is determined that the brick recovery trigger condition is met, the operation of running the brick recovery firmware stored in the brick recovery firmware area to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware includes:

[0052] When it is determined that the brick recovery triggering condition is met, the compressed brick recovery firmware stored in the brick recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area;

[0053] Decompress the compressed brick-saving firmware in the firmware running area to obtain the decompressed brick-saving firmware, and jump to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

[0054] Furthermore, before using the compressed brick recovery firmware stored in the brick recovery firmware area to overwrite the old version of the inherent firmware in the firmware running area, the method further includes:

[0055] Calculate the first MD5 checksum of the compressed brick recovery firmware stored in the brick recovery firmware area;

[0056] Compare the first MD5 checksum with the second MD5 checksum stored in the recovery firmware area;

[0057] If the first MD5 checksum is consistent with the second MD5 checksum, the compressed recovery firmware stored in the recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area.

[0058] Furthermore, before jumping to the firmware running area to run the firmware upgrade function of decompressing the brick-saving firmware and downloading the new version of the inherent firmware to the flash firmware backup area in the storage area, it also includes:

[0059] Verify the data integrity of the decompressed recovery firmware in the firmware running area;

[0060] If the verification is passed, the execution jumps to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

[0061] Furthermore, the brick recovery firmware is pre-burned in the brick recovery firmware area; or,

[0062] After receiving the brick recovery firmware sent by the external device connected to the embedded device during operation, the embedded device stores the brick recovery firmware in the brick recovery firmware area.

[0063] Based on the above structure, various embodiments of a method for recovering a bricked device due to abnormal flashing are proposed.

[0064] Reference Figure 2 , Figure 2 This is a flow chart of the first embodiment of the method for recovering a brick due to abnormal flashing of a device according to the present invention.

[0065] The embodiment of the present invention provides an embodiment of a method for recovering a brick due to an abnormal flashing of a device. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than here. In this embodiment, the execution subject of the method for recovering a brick due to an abnormal flashing of a device may be an embedded device such as a headset, a personal computer, or a smart phone, and this is not limited in this embodiment. In this embodiment, the method for recovering a brick due to an abnormal flashing of a device includes:

[0066] Step S10: After the embedded device is powered on, the boot area in the storage area is entered to run to detect whether the trigger condition for retrieving the brick is met;

[0067] In this embodiment, the storage area of ​​the embedded device is provided with at least a boot area, a firmware running area, a brick recovery firmware area, and a flash firmware backup area. In some implementations, other areas may also be provided in the storage area, such as a factory data area.

[0068] The boot program is stored in the boot area. After the embedded device is powered on, it will first run in the boot area, that is, the boot program in the boot area will be run. The firmware running area stores firmware. During the normal operation of the embedded device, after the boot area runs, it will jump to the firmware running area to run, that is, run this firmware. Compared with the brick recovery firmware stored in the brick recovery firmware area, this firmware is inherent to the embedded device and is used to implement the functions of the embedded device, such as the audio output function of the headset. Therefore, to distinguish it from the brick recovery firmware, this firmware is called inherent firmware. The brick recovery firmware area is used to store the brick recovery firmware, which is used to recover the embedded device when the flashing is abnormal; the brick recovery firmware is a program that can realize the firmware upgrade function, and the firmware upgrade function includes but is not limited to downloading the new version of the inherent firmware from other devices that have established a communication connection, and storing the new version of the inherent firmware in the flashing firmware backup area. The flashing firmware backup area is used to store the new version of the inherent firmware, and the new version of the inherent firmware is used to upgrade the old version of the inherent firmware stored in the firmware running area, thereby completing the flashing.

[0069] After the embedded device is powered on, it enters the boot and start area and runs. By running the program in the boot and start area, it is first detected whether the brick recovery trigger condition is met. That is, before jumping into the firmware running area, a detection process is added to detect whether to perform a brick recovery, so that the brick recovery process can be executed when a brick recovery is needed. Among them, the brick recovery trigger condition can be set in advance according to needs and is not limited in this embodiment. When the brick recovery trigger condition is met, it means that the current embedded device may have a flashing abnormality that causes the inherent firmware to run abnormally, and the normal function of the embedded device cannot be realized, and a brick recovery is required; when the brick recovery trigger condition is not met, it means that the inherent firmware of the current embedded device can run normally and no brick recovery is required.

[0070] Furthermore, in one embodiment, step S10 includes:

[0071] Step S101: After the embedded device is powered on, the boot area in the storage area is entered to detect whether a brick recovery indication message sent by an external device connected to the embedded device is received. If the brick recovery indication message sent by the external device connected to the embedded device is detected, it is determined that a brick recovery trigger condition is met.

[0072] In this embodiment, the brick rescue trigger condition can be set to detect the brick rescue indication information sent by the external device connected to the embedded device. The external device can be a PC end, a headphone box and other devices, which is not limited in this embodiment. The connection method between the external device and the embedded device is also not limited. For example, when the embedded device is a headphone device, the headphone box can be connected through the PC end, and the brick rescue indication information is sent to the headphone box. The headphone box sends the brick rescue indication information to the headphone device through the contact between the headphone box and the headphone device. The program in the boot startup area can implement the brick rescue process and the normal boot process. The brick rescue indication information is used to instruct the embedded device to enter the brick rescue process when running the program in the boot startup area. In this embodiment, the specific content of the brick rescue indication information is not limited and can be set in advance according to needs.

[0073] When the boot and start area is running, the embedded device detects whether a brick recovery trigger condition is met. Specifically, the embedded device may detect whether a brick recovery indication message sent by an external device connected to the embedded device is received by running a program in the boot and start area. If it is detected that the embedded device receives the brick recovery indication message sent by the external device, it can be determined that the brick recovery trigger condition is met. Furthermore, if it is detected that the embedded device does not receive the brick recovery indication message within a period of time after being powered on, it can be determined that the brick recovery trigger condition is not met. Alternatively, further detection may be performed to determine whether other brick recovery trigger conditions are met.

[0074] When the user wants to repair an embedded device, he can connect the embedded device through an external device, and after the embedded device is powered on through the external device, send repair instruction information to the embedded device.

[0075] Furthermore, in one embodiment, step S10 includes:

[0076] Step S102: After the embedded device is powered on, the boot area in the storage area is entered to detect whether a brick recovery register set in the embedded device is set. If the brick recovery register is detected to be set, it is determined that a brick recovery trigger condition is met. The setting circuit set in the embedded device sets the brick recovery register when receiving a preset signal sent by an external device electrically connected to the embedded device.

[0077] In this embodiment, the brick rescue trigger condition can be set to detect the setting of the brick rescue register in the embedded device. Among them, a setting circuit and a brick rescue register can be set in the embedded device, and the setting circuit is used to set the brick rescue register when receiving a preset signal sent by an external device connected to the embedded device. There are many ways to implement the setting circuit, which are not limited in this embodiment. The brick rescue register setting can refer to setting the original 0 to 1, or setting the original 1 to 0, or other forms of setting, which are not limited in this embodiment. The external device can be a PC end, a headphone box and other devices, which are not limited in this embodiment, and the connection method between the external device and the embedded device is not limited. For example, when the embedded device is a headphone device, the headphone box can be connected through the PC end to send a preset signal to the headphone box, and the headphone box sends the preset signal to the headphone device through the contacts between the headphone device and the headphone device. The preset signal can be set as needed, for example, set to a special waveform signal.

[0078] When the boot and start area is running, the embedded device detects whether the brick recovery trigger condition is met. Specifically, the embedded device may detect whether a brick recovery register is set by running a program in the boot and start area, for example, detecting whether the brick recovery register, which was originally set to 0, is set to 1. If the brick recovery register is detected to be set, it can be determined that the brick recovery trigger condition is met. Furthermore, if the embedded device detects that the brick recovery register is not set, for example, detecting that the brick recovery register, which was originally set to 0, is not set to 1, it can be determined that the brick recovery trigger condition is not met, or further detection can be performed to determine whether other brick recovery trigger conditions are met.

[0079] It should be noted that when a user is trying to recover a brick on an embedded device, when a preset signal is sent to the embedded device through an external device, the embedded device may not be running in the boot and start area. By setting a brick recovery register and a set circuit, the set circuit sets the brick recovery register when the preset signal is detected. After the embedded device is restarted and enters the boot and start area, whether to execute the brick recovery process is determined based on whether the brick recovery register is set or not. This allows the user to trigger the embedded device to enter the brick recovery process through an external device when running any program on the embedded device, thereby improving the success rate of brick recovery and reducing the complexity of the user's brick recovery operation.

[0080] Furthermore, in one embodiment, step S10 includes:

[0081] Step S103: After the embedded device is powered on, the boot area in the storage area is entered to perform data integrity check on the inherent firmware stored in the firmware running area. If the check fails, it is determined that the trigger condition for brick recovery is met.

[0082] In this embodiment, the brick rescue trigger condition can be set to fail when the data integrity check of the inherent firmware stored in the firmware running area fails. When the embedded device is running in the boot and start area, it detects whether the brick rescue trigger condition is met. Specifically, it can be performed by running a program in the boot and start area to perform a data integrity check on the inherent firmware stored in the firmware running area. The data integrity check is to check whether the data of the inherent firmware is complete. The specific verification operation can be set as needed and is not limited in this embodiment. For example, when the inherent firmware is stored, in addition to storing the data of the firmware itself, the firmware data length, CRC check value, MD5 (Message-Digest Algorithm) check value, etc. are also stored. The data integrity check may include but is not limited to the verification of the data length, CRC check value, and MD5 check value. It is understandable that when an exception occurs during the firmware upgrade process, the data of the upgraded inherent firmware in the firmware running area may be incomplete. If the data of the inherent firmware is incomplete, the firmware will not run normally, and may become bricked. If the data integrity check of the inherent firmware in the firmware running area fails, it can be determined that the brick rescue trigger condition is met. Furthermore, if the data integrity check of the inherent firmware in the firmware running area passes, it can be determined that the brick recovery triggering condition is not met, or further detection can be performed to determine whether other brick recovery triggering conditions are met.

[0083] Step S20, when it is determined that the brick recovery trigger condition is met, running the brick recovery firmware stored in the brick recovery firmware area to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware;

[0084] When the embedded device is running in the boot area and determines that the recovery trigger conditions are met, it can jump to running the recovery firmware stored in the recovery firmware area. The recovery firmware has a firmware upgrade function, which can be used to download a new version of the native firmware to the flash firmware backup area. It is understandable that since the native firmware cannot operate normally, the recovery firmware in this embodiment is used to implement the function of downloading the new version of the native firmware, thereby helping the embedded device complete the flash and restore normal operation.

[0085] In a specific embodiment, the brick recovery firmware can be pre-burned into the brick recovery firmware area, that is, burned when the embedded device is manufactured. Alternatively, the embedded device can receive the brick recovery firmware from an external device connected to the embedded device during operation and then store the brick recovery firmware in the brick recovery firmware area. Pre-burned brick recovery firmware is more reliable than brick recovery firmware received from an external device. By storing the brick recovery firmware after receiving it from an external device, the version of the brick recovery firmware can be updated more flexibly than pre-burning the brick recovery firmware.

[0086] Furthermore, after the new version of the inherent firmware is stored in the flash firmware backup area by running the brick recovery firmware, the embedded device can automatically restart by running the brick recovery firmware, or wait for manual restart, which is not limited here.

[0087] Step S30: When it is determined that the trigger condition for recovering the brick is not met, if it is detected that a new version of the inherent firmware is stored in the flash firmware backup area, the new version of the inherent firmware is used to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area, and then jump to the firmware running area for execution.

[0088] When the embedded device is running in the boot and start area and it is determined that the rescue triggering condition is not met, it is further detected whether the new version of the inherent firmware is stored in the flashing firmware backup area. That is, the version of the inherent firmware stored in the flashing firmware backup area is compared with the version of the inherent firmware stored in the firmware running area to determine whether the version of the inherent firmware stored in the flashing firmware backup area is newer than the version of the inherent firmware stored in the firmware running area. If so, it is determined that a new version of the inherent firmware is stored. If not, it is determined that a new version of the inherent firmware is not stored, that is, no flashing is performed. If it is determined that a new version of the inherent firmware is stored in the flashing firmware backup area, the embedded device runs the program in the boot and start area, uses the new version of the inherent firmware to overwrite the old version of the inherent firmware in the firmware running area, and then jumps to the firmware running area to run, thereby completing the flashing.

[0089] Furthermore, in one embodiment, when the brick recovery trigger condition is detecting that the brick recovery register is set, the embedded device can restore the brick recovery register after running the brick recovery firmware to store the new version of the inherent firmware in the flash firmware backup area, so that when the embedded device restarts and enters the boot startup area to run, it will not enter the brick recovery process again, but enter the normal boot process, that is, detect whether the flash firmware backup area stores the new version of the inherent firmware.

[0090] In this embodiment, a brick recovery firmware area is set in the storage area of ​​the embedded device. After the embedded device is powered on, the boot and start area in the storage area is entered to run to detect whether the brick recovery triggering condition is met; when it is determined that the brick recovery triggering condition is met, the brick recovery firmware stored in the brick recovery firmware area is run to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware; when it is determined that the brick recovery triggering condition is not met, if it is detected that the flash firmware backup area stores a new version of the inherent firmware, the new version of the inherent firmware is used to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area, and then jump to the firmware running area to run. This embodiment implements a brick recovery solution for abnormal device flashing, so that when the embedded device flashes abnormally, the device can be restored to normal by executing the brick recovery process, without the need to disassemble the device for repair, thereby reducing the scrap rate of embedded devices.

[0091] Furthermore, based on the above-mentioned first embodiment, a second embodiment of the method for recovering a brick due to abnormal flashing of a device of the present invention is proposed. In this embodiment, the recovering brick firmware is obtained by trimming the functions other than the firmware upgrade function in the inherent firmware and retaining the firmware upgrade function.

[0092] For some smaller embedded devices, their storage capacity may be limited. In order to minimize the storage capacity occupied by the brick recovery firmware, in this embodiment, the brick recovery firmware can be formed by trimming the functions of the inherent firmware except the firmware upgrade function, retaining only the firmware upgrade function, and the retained part is used as the brick recovery firmware.

[0093] Furthermore, in one embodiment, step S20 includes:

[0094] Step S201: When it is determined that the brick recovery triggering condition is met, the compressed brick recovery firmware stored in the brick recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area;

[0095] Step S202, decompress the compressed brick-saving firmware in the firmware running area to obtain the decompressed brick-saving firmware, and jump to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

[0096] In order to reduce the storage occupation of embedded devices, the brick rescue firmware stored in the brick rescue firmware area can be compressed by a compression algorithm, hereinafter referred to as compressed brick rescue firmware for distinction. When the embedded device is running in the boot startup area and it is determined that the brick rescue trigger condition is met, it can further run in the boot startup area to use the compressed brick rescue firmware stored in the brick rescue firmware area to overwrite the old version of the inherent firmware in the firmware running area, and then decompress the compressed brick rescue firmware in the firmware running area, and the decompressed brick rescue firmware is called decompressed brick rescue firmware for distinction. It can be understood that the decompressed brick rescue firmware is also stored in the firmware running area. After decompression, jump from the boot startup area to the firmware running area to run, that is, run the decompressed brick rescue firmware, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area through the firmware upgrade function of running the decompressed brick rescue firmware.

[0097] Furthermore, in one embodiment, before the step of using the compressed recovery firmware stored in the recovery firmware area to overwrite the old version of the native firmware in the firmware running area in step S201, the method further includes:

[0098] Step S203, calculating the first MD5 checksum of the compressed brick-saving firmware stored in the brick-saving firmware area;

[0099] To ensure the reliability of using the recovery firmware for recovery, when the embedded device is running the boot startup area, before using the compressed recovery firmware to overwrite the old version of the inherent firmware in the firmware running area, it can first calculate the MD5 check value (hereinafter referred to as the first MD5 check value) of the compressed recovery firmware stored in the recovery firmware area.

[0100] It should be noted that the operation of calculating the first MD5 checksum may be, but is not limited to, after it is detected that the brick rescue trigger condition is met.

[0101] Step S204, comparing the first MD5 checksum with the second MD5 checksum stored in the brick-recovery firmware area;

[0102] In addition to storing the data of the compressed brick-saving firmware, the brick-saving firmware area can also store the MD5 check value of the compressed brick-saving firmware (hereinafter referred to as the second MD5 check value). The second MD5 check value is calculated when the compressed brick-saving firmware is correct.

[0103] The embedded device compares the first MD5 check value with the second MD5 check value to determine whether the compressed brick recovery firmware stored in the brick recovery firmware area is changed.

[0104] Step S205: If the first MD5 checksum is consistent with the second MD5 checksum, then execute the step of using the compressed recovery firmware stored in the recovery firmware area to overwrite the old version of the inherent firmware in the firmware running area in step S201.

[0105] If the first MD5 checksum is consistent with the second MD5 checksum, it means that the compressed brick recovery firmware has not changed and can run normally. At this time, the embedded device can use the compressed brick recovery firmware stored in the brick recovery firmware area to overwrite the old version of the inherent firmware in the firmware running area, and then complete the subsequent brick recovery process.

[0106] If the first MD5 checksum is inconsistent with the second MD5 checksum, it means that the compressed firmware may be changed and cannot run normally, and the normal firmware upgrade function cannot be performed. At this time, the embedded device does not need to process it.

[0107] Furthermore, in one embodiment, before the step of jumping to the firmware running area in step S202 to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick-saving firmware, the method further includes:

[0108] Step S206, verifying the data integrity of the decompressed firmware in the firmware running area;

[0109] Step S207, if the verification passes, then execute the step of jumping to the firmware running area in step S202 to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick-saving firmware.

[0110] Furthermore, in one embodiment, in order to ensure the reliability of using the brick rescue firmware to rescue the brick, the embedded device can run in the boot and start area, decompress the compressed brick rescue firmware in the firmware running area, and then verify the data integrity of the decompressed brick rescue firmware in the firmware running area. In this embodiment, there is no restriction on the specific method of data integrity verification, for example, it can include data length verification, CRC verification, etc. If the data integrity verification of the decompressed brick rescue firmware passes, it means that no data loss occurs in the process of transporting the compressed brick rescue firmware to the firmware running area and decompressing it, and the decompressed brick rescue firmware can operate normally. At this time, it is possible to jump from the boot and start area to the firmware running area to download the new version of the inherent firmware to the flash firmware backup area by running the firmware upgrade function of the decompressed brick rescue firmware.

[0111] Furthermore, in one embodiment, the storage format of the brick recovery firmware can refer to Figure 3 The file header version and the version number of the recovery firmware are used to identify the version of the recovery firmware; the length and CRC checksum of the recovery firmware are used to verify the data integrity of the recovery firmware after decompression; the compressed length of the recovery firmware is used to access the compressed data of the recovery firmware according to the length before decompression; and the compressed MD5 checksum of the recovery firmware is used to perform MD5 verification of the compressed recovery firmware.

[0112] Furthermore, in one embodiment, in order to ensure the reliability of the brick recovery function, the embedded device can perform MD5 verification and / or data integrity verification on the compressed brick recovery firmware or non-compressed brick recovery firmware stored in the brick recovery firmware area by running the firmware upgrade function of the inherent firmware before downloading the new version of the inherent firmware by running the firmware upgrade function of the inherent firmware, that is, before flashing the machine, so as to download the new version of the inherent firmware and restart the flashing process only when it is ensured that the brick recovery firmware can operate normally, so as to avoid abnormalities in the flashing process and the inability to recover the brick when the brick recovery firmware is also abnormal, resulting in the device being scrapped, that is, further reducing the equipment scrapping rate.

[0113] In addition, the embodiment of the present invention also proposes a device for recovering bricks when the device is abnormally flashed. The device is deployed in an embedded device, and a recovery firmware area is set in the storage area of ​​the embedded device. Figure 4 , the device flash abnormal recovery device includes:

[0114] The detection module 10 is used to enter the boot area in the storage area after the embedded device is powered on to detect whether the trigger condition for retrieving the brick is met;

[0115] The brick recovery module 20 is configured to, when it is determined that a brick recovery trigger condition is met, run the brick recovery firmware stored in the brick recovery firmware area to download a new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware;

[0116] The upgrade module 30 is used to, when it is determined that the rescue trigger condition is not met, if it is detected that a new version of the inherent firmware is stored in the flash firmware backup area, use the new version of the inherent firmware to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area, and then jump to the firmware running area to run.

[0117] Furthermore, the detection module 10 is further configured to:

[0118] After the embedded device is powered on, it enters the boot area in the storage area to run to detect whether a brick recovery indication message sent by an external device connected to the embedded device is received. If the brick recovery indication message sent by the external device connected to the embedded device is detected, it is determined that the brick recovery trigger condition is met; or

[0119] After the embedded device is powered on, the boot area in the storage area is entered to run to detect whether a brick recovery register set in the embedded device is set. If it is detected that the brick recovery register is set, it is determined that the brick recovery trigger condition is met, wherein a setting circuit set in the embedded device sets the brick recovery register when receiving a preset signal sent by an external device electrically connected to the embedded device; or

[0120] After the embedded device is powered on, it enters the boot area in the storage area to run a data integrity check on the inherent firmware stored in the firmware running area. If the check fails, it is determined that the brick recovery trigger condition is met.

[0121] Furthermore, the brick recovery firmware is obtained by cutting out functions other than the firmware upgrade function in the inherent firmware and retaining the firmware upgrade function.

[0122] Furthermore, the brick rescue module 20 is also used to:

[0123] When it is determined that the brick recovery triggering condition is met, the compressed brick recovery firmware stored in the brick recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area;

[0124] Decompress the compressed brick-saving firmware in the firmware running area to obtain the decompressed brick-saving firmware, and jump to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

[0125] Furthermore, the brick rescue module 20 is also used to:

[0126] Calculate the first MD5 checksum of the compressed brick recovery firmware stored in the brick recovery firmware area;

[0127] Compare the first MD5 checksum with the second MD5 checksum stored in the recovery firmware area;

[0128] If the first MD5 checksum is consistent with the second MD5 checksum, the compressed recovery firmware stored in the recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area.

[0129] Furthermore, the brick rescue module 20 is also used to:

[0130] Verify the data integrity of the decompressed recovery firmware in the firmware running area;

[0131] If the verification is passed, the execution jumps to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick-saving firmware.

[0132] Furthermore, the brick recovery firmware is pre-burned in the brick recovery firmware area; or,

[0133] After receiving the brick recovery firmware sent by the external device connected to the embedded device during operation, the embedded device stores the brick recovery firmware in the brick recovery firmware area.

[0134] The various embodiments of the device for retrieving bricks when the device is flashing abnormally of the present invention can refer to the various embodiments of the method for retrieving bricks when the device is flashing abnormally of the present invention, and will not be described in detail here.

[0135] In addition, an embodiment of the present invention further proposes a computer-readable storage medium, which stores a device brick recovery program for abnormal flashing. When the device brick recovery program for abnormal flashing is executed by a processor, the following steps of a device brick recovery method for abnormal flashing are implemented.

[0136] The various embodiments of the device for recovering a brick when the device is flashing abnormally and the computer-readable storage medium of the present invention can all refer to the various embodiments of the method for recovering a brick when the device is flashing abnormally of the present invention, and will not be repeated here.

[0137] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0138] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0139] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better embodiment. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of various embodiments of the present invention.

[0140] The above are only preferred embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention description and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for recovering a bricked device due to abnormal flashing, characterized in that: The method is applied to an embedded device, wherein a brick recovery firmware area is set in a storage area of ​​the embedded device, and the method comprises the following steps: After the embedded device is powered on, the system enters the boot area in the storage area to run and detect whether a trigger condition for recovering a brick is met; When it is determined that the brick recovery trigger condition is met, running the brick recovery firmware stored in the brick recovery firmware area to download a new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware; When it is determined that the rescue trigger condition is not met, if it is detected that a new version of the inherent firmware is stored in the flash firmware backup area, the new version of the inherent firmware is used to overwrite the old version of the inherent firmware stored in the firmware running area in the storage area, and then jump to the firmware running area for execution; When it is determined that the brick recovery trigger condition is met, the step of running the brick recovery firmware stored in the brick recovery firmware area to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware includes: When it is determined that the brick recovery trigger condition is met, the compressed brick recovery firmware stored in the brick recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area; The compressed brick-saving firmware in the firmware running area is decompressed to obtain the decompressed brick-saving firmware, and the firmware is jumped to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

2. The method for recovering a bricked device due to abnormal flashing as claimed in claim 1, characterized in that: After the embedded device is powered on, the step of entering the boot area in the storage area to run and detecting whether a trigger condition for recovering a brick is met includes: After the embedded device is powered on, the boot area in the storage area is entered to run to detect whether a brick rescue indication message sent by an external device connected to the embedded device is received, and if the brick rescue indication message sent by the external device connected to the embedded device is detected, it is determined that the brick rescue triggering condition is met; or After the embedded device is powered on, the boot area in the storage area is entered to run to detect whether a brick recovery register set in the embedded device is set. If it is detected that the brick recovery register is set, it is determined that the brick recovery trigger condition is met, wherein a setting circuit set in the embedded device sets the brick recovery register when receiving a preset signal sent by an external device electrically connected to the embedded device; or After the embedded device is powered on, it enters the boot area in the storage area to run a data integrity check on the inherent firmware stored in the firmware running area. If the check fails, it is determined that the brick recovery trigger condition is met.

3. The method for recovering a bricked device due to abnormal flashing as claimed in claim 1, characterized in that: The brick recovery firmware is obtained by cutting out functions other than the firmware upgrade function in the inherent firmware and retaining the firmware upgrade function.

4. The method for recovering a bricked device due to abnormal flashing as claimed in claim 1, characterized in that: Before the step of using the compressed brick recovery firmware stored in the brick recovery firmware area to overwrite the old version of the inherent firmware in the firmware running area, the method further includes: Calculating a first MD5 checksum of a compressed brick-saving firmware, wherein the compressed brick-saving firmware is stored in the brick-saving firmware area; Comparing the first MD5 checksum with a second MD5 checksum stored in the brick recovery firmware area, wherein the second MD5 checksum is calculated when the compressed brick recovery firmware is correct; If the first MD5 checksum is consistent with the second MD5 checksum, the step of using the compressed brick-saving firmware stored in the brick-saving firmware area to overwrite the old version of the inherent firmware in the firmware running area is performed.

5. The method for recovering a bricked device due to abnormal flashing as claimed in claim 1, characterized in that: Before the step of jumping to the firmware running area to run and downloading the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware, the method further includes: Verify the data integrity of the decompressed brick-recovery firmware in the firmware running area; If the verification is passed, the step of jumping to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

6. The method for recovering a device from a brick due to abnormal flashing of the device according to any one of claims 1 to 5, characterized in that: The brick recovery firmware is pre-burned into the brick recovery firmware area; or, After receiving the brick recovery firmware sent by an external device connected to the embedded device during operation, the embedded device stores the brick recovery firmware in the brick recovery firmware area.

7. A device for recovering bricks when the device is abnormally flashed, characterized in that: The apparatus is deployed in an embedded device, and a brick recovery firmware area is set in a storage area of ​​the embedded device. The apparatus includes: A detection module is configured to enter the boot area in the storage area after the embedded device is powered on to detect whether a brick recovery trigger condition is met; a brick recovery module, configured to, when determining that the brick recovery trigger condition is met, run the brick recovery firmware stored in the brick recovery firmware area, so as to download a new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the brick recovery firmware; An upgrade module is configured to, when it is determined that the rescue trigger condition is not met, overwrite the old version of the inherent firmware stored in the firmware running area in the storage area with the new version of the inherent firmware if it is detected that the new version of the inherent firmware is stored in the firmware backup area of ​​the storage area, and then jump to the firmware running area for execution; The brick rescue module is also used to: When it is determined that the brick recovery triggering condition is met, the compressed brick recovery firmware stored in the brick recovery firmware area is used to overwrite the old version of the inherent firmware in the firmware running area; Decompress the compressed brick-saving firmware in the firmware running area to obtain the decompressed brick-saving firmware, and jump to the firmware running area to run, so as to download the new version of the inherent firmware to the flash firmware backup area in the storage area by running the firmware upgrade function of the decompressed brick-saving firmware.

8. A device for recovering bricks caused by abnormal flashing of the device, characterized in that: The device for recovering a brick due to an abnormal flashing of the device comprises: a memory, a processor, and a device recovering a brick due to an abnormal flashing of the device stored in the memory and runnable on the processor. When the device recovering a brick due to an abnormal flashing of the device is executed by the processor, the steps of the device recovering a brick due to an abnormal flashing of the device are implemented according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a device bricking recovery program when the device is abnormally flashed. When the device bricking recovery program is executed by the processor, the steps of the device bricking recovery method when the device is abnormally flashed are implemented as described in any one of claims 1 to 6.

Images