Method and device for booting application startup, electronic device, and storage medium

Abstract

The embodiments of the present application disclose a method and device for guiding application startup, an electronic device, and a storage medium. The technical solution provided by the embodiments of the present application obtains firmware from an application terminal or an interactive device according to a received application startup instruction; performs validity detection on the obtained firmware; if the firmware is valid, processes it according to pre-stored firmware upgrade rules to obtain startup firmware; if the firmware is invalid, re-acquires the firmware; and guides application startup according to the startup firmware. The technical solution provided by the embodiments of the present application can reduce the workload of guiding application startup and improve the efficiency of guiding application startup.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of information processing technology, and in particular to a method and device for guiding application startup, an electronic device, and a storage medium. Background Art

[0002] Currently, boot loaders for various platforms are typically designed based on their own software frameworks. This process must be repeated each time a new platform is used, even for the same requirements. Furthermore, differences in hardware resources between platforms often lead to process adjustments. The resulting differences in code details can lead to issues with code management and verification. Summary of the Invention

[0003] The embodiments of the present application provide a method and device for booting an application, an electronic device, and a storage medium, which can solve the problem of a large amount of repeated transplantation and debugging when booting an application and reduce the workload of booting an application.

[0004] In a first aspect, an embodiment of the present application provides a method for guiding application startup, comprising:

[0005] Obtaining firmware from the application end or interactive device according to the received application startup instruction;

[0006] Perform validity check on the obtained firmware;

[0007] If the firmware is valid, the firmware is processed according to the pre-stored firmware upgrade rules to obtain the startup firmware;

[0008] If the firmware is invalid, re-acquire the firmware;

[0009] The application is started according to the startup firmware.

[0010] Furthermore, the firmware is obtained from the application end or the interactive device according to the received application startup instruction, specifically:

[0011] Perform interaction trigger detection based on the received application startup instruction;

[0012] If an interaction trigger is detected, the firmware in the interaction device is obtained;

[0013] If no interaction trigger is detected, the firmware pre-stored in the application side is obtained.

[0014] Furthermore, the validity check of the obtained firmware is specifically performed as follows:

[0015] Obtaining the first boot firmware pre-stored in the application end or in the interactive device, and obtaining the corresponding pre-stored firmware upgrade rules;

[0016] detecting the validity of the first boot firmware;

[0017] If the first startup firmware is valid, processing is performed according to the pre-stored firmware upgrade rule to obtain the startup firmware;

[0018] If the first boot firmware is invalid, the first boot firmware pre-stored in the application end or in the interactive device is re-acquired.

[0019] Furthermore, different pre-stored firmware upgrade rules are set corresponding to different firmwares, and an upgrade flag is included in the pre-stored firmware upgrade rules of at least one firmware;

[0020] The processing according to the pre-stored firmware upgrade rule to obtain the startup firmware is specifically as follows:

[0021] Matching the first startup firmware with a corresponding pre-stored firmware upgrade rule, and detecting whether an upgrade flag exists in the corresponding pre-stored firmware upgrade rule;

[0022] If the upgrade flag is present, the first boot firmware is upgraded to obtain a second boot firmware, the second boot firmware is stored in the application end, the upgrade flag in the corresponding pre-stored firmware upgrade rule is cleared, and the application is booted through the second boot firmware;

[0023] If the upgrade flag does not exist, the application is started through the first startup firmware.

[0024] Furthermore, the detecting the validity of the first boot firmware is specifically as follows:

[0025] Detecting the format validity and information validity of the first boot firmware, where the format validity of the first boot firmware is the sum and check validity of the firmware header information, and the information validity of the first boot firmware is the validity of the firmware size and the firmware loading address.

[0026] Furthermore, the interaction trigger includes any one of a key trigger, a device insertion trigger, and a serial port trigger.

[0027] Furthermore, the firmware is obtained from the application end or the interactive device, specifically:

