Embedded software upgrading method and device, electronic equipment and storage medium

Abstract

The invention provides an embedded software upgrading method and device, electronic equipment and a storage medium, and the method comprises the steps: enabling a target version of embedded software to run in a first region of a storage space, and meanwhile, using a second region as a backup region to store backup software. When the first upgrading request is received, the system checks whether the backup software is the same as the target software or not, and performs copy-back processing under the condition that the backup software is inconsistent with the target software, so as to ensure that the backup software is consistent with the target software. Then, the system respectively verifies the correctness of the backup software and the target software, and determines an allowed upgrading mode according to a verification result; and finally, when a second upgrading request is received, the system selects a target upgrading mode, and the target software is upgraded based on the mode. According to the method, the upgrading stability can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of embedded software, and particularly relates to an embedded software upgrading method and device, electronic equipment and a storage medium. BACKGROUND

[0002] In an embedded system software product, software iteration is required due to functional changes and performance optimization. However, there is a certain probability that the device software is upgraded into a brick during the software upgrading process, which causes the system to be unable to normally operate and needs to be returned to the factory for maintenance.

[0003] Therefore, an upgrading method capable of improving stability is needed to solve the above problems, and there is a lack of corresponding solutions in the prior art. SUMMARY

[0004] Therefore, the embodiments of the present application provide an embedded software upgrading method and device, electronic equipment and a storage medium, which can improve the stability of upgrading.

[0005] The technical scheme of the embodiments of the present application is as follows:

[0006] In a first aspect, the embodiments of the present application provide an embedded software upgrading method, target software runs in a first region in a storage space, the storage space further includes a second region, the second region is used for backing up the target software, the target software is embedded software, and the method comprises the following steps:

[0007] In response to a first upgrading request, it is determined whether the backup software in the second region is the same as the target software in the first region, and when the backup software is different from the target software, a copy-back process is performed to make the backup software consistent with the target software;

[0008] The correctness of the backup software and the target software is determined respectively, and the allowed upgrading mode is determined based on the correctness result;

[0009] In response to a second upgrading request, a target upgrading mode is determined from the allowed upgrading mode, and the target software is upgraded based on the target upgrading mode.

[0010] In a second aspect, the embodiments of the present application further provide an embedded software upgrading device, target software runs in a first region in a storage space, the storage space further includes a second region, the second region is used for backing up the target software, the target software is embedded software, and the device comprises the following steps:

[0011] a rollback module configured to, in response to a first upgrade request, determine whether the backup software in the second region is identical to the target software in the first region, and perform a rollback process when the backup software is not identical to the target software, so as to keep the backup software consistent with the target software;

[0012] a determination module configured to determine the correctness of the backup software and the target software respectively, and determine an allowed upgrade mode based on the correctness result;

[0013] an upgrade module configured to, in response to a second upgrade request, determine a target upgrade mode from the allowed upgrade mode, and upgrade the target software based on the target upgrade mode.

[0014] In a third aspect, the embodiments of the present application further provide an electronic device, comprising a processor, a storage medium and a bus, the storage medium stores machine readable instructions executable by the processor, when the electronic device is running, the processor and the storage medium communicate through the bus, and the processor executes the machine readable instructions to perform the embedded software upgrade method of any one of the first aspect.

[0015] In a fourth aspect, the embodiments of the present application further provide a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by the processor to perform the embedded software upgrade method of any one of the first aspect.

[0016] The embodiments of the present application have the following beneficial effects:

[0017] (1) Optimized partition management strategy: the present application divides the system storage space into a first region, a second region, a third region and a fourth region, each region has a clear function and purpose. This partition management method effectively avoids the conflict between different versions of firmware in the upgrade process, while ensuring the integrity and security of system data. Such partition strategy, the system can more efficiently utilize the storage space, improves the utilization of resources.

[0018] (2) Efficient rollback strategy: the rollback strategy in the present application allows the firmware in the backup region (such as the second region) to be rolled back to the main running region (such as the first region) during the upgrade process, to ensure the continuity and stability of the system.

[0019] (3) Strict correctness verification mechanism: during the upgrade process, the present application introduces a strict correctness verification mechanism to comprehensively check and verify the upgrade file, firmware version and system state. This verification mechanism can ensure the integrity and correctness of the upgrade file, and avoid upgrade failure caused by file damage or version mismatch.

