Double-BootLoader software upgrading method and device and storage medium

Abstract

The invention belongs to the technical field of software upgrading, and relates to a dual-BootLoader software upgrading method and device and a storage medium, and the method comprises the steps: obtaining a first upgrading mark after a first BootLoader runs; if the first upgrade mark is valid, staying at the first BootLoader to execute the upgrade of the second BootLoader, and after the upgrade is completed, setting the first upgrade mark to be invalid and then running the second BootLoader; if the first upgrade mark is invalid, the first BootLoader verifies the second BootLoader, and if the first BootLoader passes the verification, the second BootLoader is operated; after the second BootLoader runs, a second upgrading mark is obtained; if the second upgrade mark is valid, staying at the second BootLoader to execute the upgrade of the APP, and after the upgrade is completed, setting the second upgrade mark to be invalid and then running the APP; and if the second upgrade mark is invalid, the second BootLoader verifies the APP, and if the verification is passed, the APP is operated. According to the method provided by the invention, the BootLoader can be upgraded without disassembling the equipment after the equipment leaves the factory, so that the updating cost is saved.

Description

Technical Field

[0001] The present application belongs to the technical field of software upgrade, and specifically relates to a dual BootLoader software upgrade method, device and storage medium. Background Art

[0002] The existing embedded software architecture generally adopts the design of BootLoader+APP. Among them, BootLoader is the first code executed after the device is powered on. It completes the functions of device hardware initialization, software environment preparation, stack initialization and application self-test, and then jumps to the application running address to run the APP application. For safety reasons, the user-side BootLoader is not allowed to be upgraded after the device leaves the factory.

[0003] However, during the software upgrade process, the original APP area is often insufficient and needs to be re-divided, or the upgrade rules and verification rules need to be changed. These all require updating the BootLoader. However, the existing BootLoader cannot be updated through ordinary upgrade methods. It can only be burned after the device is opened, which will cause serious economic losses. Summary of the invention

[0004] The embodiments of the present application provide a dual BootLoader software upgrade method, device, and storage medium, which can support upgrading the BootLoader without disassembling the device after the device leaves the factory, thereby saving update costs.

[0005] In a first aspect, an embodiment of the present application provides a dual BootLoader software upgrade method, wherein an upgrade flag area is provided in the Flash of a device, wherein the upgrade flag area stores a first upgrade flag and a second upgrade flag, and the method comprises:

[0006] After the first BootLoader runs, the first upgrade flag is obtained;

[0007] If the first upgrade flag is valid, stay in the first BootLoader to execute the upgrade of the second BootLoader. After the upgrade is completed, set the first upgrade flag to invalid and then run the second BootLoader;

[0008] If the first upgrade flag is invalid, the first BootLoader verifies the second BootLoader, and if the verification passes, runs the second BootLoader;

[0009] After the second BootLoader runs, the second upgrade flag is obtained;

[0010] If the second upgrade flag is valid, the second BootLoader is used to execute the upgrade of the APP. After the upgrade is completed, the second upgrade flag is set to invalid and the APP is run again.

[0011] If the second upgrade flag is invalid, the second BootLoader verifies the APP, and if the verification passes, runs the APP.

[0012] Optionally, after running the APP, the step further includes:

[0013] After receiving the second BootLoader upgrade request, the APP sets the first upgrade flag to valid and then jumps to the first BootLoader; and / or,

[0014] After receiving the APP upgrade request, the APP sets the second upgrade flag to be valid and then jumps to the second BootLoader.

[0015] Optionally, the upgrade process of the second BootLoader includes:

[0016] The first BootLoader receives the second BootLoader upgrade file, and writes the second BootLoader upgrade file into the second Boot backup area;

[0017] After the second BootLoader upgrade file is transmitted, the first BootLoader verifies the data in the second Boot backup area, and copies the data in the second Boot backup area to the second Boot area after the verification passes.

[0018] Optionally, the upgrade process of the APP includes:

[0019] The second BootLoader receives the APP upgrade file and writes the APP upgrade file into the APP backup area;

[0020] After the APP upgrade file is transmitted, the data in the APP backup area is verified, and after the verification passes, the data in the APP backup area is copied to the APP area.

[0021] Optionally, the method further comprises:

[0022] If the first BootLoader fails to verify the second BootLoader, the first BootLoader will forcefully upgrade the second BootLoader.

[0023] If the second BootLoader fails to verify the APP, the second BootLoader will force the APP to be upgraded.

[0024] Optionally, the upgrade mark area also stores a start address of the APP, and the method further includes: the APP writes its own start address into the upgrade mark area.

[0025] Optionally, the method further comprises:

[0026] If the first BootLoader fails to verify the second BootLoader, the first BootLoader obtains the starting address of the APP, obtains the APP from the starting address of the APP, verifies the APP, and runs the APP if the verification passes.

[0027] Optionally, the method also includes: if the first BootLoader fails to verify the second BootLoader, the first BootLoader forcibly upgrades the second BootLoader; if the second BootLoader upgrade file is not received within a preset time, the first BootLoader obtains the starting address of the APP, obtains the APP from the starting address of the APP, verifies the APP, and runs the APP if the verification passes.

[0028] In a second aspect, an embodiment of the present application provides an electronic device, comprising: at least one processor and a memory communicatively connected to the at least one processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the at least one processor so that the at least one processor can execute any of the methods described above.

[0029] In a third aspect, an embodiment of the present application provides a computer storage medium, which stores instructions or programs. When the instructions or programs are executed by at least one processor, the at least one processor executes any one of the methods described above.

[0030] In an embodiment of the present application, a dual BootLoader software upgrade method is provided, wherein an upgrade flag area is provided in the Flash of the device, wherein the upgrade flag area stores a first upgrade flag and a second upgrade flag, and after the first BootLoader is run, the first upgrade flag is obtained; if the first upgrade flag is valid, the first BootLoader is stayed in the first BootLoader to execute the upgrade of the second BootLoader, and after the upgrade is completed, the first upgrade flag is set to invalid and then the second BootLoader is run; if the first upgrade flag is invalid, the first BootLoader verifies the second BootLoader, and if the verification passes, the second BootLoader is run; after the second BootLoader is run, the second upgrade flag is obtained; if the second upgrade flag is valid, the second BootLoader is stayed in the second BootLoader to execute the upgrade of the APP, and after the upgrade is completed, the second upgrade flag is set to invalid and then the APP is run; if the second upgrade flag is invalid, the second BootLoader verifies the APP, and if the verification passes, the APP is run. The method of the present application sets an upgrade flag area in the Flash of the device so that after the first BootLoader is running, it can stop according to the corresponding upgrade flag and upgrade the second BootLoader, thereby realizing the upgrade of the second BootLoader without disassembling the device, meeting the diverse change requirements of the application program, and ensuring the security of the upgrade process. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A schematic diagram of Flash storage space division is shown as an example;

[0032] Figure 2 Another schematic diagram showing the division of Flash storage space

[0033] Figure 3 The following is an exemplary flowchart of a dual BootLoader software upgrade method;

[0034] Figure 4 A schematic diagram of upgrading the second BootLoader using a double backup method is exemplified;

[0035] Figure 5 A schematic diagram of upgrading an APP using a dual backup method is exemplified;

[0036] Figure 6 A structural schematic diagram of an electronic device is exemplarily shown. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0038] See also Figure 1 , Figure 1 The following is an exemplary diagram of a Flash storage space division. Figure 1 As shown, the storage space of the Flash is divided into a first Boot area, a second Boot area, an APP area and an upgrade flag area. The first Boot area stores the first BootLoader, the second Boot area stores the second BootLoader, the APP area stores the APP, and the upgrade flag area stores the first upgrade flag and the second upgrade flag.

[0039] The first BootLoader is the first program that runs after the device is powered on, and is mainly used to implement functions such as device hardware initialization, upgrading the second BootLoader, verifying the second BootLoader, and jumping to the second BootLoader. In some embodiments, the first BootLoader is also used to verify the APP and jump to the APP when the second BootLoader is abnormal (for example, verification fails or upgrade fails).

