CN116541081A - Method, device, equipment and storage medium for managing startup loading of embedded system - Google Patents
Method, device, equipment and storage medium for managing startup loading of embedded system Download PDFInfo
- Publication number
- CN116541081A CN116541081A CN202310595533.8A CN202310595533A CN116541081A CN 116541081 A CN116541081 A CN 116541081A CN 202310595533 A CN202310595533 A CN 202310595533A CN 116541081 A CN116541081 A CN 116541081A
- Authority
- CN
- China
- Prior art keywords
- embedded system
- bootloader
- program
- bootloader program
- updated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4406—Loading of operating system
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a startup loading management method, device and equipment of an embedded system and a storage medium, which belong to the field of embedded systems and are used for managing BootLoader of the embedded system. In consideration of the fact that program errors brought in the upgrading process of the BootLoader program may influence the normal starting of the embedded system, two BootLoader programs are prestored in the embedded system, only the BootLoader programs which are not called when the embedded system is started in the upgrading process are upgraded, and therefore even if the BootLoader programs of the new version are in error, the BootLoader programs of the correct historical version can be called to execute initialization work, normal starting of the embedded system is guaranteed, and user experience and working efficiency are improved.
Description
Technical Field
The present invention relates to the field of embedded systems, and in particular, to a method for managing boot loading of an embedded system, and a device, apparatus, and storage medium for managing boot loading of an embedded system.
Background
In an embedded operating system (for short, the embedded system), bootLoader is a task before the kernel of the operating system runs, and the BootLoader can initialize hardware equipment and establish a memory space map, so that the software and hardware environment of the system is brought into a proper state, and a correct environment is prepared for finally calling the kernel of the operating system; the program of BootLoader has update requirement, and if program errors are caused by unexpected situations in the update process or errors exist in the new version program, the embedded system can not be started normally, so that user experience and working efficiency are reduced.
Therefore, how to provide a solution to the above technical problem is a problem that a person skilled in the art needs to solve at present.
Disclosure of Invention
The invention aims to provide a startup loading management method of an embedded system, which only upgrades the BootLoader program which is not called when the embedded system is started in the upgrading process, even if the BootLoader program of a new version is in error, the BootLoader program of a correct historical version can be called to execute initialization work, thereby ensuring the normal startup of the embedded system and improving user experience and working efficiency; the invention also aims to provide a startup load management device, equipment and a storage medium of the embedded system, wherein only the BootLoader program which is not called when the embedded system is started is upgraded in the upgrading process, and even if the BootLoader program of a new version is in error, the BootLoader program of a correct historical version can be called to execute initialization work, so that the normal startup of the embedded system is ensured, and the user experience and the working efficiency are improved.
In order to solve the technical problems, the invention provides a startup loading management method of an embedded system, comprising the following steps:
responding to an upgrade instruction for starting and loading a BootLoader program, and determining the BootLoader program called when the embedded system is started and the BootLoader program not called;
marking the called BootLoader program as a historical version, marking the non-called BootLoader program as an updated version, and replacing the non-called BootLoader program with the BootLoader program of the new version;
when the embedded system is started, judging whether the BootLoader program calling the updated version can successfully start the embedded system;
if not, calling the BootLoader program of the history version to execute initialization work so as to start the embedded system;
wherein, two BootLoader programs are prestored in the embedded system.
Preferably, the marking the called BootLoader program as a history version and marking the non-called BootLoader program as an updated version specifically includes:
constructing a first metadata structure to be updated, wherein the first metadata structure to be updated comprises: the historically activated BootLoader partition is the BootLoader partition where the called BootLoader program is located, and the currently activated BootLoader partition is the BootLoader partition where the non-called BootLoader program is located;
determining a first firmware metadata storage area and another second firmware metadata storage area of a metadata structure used by the embedded system in the current startup;
judging whether the first metadata structure to be updated can be successfully written into the second firmware metadata storage area;
if the upgrade is unsuccessful, judging that the upgrade fails;
if so, writing the first metadata structure to be updated into the first firmware metadata storage area;
two firmware metadata storage areas are preset in the embedded system, the BootLoader program of the updated version is the BootLoader program in the BootLoader partition which is activated currently, and the BootLoader program of the historical version is the BootLoader program in the BootLoader partition which is activated historically;
when the embedded system is started, judging whether the BootLoader program calling the updated version can successfully start the embedded system or not specifically comprises the following steps:
when the embedded system is started, determining a firmware metadata storage area to be read from the two firmware metadata storage areas;
invoking the BootLoader program of the updated version from the currently activated BootLoader partition indicated by the metadata structure in the firmware metadata storage area to be read;
judging whether the BootLoader program calling the updated version can successfully start the embedded system.
Preferably, when the embedded system is started, the determining the firmware metadata storage area to be read from the two firmware metadata storage areas specifically includes:
when the embedded system is started, determining the firmware metadata storage areas to be verified from the two firmware metadata storage areas according to a preset priority order;
judging whether the metadata structure in the firmware metadata storage area to be verified is accurate or not;
if so, taking the firmware metadata storage area to be verified as a firmware metadata storage area to be read;
and if not, executing the step of determining the firmware metadata storage areas to be verified from the two firmware metadata storage areas according to the preset priority order.
Preferably, after the first metadata structure to be updated is written into the first firmware metadata storage area, the boot loader management method of the embedded system further includes:
judging whether the first metadata structure to be updated is successfully written into the first firmware metadata storage area;
if so, judging that the upgrading is successful;
if not, judging that the upgrading is failed;
the control prompter prompts the result of success or failure of upgrading.
Preferably, the first metadata structure to be updated further includes a BootLoader test mode being true;
the judging whether the BootLoader program calling the updated version can successfully start the embedded system specifically comprises the following steps:
judging whether a BootLoader test mode in a metadata structure in the firmware metadata storage area to be read is true or not;
if not, running the BootLoader program of the updated version and judging whether the embedded system can be started successfully;
if the boot loader program can be successfully started, judging that the BootLoader program calling the updated version can successfully start the embedded system, otherwise, judging that the BootLoader program calling the updated version cannot successfully start the embedded system;
if true, judging whether the current test times reach a preset threshold value or not;
if so, judging that the BootLoader program calling the updated version cannot successfully start the embedded system;
and if not, adding the test times and executing the BootLoader program running the updated version, and judging whether the embedded system can be started successfully.
Preferably, the step of calling the BootLoader program of the history version to execute initialization work so as to start the embedded system is specifically:
constructing a second metadata structure to be updated, the second metadata structure to be updated comprising: the role of the BootLoader partition activated at present is exchanged with that of the BootLoader partition activated in history;
judging whether the second metadata structure to be updated can be successfully written into the second firmware metadata storage area;
if so, writing the second metadata structure to be updated into the first firmware metadata storage area;
invoking a BootLoader program in the currently activated BootLoader partition to invoke the BootLoader program of the history version to execute initialization work;
after the BootLoader program of the history version is called to successfully start the embedded system, a third metadata structure to be updated is constructed as follows: and the BootLoader test mode is false, and the third metadata structure to be updated is written into the two firmware metadata storage areas.
Preferably applied to a processor;
the program corresponding to the startup loading management method of the embedded system is independent of the chip curing code BootROM of the embedded system.
In order to solve the technical problem, the invention also provides a startup loading management device of the embedded system, comprising:
the determining module is used for responding to an upgrading instruction for starting and loading the BootLoader program and determining the BootLoader program which is called when the embedded system is started and the BootLoader program which is not called when the embedded system is started;
the action module is used for marking the called BootLoader program as a historical version, marking the non-called BootLoader program as an updated version and replacing the non-called BootLoader program with the BootLoader program of the new version;
the judging module is used for judging whether the BootLoader program calling the updated version can successfully start the embedded system when the embedded system is started, and triggering the calling module if the BootLoader program calling the updated version can not be started successfully;
the operation module is used for calling the BootLoader program of the history version to execute initialization work so as to start the embedded system;
wherein, two BootLoader programs are prestored in the embedded system.
In order to solve the technical problem, the present invention further provides a startup load management device of an embedded system, including:
a memory for storing a computer program;
and the processor is used for realizing the steps of the startup loading management method of the embedded system when executing the computer program.
To solve the above technical problem, the present invention further provides a computer readable storage medium, on which a computer program is stored, which when executed by a processor, implements the steps of the startup load management method of an embedded system as described above.
The invention provides a startup loading management method of an embedded system, which considers that program errors brought in the upgrading process of a BootLoader program can influence the normal startup of the embedded system, so that the two BootLoader programs are prestored in the embedded system, and only the BootLoader program which is not called when the embedded system is started is upgraded in the upgrading process, therefore, even if the BootLoader program of a new version is in error, the BootLoader program of a correct historical version can be called to execute initialization work, thereby ensuring the normal startup of the embedded system, and improving user experience and working efficiency.
The invention also provides a device and equipment for managing the startup loading of the embedded system and a computer readable storage medium, which have the same beneficial effects as the startup loading management method of the embedded system.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required in the prior art and the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic flow chart of a method for managing boot loader of an embedded system according to the present invention;
FIG. 2 is a flow chart of another method for managing boot loader of an embedded system according to the present invention;
FIG. 3 is a flowchart illustrating a method for managing boot loader of an embedded system according to the present invention;
FIG. 4 is a schematic diagram of a configuration of a startup load management device of an embedded system according to the present invention;
fig. 5 is a schematic structural diagram of a startup load management device of an embedded system according to the present invention.
Detailed Description
The invention has the core of providing a startup loading management method of an embedded system, wherein only the BootLoader program which is not called when the embedded system is started is upgraded in the upgrading process, even if the BootLoader program of a new version is in error, the BootLoader program of a correct historical version can be called to execute initialization work, thereby ensuring the normal startup of the embedded system and improving user experience and working efficiency; the invention further provides a startup loading management device, equipment and a storage medium of the embedded system, wherein only the BootLoader program which is not called when the embedded system is started is upgraded in the upgrading process, and even if the BootLoader program of a new version is in error, the BootLoader program of a correct historical version can be called to execute initialization work, so that the normal startup of the embedded system is ensured, and the user experience and the working efficiency are improved.
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Referring to fig. 1, fig. 1 is a flow chart of a method for managing boot loading of an embedded system according to the present invention, where the method for managing boot loading of an embedded system includes:
s101: responding to an upgrade instruction for starting and loading a BootLoader program, and determining the BootLoader program called when the embedded system is started and the BootLoader program not called;
specifically, considering the technical problem in the background art, in combination with considering that two BootLoader programs are pre-stored, only the other program except the BootLoader program which is started and called at this time is updated in the upgrading process, the reliability of the BootLoader program which is started and called at this time can be at least guaranteed, so that even if the BootLoader program of a new version is wrong, the BootLoader program of a correct historical version can be called to execute initialization work, and therefore the BootLoader program which is called when the embedded system is started and the BootLoader program which is not called at this time can be determined in response to the upgrading instruction for starting and loading the BootLoader program so as to serve as the data base of the subsequent steps.
Two BootLoader programs are prestored in the embedded system of the application.
S102: marking the called BootLoader program as a historical version, marking the non-called BootLoader program as an updated version, and replacing the non-called BootLoader program with the new version BootLoader program;
specifically, in order to upgrade the BootLoader program according to the thought of the application and enable the embedded system to smoothly find and run the BootLoader program with the updated version when the embedded system is started next time, in the embodiment of the invention, the called BootLoader program can be marked as a historical version, the non-called BootLoader program is marked as an updated version, and the non-called BootLoader program is replaced with the BootLoader program with the new version, so that upgrade work is completed, and preparation is made for restarting and running the BootLoader program with the updated version of the embedded system.
S103: when the embedded system is started, judging whether the BootLoader program calling the updated version can successfully start the embedded system;
specifically, when the embedded system is started or restarted, the BootLoader program of the updated version can be tried to be called, whether the BootLoader program of the updated version can be successfully started or not is judged, and if so, the BootLoader program updated at the time is reliable.
S104: if not, calling the BootLoader program of the historical version to execute initialization work so as to start the embedded system;
two BootLoader programs are prestored in the embedded system.
Specifically, even if the embedded system cannot be successfully started by calling the BootLoader program of the updated version, the initialization work can be executed by calling the BootLoader program of the historical version at the moment so as to start the embedded system, so that the normal starting and working of the embedded system are ensured, and the working efficiency and the user experience are improved.
The invention provides a startup loading management method of an embedded system, which considers that program errors brought in the upgrading process of a BootLoader program can influence the normal startup of the embedded system, so that the two BootLoader programs are prestored in the embedded system, and only the BootLoader program which is not called when the embedded system is started is upgraded in the upgrading process, therefore, even if the BootLoader program of a new version is in error, the BootLoader program of a correct historical version can be called to execute initialization work, thereby ensuring the normal startup of the embedded system, and improving user experience and working efficiency.
Based on the above embodiments:
as a preferred embodiment, the called BootLoader program is marked as a history version, and the non-called BootLoader program is marked as an updated version specifically as follows:
constructing a first metadata structure to be updated, the first metadata structure to be updated comprising: the BootLoader partition activated in history is the BootLoader partition where the called BootLoader program is located, and the BootLoader partition activated in current is the BootLoader partition where the non-called BootLoader program is located;
determining a first firmware metadata storage area and another second firmware metadata storage area of a metadata structure used by the embedded system in the starting;
judging whether the first metadata structure to be updated can be successfully written into the second firmware metadata storage area;
if the upgrade is unsuccessful, judging that the upgrade fails;
if so, writing the first metadata structure to be updated into a first firmware metadata storage area;
two firmware metadata storage areas are preset in the embedded system, the BootLoader program of the updated version is the BootLoader program in the BootLoader partition which is activated currently, and the BootLoader program of the historical version is the BootLoader program in the BootLoader partition which is activated historically;
when the embedded system is started, judging whether the BootLoader program calling the updated version can successfully start the embedded system or not, wherein the method specifically comprises the following steps:
when the embedded system is started, determining a firmware metadata storage area to be read from the two firmware metadata storage areas;
invoking the updated version of BootLoader program from the currently activated BootLoader partition indicated by the metadata structure in the firmware metadata storage area to be read;
judging whether the BootLoader program calling the updated version can successfully start the embedded system.
For better illustrating the embodiments of the present invention, please refer to fig. 2 and fig. 3, fig. 2 is a flow chart of another method for managing boot loader of an embedded system according to the present invention; fig. 3 is a schematic flow chart of a boot loader management method of an embedded system according to the present invention, in fig. 2, a BootLoader image is a BootLoader program, a BootLoader storage area, that is, a BootLoader partition where the BootLoader program is located, and a "read-back check" determines whether to successfully update a metadata structure, and in fig. 3, a rollback mechanism is related operations of "starting a system through a historical version BootLoader program" when the embedded system cannot be successfully started through an updated BootLoader program in a starting process.
Specifically, considering that the possibility of errors exists in the marking made for the BootLoader program, a redundant metadata structure is designed in the application, and is used for redundantly storing data such as the marking of the BootLoader program, so that the reliability of BootLoader program management is further ensured, two firmware metadata storage areas are preset in the embedded system in the application, and a part of metadata structure is respectively stored, so that the task of marking the BootLoader program as above can be specifically: constructing a first metadata structure to be updated, the first metadata structure to be updated comprising: the BootLoader partition activated in history is the BootLoader partition where the called BootLoader program is located, and the BootLoader partition activated in current is the BootLoader partition where the non-called BootLoader program is located, that is, the BootLoader partition is marked by updating versions and historical versions of the BootLoader by defining the identity of each BootLoader partition.
In order to ensure the storage reliability of the metadata structure, in the embodiment of the invention, the metadata structure can be written into two firmware metadata storage areas respectively, firstly, the metadata structure to be updated can be accessed into a second firmware metadata storage area (namely, the firmware metadata storage area where the metadata structure which is not used in the starting of the embedded system is located), if the metadata structure cannot be successfully written into the second firmware metadata storage area, the metadata structure cannot be subjected to redundant storage, so that the upgrade failure can be directly judged, and after the metadata structure is successfully written into the second firmware metadata storage area, the updated metadata structure can be rewritten into the first firmware metadata storage area, thereby completing the redundant storage of the metadata structure, ensuring the safety of the metadata structure and improving the reliability of the BootLoader.
Specifically, when the embedded system is started, the BootLoader program of the updated version can be called from the BootLoader partition currently activated indicated by the metadata structure in the firmware metadata storage area to be read, so as to start the embedded system.
As a preferred embodiment, when the embedded system is started, determining the firmware metadata storage area to be read from the two firmware metadata storage areas specifically includes:
when the embedded system is started, determining a firmware metadata storage area to be verified from two firmware metadata storage areas according to a preset priority order;
judging whether the metadata structure in the firmware metadata storage area to be verified is accurate or not;
if so, taking the firmware metadata storage area to be verified as a firmware metadata storage area to be read;
if not, executing the step of determining the firmware metadata storage area to be verified from the two firmware metadata storage areas according to the preset priority order.
Specifically, in order to successfully and efficiently determine the firmware metadata storage area to be verified from the two firmware metadata storage areas, in the embodiment of the present invention, a priority order is preset, for example, the priority of one firmware metadata storage area is set to be the first bit, and the priority of the other firmware metadata storage area is set to be the second bit, so that the firmware metadata storage area of the first bit can be determined to be the firmware metadata storage area to be verified at each time of starting.
In the embodiment of the present invention, the metadata structure in the determined firmware metadata storage area to be verified may be verified each time, after verification is passed, the verified firmware metadata storage area may be used as the firmware metadata storage area to be read, otherwise, the step of determining the firmware metadata storage area to be verified from the two firmware metadata storage areas according to the preset priority order is re-performed, where it should be mentioned that, in the process of one start, when all the firmware metadata storage areas are determined as the firmware metadata storage area to be verified, that is, when there is no firmware metadata storage area "not determined as the firmware metadata storage area to be verified", the start failure may be determined, and the prompter may be controlled to prompt.
As a preferred embodiment, after writing the first metadata structure to be updated into the first firmware metadata storage area, the boot loader management method of the embedded system further includes:
judging whether the first metadata structure to be updated is successfully written into a first firmware metadata storage area;
if so, judging that the upgrading is successful;
if not, judging that the upgrading is failed;
the control prompter prompts the result of success or failure of upgrading.
Specifically, considering that even if the metadata structure to be updated is successfully written into the second firmware metadata storage area, there may be a possibility of failure when the first metadata structure to be updated is written into the first firmware metadata storage area, so in the embodiment of the present invention, it may be determined whether the first metadata structure to be updated is successfully written into the first firmware metadata storage area, if so, it may be determined that the upgrade is successful, otherwise, it may be determined that the upgrade is failed, and in order to facilitate a staff to timely obtain an upgrade result, in the embodiment of the present invention, the prompter may be controlled to prompt whether the upgrade is successful or not.
The prompter may be of various types, for example, may be a display, and the embodiment of the present invention is not limited herein.
As a preferred embodiment, the first metadata structure to be updated further includes a BootLoader test mode being true;
the method for judging whether the BootLoader program calling the updated version can successfully start the embedded system specifically comprises the following steps:
judging whether a BootLoader test mode in a metadata structure in a firmware metadata storage area to be read is true or not;
if not, running the BootLoader program of the updated version and judging whether the embedded system can be started successfully;
if the boot loader program can be successfully started, judging that the BootLoader program calling the updated version can successfully start the embedded system, otherwise, judging that the BootLoader program calling the updated version cannot successfully start the embedded system;
if true, judging whether the current test times reach a preset threshold value or not;
if the boot loader program is up, judging that the boot loader program calling the updated version cannot successfully start the embedded system;
if not, adding the test times and executing the BootLoader program of the updated version, and judging whether the embedded system can be started successfully.
Specifically, considering that even if the BootLoader program is updated successfully, the embedded system cannot be started by the BootLoader program of the updated version, so that in the embodiment of the invention, a test mode can be set, when the BootLoader program is updated, the BootLoader test mode in the metadata structure is set to be true, when the embedded system is started, whether the BootLoader test mode in the metadata structure in the metadata storage area of the firmware metadata to be read is true or not can be judged, if not true, the BootLoader program of the updated version can be directly operated, and if true, the BootLoader program of the updated version needs to be tested, at the moment, whether the current test frequency reaches a preset threshold value or not can be judged, if not, the BootLoader program of the updated version needs to be continuously tested, the test frequency can be added and executed, and whether the embedded system can be successfully started or not can be judged, when the preset threshold value is reached, the test for a plurality of times can be failed, and the BootLoader program of the updated version can be judged to be called.
It should be noted that, after the embedded system is successfully started, the BootLoader test mode in the metadata structure may be changed to false, and the updating sequence may be that the second firmware metadata storage area is updated first, and then the first firmware metadata storage area is updated after the success.
Specifically, after the BootLoader program with the updated version is not successfully started, the next starting process may be triggered in various manners, for example, by manual triggering, etc., which is not limited herein.
As a preferred embodiment, the BootLoader program of the call history version performs an initialization operation to start the embedded system specifically:
constructing a second metadata structure to be updated, the second metadata structure to be updated comprising: the roles of the BootLoader partition activated at present and the BootLoader partition activated in history are exchanged;
judging whether the second metadata structure to be updated can be successfully written into a second firmware metadata storage area;
if so, writing the second metadata structure to be updated into the first firmware metadata storage area;
invoking a BootLoader program in the BootLoader partition currently activated so as to invoke a BootLoader program of a historical version to execute initialization work;
after the BootLoader program of the call history version successfully starts the embedded system, constructing a third metadata structure to be updated as follows: and the BootLoader test mode is false, and the third metadata structure to be updated is written into the two firmware metadata storage areas.
Specifically, considering that when it is determined that the embedded system cannot be successfully started by the BootLoader program of the updated version, the embedded system is also in the starting process, and at this time, the embedded system can be started by directly calling the BootLoader program of the history version, but in order to be able to update the metadata structure in time, so as to ensure that the embedded system is started by calling the BootLoader program of the history version successfully next time.
In consideration of that the test of the BootLoader program representing the updated version has failed after the BootLoader program calling the historical version successfully starts the embedded system, the test does not need to be continued, so that the metadata structure to be updated in the embodiment of the present invention may be constructed as follows: the BootLoader test mode is false, and the third metadata structure to be updated is written into the two firmware metadata storage areas, so that the BootLoader program (history version) in the currently activated BootLoader partition is not tested when the next starting is guaranteed.
As a preferred embodiment, applied to a processor;
the program corresponding to the startup loading management method of the embedded system is independent of the chip curing code BootROM of the embedded system.
Specifically, considering that the BootROM of the chip curing code BootROM of the embedded system may include some management programs for BootLoader, and the curing state cannot be flexibly changed, in order to improve the flexibility of logic change of the boot loader management method of the embedded system, the program corresponding to the boot loader management method of the embedded system in the embodiment of the invention is independent of the BootROM of the chip curing code BootROM of the embedded system.
In addition, it should be noted that in the embodiment of the present invention, a program (abbreviated as BLx boot code) corresponding to a boot loader management method of an embedded system, two firmware metadata storage areas, and two partitions for storing BootLoader programs are added to the embedded system, and the BLx boot code also corresponds to a storage area, where each storage area corresponds to an actually different physical media address. In particular, the two firmware metadata storage areas are binary storage of the data structure of the BLx boot code to be actually read and written, and in order to avoid the abnormality of the storage of the whole sector of the storage medium, the addresses of the two firmware metadata storage areas are specially limited to be located in different sectors.
Referring to the following table 1, table 1 is a table of contents of a metadata structure provided by the present invention;
TABLE 1
The Bootloader partition information array may include attribute identifiers such as Bootloader physical media (flash, EMMC (Embedded Multi Media Card, embedded multimedia card) partition UUID (Universally Unique Identifier, universal unique identifier) and Bootloader test mode.
Referring to fig. 4, fig. 4 is a schematic structural diagram of a startup load management device of an embedded system according to the present invention, where the startup load management device of the embedded system includes:
the determining module 41 is configured to determine, in response to an upgrade instruction for starting and loading a BootLoader program, a BootLoader program that is called when the embedded system is started this time and a BootLoader program that is not called;
the action module 42 is configured to mark the called BootLoader program as a history version, mark the non-called BootLoader program as an updated version, and replace the non-called BootLoader program with a new version BootLoader program;
the judging module 43 is configured to judge whether the BootLoader program calling the updated version can successfully start the embedded system when the embedded system is started, and if not, trigger the calling module 44;
the operation module 44 is configured to call a historical version BootLoader program to perform an initialization operation so as to start the embedded system;
two BootLoader programs are prestored in the embedded system.
For the description of the startup load management device of the embedded system provided by the embodiment of the present invention, reference is made to the foregoing embodiment of the startup load management method of the embedded system, and the embodiment of the present invention is not repeated herein.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a boot loader of an embedded system according to the present invention, where the boot loader of the embedded system includes:
a memory 51 for storing a computer program;
the processor 52 is configured to implement the steps of the boot load management method of the embedded system in the foregoing embodiment when executing the computer program.
For the introduction of the startup load management device for an embedded system provided by the embodiment of the present invention, reference is made to the foregoing embodiment of the startup load management method for an embedded system, and the embodiment of the present invention is not repeated herein.
The invention also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program realizes the steps of the startup load management method of the embedded system when being executed by a processor.
For the description of the computer readable storage medium provided in the embodiment of the present invention, please refer to the aforementioned embodiment of the startup load management method of the embedded system, and the embodiment of the present invention is not repeated here.
In the present specification, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different point from other embodiments, and identical and similar parts between the embodiments are all enough to refer to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant points refer to the description of the method section. It should also be noted that in this specification, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. The method for managing the startup loading of the embedded system is characterized by comprising the following steps:
responding to an upgrade instruction for starting and loading a BootLoader program, and determining the BootLoader program called when the embedded system is started and the BootLoader program not called;
marking the called BootLoader program as a historical version, marking the non-called BootLoader program as an updated version, and replacing the non-called BootLoader program with the BootLoader program of the new version;
when the embedded system is started, judging whether the BootLoader program calling the updated version can successfully start the embedded system;
if not, calling the BootLoader program of the history version to execute initialization work so as to start the embedded system;
wherein, two BootLoader programs are prestored in the embedded system.
2. The method for managing boot loader of an embedded system according to claim 1, wherein the marking the called BootLoader program as a history version and the marking the non-called BootLoader program as an updated version are specifically as follows:
constructing a first metadata structure to be updated, wherein the first metadata structure to be updated comprises: the historically activated BootLoader partition is the BootLoader partition where the called BootLoader program is located, and the currently activated BootLoader partition is the BootLoader partition where the non-called BootLoader program is located;
determining a first firmware metadata storage area and another second firmware metadata storage area of a metadata structure used by the embedded system in the current startup;
judging whether the first metadata structure to be updated can be successfully written into the second firmware metadata storage area;
if the upgrade is unsuccessful, judging that the upgrade fails;
if so, writing the first metadata structure to be updated into the first firmware metadata storage area;
two firmware metadata storage areas are preset in the embedded system, the BootLoader program of the updated version is the BootLoader program in the BootLoader partition which is activated currently, and the BootLoader program of the historical version is the BootLoader program in the BootLoader partition which is activated historically;
when the embedded system is started, judging whether the BootLoader program calling the updated version can successfully start the embedded system or not specifically comprises the following steps:
when the embedded system is started, determining a firmware metadata storage area to be read from the two firmware metadata storage areas;
invoking the BootLoader program of the updated version from the currently activated BootLoader partition indicated by the metadata structure in the firmware metadata storage area to be read;
judging whether the BootLoader program calling the updated version can successfully start the embedded system.
3. The method for managing boot loader of an embedded system according to claim 2, wherein the determining, from the two firmware metadata storage areas, the firmware metadata storage area to be read when the embedded system is booted is specifically:
when the embedded system is started, determining the firmware metadata storage areas to be verified from the two firmware metadata storage areas according to a preset priority order;
judging whether the metadata structure in the firmware metadata storage area to be verified is accurate or not;
if so, taking the firmware metadata storage area to be verified as a firmware metadata storage area to be read;
and if not, executing the step of determining the firmware metadata storage areas to be verified from the two firmware metadata storage areas according to the preset priority order.
4. The method for managing boot loader of an embedded system according to claim 2, wherein after said writing said first metadata structure to be updated into said first firmware metadata storage area, the method for managing boot loader of an embedded system further comprises:
judging whether the first metadata structure to be updated is successfully written into the first firmware metadata storage area;
if so, judging that the upgrading is successful;
if not, judging that the upgrading is failed;
the control prompter prompts the result of success or failure of upgrading.
5. The method for boot loader management of an embedded system according to claim 2, wherein said first metadata structure to be updated further comprises BootLoader test mode true;
the judging whether the BootLoader program calling the updated version can successfully start the embedded system specifically comprises the following steps:
judging whether a BootLoader test mode in a metadata structure in the firmware metadata storage area to be read is true or not;
if not, running the BootLoader program of the updated version and judging whether the embedded system can be started successfully;
if the boot loader program can be successfully started, judging that the BootLoader program calling the updated version can successfully start the embedded system, otherwise, judging that the BootLoader program calling the updated version cannot successfully start the embedded system;
if true, judging whether the current test times reach a preset threshold value or not;
if so, judging that the BootLoader program calling the updated version cannot successfully start the embedded system;
and if not, adding the test times and executing the BootLoader program running the updated version, and judging whether the embedded system can be started successfully.
6. The method for managing boot loader of an embedded system according to claim 5, wherein said invoking the BootLoader program of the history version performs an initialization operation to boot the embedded system is specifically:
constructing a second metadata structure to be updated, the second metadata structure to be updated comprising: the role of the BootLoader partition activated at present is exchanged with that of the BootLoader partition activated in history;
judging whether the second metadata structure to be updated can be successfully written into the second firmware metadata storage area;
if so, writing the second metadata structure to be updated into the first firmware metadata storage area;
invoking a BootLoader program in the currently activated BootLoader partition to invoke the BootLoader program of the history version to execute initialization work;
after the BootLoader program of the history version is called to successfully start the embedded system, a third metadata structure to be updated is constructed as follows: and the BootLoader test mode is false, and the third metadata structure to be updated is written into the two firmware metadata storage areas.
7. The boot loader management method of an embedded system according to any one of claims 1 to 6, applied to a processor;
the program corresponding to the startup loading management method of the embedded system is independent of the chip curing code BootROM of the embedded system.
8. A boot load management apparatus for an embedded system, comprising:
the determining module is used for responding to an upgrading instruction for starting and loading the BootLoader program and determining the BootLoader program which is called when the embedded system is started and the BootLoader program which is not called when the embedded system is started;
the action module is used for marking the called BootLoader program as a historical version, marking the non-called BootLoader program as an updated version and replacing the non-called BootLoader program with the BootLoader program of the new version;
the judging module is used for judging whether the BootLoader program calling the updated version can successfully start the embedded system when the embedded system is started, and triggering the calling module if the BootLoader program calling the updated version can not be started successfully;
the operation module is used for calling the BootLoader program of the history version to execute initialization work so as to start the embedded system;
wherein, two BootLoader programs are prestored in the embedded system.
9. A boot load management apparatus of an embedded system, comprising:
a memory for storing a computer program;
a processor for implementing the steps of the boot load management method of the embedded system according to any one of claims 1 to 7 when executing the computer program.
10. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the steps of the boot load management method of an embedded system according to any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310595533.8A CN116541081A (en) | 2023-05-24 | 2023-05-24 | Method, device, equipment and storage medium for managing startup loading of embedded system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310595533.8A CN116541081A (en) | 2023-05-24 | 2023-05-24 | Method, device, equipment and storage medium for managing startup loading of embedded system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116541081A true CN116541081A (en) | 2023-08-04 |
Family
ID=87443410
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310595533.8A Pending CN116541081A (en) | 2023-05-24 | 2023-05-24 | Method, device, equipment and storage medium for managing startup loading of embedded system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116541081A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN119718472A (en) * | 2025-02-27 | 2025-03-28 | 山东云海国创云计算装备产业创新中心有限公司 | Chip firmware management method, device, computer program product and storage medium |
-
2023
- 2023-05-24 CN CN202310595533.8A patent/CN116541081A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN119718472A (en) * | 2025-02-27 | 2025-03-28 | 山东云海国创云计算装备产业创新中心有限公司 | Chip firmware management method, device, computer program product and storage medium |
| CN119718472B (en) * | 2025-02-27 | 2025-05-30 | 山东云海国创云计算装备产业创新中心有限公司 | Chip firmware management method, device, computer program product and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8423991B2 (en) | Embedded network device and firmware upgrading method | |
| KR100750132B1 (en) | How to boot, automatically update software and recover from errors, and the system and computer-readable recording media recording the method | |
| US7694165B2 (en) | Automation of bare metal recoveries | |
| US7036007B2 (en) | Firmware architecture supporting safe updates and multiple processor types | |
| CN102165422B (en) | Firmware update device and method | |
| CN112394965B (en) | Battery management system upgrade and operation method, controller, battery management system and storage medium | |
| US20050033954A1 (en) | Computer system having BIOS with multiple memory block | |
| CN106775674B (en) | Equipment based on universal boot loader and starting method thereof | |
| CN108733517A (en) | SSD firmware upgrades guard method and device | |
| CN114265603B (en) | System upgrade method, device and electronic device based on asymmetric partitioning | |
| JP2001331327A (en) | Electronics | |
| US7533290B2 (en) | Microcode updating error handling apparatus and method thereof | |
| CN113157303A (en) | Upgrading method, embedded system, terminal and computer storage medium | |
| CN116541081A (en) | Method, device, equipment and storage medium for managing startup loading of embedded system | |
| US20050223268A1 (en) | Method of writing non-volatile memory that avoids corrupting the vital initialization code | |
| US20090138865A1 (en) | Performing an operating system upgrade without multiple system interruptions | |
| CN114356658A (en) | Processing method of firmware upgrading exception, computer equipment and readable storage medium | |
| US20210326125A1 (en) | Installing application program code on a vehicle control system | |
| CN114398087B (en) | Method for improving running stability of singlechip after program updating and singlechip | |
| CN113377425B (en) | Method and device for generating BMC firmware, method and device for starting BMC, and storage medium | |
| CN111124459B (en) | Method and device for updating service logic of FPGA cloud server | |
| KR101420026B1 (en) | A method, apparatus and computer program for loading files during a boot-up process | |
| CN112667444A (en) | System upgrading method, storage medium and terminal equipment | |
| US20260017047A1 (en) | Updating software using hybrid partitioning | |
| TWI775578B (en) | Embedded electronic devices, boot method and embedded electronic devices readable medium with stored programs |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |