Firmware starting method and device of terminal

Abstract

The embodiment of the invention provides a firmware starting method and device of a terminal. A storage space of the terminal comprises three storage areas, one storage area is used for storing factory burning versions of firmware, and the other two storage areas are respectively used for storing other two different versions of the firmware. The method comprises the following steps: acquiring a count value of continuous startup failure times of firmware under a third version, wherein the third version is a version adopted when the firmware is started last time; and determining the starting version of the firmware and the starting time delay of the firmware according to the count value. The embodiment of the invention can be applied to agricultural machinery, can reasonably recover the application of the firmware when the terminal starts the firmware to have a fault, and can be suitable for different scenes.

Description

Technical Field

[0001] The present application relates to the field of terminal fault recovery, and more specifically, to a method and device for starting terminal firmware. Background Art

[0002] Terminal firmware refers to the software stored in the terminal's internal storage space. While software itself is inherently software, it is often referred to as firmware because it is embedded in the terminal's non-volatile memory. For example, in the case of agricultural machinery, firmware upgrades can fix bugs or add functionality.

[0003] However, after the upgrade, the firmware may fail to start due to an upgrade failure or due to environmental factors. In view of this, how to reasonably restore the application of the firmware becomes a problem that needs to be solved. Summary of the Invention

[0004] The present application provides a terminal firmware startup method and device, which can reasonably restore the application of the firmware when a fault occurs in the terminal startup firmware, and can be applied to different scenarios.

[0005] In a first aspect, a method for booting firmware of a terminal is provided. The terminal's storage space includes a first storage area, a second storage area, and a third storage area. The first storage area is used to store a first version of the firmware, the second storage area is used to store a second version of the firmware, and the third storage area is used to store a factory-burned version of the firmware.

[0006] The method includes: obtaining a count value of consecutive startup failures of the firmware under a third version, where the third version is the version used when the firmware was last started; and determining the startup version of the firmware and the startup delay of the firmware based on the count value.

[0007] Determining the startup version of the firmware and the startup delay of the firmware based on the count value includes: when the count value is less than or equal to a first threshold, determining the third version as the startup version and determining the startup delay according to a first delay method; when the count value is greater than the first threshold and less than a second threshold, determining the third version as the startup version and determining the startup delay according to a second delay method; or, when the count value is greater than or equal to the second threshold, rolling back the startup version from the third version to a previous version of the third version stored in a storage space and determining the startup delay according to the first delay method. The third version is one of the first and second versions, the previous version is the other of the first and second versions, or the previous version is a factory-programmed version; and the startup delay determined according to the second delay method is greater than the startup delay determined according to the first delay method.

[0008] In this application, the version and delay used for this firmware startup are determined based on the number of consecutive startup failures of the version used to start the firmware last time. In the case of continuous restarts due to firmware startup failure, by controlling the startup delay, on the one hand, for occasional startup failures caused by environmental factors, when the environmental factors return to normal, the firmware can resume operation on its own, which can avoid erroneously attributing the failure to the firmware version failure and avoid the wrong rollback of the firmware version. On the other hand, for the inevitable startup failure caused by the firmware version failure, the normal operation of the terminal can be achieved by rolling back the firmware version. In this way, it can adapt to the usage requirements in different scenarios.

[0009] In some possible implementations, determining the startup delay according to the first delay mode may include: determining a basic delay as the startup delay.

[0010] In some possible implementations, determining the startup delay according to the second delay mode may include: determining the startup delay according to a count value, a basic delay, and a delay tolerance.

[0011] In some possible implementations, the basic delay may be zero.

[0012] In some possible implementations, the storage area for storing the third version may correspond to the first index, and the storage area for storing the previous version may correspond to the second index; the firmware's running program may be used to start the firmware based on the startup index. Determining the third version as the startup version may include: determining the first index as the startup index. Alternatively, rolling back the startup version from the third version to a version previous to the third version stored in the storage space may include: changing the startup index from the first index to the second index.