[0040] The second BootLoader is a program that jumps to the next Flash address after the first BootLoader successfully verifies it. It is mainly used to implement functions such as upgrading the APP, verifying the APP, and jumping to the APP. The second BootLoader determines the upgrade method and verification rules of the APP. By upgrading the second BootLoader, you can change the upgrade method of the APP, the verification rules of the APP, and the starting address of the APP in the Flash. Among them, the upgrade method of the APP includes single backup upgrade and double backup upgrade. The verification rules of the APP can correspond to different rules at different stages of the product. For example, in the development stage of the product, the verification rules of the APP can be simple enough, or even no verification rules are designed. In the production and sales stage of the product, the verification rules of the APP should be as perfect as possible.

[0041] APP is a program executed when the device is operating normally. It is generally executed by jumping into the second BootLoader. When the second BootLoader is abnormal, it can also jump into the first BootLoader to execute, so that the device can still work normally when the second BootLoader is abnormal and the current environment is not suitable for upgrading.

[0042] During the running process of APP, it can receive a second BootLoader upgrade request or APP upgrade request initiated by an external device or its own device (for example, the user clicks the corresponding upgrade button on the interface of its own device). When the second BootLoader upgrade request is received, the first upgrade flag is set to valid, and the first BootLoader is jumped to execute the second BootLoader upgrade; when the APP upgrade request is received, the APP upgrade request flag is set to valid, and the second BootLoader is jumped to execute the APP upgrade.

[0043] The upgrade flag area is a space in Flash for storing the first upgrade flag and the second upgrade flag. Among them, the first upgrade flag is used to indicate whether the second BootLoader upgrade is required, and the second upgrade flag is used to indicate whether the APP upgrade is required. In some embodiments, the upgrade flag area also stores the starting address of the APP. This is because the size and starting address of the APP may change with the update iteration of the product application. In order to ensure that the first BootLoader and the second BootLoader can jump to the APP, the APP writes its own starting address to the upgrade flag area after running.

[0044] In some embodiments, when the second BootLoader upgrade adopts a dual backup upgrade method, the Flash storage space also includes the second Boot backup area; when the second APP upgrade adopts a dual backup upgrade method, the Flash storage space also includes the APP backup area. Figure 2 As shown, the storage space of Flash is divided into the first Boot area, the second Boot area, the second Boot backup area, the upgrade flag area, the APP area and the APP backup area. Among them, the size and starting address of the APP backup area can be changed by upgrading the second BootLoader. In some cases, the storage space of Flash may also only include the second Boot backup area, but not the APP backup area. For example, when the size of the APP increases significantly, resulting in insufficient storage space for Flash, the original APP backup area will be deleted after the original APP double backup upgrade method is changed to the APP single backup upgrade method by upgrading the second BootLoader.

[0045] It should be noted that Figure 1 or Figure 2The Flash shown is a memory for storing computer programs or instructions, and may be an internal Flash located in an MCU (Microcontroller Unit) or a Flash independent of a processor.

[0046] See also Figure 3 , Figure 3 The following is an exemplary flowchart of a dual BootLoader software upgrade method. Figure 6 The electronic device shown in the figure is executed, and the Flash of the electronic device can be used Figure 1 or Figure 2 In some embodiments, the Flash storage space of the electronic device includes a first Boot area for storing a first BootLoader, a second Boot area for storing a second BootLoader, an APP area for storing an APP, and an upgrade flag area for storing a first upgrade flag and a second upgrade flag. In other embodiments, the Flash storage space of the electronic device also includes a second Boot backup area and an APP backup area. Figure 3 As shown, the method specifically comprises the following steps:

[0047] Step S301: After the first BootLoader runs, a first upgrade flag is obtained.

[0048] In some embodiments, after the device is powered on, the first BootLoader starts to run, and after completing operations such as device hardware initialization, obtains the first upgrade flag from a preset upgrade flag area.

[0049] In other embodiments, when the APP receives a second BootLoader upgrade request initiated by an external device or its own device during operation, the APP sets the first upgrade flag to valid (for example, when the first upgrade flag is 1, it means "valid", and when the first upgrade flag is 0, it means "invalid"), and jumps to the first BootLoader entry to run the first BootLoader.

[0050] Step S302, determine whether the first upgrade flag is valid, if so, proceed to step S303, if not, proceed to step S304.

[0051] Step S303, staying in the first BootLoader to execute the upgrade of the second BootLoader, after the upgrade is completed, setting the first upgrade flag to invalid, and then running the second BootLoader.

