Bootloader updating and program starting control method and device and storage medium

Abstract

The invention relates to the technical field of internet-of-things upgrading, and discloses a boot loader updating and program starting control method and device and a storage medium. A flash memory driving program is stored in a second type memory through an APP, the flash memory driving program is controlled to eliminate an original boot loader stored in the second type memory, and the boot loader updating and program starting control method and device are achieved. And writing the new boot loader received by the APP into the first type of memory, so that the first type of memory is started by the new boot loader, namely updating the boot loader, repairing vulnerabilities, improving security, increasing functionality, meeting upgrading of laws and regulations and the like through the App and the flash drive program.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) upgrade technology, specifically to a bootloader update and program startup control method, device, and storage medium. Background Technology

[0002] As intelligent Internet of Things (IoT) devices are increasingly used in daily life, their functions are constantly being upgraded and iterated. Updating devices via Over-the-Air (OTA) technology has become an essential method.

[0003] Since IoT devices are mainly embedded devices, their executable code is stored in their own flash memory or external flash memory. It is erased or written by the boost circuit of the flash controller. The relevant method is to use a bootloader to flash the application (APP). However, the bootloader is burned into the controller's flash memory at the factory and is generally not rewritable. Due to the rapid product upgrades and short product development cycles, the bootloader may have some defects, which will make subsequent APP upgrades troublesome or even unusable. Summary of the Invention

[0004] In view of this, the present invention provides a bootloader update and program startup control method, device and storage medium to solve the problem that the bootloader is burned into the controller's Flash at the factory and is generally not rewritable. Due to the short product development cycle, the bootloader may have some defects, which will make subsequent APP upgrades troublesome or even unusable.

[0005] In a first aspect, the present invention provides a bootloader update method applied to an App stored in a first type of memory. The first type of memory contains multiple boot targets, and the App in the first type of memory is located at the address of a first boot target. The method includes: receiving a bootloader update instruction sent by a host computer; storing a flash driver in the bootloader update instruction in a second type of memory and running it, so that the flash driver erases the original bootloader code stored in the first type of memory; receiving new bootloader code sent by the host computer; and controlling the flash driver to write the new bootloader into the first type of memory, so that the first type of memory boots with the new bootloader.

[0006] The bootloader update method provided by this invention involves storing a flash driver in a second type of memory via an APP, controlling the flash driver to delete the original bootloader stored in the second type of memory, and writing the new bootloader received by the APP into a first type of memory, so that the first type of memory can start with the new bootloader. In other words, the bootloader is updated through the APP and the flash driver, which can fix vulnerabilities, improve security, increase functionality, and meet regulatory upgrades.

[0007] In an optional implementation, the method further includes: before receiving new bootloader code sent by the host computer, controlling the flash driver to set the original bootloader to an invalid state; and after writing the new bootloader code into the first type of memory, controlling the flash driver to set the new bootloader to an valid state.

[0008] This invention allows for setting an effective or invalid state for the bootloader, facilitating the accurate invocation of the latest upgraded bootloader to perform subsequent operations when the bootloader is invoked later.

[0009] In one alternative implementation, after the flash driver writes the new bootloader code into the first type of memory, the flash driver in the second type of memory is erased.

[0010] Once the new Bootloader update is complete, this invention can eliminate the FlashDriver downloaded in the second type of memory area, preventing accidental operation of the program.

[0011] Secondly, the present invention provides a program startup control method applied to a first type of memory. The first type of memory has multiple startup targets. An App in the first type of memory is placed at the address of a first startup target and is used to execute the bootloader update method of the first aspect or any corresponding embodiment described above. The bootloader in the first type of memory is placed at the address of a second startup target. After the first type of memory is powered on, the status of the programs in the second startup target and the first startup target is checked sequentially to see if they are valid. If the status of the program in the current startup target is found to be valid, the program at the address of the current startup target is controlled to start.

[0012] The program startup control method provided by this invention sets multiple startup targets in the Flash controller. After the controller is powered on, the validity of the program on each startup target is checked in turn. If it is invalid, the check continues. If it is valid, the program is started from the corresponding target, so that the program on the startup target in the Flash controller can be executed independently.

[0013] In an optional implementation, after the flash driver sets the original bootloader to an invalid state, and then responds to an anomaly in the first type of memory and powers on again, the method further includes: sequentially checking and determining that the state of the program in the second boot target is invalid, and the state of the program in the first boot target is valid; then controlling the APP at the address of the first boot target to start to receive the new bootloader code sent by the host computer; and controlling the flash driver to write the new bootloader into the first type of memory, so that the first type of memory starts with the new bootloader.

[0014] This invention addresses the issue of a controller malfunctioning during Bootloader updates. After a power cycle, if the Bootloader is detected as invalid, the APP can be accessed to re-execute the Bootloader update operation, ensuring a successful Bootloader update.

[0015] In one alternative implementation, the first type of memory is an in-vehicle controller or a home appliance controller.

[0016] Thirdly, the present invention provides a bootloader update device applied to an App stored in a first type of memory. The first type of memory contains multiple boot targets, and the App in the first type of memory is located at the address of a first boot target. The device includes: a driver download module, configured to receive a bootloader update instruction sent by a host computer, store the flash driver in the bootloader update instruction in a second type of memory, and run it so that the flash driver eliminates the original bootloader code stored in the first type of memory; and a bootloader update module, configured to receive new bootloader code sent by a host computer, and control the flash driver to write the new bootloader into the first type of memory so that the first type of memory boots with the new bootloader.

[0017] Fourthly, the present invention provides a program startup control device applied to a first type of memory. The first type of memory has multiple startup targets. An App in the first type of memory is placed at the address of a first startup target and is used to execute the bootloader update device provided in the third aspect above. The bootloader in the first type of memory is placed at the address of a second startup target. The address status detection module is used to check the status of the programs in the second startup target and the first startup target sequentially after the first type of memory is powered on. The program startup module is used to control the program at the address of the current startup target to start if the status of the program in the current startup target is found to be valid.

[0018] Fifthly, the present invention provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the bootloader update method of the first aspect or any corresponding embodiment thereof, or to execute the program startup control method of the second aspect or any corresponding embodiment thereof.

[0019] In a sixth aspect, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the bootloader update method of the first aspect or any corresponding embodiment thereof, or to execute the program startup control method of the second aspect or any corresponding embodiment thereof. Attached Figure Description

[0020] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 This is a structural diagram of an existing Flash controller;

[0022] Figure 2 This is an example diagram of the boot target settings in a Flash controller according to an embodiment of the present invention;

[0023] Figure 3 This is a schematic diagram of the bootloader update process according to an embodiment of the present invention;

[0024] Figure 4 This is an example diagram of a bootloader update according to an embodiment of the present invention;

[0025] Figure 5 This is a schematic diagram of another bootloader update process according to an embodiment of the present invention;

[0026] Figure 6 This is a flowchart illustrating the program startup control method according to an embodiment of the present invention;

[0027] Figure 7 This is a structural block diagram of a bootloader update apparatus according to an embodiment of the present invention;

[0028] Figure 8 This is a structural block diagram of a program startup control device according to an embodiment of the present invention;

[0029] Figure 9 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] In traditional Flash controllers, the bootloader and the application follow a specific order. Figure 1 The arrangement shown includes only one startup target. The Bootloader program is set at the address of the startup target. When the controller is powered on, the program can only start from the Bootloader corresponding to this unique startup target. Then the Bootloader starts the APP. During OTA, the APP jumps to the Bootloader to execute the APP update process.

[0032] The bootloader is burned into the controller's Flash memory at the factory and cannot be changed afterward. If the bootloader has vulnerabilities and needs to be upgraded, or if it needs to be upgraded due to regulations or other requirements, it cannot be done via OTA.