[0028] Obtain the size information of the firmware from the application or interactive device, and obtain the firmware and callback processing data in segments according to the size information of the firmware until the firmware is completely obtained.

[0029] In a second aspect, an embodiment of the present application provides a device for guiding application startup, comprising: a firmware acquisition module, configured to acquire firmware from an application terminal or an interactive device according to a received application startup instruction;

[0030] The firmware validity detection module is used to detect the validity of the acquired firmware; if the firmware is valid, it is processed according to the pre-stored firmware upgrade rules to obtain the startup firmware; if the firmware is invalid, the firmware is re-acquired;

[0031] The boot application startup module is used to boot the application startup according to the startup firmware.

[0032] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0033] memory and one or more processors;

[0034] The memory is used to store one or more programs;

[0035] When the one or more programs are executed by the one or more processors, the one or more processors implement the boot application startup method as described in the first aspect.

[0036] In a fourth aspect, an embodiment of the present application provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute the boot application startup method as described in the first aspect.

[0037] The embodiment of the present application obtains firmware from the application end or interactive device according to the received application startup instruction when the boot application is started, and detects the validity of the obtained firmware, and processes the valid firmware according to the pre-stored firmware upgrade rules to obtain the startup firmware to boot the application. By adopting the above technical means, it is possible to obtain firmware from the application end or interactive device, so that a suitable firmware acquisition path can be selected when adapting to a new platform, thereby reducing a large amount of repeated transplantation and debugging work when adapting to a new platform, and reducing the workload of booting the application. In addition, the obtained valid firmware is processed according to the corresponding pre-stored upgrade rules to obtain the startup firmware, so as to ensure the validity and applicability of the upgraded startup firmware of the boot firmware, thereby reducing the failure of the boot application startup due to the incompatibility of the startup firmware, improving the success rate of the boot application startup, and improving the work efficiency of the boot application startup. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 This is a flowchart of a method for guiding application startup provided in Example 1 of the present application;

[0039] Figure 2 This is a schematic diagram of the full-function flow in Example 1 of the present application;

[0040] Figure 3 This is a flow chart of the interaction process in Example 1 of the present application;

[0041] Figure 4This is a flowchart of the firmware receiving process in Example 1 of the present application;

[0042] Figure 5 This is the firmware storage flow chart in Example 1 of the present application;

[0043] Figure 6 This is a structural diagram of a device for guiding application startup provided in Example 2 of the present application;

[0044] Figure 7 This is a structural diagram of an electronic device provided in Example 3 of the present application. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solutions and advantages of the present application clearer, the specific embodiments of the present application are further described in detail below in conjunction with the accompanying drawings. It is understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. It should also be noted that, for ease of description, only parts related to the present application, not all of the contents, are shown in the accompanying drawings. Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow charts describe each operation (or step) as a sequential process, many of the operations therein can be implemented in parallel, concurrently or simultaneously. In addition, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but can also have additional steps not included in the accompanying drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0046] The boot application startup method and device, electronic device, and storage medium provided in this application are designed to obtain firmware from an application or interactive device, allowing the selection of an appropriate firmware acquisition path when adapting to a new platform. This reduces the extensive repetitive porting and debugging work required when adapting to a new platform, and reduces the workload associated with boot application startup. Furthermore, the acquired valid firmware is processed according to pre-stored upgrade rules to obtain the startup firmware, ensuring the validity and applicability of the upgraded boot firmware. This reduces boot application startup failures due to boot firmware incompatibility, improves the success rate of boot application startup, and enhances boot application startup efficiency. Compared to traditional boot application startup methods, which are generally designed based on the software framework of each platform, each time a new platform is used, the software framework process must be redesigned repeatedly, even for the same requirements. Furthermore, differences in hardware resources between platforms require process adjustments. Furthermore, the varying code details within the boot application startup program based on each platform can lead to difficulties in code management and inconsistent problem verification. Based on this, the boot application startup method of the present application embodiment is provided to address the existing problem of requiring extensive repetitive debugging and increased workload in the boot application startup process.

