Dual boot loader starting method and device

Abstract

This invention relates to the field of microcontroller technology and discloses a dual-BootLoader startup method and apparatus. This method allows users to upgrade and update the secondary BootLoader. If the device detects a new version of the secondary BootLoader written according to user requirements during startup, it performs a self-test on the secondary BootLoader when starting the primary BootLoader. If the self-test fails, the secondary BootLoader firmware is restored under the primary BootLoader until the self-test passes, and then the secondary BootLoader is started to implement the storage function. Conversely, if the device detects a new version of the secondary BootLoader written according to user requirements during operation, it performs a self-test on the new version. If the self-test fails, the secondary BootLoader firmware is restored under the APP until the self-test passes, and then the secondary BootLoader is started to implement the storage function. This method provides two ways to start the BootLoader and can meet specific user needs on the BootLoader, improving the user experience.

Description

Technical Field

[0001] This invention relates to the field of microcontroller technology, and in particular to a dual-BootLoader startup method and apparatus. Background Technology

[0002] The BootLoader is the first piece of code executed after a device powers on. It performs functions such as hardware initialization, preparing the software environment, stack initialization, and application self-testing, before jumping to the application's runtime address to start the application. Therefore, the BootLoader plays a crucial role in the device boot process. For safety reasons, the user-side BootLoader is not allowed to be upgraded after the device leaves the factory. If unforeseen factors cause the BootLoader firmware upgrade to fail, the device will become unusable, resulting in significant financial losses for the user. However, during use, users often request customized functions that require implementation within the BootLoader to achieve optimal results.

[0003] To implement personalized features requested by users, there are currently two methods: one is to upgrade the BootLoader, but upgrading the BootLoader carries the risk of device malfunction; the other is to implement user needs within the app, but the experience often falls short of expectations, resulting in a poor user experience. Summary of the Invention

[0004] This invention provides a dual-BootLoader startup method and apparatus, which can solve the problem of the user-side BootLoader being unable to upgrade, implement personalized functions for users in the BootLoader, and improve the user experience.

[0005] To achieve the above objectives, the first embodiment of the present invention provides a dual-BootLoader startup method, including:

[0006] When the device is powered on, the first-level BootLoader is started; wherein, the first-level BootLoader is prohibited from receiving firmware upgrade packages input by the user;

[0007] The BootLoader validity check method is used to detect whether the secondary BootLoader meets the startup conditions; wherein, the secondary BootLoader can receive firmware upgrade packages input by the user;

[0008] If the secondary BootLoader does not meet the startup conditions, the system remains at the primary BootLoader and performs firmware recovery on the secondary BootLoader until the secondary BootLoader meets the startup conditions.

[0009] When the secondary BootLoader meets the startup conditions, the secondary BootLoader is started.

[0010] Run the secondary BootLoader and guide the APP to run;

[0011] During the operation of the APP, it is determined whether there is a new version of the secondary BootLoader in the main chip that needs to be updated;

[0012] If a new version of the secondary BootLoader exists, use the BootLoader validity check method to check whether the new version of the secondary BootLoader meets the startup conditions;

[0013] If the new version of the secondary BootLoader does not meet the startup conditions, a secondary BootLoader recovery command is sent to the APP, and the APP restores the firmware of the new version of the secondary BootLoader to meet the startup conditions.

[0014] When the new version of the secondary BootLoader meets the startup conditions, start the new version of the secondary BootLoader;

[0015] Run the new version of the secondary BootLoader and implement the storage function on the new version of the secondary BootLoader.

[0016] In the first embodiment of this invention, when the device detects a new version of the secondary BootLoader written according to user requirements during power-on, it will self-test the secondary BootLoader when starting the primary BootLoader. If the self-test fails, the secondary BootLoader firmware will be restored under the primary BootLoader until the self-test passes, and then the secondary BootLoader will be started to implement the storage function. Alternatively, if the device detects a new version of the secondary BootLoader written according to user requirements during operation, it will self-test the new version of the secondary BootLoader. If the self-test fails, the secondary BootLoader firmware will be restored under the APP until the self-test passes, and then the secondary BootLoader will be started to implement the storage function. This method provides two ways to start the BootLoader and can meet specific user needs on the BootLoader, improving the user experience.

[0017] Furthermore, the specific process for forming the new version of the secondary BootLoader is as follows:

