Equipment upgrading method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses an equipment upgrading method and device, equipment and a medium. The method comprises the following steps: if a device upgrading message is received, generating a mirror image file of a flash memory area of the device, and burning the mirror image file to obtain a to-be-upgraded device; an effective storage partition in the at least two storage partitions of the to-be-upgraded device is obtained, a preset storage address in the effective storage partition is erased, and the effective storage partition comprises a non-running partition; receiving an upgrade package corresponding to the to-be-upgraded equipment, and writing the upgrade package into the erased preset storage address; and if it is detected that the to-be-upgraded device is successfully upgraded, modifying a flag bit corresponding to the non-running partition, so as to jump to the successfully upgraded application program based on the flag bit. According to the method and the device, upgrading can be carried out in the non-running partition, non-inductive upgrading of the equipment is realized, and the equipment can smoothly jump to the upgraded application program by modifying the flag bit corresponding to the non-running partition, so that rapid recovery and seamless switching are realized.

Description

Technical Field

[0001] The present application relates to the field of information technology technology, and in particular to a device upgrading method, apparatus, electronic device, and computer-readable storage medium. Background Art

[0002] As various types of electronic devices emerge in an endless stream, the competitiveness of electronic devices of different types continues to increase. In order to reflect the advantages of electronic devices, electronic devices will be equipped with highly mature and fully functional systems. Therefore, in order to ensure the stability of the system and the diversity and integrity of functions, it is necessary to upgrade and update the systems used by electronic devices. At present. Electronic devices upgrade their systems by directly downloading upgrade packages. However, as the complexity of electronic devices increases, the size of their upgrade packages is increasing, and the duration of the upgrade is also increasing.

[0003] In the current T-Box upgrade, it is necessary to notify the MCU to upgrade. The MCU records the upgrade flag and resets. After entering the boot, it determines whether the upgrade flag is true. If it is true, the upgrade is performed. This upgrade method cannot guarantee the normal operation of the business. Once an upgrade is required, it needs to be reset, which seriously affects the user experience. Summary of the invention

[0004] To solve the above technical problems, the embodiments of the present application provide a device upgrading method and apparatus, an electronic device, a computer-readable storage medium, and a computer program product.

[0005] According to one aspect of an embodiment of the present application, there is provided a device upgrade method, which is applied to a device with at least two storage partitions in a flash memory area, comprising: if a device upgrade message is received, generating an image file of the flash memory area of ​​the device, and burning the image file to obtain the device to be upgraded; obtaining a valid storage partition among the at least two storage partitions of the device to be upgraded, and erasing a preset storage address in the valid storage partition, wherein the valid storage partition includes a non-running partition; receiving an upgrade package corresponding to the device to be upgraded, and writing the upgrade package to the preset storage address after erasure; if it is detected that the device to be upgraded is upgraded successfully, modifying a flag bit corresponding to the non-running partition to jump to the successfully upgraded application based on the flag bit.

[0006] According to one aspect of an embodiment of the present application, writing the upgrade package to the preset storage address after erasure includes: determining an address offset based on the upgrade package and the application in the non-running partition; obtaining a base address corresponding to the preset storage address, and determining a base address offset corresponding to the upgrade package based on the base address and the offset; and writing the upgrade package to the non-running partition based on the base address offset.

[0007] According to one aspect of an embodiment of the present application, determining the address offset based on the upgrade package and the application in the valid storage partition includes: calculating the data size of the upgrade package; obtaining the address jump flag corresponding to the non-running partition, and determining the address offset of the application based on the address jump flag; and determining the base address offset of the upgrade package based on the data size and the address offset.

[0008] According to one aspect of an embodiment of the present application, before erasing the preset storage address in the valid storage partition, the method also includes: receiving an upgrade prompt message, the upgrade prompt information including the data upgrade size; and determining a matching preset storage address in the non-running partition based on the data upgrade size.

[0009] According to one aspect of an embodiment of the present application, the preset storage address includes an interrupt request address, and erasing the preset storage address in the non-running partition includes: obtaining a jump flag of a device, wherein the jump flag is used to determine a running application; determining a non-running partition among the at least two storage partitions based on the jump flag; and erasing the interrupt request address corresponding to the non-running partition.

[0010] According to one aspect of an embodiment of the present application, the upgrade package includes an initial data verification value, and the method further includes: after the upgrade package is written to the preset storage address after erasure, calculating the data verification value of the written upgrade package; if the data verification value matches the initial verification value, it is determined that the upgrade of the device to be upgraded is successful.

[0011] According to one aspect of an embodiment of the present application, the method also includes: if it is detected that the upgrade package has been completely received, calculating a cyclic redundancy check value based on the written upgrade package; obtaining an initial cyclic redundancy check value corresponding to the upgrade package, and comparing the initial cyclic redundancy check value with the cyclic redundancy check value; if the comparison result indicates that the initial cyclic redundancy check value is consistent with the cyclic redundancy check value, determining that the upgrade of the device to be upgraded is successful.

