Device firmware upgrade method and apparatus, and electronic device

Abstract

The application is suitable for the technical field of firmware upgrading, and provides a device firmware upgrading method, device and electronic device. The method comprises the following steps: obtaining a firmware upgrading file; based on a first partition upgrading file, a second partition upgrading file and a file system partition upgrading file in the firmware upgrading file, upgrading firmware of a first partition, firmware of a second partition and firmware of a file system partition in a preset upgrading order, and combining a first partition check value and a second partition check value in a check partition to obtain a first upgrading result corresponding to the first partition and a second upgrading result corresponding to the second partition; and determining whether the file system partition is successfully upgraded according to the first upgrading result and the second upgrading result. According to the embodiment of the application, whether the file system is successfully upgraded can be determined in the case that the upgrading is abnormal and the user configuration in the file system is not changed, so that the normal starting of the system and the stability of the device are ensured.

Description

Technical Field

[0001] This application belongs to the field of embedded software technology, and in particular relates to a device firmware upgrade method, apparatus and electronic device. Background Technology

[0002] As embedded device firmware becomes more complex and user needs change, firmware upgrades are necessary to improve or add relevant functions.

[0003] Currently, abnormal situations such as power outages may occur during firmware upgrades, making it impossible to determine whether the firmware for the file system has been written correctly, thus affecting system startup and resulting in poor device stability. Summary of the Invention

[0004] This application provides a device firmware upgrade method, apparatus, and electronic device, which can determine whether the file system upgrade was successful in the event of an upgrade failure without changing the user configuration in the file system, thereby ensuring normal system startup and device stability.

[0005] Firstly, this application provides a device firmware upgrade method, which may include:

[0006] Obtain firmware upgrade files, which include a first partition upgrade file, a second partition upgrade file, and a file system partition upgrade file;

[0007] Based on the first partition upgrade file, the second partition upgrade file, and the file system partition upgrade file, the firmware of the first partition, the firmware of the second partition, and the firmware of the file system partition are upgraded in a preset upgrade order, respectively. The first upgrade result corresponding to the first partition and the second upgrade result corresponding to the second partition are obtained by combining the check value of the first partition and the check value of the second partition in the check partition.

[0008] Based on the first upgrade result and the second upgrade result, determine whether the firmware of the file system partition has been successfully upgraded.

[0009] In one possible implementation of the first aspect, the preset upgrade sequence includes:

[0010] After upgrading the firmware of the first partition, the firmware of the file system partition is upgraded.

[0011] After upgrading the firmware of the file system partition, the firmware of the second partition is upgraded.

[0012] In one possible implementation of the first aspect, determining whether the firmware upgrade of the file system partition was successful based on the first upgrade result and the second upgrade result includes:

[0013] If both the first upgrade result and the second upgrade result are successful, then the firmware upgrade of the file system partition is determined to be successful.

[0014] If the first upgrade result is a verification failure or the second upgrade result is a verification failure, then the firmware upgrade of the file system partition is determined to have failed.

[0015] In one possible implementation of the first aspect, upgrading the firmware of the file system partition based on the file system partition upgrade file includes:

[0016] Extract the file system partition upgrade file to the directory where the file system partition is located;

[0017] The system configuration file in the decompressed file system partition upgrade file is used to overwrite the original system configuration file, thus completing the firmware upgrade of the file system partition.

[0018] In one possible implementation of the first aspect, the step of upgrading the firmware of the first partition and the second partition based on the first partition upgrade file and the second partition upgrade file respectively, and obtaining the first upgrade result corresponding to the first partition and the second upgrade result corresponding to the second partition by combining the checksum of the first partition and the checksum of the second partition in the verification partition, includes:

[0019] Read the first partition upgrade file and the second partition upgrade file into memory;

[0020] The firmware of the first partition is erased based on the upgrade file of the first partition, and the firmware of the second partition is erased based on the upgrade file of the second partition;

[0021] Calculate the first check value corresponding to the first partition and the second check value corresponding to the second partition after erasure and rewriting, respectively;

[0022] The first verification value is compared with the verification value of the first partition in the verification partition to obtain the first upgrade result;