[0013] In some possible implementations, the storage space may not store the second version; the third version may be the first version, and the previous version of the third version stored in the storage space may be a factory-burned version.

[0014] In some possible implementations, the storage space may store a first version, a second version, and a factory-burned version; the third version is the first version, and the previous version of the third version stored in the storage space may be the second version.

[0015] In some possible implementations, the method may further include: obtaining a version of the firmware to be written; and when the firmware successfully boots with the boot version, storing the version to be written in a target storage area. The target storage area may be the first storage area or the second storage area, and the boot version is not stored in the target storage area.

[0016] In some possible implementations, the method may further include: when the firmware is successfully started with the third version, clearing the count value of the number of consecutive startup failures under the third version.

[0017] In a second aspect, a device is provided. The device may include a module or unit for implementing the method in the first aspect and any possible implementation manner thereof.

[0018] Exemplarily, the apparatus may include an acquisition unit and a processing unit. The acquisition unit may be configured to: acquire a count value of consecutive startup failures of the firmware under the third version; and the processing unit may be configured to: determine the startup version of the firmware and the startup delay of the firmware based on the count value.

[0019] For descriptions of the firmware's startup version, startup delay, third version, etc., please refer to the relevant records of the first aspect above.

[0020] In a third aspect, a device is provided. The device includes at least one processor coupled to at least one memory, the at least one memory being configured to store a computer program or instructions. The at least one processor is configured to retrieve and execute the computer program or instructions from the at least one memory, causing the device to perform the method of the first aspect and any possible implementation thereof.

[0021] In a fourth aspect, a terminal is provided. The terminal includes the apparatus according to the third aspect and any possible implementation thereof. For example, the terminal may be a terminal installed on an unmanned agricultural machine. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 is a schematic diagram of a storage space of a terminal provided in an embodiment of the present application;

[0023] Figure 2 This is a schematic flow chart of a method for starting firmware of a terminal provided in an embodiment of the present application;

[0024] Figure 3 This is a functional block diagram of a terminal provided in an embodiment of the present application;

[0025] Figure 4 is a schematic diagram of a device provided in an embodiment of the present application;

[0026] Figure 5 It is a schematic diagram of another device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a way to describe the association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0028] In the embodiments of the present application, prefixes such as "first" and "second" are used only to distinguish different description objects and have no limiting effect on the position, order, priority, quantity or content of the described objects. The use of prefixes such as ordinal numbers to distinguish description objects in the embodiments of the present application does not constitute a restriction on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and the use of such prefixes should not constitute an unnecessary restriction. In addition, in the description of this embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

[0029] The technical solution in this application will be described below with reference to the accompanying drawings.

[0030] For example, Figure 1 This is a schematic diagram of a storage space of a terminal provided by an embodiment of the present application. Figure 1 As shown, the storage space 100 may include a storage area 110, a storage area 120, and a storage area 130. For example, the terminal may be a terminal provided on an agricultural machine (such as a terminal of an unmanned agricultural machine).

[0031] Exemplarily, the storage area 110 may be used to store a certain version of the firmware, the storage area 120 may be used to store another version of the firmware, and the storage area 130 may be used to store a factory-burned version of the firmware.

[0032] It is understandable that at certain moments, the storage space 100 may only store one or two versions of the firmware, and some of the storage areas 110 to 130 may not store any version of the firmware. For example, when the terminal is just shipped, the storage space 100 may only store the factory-burned version; although the storage area 110 and the storage area 120 are used to store other versions of the firmware besides the factory-burned version, since the terminal has not obtained any versions other than the factory-burned version at this time, the storage area 110 and the storage area 120 may not store any version of the firmware at this time. For another example, after the firmware is upgraded for the first time, the storage space 100 may store the first upgraded version and the factory-burned version; at this time, one of the storage area 110 and the storage area 120 may store the first upgraded version, while the other of the two may not store any version of the firmware.

[0033] Illustratively, when the firmware is upgraded, the version to be written is stored in the storage area 110 and the storage area 120 in turn.