[0018] Under the secondary BootLoader, programs written according to user requirements are received;

[0019] Based on the updated program, generate the software portion of the new version of the secondary BootLoader;

[0020] The software portion of the new version of the secondary BootLoader is packaged into the firmware of the new version of the secondary BootLoader.

[0021] In the first embodiment of the present invention, a corresponding program is written according to user needs under the secondary BootLoader, and then the secondary BootLoader software version containing the program is packaged into firmware. The user's personalized functions are realized by upgrading the secondary BootLoader firmware. This method can realize some specific user needs by starting the BootLoader, avoiding the lag in realizing user needs under the APP, improving the efficiency of realizing user functions, and enhancing the user experience.

[0022] Furthermore, the BootLoader validity verification method is specifically as follows:

[0023] Cyclic redundancy check is used to verify the validity of the secondary BootLoader header information;

[0024] If the header information of the secondary BootLoader is invalid, it is determined that the secondary BootLoader does not meet the startup conditions.

[0025] If the header information of the secondary BootLoader is valid, then the validity of the secondary BootLoader firmware data is checked using cyclic redundancy check based on the header information.

[0026] If the firmware data of the secondary BootLoader is invalid, it is determined that the secondary BootLoader does not meet the startup conditions.

[0027] If the firmware data of the secondary BootLoader is valid, then the secondary BootLoader is determined to meet the startup conditions.

[0028] The first embodiment of this invention provides a self-test method for a secondary BootLoader using cyclic redundancy check (CRUD). It checks the validity of the secondary BootLoader header information and then checks the validity of the secondary BootLoader firmware data. If both the secondary BootLoader header information and firmware data are valid, the secondary BootLoader meets the startup conditions and the self-test passes. This method avoids forcibly upgrading the secondary BootLoader before it meets the upgrade conditions, thus preventing firmware corruption and ensuring the safety of the upgrade process and the stability of subsequent upgrades.

[0029] Furthermore, the step of running the secondary BootLoader and guiding the APP to run specifically involves:

[0030] Under the secondary BootLoader, check whether the APP meets the startup conditions;

[0031] If the APP does not meet the startup conditions, it will remain in the secondary BootLoader to complete the firmware recovery of the APP until the APP meets the startup conditions.

[0032] When the app meets the startup conditions, the app will be launched and run.

[0033] In the first embodiment of this invention, when running the secondary BootLoader, it simultaneously checks whether the APP meets the startup conditions. If not, the secondary BootLoader restores the firmware of the APP until the startup conditions are met, thereby starting and running the APP. This method ensures that the APP can run normally under any conditions.

[0034] Furthermore, the startup of the first-level BootLoader also includes:

[0035] After starting the first-level BootLoader, hardware device initialization, software environment preparation, and stack initialization are implemented on the first-level BootLoader according to the preset function code.

[0036] In the first embodiment of the present invention, when starting the first-level BootLoader, the device hardware initialization, software environment preparation and stack initialization can be completed. This method can ensure the stability of subsequent upgrades and ensure that the device can be used normally.

[0037] Furthermore, the firmware data of the primary BootLoader, secondary BootLoader, and App are all stored in the Flash firmware.

[0038] The dual-BootLoader startup method provided in the first embodiment of this invention supports user upgrades and updates on the secondary BootLoader according to user needs. Software is developed and implemented on the secondary BootLoader based on user requirements, and then the developed secondary BootLoader software version is packaged into firmware. Users can upgrade the secondary BootLoader firmware to meet their specific needs. When the device detects a new version of the secondary BootLoader written according to user requirements during startup, it performs a self-check on the secondary BootLoader when starting the primary BootLoader. If the self-check fails, the secondary BootLoader firmware is restored under the primary BootLoader until the self-check passes, and the secondary BootLoader is then started to implement the storage function. Conversely, if the device detects a new version of the secondary BootLoader written according to user requirements during operation, it performs a self-check on the new version. If the self-check fails, the secondary BootLoader firmware is restored under the APP until the self-check passes, and the secondary BootLoader is then started to implement the storage function. This method provides two ways to start the BootLoader and can meet specific user needs on the BootLoader, improving the user experience.

[0039] The second embodiment of the present invention provides a dual-BootLoader startup device, comprising: a first startup module, a detection module, a recovery module, a second startup module, a first running module, a judgment module, a new version detection module, a new version recovery module, a new version startup module, and a second running module;