[0020] (4) Improve upgrade efficiency and success rate: through the comprehensive application of the above partition management, feedback strategy and correctness verification mechanism, the application significantly improves the efficiency and success rate of software upgrade. The upgrade process is more automated and intelligent, reducing the need for administrator intervention and reducing the risk of human error. At the same time, the system can automatically take corresponding measures to recover when problems are encountered, reducing the possibility of upgrade failure.

[0021] (5) Enhance system stability and user experience: the application significantly enhances the stability and reliability of the system by optimizing the upgrade process and introducing multiple protection mechanisms. During the upgrade process, the system can maintain continuous operation, reducing downtime and service interruption caused by upgrades. At the same time, the system can quickly recover to normal state, improving user experience and satisfaction. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be considered as limiting the scope. For those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0023] Figure 1 is a flowchart of steps S101-S103 provided by the embodiments of the present application;

[0024] Figure 2 is a flowchart of steps S201-S202 provided by the embodiments of the present application;

[0025] Figure 3 is a flowchart of steps S301-S302 provided by the embodiments of the present application;

[0026] Figure 4 is a flowchart of steps S401-S402 provided by the embodiments of the present application;

[0027] Figure 5 is a structural diagram of the embedded software upgrade device provided by the embodiments of the present application;

[0028] Figure 6 is a structural diagram of the electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0029] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. It should be understood that the drawings in the present application are only used for the purpose of description and illustration, and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn according to the actual proportions. The flowchart used in the present application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can not be implemented in sequence, and the steps without logical context relationship can be reversed in sequence or implemented simultaneously. In addition, one or more other operations can be added to the flowchart or one or more operations can be removed from the flowchart under the guidance of the content of the present application.

[0030] In the following description, "some embodiments" are related to a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subset of all possible embodiments, and can be combined with each other without conflict.

[0031] In addition, the described embodiments are only some of the embodiments of the present application, not all the embodiments. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative labor are within the scope of protection of the present application.

[0032] In the following description, the terms "first", "second", "third" are only to distinguish similar objects, and do not represent the specific order of the objects. It can be understood that "first", "second", "third" can be interchanged in specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0033] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0034] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are for the purpose of describing the embodiments of the present application, not for limiting the present application.

[0035] Reference is made to Figure 1 , Figure 1This is a flowchart illustrating steps S101-S103 of the embedded software upgrade method provided in this application embodiment, which will be combined with... Figure 1 Steps S101-S103 shown will be explained.

[0036] Step S101: In response to the first upgrade request, determine whether the backup software in the second region is the same as the target software in the first region, and perform a copy-back process when the backup software is different from the target software, so as to make the backup software consistent with the target software;

[0037] Step S102: Determine the correctness of the backup software and the target software respectively, and determine the allowed upgrade method based on the correctness results;

[0038] Step S103: In response to the second upgrade request, determine the target upgrade method from the allowed upgrade methods, and upgrade the target software based on the target upgrade method.

[0039] The above-mentioned embedded software upgrade method has the following beneficial effects:

[0040] (1) Optimized partition management strategy: This application divides the system storage space into a first region and a second region, physically isolating the software running area and the backup area. This partition management method effectively avoids conflicts between different firmware versions during the upgrade process, while ensuring the integrity and security of system data. With this partition strategy, the system can utilize storage space more efficiently and improve resource utilization.

[0041] (2) Efficient copy-back strategy: The copy-back strategy in this application allows the firmware of the backup area (such as the second area) to be copied back to the main running area (such as the first area) during the upgrade process to ensure the continuity and stability of the system.

[0042] (3) Strict correctness verification mechanism: During the upgrade process, this application introduces a strict correctness verification mechanism to comprehensively check and verify the upgrade files, firmware version, and system status. This verification mechanism can ensure the integrity and correctness of the upgrade files and avoid upgrade failures caused by file corruption or version incompatibility.

[0043] (4) Improved Upgrade Efficiency and Success Rate: Through the comprehensive application of the aforementioned partition management, copy-back strategy, and correctness verification mechanism, this application significantly improves the efficiency and success rate of software upgrades. The upgrade process is more automated and intelligent, reducing the need for administrator intervention and lowering the risk of human error. Simultaneously, the system can automatically take corresponding measures to recover from problems, reducing the possibility of upgrade failure.