[0023] The second verification value is compared with the verification value of the second partition in the verification partition to obtain the second upgrade result.

[0024] In one possible implementation of the first aspect, the file system partition includes multiple system files, and after the firmware of the file system partition is upgraded based on the file system partition upgrade file, the method further includes:

[0025] The system files in the file system partition are compressed to obtain a compressed system file;

[0026] The system compressed file is stored as a backup system configuration file in the backup file system partition of the backup area;

[0027] In the backup file system partition, an index file for the backup system configuration file is generated. The index file is used to record the attribute information of the backup system configuration file.

[0028] In one possible implementation of the first aspect, after determining whether the file system partition has been successfully upgraded based on the first upgrade result and the second upgrade result, the method further includes:

[0029] If the file system partition upgrade fails, the third check value of the backup system configuration file is calculated based on the index file in the backup file system partition, and the third check value is compared with the fourth check value recorded in the index file.

[0030] If the third check value is the same as the fourth check value, then the firmware of the file system partition is restored based on the backup system configuration file of the backup file system partition;

[0031] Based on the file size recorded in the index file and the size of the data returned after restoration, verify whether the backup system configuration file has been successfully restored.

[0032] Secondly, embodiments of this application provide a device firmware upgrade apparatus, which may include:

[0033] The acquisition unit is used to acquire firmware upgrade files, which include a first partition upgrade file, a second partition upgrade file, and a file system partition upgrade file.

[0034] The upgrade unit is used to upgrade the firmware of the first partition, the firmware of the second partition, and the firmware of the file system partition according to a preset upgrade order based on the first partition upgrade file, the second partition upgrade file, and the file system partition upgrade file, and to obtain a first upgrade result corresponding to the first partition and a second upgrade result corresponding to the second partition by combining the check value of the first partition and the check value of the second partition in the check partition.

[0035] The determination unit is used to determine whether the file system partition has been successfully upgraded based on the first upgrade result and the second upgrade result.

[0036] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect.

[0037] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0038] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the method described in the first aspect above.

[0039] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect, and will not be repeated here.

[0040] The beneficial effects of this application compared to the prior art are as follows: Through this application, an electronic device obtains firmware upgrade files, which include a first partition upgrade file, a second partition upgrade file, and a file system partition upgrade file. Based on these files, the firmware of the first partition, the second partition, and the file system partition are upgraded in a preset upgrade order. The checksums of the first and second partitions in the verification partition are combined to obtain a first upgrade result for the first partition and a second upgrade result for the second partition. Based on the first and second upgrade results, it is determined whether the file system partition has been successfully upgraded. By upgrading the firmware of different partitions in a preset upgrade order and verifying the results using the checksums of the verification partition, this application can determine whether the file system upgrade was successful even if an upgrade anomaly occurs without changing the user configuration in the file system, thereby ensuring normal system startup and device stability. It also has strong usability and practicality. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a schematic diagram of the partitioning architecture of the system storage medium provided in the embodiments of this application;

[0043] Figure 2This is a schematic diagram illustrating the implementation process of the device firmware upgrade method provided in the embodiments of this application;

[0044] Figure 3 This is a schematic diagram of the packaging and upgrading firmware provided in the embodiments of this application;

[0045] Figure 4 This is a schematic diagram of the upgrade process for each partition provided in the embodiments of this application;

[0046] Figure 5 This is a schematic diagram of the file system partition architecture provided in an embodiment of this application;

[0047] Figure 6 This is a schematic diagram of the index file content provided in an embodiment of this application;

[0048] Figure 7 This is a schematic diagram of the process for restoring backup firmware provided in an embodiment of this application;

[0049] Figure 8 This is a schematic diagram of the device firmware upgrade apparatus provided in the embodiments of this application;

[0050] Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0051] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0052] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0053] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0054] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0055] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0056] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0057] Currently, device firmware upgrades are used to improve device functionality or add new features. However, during the upgrade process, abnormal situations such as power outages can easily damage the firmware, making it impossible to determine whether the upgrade was successful and affecting the stability of device use.