[0040] The first startup module is used to start the first-level BootLoader when the device is powered on; wherein, the first-level BootLoader is prohibited from receiving firmware upgrade packages input by the user;

[0041] The detection module is used to detect whether the secondary BootLoader meets the startup conditions using the BootLoader validity check method; wherein, the secondary BootLoader can receive firmware upgrade packages input by the user;

[0042] The recovery module is used to remain at the first-level bootloader if the second-level bootloader does not meet the startup conditions, and to complete the firmware recovery of the second-level bootloader until the second-level bootloader meets the startup conditions.

[0043] The second startup module is used to start the secondary BootLoader when the startup conditions are met;

[0044] The first running module is used to run the secondary BootLoader and guide the APP to run;

[0045] The judgment module is used to determine whether there is a new version of the secondary BootLoader in the main chip that needs to be updated during the operation of the APP.

[0046] The new version detection module is used to detect whether a new version of the secondary BootLoader meets the startup conditions if a new version of the secondary BootLoader exists, using the BootLoader validity check method.

[0047] The new version recovery module is used to send a secondary bootloader recovery command to the APP if the new version of the secondary bootloader does not meet the startup conditions. The APP then restores the firmware of the new version of the secondary bootloader to meet the startup conditions.

[0048] The new version of the startup module is used to start the new version of the secondary BootLoader when the startup conditions are met;

[0049] The second running module is used to run the new version of the secondary BootLoader and implement the storage function on the new version of the secondary BootLoader.

[0050] Furthermore, the specific process for forming the new version of the secondary BootLoader is as follows:

[0051] Under the secondary BootLoader, programs written according to user requirements are received;

[0052] Based on the updated program, generate the software portion of the new version of the secondary BootLoader;

[0053] The software portion of the new version of the secondary BootLoader is packaged into the firmware of the new version of the secondary BootLoader.

[0054] Furthermore, the first operating module includes: a detection unit, a recovery unit, and a startup unit;

[0055] The detection unit is used to detect whether the APP meets the startup conditions under the secondary BootLoader;

[0056] The recovery unit is used to remain in the secondary BootLoader if the APP does not meet the startup conditions, and to complete the firmware recovery of the APP until the APP meets the startup conditions.

[0057] The startup unit is used to start and run the APP when the startup conditions are met.

[0058] Furthermore, the first startup module includes: an implementation unit;

[0059] The implementation unit is used to initialize hardware devices, prepare the software environment, and initialize the stack on the first-level BootLoader according to the preset function code after the first-level BootLoader is started.

[0060] The second embodiment of the present invention constructs a dual BootLoader startup device, which is based on the organic combination between modules, so as to enable the BootLoader to be started in two different situations and meet the specific needs of users on the BootLoader, thereby improving the user experience. Attached Figure Description

[0061] Figure 1 A flowchart illustrating an embodiment of the dual-BootLoader startup method provided by the present invention;

[0062] Figure 2 A flowchart illustrating another embodiment of the dual-BootLoader startup method provided by the present invention;

[0063] Figure 3 A flowchart illustrating another embodiment of the dual-BootLoader startup method provided by the present invention;

[0064] Figure 4 A flowchart illustrating an embodiment of the process for forming a new version of the secondary BootLoader provided by the present invention;

[0065] Figure 5 A flowchart illustrating an embodiment of the BootLoader validity verification method provided by the present invention;

[0066] Figure 6 A schematic diagram of a Flash partition design provided by the present invention;

[0067] Figure 7 This is a schematic diagram of an embodiment of the dual-BootLoader boot process provided by the present invention;

[0068] Figure 8 This is a schematic diagram of one embodiment of the dual BootLoader startup device provided by the present invention. Detailed Implementation

[0069] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0070] In the description of this invention, it should be understood that the following terminology is used:

[0071] 1. "BootLoader": The BootLoader is the first piece of code executed after the device is powered on. It performs some device initialization and application self-test functions, and then jumps to the application's runtime address to start the application.

[0072] 2. "Flash": The English name for Flash memory is "Flash Memory", which is usually abbreviated as "Flash". It is a type of memory device and is a non-volatile memory.

[0073] Example 1

[0074] like Figure 1 The diagram shown is a flowchart of an embodiment of the dual-BootLoader startup method provided by the present invention. The method includes steps 1001 to 1010, and the specific steps are as follows:

[0075] Step 1001: When the device is powered on, start the first-level BootLoader; wherein, the first-level BootLoader is prohibited from receiving firmware upgrade packages input by the user.

[0076] In the first embodiment of the present invention, if certain uncertainties occur during the upgrade process of the Level 1 BootLoader firmware (e.g., power outage / abnormality of the device), the upgrade of the Level 1 BootLoader firmware will fail, which will cause the device to be unusable and thus cause significant economic losses to the customer. Therefore, after the Level 1 BootLoader leaves the factory, the user cannot upgrade or update it.

[0077] In the first embodiment of the present invention, as Figure 2 As shown, step 1001 includes step 2001, which is detailed below:

[0078] Step 2001: After starting the first-level BootLoader, hardware device initialization, software environment preparation, and stack initialization are performed on the first-level BootLoader according to the preset function code.

[0079] In the first embodiment of the present invention, the primary BootLoader mainly plays the role of booting and guiding, performing some device startup hardware initialization, software runtime stack initialization, checking the validity of the secondary BootLoader, and guiding the secondary BootLoader functions.

[0080] Step 1002: Use the BootLoader validity check method to check whether the secondary BootLoader meets the startup conditions; wherein, the secondary BootLoader can receive firmware upgrade packages input by the user.

[0081] In the first embodiment of this invention, the secondary BootLoader software is very streamlined, enabling extremely fast startup. The secondary BootLoader primarily serves to implement customized functions for customers, supporting upgrades on the customer side. For example, some customers may want the indicator light to illuminate immediately upon power-on, while others may not.

[0082] Step 1003: If the secondary BootLoader does not meet the startup conditions, the system remains at the primary BootLoader and performs firmware recovery on the secondary BootLoader until the secondary BootLoader meets the startup conditions.

[0083] In the first embodiment of the present invention, when the secondary bootloader fails to self-test, the primary bootloader enters recovery mode. Upon entering recovery mode, the primary bootloader initializes the USB module. At this time, the main chip Decserver application can detect that the device is under the primary bootloader. The main chip Decserver application then restores and upgrades the secondary bootloader, ensuring that the chip can run normally to the App under any circumstances (including extreme scenarios such as power failure during secondary bootloader upgrade). The secondary bootloader can then be upgraded normally under the App. Specifically, the firmware restoration method of the primary bootloader to the secondary bootloader is a USB CDC proprietary protocol upgrade, not a serial port / TFTP / HTTP / FTP protocol upgrade. The firmware restoration process of the secondary bootloader does not require manual user intervention; it is an automatic system-wide upgrade.

[0084] Step 1004: When the secondary BootLoader meets the startup conditions, start the secondary BootLoader.

[0085] Step 1005: Run the secondary BootLoader and guide the APP to run;

[0086] In the first embodiment of the present invention, as Figure 3 As shown, step 1005 includes steps 3001 to 3003, as detailed below:

[0087] Step 3001: Under the secondary BootLoader, check whether the APP meets the startup conditions.

[0088] Step 3002: If the APP does not meet the startup conditions, it will remain in the secondary BootLoader to complete the firmware recovery of the APP until the APP meets the startup conditions.

[0089] Step 3003: When the APP meets the startup conditions, start and run the APP.

[0090] Step 1006: During the operation of the APP, determine whether there is a new version of the secondary BootLoader in the main chip that needs to be updated.

[0091] Step 1007: If a new version of the secondary BootLoader exists, use the BootLoader validity check method to check whether the new version of the secondary BootLoader meets the startup conditions;

[0092] Step 1008: If the new version of the secondary BootLoader does not meet the startup conditions, a secondary BootLoader recovery command is sent to the APP, and the APP restores the firmware of the new version of the secondary BootLoader to meet the startup conditions.

[0093] Step 1009: When the new version of the secondary BootLoader meets the startup conditions, start the new version of the secondary BootLoader;

[0094] Step 1010: Run the new version of the secondary BootLoader to implement the storage function on the new version of the secondary BootLoader.

[0095] In the first embodiment of the present invention, as Figure 4 As shown, the process of forming a new version of the secondary BootLoader includes steps 4001 to 4003, as detailed below:

[0096] Step 4001: Under the secondary BootLoader, receive the program written according to user requirements.