[0044] (5) Enhanced System Stability and User Experience: This application significantly enhances the stability and reliability of the system by optimizing the upgrade process and introducing multiple protection mechanisms. During the upgrade process, the system can maintain continuous operation, reducing downtime and service interruptions caused by the upgrade. At the same time, the system can quickly recover to a normal state, improving user experience and satisfaction.

[0045] The exemplary steps described above in the embodiments of this application will be explained below.

[0046] In step S101, in response to the first upgrade request, it is determined whether the backup software in the second region is the same as the target software in the first region, and if the backup software is different from the target software, a copy-back process is performed to make the backup software consistent with the target software.

[0047] Here, upon receiving the first upgrade request, the system first checks whether the backup software in the second area is the same as the target software in the first area. If they are different, the system will perform a copy-back process to ensure that the backup software is consistent with the target software. The purpose of this step is to ensure that a reliable version exists during the upgrade process.

[0048] The copy-back process is implemented in the following way:

[0049] The correctness of the backup software and the target software is judged separately. When both the backup software and the target software are correct, the backup software is replaced with the target software.

[0050] When the backup software is correct and the target software is incorrect, the backup software shall replace the target software.

[0051] When the backup software is incorrect and the target software is correct, the backup software is replaced with the target software.

[0052] The copy-back process is not performed when both the backup software and the target software are incorrect.

[0053] Based on the above, it can be seen that the copy-back strategy ensures the correctness and consistency between the backup software and the target software. When the backup software differs from the target software, a copy-back is required to ensure consistency. The direction of the copy-back is determined by the correctness of the software.

[0054] When both the backup software and the target software are correct:

[0055] In this scenario, since both are correct, the system can choose to replace the backup software with the target software to ensure the backup software is the latest version. However, this is usually not necessary, as the purpose of a backup is to retain a reliable older version. Therefore, a copy-back is typically not performed in this case, but it can be done if updating the backup is required for some reason.

[0056] When the backup software is correct but the target software is incorrect:

[0057] This is a critical scenario for copy-back processing. Since the backup software is correct, but the target software has a problem, the system needs to replace the target software with the backup software to restore it to a known correct state.

[0058] When the backup software is incorrect and the target software is correct:

[0059] In this scenario, the target software is correct, but the backup software is faulty. The system typically performs a copyback, moving the target software to a second region to replace the faulty backup, thus ensuring both the target and backup software are correct and consistent. However, if the second region is corrupted, a copyback is unnecessary.

[0060] When both the backup software and the target software are incorrect:

[0061] Since neither is correct, performing a copyback is pointless, so no copyback operation is performed. At this point, the system may need to take other measures, such as obtaining the correct software version from an external source or notifying the user to perform a manual repair.

[0062] In step S102, the correctness of the backup software and the target software is determined respectively, and the allowed upgrade method is determined based on the correctness results.

[0063] When the backup software and the target software are identical from the beginning, or after a copy-back process has been performed, it is necessary to verify the correctness of the software again. This is because the copy-back operation cannot guarantee that the written data is correct. Reasons for incorrectness include: (1) external electromagnetic interference causing bit reversal inside the storage; (2) resource contention during Flash read / write operations, resulting in incorrect data being read; the written data and the read data are correct, but the data read from the source is incorrect; (3) bus interference, the bus for reading / writing Flash is interfered with. Therefore, it is necessary to check the correctness again. The correctness check can be performed based on the software's checksum.

[0064] The determination of permitted upgrade methods based on correctness results includes:

[0065] When both the backup software and the target software are correct, local and remote upgrades are permitted.

[0066] Local and remote upgrades are permitted when the backup software is correct and the target software is incorrect.

[0067] Local and remote upgrades are not allowed when the backup software is incorrect and the target software is correct.

[0068] When both the backup software and the target software are incorrect, local upgrades are allowed but remote upgrades are not.

[0069] Here, (1) when both the backup software and the target software are correct:

[0070] Allow local upgrades: When both are correct, the system has sufficient redundancy and reliability. Therefore, whether upgrading by loading a new version from local storage or downloading a new version from a remote server (i.e., remote upgrade), it is safe and reliable.

[0071] Remote upgrades are allowed: Similar to local upgrades, remote upgrades are also allowed in this case because the system has verified the correctness of the target software and backup software.

[0072] (2) When the backup software is correct but the target software is incorrect:

[0073] Allow local upgrades: Since the backup software is correct, the administrator can use the backup software to restore the system to a known correct state, and then load the new version from the local machine for the upgrade.

[0074] Remote upgrades are allowed: Despite issues with the target software, the correctness of the backup software ensures that the system can be safely upgraded remotely after recovery.

[0075] (3) When the backup software is incorrect and the target software is correct:

[0076] Local upgrades are not allowed: Using the backup software for local upgrades may introduce errors or instability due to issues with the backup software.

[0077] Remote upgrades are not permitted: In this case, remote upgrades may also pose risks, as there will be no reliable backups available for recovery should problems occur during the upgrade process.

[0078] (4) When both the backup software and the target software are incorrect:

[0079] Allowing local upgrades (but with risks): While neither is entirely correct, in certain emergency situations, administrators might still want to attempt an upgrade by loading a possible version from local storage. However, this requires the administrator to be very cautious and prepared to handle any potential problems.

[0080] Remote upgrades are not allowed: Since there is currently no reliable software version available for the system, remote upgrades may further compromise the system's stability.

[0081] In step S103, in response to the second upgrade request, a target upgrade method is determined from the allowed upgrade methods, and the target software is upgraded based on the target upgrade method.

[0082] Here, upon receiving a second upgrade request, the system selects a target upgrade method from the allowed options. The system then upgrades the target software based on the selected upgrade method. This may include downloading a new software version, replacing old files, or performing other necessary upgrade steps.

[0083] In some embodiments, see Figure 2 , Figure 2 This is a flowchart illustrating steps S201-S202 provided in an embodiment of this application. The target upgrade method includes remote upgrade. The storage space further includes a third area and a fourth area. The third area is used to receive the first upgrade firmware, and the fourth area is used to run the BOOT program. The remote upgrade can be implemented through steps S201-S202, which will be explained in conjunction with each step.

[0084] In step S201, in response to a remote upgrade request, the first upgrade firmware is received through the third region.

[0085] In step S202, the first upgrade firmware is transmitted to the first region based on the BOOT program in the fourth region to complete the remote upgrade of the target software.

[0086] Here, when the system receives a remote upgrade request, it begins preparations for the remote upgrade. A third area in the storage space is dedicated to receiving the first upgrade firmware transmitted during the remote upgrade process. This ensures that even if problems occur in the first area (where the target software resides) during the upgrade, it will not affect the upgrade firmware being received. The system receives the first upgrade firmware from the remote server via a network connection and stores it in the third area.

[0087] The fourth area in the storage space contains the BOOT program, which runs during system startup or under specific conditions and performs initialization and boot tasks. During this remote upgrade process, the BOOT program is responsible for transferring the first upgrade firmware from the third area to the first area. Once the first upgrade firmware is verified, the BOOT program starts and controls the transfer process. It reads the data from the first upgrade firmware from the third area and writes it to the first area, thus replacing the original target software. Once the first upgrade firmware is successfully transferred to the first area, the remote upgrade process is complete. The system may need to reboot for the new target software to take effect.

[0088] In some embodiments, before transferring the first upgrade firmware to the first region based on the BOOT program in the fourth region, the method further includes:

[0089] The first upgrade firmware is calibrated to determine whether it meets the upgrade requirements, and if the first upgrade firmware does not meet the upgrade requirements, the remote upgrade is stopped.

[0090] Here, before transmitting the first upgrade firmware to the first region, the system should verify it to ensure its integrity and correctness. This typically includes calculating a hash value and comparing it with a hash value provided by the server, as well as performing signature verification, etc.

[0091] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application. The target upgrade method includes local upgrade, which can be implemented through steps S301-S302. The following will be explained in conjunction with each step.

[0092] In step S301, in response to a local upgrade request, the second upgrade firmware is received through the BOOT program in the fourth region.

[0093] In step S302, the second upgrade firmware is written to the first area through the BOOT program to complete the local upgrade of the target software.

[0094] Here, when a user or administrator initiates a local upgrade request, the system begins preparing for a local upgrade. In the system's storage space, the fourth area contains the BOOT program. During the local upgrade process, the BOOT program is responsible for receiving the second upgrade firmware stored on local storage media (such as an SD card, USB device, etc.). The BOOT program starts and checks whether an available upgrade firmware (i.e., the second upgrade firmware) exists on the local storage media. If it exists, the BOOT program reads the firmware and prepares for subsequent write operations.

[0095] Before writing the second upgrade firmware to the first region, the system should verify it to ensure its integrity and correctness. This typically includes calculating a hash value and comparing it with the expected hash value, as well as performing signature verification, etc.

[0096] Once the second upgrade firmware is verified, the BOOT program will control the writing process. It will read the data of the second upgrade firmware from the local storage medium and write it to the first area, thereby replacing the original target software. During the writing process, it is necessary to ensure that the data in the first area is correctly replaced without affecting the data in other storage areas. To prevent write failures due to unexpected interruptions, mechanisms such as staged writing and checksums can be considered to improve the reliability and stability of the write process. Once the second upgrade firmware is successfully written to the first area, the local upgrade process is complete. The system may need to restart for the new target software to take effect.

[0097] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S402 provided in the embodiments of this application. The method further includes steps S401-S402, which will be explained in conjunction with each step.

[0098] In step S401, the number of times the copy-back process is performed is counted to obtain the number of copy-backs;

[0099] In step S402, when the number of copy-back attempts exceeds a preset number, the copy-back operation is no longer performed.

[0100] When it comes to software upgrades, especially firmware or software copy-back operations, it's necessary to set a limit on the number of copy-backs. This is to ensure that in the event of unforeseen problems, the system does not endlessly perform copy-back operations, leading to resource exhaustion or system instability.

[0101] At the start of the software or firmware upgrade process, initialize a counter to record the number of copy-back operations, setting it to 0. Each time the system performs a copy-back operation (e.g., copying firmware from a backup area to a target area), increment the copy-back counter by 1. After each copy-back operation, check if the copy-back counter has exceeded a preset limit. This preset limit can be set according to the specific needs and reliability requirements of the system.

[0102] In summary, the embodiments of this application have the following beneficial effects:

[0103] (1) Optimized partition management strategy: This application divides the system storage space into a first region, a second region, a third region, and a fourth region, each with a clearly defined function and purpose. This partition management method effectively avoids conflicts between different firmware versions during the upgrade process, while ensuring the integrity and security of system data. This partitioning strategy allows the system to utilize storage space more efficiently, improving resource utilization.

[0104] (2) Efficient copy-back strategy: The copy-back strategy in this application allows the firmware of the backup area (such as the second area) to be copied back to the main running area (such as the first area) during the upgrade process to ensure the continuity and stability of the system.

[0105] (3) Strict correctness verification mechanism: During the upgrade process, this application introduces a strict correctness verification mechanism to comprehensively check and verify the upgrade files, firmware version, and system status. This verification mechanism can ensure the integrity and correctness of the upgrade files and avoid upgrade failures caused by file corruption or version incompatibility.

[0106] (4) Improved Upgrade Efficiency and Success Rate: Through the comprehensive application of the aforementioned partition management, copy-back strategy, and correctness verification mechanism, this application significantly improves the efficiency and success rate of software upgrades. The upgrade process is more automated and intelligent, reducing the need for administrator intervention and lowering the risk of human error. Simultaneously, the system can automatically take corresponding measures to recover from problems, reducing the possibility of upgrade failure.

[0107] (5) Enhanced System Stability and User Experience: This application significantly enhances the stability and reliability of the system by optimizing the upgrade process and introducing multiple protection mechanisms. During the upgrade process, the system can maintain continuous operation, reducing downtime and service interruptions caused by the upgrade. At the same time, the system can quickly recover to a normal state, improving user experience and satisfaction.

[0108] Based on the same inventive concept, this application also provides an embedded software upgrade device corresponding to the embedded software upgrade method in the first embodiment. Since the principle of the device in this application is similar to that of the above-mentioned embedded software upgrade method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0109] like Figure 5 As shown, Figure 5 This is a schematic diagram of the embedded software upgrade device 500 provided in an embodiment of this application. The target software runs in a first area of ​​a storage space, and the storage space further includes a second area for backing up the target software. The target software is embedded software, and the embedded software upgrade device 500 includes:

[0110] The copy-back module 501 is used to respond to the first upgrade request, determine whether the backup software in the second region is the same as the target software in the first region, and perform a copy-back process when the backup software is different from the target software, so as to make the backup software consistent with the target software;