[0047] Example 1:

[0048] Figure 1 A flowchart of a boot application startup method provided in Example 1 of the present application is given. The boot application startup method provided in this embodiment can be executed by a boot application startup device, which can be implemented by software and / or hardware. The boot application startup device can be composed of two or more physical entities, or it can be composed of one physical entity.

[0049] The following description is based on the Bootloader as the main body of the boot application startup method. Figure 1 and Figure 2 , the boot application startup method specifically includes:

[0050] S101. Obtain firmware from an application terminal or an interactive device according to a received application startup instruction.

[0051] Specifically, an interaction trigger detection is performed according to the received application startup instruction; if an interaction trigger is detected, the firmware in the interaction device is obtained; if no interaction trigger is detected, the firmware pre-stored in the application end is obtained.

[0052] Furthermore, an interaction trigger detection is performed based on the received application startup instruction; if an interaction trigger is detected, the firmware in the interactive device is obtained and stored in the storage location corresponding to the application end; if no interaction trigger is detected, the firmware pre-stored in the application end is obtained.

[0053] For example, refer to Figure 3 , performing interaction trigger detection according to the received application startup instruction, if the interaction trigger is detected, performing interactive selection in the display menu of the interactive device, displaying the corresponding firmware selection option in the display menu, selecting the firmware selection option in the display menu according to the interactive selection, performing option processing according to the selected firmware selection option, and obtaining the corresponding firmware according to the option processing.

[0054] For example, the display menu and the options within it must be registered before the interactive device is started. The options within the display menu are determined externally by a callback function. The menu callback function is fixed to register the options for that menu page, and the menu option callback function handles the options. Displaying the menu first registers all options for the current menu and then calls the display interface within the interactive device to display the menu contents.

[0055] Exemplarily, the interactive device is a serial port interaction or an LCD interaction. The serial port interaction is to display an interactive menu on a serial port debugging interface and receive interactive options through the serial port. The LCD interaction is to display a menu on a display screen and select an interactive option by touching the result.

[0056] Furthermore, the interaction trigger includes any one of a key trigger, a device insertion trigger, and a serial port trigger.

[0057] Exemplarily, the interaction trigger includes any one of a key trigger, a device insertion trigger, and a serial port trigger. The key trigger is triggered successfully when a target voltage level persists for a period of time. The device insertion trigger is triggered successfully when a block device is detected to be inserted and the target firmware is detected in the block device; the block device includes a USB flash drive or an SD card. The serial port trigger is triggered successfully when a specified character, such as a carriage return, is received.

[0058] Further, refer to Figure 4 , according to the received application startup instruction, obtain the firmware from the application end or interactive device. Obtain the size information of the firmware from the application end or interactive device, and obtain the firmware and callback processing data in segments according to the size information of the firmware until the firmware is completely obtained.

[0059] For example, firmware data is retrieved in segments, with each segment immediately stored in the target location on the application until all data is received. Each segment is received in memory, with the size of the memory determined by each platform. Due to module coupling, firmware storage is handled externally using callback functions. Due to resource constraints, firmware upgrades are received in segments.

[0060] Exemplarily, the data is received via a block device file system such as a USB disk or an SD card, and / or is received via a serial port X-modem / Y-modem protocol.

[0061] S102, performing validity check on the obtained firmware; if the firmware is valid, processing it according to pre-stored firmware upgrade rules to obtain startup firmware; if the firmware is invalid, re-acquiring the firmware.

[0062] Specifically, refer to Figure 2 , obtain the first boot firmware pre-stored in the application end or in the interactive device, and obtain the corresponding pre-stored firmware upgrade rules; detect the validity of the first boot firmware; if the first boot firmware is valid, process it according to the pre-stored firmware upgrade rules to obtain the boot firmware; if the first boot firmware is invalid, re-obtain the first boot firmware pre-stored in the application end or in the interactive device.