[0097] Step 4002: Based on the updated program, generate the software portion of the new version of the secondary BootLoader.

[0098] Step 4003: Package the software portion of the new version of the secondary BootLoader into the firmware of the new version of the secondary BootLoader.

[0099] In the first embodiment of the present invention, as Figure 5 As shown, the BootLoader validity verification method includes steps 5001 to 5005, as detailed below:

[0100] Step 5001: Use cyclic redundancy check to check whether the secondary BootLoader header information is valid.

[0101] Step 5002: If the header information of the secondary BootLoader is invalid, it is determined that the secondary BootLoader does not meet the startup conditions.

[0102] Step 5003: If the header information of the secondary BootLoader is valid, then use cyclic redundancy check to check whether the firmware data of the secondary BootLoader is valid based on the header information.

[0103] Step 5004: If the firmware data of the secondary BootLoader is invalid, it is determined that the secondary BootLoader does not meet the startup conditions.

[0104] Step 5005: If the firmware data of the secondary BootLoader is valid, then the secondary BootLoader is determined to meet the startup conditions.

[0105] In the first embodiment of the present invention, the secondary BootLoader software header stores the secondary BootLoader firmware CRC value, and the header information also performs CRC and magic validity checks.

[0106] In the first embodiment of the present invention, as Figure 6 As shown, the firmware data of the first-level BootLoader, the second-level BootLoader, and the App are all stored in the Flash firmware.

[0107] In the first embodiment of the present invention, as Figure 7 As shown, the method for starting the device with dual BootLoaders is as follows: After the device is powered on, the primary BootLoader is started first, followed by a self-test of the secondary BootLoader. If the secondary BootLoader self-test fails, the device enters recovery and upgrade mode to restore and upgrade the firmware of the secondary BootLoader. If the secondary BootLoader self-test succeeds, the secondary BootLoader is started, followed by a self-test of the APP. If the APP self-test fails, the device enters recovery and upgrade mode to restore and upgrade the APP firmware. If the APP self-test succeeds, the APP application is started and run.

[0108] In the first embodiment of the present invention, there is also a situation where the user triggers the secondary BootLoader update. Since the firmware of the new version of the secondary BootLoader is built into the main chip device, when the user triggers the device update, the main chip software will be updated first. After the main chip software update is successful, the device will restart. After the device restarts, the Decserver application (a web interface that can be used to set parameters) will run on the main chip. When the application detects the slave chip device, it will initialize the slave chip and then detect the version of the secondary BootLoader of the slave chip. If the version of the secondary BootLoader of the slave chip is found to be inconsistent with the version of the secondary BootLoader built into the main chip, the main chip will send a command to the slave chip App application to complete the software upgrade of the secondary BootLoader of the slave chip under the App.

[0109] In summary, the first embodiment of the present invention provides a dual-BootLoader startup method, supporting users to upgrade and update the secondary BootLoader according to their needs. Software development and implementation are performed on the secondary BootLoader based on user requirements, and the developed secondary BootLoader software version is then packaged into firmware. Users can upgrade the secondary BootLoader firmware to meet their specific needs. When the device detects a new version of the secondary BootLoader written according to user requirements during startup, it performs a self-test on the secondary BootLoader when starting the primary BootLoader. If the self-test fails, the secondary BootLoader firmware is restored under the primary BootLoader until the self-test passes, and the secondary BootLoader is then started to implement the storage function. Similarly, if the device detects a new version of the secondary BootLoader written according to user requirements during operation, it performs a self-test on the new version. If the self-test fails, the secondary BootLoader firmware is restored under the APP until the self-test passes, and the secondary BootLoader is then started to implement the storage function. This method provides two ways to start the BootLoader and can meet specific user needs on the BootLoader, improving the user experience.

[0110] Example 2

[0111] like Figure 8The diagram shown is a structural schematic of an embodiment of the dual-BootLoader startup device provided by the present invention. The device includes a first startup module 8001, a detection module 8002, a recovery module 8003, a second startup module 8004, a first running module 8005, a judgment module 8006, a new version detection module 8007, a new version recovery module 8008, a new version startup module 8009, and a second running module 8010. Specifically:

[0112] The first startup module 8001 is used to start the first-level BootLoader when the device is powered on; wherein, the first-level BootLoader is prohibited from receiving firmware upgrade packages input by the user;