[0111] The determination module 502 is used to determine the correctness of the backup software and the target software respectively, and determine the allowed upgrade method based on the correctness results;

[0112] Upgrade module 503 is configured to, in response to a second upgrade request, determine a target upgrade method from the allowed upgrade methods, and upgrade the target software based on the target upgrade method.

[0113] Those skilled in the art should understand that Figure 5 The functions of each unit in the embedded software upgrade device 500 shown can be understood by referring to the relevant description of the aforementioned embedded software upgrade method. Figure 5 The functions of each unit in the embedded software upgrade device 500 shown can be implemented by a program running on the processor or by specific logic circuits.

[0114] In one possible implementation, the copy-back process is carried out in the following way:

[0115] The correctness of the backup software and the target software is judged separately. When both the backup software and the target software are correct, the backup software is replaced with the target software.

[0116] When the backup software is correct and the target software is incorrect, the backup software shall replace the target software.

[0117] When the backup software is incorrect and the target software is correct, the backup software is replaced with the target software.

[0118] The copy-back process is not performed when both the backup software and the target software are incorrect.

[0119] In one possible implementation, the determining module 502 determines the permissible upgrade method based on the correctness result, including:

[0120] When both the backup software and the target software are correct, local and remote upgrades are permitted.

[0121] Local and remote upgrades are permitted when the backup software is correct and the target software is incorrect.

[0122] Local and remote upgrades are not allowed when the backup software is incorrect and the target software is correct.

[0123] When both the backup software and the target software are incorrect, local upgrades are allowed but remote upgrades are not.

[0124] In one possible implementation, the target upgrade method includes a remote upgrade, and the storage space further includes a third region and a fourth region. The third region is used to receive the first upgrade firmware, and the fourth region is used to run the BOOT program. The remote upgrade is achieved through the following means:

[0125] In response to a remote upgrade request, the first upgrade firmware is received through the third area;

[0126] The first upgrade firmware is transmitted to the first region based on the BOOT program in the fourth region to complete the remote upgrade of the target software.

[0127] In one possible implementation, the target upgrade method includes a local upgrade, which is achieved in the following way:

[0128] In response to a local upgrade request, the second upgrade firmware is received through the BOOT program in the fourth region;

[0129] The second upgrade firmware is written to the first region through the BOOT program to complete the local upgrade of the target software.

[0130] In one possible implementation, the copy-back module 501 further includes:

[0131] The number of times the copy-back process was performed was counted to obtain the total number of copy-backs.

[0132] When the number of copy-back attempts exceeds the preset number, the copy-back operation will no longer be performed.

[0133] In one possible implementation, before the upgrade module 503 transmits the first upgrade firmware to the first region based on the BOOT program in the fourth region, the method further includes:

[0134] The first upgrade firmware is calibrated to determine whether it meets the upgrade requirements, and if the first upgrade firmware does not meet the upgrade requirements, the remote upgrade is stopped.

[0135] The aforementioned embedded software upgrade device has the following beneficial effects:

[0136] (1) Optimized partition management strategy: This application divides the system storage space into a first region, a second region, a third region, and a fourth region, each with a clearly defined function and purpose. This partition management method effectively avoids conflicts between different firmware versions during the upgrade process, while ensuring the integrity and security of system data. This partitioning strategy allows the system to utilize storage space more efficiently, improving resource utilization.

[0137] (2) Efficient copy-back strategy: The copy-back strategy in this application allows the firmware of the backup area (such as the second area) to be copied back to the main running area (such as the first area) during the upgrade process to ensure the continuity and stability of the system.

[0138] (3) Strict correctness verification mechanism: During the upgrade process, this application introduces a strict correctness verification mechanism to comprehensively check and verify the upgrade files, firmware version, and system status. This verification mechanism can ensure the integrity and correctness of the upgrade files and avoid upgrade failures caused by file corruption or version incompatibility.

[0139] (4) Improved Upgrade Efficiency and Success Rate: Through the comprehensive application of the aforementioned partition management, copy-back strategy, and correctness verification mechanism, this application significantly improves the efficiency and success rate of software upgrades. The upgrade process is more automated and intelligent, reducing the need for administrator intervention and lowering the risk of human error. Simultaneously, the system can automatically take corresponding measures to recover from problems, reducing the possibility of upgrade failure.