[0058] The existing upgrade method is only applicable when the partition contains only system configuration. If the partition contains both system configuration and user configuration, the existing upgrade method will restore the user configuration to the default settings. As a result, the relevant configuration items need to be reset after each upgrade, making the device firmware upgrade operation cumbersome and inconvenient.

[0059] The existing upgrade packages are highly targeted and flexible when upgrading a certain type of file or a specific partition. However, when upgrading multiple or all partitions, multiple upgrade packages need to be distributed, making the process cumbersome. Furthermore, it is necessary to specify in advance which partition needs to be upgraded, rather than achieving a one-click upgrade.

[0060] The current upgrade method involves backing up the decompressed upgrade file, which results in a large backup file size. Furthermore, storing the backup file in the original partition can also affect the device's system startup speed to some extent.

[0061] To address the aforementioned shortcomings, this application provides a method for upgrading device firmware. By adjusting the upgrade order of each partition and based on the verification results of the upgrade process of other partitions, it is possible to determine whether the file system partition has been successfully upgraded in the event of abnormal situations such as power outages during the upgrade process. Moreover, the upgrade file only upgrades the system configuration, and the upgrade process does not change the user configuration, nor does it require resetting related configuration items. At the same time, by adding a backup partition and backing up the system configuration files in the backup partition, the impact of backup space on system startup speed is reduced. Furthermore, in order to make full use of storage space, a compressed backup method is adopted to reduce the burden on the storage medium.

[0062] The following specific examples illustrate the process of firmware upgrades for devices.

[0063] Please see Figure 1 , Figure 1 This is a schematic diagram of the partitioning architecture of the system storage medium provided in an embodiment of this application. For example... Figure 1 As shown, the system storage medium is divided into two types of partitions: primary partitions and backup partitions. The primary partition includes a verification partition, a real-time operating system (RTOS) partition, a system kernel partition, a file system partition, and a system application partition. The backup partition includes a backup verification partition, a backup real-time operating system partition, a backup system kernel partition, a backup file system partition, and a backup system application partition.

[0064] For example, to enable the doorbell device to quickly output data after capturing a face, the Real-Time Operating System (RTOS) starts first during system startup, followed by the Linux kernel. The file system partition contains system configuration files and user configuration files. During device operation, the user configuration file can receive user changes to relevant configuration settings. This user configuration file may relate to the device's encoding parameters and output image parameters. Both the RTOS and the kernel can read the contents of the file system partition and adjust the output parameters based on the user configuration file within it. Correspondingly, other partitions besides the file system partition are only modified during upgrades.

[0065] For example, the verification partition stores a structure containing the starting offset address of each partition's data, the data length (len), and the MD5 checksum. The verification partition records the MD5 checksums of partitions other than the file system partition. When packaging the firmware, the files of the corresponding partitions are read into memory, and the MD5 checksums corresponding to the data in that memory segment are calculated.

[0066] The backup partition is used to back up the file content of each partition in the primary partition. It reads the file content of the primary partition into memory, compresses it, and writes the compressed file content into the corresponding backup partition.

[0067] Based on the partitioned architecture of the system storage media described above, the implementation process of device firmware upgrades will be introduced below through specific embodiments.

[0068] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating the implementation flow of the device firmware upgrade method provided in this application embodiment. For example... Figure 2 As shown, the method may include the following steps:

[0069] S201, Obtain firmware upgrade files, the firmware upgrade files include first partition upgrade files, second partition upgrade files and file system partition upgrade files.

[0070] In some embodiments, when the device firmware is upgraded, a firmware upgrade file is sent out. This firmware upgrade file can be sent out as an upgrade package, which may include upgrade files for different partitions.

[0071] For example, the file system partition upgrade file is stored as a compressed package. The file system partition upgrades the system configuration file by default, without requiring changes to the user configuration file; the corresponding file system partition upgrade file contains the system configuration file. The first partition upgrade file can be the upgrade file corresponding to the system kernel partition, and the second partition upgrade file can be the upgrade file corresponding to the system application partition. The first and second partition upgrade files can also be upgrade files for partitions other than the file system partition, such as the upgrade file for the verification partition or the upgrade file for the real-time operating system partition.

