CN112698985A - System starting method and system based on multi-partition technology firmware protection - Google Patents
System starting method and system based on multi-partition technology firmware protection Download PDFInfo
- Publication number
- CN112698985A CN112698985A CN202011521569.4A CN202011521569A CN112698985A CN 112698985 A CN112698985 A CN 112698985A CN 202011521569 A CN202011521569 A CN 202011521569A CN 112698985 A CN112698985 A CN 112698985A
- Authority
- CN
- China
- Prior art keywords
- firmware
- boot
- backup
- 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
- 238000005192 partition Methods 0.000 title claims abstract description 171
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000005516 engineering process Methods 0.000 title claims abstract description 16
- 238000003860 storage Methods 0.000 claims abstract description 34
- 238000004891 communication Methods 0.000 claims description 83
- 230000006870 function Effects 0.000 claims description 32
- 238000011084 recovery Methods 0.000 claims description 27
- 238000010586 diagram Methods 0.000 description 16
- 238000004590 computer program Methods 0.000 description 6
- 230000002035 prolonged effect Effects 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000007488 abnormal function Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1417—Boot up procedures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The application provides a system starting method and a system based on multi-partition technology firmware protection, wherein the starting method comprises the following steps: loading boot firmware, wherein the boot firmware is independently stored in a storage partition; if the loading of the starting firmware is successful, finishing the starting of the system; and if the loading of the starting firmware fails, loading the backup starting firmware.
Description
Technical Field
The present application relates to firmware protection in electronic information products, and in particular, to a system boot method based on multi-partition technology firmware protection and a system based on multi-partition technology firmware protection.
Background
At present, most of intelligent electronic information products include a microprocessor and firmware, and the firmware is run on the running microprocessor to realize various intelligent functions. However, when the system runs for a long time, due to improper use, such as abnormal power on/off, or reliability and inconsistency of the storage device, a firmware portion may be damaged, which may cause the system to fail to be powered on or to have abnormal functions.
Disclosure of Invention
Based on this, the present application provides a system boot method based on multi-partition technology firmware protection, including: loading the starting firmware; the boot firmware is independently stored in a storage partition; if the loading of the starting firmware is successful, finishing the starting of the system; and if the loading of the starting firmware fails, loading the backup starting firmware.
The application also provides an electronic device comprising a processor and a memory, and a program executable by the processor stored in the memory, wherein when the program is executed, the processor performs any one of the aforementioned boot methods.
The present application also provides a storage medium storing a program executable by a processor, the processor performing any of the aforementioned boot methods when the program is executed.
The application also provides a system for firmware protection based on multi-partition technology, comprising: a boot firmware for booting the system; backing up boot firmware, and when the boot firmware is damaged, replacing the boot firmware to boot the system; and restoring the functional firmware, and restoring the starting firmware by using the backup firmware starting component.
By the aid of the starting method and the system, the system firmware can be modularly decomposed into a plurality of independent starting firmware, and backup is configured for each starting firmware. The system can be temporarily started by using the backup boot firmware instead of the boot firmware when the system firmware is wrong and damaged. And the damaged boot firmware can be restored by using the backup boot firmware after the temporary boot. Thereby effectively ensuring the robustness of the system. The service life of the electronic equipment applying the system can be prolonged. And the cost of returning damaged equipment to the factory for maintenance can be reduced.
In the scheme, the firmware in the system is decomposed into a plurality of component parts. The fault point of the system can be relatively accurately positioned, and the system repair can be carried out aiming at the fault point. This may reduce the time for system repair. And can restore the original appearance of the system to the maximum extent.
Meanwhile, in the scheme, a plurality of backup partitions can be set, and one boot firmware can be independently stored in at least one backup partition or one backup boot firmware can be independently stored. This effectively reduces the possibility of failure of the boot firmware and the backup firmware. The service life of the electronic equipment applying the system is prolonged.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without exceeding the protection scope of the present application.
Fig. 1 is a flowchart illustrating a system boot method based on multi-partition technology firmware protection according to an embodiment of the present application.
Fig. 2 is a flowchart illustrating a system boot method based on multi-partition technology firmware protection according to another embodiment of the present application.
Fig. 3 is a schematic diagram showing a system for firmware protection based on multi-partition technology according to another embodiment of the present application.
FIG. 4 shows a partition diagram of a memory included in the system of FIG. 3.
FIG. 5 shows a block diagram of an electronic device according to an example embodiment.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. 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 application.
Fig. 1 is a flowchart illustrating a system boot method based on multi-partition technology firmware protection according to an embodiment of the present application.
As shown in fig. 1, the boot firmware may be loaded in S110. Optionally, a system applying the method may comprise two or more boot firmware. S110 may include sequentially loading the two or more boot-up firmware in a preset order. Optionally, a system applying the method may include a memory storing firmware, which may include a plurality of boot partitions. At least one of the two or more boot firmware may monopolize a memory partition.
If the two or more boot firmware boots successfully, S120 may be entered. If any of the boot firmware boots up unsuccessfully, S130 may be entered. Optionally, when any boot firmware fails to boot, the boot firmware may be considered to be damaged, and a bad firmware flag corresponding to the boot firmware may be marked. Optionally, a system applying the method may have a plurality of bad firmware marks, which correspond to different boot firmware, respectively. Optionally, the storage partition of a system applying the method may comprise a label partition. The annotation partition may be used to store bad firmware flags.
As shown in fig. 1, in S120, all boot firmware loads successfully. At this time, the system using the method is started normally. The system will enter normal operation.
As shown in fig. 1, in S130, if any boot firmware fails to boot, the boot firmware may be considered damaged. At this time, the backup boot firmware corresponding to the boot firmware may be loaded. And the backup starting firmware can be utilized to temporarily start the system applying the method. Optionally, the system may include one backup boot firmware, or may include two or more backup boot firmware. Optionally, the at least one backup boot firmware may be a backup of the aforementioned at least one boot firmware.
Optionally, after S130, the method may further include: the corrupted boot firmware is restored. Alternatively, the corrupted boot firmware may be restored using a backup boot firmware corresponding to the corrupted boot firmware. Alternatively, the recovery of the corrupted boot firmware may be achieved by replacing the corrupted boot firmware with a corresponding backup boot firmware. Alternatively, the corrupted boot firmware and the corresponding backup boot firmware may each monopolize one memory partition. Optionally, the content of the storage partition where the corresponding backup boot firmware is located may be used to cover the storage partition where the damaged boot firmware is located, so as to recover the damaged boot firmware. Alternatively, a corrupted boot firmware may be located among a plurality of boot firmware included in the system based on the corrupted firmware flag, and the corrupted boot component may be recovered after the temporary boot. And the corresponding bad firmware flag may be cleared after the corrupted boot firmware is restored.
Optionally, a system applying the method may include restoring functional firmware. Wherein the recovery function firmware may be used to recover the corrupted boot firmware according to the foregoing steps. Optionally, S130 may include starting the resume function firmware. Optionally, the storage partition may include a recovery function partition. The resume function partition may be used to store resume function firmware.
Alternatively, the steps beginning at S110 may be performed after the boot firmware is restored. Again an attempt is made to start the system applying the method.
Optionally, the boot firmware may include: at least one of a master boot program, an application boot program, system security firmware, kernel firmware, communication firmware, and system firmware. Optionally, the system may include a plurality of memory partitions. Optionally, the memory partition of the system may include at least one of a master boot partition, a partition table, a communication parameter partition, a system security partition, an application boot partition, a kernel partition, a communication system partition, and a system partition. Where the master boot partition may be used to store the master boot. The application boot partition may be used to store an application boot. The system security partition stores system security firmware. A kernel partition may be used to store the kernel firmware. A communication system partition may be used to store the communication firmware. The system partition may store system firmware. The communication parameter partition may be used to store parameters of the communication firmware.
Optionally, backing up the boot firmware may include: at least one of an application boot backup firmware, a system security backup firmware, a kernel backup firmware, a communication backup firmware, and a system backup firmware. Wherein the application boot backup firmware can be a backup of the application boot. The system security backup firmware may be a backup of the system security firmware. The kernel backup firmware may be a backup of the kernel firmware. The communication backup firmware may be a backup of the communication firmware. The system backup firmware may be a backup of the system firmware.
Optionally, the memory partition included in the system applying the method may further include: at least one of a communication parameter backup partition, a system security backup partition, an application boot backup partition, a kernel backup firmware partition, and a mirror partition. Wherein the communication parameter backup partition is to restore backup firmware of the communication parameter partition. The system secure backup partition stores system secure backup firmware and may be used to restore the system secure partition. The application boot backup partition may be used to store application boot backup firmware and may be used to restore the application boot partition. The kernel backup partition may be used to store kernel backup firmware and may be used to restore the kernel partition. The mirrored partition may store system backup firmware and may be used to restore system firmware. Optionally, the mirrored partition may also be used to store the communicative backup firmware.
Fig. 2 is a flowchart illustrating a system boot method based on multi-partition technology firmware protection according to another embodiment of the present application.
As shown in fig. 2, the primary boot program SBL may be started in S205. The primary boot SBL may be stored separately in the primary boot partition. After the system is powered on, the main boot SBL may be started first. After the successful start of the primary boot program SBL, S210 may be entered.
As shown in fig. 2, the main boot program SBL may be used to detect whether a bad firmware flag exists in S210. Wherein the bad firmware flag may be used to flag whether the corresponding boot firmware is corrupted. Optionally, there may be a plurality of bad firmware flags, each corresponding to a different boot firmware. Alternatively, the bad firmware tag may be centrally stored in the label partition MISC. If no bad firmware flag exists, S215 may be entered to perform the subsequent boot steps. If the bad firmware flag exists, the process may proceed to S240 to perform corresponding bad firmware processing.
As shown in fig. 2, the system security firmware TZ may be loaded in S215. Alternatively, the system security firmware TZ may be separately stored in the system security partition. If the loading of the system security firmware TZ is successful, S220 may be entered to perform the subsequent boot steps. If the loading of the system security firmware TZ fails, the process may proceed to S240 to perform corresponding bad firmware processing. When the loading of the system security firmware TZ fails, a system security firmware loading failure mark can be marked in the marking partition MISC.
As shown in fig. 2, the application boot Aboot may be loaded with the host boot SBL in S220. Alternatively, the application boot Aboot may be stored separately in the application boot partition. If the application boot Aboot loading is successful, S225 may be entered to perform the first boot step. If the boot application abort loads, S245 may be entered to execute corresponding bad firmware processing. When the application bootstrap Aboot fails to load, an application bootstrap Aboot loading failure flag may be tagged in the tagging partition MISC.
As shown in fig. 2, the kernel firmware Boot may be loaded with the application Boot Aboot in S225. Alternatively, the kernel firmware Boot may be stored separately in the kernel partition. If the kernel firmware Boot loading is successful, S230 may be entered to perform the subsequent Boot steps. If the kernel firmware Boot loading fails, the process may enter S250 to perform corresponding bad firmware processing. When the loading of the kernel firmware Boot fails, a kernel firmware Boot loading failure mark can be marked in the marking partition MISC.
As shown in fig. 2, the communication firmware Modem may be loaded with the kernel firmware Boot in S230. Alternatively, the communication firmware Modem may be separately stored in the communication system partition. If the communication firmware Modem is successfully loaded, the process may proceed to S235, and a subsequent boot procedure is performed. If the communication firmware Modem fails to load, the process may proceed to S260 to execute corresponding bad firmware processing. When the communication firmware Modem fails to load, a communication firmware loading failure mark can be marked in the marking partition MISC.
As shown in fig. 2, the System firmware System may be loaded with the kernel firmware Boot in S235. The System firmware System may be stored separately in the System partition. If the System firmware System is successfully loaded, the process can proceed to S290, which indicates that there is no firmware damage and the boot process is successfully completed. If the System firmware System loading fails, S265 may be entered for corresponding bad firmware processing. When the System firmware System fails to load, a System firmware loading failure flag may be marked in the marking partition MISC.
As shown in fig. 2, the system backup firmware may be loaded in S265. The System backup firmware may be a backup boot firmware of the System firmware System. The System firmware System may be stored in the mirrored partition. The system backup firmware may be loaded by the kernel firmware Boot. After the system backup firmware loading is successful, S280 may be entered.
As shown in fig. 2, the system secure backup firmware TZBAK may be loaded at 240. The system secure backup firmware TZBAK is a backup boot firmware of the system secure firmware TZ. The system secure backup firmware TZBAK may be loaded by the primary boot program SBL. The system secure backup firmware TZBAK may be stored separately in the system secure backup partition. After the system secure backup firmware TZBAK is successfully loaded, S245 may be entered.
As shown in fig. 2, the application boot backup firmware ABootBAK may be loaded in S245. The application boot backup firmware ABootBAK may be loaded by the primary boot SBL. The application boot backup firmware ABootBAK may be a backup boot firmware of the application boot Aboot. The application boot backup firmware ABootBAK may be stored separately in the application boot backup partition. After the application boot backup firmware ABootBAK loading is successfully loaded, S250 may be entered.
As shown in fig. 2, the kernel backup firmware Recovery may be loaded in S250. The kernel backup firmware Recovery may be a backup Boot firmware of the kernel firmware Boot. The kernel backup firmware Recovery may be loaded by the application boot Aboot, or may be loaded by the application boot backup firmware ABootBAK. The kernel backup firmware Recovery may be stored separately in the kernel backup partition. After the kernel backup firmware Recovery is successfully loaded, S255 may be entered.
As shown in fig. 2, in S255, the communication firmware Modem may be loaded by the kernel backup firmware Recovery. The communication firmware Modem can be loaded, and simultaneously, the communication parameters in the communication parameter partition can be loaded. If the communication firmware Modem loading is successful, S280 may be entered. If the communication firmware Modem fails to load, S260 may be entered. When the communication firmware Modem fails to load, a communication firmware loading failure mark can be marked in the marking partition MISC.
As shown in fig. 2, the communication backup firmware may be loaded in S260. The communication backup firmware may be a backup boot firmware of the communication firmware Modem. The communication parameter backup in the communication parameter backup partition can be loaded at the same time when the communication backup firmware is loaded. The communication backup firmware can be loaded by the kernel firmware Boot or the kernel backup firmware Recovery. After the communication backup firmware loading is successful, S280 may be entered.
As shown in fig. 2, the resume function firmware may be loaded in S280. The recovery function firmware may be used to recover the corrupted boot firmware. Alternatively, the recovery function firmware may be stored separately in the recovery function partition. The Recovery function firmware can be loaded by the kernel backup firmware Recovery or the kernel firmware Boot. After the resume function firmware loading is successful, S285 may be entered.
As shown in fig. 2, the foregoing respective boot firmware damaged may be recovered by the recovery function firmware in S285. In S285, the bad firmware flag in the mark-up partition MISC may be detected, and the damaged boot firmware may be determined from the bad firmware flag. The corrupted boot-up firmware may be replaced with a backup boot-up firmware corresponding to the corrupted boot-up firmware. Alternatively, the storage partition in which the corrupted boot firmware resides may be overwritten with the storage partition in which the backup boot firmware resides. Alternatively, when the communication firmware is restored, the communication parameters may be restored at the same time. Restoring the communication parameters may include overwriting the communication parameter partition with the communication parameter backup partition. Alternatively, the bad firmware flag in the mark-up partition MISC may be cleared after the corrupted boot firmware is restored. After the completion of recovering the damaged boot firmware, the process may proceed to S205, and the steps from S205 may be executed again.
Fig. 3 is a schematic diagram showing a system for firmware protection based on multi-partition technology according to another embodiment of the present application.
As shown in fig. 3, system 3000 may include at least one boot-up firmware, at least one backup boot-up firmware, and a restore function firmware 33.
Boot firmware may be used to boot system 3000. As shown in an example embodiment, the boot firmware in system 3000 may include: host boot firmware 311, system security firmware 312, application boot firmware 313, kernel firmware 314, communication firmware 315, and system firmware 316. Alternatively, system 3000 may be started by loading in sequence host boot firmware 311, system security firmware 312, application boot firmware 313, kernel firmware 314, communication firmware 315, and system firmware 316.
Backup boot firmware may be used to boot system 3000 in place of boot firmware when boot firmware is corrupted. As shown in an example embodiment, the standby boot firmware in system 3000 may include: system security backup firmware 322, application boot backup firmware 323, kernel backup firmware 324, communication backup firmware 325, and system backup firmware 326. Among other things, system secure backup firmware 322 is backup boot firmware that may be used in place of system secure firmware 312. Application boot backup firmware 323 is backup boot firmware that may be used in place of application boot firmware 313. Kernel backup firmware 324 is backup boot firmware that may be used in place of kernel firmware 314. Communication backup firmware 325 is backup boot firmware that may be used in place of communication firmware 315. System backup firmware 326 is backup boot firmware that may be used in place of system firmware 316.
When the boot firmware is corrupted, the recovery function firmware 33 may be used to recover the corrupted boot firmware using the backup boot firmware. The recovery function firmware 33 may replace the corrupted boot firmware with its corresponding backup boot firmware to effect recovery of the corrupted boot firmware. Such as: the restore functionality firmware 33 may restore the system security firmware 312 using the system security backup firmware 322, restore the application boot firmware 313 using the application boot backup firmware 323, restore the kernel firmware 314 using the kernel backup firmware 324, restore the communication firmware 315 using the communication backup firmware 325, and restore the system firmware 316 using the system backup firmware 326.
Optionally, system 3000 can include memory (not shown). At least one of the boot firmware 311, 316, the boot firmware 322, 326, and the recovery function firmware 33 may be a program and may be stored in the memory. Alternatively, the memory may be a non-volatile memory.
FIG. 4 shows a partition diagram of a memory included in the system of FIG. 3.
As shown in FIG. 4, the memory partitioning within the memory included in system 3000 may include: a master boot partition 3411, a system security partition 3412, an application boot partition 3413, a kernel partition 3414, a communication system partition 3415, and a system partition 3416. The memory partitions may be respectively used for storing at least one of the boot firmware, such as: host boot firmware 311, system security firmware 312, application boot firmware 313, kernel firmware 314, communication firmware 315, and system firmware 316.
As shown in fig. 4, the in-memory partitions of the memory included in system 3000 may include: a system secure backup partition 3422, an application boot backup partition 3423, a kernel backup partition 3424, a mirror partition 3426. The storage partitions may be respectively used for storing at least one of the backup boot firmware, such as: system security backup firmware 322, application boot backup firmware 323, kernel backup firmware 324, communication backup firmware 325, and system backup firmware 326. Among other things, mirrored partition 3426 may store communication firmware 315 and system firmware 316.
Optionally, at least one of the aforementioned boot firmware may monopolize one memory partition. At least one of the aforementioned backup boot firmware may also monopolize one boot partition. Alternatively, the recovery of the boot firmware may be implemented by overwriting the storage partition in which the corresponding boot firmware is located with the storage partition in which the backup boot firmware is located.
As shown in fig. 4, optionally, the storage partition included in the system 3000 may further include: partition table 3431, communication system parameters 3432, communication system parameter backup 3433, recovery function partition 3434, and callout partition 3435. The partition table 3431 may be used to record the physical address distribution of each storage partition. Communication system parameters 3432 may be used to record communication parameters of communication firmware 315. The communication system parameter backup 3433 may be used to backup communication parameters in the communication system parameters 3432. The recovery function partition 3434 may be used to store recovery function firmware 33. The annotation partition 3435 may be used to store bad firmware flags. Wherein the bad firmware flag may be used to flag whether the at least one boot firmware is corrupted.
FIG. 5 shows a block diagram of an electronic device according to an example embodiment.
An electronic device 200 according to this embodiment of the present application is described below with reference to fig. 5. The electronic device 200 shown in fig. 5 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 5, the electronic device 200 is embodied in the form of a general purpose computing device. The firmware of the electronic device 200 may include, but is not limited to: at least one processing unit 210, at least one memory unit 220, a bus 230 connecting different system firmware (including the memory unit 220 and the processing unit 210), a display unit 240, and the like.
Wherein the storage unit stores program code executable by the processing unit 210 to cause the processing unit 210 to perform the methods according to various exemplary embodiments of the present application described herein. For example, the processing unit 210 may perform a system boot method based on multi-partition technology firmware protection as shown in fig. 1-2.
The memory unit 220 may include readable media in the form of volatile memory units, such as a random access memory unit (RAM)2201 and/or a cache memory unit 2202, and may further include a read only memory unit (ROM) 2203.
The storage unit 220 may also include a program/utility 2204 having a set (at least one) of program modules 2205, such program modules 2205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
The electronic device 200 may also communicate with one or more external devices 300 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 200, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 200 to communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 250. Also, the electronic device 200 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network such as the Internet) via the network adapter 260. The network adapter 260 may communicate with other modules of the electronic device 200 via the bus 230. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the electronic device 200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup firmware storage systems, among others.
By the aid of the starting method and the starting system, the firmware in the system can be modularly decomposed into a plurality of independent starting firmware, and backup is configured for each starting firmware. The system can be temporarily started by using the backup boot firmware instead of the boot firmware when the system firmware is wrong and damaged. And the damaged boot firmware can be restored by using the backup boot firmware after the temporary boot. Thereby effectively ensuring the robustness of the system. The service life of the electronic equipment applying the system can be prolonged. And the cost of returning damaged equipment to the factory for maintenance can be reduced.
Because in this scheme the system firmware is broken up into a number of component parts. The fault point of the system can be relatively accurately positioned, and the system repair can be carried out aiming at the fault point. This may reduce the time for system repair. And can restore the original appearance of the system to the maximum extent.
Meanwhile, in the scheme, a plurality of backup partitions can be set, and one boot firmware can be independently stored in at least one backup partition or one backup boot firmware can be independently stored. This effectively reduces the possibility of failure of the boot firmware and the backup firmware. The service life of the electronic equipment applying the system is prolonged.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments. The technical features of the embodiments may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The foregoing detailed description of the embodiments of the present application has been presented to illustrate the principles and implementations of the present application, and the description of the embodiments is only intended to facilitate the understanding of the methods and their core concepts of the present application. Meanwhile, a person skilled in the art should, according to the idea of the present application, change or modify the embodiments and applications of the present application based on the scope of the present application. In view of the above, the description should not be taken as limiting the application.
Claims (10)
1. A system starting method based on multi-partition technology firmware protection is characterized by comprising the following steps:
loading boot firmware, wherein the boot firmware is independently stored in a storage partition;
if the loading of the starting firmware is successful, finishing the starting of the system;
and if the loading of the starting firmware fails, loading the backup starting firmware.
2. The startup method of claim 1,
the starting firmware and the backup starting firmware are respectively and independently stored in different storage partitions;
after the loading the backup boot firmware, the boot method further includes:
restoring the storage partition where the starting firmware is located by using the storage partition where the backup starting firmware is located;
after the storage partition where the boot firmware is located is restored by using the storage partition where the backup boot firmware is located, the boot method further includes:
executing the step of loading the boot firmware to start;
the restoring the storage partition where the boot firmware is located by using the storage partition where the backup boot firmware is located includes:
loading recovery function firmware;
restoring, by the restoration function firmware, the storage partition where the boot firmware is located by using the storage partition where the backup boot firmware is located;
the memory partition includes:
and the recovery function partition is used for storing the recovery function firmware.
3. The boot method according to claim 2, further comprising, before restoring the storage partition in which the boot firmware is located by using the storage partition in which the backup boot firmware is located:
marking a bad firmware mark corresponding to the starting firmware;
the restoring the storage partition where the boot firmware is located by using the storage partition where the backup boot firmware is located includes:
restoring the storage partition where the starting firmware is located by using the storage partition where the backup starting firmware is located according to the bad firmware mark;
clearing the bad firmware mark;
the memory partition includes:
the marking partition is used for storing the bad firmware mark;
the boot firmware includes:
at least one of a master boot program, an application boot program, system security firmware, kernel firmware, communication firmware, and system firmware;
the backup boot firmware includes:
at least one of an application boot backup firmware, a system security backup firmware, a kernel backup firmware, a communication backup firmware, and a system backup firmware.
4. A boot method according to claim 3, wherein the memory partition comprises: a master boot partition, a partition table, a communication parameter partition, a system security partition, an application boot partition, a kernel partition, a communication system partition, and a system partition, wherein
The primary boot partition storing the primary boot;
the application boot partition storing the application boot;
the system security partition storing the system security firmware;
the kernel partition stores the kernel firmware;
the communication system partition storing the communication firmware;
the system partition storing the system firmware;
the memory partition further comprises:
at least one of a communication parameter backup partition, a system security backup partition, an application boot backup partition, a kernel backup partition, and a mirror partition, wherein
The communication parameter backup partition is used for recovering the backup firmware of the communication parameter partition;
the system security backup partition stores the system security backup firmware and is used for restoring the system security partition;
the application boot backup partition storing the application boot backup firmware and for restoring the application boot partition's backup firmware;
the kernel backup partition stores the kernel backup firmware and is used for restoring the kernel partition;
the mirrored partition stores the system backup firmware and is used to restore the system firmware.
5. The boot method of claim 4, wherein loading the boot firmware comprises:
starting the main bootstrap program;
detecting whether a bad firmware mark exists;
if the loading of the boot firmware fails, loading the backup boot firmware, including:
if the bad firmware flag is present, then execute
Loading, by the primary boot program, the system secure backup firmware; and/or
Loading, by the primary boot program, the application boot program backup firmware; and/or
Loading, by the application boot backup firmware, the kernel backup firmware; and/or
Loading, by the kernel backup firmware, the communication firmware.
6. The boot method of claim 5, wherein after said booting the master boot program, said loading boot firmware further comprises:
loading, by the primary boot program, the system security firmware;
if the loading of the boot firmware fails, loading the backup boot firmware, including:
if the loading of the system security firmware by the main boot program fails, executing
Loading, by the primary boot program, the system secure backup firmware; and/or
Loading, by the primary boot program, the application boot program backup firmware; and/or
Loading, by the application boot backup firmware, the kernel backup firmware; and/or
Loading, by the kernel backup firmware, the communication firmware;
the marking of the bad firmware mark corresponding to the boot firmware comprises: marking a security module loading failure mark;
after the booting the master boot program, the loading boot firmware further comprises:
loading, by the primary boot program, the application boot program;
if the loading of the boot firmware fails, loading the backup boot firmware, including:
if the loading of the application boot program by the main boot program fails, executing
Loading, by the primary boot program, the application boot program backup firmware; and/or
Loading, by the application boot backup firmware, the kernel backup firmware; and/or
Loading, by the kernel backup firmware, the communication firmware;
the marking of the bad firmware mark corresponding to the boot firmware further comprises: the markup application boots a load failure markup.
7. The boot method of claim 6, wherein, upon said loading of said application boot by said master boot, said loading boot firmware further comprises:
loading, by the application boot program, the kernel firmware;
if the loading of the boot firmware fails, loading the backup boot firmware, including:
executing if the loading of the kernel firmware by the application boot program fails
Loading, by the application boot program, the kernel backup firmware; and/or
Loading, by the kernel backup firmware, the communication firmware;
the marking of the bad firmware mark corresponding to the boot firmware further comprises: the kernel firmware load failure is flagged.
8. The boot method of claim 7, wherein after said loading the kernel firmware by the application boot program, said loading the boot firmware further comprises:
loading, by the kernel firmware, the communication firmware;
if the loading of the boot firmware fails, loading the backup boot firmware, including:
if the communication firmware loading by the kernel firmware fails, loading communication backup firmware;
the marking of the bad firmware mark corresponding to the boot firmware further comprises: marking a communication firmware loading failure mark;
after the loading of the kernel firmware by the application boot program, the loading the boot firmware further comprises:
loading, by the kernel firmware, the system firmware;
if the loading of the boot firmware fails, loading the backup boot firmware, including:
loading the backup boot firmware from the mirror partition if the system firmware is loaded by the kernel firmware; the marking of the bad firmware mark corresponding to the boot firmware further comprises: the system firmware load failure flag is marked.
9. A system for multi-partition technology based firmware protection, comprising:
a boot firmware for booting the system;
backing up boot firmware, and when the boot firmware is damaged, replacing the boot firmware to boot the system;
and restoring the functional firmware, and restoring the starting firmware by using the backup starting firmware.
10. The system of claim 9, wherein the boot firmware comprises:
at least one of a master boot firmware, an application boot firmware, a system security firmware, a kernel firmware, a communication firmware, and a system firmware;
the backup boot firmware includes:
at least one of an application boot program backup firmware, a system security backup firmware, a kernel backup firmware, a communication backup firmware, and a system backup firmware; wherein
The application boot backup firmware is to replace the application boot firmware and to restore the application boot firmware;
the system security backup firmware is used for replacing the system security firmware and recovering the system security firmware;
the kernel backup firmware is used for replacing the kernel firmware and restoring the kernel firmware;
the communication backup firmware is used for replacing the communication firmware and restoring the communication firmware;
the system backup firmware is used to replace the system firmware and to restore the system firmware.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011521569.4A CN112698985A (en) | 2020-12-21 | 2020-12-21 | System starting method and system based on multi-partition technology firmware protection |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011521569.4A CN112698985A (en) | 2020-12-21 | 2020-12-21 | System starting method and system based on multi-partition technology firmware protection |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112698985A true CN112698985A (en) | 2021-04-23 |
Family
ID=75509731
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011521569.4A Pending CN112698985A (en) | 2020-12-21 | 2020-12-21 | System starting method and system based on multi-partition technology firmware protection |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112698985A (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040025002A1 (en) * | 2002-08-01 | 2004-02-05 | Cepulis Darren J. | System firmware back-up using a BIOS-accessible pre-boot partition |
| CN1490817A (en) * | 2002-10-14 | 2004-04-21 | 华为技术有限公司 | Guide program recorder and method for guarantee of online upgrading thereof |
| CN104063256A (en) * | 2014-07-18 | 2014-09-24 | 上海斐讯数据通信技术有限公司 | Partition and firmware upgrading method based on minimum operating system |
| CN106776122A (en) * | 2016-11-23 | 2017-05-31 | 武汉光迅科技股份有限公司 | A kind of method of main-apparatus protection in start-up course based on Flash |
| CN109783150A (en) * | 2019-01-31 | 2019-05-21 | 深兰科技（上海）有限公司 | A kind of anti-brick method and device of embedded system starting |
-
2020
- 2020-12-21 CN CN202011521569.4A patent/CN112698985A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040025002A1 (en) * | 2002-08-01 | 2004-02-05 | Cepulis Darren J. | System firmware back-up using a BIOS-accessible pre-boot partition |
| CN1490817A (en) * | 2002-10-14 | 2004-04-21 | 华为技术有限公司 | Guide program recorder and method for guarantee of online upgrading thereof |
| CN104063256A (en) * | 2014-07-18 | 2014-09-24 | 上海斐讯数据通信技术有限公司 | Partition and firmware upgrading method based on minimum operating system |
| CN106776122A (en) * | 2016-11-23 | 2017-05-31 | 武汉光迅科技股份有限公司 | A kind of method of main-apparatus protection in start-up course based on Flash |
| CN109783150A (en) * | 2019-01-31 | 2019-05-21 | 深兰科技（上海）有限公司 | A kind of anti-brick method and device of embedded system starting |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6687849B1 (en) | Method and apparatus for implementing fault-tolerant processing without duplicating working process | |
| CN104834575B (en) | A kind of firmware restoration method and device | |
| US10949314B2 (en) | Method and apparatus for failure recovery of storage device | |
| CN105446834A (en) | Virtual machine snapshot generation method and apparatus | |
| KR970059930A (en) | I / O control device and method | |
| WO2016206514A1 (en) | Startup processing method and device | |
| CN105653405B (en) | A kind of fault handling method and system of Generic Bootstrap | |
| CN111045712A (en) | Single system upgrading method and system with backup function | |
| CN108268302B (en) | Method and device for realizing equipment starting | |
| CN107566169A (en) | A kind of firmware upgrade method and router based on openwrt | |
| CN111813753A (en) | File saving method, file restoring method, device and terminal equipment | |
| CN105589713A (en) | Electronic equipment and starting method therefor | |
| US20070050612A1 (en) | Boot program update and restoration system and method thereof | |
| CN105183580A (en) | Storage method and fault recovery method for bootstrap program, and devices | |
| CN101923500A (en) | Backup and update method and device of bootstrap program in embedded equipment | |
| CN113608926A (en) | Backup recovery method and device and electronic equipment | |
| CN109086085A (en) | A kind of os starting management method and device | |
| CN111290885B (en) | Multi-computer two-stage data backup and hierarchical recovery method for Mars detection | |
| CN109710377B (en) | Method for recovering kvm virtual machine from faulty distributed storage | |
| CN112698985A (en) | System starting method and system based on multi-partition technology firmware protection | |
| CN113515291A (en) | Equipment online upgrading method and device | |
| CN111984195A (en) | Method and device for improving stability of embedded Linux system | |
| CN105159810B (en) | The method and device that the BIOS of computer system is tested | |
| CN111857740A (en) | Software upgrading method and device | |
| CN112395130A (en) | System backup method and device |
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 |