[0113] In a second embodiment of the present invention, the first startup module 8001 includes an implementation unit, specifically:

[0114] The implementation unit is used to initialize hardware devices, prepare the software environment, and initialize the stack on the first-level BootLoader after it starts, according to the preset function code.

[0115] The detection module 8002 is used to detect whether the secondary BootLoader meets the startup conditions using the BootLoader validity check method; wherein, the secondary BootLoader can receive firmware upgrade packages input by the user;

[0116] The recovery module 8003 is used to remain at the first-level bootloader if the second-level bootloader does not meet the startup conditions, and to complete the firmware recovery of the second-level bootloader until the second-level bootloader meets the startup conditions.

[0117] The second startup module 8004 is used to start the second-level BootLoader when the startup conditions are met;

[0118] The first running module 8005 is used to run the secondary BootLoader and guide the APP to run.

[0119] In a second embodiment of the present invention, the first operating module 8005 includes a detection unit, a recovery unit, and a startup unit, specifically:

[0120] The detection unit is used to detect whether the APP meets the startup conditions under the secondary BootLoader;

[0121] The recovery unit is used to stay in the secondary BootLoader if the APP does not meet the startup conditions, and to complete the firmware recovery of the APP until the APP meets the startup conditions.

[0122] The startup unit is used to start and run the application when the application meets the startup conditions.

[0123] The judgment module 8006 is used to determine whether there is a new version of the secondary BootLoader that needs to be updated in the main chip during the operation of the APP;

[0124] The new version detection module 8007 is used to detect whether a new version of the secondary BootLoader meets the startup conditions if a new version of the secondary BootLoader exists, using the BootLoader validity check method.

[0125] The new version recovery module 8008 is used to send a secondary bootloader recovery command to the APP if the new version of the secondary bootloader does not meet the startup conditions. The APP then restores the firmware of the new version of the secondary bootloader to meet the startup conditions.

[0126] The new version of the startup module 8009 is used to start the new version of the secondary BootLoader when the startup conditions are met;

[0127] The second running module 8010 is used to run the new version of the secondary BootLoader and implement the storage function on the new version of the secondary BootLoader.

[0128] In the second embodiment of the present invention, the specific process of forming the new version of the secondary BootLoader is as follows:

[0129] Under the secondary BootLoader, programs written according to user requirements are received;

[0130] Based on the updated program, generate the software portion of the new version of the secondary BootLoader;

[0131] The software portion of the new version of the secondary BootLoader is packaged into the firmware of the new version of the secondary BootLoader.

[0132] The second embodiment of the present invention constructs a dual BootLoader startup device, which is based on the organic combination between modules, so as to enable the BootLoader to be started in two different situations and meet the specific needs of users on the BootLoader, thereby improving the user experience.

[0133] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and substitutions can be made without departing from the technical principles of the present invention, and these improvements and substitutions should also be considered within the scope of protection of the present invention.

Claims

1. A dual-BootLoader startup method, characterized in that, include: When the device is powered on, the first-level BootLoader is started; wherein, the first-level BootLoader is prohibited from receiving firmware upgrade packages input by the user; The BootLoader validity check method is used to detect whether the secondary BootLoader meets the startup conditions; wherein, the secondary BootLoader can receive firmware upgrade packages input by the user; If the secondary BootLoader does not meet the startup conditions, the system will remain at the primary BootLoader and perform firmware recovery on the secondary BootLoader until the secondary BootLoader meets the startup conditions. When the secondary BootLoader meets the startup conditions, the secondary BootLoader is started. Run the secondary BootLoader and guide the APP to run; During the operation of the APP, it is determined whether there is a new version of the secondary BootLoader in the main chip that needs to be updated; If a new version of the secondary BootLoader exists, use the BootLoader validity check method to check whether the new version of the secondary BootLoader meets the startup conditions; If the new version of the secondary BootLoader does not meet the startup conditions, a secondary BootLoader recovery command is sent to the APP, and the APP restores the firmware of the new version of the secondary BootLoader to meet the startup conditions. When the new version of the secondary BootLoader meets the startup conditions, start the new version of the secondary BootLoader; Run the new version of the secondary BootLoader and implement the storage function on the new version of the secondary BootLoader.