[0033] According to an embodiment of the present invention, a bootloader update method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] In this embodiment of the invention, the first type of memory can be Flash controller, and the second type of memory can be RAM. These are merely examples and not intended to be limiting. This embodiment provides a bootloader update method applied to an APP in the aforementioned first type of memory. The first type of memory has multiple boot targets. This application embodiment does not limit the number of boot targets set; it can be set according to the structure of the first type of memory. Generally, two or more boot targets are used as an example. For instance, the first type of memory, i.e., the Flash controller, includes a Bootloader and an APP, so two boot targets can be set accordingly. Figure 2As shown, they can be named Boot Target 1 and Boot Target 2 respectively. The Bootloader program is located at the address of Boot Target 1, and the App is located at the address of Boot Target 2. This is just an example; the App in the first type of memory is placed at the address of the first boot target. The "first" designation is only for differentiation and does not indicate any order. Figure 2 In the case of boot target 2, after the Flash controller is powered on, it will sequentially check the validity of the program at each boot target address. If the Bootloader at the address of boot target 1 is in a valid state, the Bootloader in boot target 1 can be started directly. If the Bootloader at the address of boot target 1 is in an invalid state, it will continue to check whether the APP at the address of boot target 2 is in a valid state. If the APP is in a valid state, the APP on boot target 2 can be started. This is just an example.

[0035] Figure 3 This is a flowchart of a bootloader update method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps:

[0036] Step S301: Receive the bootloader update instruction sent by the host computer, store the flash driver in the bootloader update instruction in the second type of memory and run it, so that the flash driver will eliminate the original bootloader code stored in the first type of memory.

[0037] In this embodiment of the invention, after receiving a bootloader update instruction sent by the host computer, the APP can determine that the Bootloader in the Flash controller needs to be updated, such as... Figure 4 As shown, the APP on the address of target 2 starts and can receive the bootloader update command sent by the host computer. It can then store the flash driver code in the bootloader update command in RAM for execution. At the same time, the RAM permissions can be set to executable. This allows the original bootloader code currently stored in the flash controller to be eliminated through the flash driver. This is just an example. Since the APP stores the flash driver in RAM and runs it independently after receiving the bootloader update command from the host computer, it does not need to modify the information in the controller. Therefore, if the APP experiences an abnormal power outage or communication interruption during the flash driver reception process, it will not have any impact on the flash controller.

[0038] Step S302: Receive the new bootloader code sent by the host computer, and control the flash memory driver to write the new bootloader into the first type of memory so that the first type of memory can be started with the new bootloader.

[0039] In this embodiment of the invention, the original bootloader code is eliminated through the flash driver, such as... Figure 4 As shown, the APP can receive new Bootloader code sent by the host computer, and then perform a write operation through FlashDriver to write the new Bootloader code into the Flash controller. Subsequently, the Flash controller can directly start with the new Bootloader code. This is just an example.

[0040] The bootloader update method provided by this invention involves storing a flash driver in a second type of memory via an APP, controlling the flash driver to delete the original bootloader stored in the second type of memory, and writing the new bootloader received by the APP into a first type of memory, so that the first type of memory can start with the new bootloader. In other words, the bootloader is updated through the APP and the flash driver, which can fix vulnerabilities, improve security, increase functionality, and meet regulatory upgrades.

[0041] This embodiment provides a bootloader update method, which can be used for APPs in the first type of memory described above. Figure 5 This is a flowchart of a bootloader update method according to an embodiment of the present invention, such as... Figure 5 As shown, the process includes the following steps:

[0042] Step S501: Receive the bootloader update instruction sent by the host computer, store the flash driver in the bootloader update instruction in the second type of memory and run it, so that the flash driver will erase the original bootloader code stored in the first type of memory. For details, please refer to... Figure 3 Step S301 of the illustrated embodiment will not be described again here.

[0043] Step S502: Control the flash memory driver to set the original bootloader to an invalid state.

[0044] In addition to eliminating the original bootloader code, this embodiment of the invention can also control the FlashDriver to set the original bootloader code stored in the Flash controller to an invalid state, ensuring that the original bootloader will not be called again in the future. This is just an example.