[0012] According to one aspect of an embodiment of the present application, there is provided a device upgrade apparatus, which is applied to a device with at least two storage partitions in a flash memory area, the apparatus comprising: a burning module, for generating an image file of the flash memory area of ​​the device if a device upgrade message is received, and burning the image file to obtain the device to be upgraded; an erasing module, for obtaining a valid storage partition among the at least two storage partitions of the device to be upgraded, and erasing a preset storage address in the valid storage partition, wherein the valid storage partition includes a non-running partition; a writing module, for receiving an upgrade package corresponding to the device to be upgraded, and writing the upgrade package to the preset storage address after erasure; and a modifying module, for modifying a flag bit corresponding to the non-running partition if it is detected that the device to be upgraded is successfully upgraded, so as to jump to the successfully upgraded application based on the flag bit.

[0013] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the device upgrade method as described above.

[0014] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor of a computer, the computer executes the device upgrade method as described above.

[0015] According to one aspect of an embodiment of the present application, a computer program product is also provided, including a computer program, which implements the steps in the device upgrade method as described above when executed by a processor.

[0016] In the technical solution provided in the embodiment of the present application, by pre-generating and burning the image file, and erasing and writing only the preset storage address of the valid storage partition (including the non-operating partition) during the upgrade process, the errors and conflicts that may occur during the upgrade process are reduced, and the risk of upgrade failure is reduced. Since the upgrade process involves the non-operating partition, this means that during the upgrade process, the current running system of the device will not be affected. Once the upgrade is detected to be successful, by modifying the flag bit corresponding to the non-operating partition, the device can smoothly jump to the upgraded application without restarting the device, thereby achieving fast recovery and seamless switching.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0019] Figure 1 is a schematic diagram of an implementation environment for performing device upgrades according to an exemplary embodiment of the present application;

[0020] Figure 2 is a flow chart of a device upgrade method shown in an exemplary embodiment of the present application;

[0021] Figure 3 is a flow chart of a device upgrading method shown in another exemplary embodiment of the present application;

[0022] Figure 4 is a flow chart of a device upgrading method shown in another exemplary embodiment of the present application;

[0023] Figure 5 is a flow chart of a device upgrading method shown in another exemplary embodiment of the present application;

[0024] Figure 6 is a flow chart of a device upgrading method shown in another exemplary embodiment of the present application;

[0025] Figure 7 is a flow chart of a device upgrading method shown in another exemplary embodiment of the present application;

[0026] Figure 8 is a flow chart of a device upgrading method shown in another exemplary embodiment of the present application;

[0027] Fig. 9 is a schematic diagram of a brief process of performing a device upgrade in an exemplary application scenario;

[0028] Fig.10 is a block diagram of a device upgrading apparatus shown in an exemplary embodiment of the present application;

[0029] Fig.11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0030] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0031] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0032] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0033] The term "multiple" as used in this application refers to two or more than two. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0034] First of all, it should be noted that the T-Box (Telemetry Box) upgrade method does have some challenges in business continuity and user experience. This upgrade method in the Boot environment usually requires the device to be reset to enter the Boot environment, which will cause interruptions to currently running services or businesses. To improve this situation, the following strategies can be considered to optimize the upgrade process: Online (OTA) upgrade: Implement a more flexible online upgrade system (Over-The-Air, OTA) that allows updates to be downloaded and installed directly from the network while the device is running without restarting the device or entering the Boot environment. This can be done by implementing an upgrade agent at the application layer, which is responsible for checking for updates, downloading update packages, and installing updates at appropriate times (such as low-load periods).

[0035] Phased upgrade: If a full online upgrade is not feasible, consider implementing a phased upgrade. For example, you can first download the update package to non-volatile storage (such as Flash or SD card), and then enter the Boot environment to upgrade at the next restart, but the restart can be scheduled during off-peak hours.

[0036] Smooth restart: If you must restart to enter the Boot environment for upgrade, try to implement a smooth restart process, such as notifying the user or system administrator of the upcoming restart and saving the current working status as much as possible so that it can be quickly restored after the restart.

[0037] Dual systems or A / B partitions: Use dual systems or A / B partitions, where one system (or partition) runs the current version and the other is used for upgrades. After the upgrade package is downloaded and verified, it switches to the upgraded system when it restarts. This ensures that business will not be interrupted during the upgrade process because there is always one system available.

[0038] Figure 1 FIG. 1 is a real-time environment diagram of a device upgrade shown in an exemplary embodiment of the present application. Figure 1 As shown, for a device 110 having at least two storage partitions in the flash memory area, after the upgrade server 120 receives the device upgrade message, it can generate an image file of the flash memory area of ​​the device 110, and burn the image file to obtain the corresponding device to be upgraded, and then obtain the valid storage partition in the at least two storage partitions of the device to be upgraded, and erase the preset storage address in the valid storage partition, wherein the valid partition can be a non-running partition in at least two storage groups, and then receive the upgrade package corresponding to the device to be upgraded, and write the upgrade package to the preset storage address after erasure, and after detecting that the device to be upgraded has been successfully upgraded, modify the identification bit corresponding to the non-running partition to achieve entry into the successfully upgraded application during the next jump.

[0039] in, Figure 1 The device 110 shown may be any terminal device that supports the installation of navigation map software, such as a smart phone, a car computer, a tablet computer, a laptop computer, or a wearable device, but is not limited thereto. Figure 1 The upgrade server 220 shown is an upgrade server, which can be, for example, an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, etc., and is not limited here. The device 110 can communicate with the upgrade server 120 through wireless networks such as 3G (third generation mobile information technology), 4G (fourth generation mobile information technology), and 5G (fifth generation mobile information technology), and is not limited here.

[0040] In the current T-Box upgrade, the MCU needs to be notified to upgrade. The MCU records the upgrade flag and resets. After entering the boot, it determines whether the upgrade flag is true. If it is true, the upgrade is performed. This upgrade method cannot guarantee the normal operation of the business. Once an upgrade is required, it needs to be reset. . Affecting the user experience.

[0041] The problems pointed out above are generally applicable in general scenarios. To solve these problems, the embodiments of the present application respectively propose a device upgrade method, a device upgrade device, an electronic device, a computer-readable storage medium and a computer program product, which will be described in detail below.

[0042] See also Figure 2 , Figure 2 is a flowchart of a device upgrade method shown in an exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown is specifically executed by the device 110 in the implementation environment. It should be understood that the method can also be applied to other exemplary implementation environments and be specifically executed by devices in other implementation environments, and this embodiment does not limit the implementation environment to which the method is applicable.

[0043] like Figure 2 As shown, in an exemplary embodiment, the device upgrade method includes at least steps S210 to S240, which are described in detail as follows:

[0044] Step S210: If a device upgrade message is received, an image file of the flash memory area of ​​the device is generated, and the image file is burned to obtain the device to be upgraded.

[0045] Specifically, first, the device needs to be able to receive and recognize upgrade messages. This is usually done over a network (such as Wi-Fi, cellular network, wired connection, etc.) or physical media (such as a USB drive). The upgrade message can be a simple notification that a new firmware version is available for the device, or it may directly contain a download link for the upgrade package (i.e., new firmware). Before upgrading, the corresponding files of the device need to be integrated into one or more image files, which will be written directly to the flash memory area of ​​the device. The image file is a complete copy of the flash memory area of ​​the device, containing all the data and configuration required after the upgrade. The process of generating an image file may involve decompressing, compiling, or converting the files in the upgrade package to meet the hardware and firmware requirements of the device. Once the image file is ready, the next step is to burn it into the flash memory area of ​​the device. The burning process involves writing the contents of the image file into the non-volatile memory (such as flash memory) of the device, replacing the old firmware and configuration. After the burning is completed, the device usually performs a series of verification tests to ensure that the new firmware has been installed correctly and can work properly. These tests may include checking hardware compatibility, running diagnostic programs, and testing key functions. If the verification is successful, the device will restart and load the new firmware.

[0046] Step S220, obtaining a valid storage partition among at least two storage partitions of the device to be upgraded, and erasing a preset storage address in the valid storage partition, wherein the valid storage partition includes a non-operating partition.

[0047] Specifically, after identifying all storage partitions, the device needs to determine which partitions are valid, that is, they contain upgradeable data or configurations. Valid storage partitions may include device partitions, application partitions, user data partitions, etc. In this process, non-operating partitions (i.e., partitions that are not currently used by the device) are particularly important because they can be upgraded without affecting the current operation of the device. For each valid storage partition, the device needs to select or determine one or more preset storage addresses for storing upgraded data or configurations. These preset storage addresses are usually one or more specific areas within the partition, which are reserved for data writing during the upgrade process. Before writing new data to the preset storage addresses, the device needs to first erase the old data at these addresses. This is to ensure the integrity and consistency of the new data and avoid data conflicts or corruption. The erase operation may involve simple data zeroing or more complex file device formatting operations, depending on the type and purpose of the partition.

[0048] Exemplarily, after identifying all storage partitions, the device needs to filter out non-operating partitions. Non-operating partitions refer to partitions that are not currently used by the device as primary operating devices, critical applications, or real-time data storage. These partitions may contain backup data, old versions of firmware, applications that are not frequently used by users, or other data that is not immediately needed. Before determining non-operating partitions, the device should verify the status of these partitions to ensure that they are not accidentally marked as being in use or in a read-only state. If the partition status is not as expected, the device may need to perform status adjustment or error handling first. For each non-operating partition, the device needs to select or determine one or more preset storage addresses, which will be used to store upgraded data or configurations. The selection of preset storage addresses should be based on the layout of the partition, available space, and specific requirements of the upgraded data. Before writing new data to the preset storage addresses, the old data on these addresses needs to be erased. The erase operation can ensure the integrity and consistency of the new data and avoid data conflicts or corruption. The erase operation may involve simple data clearing (i.e., setting the contents of the storage unit to zero or a specific value), or a more complex file device formatting operation (if a file device originally existed on the partition).

[0049] Step S230, receiving an upgrade package corresponding to the device to be upgraded, and writing the upgrade package into the erased preset storage address.