[0063] Furthermore, different pre-stored firmware upgrade rules are set for different firmwares, and there is an upgrade flag in the pre-stored firmware upgrade rules of at least one firmware; the first startup firmware is matched with the corresponding pre-stored firmware upgrade rule, and it is detected whether there is an upgrade flag in the corresponding pre-stored firmware upgrade rule; if there is an upgrade flag, the first startup firmware is upgraded to obtain the second startup firmware, the second startup firmware is stored in the application end and the upgrade flag in the corresponding pre-stored firmware upgrade rule is cleared, and the application is guided to start through the second startup firmware; if there is no upgrade flag, the application is guided to start through the first startup firmware.

[0064] Further, refer to Figure 5 , detecting the format validity and information validity of the first boot firmware, where the format validity of the first boot firmware is the sum check validity of the firmware header information, and the information validity of the first boot firmware is the validity of the firmware size and the firmware loading address.

[0065] Specifically, when storage begins, the system first determines whether the offset value of the data to be stored is equal to 0. If so, the data is stored directly. If not, the system checks the format validity of the first boot firmware to determine whether the format is valid. If not, the result is returned, and the firmware is received again to begin the storage process. If the format is valid, the system checks the information validity of the first firmware to determine whether the information is valid. If so, the data is stored. If not, the result is returned, and the firmware is received again to begin the storage process. Data is only stored if both the format and information of the first boot firmware are valid. After storing the data, the offset value is refreshed, and the result is returned.

[0066] Exemplarily, the format validity judgment of the firmware only determines whether the checksum in the header information is valid, that is, only checks the integrity of the data itself; the firmware information validity judgment is processed by the judgment interface in the implementation device, and the firmware size, firmware loading address and other information are associated with the properties of the implementation device.

[0067] In one embodiment, the following device implementation cases are provided: Nor Flash, which stores according to the address information provided during registration and can support running firmware on the storage Flash; Nand Flash, which stores according to the block address information provided during registration; file system storage, in which the file system is mounted outside the module and the file operation interface is directly used within the module.

[0068] S103: Boot the application according to the startup firmware.

[0069] Specifically, refer to Figure 2, performing interaction trigger detection based on the received application startup instruction; if an interaction trigger is detected, obtaining the first startup firmware in the interactive device and storing it in the corresponding storage location on the application side; if no interaction trigger is detected, obtaining the first startup firmware pre-stored on the application side. Obtaining the corresponding pre-stored firmware upgrade rules; detecting the validity of the first startup firmware; if the first startup firmware is valid, processing it according to the pre-stored firmware upgrade rules to obtain the startup firmware; if the first startup firmware is invalid, re-obtaining the first startup firmware pre-stored on the application side or on the interactive device.

[0070] Furthermore, different pre-stored firmware upgrade rules are set for different firmwares, and there is an upgrade flag in the pre-stored firmware upgrade rules of at least one firmware; the first startup firmware is matched with the corresponding pre-stored firmware upgrade rule, and it is detected whether there is an upgrade flag in the corresponding pre-stored firmware upgrade rule; if there is an upgrade flag, the first startup firmware is upgraded to obtain the second startup firmware, the second startup firmware is stored in the application end and the upgrade flag in the corresponding pre-stored firmware upgrade rule is cleared, and the application is guided to start through the second startup firmware; if there is no upgrade flag, the application is guided to start through the first startup firmware.

