Reliable device firmware upgrading method with high compatibility and low cost

Abstract

The invention belongs to the technical field of computers, and particularly relates to a high-compatibility low-cost reliable equipment firmware upgrading method which comprises the following steps: S1, starting to update a kernel partition mirror image; s2, checking that a kernel partition is updated, and if the kernel partition is updated, skipping to a stage S13 of recovering app data; and if not, entering S3. According to the method, a reliable main and standby upgrading function can be realized under the conditions of not changing partition layout and not expanding capacity, compared with a conventional main and standby upgrading scheme, the cost performance is higher, the method is particularly suitable for transformation of an old system, a high-reliability network remote upgrading function is realized, the complexity of firmware upgrading can be effectively reduced, the development period is shortened, the product cost is reduced, and the method is suitable for popularization and application. And good compatibility can be provided for previous and later versions by keeping the existing partition layout, and the product competitiveness is improved.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and particularly relates to a reliable device firmware upgrade method with high compatibility and low cost. Background Art

[0002] Firmware upgrade is an indispensable function in the life cycle of an embedded system. Through upgrading, vulnerabilities can be repaired, performance can be optimized, and new functions can be extended. Firmware upgrade methods can be divided into two categories: local upgrade and network upgrade. In local upgrade, the firmware file is transferred to the device through a physical connection (such as a serial port, USB, SD card, etc.) for upgrading. This method requires manual intervention and is not suitable for large-scale deployment. Network upgrade (OTA) is to remotely push the firmware to the device for upgrading through the network. This method can achieve automation, support large-scale deployment, and can significantly reduce the operation and maintenance costs. It is also the currently widely used upgrade method;

[0003] However, network upgrade also faces many challenges. Once an abnormal situation such as accidental power-off or system restart occurs during the upgrade process, it may lead to the loss of key data, and the device cannot start normally. Complex operations need to be carried out on-site to restore the device, which greatly increases the maintenance cost. Therefore, improving its reliability becomes the key;

[0004] The industry generally adopts the primary and secondary system upgrade scheme to ensure the reliability of the upgrade. Its basic idea is: construct the primary and secondary partitions to store the same data. When the data in the primary partition is damaged, the secondary partition is used to start. When the data in the secondary partition is damaged, the primary partition is used to start. The primary and secondary system ensures reliability by storing redundant data, which requires double storage space, increasing the hardware cost. At the same time, the primary and secondary scheme must be managed according to a specific partition layout, increasing the development complexity. For the transformation of old devices, it will also bring compatibility problems between the previous and current versions, resulting in a sharp increase in the transformation cost and risk. To solve the above problems, a reliable device firmware upgrade method with high compatibility and low cost is proposed in this application. Summary of the Invention

[0005] The present invention provides a reliable device firmware upgrade method with high compatibility and low cost, which can effectively solve the problems proposed in the above background art.

[0006] To achieve the above object, the present invention provides the following technical solution: A reliable device firmware upgrade method with high compatibility and low cost, including the following steps:

[0007] S1: Start updating the kernel partition image;

[0008] S2: Check the updated flag of the kernel partition. If it has been updated, jump to the S13 app data recovery stage; if not, enter S3;

[0009] S3: Check whether the uboot environment variable points to the standby kernel. If so, jump to S10 to rewrite the target partition; if not, proceed to S4;

[0010] S4: Check whether the app partition is marked as unavailable. If so, jump to S8 to rewrite the kernel to the standby space; if not, proceed to S5;

[0011] S5: Detect whether there is enough remaining space in the data partition. If not, exit the upgrade; if sufficient, enter the data backup phase of S6;

[0012] S6: Back up the app partition header data to the data partition to free up enough space for the standby system, and then enter S7;

[0013] S7: Mark the app partition as unavailable and enter S8;

[0014] S8: Rewrite the kernel to the standby space starting from the app partition header and enter S9;

[0015] S9: After successfully rewriting the standby kernel, switch the environment variable to enable the standby kernel and enter S10;

[0016] S10: Rewrite the kernel to the main target partition and enter S11;

[0017] S11: After successfully rewriting the main kernel, switch the environment variable to enable the main kernel and enter S12;

[0018] S12: After switching the boot to the main kernel, mark the kernel partition as updated and enter S13;

[0019] S13: Restore the app header data to the state before the upgrade and enter S14;

[0020] S14: Remove the unavailable mark of the app partition, restore the app reference, and enter S15;

[0021] S15: Clear the updated mark of the kernel partition to end this upgrade.

[0022] Preferably, in S6, it includes backing up the area of the app partition from the header to the length of the image to be upgraded to the data partition in the form of a file.

[0023] Preferably, in S7, mark the app partition as unavailable and write the image to be upgraded to the app partition to deploy the standby system. If power failure occurs during the writing process, the next restart will boot from the main kernel and re-enter the upgrade mode.

[0024] Preferably, in S8, the image to be upgraded is burned into the spare space starting from the head of the app partition to create a spare system.

[0025] Preferably, in S9, after successfully burning the spare kernel, the env partition is modified to point the boot environment variable to the spare kernel, that is, the next restart will boot from the spare kernel to activate the spare system.

[0026] Preferably, in S10, the image to be upgraded is burned into the target partition, i.e., the kernel partition. If the power is interrupted during the burning process, the next restart will boot from the spare kernel and re-enter the upgrade mode to upgrade the target system.

[0027] Preferably, in S11, after successfully burning the main kernel, the env partition is modified to point the boot environment variable to the main kernel, that is, the next restart will boot from the main kernel. After the burning is completed, the kernel partition is marked as updated, thereby activating the main target system.

[0028] Preferably, in S13, if the power is interrupted during the process of restoring the data at the head of the app partition, the device will boot from the main kernel and re-enter the upgrade mode.

[0029] Preferably, in S13, it also includes restoring the backed-up app head data to the app partition to restore the state before the upgrade.

[0030] Compared with the prior art, the beneficial effects of the present invention are:

[0031] The present invention can achieve a reliable primary and standby upgrade function without changing the partition layout and without the need for expansion. It is more cost-effective compared to the conventional primary and standby upgrade scheme, and is especially suitable for the transformation of old systems to achieve a highly reliable network remote upgrade function. It can effectively reduce the complexity of firmware upgrade, shorten the development cycle, reduce product costs, maintain the existing partition layout to provide good compatibility for front and back versions, and enhance product competitiveness. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The drawings are used to provide a further understanding of the present invention, and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the present invention, and do not constitute a limitation to the present invention. In the drawings:

[0033] Figure 1 is a flowchart of a reliable device firmware upgrade method with high compatibility and low cost of the present invention;

[0034] Figure 2 is a detailed description schematic diagram taking the kernel partition of the present invention as an example. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0035] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0036] An embodiment is as Figure 1-2 shown. A reliable device firmware upgrade method with high compatibility and low cost includes the following steps:

[0037] S1: Start updating the kernel partition image. This step usually involves starting the upgrade program and preparing the resources and environment required for the upgrade;

[0038] S2: Check the updated flag of the kernel partition. The system will check a specific flag to determine whether the kernel partition has been updated. If the flag indicates that it has been updated, jump to step S13 to perform app data recovery; if the flag indicates that it has not been updated, enter step S3;

[0039] S3: Check whether the uboot environment variable points to the alternate kernel. If the uboot environment variable points to the alternate kernel, this indicates that a restart may have occurred during the burning of the main kernel. Therefore, jump to step S10 to rewrite the target partition again. If it does not point to the alternate kernel, enter step S4;

[0040] S4: Check whether the app partition is marked as unavailable. If the app partition has been marked as unavailable, this indicates that a restart may have occurred during the burning of the alternate kernel. Therefore, jump to step S8 to rewrite the alternate kernel again. If the app partition is not marked as unavailable, enter step S5;

[0041] S5: Detect whether the remaining space in the data partition is sufficient. If it is not enough, exit the upgrade. If it is enough, enter the S6 data backup stage;

[0042] S6: Back up the app partition header data to the data partition, and at the same time back up the area from the header of the app partition to the length of the image to be upgraded to the data partition in the form of a file, so as to free up enough space to prepare for the alternate system;

[0043] S7: Mark the app partition as unavailable and burn the image to be upgraded to the app partition. While marking the app partition as unavailable, burn the image to be upgraded to the app partition to deploy the alternate system. If a power failure occurs during the burning process, the next restart will be able to boot from the main kernel and re-enter the upgrade mode. The purpose of this step is to deploy the alternate system;

[0044] S8: Burn the kernel to the spare space starting from the head of the app partition, and burn the image to be upgraded to the spare space starting from the head of the app partition to create a spare system;

[0045] S9: After successfully burning the spare kernel, switch the environment variable to enable the spare kernel. After successfully burning the spare kernel, modify the env partition to point the boot environment variable to the spare kernel, that is, the next restart will boot from the spare kernel to activate the spare system;

[0046] S10: Burn the kernel to the main target partition, and burn the image to be upgraded to the target partition, that is, the kernel partition. If the power is interrupted during the burning process, the next restart will boot from the spare kernel and re-enter the upgrade mode to upgrade the target system;

[0047] S11: After successfully burning the main kernel, switch the environment variable to enable the main kernel. After successfully burning the main kernel, modify the env partition to point the boot environment variable to the main kernel, that is, the next restart will boot from the main kernel. After the burning is completed, mark the kernel partition as updated to activate the main target system;

[0048] S12: After switching the boot to the main kernel, mark the kernel partition as updated;

[0049] S13: Restore the app header data to the state before the upgrade. If the power is interrupted during the process of restoring the app partition header data, the device will boot from the main kernel and re-enter the upgrade mode. It also includes restoring the backed-up app header data to the app partition to restore the state before the upgrade;