[0050] Specifically, the device needs to be able to receive upgrade packages sent from external sources (such as servers, USB drives, or other storage media). This is usually done through a network connection (such as Wi-Fi, cellular networks, or wired connections), or by physically transferring the upgrade package directly to the device (such as plugging in a USB drive). After receiving the upgrade package, the device should verify it to ensure its integrity and authenticity. The verification process may include checking the digital signature, hash value, or checksum of the upgrade package to confirm that the package has not been tampered with during transmission and is indeed from a trusted source. Once the upgrade package is verified to be valid, the device will prepare for the write operation. This includes determining the previously erased preset storage addresses (located in the non-running partition) and ensuring that these addresses have sufficient space to store the data in the upgrade package. The device writes the data in the upgrade package to the erased preset storage addresses. The write operation may involve gradually transferring the data stream in the upgrade package to the device's storage controller, which then writes the data to the specified storage location. In this process, the device should ensure the integrity and accuracy of the data to avoid data loss or corruption.

[0051] Step S240: If it is detected that the device to be upgraded is successfully upgraded, the flag bit corresponding to the non-running partition is modified to jump to the successfully upgraded application based on the flag bit.

[0052] Specifically, it is necessary to be able to detect whether the upgrade is successful. This is usually done by verifying the integrity of the new firmware or configuration, performing some basic tests, or checking application-specific upgrade verification points. It is necessary to modify the flag bit corresponding to the non-running partition. This flag bit is a data stored in the partition metadata or a specific location to indicate the status of the partition (such as whether it has been upgraded, whether it contains valid data, etc.). Modifying the flag bit usually involves writing a new value to the specified storage location, which indicates that the partition now contains valid, upgraded firmware or configuration. Once the flag bit is correctly modified and verified, the device is ready to jump to the successfully upgraded application. This usually involves updating the configuration or settings of the bootloader so that the new firmware or configuration is loaded at the next startup. If the successfully upgraded application is immediately available (for example, it is located in a partition that can be started at any time), some additional steps may be required to activate or configure the application.

[0053] In this embodiment, by pre-generating and burning the image file, and erasing and writing only the preset storage addresses of the valid storage partitions (including the non-operating partitions) during the upgrade process, the errors and conflicts that may occur during the upgrade process are reduced, and the risk of upgrade failure is reduced. Since the upgrade process involves the non-operating partition, this means that during the upgrade process, the current running device of the device will not be affected. Once the upgrade is detected to be successful, by modifying the flag bit corresponding to the non-operating partition, the device can smoothly jump to the upgraded application without restarting the device, thereby achieving fast recovery and seamless switching.

[0054] Further, based on the above embodiments, please refer to Figure 3 In one of the exemplary embodiments provided in the present application, the specific implementation process of writing the upgrade package to the preset storage address after erasure may also include steps S310 to S330, which are described in detail as follows:

[0055] Step S310, determining an address offset based on the upgrade package and the application in the non-running partition;

[0056] Step S320, obtaining a base address corresponding to the preset storage address, and determining a base address offset corresponding to the upgrade package based on the base address and the offset;

[0057] Step S330: writing the upgrade package into the non-running partition based on the base address offset.

[0058] Specifically, first you need to analyze the contents of the upgrade package, including the firmware, configuration files, application data, etc. It contains. Understanding the size of these components and the dependencies between them is crucial to determining how to arrange their locations in the partition. Find the starting address (i.e., base address) of the non-running partition by querying the device's partition table or file device metadata. This address is the physical or logical starting point of the partition on the storage device. Apply the previously calculated address offset to the base address of the non-running partition to determine the starting address (i.e., base address offset) where the upgrade package should be written. This address is the actual write location of the upgrade package in the partition. Now, use the base address offset as the starting point to write the contents of the upgrade package to the non-running partition. This writing process should follow the data structure and order inside the upgrade package to ensure that all data is correctly placed and stored. After the writing is completed, verify whether the write operation is successful and check whether the contents of the upgrade package are stored completely and correctly at the expected address location. This can be done by reading the data in the partition and comparing it with the original data of the upgrade package.

[0059] In this embodiment, by accurately calculating the address offset, it is possible to ensure that the upgrade package is accurately written to the target location, which avoids write failure or data corruption caused by address errors and improves the stability and reliability of device upgrades. Writing the upgrade package to a specific base address offset in a non-running partition can reduce the impact on the normal operation of the device. During the upgrade process, even if an unexpected situation occurs, it will not immediately affect the core functions of the device, thereby improving the security of the device.

[0060] Further, based on the above embodiments, please refer to Figure 4 In one of the exemplary embodiments provided in the present application, the specific implementation process of determining the address offset based on the upgrade package and the application in the valid storage partition may also include steps S410 to S430, which are described in detail as follows:

[0061] Step S410, calculating the data size of the upgrade package;

[0062] Step S420, obtaining an address jump flag corresponding to the non-running partition, and determining an address offset of the application program based on the address jump flag;

[0063] Step S430, determining the base address offset of the upgrade package based on the data size and the address offset.

[0064] Specifically, it is necessary to traverse all files and data blocks in the upgrade package and calculate their total size. This usually involves reading the directory structure or metadata of the upgrade package and accumulating the size of each file or data block. The obtained data size (including firmware, configuration files, update scripts, etc.) will be used to subsequently calculate the write position of the upgrade package in the partition. The address jump mark is a specific mark or data structure in the non-running partition, which is used to indicate the starting address of different programs or data blocks in the partition. This mark may be a special value stored in the head, tail or specific position of the partition, or it may be a pointer to the internal table or index of the partition. By reading this mark, the layout of existing applications or data in the partition can be understood. Based on the information provided by the address jump mark, the starting address (or base address) of the current application in the non-running partition can be determined. Then, based on the size and layout of the application (if necessary), the address offset of the next available space can be calculated. This offset will be used to determine where the upgrade package should start writing to ensure that it does not overwrite existing important data. Now, we have the data size of the upgrade package and the address offset of the application. Adding these two values, we can get the base address offset of the upgrade package in the non-running partition. This offset is the distance from the partition start address to the upgrade package start address, which indicates the specific location where the upgrade package should be written. Use the calculated base address offset as the starting point to write the contents of the upgrade package to the non-running partition. During the writing process, the integrity and accuracy of the data should be ensured, and the data structure and order inside the upgrade package should be followed.

[0065] In this embodiment, by calculating the data size of the upgrade package, sufficient storage space can be accurately allocated to the upgrade package. This helps to avoid wasted or insufficient space and ensures that the upgrade package can be completely written to the non-running partition. By accurately calculating the address jump flag and offset, it can be ensured that the upgrade package is written to the correct location to avoid conflicts with existing data or applications. This helps to reduce errors and failures that may occur during the upgrade process and improve the stability and reliability of the device.

[0066] Further, based on the above embodiments, please refer to Figure 5 In one of the exemplary embodiments provided in the present application, before erasing the preset storage address in the above-mentioned valid storage partition, the specific implementation process of the above-mentioned device upgrade method may also include step S510 and step S520, which are described in detail as follows:

[0067] Step S510, receiving an upgrade prompt message, the upgrade prompt information including the data upgrade size;

[0068] Step S520: determining a matching preset storage address in the non-operating partition based on the data upgrade size.

[0069] Specifically, the device parses the received upgrade prompt message and extracts key information, especially the data upgrade size. This size is usually expressed in bytes, kilobytes, megabytes, or larger units, depending on the size of the upgrade package and the storage capacity of the device. Next, the device needs to evaluate the available space of the non-operating partition. This usually involves reading the partition table or file device metadata to obtain information about the total size, used space, and available space of the partition. The device needs to ensure that the non-operating partition has enough available space to accommodate the upgrade package, including the upgrade package itself and additional space that may be required (such as backup space, temporary file space, etc.). Based on the data upgrade size and the available space of the non-operating partition, the device can determine a matching preset storage address. This address should be located in the non-operating partition and have enough continuous space to store the entire upgrade package. If there are multiple preset storage addresses in the non-operating partition (for example, different partition segments or blocks), the device needs to select an address that best suits the current upgrade requirements. Once a matching preset storage address is determined, the device can prepare for a write operation. This includes ensuring the partition is in a writable state, preparing the necessary write buffers, and, if possible, performing some pre-write checks (such as verifying partition integrity, checking power status, etc.).

[0070] In this embodiment, by analyzing the size of the upgrade data, the device can intelligently select sufficient and appropriate storage space to store the upgrade package. This helps to avoid space waste and ensure that the resources of the non-running partition are optimally utilized. Selecting a storage address that matches the size of the upgrade data can reduce the risk of upgrade failure due to insufficient storage space or improper configuration, which also improves the stability and reliability of the upgrade process.

[0071] Further, based on the above embodiments, please refer to Figure 6 In one of the exemplary embodiments provided in the present application, the preset storage address includes an interrupt request address, and the specific implementation process of erasing the preset storage address in the non-running partition may also include steps S610 to S630, which are described in detail as follows:

[0072] Step S610, obtaining a jump flag of the device, where the jump flag is used to determine the running application;

[0073] Step S620, determining a non-operating partition among at least two storage partitions based on the jump flag bit;

[0074] Step S630, erasing the interrupt request address corresponding to the non-operating partition.

[0075] Specifically, first, the device needs to read the current jump flag from its storage or memory. This flag may be stored in the boot ROM, EEPROM, flash memory or other non-volatile memory. It may be a pointer, address offset or memory address directly pointing to the actual code. The device usually has multiple storage partitions for storing different device images, applications or data. By comparing the current jump flag with the starting address or specific mark of each partition, the device can determine which partition is currently running (i.e., the running partition). Then, the partitions other than the running partition can be considered as non-running partitions. In embedded devices or devices with multiple processors / controllers, each storage partition may be configured with its own interrupt request (IRQ) address or interrupt vector table. These addresses are used to transfer control to the corresponding interrupt service routine when an interrupt occurs. In order to prepare to upgrade or change the non-running partition, the device needs to find the interrupt request address or interrupt vector table corresponding to the partition and process it. During the upgrade process, in order to ensure that the non-running partition does not interfere with the running partition during the upgrade, the device may need to temporarily disable or erase the interrupt request address corresponding to the partition. This can be achieved by modifying the interrupt controller settings, pointing the interrupt vector table to an empty handler function, or directly erasing the entries in the interrupt vector table.

