CN114035818A - Firmware upgrading method and device, computer equipment and storage medium - Google Patents
Firmware upgrading method and device, computer equipment and storage medium Download PDFInfo
- Publication number
- CN114035818A CN114035818A CN202111239446.6A CN202111239446A CN114035818A CN 114035818 A CN114035818 A CN 114035818A CN 202111239446 A CN202111239446 A CN 202111239446A CN 114035818 A CN114035818 A CN 114035818A
- Authority
- CN
- China
- Prior art keywords
- partition
- target data
- firmware
- written
- data
- 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
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- 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
-
- 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/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The application discloses a firmware upgrading method and device, computer equipment and a storage medium. The method comprises the following steps: establishing connection with a server, acquiring new firmware from the server, writing first target data, second target data and third target data contained in the new firmware into a verification partition, a function partition and an upgrade partition of the embedded device respectively, the new firmware is used for firmware upgrade of the embedded device, if the embedded device is restarted during the firmware upgrade, and the first target data is written into the check partition without exception, and the third target data is written into the upgrade partition with exception, and whether the functional partition has backed up the third target data or not, performing data recovery on the upgraded partition according to the third target data backed up by the functional partition, returning to the step of establishing connection with the server and acquiring new firmware from the server, therefore, the possibility of upgrading damage is effectively reduced, the use of storage space is saved, and the cost is further reduced.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a firmware upgrade method and apparatus, a computer device, and a storage medium.
Background
In recent years, embedded devices have been widely used and have been rapidly developed due to their advantages of low cost, high reliability, rich code, and scalability and portability of application programs. With the improvement of requirements on system functions, performance, scale and the like of the embedded equipment, the firmware of the embedded equipment needs to be upgraded in the using process of the embedded equipment, so that the system can be maintained and upgraded in time according to the requirements of customers, and the performance of the system is improved.
At present, an embedded device downloads a new firmware from a cloud, and then performs firmware upgrade in a manner of writing the new firmware, so that in order to avoid abnormal situations such as sudden power failure in the upgrade process, which results in abnormal writing of the new firmware, data loss and the like, the new firmware needs to be backed up, so that the firmware upgrade is recovered when the situations occur. However, the backup of the new firmware requires additional storage space, which increases the cost.
Disclosure of Invention
The embodiment of the application provides a firmware upgrading method and device, computer equipment and a storage medium, which can save storage space while ensuring the stability and reliability of firmware upgrading, thereby reducing cost.
In a first aspect, an embodiment of the present application provides a firmware upgrade method, which is applied to an embedded device, where the embedded device includes a flash memory, and the flash memory includes a check partition, a function partition, and an upgrade partition, and the method includes:
establishing connection with a server, acquiring new firmware from the server, and writing first target data, second target data and third target data contained in the new firmware into the verification partition, the function partition and the upgrade partition respectively, wherein the new firmware is used for upgrading the firmware of the embedded equipment;
if the embedded equipment is restarted when the firmware is upgraded, judging whether the first target data is abnormal when written into the check partition through a boot loader of the embedded equipment;
if the first target data is not abnormal when written into the check partition, judging whether the third target data is abnormal when written into the upgrade partition by the boot loader;
if the third target data is abnormal when being written into the upgrading partition, judging whether the third target data is backed up by the functional partition or not through the boot loader;
if the third target data is backed up by the functional partition, performing data recovery on the upgrading partition according to the backed-up third target data in the functional partition;
and returning to the step of establishing connection with the server and acquiring new firmware from the server.
In the firmware upgrading method provided in this embodiment of the present application, if no exception occurs when the first target data is written into the verification partition, the verification partition stores the first data identifier of the third target data, and the determining, by the boot loader, whether an exception occurs when the third target data is written into the upgrade partition includes:
acquiring a first current data identifier corresponding to first current data in the upgrading partition through the boot loader;
if the first current data identifier is consistent with the first data identifier, determining that no exception occurs when the third target data is written into the upgrade partition; or
And if the first current data identifier is inconsistent with the first data identifier, determining that an exception occurs when the third target data is written into the upgrading partition.
In the firmware upgrading method provided in the embodiment of the present application, the determining, by the boot loader, whether the third target data has been backed up by the functional partition includes:
acquiring a second current data identifier corresponding to second current data in the functional partition;
if the second current data identifier is consistent with the first data identifier, determining that the third target data is backed up by the functional partition; or
And if the second current data identifier is inconsistent with the first data identifier, determining that the third target data is not backed up by the functional partition.
In the firmware upgrading method provided in the embodiment of the present application, after determining that the third target data is not backed up by the functional partition, the method further includes:
and returning to the step of establishing connection with the server and acquiring new firmware from the server.
In the firmware upgrading method provided in this embodiment of the present application, if no abnormality occurs when the first target data is written into the verification partition, the verification partition further stores a second data identifier corresponding to the second target data, and the method further includes:
if the third target data is not abnormal when written into the upgrading partition, acquiring a third current data identifier corresponding to third current data in the functional partition through the boot loader;
if the third current data identifier is inconsistent with the second data identifier, determining that an exception occurs when the second target data is written into the functional partition;
and returning to the step of establishing connection with the server and acquiring new firmware from the server.
In the firmware upgrading method provided in the embodiment of the present application, the determining, by the boot loader of the embedded device, whether an exception occurs when the first target data is written into the check partition includes:
reading fourth current data in the check partition through the boot loader;
if the fourth current data is in a preset format, determining that no abnormality occurs when the first target data is written into the check partition;
and if the fourth current data is not in a preset format, determining that the first target data is abnormal when being written into the check partition.
In the firmware upgrading method provided in the embodiment of the present application, the method further includes:
and if the first target data is abnormal when being written into the verification partition, returning to the step of executing the connection established with the server and acquiring new firmware from the server.
In a second aspect, an embodiment of the present application further provides a firmware upgrading apparatus, which is applied to an embedded device, where the embedded device includes a flash memory, the flash memory includes a verification partition, a function partition, and an upgrade partition, and the apparatus includes:
the acquisition module is used for establishing connection with a server, acquiring new firmware from the server, and respectively writing first target data, second target data and third target data contained in the new firmware into the verification partition, the function partition and the upgrade partition, wherein the new firmware is used for upgrading the firmware of the embedded equipment;
the first judgment module is used for judging whether the first target data is abnormal when being written into the check partition through a boot loader of the embedded equipment if the embedded equipment is restarted during firmware upgrading;
a second determining module, configured to determine, by the boot loader, whether an exception occurs when the third target data is written into the upgrade partition if the first target data is not written into the check partition;
a third determining module, configured to determine, by the boot loader, whether the third target data is backed up by the functional partition if an exception occurs when the third target data is written into the upgrade partition;
the recovery module is used for performing data recovery on the upgrading partition according to the backed-up third target data in the functional partition if the functional partition backs up the third target data; and returning to the acquisition module and executing the functions of the acquisition module.
In a third aspect, embodiments of the present application further provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method according to the first aspect.
In a fourth aspect, the present application further provides a storage medium having a computer program stored thereon, where the computer program is executed by a processor to implement the steps of the method according to the first aspect.
The embodiment of the application provides a firmware upgrading method, a firmware upgrading device, computer equipment and a storage medium, wherein the upgrading method comprises the following steps: establishing connection with a server, acquiring a new firmware from the server, and writing first target data, second target data and third target data contained in the new firmware into a verification partition, a function partition and an upgrade partition of the embedded device respectively, wherein the new firmware is used for upgrading the firmware of the embedded device, if the embedded device is restarted during upgrading the firmware, the first target data is not abnormal when being written into the verification partition, the third target data is abnormal when being written into the upgrade partition, and the function partition backs up the third target data or not, performing data recovery on the upgrade partition according to the third target data backed up by the function partition, and returning to execute the steps of establishing connection with the server and acquiring the new firmware from the server. According to the method and the device, the upgrading partition is backed up through the functional partition, and extra storage space is not needed for backup, so that the possibility of upgrading damage is effectively reduced, the use of the storage space is saved, and the cost is reduced.
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 creative efforts.
Fig. 1 is a schematic flowchart of a firmware upgrading method according to an embodiment of the present application.
FIG. 2 is a partition diagram of firmware provided by an embodiment of the present application;
FIG. 3 is a process diagram of a firmware upgrade method provided by an embodiment of the present application;
FIG. 4 is a schematic diagram illustrating a firmware upgrade method according to an embodiment of the present disclosure;
FIG. 5 is a schematic structural diagram of a firmware upgrading apparatus provided in an embodiment of the present application;
fig. 6 is a schematic structural diagram of a computer device according to an embodiment of the present application.
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 only a part of the embodiments of the present application, 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 application.
The embodiment of the application provides a firmware upgrading method and device, computer equipment and a storage medium. In particular, the present embodiment provides a firmware upgrade method suitable for a firmware upgrade apparatus, which may be integrated in a computer device.
Referring to fig. 1, fig. 1 is a schematic flowchart illustrating a firmware upgrading method according to an embodiment of the present application, where the firmware upgrading method is applied to an embedded device, the embedded device includes a flash memory, the flash memory includes a check partition, a function partition, and an upgrade partition, and the method mainly includes steps 101 to 105, which are described as follows:
for ease of understanding, the partition design provided in the present application and the write design of each partition during the upgrade process will be described in detail first.
Referring to fig. 2, fig. 2 is a schematic structural diagram of a flash partition design described in the embodiment of the present application, which mainly includes a partition that is not modified frequently, an upgrade partition, a function partition, and a check partition. The partitions which are not modified frequently may include a U-Boot partition, a configuration file partition, a product information partition and the like. And a complete upgrading system is stored in the upgrading partition and comprises a kernel, files necessary for running a root file system and all files necessary for firmware upgrading. The functional partition stores a functional system, including all programs and related files for realizing product requirements. And checking the partition, storing an MD5(message digest algorithm) value calculated according to the upgrading partition and an MD5 value calculated according to the functional partition, and judging whether the upgrading partition or the functional partition is damaged in the U-Boot.
It is readily understood that the new firmware, when released, may split the root file system into two parts: the first part includes files necessary to run the root file system and all files necessary for firmware upgrade (upgrade system); the second part includes all the programs and related files (functional systems) that fulfill the product requirements. The kernel and the upgrade system are merged together as an upgrade partition when the boot media is manufactured. The U-Boot obtains the size of the kernel by reading kernel header information and the like, calculates the starting address of the upgrade partition, and provides the starting address to the kernel for constructing an MTD (Memory technology device) partition. The functional system is independently stored in a functional partition, the kernel loads and upgrades the partition after being started, and then whether the functional partition is loaded or not is determined according to the command line parameters transmitted by the U-Boot. If the functional partition is loaded, the functional system in the loaded functional partition is merged with the upgrade system in the loaded upgrade partition in some way, and then the program of the function related to the product demand is run. If the function partition is not loaded, the automatic upgrading software in the upgrading partition is operated, and the firmware is automatically upgraded and recovered through networking.
Referring to fig. 3, fig. 3 shows a schematic diagram of a writing process of each partition in an upgrade process under a normal condition, first, a new firmware is downloaded from a cloud, then, a check partition of the new firmware is written into a check partition of a flash (step1), then, an upgrade partition of the new firmware is written into a functional partition of the flash as a backup of the upgrade partition (step2), then, the upgrade partition of the new firmware is written into an upgrade partition of the flash (step3), and then, the functional partition of the new firmware is written into a functional partition of the flash (step4), so that the upgrade is completed.
It should be appreciated that in order to use the functional partition to backup the contents of the upgrade partition during the upgrade process, the sizes of the upgrade partition and the functional partition must remain consistent. Or, under the condition that the upgrade partition is too large and the function partition is idle, the data content of the upgrade partition can be compressed and then backed up into the function partition. The compression can be performed when the new firmware is manufactured, so that the file size of the transmitted new firmware can be reduced, and the calculation overhead of the compressed file can be saved at the equipment end.
Specifically, before writing the upgrade partition of the new firmware into the upgrade partition of the flash, the upgrade partition of the new firmware is written into the functional partition of the flash for backup, so that if abnormality occurs in step2, it can be ensured that the state before upgrade is maintained in the upgrade partition, and if abnormality occurs in step3, the content of the upgrade partition of the new firmware backed up in the functional partition in the flash memory can be used to restore the content of the upgrade partition in the flash memory, so as to ensure that a correct kernel, files necessary for running a root file system, and files necessary for upgrading all the firmware are always stored in the upgrade partition.
It should be noted that for the partition that is not modified frequently, when the new firmware is released, each partition in the new firmware may be marked to determine whether erasing is needed. In addition, compared with an upgrading partition and a function partition, the size of the partition which is not frequently modified is small, the erasing speed is high, and the abnormity is not easy to occur. In erasing, the data blocks are erased and written, and the content of each data block is compared, so that the erasing and writing are not needed when the content is the same, the erasing and writing speed is increased, and the possibility of abnormal occurrence is reduced.
According to the partition design, the root file system is divided into the upgrading partition and the function partition, then the product function is achieved by simply combining the partitions, the partition writing sequence in the upgrading process is ingeniously designed, the data backup of the upgrading partition is stored by the function partition, the backup is achieved without adding extra flash memory space, the storage space is saved, and meanwhile, the upgrading recovery system can be started under the condition that the data damage is caused due to the fact that power failure abnormity occurs in any step in the upgrading process.
The first target data is data in a check partition in the new firmware, the second target data is data in functional service in the new firmware, the third target data is data in an upgrade partition in the new firmware, and the sequence of writing the first target data, the second target data and the third target data into the flash memory is strictly written according to the sequence. And if no exception occurs in the writing process, the upgrading is successful.
The Bootloader, i.e., the U-Boot, is a Bootloader that is commonly used in an embedded system, and the Bootloader is a small segment of program that is executed before an operating system runs, and through the Bootloader, hardware devices can be initialized, and a mapping table of a memory space is established, so that a proper software and hardware environment is established, and preparation is made for finally calling an operating system kernel. The main running task of BootLoader is to read the kernel image from the hard disk into the RAM, and then jump to the entry point of the kernel to run, i.e. start to start the operating system. The system is usually executed from the address 0x00000000 when it is powered on or reset, and it is usually BootLoader program of the system that is arranged at this address.
As can be seen from the above, the upgrade partition of the flash memory of the embedded device stores the files necessary for operating the root file system and all the files necessary for upgrading the firmware, and therefore, it is necessary to ensure that the contents stored in the upgrade partition always keep an operable state, that is, the contents store the correct data before the update or the correct data after the update.
After the upgrade is successful, the embedded device may be automatically restarted, and at this time, if it can be determined that the first target data is not abnormal when written into the check partition by the boot loader of the embedded device, step 103 is executed. If the embedded device is abnormally powered off in the upgrading process, for example, when the power supply is suddenly powered off, and the embedded device is restarted, the boot loader determines whether the first target data is abnormally written into the verification partition, if not, the first target data is considered not to be abnormally written into the verification partition, then step 103 is executed, whether the third target data is normally written into the upgrading partition is continuously determined, if the boot loader determines that the first target data is abnormally written into the verification partition, the upgrade partition can be considered not to be written into, further, the upgrade partition can be considered to store correct data before updating, namely, the content stored in the upgrade partition is kept in a runnable state, the step 101 is returned to, namely, the connection with the server is established again, new firmware is obtained from the server, and the firmware is upgraded again.
Specifically, step 102 may mainly include: reading fourth current data in the check partition through a boot loader; if the fourth current data is in a preset format, determining that no abnormality occurs when the first target data is written into the check partition; and if the fourth current data is not in the preset format, determining that the first target data is abnormal when being written into the check partition.
The check partition stores therein data identifiers of the upgrade partition and the function partition, for example, an MD5 value calculated according to the data of the upgrade partition and the function partition is stored therein, the MD5 value is a fixed-length hexadecimal digital string, and by reading the current data in the check partition and determining the format of the current data in the check partition, it can be determined whether the first target data is abnormal when written into the check partition.
It is easy to understand that, the data writing process is an erasing process, and if abnormal power failure occurs in the erasing process, the length of the current data of the verification partition will not conform to the actual length, so that it can be determined whether the first target data is abnormal when written into the verification partition by determining whether the length of the current data conforms to the preset length.
For example, if the second target data is "hsolngffbkop-phnnm, l [", the MD5 value calculated from the second target data is "C9 A8B387E5CDAF 0F", the third target data is "gyighuojnioj", and the MD5 value calculated from the third target data is "12111 ACCA8B2E 394", it is possible to determine whether an abnormality occurs when the first target data is written into the check partition by determining whether the current data of the check partition is two sixteen bytes of data.
103, judging whether the third target data is abnormal when written into the upgrade section by the boot loader; if yes, go to step 104; if not, go to step 101.
It is easy to understand that, in the new firmware, the verification partition stores the first data identifier of the third target data and the second data identifier of the second target data, and if the first target data is written into the verification partition without exception, the current verification partition stores the first data identifier, and step 103 may mainly include: acquiring a first current data identifier corresponding to first current data in an upgrading partition through a boot loader; if the first current data identifier is consistent with the first data identifier, determining that no exception occurs when the third target data is written into the upgrading partition; or if the first current data identifier is inconsistent with the first data identifier, determining that the third target data is abnormal when being written into the upgrading partition.
The first data identifier may be an MD5 value calculated according to the third target data, the second data identifier may be an MD5 value calculated according to the second target data, and similarly, the first current data identifier may also be an MD5 value calculated according to the first current data. Or, the first data identifier may be a version number of the third target data, where the version number may be carried at a tail of the third target data, and similarly, the first current data identifier may also be a version number carried at a tail of the first current data, if writing of the third target data into the upgrade partition is completed, the version number acquired by the U-Boot should be consistent with the first data identifier, and if the third target data is not written into the upgrade partition or writing of the third target data into the upgrade partition is not completed, the version number acquired by the U-Boot should be inconsistent with the first data identifier.
It is easy to understand that, if the first current data identifier is consistent with the first data identifier, it may be considered that the third target data has been successfully written into the upgrade partition, and at this time, a new complete upgrade system is stored in the upgrade partition, and the process may directly return to the step 101, that is, the network is reconnected to obtain the firmware, so as to perform the firmware upgrade again. If the first current data identifier is not consistent with the first data identifier, it may be determined that the third target data is not successfully written into the upgrade partition, and at this time, it needs to be determined whether to power off during writing or to power off during non-writing, that is, step 104 is executed.
104, judging whether the functional partition backs up the third target data or not by the boot loader; if yes, go to step 105; if not, go to step 101.
Specifically, step 104 may specifically include: acquiring a second current data identifier corresponding to second current data in the functional partition; if the second current data identifier is consistent with the first data identifier, determining that the functional partition backs up third target data; or if the second current data identifier is inconsistent with the first data identifier, determining that the functional partition does not back up the third target data.
It is easy to understand that, the check partition in the new firmware stores the first data identifier of the third target data and the second data identifier of the second target data, and if the first target data is written into the check partition without exception, the current check partition stores the first data identifier. If the functional partition is backed up with the third target data, a second current data identifier corresponding to the second current data in the functional partition should be consistent with the first data identifier, and if the functional partition is not backed up with the third target data, the second current data identifier corresponding to the second current data in the functional partition is inconsistent with the first data identifier.
In this way, under normal conditions, the data writing sequence is to backup the third target data in the functional partition first, and then write the third target data in the upgrade partition. Therefore, if it is determined that the third target data is not backed up by the functional partition, it may be considered that the updated partition still stores the correct data before updating, that is, the functional partition remains in the operable state, and the process may directly return to step 101 to establish a connection with the server again and perform updating again. If the functional partition is determined to be backed up with the third target data, it can be considered that abnormal power failure occurs when the third target data is written into the upgrading partition, at this time, the upgrading partition does not store the correct data before updating or the correct data after updating, and the upgrading partition is restored, re-networked and re-updated in the subsequent steps according to the third target data backed up by the functional partition.
In some embodiments, if no exception occurs when the first target data is written into the check partition, the check partition further stores a second data identifier corresponding to the second target data, and the method may further include: if the third target data is not abnormal when being written into the upgrading partition, acquiring a third current data identifier corresponding to the third current data in the functional partition through a boot loader; and if the third current data identifier is not consistent with the second data identifier, determining that an exception occurs when the second target data is written into the functional partition, and returning to execute the step 101.
Specifically, the second data identifier may be an MD5 value calculated from the second target data, and similarly, the third current data identifier may also be an MD5 value calculated from the third current data. Or the second data identifier may be a version number of the second target data, where the version number may be carried at a tail of the second target data, and similarly, the third current data identifier may also be a version number carried at a tail of the third current data, if writing of the second target data into the functional partition is completed, the version number acquired by the U-Boot should be consistent with the second data identifier, and if the second target data is not written into the functional partition or writing of the second target data into the functional partition is not completed, the version number acquired by the U-Boot should be inconsistent with the second data identifier. If the third current data identifier is not consistent with the second data identifier, it may be considered that an exception occurs when the second target data is written into the functional partition, and at this time, the updated correct data is stored in the upgrade partition, then the step 101 is returned to, the network is reconnected to obtain new firmware, and the firmware upgrade is resumed.
It is easy to understand that if the third current data identifier is consistent with the second identifier, it can be determined that the firmware has been upgraded.
And 105, performing data recovery on the upgraded partition according to the backed-up third target data in the functional partition, and returning to execute the step 101.
Specifically, after data recovery is performed on the upgrade partition according to the third target data backed up by the functional partition, the upgraded correct data is stored in the upgrade partition, that is, the upgrade partition is in an operable state, and then the network can be connected again to download new firmware, so as to perform firmware upgrade again.
It is easy to understand that, when the third target data backed up in the functional partition is used to perform data recovery on the upgrade partition, erasing and writing can be performed according to the data blocks, and the content of each data block is compared, and the erasing and writing are not required when the content is the same, so that the erasing and writing speed is increased.
Specifically, referring to fig. 4, fig. 4 shows an abnormal situation and a processing manner during a firmware upgrade process, where the upgrade recovery mode is to establish a connection with the server again and download new firmware to upgrade the firmware again. As shown in fig. 4, when the upgrade partition is damaged and the function partition is backed up, the upgrade recovery mode is started after the function partition is used to recover the upgrade partition. And when the functional partition is damaged or the check partition is damaged, directly starting an upgrading recovery mode. Therefore, when the upgrading partition is kept in a running state, the firmware upgrading device can be connected with the server and can be used for upgrading the firmware again, extra storage space is not needed for backing up the data of the upgrading partition, the use of the storage space is saved, and the cost is reduced.
The firmware upgrading method provided by the embodiment of the application is characterized in that connection is established with a server, new firmware is obtained from the server, first target data, second target data and third target data contained in the new firmware are respectively written into a verification partition, a function partition and an upgrading partition of an embedded device, the new firmware is used for upgrading the firmware of the embedded device, if the embedded device is restarted during firmware upgrading, the first target data is not abnormal when being written into the verification partition, the third target data is abnormal when being written into the upgrading partition, and the function partition backs up the third target data, data recovery is performed on the upgrading partition according to the third target data backed up by the function partition, and the steps of establishing connection with the server and obtaining the new firmware from the server are returned, so that the upgrading partition is backed up through the function partition, and extra storage space is not needed for backup, so that the possibility of upgrading damage is effectively reduced, the use of the storage space is saved, and the cost is reduced.
In order to better implement the firmware upgrading method according to the embodiment of the present application, an embodiment of the present application further provides a firmware upgrading apparatus.
While method embodiments of the present application have been described above in detail, and device embodiments of the present application will be described in detail below in conjunction with fig. 5-6, it is to be understood that device embodiments correspond to method embodiments, and similar descriptions may be had with reference to method embodiments.
Fig. 5 is a schematic block diagram of a firmware upgrading apparatus 10 according to an embodiment of the present application, where the firmware upgrading apparatus 10 is applied to an embedded device, the embedded device includes a flash memory, the flash memory includes a verification partition, a function partition and an upgrade partition, and as shown in fig. 5, the firmware upgrading apparatus 10 may include:
the acquisition module 11 is configured to establish a connection with a server, acquire a new firmware from the server, and write first target data, second target data, and third target data included in the new firmware into the verification partition, the function partition, and the upgrade partition, respectively, where the new firmware is used to upgrade firmware of the embedded device;
the first judging module 12 is configured to, if the embedded device is restarted during firmware upgrade, judge whether the first target data is abnormal when written into the check partition by using a boot loader of the embedded device;
a second judging module 13, configured to, if no exception occurs when the first target data is written into the check partition, judge, by the boot loader, whether an exception occurs when the third target data is written into the upgrade partition;
a third determining module 14, configured to determine, by the boot loader, whether the third target data is backed up by the functional partition if the third target data is abnormal when written into the upgrade partition;
the recovery module 15 is configured to, if the functional partition has backed up the third target data, perform data recovery on the upgrade partition according to the backed up third target data in the functional partition; and returning to the acquisition module and executing the functions of the acquisition module.
In some embodiments, if no abnormality occurs when the first target data is written into the check partition, the check partition stores the first data identifier of the third target data, and the second determining module 13 may be specifically configured to: acquiring a first current data identifier corresponding to first current data in an upgrading partition through a boot loader; if the first current data identifier is consistent with the first data identifier, determining that no exception occurs when the third target data is written into the upgrading partition; or if the first current data identifier is inconsistent with the first data identifier, determining that the third target data is abnormal when being written into the upgrading partition.
Further, the third determining module 14 is mainly configured to: acquiring a second current data identifier corresponding to second current data in the functional partition; if the second current data identifier is consistent with the first data identifier, determining that the functional partition backs up third target data; or if the second current data identifier is inconsistent with the first data identifier, determining that the functional partition does not back up the third target data.
In some embodiments, after the third determining module 14 determines that the functional partition does not backup the third target data, it may further be configured to: and returning to the acquisition module and executing the functions of the acquisition module.
Further, if no exception occurs when the first target data is written into the verification partition, the verification partition further stores a second data identifier corresponding to the second target data, and the firmware upgrading apparatus 10 may further include a determining module, configured to: if the third target data is not abnormal when being written into the upgrading partition, acquiring a third current data identifier corresponding to the third current data in the functional partition through a boot loader; if the third current data identifier is inconsistent with the second data identifier, determining that the second target data is abnormal when being written into the functional partition; and returning to the step of establishing connection with the server and acquiring the new firmware from the server.
In some embodiments, the first determining module 12 may specifically be configured to: reading fourth current data in the check partition through a boot loader; if the fourth current data is in a preset format, determining that no abnormality occurs when the first target data is written into the check partition; and if the fourth current data is not in the preset format, determining that the first target data is abnormal when being written into the check partition.
Further, the first determining module 12 may be further specifically configured to: if an exception occurs when the first target data is written into the check partition, the return-to-acquisition module 11 executes the function of the acquisition module 11.
It should be noted that, for the functions of each module in the firmware upgrading apparatus 10 in the embodiment of the present application, reference may be made to the specific implementation manner in each method embodiment described above, and details are not described here again.
The modules in the firmware upgrading device can be wholly or partially realized by software, hardware and a combination thereof. The modules may be embedded in hardware or independent of a processor in the computer device, or may be stored in a memory in the computer device in software, so that the processor can call and execute operations corresponding to the modules.
The firmware upgrading apparatus 10 according to the embodiment of the application establishes a connection with a server through an obtaining module 11, obtains a new firmware from the server, and writes first target data, second target data, and third target data included in the new firmware into a verification partition, a function partition, and an upgrade partition of an embedded device, respectively, where the new firmware is used to upgrade the firmware of the embedded device, if the embedded device is restarted during firmware upgrade, a first determining module 12 determines whether an abnormality occurs when the first target data is written into the verification partition through a boot loader of the embedded device, and if the first target data is not written into the verification partition, a second determining module 13 determines whether an abnormality occurs when the third target data is written into the upgrade partition through the boot loader, and if the third target data is written into the upgrade partition, the third determining module 14 determines whether the functional partition has backed up the third target data by using the boot loader, and if the functional partition has backed up the third target data, the recovering module 15 performs data recovery on the upgraded partition according to the backed up third target data in the functional partition, and returns to the obtaining module 11 to execute the function of the obtaining module 11. According to the method and the device, the upgrading partition is backed up through the functional partition, and extra storage space is not needed for backup, so that the possibility of upgrading damage is effectively reduced, the use of the storage space is saved, and the cost is reduced.
In addition, an embodiment of the present application further provides a computer device, where the computer device may be an embedded device, and the embedded device may be a terminal device such as a notebook computer, a Personal Computer (PC), a Personal Digital Assistant (PDA), and the like. As shown in fig. 6, fig. 6 is a schematic structural diagram of a computer device according to an embodiment of the present application. The computer device 2000 includes a processor 2001 with one or more processing cores, a memory 2002 with one or more computer-readable storage media, and a computer program stored on the memory 2002 and executable on the processor. The processor 2001 is electrically connected to the memory 2002. Those skilled in the art will appreciate that the computer device configurations illustrated in the figures are not meant to be limiting of computer devices and may include more or fewer components than those illustrated, or some components may be combined, or a different arrangement of components.
The processor 2001 is a control center of the computer device 2000, connects the respective parts of the entire computer device 2000 by using various interfaces and lines, and performs various functions of the computer device 2000 and processes data by operating or loading software programs and/or modules stored in the memory 2002 and calling data stored in the memory 2002, thereby integrally monitoring the computer device 2000.
In the embodiment of the present application, the processor 2001 in the computer device 2000 loads instructions corresponding to processes of one or more application programs into the memory 2002, and the processor 2001 runs the application programs stored in the memory 2002, thereby implementing various functions as follows:
establishing connection with a server, acquiring new firmware from the server, and writing first target data, second target data and third target data contained in the new firmware into a verification partition, a function partition and an upgrading partition respectively, wherein the new firmware is used for upgrading the firmware of the embedded equipment; if the embedded equipment is restarted during firmware upgrading, judging whether the first target data is abnormal when being written into the check partition through a boot loader of the embedded equipment; if the first target data are not abnormal when written into the check partition, judging whether the third target data are abnormal when written into the upgrade partition by a boot loader; if the third target data is abnormal when being written into the upgrading partition, judging whether the third target data is backed up by the functional partition or not by the boot loader; if the functional partition has backed up the third target data, performing data recovery on the upgrade partition according to the backed up third target data in the functional partition; and returning to the step of establishing connection with the server and acquiring the new firmware from the server.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
Optionally, as shown in fig. 6, the computer device 2000 further includes: touch display 2003, radio frequency circuit 2004, audio circuit 2005, input unit 2006 and power 2007. The processor 2001 is electrically connected to the touch display screen 2003, the rf circuit 2004, the audio circuit 2005, the input unit 2006 and the power supply 2007 respectively. Those skilled in the art will appreciate that the computer device configuration illustrated in FIG. 6 does not constitute a limitation of computer devices, and may include more or fewer components than those illustrated, or some components may be combined, or a different arrangement of components.
The touch display screen 2003 may be used to display a graphical user interface and receive operation instructions generated by a user acting on the graphical user interface. The touch display screen 2003 may include a display panel and a touch panel. The display panel may be used, among other things, to display information entered by or provided to a user and various graphical user interfaces of the computer device, which may be made up of graphics, text, icons, video, and any combination thereof. Alternatively, the display panel may be configured in the form of a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), or the like. The touch panel may be used to collect touch operations of a user on or near the touch panel (for example, operations of the user on or near the touch panel using any suitable object or accessory such as a finger, a stylus pen, and the like), and generate corresponding operation instructions, and the operation instructions execute corresponding programs. Alternatively, the touch panel may include two parts, a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, and sends the touch point coordinates to the processor 2001, and can receive and execute commands sent from the processor 2001. The touch panel may overlay the display panel and, when the touch panel detects a touch operation thereon or thereabout, communicate to the processor 2001 to determine the type of touch event, and the processor 2001 then provides a corresponding visual output on the display panel in accordance with the type of touch event. In the embodiment of the present application, a touch panel and a display panel may be integrated into the touch display screen 2003 to realize input and output functions. However, in some embodiments, the touch panel and the touch panel can be implemented as two separate components to perform the input and output functions. That is, the touch display screen 2003 may also implement an input function as part of the input unit 2006.
The rf circuit 2004 may be used for transceiving rf signals to establish wireless communication with a network device or other computer device via wireless communication, and for transceiving signals with the network device or other computer device.
The audio circuit 2005 may be used to provide an audio interface between a user and a computer device through a speaker, microphone. The audio circuit 2005 can transmit the electrical signal converted from the received audio data to a speaker, and convert the electrical signal into a sound signal for output; on the other hand, the microphone converts a collected sound signal into an electric signal, converts the electric signal into audio data after being received by the audio circuit 2005, processes the audio data by the audio data output processor 2001, and then sends the audio data to, for example, another computer device via the radio frequency circuit 2004, or outputs the audio data to the memory 2002 for further processing. The audio circuitry 2005 may also include an earbud jack to provide communication of a peripheral headset with the computer device.
The input unit 2006 may be used to receive input numbers, character information, or user characteristic information (e.g., fingerprint, iris, facial information, etc.), and generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.
A power supply 2007 is used to power the various components of the computer device 2000. Optionally, the power supply 2007 may be logically connected to the processor 2001 through a power management system, so that functions of managing charging, discharging, power consumption management, and the like are implemented through the power management system. The power supply 2007 may also include any component of one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, and the like.
Although not shown in fig. 6, the computer device 2000 may further include a camera, a sensor, a wireless fidelity module, a bluetooth module, etc., which will not be described herein.
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.
As can be seen from the above, the computer device provided in this embodiment, by establishing a connection with the server, acquiring a new firmware from the server, and writing first target data, second target data, and third target data included in the new firmware into the verification partition, the function partition, and the upgrade partition, respectively, the new firmware is used to upgrade the firmware of the embedded device; if the embedded equipment is restarted during firmware upgrading, judging whether the first target data is abnormal when being written into the check partition through a boot loader of the embedded equipment; if the first target data are not abnormal when written into the check partition, judging whether the third target data are abnormal when written into the upgrade partition by a boot loader; if the third target data is abnormal when being written into the upgrading partition, judging whether the third target data is backed up by the functional partition or not by the boot loader; if the functional partition has backed up the third target data, performing data recovery on the upgrade partition according to the backed up third target data in the functional partition; and returning to the step of establishing connection with the server and acquiring new firmware from the server, thereby effectively reducing the possibility of upgrading damage, saving the use of storage space and further reducing the cost.
It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions or by associated hardware controlled by the instructions, which may be stored in a computer readable storage medium and loaded and executed by a processor.
To this end, embodiments of the present application provide a computer-readable storage medium, in which a plurality of computer programs are stored, and the computer programs can be loaded by a processor to execute the steps in any firmware upgrading method provided by the embodiments of the present application. For example, the computer program may perform the steps of:
establishing connection with a server, acquiring new firmware from the server, and writing first target data, second target data and third target data contained in the new firmware into a verification partition, a function partition and an upgrading partition respectively, wherein the new firmware is used for upgrading the firmware of the embedded equipment;
if the embedded equipment is restarted during firmware upgrading, judging whether the first target data is abnormal when being written into the check partition through a boot loader of the embedded equipment;
if the first target data are not abnormal when written into the check partition, judging whether the third target data are abnormal when written into the upgrade partition by a boot loader;
if the third target data is abnormal when being written into the upgrading partition, judging whether the third target data is backed up by the functional partition or not by the boot loader;
if the functional partition has backed up the third target data, performing data recovery on the upgrade partition according to the backed up third target data in the functional partition;
and returning to the step of establishing connection with the server and acquiring the new firmware from the server.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
Wherein the storage medium may include: a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic or optical disk, or the like.
Since the computer program stored in the storage medium can execute the steps in any firmware upgrading method provided in the embodiments of the present application, beneficial effects that can be achieved by any firmware upgrading method provided in the embodiments of the present application can be achieved, which are detailed in the foregoing embodiments and will not be described herein again.
The above detailed description is provided for a firmware upgrading method, apparatus, storage medium and computer device provided in the embodiments of the present application, and a specific example is applied in the present application to explain the principle and implementation manner of the present application, and the description of the above embodiments is only used to help understanding the method and core ideas of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.
Claims (10)
1. A firmware upgrading method is applied to an embedded device, the embedded device comprises a flash memory, the flash memory comprises a check partition, a function partition and an upgrading partition, and the method comprises the following steps:
establishing connection with a server, acquiring new firmware from the server, and writing first target data, second target data and third target data contained in the new firmware into the verification partition, the function partition and the upgrade partition respectively, wherein the new firmware is used for upgrading the firmware of the embedded equipment;
if the embedded equipment is restarted when the firmware is upgraded, judging whether the first target data is abnormal when written into the check partition through a boot loader of the embedded equipment;
if the first target data is not abnormal when written into the check partition, judging whether the third target data is abnormal when written into the upgrade partition by the boot loader;
if the third target data is abnormal when being written into the upgrading partition, judging whether the third target data is backed up by the functional partition or not through the boot loader;
if the third target data is backed up by the functional partition, performing data recovery on the upgrading partition according to the backed-up third target data in the functional partition;
and returning to the step of establishing connection with the server and acquiring new firmware from the server.
2. The firmware upgrading method according to claim 1, wherein if no exception occurs when the first target data is written into the check partition, the check partition stores a first data identifier of the third target data, and the determining, by the boot loader, whether an exception occurs when the third target data is written into the upgrade partition includes:
acquiring a first current data identifier corresponding to first current data in the upgrading partition through the boot loader;
if the first current data identifier is consistent with the first data identifier, determining that no exception occurs when the third target data is written into the upgrade partition; or
And if the first current data identifier is inconsistent with the first data identifier, determining that an exception occurs when the third target data is written into the upgrading partition.
3. The firmware upgrade method according to claim 2, wherein the determining, by the boot loader, whether the functional partition has backed up the third target data comprises:
acquiring a second current data identifier corresponding to second current data in the functional partition;
if the second current data identifier is consistent with the first data identifier, determining that the third target data is backed up by the functional partition; or
And if the second current data identifier is inconsistent with the first data identifier, determining that the third target data is not backed up by the functional partition.
4. The firmware upgrade method according to claim 3, further comprising, after the determining that the functional partition does not backup the third target data:
and returning to the step of establishing connection with the server and acquiring new firmware from the server.
5. The firmware upgrade method according to claim 2, wherein if no exception occurs when the first target data is written into the check partition, the check partition further stores a second data identifier corresponding to the second target data, and the method further comprises:
if the third target data is not abnormal when written into the upgrading partition, acquiring a third current data identifier corresponding to third current data in the functional partition through the boot loader;
if the third current data identifier is inconsistent with the second data identifier, determining that an exception occurs when the second target data is written into the functional partition;
and returning to the step of establishing connection with the server and acquiring new firmware from the server.
6. The firmware upgrading method according to claim 1, wherein the determining, by the boot loader of the embedded device, whether an exception occurs when the first target data is written into the check partition includes:
reading fourth current data in the check partition through the boot loader;
if the fourth current data is in a preset format, determining that no abnormality occurs when the first target data is written into the check partition;
and if the fourth current data is not in a preset format, determining that the first target data is abnormal when being written into the check partition.
7. The firmware upgrade method according to claim 6, further comprising:
and if the first target data is abnormal when being written into the verification partition, returning to the step of executing the connection established with the server and acquiring new firmware from the server.
8. The firmware upgrading device is applied to an embedded device, the embedded device comprises a flash memory, the flash memory comprises a check partition, a function partition and an upgrading partition, and the device comprises:
the acquisition module is used for establishing connection with a server, acquiring new firmware from the server, and respectively writing first target data, second target data and third target data contained in the new firmware into the verification partition, the function partition and the upgrade partition, wherein the new firmware is used for upgrading the firmware of the embedded equipment;
the first judgment module is used for judging whether the first target data is abnormal when being written into the check partition through a boot loader of the embedded equipment if the embedded equipment is restarted during firmware upgrading;
a second determining module, configured to determine, by the boot loader, whether an exception occurs when the third target data is written into the upgrade partition if the first target data is not written into the check partition;
a third determining module, configured to determine, by the boot loader, whether the third target data is backed up by the functional partition if an exception occurs when the third target data is written into the upgrade partition;
the recovery module is used for performing data recovery on the upgrading partition according to the backed-up third target data in the functional partition if the functional partition backs up the third target data; and returning to the acquisition module and executing the functions of the acquisition module.
9. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 7 when executing the computer program.
10. A storage medium, in which a computer program is stored, wherein the computer program, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111239446.6A CN114035818A (en) | 2021-10-25 | 2021-10-25 | Firmware upgrading method and device, computer equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111239446.6A CN114035818A (en) | 2021-10-25 | 2021-10-25 | Firmware upgrading method and device, computer equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114035818A true CN114035818A (en) | 2022-02-11 |
Family
ID=80141875
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111239446.6A Pending CN114035818A (en) | 2021-10-25 | 2021-10-25 | Firmware upgrading method and device, computer equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114035818A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115952564A (en) * | 2023-03-01 | 2023-04-11 | 荣耀终端有限公司 | Data writing method and terminal equipment |
| CN116932010A (en) * | 2023-09-14 | 2023-10-24 | 首都信息科技发展有限公司 | System firmware upgrading method, device and server |
-
2021
- 2021-10-25 CN CN202111239446.6A patent/CN114035818A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115952564A (en) * | 2023-03-01 | 2023-04-11 | 荣耀终端有限公司 | Data writing method and terminal equipment |
| CN115952564B (en) * | 2023-03-01 | 2023-08-15 | 荣耀终端有限公司 | Data writing method and terminal equipment |
| CN116932010A (en) * | 2023-09-14 | 2023-10-24 | 首都信息科技发展有限公司 | System firmware upgrading method, device and server |
| CN116932010B (en) * | 2023-09-14 | 2024-01-19 | 首都信息科技发展有限公司 | System firmware upgrading method, device and server |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10860425B2 (en) | Method for recovering basic input/output system image file of a computer system and the computer system | |
| CN110780890B (en) | System upgrading method, device, electronic equipment and medium | |
| KR101861724B1 (en) | Selective power management for pre-boot firmware updates | |
| CN112667266B (en) | Firmware upgrading method, device, equipment and storage medium | |
| CN114035818A (en) | Firmware upgrading method and device, computer equipment and storage medium | |
| CN103729220A (en) | Method and device for restoring BIOS (basic input output system) ROM (read only memory) by aid of EC (electronically controllable) ROM | |
| JPWO2006075397A1 (en) | Installation method, program, peripheral device and system | |
| CN110825419B (en) | Firmware refreshing method and device, electronic equipment and storage medium | |
| KR20200100958A (en) | Electronic device and method for prefetching application | |
| US9218249B2 (en) | Electronic apparatus, method of restoring guid partition table (GPT) and computer-readable recording medium | |
| CN112732289A (en) | Server management method and server | |
| CN111399874A (en) | System upgrading method and device, storage medium and intelligent wearable device | |
| CN109408282B (en) | Application program backup recovery method and device and computer readable storage medium | |
| CN101500330A (en) | Tool for fast and safely updating operation system of smart phone | |
| CN113396391B (en) | Application program starting method and device, electronic equipment and storage medium | |
| EP3291092B1 (en) | Data recovery method, device and terminal | |
| CN111262737A (en) | Port configuration management method and device, storage medium and terminal | |
| KR20160059181A (en) | Apparatus and method for controlling updating software of AVN system in vehicle | |
| US10389851B2 (en) | Performing power management during a download and execute operation | |
| KR20080023064A (en) | Program update method and system for wireless communication terminal | |
| CN112783535A (en) | Firmware upgrading method, embedded device and storage medium | |
| JP5659892B2 (en) | Information processing apparatus, portable terminal apparatus, and log output control method in information processing apparatus | |
| CN113127029A (en) | Firmware updating method and device, electronic equipment and storage medium | |
| CN112052122A (en) | Linux system based backup and recovery system and method | |
| CN107247642B (en) | Method and device for determining executable mapping file during system startup |
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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20220810 Address after: Floor 12-17, Unit 1, Building 2, No. 466, Xinyu Road, Chengdu High-tech Zone, Chengdu, Sichuan 610213 Applicant after: Chengdu Lianzhou International Technology Co.,Ltd. Address before: 518109 floor 5, fulizhen building, No. 1, Kefa Road, high tech park, Nanshan District, Shenzhen, Guangdong Province Applicant before: Shenzhen Lianzhou International Technology Co.,Ltd. |