[0071] Exemplarily, different pre-stored firmware upgrade rules are set for different firmwares, and there is an upgrade flag in the pre-stored firmware upgrade rules of at least one firmware. For example, firmware A, firmware B, and firmware C are stored, and there is no upgrade flag in the pre-stored upgrade rule corresponding to firmware A. Then, when obtaining firmware A to boot the application, after judging that firmware A is valid, based on the fact that there is no upgrade flag in the pre-stored upgrade rule matched by firmware A, the application is directly booted according to firmware A. If there is an upgrade flag in the pre-stored upgrade rule corresponding to firmware B, then when obtaining firmware B to boot and start, after judging that firmware B is valid, based on the fact that there is an upgrade flag in the pre-stored upgrade rule matched by firmware B, firmware B is upgraded to obtain the upgraded firmware B1, and firmware B1 is stored in the storage location corresponding to the application end, and the corresponding upgrade flag is deleted in the pre-stored firmware upgrade rule corresponding to firmware B1, and the application is booted according to the upgraded firmware B1.

[0072] For example, if the trigger check fails and the upgrade flag is not obtained, the application is directly booted to start; there are two situations for firmware acquisition. The first situation is that the BootLoader triggers the detection successfully, the menu interactive device is interactively selected, the firmware is received according to the interactively selected option, and the received firmware is stored in the corresponding running area and in the area where the firmware is pre-stored on the application side; after the firmware is stored in the running area, the boot reference is loaded and started. The second situation is to obtain the firmware from the pre-stored firmware area on the application side, and set the upgrade flag in the pre-stored firmware upgrade rule corresponding to the firmware. After reset, the BootLoader starts, and based on the failure of the trigger detection, the firmware obtained from the application side is checked for the upgrade flag. If the firmware is running on Flash, the upgrade process is entered, the upgraded firmware is refreshed to the running area, and then the process jumps to boot application startup. If the firmware is running on Ram, the application is directly loaded and enabled.

[0073] As described above, when the boot application is started, the firmware is obtained from the application end or the interactive device according to the received application startup instruction, and the validity of the obtained firmware is detected, and the valid firmware is processed according to the pre-stored firmware upgrade rules to obtain the startup firmware to boot the application. By adopting the above technical means, the firmware can be obtained from the application end or the interactive device, so that the appropriate firmware acquisition path can be selected when adapting to the new platform, thereby reducing a large amount of repeated transplantation and debugging work when adapting to the new platform, and reducing the workload of boot application startup. In addition, the obtained valid firmware is processed according to the corresponding pre-stored upgrade rules to obtain the startup firmware, so as to ensure the validity and applicability of the upgraded startup firmware of the boot firmware, thereby reducing the failure of the boot application startup due to the incompatibility of the startup firmware, improving the success rate of the boot application startup, and improving the work efficiency of the boot application startup.

[0074] Example 2:

[0075] Based on the above embodiments, Figure 6 This is a schematic diagram of the structure of a device for guiding application startup provided in Example 2 of this application. Figure 6 The boot application startup device provided in this embodiment specifically includes: a firmware acquisition module 21, a firmware validity detection module 22 and a boot application startup module 23.

[0076] Among them, the firmware acquisition module 21 is used to obtain firmware from the application end or interactive device according to the received application startup instruction; the firmware validity detection module 22 is used to perform validity detection on the acquired firmware; if the firmware is valid, it is processed according to the pre-stored firmware upgrade rules to obtain the startup firmware; if the firmware is invalid, the firmware is re-acquired; the boot application startup module 23 is used to boot the application startup according to the startup firmware.

[0077] Furthermore, the boot application startup device provided by this embodiment also includes a disabling module, which is used to disable interactive enablement or disable application-side enablement. When the disabling module is used to disable interactive enablement, it prohibits external interactive operations, obtains the first startup firmware pre-stored on the application side after receiving the startup application instruction, and performs validity judgment and upgrade mark detection on the first startup firmware. If it is judged that the first firmware is valid and there is no upgrade mark, the application startup is guided according to the first startup firmware. If it is judged that the first firmware is valid and there is an upgrade mark, the first startup firmware is upgraded to obtain the second startup firmware, and the application startup is guided according to the second startup firmware; if the first startup firmware is judged to be invalid, the first firmware is obtained from the application side again. By disabling the interactive enablement through the disabling module, the firmware acquisition and boot application startup processing process are directly performed from the application side, which reduces the waiting time for triggering, increases the speed of boot application startup, and improves work efficiency.