[0050] S14: Remove the unavailable mark of the app partition and restore the app reference;

[0051] S15: Clear the updated mark of the kernel partition to end this upgrade.

[0052] It should be noted that: Marking the app partition as unavailable is to prevent the files in the app partition from being referenced. Since the header data of the app partition has been modified, referencing incorrect files will cause system exceptions. Setting the updated flag of the kernel partition is to prevent repeated burning after a power failure and restart into the recovery upgrade mode during the upgrade process. The marked status can be recorded by saving it to a file in the data partition. The modification of the env partition can switch the boot of the main and spare systems by specifying variables, and limit the change to one byte to ensure the atomicity of the boot switching operation.

[0053] It should be noted that: Figure 2Uboot already contains env. Arrow 7 points to the original boot, arrows 3 and 5 point to the updated boot, and arrows 1, 2, 4, and 6 represent data copying.

[0054] This invention can achieve a reliable primary and standby upgrade function without changing the partition layout and without the need for expansion. It is more cost-effective compared to the conventional primary and standby upgrade scheme, and is especially suitable for the transformation of old systems. It can achieve a highly reliable network remote upgrade function, effectively reduce the complexity of firmware upgrade, shorten the development cycle, reduce product costs, maintain the existing partition layout to provide good compatibility for front and back versions, and enhance product competitiveness.

[0055] Finally, it should be noted that the above are only the preferred embodiments of the present invention and are not used to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A highly compatible and low-cost reliable device firmware upgrade method, characterized in that , including the following steps: S1: Start updating the kernel partition image; S2: Check the kernel partition update mark. If it has been updated, jump to S13 to restore app data; if it has not been updated, enter S3; S3: Check whether the uboot environment variable points to the backup kernel. If so, jump to S10 to re-burn the target partition; if not, enter S4; S4: Check whether the app partition is marked as unavailable. If so, jump to S8 to re-burn the kernel to the spare space. If not, enter S5; S5: Check whether the remaining space in the data partition is sufficient. If not, exit the upgrade. If sufficient, enter S6 to back up data. S6: Back up the app partition header data to the data partition to free up enough space for the backup system and enter S7; S7: Mark the app partition as unavailable and go to S8; S8: Burn the kernel to the spare space starting from the head of the app partition and enter S9; S9: After the spare kernel is successfully burned, the environment variable is switched to enable the spare kernel and enter S10; S10: Burn the kernel to the main target partition and enter S11; S11: After the main kernel is successfully burned, the environment variable is switched to enable the main kernel and enter S12; S12: After switching the boot to the main kernel, mark the kernel partition as updated and enter S13; S13: Restore the app header data to the state before the upgrade and enter S14; S14: Remove the unavailable mark of the app partition, restore the app reference, and enter S15; S15: Clear the kernel partition updated mark and end the upgrade.

2. The highly compatible, low-cost, reliable device firmware upgrade method according to claim 1, characterized in that: In the step S6, the area from the head of the app partition to the length of the image to be upgraded is backed up in the form of a file to the data partition.

3. The highly compatible, low-cost, reliable device firmware upgrade method according to claim 1, characterized in that: In S7, the app partition is marked as unavailable, and the image to be upgraded is burned into the app partition to deploy a backup system. If power is cut off during the burning process, the next restart will start from the main kernel and re-enter the upgrade mode.

4. The highly compatible, low-cost, reliable device firmware upgrade method according to claim 1, characterized in that: In S8, the image to be upgraded is burned into the spare space starting from the head of the app partition to create a spare system.

5. The highly compatible, low-cost, reliable device firmware upgrade method according to claim 1, characterized in that: In S9, after the standby kernel is successfully burned, the env partition is modified to point the boot environment variable to the standby kernel, that is, the next restart will be started from the standby kernel to activate the standby system.

6. The highly compatible, low-cost, reliable device firmware upgrade method according to claim 1, characterized in that: In S10, the image to be upgraded is burned into the target partition, namely the kernel partition. If power is cut off during the burning process, the next restart will start from the standby kernel and re-enter the upgrade mode to upgrade the target system.

7. The highly compatible, low-cost, reliable device firmware upgrade method according to claim 1, characterized in that: In S11, after the main kernel is successfully burned, the env partition is modified to point the boot environment variable to the main kernel, that is, the next restart will be started from the main kernel. After the burning is completed, the kernel partition is marked as updated, thereby activating the main target system.

8. The highly compatible, low-cost, reliable device firmware upgrade method according to claim 1, characterized in that: In S13, if power is cut off during the process of restoring the app partition header data, the device will boot from the main kernel and re-enter the upgrade mode.

9. The highly compatible, low-cost, reliable device firmware upgrade method according to claim 1, characterized in that: The S13 also includes restoring the backed-up app header data to the app partition to restore the state before the upgrade.

Images