[0072] S202, based on the first partition upgrade file, the second partition upgrade file, and the file system partition upgrade file, the firmware of the first partition, the firmware of the second partition, and the firmware of the file system partition are upgraded in a preset upgrade order, and the first upgrade result corresponding to the first partition and the second upgrade result corresponding to the second partition are obtained by combining the check value of the first partition and the check value of the second partition in the check partition.

[0073] In some embodiments, the verification partition in the primary partition records the verification values ​​of different partitions. During the upgrade process, the verification values ​​saved in the upgrade package are compared with the verification values ​​saved in the verification partition of the existing firmware. If the verification values ​​saved in the upgrade package are different from the verification values ​​saved in the verification partition of the existing firmware, the corresponding partition firmware is upgraded; otherwise, it is not upgraded.

[0074] The preset upgrade sequence may include: upgrading the firmware of the file system partition after upgrading the firmware of the first partition; and upgrading the firmware of the second partition after upgrading the firmware of the file system partition.

[0075] For example, the file system partition upgrade occurs between the first and second partition upgrades. The file system partition upgrade files are packaged using compression.

[0076] like Figure 3 The diagram shown illustrates the process of packaging and upgrading firmware according to an embodiment of this application. The upgrade file packaging process may include the following steps:

[0077] S301, package system configuration files to generate file system upgrade compressed packages.

[0078] Since file system partitions only upgrade system configuration files by default and do not modify user configuration files, the upgrade files for file system partitions only need to package the system configuration files and compress and package them.

[0079] S302, read the file system upgrade compressed package into memory; S303, read the real-time operating system (RTOS) firmware into memory; S304, read the system kernel firmware into memory; S305, read the application firmware into memory.

[0080] When upgrading device firmware, the upgrade files for each partition need to be read into memory for use during the upgrade process.

[0081] S306, calculate the checksum of different partitions and write it into memory; S307, write the memory data into the upgrade file corresponding to each partition.

[0082] The configuration file stores the offset and length of each partition. When packaging the upgrade file, this memory data can be stored in the verification partition.

[0083] After reading the upgrade files for each partition into memory, the checksums of the upgrade files in different partitions can be calculated. These checksums are then compared with the checksums already saved in the checksum partition to determine whether the corresponding partition needs to be upgraded. For example, if the checksum of the upgrade file read into memory differs from the checksum already saved in the checksum partition, then that partition is upgraded; otherwise, it is not upgraded.

[0084] like Figure 4 The diagram illustrates the upgrade process for each partition provided in this application embodiment. This upgrade process may include the following steps:

[0085] S401, Mounting the file system. The file system needs to be mounted to a directory in memory before processes can access the file system partition.

[0086] S402: Distribute the upgrade package and load it into memory. The upgrade package may include upgrade files from different partitions; however, the upgrade files for the file system partition are in compressed format, while the upgrade files for other partitions are not compressed.

[0087] S403, call the upgrade file in the upgrade package to erase and write the verification partition in the flash memory; S404, call the upgrade file in the upgrade package to erase and write the real-time operating system (RTOS) partition in the flash memory; S405, call the upgrade file in the upgrade package to erase and write the system kernel partition in the flash memory.

[0088] S406 uses the tar command to extract the file system upgrade package from the upgrade package to the directory where the file system is located, and overwrites the original system configuration file with the system configuration file of the file system upgrade package.

[0089] S407 calls the upgrade file in the upgrade package to erase and rewrite the application partition in the flash memory.

[0090] Firmware upgrades for partitions other than the file system partition are performed by erasing and rewriting the flash memory. If the file system partition is upgraded by erasing and rewriting the flash memory, the user configuration file within it will be lost, resulting in a discrepancy between the device output and the user-defined configuration settings.

[0091] In some embodiments, upgrading the firmware of a file system partition based on a file system partition upgrade file includes:

[0092] Extract the file system partition upgrade file to the directory where the file system partition is located; overwrite the original system configuration file with the system configuration file in the extracted file system partition upgrade file to complete the firmware upgrade of the file system partition.