[0052] In some embodiments, when the first upgrade flag is valid, it stays in the first BootLoader. The first BootLoader initializes the communication peripherals, establishes a communication connection with the external upgrade device, and then starts to execute the upgrade process of the second BootLoader. Specifically, the upgrade process of the second BootLoader can be performed using a single backup method or a double backup method. Among them, when the single backup method is used for upgrading, the specific implementation method of the second BootLoader includes the following steps: the first BootLoader first erases the second Boot area of ​​the Flash, and then receives the second BootLoader upgrade file transmitted by the external upgrade device; when the second BootLoader upgrade file is fully received, the first BootLoader verifies the second BootLoader upgrade file, and writes the second BootLoader upgrade file to the second Boot area after the verification passes. When the second BootLoader is upgraded using the single backup method, if the first BootLoader fails to verify the second BootLoader upgrade file, the first BootLoader runs the second upgrade of the second BootLoader until the second BootLoader upgrade is successful or the number of upgrades reaches a preset threshold. If the upgrade times of the second BootLoader reach the preset threshold and are still unsuccessful, the first BootLoader verifies the APP and runs the APP after the verification passes.

[0053] The specific process of upgrading the second BootLoader using the dual backup method can be found in the following Figure 3 Description.

[0054] Step S304: the first BootLoader verifies the second BootLoader. If the verification passes, the second BootLoader is run.

[0055] In one embodiment, the first BootLoader verifies the second BootLoader using a cyclic redundancy check and / or a longitudinal redundancy check, etc. If the verification passes, the second BootLoader is run; if the verification fails, the first BootLoader forcibly upgrades the second BootLoader.

[0056] Step S305: After the second BootLoader runs, a second upgrade flag is obtained.

[0057] Step S306, determining whether the second upgrade flag is valid, if so, proceeding to step S307, if not, proceeding to step S308.

[0058] Step S307, staying in the second BootLoader to execute the upgrade of the APP, after the upgrade is completed, setting the second upgrade flag to invalid and then running the APP.

[0059] In some embodiments, when the second upgrade flag is valid, it stays in the second BootLoader. The second BootLoader initializes the communication peripherals, establishes a communication connection with the external upgrade device, and then starts to execute the upgrade process of the APP. Specifically, the upgrade process of the APP can be carried out using a double backup method or a single backup method. Among them, the specific implementation method of upgrading the APP using the single backup method includes the following steps: the second BootLoader first erases the APP area of ​​the Flash, and then receives the APP upgrade file transmitted by the external upgrade device; when all the APP upgrade files are received, the second BootLoader verifies the APP upgrade file, and writes the APP upgrade file to the APP area after the verification passes. When the single backup method is used to upgrade the APP, if the second BootLoader fails to verify the APP upgrade file, the second BootLoader runs another upgrade of the APP until the APP upgrade is successful or the number of upgrades reaches a preset threshold.

[0060] The specific process of upgrading APP using the dual backup method can be found in the following Figure 4 Description.

[0061] Step S308: The second BootLoader verifies the APP, and if the verification passes, runs the APP.

[0062] As mentioned above, the verification rules of the APP are determined by the second BootLoader, and different rules may correspond to different stages of the product. Generally, the verification rules may include cyclic redundancy check, longitudinal redundancy check, header file information check of the APP area, and first and last special character check of the APP area. In some embodiments, if the second BootLoader fails to verify the APP, the second BootLoader will force an upgrade of the APP.

[0063] In some embodiments, the upgrade flag area also stores the starting address of the APP. After the APP runs normally, its starting address in the Flash is written to the upgrade flag area. In step S304, if the first BootLoader fails to verify the second BootLoader, the method may also include the following steps: the first BootLoader obtains the starting address of the APP from the upgrade flag area, then obtains the APP from the starting address of the APP and verifies the APP. If the verification passes, the APP is run; or, the first BootLoader forcibly upgrades the second BootLoader. If the second BootLoader upgrade file is not received within a preset time, the first BootLoader obtains the starting address of the APP from the upgrade flag area, obtains the APP from the starting address of the APP, and then verifies the APP. If the verification passes, the APP is run. In this application, both the first BootLoader and the second BootLoader can jump to the APP, ensuring that the device can still be used normally without upgrading the second BootLoader when the second BootLoader is abnormal.