[0076] Furthermore, it is not necessary to erase the interrupt request address directly, because the interrupt vector table usually contains pointers to the interrupt service routines instead of storing the interrupt request addresses directly. It is more common to set these pointers to point to a null function (also called a "dumb" interrupt service routine) that does nothing when called.

[0077] In this embodiment, by erasing the interrupt request address corresponding to the non-operating partition, it is possible to avoid the non-operating partition accidentally receiving or processing the interrupt request during the upgrade or maintenance process, thereby reducing the risk of device crash or instability, which helps to improve the overall stability and reliability of the device. When performing device upgrades or maintenance, the interrupt request addresses of the non-operating partitions are erased, which means that these partitions will not be interrupted by external events, thereby reducing interference during the upgrade process. This helps to ensure the smooth progress of the upgrade process and improves the success rate of the upgrade.

[0078] Further, based on the above embodiments, please refer to Figure 7 In one of the exemplary embodiments provided in the present application, the upgrade package includes an initial data check value, and the specific implementation process of the device upgrade method may also include step S710 and step S720, which are described in detail as follows:

[0079] Step S710, after the upgrade package is written to the preset storage address after erasure, a data check value of the written upgrade package is calculated;

[0080] Step S720: If the data verification value matches the initial verification value, it is determined that the device to be upgraded is upgraded successfully.

[0081] Specifically, first, the upgrade package is written to the preset storage address that was previously erased and prepared. This writing process should ensure the integrity and accuracy of the data and avoid errors during the transmission or writing process. After the writing is completed, one or more verification algorithms (such as CRC, MD5, SHA-1, etc.) are used to calculate the data check value of the upgrade package. This check value is based on the calculation result of all the data in the upgrade package and is used for subsequent comparison with the initial check value. The initial check value is calculated when the upgrade package is created or distributed, and it represents the data integrity of the upgrade package in its original state. This value is usually provided with the upgrade package or obtained from a reliable source during the upgrade process. The calculated check value is compared with the initial check value. If the two match exactly, it can be considered that the upgrade package has been correctly written to the preset storage address and the data has not changed during the writing process. If the data check values ​​match, it can be determined that the device to be upgraded has been successfully upgraded. At this point, the device can be prepared to restart or perform other necessary subsequent operations to apply the new firmware or update.

[0082] If the data checksum does not match, it means that an error may have occurred during the writing process, or there is a problem with the upgrade package itself. At this time, the device should take appropriate error handling measures, such as rolling back to the previous version, recording an error log, or notifying the user to intervene.

[0083] In this embodiment, during the upgrade process, if the upgrade package data is erroneous or damaged, it is likely to cause upgrade failure or device abnormality. By comparing the data verification values, these potential problems can be discovered and prevented in time, thereby improving the success rate of the upgrade.

[0084] Further, based on the above embodiments, please refer to Figure 8 In one of the exemplary embodiments provided in the present application, the specific implementation process of the above device upgrade method may also include steps S810 to S830, which are described in detail as follows:

[0085] Step S810, if it is detected that all upgrade packages have been received, a cyclic redundancy check value is calculated based on the written upgrade package;

[0086] Step S820, obtaining an initial cyclic redundancy check value corresponding to the upgrade package, and comparing the initial cyclic redundancy check value with the cyclic redundancy check value;

[0087] Step S830: If the comparison result indicates that the initial cyclic redundancy check value is consistent with the cyclic redundancy check value, it is determined that the device to be upgraded is upgraded successfully.

[0088] Specifically, in the device upgrade process, cyclic redundancy check (CRC) is a commonly used data verification method used to detect errors in data transmission or storage. When it is detected that all upgrade packages have been received, the cyclic redundancy check value of the written upgrade package can be calculated and compared with the initial cyclic redundancy check value corresponding to the upgrade package to determine whether the upgrade package is complete and has not been tampered with.

[0089] First, the device needs to ensure that all data in the upgrade package has been completely received. This usually involves listening to the completion event of data reception, checking whether the number or size of received data packets meets expectations, etc. Once it is confirmed that the upgrade package has been fully received, the device can use the CRC algorithm to calculate the upgrade package data written to the preset storage address to obtain a cyclic redundancy check value (CRC value). This CRC value is based on the calculation result of all the data in the upgrade package and is used for subsequent comparison with the initial CRC value. The initial CRC value is calculated when the upgrade package is created or distributed. It represents the data integrity of the upgrade package in its original state. This value is usually provided with the upgrade package or obtained from a reliable source during the upgrade process. The calculated CRC value is compared with the initial CRC value. If the two are exactly the same, it can be assumed that there were no errors in the transmission and writing of the upgrade package, and the data remains intact. If the comparison result shows that the initial CRC value is consistent with the calculated CRC value, it can be determined that the device to be upgraded has successfully received and verified the upgrade package. At this point, the device can prepare for subsequent upgrade operations, such as restarting to apply new firmware or updates.