[0093] like Figure 5 As shown, a file system partition can include system configuration files and user configuration files. Since only the system configuration files are modified during firmware upgrades, the file system partition can be upgraded by extracting the file system upgrade package and overwriting the system configuration file with the same name.

[0094] For example, the file system upgrade package can only save the checksum of the system configuration file, and the checksum saved in the checksum partition also only includes the checksum of the system configuration file. However, the file system partition also includes user configuration files. The checksum obtained after reading the file system partition from flash memory into memory includes both the system configuration file and the user configuration file. Because the file system partition is only partially upgraded, and user configurations may be modified at any time during use, firmware upgrades of the file system partition cannot be directly verified based on the checksum of the checksum partition. The upgrade results of other partitions are needed to determine whether the file system partition has been upgraded successfully. Because the file system partition is only partially upgraded, user configurations can be saved, eliminating the need for users to reset or modify them after the upgrade.

[0095] It should be noted that, Figure 4 The upgrade order of the partitions is for illustrative purposes only. The upgrade order can also be: check partition, first partition, file system partition, second partition, for example, check partition → system kernel partition → file system partition → system application partition.

[0096] In some embodiments, based on the first partition upgrade file and the second partition upgrade file, the firmware of the first partition and the firmware of the second partition are upgraded respectively, and the first upgrade result corresponding to the first partition and the second upgrade result corresponding to the second partition are obtained by combining the checksum of the first partition and the checksum of the second partition in the verification partition, including:

[0097] Read the first partition upgrade file and the second partition upgrade file into memory; erase and write the firmware of the first partition based on the first partition upgrade file and erase and write the firmware of the second partition based on the second partition upgrade file; calculate the first check value corresponding to the first partition and the second check value corresponding to the second partition after erasure and writing, respectively; compare the first check value with the check value of the first partition in the check partition to obtain the first upgrade result; compare the second check value with the check value of the second partition in the check partition to obtain the second upgrade result.

[0098] For example, other partitions determine whether the upgrade was successful by comparing the checksum stored in the checksum partition with the checksum of the data actually read into memory. If they are the same, the upgrade is considered successful; otherwise, the upgrade is considered to have failed.

[0099] Accordingly, the first and second partitions undergo firmware upgrades via flash rewriting, and the verification partition records the verification values ​​for both partitions. The verification values ​​of the first and second partitions after the flash rewriting process are calculated and compared with the recorded verification values ​​in the verification partition. If they match, the firmware upgrade for the corresponding partition is successful; otherwise, the upgrade fails. In other words, if the first verification value matches the verification value of the first partition in the verification partition, the first upgrade is successful; otherwise, the first upgrade fails. Similarly, if the second verification value matches the verification value of the second partition in the verification partition, the second upgrade is successful; otherwise, the second upgrade fails.

[0100] S203, based on the first upgrade result and the second upgrade result, determine whether the firmware of the file system partition has been successfully upgraded.

[0101] In some embodiments, based on the upgrade order described above, if the verification of the first partition and the second partition passes, the file system partition upgrade is determined to be successful; otherwise, if either of them fails the verification, the file system upgrade is determined to be unsuccessful.

[0102] In some embodiments, determining whether the firmware upgrade of the file system partition was successful based on the first upgrade result and the second upgrade result includes:

[0103] If both the first and second upgrade results are successful, the firmware upgrade of the file system partition is determined to be successful; if either the first or second upgrade result is unsuccessful, the firmware upgrade of the file system partition is determined to be unsuccessful.

[0104] For example, as shown in the upgrade process diagram in Figure 4, if a power outage occurs during the file system partition upgrade process, i.e., during the process of decompressing the file system upgrade package using the tar command, the checksum of the system kernel partition is the same as the value stored in the checksum partition, while the checksum of the system application partition is different from the value stored in the checksum partition. Therefore, the system kernel partition upgrade is successful, the system application partition upgrade fails, and the file system partition upgrade is determined to have failed.