[0064] See also Figure 4 , Figure 4 A schematic diagram of upgrading the second BootLoader using a dual backup method is exemplarily shown, and the method specifically includes the following steps:

[0065] Step S401: the APP receives a second BootLoader upgrade request, sets a first upgrade flag to be valid, and then jumps to the first BootLoader.

[0066] The normally running APP receives the second BootLoader upgrade request initiated by the external device or the device itself, sets the first upgrade flag in the upgrade flag area to valid, and then jumps to the first BootLoader.

[0067] Step S402: The first BootLoader receives the second BootLoader upgrade file, and writes the second BootLoader upgrade file into the second Boot backup area.

[0068] Step S403: After the second BootLoader upgrade file is transmitted, the first BootLoader verifies the data in the second Boot backup area, and copies the data in the second Boot backup area to the second Boot area after the verification passes.

[0069] When the first BootLoader fails to verify the data in the second Boot backup area, it erases the second Boot backup area and then jumps to the APP.

[0070] Step S404: After the second BootLoader is upgraded, the first BootLoader sets the first upgrade flag to invalid and then jumps to the APP.

[0071] Specifically, after the second BootLoader upgrade is completed, the first BootLoader sets the first upgrade flag to invalid and then jumps to the second BootLoader, and the second BootLoader verifies the APP and then jumps to the APP.

[0072] See also Figure 5 , Figure 5 A schematic diagram of upgrading an APP using a dual backup method is exemplarily shown, and the method specifically includes the following steps:

[0073] Step S501: the APP receives an APP upgrade request, sets a second upgrade flag to be valid, and then jumps to the second BootLoader.

[0074] The normally running APP receives an APP upgrade request initiated by an external device or its own device, sets the second upgrade flag in the upgrade flag area to valid, and then jumps to the second BootLoader.

[0075] Step S502: The second BootLoader receives the APP upgrade file and writes the APP upgrade file into the APP backup area.

[0076] Step S503, after the APP upgrade file is transmitted, the second BootLoader verifies the data in the APP backup area, and copies the data in the APP backup area to the APP area after the verification passes.

[0077] When the second BootLoader fails to verify the data in the APP backup area, it erases the APP backup area and jumps to the APP.

[0078] Step S504, after the APP upgrade is completed, the second BootLoader sets the second upgrade flag to invalid and then jumps to the APP.

[0079] In an embodiment of the present application, a dual BootLoader software upgrade method is provided, wherein an upgrade flag area is provided in the Flash of the device, wherein the upgrade flag area stores a first upgrade flag and a second upgrade flag, and after the first BootLoader is run, the first upgrade flag is obtained; if the first upgrade flag is valid, the first BootLoader is stayed in the first BootLoader to execute the upgrade of the second BootLoader, and after the upgrade is completed, the first upgrade flag is set to invalid and then the second BootLoader is run; if the first upgrade flag is invalid, the first BootLoader verifies the second BootLoader, and if the verification passes, the second BootLoader is run; after the second BootLoader is run, the second upgrade flag is obtained; if the second upgrade flag is valid, the second BootLoader is stayed in the second BootLoader to execute the upgrade of the APP, and after the upgrade is completed, the second upgrade flag is set to invalid and then the APP is run; if the second upgrade flag is invalid, the second BootLoader verifies the APP, and if the verification passes, the APP is run. The method of the present application sets an upgrade flag area in the Flash of the device, so that after the first BootLoader runs, it can stop according to the corresponding upgrade flag and upgrade the second BootLoader, thereby upgrading the second BootLoader without disassembling the device, meeting the diverse change requirements of the application program, and ensuring the security of the upgrade process. In addition, the present application adds relevant upgrade exception and verification exception handling measures in the first BootLoader and the second BootLoader, ensuring that the device can still be restored or enter the APP operation when the upgrade exception or verification exception occurs, thereby ensuring the safety of the device.

[0080] See also Figure 6 , Figure 6 The schematic diagram of the structure of an embedded device is shown as an example. Figure 6 As shown, the electronic device 100 includes at least one processor 10, a memory 20 and a communication interface 30, wherein the memory 20 can be built into the processor 10, can be external to the processor 10, or can be a remotely set memory connected to the processor 10 via a network. The processor 10, the memory 20 and the communication interface 30 are connected via a line. Figure 6 In the illustrated embodiment, the processor 10, the memory 20 and the communication interface 30 are communicatively connected to each other via a bus.