[0078] Furthermore, the boot application startup device provided in this embodiment also includes a disabling module, which is used to disable interactive enablement or disable application-side enablement. When the disabling module is used to disable application-side enablement, it directly obtains the first startup firmware from the interactive device to perform a startup operation after receiving the startup application instruction. For example, after the BootLoader is started, it detects the insertion of a USB flash drive, and the target upgrade firmware is stored in the USB flash drive. It automatically reads the firmware and refreshes it to the running area to boot the application. The application-side enablement is prohibited throughout the process, and no operation is performed on the application side. The boot application can be started by inserting the USB flash drive or SD card with the upgrade firmware in order, which increases the speed of booting the application and improves work efficiency.

[0079] As described above, when the boot application is started, the firmware is obtained from the application end or the interactive device according to the received application startup instruction, and the validity of the obtained firmware is detected, and the valid firmware is processed according to the pre-stored firmware upgrade rules to obtain the startup firmware to boot the application. By adopting the above technical means, the firmware can be obtained from the application end or the interactive device, so that the appropriate firmware acquisition path can be selected when adapting to the new platform, thereby reducing a large amount of repeated transplantation and debugging work when adapting to the new platform, and reducing the workload of boot application startup. In addition, the obtained valid firmware is processed according to the corresponding pre-stored upgrade rules to obtain the startup firmware, so as to ensure the validity and applicability of the upgraded startup firmware of the boot firmware, thereby reducing the failure of the boot application startup due to the incompatibility of the startup firmware, improving the success rate of the boot application startup, and improving the work efficiency of the boot application startup.

[0080] The boot application startup device provided in the second embodiment of the present application can be used to execute the boot application startup method provided in the above-mentioned first embodiment, and has corresponding functions and beneficial effects.

[0081] Example 3:

[0082] The third embodiment of the present application provides an electronic device, referring to Figure 7 The electronic device includes: a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The number of processors in the electronic device may be one or more, and the number of memories in the electronic device may be one or more. The processor, memory, communication module, input device, and output device of the electronic device may be connected via a bus or other means.

[0083] The memory 32, as a computer-readable storage medium, can be used to store software programs, computer executable programs and modules, such as the program instructions / modules corresponding to the boot application startup method described in any embodiment of the present application (for example, the firmware acquisition module, the firmware validity detection module and the boot application startup module in the boot application startup device). The memory may mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function; the data storage area can store data created according to the use of the device, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory may further include a memory remotely located relative to the processor, and these remote memories can be connected to the device via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0084] The communication module 33 is used for data transmission.

[0085] The processor 31 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory, that is, implements the above-mentioned boot application startup method.

[0086] The input device 34 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the device. The output device 35 may include a display device such as a display screen.

[0087] The electronic device provided above can be used to execute the boot application startup method provided in the above embodiment 1, and has corresponding functions and beneficial effects.

[0088] Example 4:

[0089] An embodiment of the present application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute a method for booting an application startup. The method includes: obtaining firmware from an application end or an interactive device according to a received application startup instruction; performing a validity check on the obtained firmware; if the firmware is valid, processing it according to pre-stored firmware upgrade rules to obtain startup firmware; if the firmware is invalid, re-obtaining the firmware; and booting the application startup according to the startup firmware.

[0090] Storage medium - any of various types of memory devices or storage devices. The term "storage medium" is intended to include: installation media, such as CD-ROMs, floppy disks, or tape drives; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (such as hard disks or optical storage); registers or other similar types of memory elements, etc. Storage media may also include other types of memory or combinations thereof. In addition, the storage medium may be located in the first computer system in which the program is executed, or it may be located in a different second computer system that is connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term "storage medium" may include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). The storage medium may store program instructions (e.g., embodied as a computer program) that can be executed by one or more processors.