[0090] In this embodiment, during the upgrade process, any minor data error may cause the upgrade to fail or the device to be unstable. Through CRC verification, these potential problems can be discovered and prevented in time, thereby enhancing the reliability of the device upgrade. CRC verification can be integrated into the automated upgrade process, so that the device can automatically verify the integrity of the upgrade package and continue to perform the upgrade operation after confirmation. This reduces the need for manual intervention and improves the efficiency of the upgrade.

[0091] Fig. 9It is a brief flowchart of device upgrade in an exemplary application scenario. In the application scenario shown in 9, if a device upgrade message is received, an image file of the flash memory area of ​​the device is generated, and the image file is burned to obtain the device to be upgraded; obtain a valid storage partition in at least two storage partitions of the device to be upgraded, and erase the preset storage address in the valid storage partition, the valid storage partition includes a non-running partition; determine the address offset based on the upgrade package and the application in the non-running partition; obtain the base address corresponding to the preset storage address, and determine the base address offset corresponding to the upgrade package based on the base address and the offset; write the upgrade package to the non-running partition based on the base address offset. After the upgrade package is written to the erased preset storage address, calculate the data check value of the written upgrade package; if the data check value matches the initial check value, it is determined that the upgrade of the device to be upgraded is successful. For the detailed implementation process, please refer to the records in the aforementioned embodiments, which will not be repeated here.

[0092] Fig.10 is a block diagram of a device upgrade apparatus shown in an exemplary embodiment of the present application. The apparatus can be applied to Figure 1 The implementation environment shown in the figure is specifically configured in the device 110. The device can also be applied to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0093] like Fig.10 As shown, the exemplary device upgrade apparatus 1000 includes: a burning module 1010, which is used to generate an image file of the flash memory area of ​​the device if a device upgrade message is received, and burn the image file to obtain the device to be upgraded; an erasing module 1020, which is used to obtain a valid storage partition in at least two storage partitions of the device to be upgraded, and erase the preset storage address in the valid storage partition, the valid storage partition including a non-running partition; a writing module 1030, which is used to receive an upgrade package corresponding to the device to be upgraded, and write the upgrade package to the preset storage address after erasure; a modification module 1040, which is used to modify the flag bit corresponding to the non-running partition if it is detected that the device to be upgraded is upgraded successfully, so as to jump to the successfully upgraded application based on the flag bit.

[0094] According to one aspect of an embodiment of the present application, the above-mentioned writing module 1030 is also used to determine the address offset based on the upgrade package and the application in the non-running partition; obtain the base address corresponding to the preset storage address, and determine the base address offset corresponding to the upgrade package based on the base address and the offset; and write the upgrade package to the non-running partition based on the base address offset.

[0095] According to one aspect of an embodiment of the present application, the above-mentioned write module 1030 is also used to calculate the data size of the upgrade package; obtain the address jump flag corresponding to the non-running partition, and determine the address offset of the application based on the address jump flag; determine the base address offset of the upgrade package based on the data size and the address offset.

[0096] According to one aspect of an embodiment of the present application, the above-mentioned device upgrade apparatus also includes: a receiving module for receiving an upgrade prompt message, the upgrade prompt information including a data upgrade size; a first determination module for determining a matching preset storage address in a non-running partition based on the data upgrade size.

[0097] According to one aspect of an embodiment of the present application, the above-mentioned erase module 1020 is also used to obtain a jump flag of the device, which is used to determine the running application; determine a non-running partition in at least two storage partitions based on the jump flag; and erase the interrupt request address corresponding to the non-running partition.

[0098] According to one aspect of an embodiment of the present application, the above-mentioned device upgrade device also includes: a calculation module, which is used to calculate the data verification value of the written upgrade package after the upgrade package is written to the preset storage address after being erased; and a matching module, which is used to determine that the upgrade of the device to be upgraded is successful if the data verification value matches the initial verification value.

[0099] According to one aspect of an embodiment of the present application, the above-mentioned device upgrade device also includes: a detection module, which is used to calculate a cyclic redundancy check value based on the written upgrade package if it is detected that all upgrade packages have been received; a comparison module, which is used to obtain an initial cyclic redundancy check value corresponding to the upgrade package, and compare the initial cyclic redundancy check value with the cyclic redundancy check value; a second determination module, which is used to determine that the upgrade of the device to be upgraded is successful if the comparison result indicates that the initial cyclic redundancy check value is consistent with the cyclic redundancy check value.

[0100] It should be noted that the device upgrade apparatus provided in the above embodiment and the device upgrade method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment, and will not be repeated here. In actual application, the device upgrade apparatus provided in the above embodiment can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the apparatus into different functional modules to complete all or part of the functions described above, and this is not limited here.