[0034] Assume that the factory-programmed version is version #0, and the firmware is subsequently upgraded to version #n (n is a positive integer). The descriptions of versions #0 to #n are unified here and will not be repeated later.

[0035] Exemplarily, after the firmware is upgraded, at least two versions of the firmware may be stored in the storage space 100 .

[0036] For example, during the first upgrade, version #1 can be stored in the storage area 110; during the second upgrade, version #2 can be stored in the storage area 120; during the third upgrade, version #3 can be stored in the storage area 110; during the fourth upgrade, version #4 can be stored in the storage area 120; and so on, the firmware version can be upgraded to version #n.

[0037] In some embodiments, the upgrade to version #n may be performed in the opposite manner to the above. For example, during the first upgrade, version #1 may be stored in storage area 120, and during the second upgrade, version #2 may be written to storage area 110, and so on.

[0038] In some other embodiments, to save space occupied by the firmware in the storage area, some versions of the firmware may be erased. For example, during the third upgrade, version #1 in storage area 110 may be erased, and version #3 may be stored in storage area 110; during the fourth upgrade, version #2 in storage area 120 may be erased, and version #4 may be stored in storage area 120.

[0039] After a firmware upgrade, the upgraded firmware may fail to boot. On the one hand, a failed firmware upgrade may prevent the upgraded firmware from booting. On the other hand, even if the firmware upgrade is successful, changes in the terminal's environment before and after the upgrade may also prevent the upgraded firmware from booting. For example, after the upgrade, if the terminal experiences voltage instability due to environmental factors, even the successfully upgraded firmware may fail to boot in this scenario. For another example, some firmware upgrades require users to adjust the terminal's internal communication lines. After the upgrade, if the user reverses some of the connections when restoring these lines, the firmware may still fail to boot even if the upgrade was successful. However, firmware boot failures caused by environmental factors may be mistakenly identified as a malfunction caused by the firmware upgrade. Improper version rollbacks will require subsequent firmware upgrades, resulting in significant wasted work.

[0040] In view of this, the embodiments of the present application provide a method and apparatus for starting firmware of a terminal, which can reasonably restore the application of the firmware when a fault occurs in the terminal and can be applied to different scenarios.

[0041] For example, Figure 2 This is a schematic flow chart of a method for starting the firmware of a terminal provided in an embodiment of the present application. Figure 2 As shown, the method 200 may include:

[0042] S210: Obtain a count value of consecutive startup failures of the firmware in a third version, where the third version is the version used when the firmware was last started.

[0043] The storage space of the terminal may include a first storage area, a second storage area and a third storage area; the first storage area may be used to store the first version of the firmware, the second storage area may be used to store the second version of the firmware, and the third storage area may be used to store the factory-burned version of the firmware.

[0044] The first version may be any version other than the factory-programmed version, and the second version may be any version different from the factory-programmed version and the first version.

[0045] For example, Figure 1 Taking the storage space 100 shown as an example, the first storage area may be one of the storage areas 110 and 120, the second storage area may be the other of the storage areas 110 and 120, and the storage area 130 may correspond to the third storage area.

[0046] Exemplarily, the third version may be one of the first version and the second version; the previous version of the third version stored in the storage space may be the other of the first version and the second version, or the third version may be a factory-burned version.

[0047] In some possible implementations, the method may further include: when the firmware is successfully started with the third version, clearing the count value to zero.

[0048] In some embodiments, a counter A can be set, and the count of consecutive startup failures can be determined based on the value of counter A. For example, taking version #2 as an example, when version #2 fails to start, the value of counter A can be increased by 1; when version #2 successfully starts, the value of counter A can be cleared. Thus, based on the value of counter A, the number of consecutive startup failures of version #2 can be determined.

[0049] S220: Determine the startup version of the firmware and the startup delay of the firmware according to the count value.

[0050] The startup delay can be understood as: for two adjacent startup processes, if the previous startup process fails, the delay between the end time of the previous startup process and the start time of the next startup process.