2. The dual-BootLoader startup method according to claim 1, characterized in that, The specific process by which the new version of the secondary BootLoader is formed is as follows: Under the secondary BootLoader, programs written according to user requirements are received; Based on the updated program, generate the software portion of the new version of the secondary BootLoader; The software portion of the new version of the secondary BootLoader is packaged into the firmware of the new version of the secondary BootLoader.

3. The dual-BootLoader startup method according to claim 1, characterized in that, The BootLoader validity verification method is as follows: Cyclic redundancy check is used to verify the validity of the secondary BootLoader header information; If the header information of the secondary BootLoader is invalid, it is determined that the secondary BootLoader does not meet the startup conditions. If the header information of the secondary BootLoader is valid, then the validity of the secondary BootLoader firmware data is checked using cyclic redundancy check based on the header information. If the firmware data of the secondary BootLoader is invalid, it is determined that the secondary BootLoader does not meet the startup conditions. If the firmware data of the secondary BootLoader is valid, then the secondary BootLoader is determined to meet the startup conditions.

4. The dual-BootLoader startup method according to claim 1, characterized in that, The process of running the secondary BootLoader and guiding the APP to run is as follows: Under the secondary BootLoader, check whether the APP meets the startup conditions; If the APP does not meet the startup conditions, it will remain in the secondary BootLoader to complete the firmware recovery of the APP until the APP meets the startup conditions. When the app meets the startup conditions, the app will be launched and run.

5. The dual-BootLoader startup method according to claim 1, characterized in that, The startup of the first-level BootLoader also includes: After starting the first-level BootLoader, hardware device initialization, software environment preparation, and stack initialization are implemented on the first-level BootLoader according to the preset function code.

6. The dual-BootLoader startup method according to claim 1, characterized in that, The firmware data for the primary BootLoader, secondary BootLoader, and App are all stored in the Flash firmware.

7. A dual-BootLoader startup device, characterized in that, include: First startup module, detection module, recovery module, second startup module, first running module, judgment module, new version detection module, new version recovery module, new version startup module, second running module; The first startup module is used to start the first-level BootLoader when the device is powered on; wherein, the first-level BootLoader is prohibited from receiving firmware upgrade packages input by the user; The detection module is used to detect whether the secondary BootLoader meets the startup conditions using the BootLoader validity check method; wherein, the secondary BootLoader can receive firmware upgrade packages input by the user; The recovery module is used to remain at the first-level bootloader if the second-level bootloader does not meet the startup conditions, and to complete the firmware recovery of the second-level bootloader until the second-level bootloader meets the startup conditions. The second startup module is used to start the secondary BootLoader when the startup conditions are met; The first running module is used to run the secondary BootLoader and guide the APP to run; The judgment module is used to determine whether there is a new version of the secondary BootLoader in the main chip that needs to be updated during the operation of the APP. The new version detection module is used to detect whether a new version of the secondary BootLoader meets the startup conditions if a new version of the secondary BootLoader exists, using the BootLoader validity check method. The new version recovery module is used to send a secondary bootloader recovery command to the APP if the new version of the secondary bootloader does not meet the startup conditions. The APP then restores the firmware of the new version of the secondary bootloader to meet the startup conditions. The new version of the startup module is used to start the new version of the secondary BootLoader when the startup conditions are met; The second running module is used to run the new version of the secondary BootLoader and implement the storage function on the new version of the secondary BootLoader.

8. The dual-BootLoader startup device according to claim 7, characterized in that, The specific process by which the new version of the secondary BootLoader is formed is as follows: Under the secondary BootLoader, programs written according to user requirements are received; Based on the updated program, generate the software portion of the new version of the secondary BootLoader; The software portion of the new version of the secondary BootLoader is packaged into the firmware of the new version of the secondary BootLoader.

9. The dual-BootLoader startup device according to claim 7, characterized in that, The first operating module includes: a detection unit, a recovery unit, and a startup unit; The detection unit is used to detect whether the APP meets the startup conditions under the secondary BootLoader; The recovery unit is used to remain in the secondary BootLoader if the APP does not meet the startup conditions, and to complete the firmware recovery of the APP until the APP meets the startup conditions. The startup unit is used to start and run the APP when the startup conditions are met.

10. The dual-BootLoader startup device according to claim 7, characterized in that, The first startup module includes: an implementation unit; The implementation unit is used to initialize hardware devices, prepare the software environment, and initialize the stack on the first-level BootLoader according to the preset function code after the first-level BootLoader is started.

Images