[0105] Furthermore, based on the aforementioned upgrade sequence, a power outage during the write / erase of the verification partition can also indicate a file system partition upgrade failure. For example, if the checksum stored in the verification partition before the upgrade is the same as the actual checksums of the first and second partitions, but a power outage occurs during the write / erase of the verification partition, the checksum stored in the verification partition will not match the actual value, indicating an upgrade failure. A power outage occurring at other partition upgrade nodes, such as before or during the application partition upgrade, will also indicate a file system partition upgrade failure.

[0106] It's important to note that, typically, each device upgrade includes both the kernel and application partitions, so the file system partition upgrade is placed between these two partitions. However, the RTOS partition is not upgraded with every upgrade. Placing the file system partition between any two partitions that need upgrading indirectly verifies the file system partition upgrade process.

[0107] In some embodiments, the file system partition includes multiple system files, and after the firmware of the file system partition is upgraded based on the file system partition upgrade file, the method further includes:

[0108] Multiple system files in the file system partition are compressed to obtain a compressed system file; the compressed system file is used as a backup system configuration file and stored in the backup file system partition of the backup area; an index file of the backup system configuration file is generated in the backup file system partition, and the index file is used to record the attribute information of the backup system configuration file.

[0109] For example, if the file system partition upgrade fails, a process of restoring the backup is executed to ensure that the system configuration in the file system is normal.

[0110] like Figure 6 The diagram shows the architecture of the backup partition provided in this embodiment. After each device upgrade, the upgraded firmware for each partition is saved to the corresponding backup partition. Figure 6 As shown in Figure (a), the backup partition includes backup files corresponding to each partition; for example, the backup verification partition, the backup real-time operating system partition, the backup system kernel partition, and the backup system application partition each include corresponding backup files; among them, the backup file system partition includes backup system configuration files and index files.

[0111] For example, such as Figure 6 As shown in Figure (b), in the backup file system partition, the original file system of the primary partition is first traversed, all system configuration files are read into memory, and the total file size and checksum are recorded. Then, multiple system configuration files (e.g., file 1 and file 2) are compressed into a backup file F, which is stored in the backup file system partition as the backup system configuration file. Then, the original file size, name, and checksum are recorded (e.g., file 1 has a size of 2 and a checksum of A; file 2 has a size of 3 and a checksum of B), an index file is generated, and stored in the backup file system. The checksum in the index file can determine whether the backup was successful.

[0112] The index file stores not only the names, sizes, and checksums of each file in the original file system, but also the total file size and checksum (e.g., the total backup file size is 5, and the checksum is A+B). After the backup file is written to the backup partition, it is read into memory again and decompressed. The checksum stored in the index file is compared with the checksum calculated from the decompressed content to determine whether the backup was successful.

[0113] Correspondingly, within the backup partition, one partition corresponds to one compressed file. Other partitions can read the contents of the primary partition into memory, compress them, and write the compressed backup file into the corresponding backup partition.

[0114] In some embodiments, after determining whether the file system partition has been successfully upgraded based on the first upgrade result and the second upgrade result, the method further includes:

[0115] If the file system partition upgrade fails, a third checksum of the backup system configuration file is calculated based on the index file in the backup file system partition, and the third checksum is compared with the fourth checksum recorded in the index file. If the third checksum and the fourth checksum are the same, the firmware of the file system partition is restored based on the backup system configuration file in the backup file system partition. The restoration of the backup system configuration file is verified based on the file size recorded in the index file and the data size returned after restoration.

[0116] like Figure 7 The diagram illustrates the process of restoring backup firmware according to an embodiment of this application. The restoration process may include the following steps:

[0117] S701 decompresses the backup system configuration file in the backup file system partition into memory;

[0118] S702, calculate the check value of the data at the corresponding position and length in memory based on the contents of the index file;

[0119] S703, compare the calculated check value with the check value recorded in the index file;

[0120] S704, if the two checksums are the same, then the backup system configuration file is written to the file system;

[0121] S705: If the size of the data returned by the write function is the same as the size of the record in the index file, then the write is successful.