[0081] The memory 20 stores logic instructions that can be run on the processor 10. When the processor 10 executes the computer program instructions, the above-mentioned dual BootLoader software upgrade method is implemented.

[0082] In addition, the logic instructions in the above-mentioned memory 20 can be implemented in the form of a software functional unit and can be stored in several computer-readable storage media when it is sold or used as an independent product. Based on such an understanding, the technical solution of the present invention can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the dual BootLoader software upgrade method in this application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0083] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Under the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other changes in different aspects of the present application as described above, which are not provided in detail for the sake of simplicity. Although the present application has been described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features can be replaced by equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A dual BootLoader software upgrade method, characterized in that: An upgrade mark area is set in the Flash of the device, and the upgrade mark area stores a first upgrade mark and a second upgrade mark. The method includes: After the first BootLoader runs, the first upgrade flag is obtained; If the first upgrade flag is valid, stay in the first BootLoader to execute the upgrade of the second BootLoader. After the upgrade is completed, set the first upgrade flag to invalid and then run the second BootLoader; If the first upgrade flag is invalid, the first BootLoader verifies the second BootLoader, and if the verification passes, runs the second BootLoader; After the second BootLoader runs, the second upgrade flag is obtained; If the second upgrade flag is valid, the second BootLoader is used to execute the upgrade of the APP. After the upgrade is completed, the second upgrade flag is set to invalid and the APP is run again. If the second upgrade flag is invalid, the second BootLoader verifies the APP, and if the verification passes, runs the APP.

2. The method according to claim 1, characterized in that After running the APP, the following steps are also included: After receiving the second BootLoader upgrade request, the APP sets the first upgrade flag to valid and then jumps to the first BootLoader; and / or, After receiving the APP upgrade request, the APP sets the second upgrade flag to be valid and then jumps to the second BootLoader.

3. The method according to claim 1 or 2, characterized in that: The upgrade process of the second BootLoader includes: The first BootLoader receives the second BootLoader upgrade file, and writes the second BootLoader upgrade file into the second Boot backup area; After the second BootLoader upgrade file is transmitted, the first BootLoader verifies the data in the second Boot backup area, and copies the data in the second Boot backup area to the second Boot area after the verification passes.

4. The method according to claim 1 or 2, characterized in that: The upgrade process of the APP includes: The second BootLoader receives the APP upgrade file and writes the APP upgrade file into the APP backup area; After the APP upgrade file is transmitted, the data in the APP backup area is verified, and after the verification passes, the data in the APP backup area is copied to the APP area.

5. The method according to claim 1 or 2, characterized in that: The method further comprises: If the first BootLoader fails to verify the second BootLoader, the first BootLoader will forcefully upgrade the second BootLoader. If the second BootLoader fails to verify the APP, the second BootLoader will force the APP to be upgraded.

6. The method according to claim 1 or 2, characterized in that: The upgrade mark area also stores the start address of the APP, and the method further includes: the APP writes its own start address into the upgrade mark area.

7. The method according to claim 6, characterized in that The method further comprises: If the first BootLoader fails to verify the second BootLoader, the first BootLoader obtains the starting address of the APP, obtains the APP from the starting address of the APP, and then verifies the APP. If the verification passes, the APP is run.

8. The method according to claim 6, characterized in that The method also includes: if the first BootLoader fails to verify the second BootLoader, the first BootLoader forcibly upgrades the second BootLoader, and if the second BootLoader upgrade file is not received within a preset time, the first BootLoader obtains the starting address of the APP, obtains the APP from the starting address of the APP, and then verifies the APP, and if the verification passes, runs the APP.

9. An electronic device, characterized in that: It includes at least one processor and a memory communicatively connected to the at least one processor, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the dual BootLoader software upgrade method as described in any one of claims 1 to 8.

10. A computer storage medium, characterized in that: The computer storage medium stores instructions or programs, and when the instructions or programs are executed by at least one processor, the at least one processor executes the dual BootLoader software upgrade method according to any one of claims 1 to 8.

Images