[0140] (5) Enhanced System Stability and User Experience: This application significantly enhances the stability and reliability of the system by optimizing the upgrade process and introducing multiple protection mechanisms. During the upgrade process, the system can maintain continuous operation, reducing downtime and service interruptions caused by the upgrade. At the same time, the system can quickly recover to a normal state, improving user experience and satisfaction.

[0141] like Figure 6 As shown, Figure 6 This is a schematic diagram of the composition structure of the electronic device 600 provided in the embodiments of this application. The electronic device 600 includes:

[0142] The device 600 includes a processor 601, a storage medium 602, and a bus 603. The storage medium 602 stores machine-readable instructions executable by the processor 601. When the electronic device 600 is running, the processor 601 communicates with the storage medium 602 via the bus 603. The processor 601 executes the machine-readable instructions to perform the steps of the embedded software upgrade method described in the embodiments of this application.

[0143] In practical applications, the various components in the electronic device 600 are coupled together via a bus 603. It is understood that the bus 603 is used to achieve communication between these components. In addition to a data bus, the bus 603 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 6 The general designated all buses as Bus 603.

[0144] The above-mentioned electronic devices have the following beneficial effects:

[0145] (1) Optimized partition management strategy: This application divides the system storage space into a first region, a second region, a third region, and a fourth region, each with a clearly defined function and purpose. This partition management method effectively avoids conflicts between different firmware versions during the upgrade process, while ensuring the integrity and security of system data. This partitioning strategy allows the system to utilize storage space more efficiently, improving resource utilization.

[0146] (2) Efficient copy-back strategy: The copy-back strategy in this application allows the firmware of the backup area (such as the second area) to be copied back to the main running area (such as the first area) during the upgrade process to ensure the continuity and stability of the system.

[0147] (3) Strict correctness verification mechanism: During the upgrade process, this application introduces a strict correctness verification mechanism to comprehensively check and verify the upgrade files, firmware version, and system status. This verification mechanism can ensure the integrity and correctness of the upgrade files and avoid upgrade failures caused by file corruption or version incompatibility.

[0148] (4) Improved Upgrade Efficiency and Success Rate: Through the comprehensive application of the aforementioned partition management, copy-back strategy, and correctness verification mechanism, this application significantly improves the efficiency and success rate of software upgrades. The upgrade process is more automated and intelligent, reducing the need for administrator intervention and lowering the risk of human error. Simultaneously, the system can automatically take corresponding measures to recover from problems, reducing the possibility of upgrade failure.

[0149] (5) Enhanced System Stability and User Experience: This application significantly enhances the stability and reliability of the system by optimizing the upgrade process and introducing multiple protection mechanisms. During the upgrade process, the system can maintain continuous operation, reducing downtime and service interruptions caused by the upgrade. At the same time, the system can quickly recover to a normal state, improving user experience and satisfaction.

[0150] This application also provides a computer-readable storage medium storing executable instructions, which, when executed by at least one processor 601, implement the embedded software upgrade method described in this application.

[0151] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD ROM), etc.; or it may be a device that includes one or any combination of the above-mentioned memories.

[0152] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0153] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0154] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0155] The aforementioned computer-readable storage media have the following beneficial effects:

[0156] (1) Optimized partition management strategy: This application divides the system storage space into a first region, a second region, a third region, and a fourth region, each with a clearly defined function and purpose. This partition management method effectively avoids conflicts between different firmware versions during the upgrade process, while ensuring the integrity and security of system data. This partitioning strategy allows the system to utilize storage space more efficiently, improving resource utilization.

[0157] (2) Efficient copy-back strategy: The copy-back strategy in this application allows the firmware of the backup area (such as the second area) to be copied back to the main running area (such as the first area) during the upgrade process to ensure the continuity and stability of the system.

[0158] (3) Strict correctness verification mechanism: During the upgrade process, this application introduces a strict correctness verification mechanism to comprehensively check and verify the upgrade files, firmware version, and system status. This verification mechanism can ensure the integrity and correctness of the upgrade files and avoid upgrade failures caused by file corruption or version incompatibility.