[0122] For example, when a file system partition upgrade fails, the backup system configuration file in the backup file system is decompressed into memory. Then, based on the file name and size recorded in the index file, it is written to the original file system. Simultaneously, a checksum is used to determine if the file was written successfully, ensuring normal file recovery. Before writing the corresponding file to the original file system, a checksum of the corresponding position and length of data in memory is calculated based on the index file content. This calculated checksum is compared with the checksum recorded in the index file. If they match, the content is written to the file. The write function then checks if the returned data size matches the recorded file size; if they do, the write was successful.

[0123] In addition, if the upgrade of other partitions fails, the original firmware files of the backup partitions can be restored to ensure the normal operation of the device.

[0124] In this embodiment, when user configuration and system configuration reside on the same partition, only the system configuration is upgraded during the upgrade process, only the system configuration is backed up upon successful upgrade backup, and only the system configuration is restored upon recovery from an upgrade failure. User configuration is only modified by the user, resulting in a good user experience and eliminating the need for post-upgrade reconfiguration, thus simplifying the upgrade process. By adjusting the partition upgrade order and utilizing the verification results of other partitions, the problem of read / write file system partitions being unable to be verified is solved, enabling timely detection and handling of anomalies. This embodiment compresses multiple system configuration files into a single file, reducing space usage, improving storage media utilization efficiency, and saving costs. Furthermore, the backup file is stored in the backup file system partition, without affecting the mounting and use of the original file system. This embodiment adds an index file to the backup file system partition, recording the filename, size, and checksum of the compressed backup file, enabling verification of successful file backup and thus improving system reliability.

[0125] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0126] Corresponding to the device firmware upgrade method described in the above embodiments, Figure 8 A structural block diagram of the device firmware upgrade apparatus provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0127] Reference Figure 8 The device includes:

[0128] The acquisition unit 81 is used to acquire firmware upgrade files, the firmware upgrade files including a first partition upgrade file, a second partition upgrade file and a file system partition upgrade file;

[0129] The upgrade unit 82 is used to upgrade the firmware of the first partition, the firmware of the second partition, and the firmware of the file system partition according to a preset upgrade order based on the first partition upgrade file, the second partition upgrade file, and the file system partition upgrade file, and to obtain the first upgrade result corresponding to the first partition and the second upgrade result corresponding to the second partition by combining the check value of the first partition and the check value of the second partition in the check partition.

[0130] The determination unit 83 is used to determine whether the file system partition has been successfully upgraded based on the first upgrade result and the second upgrade result.

[0131] Through the embodiments of this application, firmware of different partitions is upgraded according to a preset upgrade order, and verification is performed in combination with the verification value of the verification partition. This can determine whether the file system has been upgraded successfully without changing the user configuration in the file system if an upgrade anomaly occurs, thereby ensuring normal system startup and device stability.

[0132] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0133] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0134] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0135] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to execute the steps described in the various method embodiments above.

[0136] Figure 9 This is a schematic diagram of the structure of an electronic device 9 provided in an embodiment of this application. Figure 9 As shown, the electronic device 9 of this embodiment includes: at least one processor 90 ( Figure 9 Only one is shown in the diagram), memory 91, and computer program 92 stored in memory 91 and executable on at least one processor 90, wherein the processor 90 executes computer program 92 to implement the steps in the above embodiments.

[0137] The electronic device 9 may include, but is not limited to, a processor 90 and a memory 91. Those skilled in the art will understand that... Figure 9 This is merely an example of electronic device 9 and does not constitute a limitation on electronic device 9. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0138] The processor 90 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. The electronic device 9 may be a video doorbell, wireless doorbell, electronic doorbell, or peephole doorbell, or it may be an electronic device with multiple partitions on its storage medium.

[0139] In some embodiments, the memory 91 may be an internal storage unit of the electronic device 9, such as a hard disk or memory of the electronic device 9. In other embodiments, the memory 91 may be an external storage device of the electronic device 9, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 9. Furthermore, the memory 91 may include both internal and external storage units of the electronic device 9. The memory 91 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 91 can also be used to temporarily store data that has been output or will be output.