[0045] Step S503: Receive the new bootloader code sent by the host computer, and control the flash memory driver to write the new bootloader into the first type of memory, so that the first type of memory boots with the new bootloader. For detailed instructions, please refer to [link to detailed instructions]. Figure 3 Step S302 of the illustrated embodiment will not be described again here.

[0046] Step S504: Control the flash driver to set the new bootloader to an active state.

[0047] In this embodiment of the invention, after the APP receives a new bootloader, it can also control the FlashDriver to write the new bootloader to a new area in the Flash controller and set the new bootloader to a valid state, so that the new bootloader code in a valid state can be selected for subsequent operations when the bootloader starts.

[0048] This invention allows for setting an effective or invalid state for the bootloader, facilitating the accurate invocation of the latest upgraded bootloader to perform subsequent operations when the bootloader is invoked later.

[0049] Step S505: The flash memory driver in the second type of memory is eliminated.

[0050] Once the new bootloader update is complete, this invention can eliminate the FlashDriver downloaded to the RAM area, preventing accidental program operations.

[0051] This embodiment also provides a program startup control method, which can be used in the aforementioned first type of memory. The first type of memory has multiple startup targets, and the number of startup targets is not limited and can be set according to the structure of the first type of memory. For example, the first type of memory, i.e., the Flash controller, includes a Bootloader and an App, so two startup targets can be set accordingly. Figure 2 As shown, they can be named Boot Target 1 and Boot Target 2 respectively. The Bootloader program is located at the address of Boot Target 1, and the App is located at the address of Boot Target 2. This is just an example; the App in the first type of memory can be placed at the address of the first boot target. Figure 2 The second boot target is used to execute the bootloader update method described in the above embodiments. The bootloader is placed at the address of the second boot target, corresponding to... Figure 2 The startup target 1 in the example is only used as an example. Figure 6 This is a flowchart of a bootloader update method according to an embodiment of the present invention, such as... Figure 6 As shown, the process includes the following steps:

[0052] Step S601: After the first type of memory is powered on, check in turn whether the status of the program in the second boot target and the first boot target is valid.

[0053] Step S602: If the status of the program in the current startup target is found to be valid, then control the program at the address of the current startup target to start.

[0054] The first type of memory in this embodiment of the invention, namely the Flash controller, is configured with multiple boot targets. After the Flash controller is powered on, it can sequentially check the second boot target and the first boot target. If the program status of the second boot target is detected to be valid, the procedure operation is performed according to normal circumstances. For example, under normal circumstances, the Flash controller first starts the Bootloader, and then the Bootloader starts the APP to perform application operations. During OTA upgrade, the process jumps from the APP to the Bootloader to perform the APP update process. This is just an example.

[0055] If the Bootloader program in the second launch target is found to be invalid, then the APP program in the first launch target can be checked in turn. If it is valid, the APP program is controlled to start and execute operations. This is just an example.

[0056] The program startup control method provided by this invention has multiple startup targets set in the Flash controller. After the controller is powered on, the validity of the program on each startup target is checked in turn. If it is invalid, the check continues. If it is valid, the program is started from the corresponding target, so that the program on the startup target in the Flash controller can be executed independently.

[0057] In one optional implementation, after the flash memory driver sets the original bootloader to an invalid state, and then responds to an exception in the first type of memory and powers on again, the status of the program in the second boot target is checked and determined to be invalid, while the status of the program in the first boot target is valid. Then, the APP at the address of the first boot target is controlled to start to receive the new bootloader code sent by the host computer, and the flash memory driver is controlled to write the new bootloader into the first type of memory so that the first type of memory starts with the new bootloader.

[0058] In this embodiment of the invention, after the flash driver sets the original bootloader to an invalid state, if the first type of memory, i.e., the Flash controller, suddenly loses power or communication is interrupted, when the Flash controller is powered on again, it can sequentially check whether the boot target is valid. If the program of the second boot target is found to be invalid, and the program in the first boot target is determined to be valid, it can directly enter the APP at the address of the first boot target, so that the APP can receive the new bootloader code sent by the host computer and control the flash driver to write the new bootloader code into the Flash controller, so that the new bootloader code can be called when the bootloader starts. This is only an example.