[0091] Of course, the storage medium containing computer-executable instructions provided in an embodiment of the present application is not limited to the boot application startup method described above, and can also execute related operations in the boot application startup method provided in any embodiment of the present application.

[0092] The boot application startup device, storage medium and electronic device provided in the above embodiments can execute the boot application startup method provided in any embodiment of the present application. For technical details not described in detail in the above embodiments, please refer to the boot application startup method provided in any embodiment of the present application.

[0093] The above are only preferred embodiments of the present application and the technical principles employed. The present application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that are possible for those skilled in the art will not depart from the scope of protection of the present application. Therefore, although the present application has been described in more detail through the above embodiments, the present application is not limited to the above embodiments and may include more other equivalent embodiments without departing from the concept of the present application. The scope of the present application is determined by the scope of the claims.

Claims

1. A method for starting a boot application, characterized in that: include: Obtaining the first startup firmware from the application end or the interactive device according to the received application startup instruction, and obtaining the corresponding pre-stored firmware upgrade rules; wherein the method includes performing interaction trigger detection according to the received application startup instruction, and if an interaction trigger is detected, obtaining the firmware in the interactive device; if no interaction trigger is detected, obtaining the pre-stored firmware in the application end; the interaction trigger may include any one of a key trigger, a device insertion trigger, and a serial port trigger; The step of obtaining the first startup firmware from the application terminal or the interactive device is as follows: Obtain the firmware size information from the application or interactive device, and obtain the firmware and callback processing data in segments according to the firmware size information until the firmware is completely obtained; Performing a validity check on the obtained first startup firmware; setting different pre-stored firmware upgrade rules for different firmwares, and having an upgrade flag in the pre-stored firmware upgrade rules of at least one firmware; If the first boot firmware is valid, processing is performed according to pre-stored firmware upgrade rules to obtain the boot firmware; The processing according to the pre-stored firmware upgrade rule to obtain the startup firmware is specifically as follows: Matching the first startup firmware with a corresponding pre-stored firmware upgrade rule, and detecting whether an upgrade flag exists in the corresponding pre-stored firmware upgrade rule; If the upgrade flag is present, the first boot firmware is upgraded to obtain a second boot firmware, the second boot firmware is stored in the application end, the upgrade flag in the corresponding pre-stored firmware upgrade rule is cleared, and the application is booted through the second boot firmware; If the upgrade flag does not exist, booting the application through the first boot firmware; If the first boot firmware is invalid, the first boot firmware is obtained again from the application end or the interactive device.

2. The boot application startup method according to claim 1, characterized in that: Detecting the validity of the first boot firmware, specifically: Detecting the format validity and information validity of the first boot firmware, where the format validity of the first boot firmware is the sum and check validity of the firmware header information, and the information validity of the first boot firmware is the validity of the firmware size and the firmware loading address.

3. A device for booting an application, characterized in that: The method for guiding application startup according to any one of claims 1 to 2 is performed, including: a firmware acquisition module, configured to acquire first startup firmware from an application end or an interactive device according to a received application startup instruction, and specifically to perform interaction trigger detection according to the received application startup instruction, and if an interaction trigger is detected, acquire the firmware in the interactive device; if no interaction trigger is detected, acquire the firmware pre-stored in the application end; a firmware validity detection module, configured to detect the validity of the acquired first boot firmware; if the first boot firmware is valid, processing the firmware according to pre-stored firmware upgrade rules to obtain the boot firmware; if the first boot firmware is invalid, re-acquiring the first boot firmware pre-stored in the application end or in the interactive device; The boot application startup module is used to boot the application startup according to the startup firmware.

4. An electronic device, characterized in that: include: memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 2.

5. A storage medium containing computer-executable instructions, characterized in that: When the computer executable instructions are executed by a computer processor, they are used to perform the method according to any one of claims 1 to 2.

Images