[0140] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0141] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0142] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0143] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0144] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0145] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A device firmware upgrade method, characterized in that, The method includes: Obtain firmware upgrade files, which include a first partition upgrade file, a second partition upgrade file, and a file system partition upgrade file; Based on the first partition upgrade file, the second partition upgrade file, and the file system partition upgrade file, the firmware of the first partition, the firmware of the second partition, and the firmware of the file system partition are upgraded in a preset upgrade order, respectively. The first upgrade result corresponding to the first partition and the second upgrade result corresponding to the second partition are obtained by combining the check value of the first partition and the check value of the second partition in the check partition. Based on the first upgrade result and the second upgrade result, determine whether the firmware of the file system partition has been successfully upgraded; the preset upgrade order includes: After upgrading the firmware of the first partition, the firmware of the file system partition is upgraded. After upgrading the firmware of the file system partition, the firmware of the second partition is upgraded.

2. The method as described in claim 1, characterized in that, The step of determining whether the firmware upgrade of the file system partition was successful based on the first upgrade result and the second upgrade result includes: If both the first upgrade result and the second upgrade result are successful, then the firmware upgrade of the file system partition is determined to be successful. If the first upgrade result is a verification failure or the second upgrade result is a verification failure, then the firmware upgrade of the file system partition is determined to have failed.

3. The method as described in claim 1, characterized in that, The firmware upgrade of the file system partition based on the file system partition upgrade file includes: Extract the file system partition upgrade file to the directory where the file system partition is located; The system configuration file in the decompressed file system partition upgrade file is used to overwrite the original system configuration file, thus completing the firmware upgrade of the file system partition.

4. The method as described in claim 1, characterized in that, The process involves upgrading the firmware of the first partition and the second partition based on the first partition upgrade file and the second partition upgrade file, respectively, and combining the checksums of the first partition and the second partition in the verification partition to obtain a first upgrade result corresponding to the first partition and a second upgrade result corresponding to the second partition, including: Read the first partition upgrade file and the second partition upgrade file into memory; The firmware of the first partition is erased based on the upgrade file of the first partition, and the firmware of the second partition is erased based on the upgrade file of the second partition; Calculate the first check value corresponding to the first partition and the second check value corresponding to the second partition after erasure and rewriting, respectively; The first verification value is compared with the verification value of the first partition in the verification partition to obtain the first upgrade result; The second verification value is compared with the verification value of the second partition in the verification partition to obtain the second upgrade result.

5. The method according to any one of claims 1 to 4, characterized in that, The file system partition includes multiple system files. After upgrading the firmware of the file system partition based on the file system partition upgrade file, the method further includes: The system files in the file system partition are compressed to obtain a compressed system file; The system compressed file is stored as a backup system configuration file in the backup file system partition of the backup area; In the backup file system partition, an index file for the backup system configuration file is generated. The index file is used to record the attribute information of the backup system configuration file.

6. The method as described in claim 5, characterized in that, After determining whether the file system partition has been successfully upgraded based on the first upgrade result and the second upgrade result, the method further includes: If the file system partition upgrade fails, the third check value of the backup system configuration file is calculated based on the index file in the backup file system partition, and the third check value is compared with the fourth check value recorded in the index file. If the third check value is the same as the fourth check value, then the firmware of the file system partition is restored based on the backup system configuration file of the backup file system partition; Based on the file size recorded in the index file and the size of the data returned after restoration, verify whether the backup system configuration file has been successfully restored.

7. A device firmware upgrade apparatus, characterized in that, include: The acquisition unit is used to acquire firmware upgrade files, which include a first partition upgrade file, a second partition upgrade file, and a file system partition upgrade file. The upgrade unit is used to upgrade the firmware of the first partition, the firmware of the second partition, and the firmware of the file system partition according to a preset upgrade order based on the first partition upgrade file, the second partition upgrade file, and the file system partition upgrade file, and to obtain a first upgrade result corresponding to the first partition and a second upgrade result corresponding to the second partition by combining the check value of the first partition and the check value of the second partition in the check partition. The determination unit is used to determine whether the file system partition has been successfully upgraded based on the first upgrade result and the second upgrade result; The preset upgrade sequence includes: After upgrading the firmware of the first partition, the firmware of the file system partition is upgraded. After upgrading the firmware of the file system partition, the firmware of the second partition is upgraded.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1 to 6.

Images