[0101] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by one or more processors, the electronic device implements the device upgrade method provided in the above-mentioned embodiments.

[0102] Fig.11 The structure diagram of a computer device suitable for implementing the electronic device of the embodiment of the present application is shown. It should be noted that: Fig.11 The computer device 1100 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0103] like Fig.11 As shown, the computer device 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1102 or the program loaded from the storage part 1108 to the random access memory (RAM) 1103, such as executing the method in the above embodiment. In the RAM 1103, various programs and data required for the operation of the device are also stored. The CPU 1101, the ROM 1102 and the RAM 1103 are connected to each other through the bus 1104. The input / output (I / O) interface 1105 is also connected to the bus 1104.

[0104] The following components are connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, etc.; an output section 1107 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. A removable medium 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1110 as needed so that a computer program read therefrom is installed into the storage section 1108 as needed.

[0105] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1109, and / or installed from a removable medium 1111. When the computer program is executed by a central processing unit (CPU) 1101, various functions defined in the device of the present application are executed.

[0106] It should be noted that the computer-readable medium shown in the embodiment of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor device, apparatus or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. This propagated data signal can take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution device, apparatus or device. A computer program contained on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0107] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the devices, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based device that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0108] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0109] Another aspect of the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the device upgrade method as described above is implemented. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0110] Another aspect of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the device upgrade method provided in each of the above embodiments.

[0111] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person skilled in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A device upgrading method, characterized in that: A device for at least two storage partitions of a flash memory area, comprising: If a device upgrade message is received, an image file of the flash memory area of ​​the device is generated, and the image file is burned to obtain the device to be upgraded; Obtaining a valid storage partition from among at least two storage partitions of the device to be upgraded, and erasing a preset storage address in the valid storage partition, wherein the valid storage partition includes a non-operating partition; Receiving an upgrade package corresponding to the device to be upgraded, and writing the upgrade package to the erased preset storage address; If it is detected that the device to be upgraded is successfully upgraded, the flag bit corresponding to the non-running partition is modified to jump to the successfully upgraded application program based on the flag bit.

2. The method according to claim 1, characterized in that The step of writing the upgrade package to the erased preset storage address comprises: Determine an address offset based on the upgrade package and the application in the non-running partition; Obtaining a base address corresponding to the preset storage address, and determining a base address offset corresponding to the upgrade package based on the base address and the offset; The upgrade package is written into the non-running partition based on the base address offset.

3. The method according to claim 2, characterized in that The determining the address offset based on the upgrade package and the application in the valid storage partition includes: Calculating the data size of the upgrade package; Acquire an address jump flag corresponding to the non-running partition, and determine an address offset of the application based on the address jump flag; A base address offset of the upgrade package is determined based on the data size and the address offset.

4. The method according to claim 1, characterized in that Before erasing the preset storage address in the valid storage partition, the method further includes: receiving an upgrade prompt message, wherein the upgrade prompt message includes the data upgrade size; A matching preset storage address in the non-operating partition is determined based on the data upgrade size.

5. The method according to claim 1, characterized in that The preset storage address includes an interrupt request address, and erasing the preset storage address in the non-operating partition includes: Obtaining a jump flag of a device, wherein the jump flag is used to determine the running application; Determine a non-operating partition among the at least two storage partitions based on the jump flag bit; The interrupt request address corresponding to the non-operating partition is erased.

6. The method according to claim 1, characterized in that The upgrade package includes an initial data verification value, and the method further includes: After the upgrade package is written to the erased preset storage address, a data check value of the written upgrade package is calculated; If the data verification value matches the initial verification value, it is determined that the device to be upgraded is upgraded successfully.

7. The method according to claim 6, characterized in that The method further comprises: If it is detected that all the upgrade packages have been received, a cyclic redundancy check value is calculated based on the written upgrade packages; Obtaining an initial cyclic redundancy check value corresponding to the upgrade package, and comparing the initial cyclic redundancy check value with the cyclic redundancy check value; If the comparison result indicates that the initial cyclic redundancy check value is consistent with the cyclic redundancy check value, it is determined that the device to be upgraded is upgraded successfully.

8. A device upgrading apparatus, characterized in that: A device applied to at least two storage partitions of a flash memory area, the device comprising: A burning module, for generating an image file of the flash memory area of ​​the device upon receiving a device upgrade message, and burning the image file to obtain the device to be upgraded; An erasing module, used to obtain a valid storage partition from among at least two storage partitions of the device to be upgraded, and to erase a preset storage address in the valid storage partition, wherein the valid storage partition includes a non-operating partition; A writing module, used for receiving an upgrade package corresponding to the device to be upgraded, and writing the upgrade package into the erased preset storage address; The modification module is used to modify the flag bit corresponding to the non-running partition if it is detected that the device to be upgraded is successfully upgraded, so as to jump to the application program that has been successfully upgraded based on the flag bit.

9. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the device upgrade method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Computer-readable instructions are stored thereon, and when the computer-readable instructions are executed by a processor of a computer, the computer is caused to execute the device upgrading method according to any one of claims 1 to 7.

Images