[0059] If, after a partial update of the new bootloader, the flash controller suddenly loses power or communication is interrupted, when the flash controller is powered on again, it can sequentially check whether the boot target is valid. If the program of the second boot target is found to be invalid, and the program in the first boot target is determined to be valid, then it can directly enter the APP at the address of the first boot target and perform a new bootloader update operation. This is just an example.

[0060] This invention addresses the issue of a controller malfunctioning during Bootloader updates. Upon power-up, if the Bootloader is detected to be invalid, the APP can be accessed to re-execute the Bootloader update operation, ensuring a successful Bootloader update.

[0061] In one alternative implementation, if the Flash controller structure contains only the APP, it is stored at the address of the boot target 2. If the APP needs to be updated, the Flash Driver is downloaded first, then the Bootloader is downloaded to the location of the boot target 1. Then, the upper layer data is received through the Bootloader to update the APP. After the APP is updated, the Bootloader jumps to the APP and then erases the Bootloader again through the Flash Driver. This is just an example.

[0062] In an optional implementation, the first type of memory in this embodiment of the invention can be an in-vehicle controller or a home appliance controller. When it is an in-vehicle controller, for example, in the early stages of a Battery Management System (BMS) project, both the APP and the Bootloader may change. This solution can be used to update the Bootloader to meet the project schedule and functional requirements, that is, the Bootloader and APP can be developed simultaneously without waiting for the Bootloader to be fully developed before it can be used. When the first type of memory is a smart home device, if a vulnerability is found in the Bootloader, a remote upgrade and update is required. In an optional implementation, the above-mentioned bootloader update method can also be applied to the scenario of upgrading the BMS boot to a secure boot to increase protection capabilities. This is only an example and is not intended to limit the scope.

[0063] This embodiment also provides a bootloader update device and a program startup control device, which are used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0064] This embodiment provides a bootloader update device applied to an App stored in a first type of memory. The first type of memory contains multiple boot targets, and the App is located at the address of a first boot target. Figure 7 As shown, it includes: a driver download module 701, used to receive a bootloader update instruction sent by a host computer, store the flash driver in the bootloader update instruction in a second type of memory and run it, so that the flash driver will eliminate the original bootloader code stored in the first type of memory; and a bootloader update module 702, used to receive new bootloader code sent by a host computer, control the flash driver to write the new bootloader into the first type of memory, so that the first type of memory will start with the new bootloader.

[0065] In some optional implementations, the invalid state setting module is used to control the flash driver to set the original bootloader to an invalid state before receiving the new bootloader code sent by the host computer; the valid state setting module is used to control the flash driver to set the new bootloader to a valid state after writing the new bootloader code into the first type of memory.

[0066] In some alternative implementations, a driver elimination module is used to eliminate the flash driver in the first type of memory after the control flash driver has written new bootloader code into the first type of memory.

[0067] This embodiment provides a program startup control device applied to a first type of memory. The first type of memory has multiple startup targets. The APP in the first type of memory is placed at the address of the first startup target and is used to execute the aforementioned bootloader update device. The bootloader in the first type of memory is placed at the address of a second startup target, such as... Figure 8 As shown, the device includes:

[0068] The address status detection module 801 is used to check whether the status of the program in the second boot target and the first boot target is valid after the first type of memory is powered on; the program startup module 802 is used to control the program at the address of the current boot target to start if the status of the program in the current boot target is found to be valid.

[0069] In some optional implementations, after the flash memory driver sets the original bootloader to an invalid state, and then responds to an anomaly in the first type of memory and powers on again, the program startup control device further includes: a program status detection module, used to sequentially check and determine that the status of the program in the second startup target is invalid, and the status of the program in the first startup target is valid. Then, it controls the APP at the address of the first startup target to start to receive the new bootloader code sent by the host computer, and controls the flash memory driver to write the new bootloader into the first type of memory, so that the first type of memory starts with the new bootloader.

[0070] In some alternative implementations, the first type of memory is an in-vehicle controller or a home appliance controller.