[0051] Exemplarily, determining the startup version of the firmware and the startup delay of the firmware based on the count value may include: when the count value is less than or equal to the first threshold, determining the third version as the startup version, and determining the startup delay according to the first delay method; when the count value is greater than the first threshold and less than the second threshold, determining the third version as the startup version, and determining the startup delay according to the second delay method; or, when the count value is greater than or equal to the second threshold, rolling back the startup version from the third version to the previous version of the third version in the storage space, and determining the startup delay according to the first delay method.

[0052] In some possible implementations, for the firmware, there may be multiple versions between the previous version of the third version stored in the storage space and the third version that are not stored in the storage space.

[0053] Assume that storage area 120 stores version #4, storage area 110 stores version #3, and storage area 130 stores version #0; versions #1 and #2 between version #3 and version #0 have been partially or completely erased from the storage space.

[0054] In one embodiment, when version #4 corresponds to the third version, version #3 may correspond to the previous version of the third version stored in the storage space; the startup version may roll back from version #4 to version #3.

[0055] In another embodiment, when the boot version is further rolled back from version #3, since versions #1 and #2 have been erased from the storage space, the firmware will roll back from version #3 to version #0. In this scenario, version #3 may correspond to the third version, and version #0 may correspond to the previous version of the third version stored in storage space 100.

[0056] The first threshold value can be any value, such as 30, 32, 35, 40, etc. The second threshold value can be any value greater than the first threshold value, such as 10,000, 20,000, 60,000, etc. That is, when booting a certain version of firmware, when the number of consecutive boot failures is small, the first delay method can be used to determine the boot delay, and the firmware of this version can be booted based on the boot delay; further, when the number of consecutive boot failures is large but still less than the second threshold value, the second delay method can be used to determine the boot delay, and the firmware of this version can be booted based on the boot delay; further, when the number of consecutive boot failures reaches the second threshold value, the boot delay can be determined based on the first delay method, and the firmware of the previous version of this version can be booted based on the boot delay.

[0057] The startup delay determined by the second delay mode can be longer than the startup delay determined by the first delay mode. For example, the startup delay determined by the first delay mode can be 5 seconds (s), while the startup delay determined by the second delay mode can be 10s, 20s, etc.

[0058] In actual scenarios, startup failures caused by environmental factors are often sporadic; however, failures caused by the lack of version-related information (such as those caused by upgrades) are unrelated to environmental factors and are inevitable. For example, if the firmware upgrade is successful, although unstable power supply voltage will cause the firmware to fail to start; however, the unstable power supply voltage often lasts for a short time and will recover after a period of time. For example, in the case of firmware startup failure caused by incorrect wiring, users can troubleshoot the related faults in a relatively short time.

[0059] In an embodiment of the present application, the version and delay used for this firmware startup are determined based on the number of consecutive startup failures of the version used to start the firmware last time. In the case of continuous restarts due to firmware startup failure, on the one hand, for occasional startup failures caused by environmental factors, the startup delay is controlled so that the firmware can survive the failure period of the environmental factors. When the environmental factors return to normal, the firmware can resume operation on its own, which can avoid erroneously attributing the failure to the firmware version failure and avoid the wrong rollback of the firmware version. On the other hand, for the inevitable failure caused by the firmware version, the normal operation of the terminal can be achieved by rolling back the firmware version. In this way, it can adapt to the usage requirements in different scenarios.

[0060] In some possible implementations, determining the startup delay according to the first delay mode may include: determining a basic delay as the startup delay. For example, the basic delay may be 0s, 1s, 2s, etc.

[0061] In some possible implementations, determining the startup delay according to the second delay mode may include determining the startup delay according to the count value, the basic delay, and a delay tolerance. For example, the delay tolerance may be 8s, 10s, 12s, etc.

[0062] Assume the first threshold is 30, the base latency is 0s, and the latency tolerance is 5s. In a scenario where a version experiences consecutive restart failures, for the first 30 consecutive restart failures, the next restart will proceed directly after each failed restart. After the 30th consecutive restart failure, the startup delay increases by 5s for each additional restart, until the number of consecutive restart failures reaches the second threshold, triggering a version rollback.