[0159] (4) Improved Upgrade Efficiency and Success Rate: Through the comprehensive application of the aforementioned partition management, copy-back strategy, and correctness verification mechanism, this application significantly improves the efficiency and success rate of software upgrades. The upgrade process is more automated and intelligent, reducing the need for administrator intervention and lowering the risk of human error. Simultaneously, the system can automatically take corresponding measures to recover from problems, reducing the possibility of upgrade failure.

[0160] (5) Enhanced System Stability and User Experience: This application significantly enhances the stability and reliability of the system by optimizing the upgrade process and introducing multiple protection mechanisms. During the upgrade process, the system can maintain continuous operation, reducing downtime and service interruptions caused by the upgrade. At the same time, the system can quickly recover to a normal state, improving user experience and satisfaction.

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

[0162] The modules described as separate components may or may not be physically separate. The components shown as modules 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.

[0163] In addition, the functional units in the various embodiments of this application 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.

[0164] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0165] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An embedded software upgrade method, characterized in that, The target software runs in a first region of a storage space, the storage space further includes a second region for backing up the target software, the target software being embedded software, and the method includes: In response to the first upgrade request, it is determined whether the backup software in the second region is the same as the target software in the first region, and if the backup software is different from the target software, a copy-back process is performed to make the backup software consistent with the target software; The correctness of the backup software and the target software is determined respectively, and the allowed upgrade method is determined based on the correctness results; In response to the second upgrade request, a target upgrade method is determined from the allowed upgrade methods, and the target software is upgraded based on the target upgrade method.

2. The embedded software upgrade method according to claim 1, characterized in that, The copy-back process is implemented in the following way: The correctness of the backup software and the target software is judged separately. When both the backup software and the target software are correct, the backup software is replaced with the target software. When the backup software is correct and the target software is incorrect, the backup software shall replace the target software. When the backup software is incorrect and the target software is correct, the backup software is replaced with the target software. The copy-back process is not performed when both the backup software and the target software are incorrect.

3. The embedded software upgrade method according to claim 1, characterized in that, The determination of permitted upgrade methods based on correctness results includes: When both the backup software and the target software are correct, local and remote upgrades are permitted. Local and remote upgrades are permitted when the backup software is correct and the target software is incorrect. Local and remote upgrades are not allowed when the backup software is incorrect and the target software is correct. When both the backup software and the target software are incorrect, local upgrades are allowed but remote upgrades are not.

4. The embedded software upgrade method according to claim 1, characterized in that, The target upgrade method includes remote upgrade. The storage space further includes a third area and a fourth area. The third area is used to receive the first upgrade firmware, and the fourth area is used to run the BOOT program. The remote upgrade is implemented in the following way: In response to a remote upgrade request, the first upgrade firmware is received through the third area; The first upgrade firmware is transmitted to the first region based on the BOOT program in the fourth region to complete the remote upgrade of the target software.

5. The embedded software upgrade method according to claim 4, characterized in that, The target upgrade method includes local upgrade, which is implemented in the following ways: In response to a local upgrade request, the second upgrade firmware is received through the BOOT program in the fourth region; The second upgrade firmware is written to the first region through the BOOT program to complete the local upgrade of the target software.

6. The embedded software upgrade method according to claim 1, characterized in that, The method further includes: The number of times the copy-back process was performed was counted to obtain the total number of copy-backs. When the number of copy-back attempts exceeds the preset number, the copy-back operation will no longer be performed.

7. The embedded software upgrade method according to claim 4, characterized in that, Before transferring the first upgrade firmware to the first region based on the BOOT program in the fourth region, the method further includes: The first upgrade firmware is calibrated to determine whether it meets the upgrade requirements, and if the first upgrade firmware does not meet the upgrade requirements, the remote upgrade is stopped.

8. An embedded software upgrade device, characterized in that, The target software runs in a first region of a storage space, the storage space further includes a second region for backing up the target software, the target software is embedded software, and the device includes: The copy-back module is used to respond to the first upgrade request, determine whether the backup software in the second region is the same as the target software in the first region, and perform a copy-back process when the backup software is different from the target software, so as to make the backup software consistent with the target software; The determination module is used to determine the correctness of the backup software and the target software respectively, and to determine the allowed upgrade method based on the correctness results; An upgrade module is configured to, in response to a second upgrade request, determine a target upgrade method from the allowed upgrade methods, and upgrade the target software based on the target upgrade method.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the embedded software upgrade method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the embedded software upgrade method as described in any one of claims 1 to 7.

Images