[0071] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0072] In this embodiment, the bootloader device and the program startup control device are presented in the form of functional units. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0073] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 9As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 9 Take a processor 10 as an example.

[0074] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0075] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0076] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0077] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0078] The computer device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30, and output device 40 can be connected via a bus or other means. Figure 9 Taking the example of a connection between China and Israel via a bus.

[0079] Input device 30 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the computer device, such as a touchscreen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 40 may include display devices, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors). The aforementioned display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, displays, and plasma displays. In some alternative embodiments, the display device may be a touchscreen.

[0080] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0081] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0082] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined herein.

Claims

1. A bootloader update method, characterized in that, An app is applied to a first type of memory, wherein the first type of memory has multiple launch targets, and the app in the first type of memory is placed at the address of a first launch target. The method includes: The system receives a bootloader update instruction from the host computer, stores the flash driver in the bootloader update instruction in a second type of memory, and runs it so that the flash driver can eliminate the original bootloader code stored in the first type of memory. The system receives new bootloader code sent by the host computer and controls the flash memory driver to write the new bootloader into the first type of memory, so that the first type of memory can be started with the new bootloader.

2. The method according to claim 1, characterized in that, The method further includes: Before receiving the new bootloader code sent by the host computer, the control flash driver sets the original bootloader to an invalid state; After the new bootloader code is written into the first type of memory, the flash driver is controlled to set the new bootloader to an active state.

3. The method according to claim 1 or 2, characterized in that, After the flash driver writes the new bootloader code into the first type of memory, the flash driver in the second type of memory is erased.

4. A program startup control method, characterized in that, Applied to a first type of memory, the first type of memory has multiple boot targets, the APP in the first type of memory is placed at the address of the first boot target, and is used to execute the bootloader update method according to any one of claims 1-3, wherein the bootloader in the first type of memory is placed at the address of the second boot target, wherein, After the first type of memory is powered on, the status of the programs in the second boot target and the first boot target is checked sequentially to see if they are valid. If the status of the program in the current startup target is found to be valid, then the program at the address of the current startup target is controlled to start.

5. The method according to claim 4, characterized in that, The method further includes the following steps after the flash memory driver invalidates the original bootloader and then responds to a Type 1 memory exception and power is restored: If the status of the program in the second boot target is found to be invalid and the status of the program in the first boot target is valid, then the APP at the address of the first boot target is controlled to start to receive the new bootloader code sent by the host computer, and the flash memory driver is controlled to write the new bootloader into the first type of memory so that the first type of memory is started with the new bootloader.

6. The method according to claim 4, characterized in that, The first type of memory is an in-vehicle controller or a home appliance controller.

7. A bootloader update device, characterized in that, An app for use in a first type of memory, wherein the first type of memory has multiple launch targets, and the app in the first type of memory is placed at the address of a first launch target, the device comprising: The driver download module is used to receive the bootloader update instruction sent by the host computer, store the flash driver in the bootloader update instruction in the second type of memory and run it, so that the flash driver will eliminate the original bootloader code stored in the first type of memory; The bootloader update module is used to receive new bootloader code sent by the host computer and control the flash memory driver to write the new bootloader into the first type of memory so that the first type of memory can be started with the new bootloader.

8. A program start control device, characterized in that, Applied to a first type of memory, the first type of memory has multiple boot targets, the APP in the first type of memory is placed at the address of the first boot target, and is used to execute the bootloader update device as described in claim 7, wherein the bootloader in the first type of memory is placed at the address of the second boot target, wherein... The address status detection module is used to check the status of the programs in the second boot target and the first boot target sequentially after the first type of memory is powered on. The program startup module is used to control the program at the address of the current startup target to start if the status of the program in the current startup target is found to be valid.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the bootloader update method according to any one of claims 1 to 3, or to execute the program startup control method according to any one of claims 4 to 5.

10. A computer program product, characterized in that, The system includes computer instructions that cause a computer to execute the bootloader update method according to any one of claims 1 to 3, or to execute the program startup control method according to any one of claims 4 to 5.

Images