[0063] For example, the firmware execution program can start the firmware according to the startup index. Different storage areas can correspond to different index values. When the startup index takes different index values, the firmware execution program will run different versions of the firmware.

[0064] In some possible implementations, the storage area for storing the third version may correspond to the first index, and the storage area for storing the previous version may correspond to the second index. Determining the third version as the startup version may include: determining the first index as the startup index. Determining the previous version as the startup version may include: determining the second index as the startup index.

[0065] In the embodiment of the present application, there is no need to migrate the running programs of the firmware between different storage areas. The startup version can be switched simply by switching the value of the startup index, which can improve the efficiency and reliability of firmware upgrades and firmware rollbacks.

[0066] In some possible implementations, the terminal's storage space may not store the second version of the firmware, the third version may be the first version, and the version preceding the third version stored in the storage space may be the factory-burned version. For example, if the firmware has only been upgraded for the first time, only two versions may be stored in the storage area; if version #1 after the initial upgrade fails to restart continuously, version #1 may correspond to the third version, and the version preceding the third version stored in the storage space may be version #0, which was burned into the factory.

[0067] In some possible implementations, the terminal's storage space may store a first version, a second version, and a factory-burned version. The third version may be the first version, and the previous version of the third version stored in the storage space may be the second version. For example, if the firmware has been upgraded multiple times, it may be possible to roll back between the two versions stored in the first storage area and the second storage area; if the versions stored in both storage areas are unusable, the firmware may roll back to the factory-burned version.

[0068] In some possible implementations, the method may further include: obtaining a version of the firmware to be written; and when the firmware successfully boots with the boot version, storing the version to be written in a target storage area. The target storage area may be the first storage area or the second storage area, and the boot version is not stored in the target storage area.

[0069] Combination of the above Figure 2 The method provided in the embodiment of the present application is exemplified. Figure 3 This method is further explained.

[0070] For example, Figure 3 This is a functional block diagram of a terminal provided in an embodiment of the present application.

[0071] like Figure 3 As shown, the storage area of ​​the terminal 300 includes area A, area B and factory area. In the process of firmware upgrade, the version to be updated can be written into area A and area B in turn. The factory area is used to store the factory-burned version of the firmware; the factory area cannot be erased. For example, version #0 is stored in the factory area; when the firmware is updated for the first time, version #1 can be written into area A; when the firmware is updated for the second time, version #2 can be written into area B; when the firmware is updated for the third time, version #1 in area A can be erased, and version #3 can be written into area A; and so on. For another example, restrictions on writing and / or erasing can be added to the factory area, so that the user is not allowed to write to and erase the factory area by himself after the terminal leaves the factory; that is, for the user, the factory area can be a non-writable storage area. The above-mentioned area A, area B and factory area can correspond to Figure 1 Storage areas 110, 120 and 130 in.

[0072] During power-on, a counter is started in the boot process, which is incremented by 1 each time the system boots. After a successful boot, the corresponding program can reset the counter to 0. This allows you to calculate the number of consecutive boot failures for a particular version.

[0073] The terminal 300 may boot the firmware based on the boot index, which may indicate which version of the firmware to boot from, among the A zone, the B zone, or the factory zone.

[0074] For example, if the boot index of this boot indicates area A, the version stored in area A will be used for this boot; when a version rollback is triggered, BOOT can determine whether the version stored in area B is complete. If the version stored in area B is complete, BOOT can roll back the boot version to the version stored in area B by adjusting the boot index and erase the version stored in area A. Furthermore, when a version rollback is triggered again, since the version stored in area A has been erased by the previous version rollback, the boot version can be rolled back to the factory burned version.

