CN111316235A - Method for starting system, electronic device and machine-readable storage medium - Google Patents
Method for starting system, electronic device and machine-readable storage medium Download PDFInfo
- Publication number
- CN111316235A CN111316235A CN201980005508.1A CN201980005508A CN111316235A CN 111316235 A CN111316235 A CN 111316235A CN 201980005508 A CN201980005508 A CN 201980005508A CN 111316235 A CN111316235 A CN 111316235A
- Authority
- CN
- China
- Prior art keywords
- firmware
- boot
- available
- partition
- loading
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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
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
A method for starting a system, an electronic device and a machine-readable storage medium are provided. A method for starting a system, applied to an electronic device installed with the system, where the electronic device includes a plurality of memory partitions, and each memory partition stores a firmware, the method comprising: selecting an available firmware from the plurality of firmware; the available firmware is loaded to boot the system. In the embodiment, a plurality of storage partitions are arranged, and one firmware is stored in each storage partition. Therefore, when the storage of the machine starting system is abnormal, an available firmware can be selected from the plurality of firmware, and then the available firmware is loaded to carry out system recovery, so that the normal use of the electronic equipment is ensured, and the use experience is improved.
Description
Technical Field
The embodiment of the invention relates to the technical field of control, in particular to a method for starting a system, electronic equipment and a machine-readable storage medium.
Background
Currently, an electronic device with an operating system installed therein loads firmware from a fixed file system partition during a boot process. When the firmware is damaged, for example, the file system partition is damaged, the firmware is damaged, the logic analysis is damaged, the upgrade fails, and the like, the electronic device may be abnormally started.
Disclosure of Invention
The embodiment of the invention provides a method for starting a system, electronic equipment and a machine-readable storage medium.
In a first aspect, an embodiment of the present invention provides a method for starting a system, which is applied to an electronic device installed with the system, where the electronic device includes a plurality of storage partitions, and each storage partition stores a firmware, and the method includes:
selecting an available firmware from the plurality of firmware;
the available firmware is loaded to boot the system.
In a second aspect, an embodiment of the present invention provides an electronic device, where the electronic device is installed with a system, and includes a boot chip and a plurality of memory partitions, where each memory partition stores a firmware, the boot chip loads a system loader in advance, and the system loader loads available firmware from the plurality of memory partitions according to the steps of the method in the first aspect to start the system.
In a third aspect, an embodiment of the present invention provides a machine-readable storage medium, on which computer instructions are stored, and when executed, the computer instructions implement the steps of the method in the first aspect.
As can be seen from the above technical solutions, in this embodiment, a plurality of storage partitions are provided, and one firmware is stored in each storage partition. Therefore, when the storage of the machine starting system is abnormal, an available firmware can be selected from the plurality of firmware, and then the available firmware is loaded to carry out system recovery, so that the normal use of the electronic equipment is ensured, and the use experience is improved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive labor.
Fig. 1 is a flowchart of a method for starting a system according to an embodiment of the present invention;
fig. 2 is a flowchart of a method for starting a system according to an embodiment of the present invention;
fig. 3 is a flowchart of verifying whether header information is complete according to an embodiment of the present invention;
FIG. 4 is a flow chart of determining available firmware provided by an embodiment of the invention;
fig. 5 is a flowchart illustrating a method for verifying whether a valid flag is a preset value according to an embodiment of the present invention;
fig. 6 is a flowchart illustrating another method for verifying whether a valid flag is a preset value according to an embodiment of the present invention;
FIG. 7 is a flowchart illustrating another method for verifying whether a valid flag is a preset value according to an embodiment of the present invention;
FIG. 8 is a flowchart of selecting an available firmware from a plurality of firmware according to an embodiment of the present invention;
FIG. 9 is a flow diagram of another method for selecting an available firmware from a plurality of firmware provided by an embodiment of the present invention;
FIG. 10 is a flowchart of a loading firmware boot system according to an embodiment of the present invention;
FIG. 11 is a flow chart of a firmware upgrade provided by an embodiment of the present invention;
FIG. 12 is a flowchart of a system loader upgrade provided by an embodiment of the present invention;
fig. 13 is an application scenario of a start system according to an embodiment of the present invention;
fig. 14 is an application scenario of the operation on the firmware after the firmware is loaded according to the embodiment of the present invention;
FIG. 15 is an application scenario of firmware upgrade provided by an embodiment of the present invention;
fig. 16 is an application scenario of upgrading Boot loader according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Currently, an electronic device with an operating system installed therein loads firmware from a fixed file system partition during a boot process. When the firmware is damaged, for example, the file system partition is damaged, the firmware is damaged, the logic analysis is damaged, the upgrade fails, and the like, the electronic device may be abnormally started.
Therefore, the embodiment of the invention provides a method for starting a system, and the invention conception is that a plurality of firmware can be set by utilizing the characteristic that a plurality of partitions exist in the system; and when the current firmware is not available, the system can be returned to the available firmware, so that the system can be started normally.
Fig. 1 is a flowchart of a method for booting a system according to an embodiment of the present invention, and referring to fig. 1, a method for booting a system is applied to an electronic device in which a system is installed, where the electronic device includes multiple firmware disposed in different memory partitions, and a system loader (Boot loader) may be stored in one of the multiple memory partitions. The system loading program can be pre-loaded by a Boot ROM of the electronic device, and then the method is completed due to the system loading program (Boot loader), wherein the method comprises steps 101 to 102, wherein:
in step 101, an available firmware is selected from the plurality of firmware.
In this embodiment, the number of the plurality of firmware and the number of the storage partitions may be the same or different. For example, when the number of the firmware blocks is the same, one firmware block may be stored in each memory partition, or more than two firmware blocks may be stored in a part of the memory partitions, and the firmware blocks are not stored in the remaining part of the memory partitions. If the number of the firmware is different from the number of the storage partitions, the firmware can be stored in part of the partitions in the plurality of storage partitions; if the number of the firmware is more than that of the storage partitions, more than two pieces of firmware can be stored in a part of the plurality of storage partitions, and one piece of firmware can be stored in the remaining part of the plurality of storage partitions. That is to say, a technician can adjust the number of the firmware in different partitions according to a specific scenario, so as to achieve the effect of storing a plurality of firmware in different storage partitions, and all of the corresponding schemes fall within the protection scope of the present application.
In this embodiment, the versions of the plurality of firmware may be the same or different. When the versions are the same, the plurality of firmware may be preset firmware when leaving a factory, or may be new firmware after each version upgrade. When the versions are different, the plurality of firmware may include firmware preset at the time of factory shipment and firmware of each version upgraded after factory shipment.
In one embodiment, the firmware in at least one memory partition is not erasable, such as pre-factory firmware, to ensure that the system is booted normally next time, in view of security issues.
In one embodiment, considering the loading order, if the versions of the multiple firmware are different, the different versions of the firmware may have different priorities, and the newer (later in the upgrade time) version of the firmware has higher priority; if the versions of the multiple firmware are the same, the priority of each firmware may be determined according to the precedence order (e.g., physical order, size of partition ID) of the multiple storage partitions. Of course, a technician may adjust the loading sequence of different firmware according to a specific scenario, for example, an identification code may be added to the same version of firmware, so as to form different firmware, and the solution of the present application may also be implemented, and the corresponding solution falls within the scope of the present application.
In an embodiment, the firmware is provided with preset information, and in this scenario, selecting an available firmware from a plurality of firmware may include: referring to fig. 2, the preset information of the firmware on each memory partition is verified (corresponding to step 201). Then, the firmware whose preset information passes the verification is determined as the usable firmware (corresponding to step 202). Thus, the available firmware in the plurality of firmware can be determined, and the determination efficiency is improved.
In this embodiment, the preset information at least includes header information and the header information at least includes a valid flag bit, in this scenario, referring to fig. 3, verifying the preset information of the firmware on each storage partition may include:
first, it is verified whether the header information of the firmware on each storage partition is complete (corresponding to step 301). Referring to fig. 4, in this embodiment, a first Check code may be generated based on file header information (corresponding to step 401), where the first Check code may be a Cyclic Redundancy Check (CRC), and certainly, the first Check code may also be a parity Check code or a hamming Check code, and under the condition that information Check can be implemented, the corresponding Check code and the using method fall within the protection scope of the present application. If the first check code is the same as the received check code, it is determined that the header information is complete (corresponding to step 402), otherwise, the header information is incomplete.
Continuing to refer to fig. 3, if the header information is not complete, the firmware is not available, and if the header information is complete, it is verified whether the valid flag bit in the header information is a preset value (corresponding to step 302). The preset value may be represented by a number, an alphabet, or a combination of a number and an alphabet, and is not limited herein.
In one example, verifying whether the valid flag bit is a preset value includes: referring to fig. 5, a value of the valid flag is obtained, if the valid flag is in verification, a load count of the firmware is obtained (corresponding to step 501), and then the load count and a maximum allowable load count are compared (corresponding to step 502), where the maximum allowable load count may be preset. If the number of times of loading is less than the maximum allowable number of times of loading, the valid flag is determined to be a preset value (corresponding to step 503).
It should be noted that the value of the valid flag includes at least one of the following: invalidation, freezing, verification of neutralization normal. The invalid state is a state that the loading times of the firmware exceed the maximum allowable loading times; freezing is a state in which the firmware cannot be loaded again in the processes of loading, upgrading and the like; the verification state refers to a state in which the number of loads is less than the maximum allowable number of loads, but the verification has not been passed.
In practical applications, step 502 may further include adjusting the value of the loading times of the firmware, for example, adding 1 to the current loading times of the firmware, and then updating the loading times of the firmware to the adjusted loading times, so as to facilitate the next loading of the firmware.
In another embodiment, verifying whether the valid flag is a preset value comprises: referring to fig. 6, if the valid flag is normal, it is determined whether the boot is normal (corresponding to step 601); if the computer is normally powered on, the valid flag is determined to be a preset value (step 602). Referring to fig. 7, if the firmware is abnormally powered on (e.g., restarted, powered off, etc.), a second check code of the firmware may be obtained (corresponding to step 701); wherein the second check code comprises at least one of: MD5 value, SHA1 value. Then, it is detected whether the second check code is identical to the received check code (corresponding to step 702). If the two bits are the same, the valid flag bit is determined to be a preset value (corresponding to step 703).
Continuing with fig. 3, if the valid flag is the preset value, it is determined that the preset information of the firmware is verified (corresponding to step 302). Otherwise, determining that the preset information of the firmware is not verified.
In another embodiment, the firmware may have a priority set thereon, and in this scenario, selecting an available firmware from the plurality of firmware may include: referring to fig. 8, the priority of each firmware may be obtained (corresponding to step 801), and the firmware with the priority may be used as the available firmware (corresponding to step 802). In order to ensure that each firmware with the priority is an available firmware, if the firmware is not available, the priority of the firmware is deleted, or the value of the priority is adjusted to be the lowest value (such as 0) or an invalid value (such as-1), so that the priority is ranked later or is not ranked any more, the selection efficiency is improved, and the boot speed is improved.
In yet another embodiment, selecting an available firmware from a plurality of firmware may include: referring to fig. 9, the available firmware loaded by the last boot-up may be obtained (corresponding to step 901), then the preset information is verified from the available firmware loaded by the last boot-up according to the descending order of the priority, and the firmware corresponding to the first verified preset information is taken as the available firmware of the current boot-up (corresponding to step 902). Since the processing is started from the available firmware loaded by the last boot, and generally, the probability of damage to the available firmware loaded by the last boot is low, the selection efficiency can be improved, and the boot speed can be increased in this embodiment.
In step 102, the available firmware is loaded to boot the system.
Referring to fig. 10, in the present embodiment, all system modules are initialized first in the process of starting the system (corresponding to step 1001); then, judging whether the valid flag bit of the current firmware is in verification (corresponding to step 1002), if so, setting the valid flag bit to be normal; if not, the verification is passed (corresponding to step 1003). Finally, the available firmware is loaded to start the system.
After the system is started, referring to fig. 11, the electronic device may also monitor the upgrade requirement of the firmware on each storage partition (corresponding to step 1101). If a firmware has an upgrade requirement, the complete firmware, the second check code of the received firmware, the storage partition where the firmware with the upgrade requirement is located, and the priority may be received in response to the upgrade requirement (corresponding to step 1102). If the second check code passes the check, it is determined that the firmware is successfully upgraded, the upgraded firmware is stored in a next partition of the storage partition where the firmware with the upgrade requirement is located, and the priority of the upgraded firmware is adjusted to be higher than that of the firmware with the upgrade requirement (corresponding to step 1103). That is to say, the priority of the upgraded firmware is higher than that of the firmware before upgrading, and the upgraded firmware is stored in the next storage partition on the premise of keeping the firmware needing to be upgraded, so that the number of the firmware is increased, and the success rate of starting the system is further improved.
It should be noted that the next partition is: and the effective zone bit of the partition physically adjacent to the storage partition where the firmware with the upgrading requirement is located, and the storage partition where the firmware with the invalid or frozen effective zone bit is located.
In addition, the upgraded firmware is effective at the next system start, so as to ensure the normal operation of the system after the system is started.
In one embodiment, the boot chip also monitors and upgrades the system loader. Referring to fig. 12, the boot chip may monitor the upgrade requirement of the system loader (corresponding to step 1201). The upgrading requirement can be autonomously searched by the system or set by a user, and the chip is guided to obtain the upgrading requirement of the system loading program by calling corresponding system information. Then, the boot chip may receive the complete system loader file and a third check code of the system loader file in response to an upgrade requirement of the system loader (corresponding to step 1202), where the third check code may be an MD5 code. If the third check code passes the check, the boot chip may determine that the system loader is successfully upgraded, and store the system loader file in a next partition of the storage partition where the system loader is located (corresponding to step 1203). Wherein the next partition is: the partition physically adjacent to the storage partition where the system loader is located, and the storage partition where the firmware with the highest priority is located. In this embodiment, by upgrading the system loader, it can be ensured that the system is started by the system loader of the latest version, thereby improving the starting efficiency.
To this end, in the present embodiment, a plurality of memory partitions are provided, and one firmware is stored in each memory partition. Therefore, when the storage of the machine starting system is abnormal, an available firmware can be selected from the plurality of firmware, and then the available firmware is loaded to carry out system recovery, so that the normal use of the electronic equipment is ensured, and the use experience is improved.
In combination with the method for starting the system, this embodiment provides an application scenario for starting the system, with reference to fig. 13, including:
1, after the electronic equipment is started, searching the firmware of each storage partition when a system loading program Boot loader runs, and checking whether the file header information of all the firmware is complete. If not, abandoning the firmware of the current storage partition, and continuously searching the firmware of the next storage partition; and if the file header information is complete, the next step 2 is carried out.
2, searching and analyzing a valid flag bit from the file header information, if the valid flag bit is Invalid (Invalid) or frozen (Freeze), abandoning the firmware of the current storage partition, and continuously searching the firmware of the next storage partition; otherwise proceed to the next step 3.
If the valid flag bit of the current firmware is ' verification ' (Verifying '), searching the loading times of the firmware, and if the loading times is greater than the maximum allowable loading times, considering that the firmware is invalid and setting the valid flag bit of the firmware to ' invalid '; otherwise, adding 1 to the number of times of loading the firmware, and setting the firmware as a candidate loading firmware.
And 4, if the valid flag bit of the current firmware is 'Normal', further judging whether the current boot is a Normal boot. If the boot-up belongs to abnormal boot-up, and the MD5 value of the firmware is detected to be abnormal, the firmware is considered to be invalid, and the valid flag bit of the firmware is set to be invalid; otherwise, the firmware is set as the candidate loading firmware.
And 5, after searching all the firmware of the storage partitions, selecting the firmware with the highest priority from the candidate loading firmware for loading.
Based on the steps 1-5, the electronic equipment can complete system starting and operate the system.
The embodiment further provides an application scenario for operating the firmware after loading the firmware, referring to fig. 14, including: and after the system is started, reading the storage partition and the priority of the current firmware, and storing the storage partition and the priority into the memory as the reserved priority. Then, after initializing all system modules, judging whether the effective zone bit of the current firmware is 'verification in process', if so, setting the effective zone bit to 'normal', otherwise, finishing the verification.
The embodiment further provides an application scenario of firmware upgrade, referring to fig. 15, including:
1, when the firmware needs to be upgraded online, firstly receiving the complete firmware and an MD5 value thereof, calculating an MD5 value of the firmware, and if the MD5 value fails to check, determining that the online upgrade fails; otherwise, the next step 2 is performed.
And 2, storing the new firmware into the next storage partition, and setting the priority of the firmware to be +1 of the reserved priority so as to ensure that the new firmware is effective when being started next time.
The embodiment further provides an application scenario for upgrading Boot loader, referring to fig. 16, including:
1, under the scene that a Boot chip Boot ROM supports Boot loaders with different file names in the same memory partition, if the Boot loaders need to be upgraded, MD5 verification is carried out on received bin files, and the bin files are stored in the partition where the Boot loaders are located and are named as names (Boot0010.bin) which have lower priority than the file name (Boot. bin) of the current Boot loader and have higher priority than the file name (Boot0020.bin) of a backup Boot loader. Then, the backup Boot loader (Boot0020.bin) is deleted, the current Boot loader (Boot. bin) is renamed to the name of the backup Boot loader (Boot0020.bin), and the new Boot loader (Boot0010.bin) is renamed to the name of the current Boot loader (Boot. bin).
2, in step 2, if an abnormality occurs in the process of renaming the current Boot loader (Boot. bin) to the backup Boot loader (Boot0020.bin), the Boot ROM takes the Boot0010.bin loaded as the Boot loader at the next Boot, and when the Boot loader is upgraded next time, the new Boot loader is saved in the Boot partition and then renamed to a temporary file name, the file name is changed to Boot. bin after passing the check, and then the Boot0010.bin is renamed to Boot0020.bin to change the Boot loader to the backup Boot loader.
In step 1, if an abnormality occurs in the process of renaming a new Boot loader (Boot0010.bin) to a current Boot loader (Boot. bin), the Boot ROM loads a backup Boot loader at the next Boot, saves the new Boot loader in a Boot partition and then renames the new Boot loader to a temporary file name at the next Boot loader upgrade, and changes the file name to the Boot. bin after the new Boot loader passes the verification.
Embodiments of the present invention also provide a machine-readable storage medium, on which computer instructions are stored, and when executed, the computer instructions implement the steps of the methods shown in fig. 1 to 16. The computer instruction may be executed by a processor or a Boot chip (Boot ROM), and the corresponding contents may refer to the contents of the embodiments shown in fig. 1 to 16, which are not described herein again.
It is noted that, herein, relational terms such as first and second, and the like may be 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. 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 an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The above detailed description of the detection apparatus and method provided by the embodiments of the present invention has been presented, and the present invention has been made by applying specific examples to explain the principle and the implementation of the present invention, and the above description of the embodiments is only used to help understanding the method and the core idea of the present invention; to sum up, the present disclosure should not be construed as limiting the invention, which will be described in the following description but will be modified within the scope of the invention by the spirit of the present disclosure.
Claims (26)
1. A method for starting a system, which is applied to an electronic device installed with the system, wherein the electronic device comprises a plurality of firmware arranged in different memory partitions, and the method comprises the following steps:
selecting an available firmware from the plurality of firmware;
the available firmware is loaded to boot the system.
2. The method of claim 1, wherein the versions of the plurality of firmware are different.
3. The method of claim 2, wherein the plurality of firmware includes factory preset firmware and factory upgraded firmware.
4. The method of claim 3, wherein the factory default firmware is not erasable.
5. The method of any one of claims 2 to 4, wherein different versions of firmware have different priorities, the priority of the newer version of firmware being higher.
6. The method of claim 1, wherein the versions of the plurality of firmware are the same.
7. The method of claim 1, wherein selecting an available firmware from the plurality of firmware comprises:
verifying preset information of the firmware on each storage partition;
and determining the firmware with the preset information passing the verification as the available firmware.
8. The method of claim 7, wherein the predetermined information at least includes header information and the header information at least includes a valid flag bit, and verifying the predetermined information of the firmware of each storage partition comprises:
verifying whether the file header information of the firmware on each storage partition is complete;
if the file header information is complete, verifying whether an effective flag bit in the file header information is a preset value;
and if the effective zone bit is a preset value, the preset information of the firmware passes verification.
9. The method of claim 8, wherein verifying whether the header information of the firmware on each storage partition is complete comprises:
generating a first check code based on the file header information;
and if the first check code is the same as the received check code, the file header information is complete.
10. The method of claim 8, wherein the value of the valid flag bit comprises at least one of: invalidation, freezing, verification of neutralization normal.
11. The method of claim 8, wherein verifying whether the valid flag bit in the header information is a preset value comprises:
if the effective flag bit is in verification, acquiring the loading times of the firmware;
comparing the loading times with the maximum allowable loading times;
and if the loading times are less than the maximum allowable loading times, determining that the effective zone bit is a preset value.
12. The method of claim 11, wherein determining the valid flag bit to be a preset value comprises:
and adjusting the numerical value of the loading times, and updating the loading times of the firmware into the adjusted loading times.
13. The method of claim 8, wherein verifying whether the valid flag bit in the header information is a preset value comprises:
if the effective flag bit is normal, judging whether the starting is normal or not;
and if the computer is normally started, determining the effective zone bit as a preset value.
14. The method of claim 13, further comprising:
if the boot is abnormal, acquiring a second check code of the firmware;
detecting whether the second check code is the same as the received check code;
and if the two are the same, determining that the effective zone bit is a preset value.
15. The method of claim 14, wherein the second parity code comprises at least one of: MD5 value, SHA1 value.
16. The method of claim 7, wherein determining the firmware with the preset information verified as the available firmware comprises:
acquiring the priority of each firmware;
the firmware with the highest priority is taken as the available firmware.
17. The method of claim 1, wherein selecting an available firmware from the plurality of firmware comprises:
acquiring available firmware loaded by last startup;
and according to the descending order of the priority, verifying the preset information from the available firmware loaded by the last boot, and taking the firmware corresponding to the first verified preset information as the available firmware of the boot.
18. The method of claim 1, wherein loading the available firmware to boot up a system comprises:
initializing all system modules;
judging whether the effective zone bit of the current firmware is in verification;
if yes, setting the effective zone bit to be normal; if not, the verification is passed;
the available firmware is loaded to boot the system.
19. The method of claim 18, further comprising:
monitoring the upgrading requirement of the firmware on each storage partition;
responding to the upgrading requirement, receiving the complete firmware, the second check code of the received firmware, the storage partition where the firmware with the upgrading requirement is located and the priority;
if the second check code passes the check, the firmware is determined to be successfully upgraded, the upgraded firmware is stored in the next partition of the storage partition where the firmware with the upgrade requirement is located, and the priority of the upgraded firmware is adjusted to be higher than that of the firmware with the upgrade requirement.
20. The method of claim 19, wherein the next partition is: and the effective zone bit of the partition physically adjacent to the storage partition where the firmware with the upgrading requirement is located, and the storage partition where the firmware with the invalid or frozen effective zone bit is located.
21. The method of claim 19, wherein the upgraded firmware is validated at a next system boot.
22. A method for starting a system according to claim 1, wherein a system loader Boot loader is stored in one of the plurality of memory partitions; the method further comprises the following steps:
loading the available firmware with the system loader to boot up a system; the system loading program is pre-loaded by a Boot ROM of a Boot chip in the electronic equipment.
23. A method of starting a system according to claim 22, the method further comprising:
monitoring the upgrading requirement of the system loading program;
responding to the upgrading requirement of the system loading program, and receiving a complete system loading program file and a third check code of the system loading program file;
and if the third check code passes the check, determining that the system loading program is successfully upgraded and storing the system loading program file in the next partition of the storage partition where the system loading program is located.
24. A method of starting up a system according to claim 23, characterised in that the next partition is: the partition physically adjacent to the storage partition where the system loader is located, and the storage partition where the firmware with the highest priority is located.
25. An electronic device, wherein the electronic device is equipped with a system and comprises a boot chip and a plurality of memory partitions, each memory partition having a firmware stored thereon, the boot chip having a system loader preloaded with system firmware, the system loader loading available firmware from the plurality of memory partitions to boot the system according to the steps of the method of any of claims 1 to 24.
26. A machine-readable storage medium having stored thereon computer instructions which, when executed, implement the steps of the method of any one of claims 1 to 24.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2019/080649 WO2020199027A1 (en) | 2019-03-29 | 2019-03-29 | Method for starting system, electronic device, and machine readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111316235A true CN111316235A (en) | 2020-06-19 |
Family
ID=71161145
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980005508.1A Pending CN111316235A (en) | 2019-03-29 | 2019-03-29 | Method for starting system, electronic device and machine-readable storage medium |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN111316235A (en) |
| WO (1) | WO2020199027A1 (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111897594A (en) * | 2020-07-10 | 2020-11-06 | 广东小天才科技有限公司 | Electronic equipment and firmware loading method and device thereof |
| CN112596798A (en) * | 2020-12-25 | 2021-04-02 | 珠海市一微半导体有限公司 | Chip starting control circuit and control method |
| CN112612524A (en) * | 2020-12-22 | 2021-04-06 | 西人马(西安)测控科技有限公司 | Method, device and equipment for starting Linux system and storage medium |
| CN116700061A (en) * | 2023-04-12 | 2023-09-05 | 广东为辰信息科技有限公司 | Quick starting method based on safe starting technology |
| CN116847019A (en) * | 2023-07-12 | 2023-10-03 | 荣耀终端有限公司 | Communication abnormality processing method, electronic device, and computer-readable storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110004871A1 (en) * | 2009-07-03 | 2011-01-06 | Inventec Appliances Corp. | Embedded electronic device and firmware updating method thereof |
| CN102339227A (en) * | 2010-07-28 | 2012-02-01 | 环旭电子股份有限公司 | Multi-firmware embedded system and firmware update method thereof |
| CN106776122A (en) * | 2016-11-23 | 2017-05-31 | 武汉光迅科技股份有限公司 | A kind of method of main-apparatus protection in start-up course based on Flash |
| CN109062517A (en) * | 2018-09-19 | 2018-12-21 | 郑州云海信息技术有限公司 | A kind of firmware redundancy approach, device, equipment and medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101605875B1 (en) * | 2009-04-03 | 2016-03-24 | 삼성전자주식회사 | Memory apparatus and method for updating firmware of the memory apparatus |
-
2019
- 2019-03-29 WO PCT/CN2019/080649 patent/WO2020199027A1/en active Application Filing
- 2019-03-29 CN CN201980005508.1A patent/CN111316235A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110004871A1 (en) * | 2009-07-03 | 2011-01-06 | Inventec Appliances Corp. | Embedded electronic device and firmware updating method thereof |
| CN102339227A (en) * | 2010-07-28 | 2012-02-01 | 环旭电子股份有限公司 | Multi-firmware embedded system and firmware update method thereof |
| CN106776122A (en) * | 2016-11-23 | 2017-05-31 | 武汉光迅科技股份有限公司 | A kind of method of main-apparatus protection in start-up course based on Flash |
| CN109062517A (en) * | 2018-09-19 | 2018-12-21 | 郑州云海信息技术有限公司 | A kind of firmware redundancy approach, device, equipment and medium |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111897594A (en) * | 2020-07-10 | 2020-11-06 | 广东小天才科技有限公司 | Electronic equipment and firmware loading method and device thereof |
| CN112612524A (en) * | 2020-12-22 | 2021-04-06 | 西人马(西安)测控科技有限公司 | Method, device and equipment for starting Linux system and storage medium |
| CN112596798A (en) * | 2020-12-25 | 2021-04-02 | 珠海市一微半导体有限公司 | Chip starting control circuit and control method |
| CN116700061A (en) * | 2023-04-12 | 2023-09-05 | 广东为辰信息科技有限公司 | Quick starting method based on safe starting technology |
| CN116700061B (en) * | 2023-04-12 | 2024-05-03 | 广东为辰信息科技有限公司 | Quick starting method based on safe starting technology |
| CN116847019A (en) * | 2023-07-12 | 2023-10-03 | 荣耀终端有限公司 | Communication abnormality processing method, electronic device, and computer-readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020199027A1 (en) | 2020-10-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111316235A (en) | Method for starting system, electronic device and machine-readable storage medium | |
| US11017091B2 (en) | Firmware map data | |
| CN107783776B (en) | Processing method and device of firmware upgrade package and electronic equipment | |
| US7320087B2 (en) | Information processing apparatus and method, program, and recording medium | |
| US7689981B1 (en) | Mobile handset with efficient interruption point detection during a multiple-pass update process | |
| CN106843947B (en) | Method and device for processing code defects | |
| CN106775674B (en) | Equipment based on universal boot loader and starting method thereof | |
| CN110597545A (en) | Hot patch intelligent upgrading method and system based on OTA component | |
| CN113238790B (en) | Firmware program updating method and system based on SD card and EEPROM | |
| CN106445737B (en) | Multi-backup starting method | |
| CN112631621A (en) | Dependency package management method, device, server and storage medium | |
| CN110908722B (en) | Method and device applied to starting of operating system, electronic equipment and storage medium | |
| US10691465B2 (en) | Method for synchronization of system management data | |
| CN115543429A (en) | Project environment building method, electronic equipment and computer readable storage medium | |
| CN105278993B (en) | A kind of drive module upgrade method and device based on linux system | |
| CN104216797B (en) | Embedded system setting value initialization system, method and electronic installation | |
| CN113703804A (en) | System upgrading method, system, device and storage medium | |
| CN113703823A (en) | BMC (baseboard management controller) firmware upgrading method and device, electronic equipment and storage medium | |
| CN115437674B (en) | Firmware upgrading method, device, medium and electronic equipment | |
| CN107967160B (en) | Method and device for updating operating system file through Boot Loader | |
| CN108021381A (en) | The upgrading method for one-chip computer and device of equipment | |
| US11507385B1 (en) | Embedded electronic device, boot method, and embedded electronic device readable recording medium with stored program | |
| CN116932006A (en) | Firmware updating operation method and system of BMC | |
| CN107451000B (en) | System upgrade detection method | |
| KR20240085104A (en) | Hybrid booting method, recording medium and device for performing it |
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 | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20200619 |