[0075] For example, a version rollback can be triggered when any version fails to boot 60,000 times in a row. Furthermore, for the first 32 consecutive boot failures of a version, the next boot process will begin immediately after the current boot process completes; in other words, the base delay is 0. After a version fails to boot 32 times in a row, the boot delay increases by 10 seconds for each additional reboot. Therefore, in the case of consecutive boot failures, the cumulative time from the first boot failure to the 60,000th boot failure can reach approximately 24 hours. Failures caused by environmental factors can generally be resolved within 24 hours, thus avoiding accidental version rollbacks. However, if the boot delay is not increased after a version fails to boot 32 times in a row, the number of consecutive boot failures will reach 60,000 in a very short period of time. If the environmental failure persists for a long time, an accidental version rollback may occur.

[0076] Combination of the above Figures 1 to 3 The method provided by the embodiment of the present application is introduced below. Figure 4 and Figure 5 The following describes an apparatus provided in an embodiment of the present application. The description of the apparatus embodiment corresponds to the description of the method embodiment, so for matters not described in detail, reference can be made to the above method embodiment.

[0077] For example, Figure 4 2 is a schematic block diagram of an apparatus 2000 provided in an embodiment of the present application. The apparatus 2000 may include modules or units for implementing the above method embodiments. For example, the apparatus 2000 may include an acquisition unit 2010 and a processing unit 2020.

[0078] In one embodiment, the device 2000 may correspond to a boot device of a firmware, or may correspond to a component of the boot device (such as a chip, a processor, a processing circuit, etc.), or may correspond to a terminal including the boot device.

[0079] The device 2000 can implement the steps or processes performed by the firmware startup device in the above method embodiment. Among them, the acquisition unit 2010 can be used to perform the acquisition-related operations of the startup device in the above method embodiment; the processing unit 2020 can be used to perform the processing-related operations of the startup device in the above method embodiment.

[0080] Exemplarily, the acquisition unit 2010 may be configured to acquire a count value of consecutive startup failures of the firmware under the third version; the processing unit 2020 may be configured to determine the startup version of the firmware and the startup delay of the firmware according to the count value.

[0081] In some possible implementations, when the first delay mode is required to be used to determine the startup delay, the processing unit 2020 may be configured to determine the basic delay as the startup delay.

[0082] In some possible implementations, when the second delay mode is required to determine the startup delay, the processing unit 2020 may be configured to determine the startup delay according to the count value, the basic delay, and the delay tolerance.

[0083] In some possible implementations, the storage area for storing the third version may correspond to the first index, and the storage area for storing the previous version may correspond to the second index.

[0084] If the third version needs to be determined as the startup version, the processing unit 2020 may be configured to determine the first index as the startup index. If the startup version needs to be rolled back from the third version to a version immediately preceding the third version stored in the storage space, the processing unit 2020 may be configured to determine the second index as the startup index.

[0085] In some possible implementations, the processing unit 2020 may further be configured to: obtain a version of the firmware to be written; and when the firmware successfully boots with the boot version, store the version to be written in a target storage area. The target storage area may be the first storage area or the second storage area, and the boot version is not stored in the target storage area.

[0086] It should be understood that the specific process of each unit executing the above corresponding steps has been described in detail in the above method embodiment, and for the sake of brevity, it will not be repeated here.

[0087] It should also be understood that the division of the various units in the above devices is merely a division of logical functions. In actual implementation, they may be fully or partially integrated into a single physical entity, or physically separated. All units in the above devices may be implemented entirely through a processor calling software, entirely through hardware circuits, or partially through a processor calling software, with the remainder implemented through hardware circuits.

[0088] For example, in a specific implementation, the processing unit 2020 may be implemented by at least one processor or processor-related circuits. For example, one or more processors may determine the startup version of the firmware and the startup delay of the firmware based on the count value.

[0089] For example, Figure 5is a schematic block diagram of another apparatus 3000 provided in an embodiment of the present application. The apparatus 3000 may include: a processor 3010, an interface circuit 3020, and a memory 3030. The processor 3010, the interface circuit 3020, and the memory 3030 are connected via an internal connection path. The memory 3030 is used to store instructions, and the processor 3010 is used to execute the instructions stored in the memory 3030 and receive / send some parameters through the interface circuit 3020. Optionally, the memory 3030 may be coupled to the processor 3010 via an interface or may be integrated with the processor 3010.

[0090] It should be noted that the interface circuit 3020 may include but is not limited to a transceiver device such as an input / output interface to implement communication between the apparatus 3000 and other devices or a communication network.

[0091] The embodiment of the present application also provides a computer program product, which includes: a computer program code, which, when executed on a computer, enables the computer to execute the above Figures 1 to 3 Any method embodiment and any possible implementation thereof.

[0092] The embodiment of the present application also provides a computer-readable storage medium, which stores program codes or instructions. When the computer program codes or instructions are executed by a computer processor, the processor implements the above-mentioned Figures 1 to 3 Any method embodiment and any possible implementation thereof.

[0093] The present application also provides a chip including a circuit for executing the above Figures 1 to 3 Any method embodiment and any possible implementation thereof.

[0094] The embodiment of the present application also provides a terminal, which includes the above Figure 4 or Figure 5 The device in.

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

[0096] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, 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.

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

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

[0099] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0100] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for starting a terminal firmware, characterized in that: The storage space of the terminal includes a first storage area, a second storage area and a third storage area, the first storage area is used to store the first version of the firmware, the second storage area is used to store the second version of the firmware, and the third storage area is used to store the factory-burned version of the firmware; The method comprises: Obtaining a count value of the number of consecutive startup failures of the firmware under a third version, where the third version is the version used when the firmware was last started; Determine the startup version of the firmware and the startup delay of the firmware according to the count value; Wherein, determining the startup version of the firmware and the startup delay of the firmware according to the count value includes: When the count value is less than or equal to a first threshold, determining the third version as the startup version, and determining the startup delay according to a first delay mode; When the count value is greater than the first threshold and less than the second threshold, the third version is determined as the startup version, and the startup delay is determined according to a second delay mode; or, When the count value is greater than or equal to the second threshold, rolling back the startup version from the third version to a previous version of the third version stored in the storage space, and determining the startup delay according to the first delay mode; The third version is one of the first version and the second version, the previous version is the other of the first version and the second version, or the previous version is the factory-burned version; The startup delay determined according to the second delay mode is greater than the startup delay determined according to the first delay mode.

2. The method according to claim 1, characterized in that The determining the startup delay according to the first delay mode includes: determining a basic delay as the startup delay.

3. The method according to claim 1, characterized in that The determining the startup delay according to the second delay mode includes: The startup delay is determined according to the count value, the basic delay and the delay tolerance.

4. The method according to claim 2 or 3, characterized in that: The basic delay is zero.

5. The method according to any one of claims 1 to 3, characterized in that The storage area for storing the third version corresponds to the first index, the storage area for storing the previous version corresponds to the second index, and the running program of the firmware is used to start the firmware according to the startup index, The determining the third version as the startup version includes: determining the first index as the startup index; or, The rolling back the startup version from the third version to a previous version of the third version stored in the storage space includes: changing the startup index from the first index to the second index.

6. The method according to any one of claims 1 to 3, characterized in that The storage space does not store the second version, the third version is the first version, and the previous version is the factory-burned version.

7. The method according to any one of claims 1 to 3, characterized in that The storage space stores the first version, the second version and the factory-burned version, the third version is the first version and the previous version is the second version.

8. The method according to any one of claims 1 to 3, characterized in that The method further comprises: Obtaining the version of the firmware to be written; When the firmware is successfully started with the startup version, the version to be written is stored in a target storage area, the target storage area is the first storage area or the second storage area, and the startup version is not stored in the target storage area.

9. The method according to any one of claims 1 to 3, characterized in that The method further comprises: When the firmware is successfully started with the third version, the count value is cleared.

10. A device, characterized in that: The device comprises at least one processor, wherein the at least one processor is coupled to at least one memory and is configured to execute computer instructions stored in the memory, so that the device performs the method according to any one of claims 1 to 9.

11. A terminal, characterized in that: Comprising the device as claimed in claim 10.

Images