Firmware upgrading method and device

Abstract

The invention provides a firmware upgrading method and device. The method comprises the steps that an upgrade package is obtained, and the upgrade package comprises an upgrade file of firmware to be upgraded and further comprises a version list file used for recording the dependency relationship between the firmware to be upgraded; constructing an upgrading task queue according to a dependency relationship recorded by the version list file, wherein the upgrading task queue comprises file information of upgrading files of all the to-be-upgraded firmware which are sequentially arranged according to priorities; for each priority in the upgrade task queue, distributing a working unit for the upgrade file of the current priority, and calling a decompression module and a burning module in parallel by the working unit to decompress and burn the upgrade file; and after all the priorities of the upgrade task queue are processed, restarting the to-be-upgraded equipment to enable the new firmware to take effect. According to the method, a dynamic double-buffer mechanism is introduced, so that the decompression module and the burning module work in parallel through the annular buffer area, the memory occupation is reduced, and the upgrading efficiency is remarkably improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a firmware upgrade method and apparatus. Background Technology

[0002] Firmware upgrades are a core method for maintaining and updating the functions of various electronic devices, fixing defects, and improving performance. Traditional firmware upgrade schemes generally employ a combination of full decompression and serial burning: the complete upgrade package (e.g., a .ipe file) is first downloaded to the device, fully decompressed into an executable binary file (e.g., a .bin file), and then written sequentially to the device's non-volatile memory. However, this traditional method has the following problems in practical applications, especially in resource-constrained environments: (1) The pressure on memory and storage resources is enormous. During the upgrade process, the device needs to cache the entire compressed package first, and then perform full decompression in memory to generate a complete binary file. This process places high demands on the device's RAM and temporary storage space. For devices with limited memory resources (such as embedded terminals, IoT modules, edge computing nodes, etc.), decompression failure is very likely due to insufficient memory, which will cause the upgrade process to be interrupted and threaten the reliability of the system.

[0003] (2) The upgrade efficiency is low, which affects the availability of the equipment. Traditional solutions mostly rely on single-threaded decompression and burning operations, which takes a long time. When upgrading large-capacity firmware or dealing with devices with average performance, the decompression stage becomes the bottleneck of the entire upgrade process, which significantly prolongs the service interruption time of the equipment and makes it difficult to meet the requirements of industrial, communication and consumer application scenarios with strict business continuity requirements.

[0004] (3) Waste of network and bandwidth resources. Each upgrade, regardless of the scope of the modification, requires downloading the complete firmware package. This results in the transmission of a large amount of redundant data, which not only consumes valuable network bandwidth, but is also particularly detrimental in environments with pay-per-use or unstable networks, and increases the load on the upgrade server and distribution costs.

[0005] To alleviate the above problems, some improvement plans have been proposed in the industry, but shortcomings still exist: One improved approach is to directly distribute and burn multiple BIN files. This approach eliminates the need for compressed packages, directly transferring multiple independent BIN files to the device for burning. While this avoids centralized decompression, the increased number of files complicates transmission management, makes overall verification difficult, and the failure of any file transmission or verification can lead to the failure of the entire upgrade, resulting in low fault tolerance and operational efficiency.

[0006] Another improved approach relies on boot or recovery modes for upgrades. This method requires the device to enter a special boot (such as Bootloader) or recovery mode (such as Bootware) to perform the upgrade operation. Its disadvantages are complexity and difficulty in scaling; it typically requires physical interaction (such as button presses or serial commands) for each device to enter a specific mode, and errors necessitate repeated attempts. When deploying hundreds or thousands of devices in batches, this manual or semi-automatic method is almost impossible to implement, resulting in extremely high maintenance costs.

[0007] In summary, existing firmware upgrade solutions generally fall short in terms of resource consumption, upgrade efficiency, ease of operation, and cost-effectiveness. Particularly in fields involving massive numbers of resource-constrained devices, such as IoT devices, industrial control, and consumer electronics, there is an urgent need for a firmware upgrade solution that can achieve high efficiency, stability, low resource consumption, and easy scalability. Summary of the Invention

[0008] This application provides a firmware upgrade method and apparatus to reduce memory usage and improve upgrade efficiency during the firmware upgrade process.

[0009] Specifically, this application provides the following technical solution: In a first aspect, this application provides a firmware upgrade method, the method being applied to a device to be upgraded, the method comprising: Obtain the upgrade package; wherein, the upgrade package includes the upgrade file of the firmware to be upgraded, and also includes a version manifest file for recording the dependency relationships between the firmware to be upgraded; Based on the dependencies, an upgrade task queue is constructed; wherein, the upgrade task queue includes file information of all firmware upgrade files to be upgraded, arranged in order of priority; For each priority level in the upgrade task queue, a working unit is assigned to the upgrade file of the current priority. The working unit concurrently calls the decompression module and the burning module to decompress and burn the upgrade file. The decompression module decompresses the upgrade file and writes the currently decompressed data block into a first buffer. The burning module reads the previously decompressed data block from a second buffer and writes it into the Flash memory. The first buffer and the second buffer are of the same size and form a circular buffer. When either buffer is full and the other buffer is completely read, a buffer role swap operation is performed. After processing all priorities in the upgrade task queue, the device to be upgraded is restarted to make the new firmware take effect.

[0010] Secondly, this application provides a firmware upgrade device, which is applied to a device to be upgraded, and the device includes: The first module is used to obtain an upgrade package; wherein, the upgrade package includes an upgrade file for the firmware to be upgraded, and also includes a version manifest file for recording the dependencies between the firmware to be upgraded; The second module is used to construct an upgrade task queue based on the dependencies; wherein the upgrade task queue includes file information of all firmware upgrade files to be upgraded, arranged in order of priority. The third module is used to allocate a working unit to the upgrade file of the current priority for each priority in the upgrade task queue. The working unit calls the decompression module and the burning module in parallel to decompress and burn the upgrade file. The decompression module is used to decompress the upgrade file and write the currently decompressed data block into the first buffer. The burning module is used to read the previously decompressed data block from the second buffer and write it into the Flash memory. The first buffer and the second buffer are of the same size and form a circular buffer. When either buffer is full and the other buffer is completely read, a buffer role swap operation is performed. The fourth module is used to restart the device to be upgraded after processing all priorities in the upgrade task queue to make the new firmware take effect.

[0011] Thirdly, this application provides an electronic device, comprising: A memory, one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, and when the computer instructions are executed by the processor, the electronic device performs the method described above.

[0012] Fourthly, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described above.

[0013] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described above.

[0014] The technical solution provided in this application has the following beneficial effects: This application introduces a dynamic double buffering mechanism, which enables the decompression module and the burning module to work in parallel through a circular buffer. This reduces the memory usage of the upgrade process from the entire firmware size to the size of a few data blocks. At the same time, the parallel decompression and burning eliminates the idle time of mutual waiting, which greatly improves the overall data processing efficiency and CPU utilization, thereby achieving the goal of reducing memory usage and improving upgrade efficiency.

[0015] This application constructs an upgrade task queue based on the dependencies in the version manifest file, arranging the files according to priority. On the one hand, it strictly ensures the correct upgrade order, avoiding upgrade failure or firmware abnormalities due to incorrect order. On the other hand, it provides a clear scheduling framework for subsequent task scheduling, laying the foundation for fully utilizing device resources to process data in parallel, and improving system stability and success rate in complex firmware upgrade scenarios.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] Figure 1 A flowchart illustrating a firmware upgrade method provided in an embodiment of this application; Figure 2 A schematic diagram of the frame of a firmware upgrade device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the embodiments of this application is only used to describe specific embodiments of this application and is not intended to limit this application.

[0020] The practical application of this application will be described in detail below through specific embodiments.

[0021] Example 1 This embodiment provides a firmware upgrade method, applied to a device to be upgraded. For example... Figure 1 As shown, the method may include the following steps: Step 110: Obtain the upgrade package, which includes the upgrade file of the firmware to be upgraded, and also includes a version manifest file used to record the dependencies between the firmware to be upgraded; Step 120: Based on the dependencies recorded in the version manifest file, construct an upgrade task queue, which includes file information of all firmware upgrade files to be upgraded in order of priority. Step 130: For each priority in the upgrade task queue, assign a working unit to the upgrade file of the current priority, and have the working unit call the decompression module and the burning module in parallel to decompress and burn the upgrade file; The decompression module is used to decompress the upgrade file and write the currently decompressed data block into the first buffer; the burning module is used to read the previously decompressed data block from the second buffer and write it into the Flash memory; the first buffer and the second buffer are the same size and form a circular buffer; when either buffer is full and the other buffer is completely read, the buffer role swapping operation is performed.

[0022] For example, when the first buffer is full and the second buffer is completely read, a buffer role swap operation is performed to switch the writing target of the decompression module to the second buffer and the reading source of the burning module to the first buffer; correspondingly, when the second buffer is full and the first buffer is completely read, a buffer role swap operation is performed to switch the writing target of the decompression module back to the first buffer and the reading source of the burning module back to the second buffer.

[0023] Step 140: After processing all priorities in the upgrade task queue, restart the device to be upgraded to make the new firmware take effect.

[0024] Specifically, in step 110, the device to be upgraded can obtain the upgrade package from the firmware upgrade server via the network or read the upgrade package from local storage. The upgrade package contains any number of firmware upgrade files and a version manifest file that records the dependencies between these firmware files.

[0025] It is worth noting that in practice, the upgrade package may only contain the upgrade files for the firmware that has undergone file changes (i.e., the firmware to be upgraded), or it may contain upgrade files for both the firmware that has undergone file changes and the firmware that has not undergone file changes.

[0026] When the upgrade package contains upgrade files for firmware that has not undergone file changes, the device to be upgraded can perform the following operations: for each firmware recorded in the version manifest file, by comparing the upgrade files of the firmware in the upgrade package with the old version files of the firmware stored locally, determine whether the firmware has undergone file changes, and thus conclude whether the firmware is the firmware to be upgraded.

[0027] Therefore, this application provides two methods for generating upgrade task queues: Method 1: When the upgrade package contains upgrade files for firmware that has not undergone file changes, the firmware to be upgraded can be identified using the method described above. Upgrade files for the unchanged firmware can be filtered out, and only the upgrade files for the firmware to be upgraded can be retained. The file information of these upgrade files is then sorted by priority to obtain an upgrade task queue. Subsequent steps only process the upgrade files for the firmware to be upgraded, skipping the unchanged firmware and thus reducing the amount of file processing.

[0028] Method 2: Identify all firmware upgrade files recorded in the version manifest file, and directly arrange these upgrade files in order of priority to obtain the upgrade task queue. This method avoids the file comparison process and simplifies the task queue generation process.

[0029] As mentioned above, the upgrade task queue includes file information for the upgrade files, which may specifically include file identifiers.

[0030] Optionally, while the decompression module and the burning module are called in parallel to decompress and burn the upgrade file, the sizes of the first buffer and the second buffer are adjusted in the same direction according to the write speed of the Flash memory. Adjustment in the same direction means that when the write speed increases, the size of the buffer is increased, and correspondingly, when the write speed decreases, the size of the buffer is decreased.

[0031] Optionally, the programming module reads the previously decompressed data block from the second buffer and writes it to the Flash memory in the following way: writes the starting physical address of the second buffer and the target physical address of the Flash memory into the transfer descriptor of the DMA controller; initiates DMA transfer, and the DMA controller moves the previously decompressed data block in the second buffer to the Flash memory.

[0032] In other words, once a piece of data is ready in the buffer, the programming module does not call the memory copy function, but instead uses DMA to achieve zero-copy programming, thereby eliminating the overhead of CPU involvement in data transfer and improving data transfer efficiency.

[0033] Furthermore, after the transfer is completed, the DMA controller generates an interrupt signal, which can be used to update the buffer role and trigger the next buffer role swap operation.

[0034] Optionally, work units are assigned to upgrade files of the current priority in the following manner: if the upgrade file of the current priority includes a large file whose size exceeds a preset threshold, the large file is split into data blocks of fixed size, and a work unit is assigned to each data block; if the upgrade file of the current priority includes two or more small files whose size is below the preset threshold, a work unit is assigned to each of the small files. These work units run in parallel in subsequent workflows.

[0035] In other words, this application divides upgrade files of the same priority into two methods, vertical and horizontal, and allocates working units to different data blocks or small files, and calls these working units in parallel to perform subsequent processing, thereby significantly improving upgrade efficiency.

[0036] Furthermore, the aforementioned working units include CPU cores, as well as GPUs and / or DSPs. In other words, this application supports heterogeneous acceleration.

[0037] Furthermore, load balancing is considered when allocating work units. This application does not limit the specific load balancing strategy adopted.

[0038] When generating the upgrade task queue, the upgrade mode of each firmware to be upgraded can be further considered. This application divides the upgrade mode into full upgrade and incremental upgrade according to the layered architecture (base layer and extension layer) to which the firmware belongs. For firmware with a full upgrade mode, the upgrade file in the upgrade package is a complete new version image, while for firmware with an incremental upgrade mode, the upgrade file in the upgrade package is a differential patch file. This application not only records the file identifier of the upgrade file of each firmware to be upgraded in the upgrade task queue, but also records the upgrade mode of the upgrade file.

[0039] Accordingly, for each priority level in the upgrade task queue, when assigning a work unit to an upgrade file of the current priority, it is necessary to assign a work unit responsible for the corresponding pipeline based on the upgrade mode (incremental upgrade, full upgrade). For example, for an upgrade file with a full upgrade mode, it can be processed as described above, assigning a work unit responsible for the full decompression pipeline, which will then call the decompression module and the burning module in parallel to decompress and burn the upgrade file. For an upgrade file with an incremental upgrade mode, a second work unit responsible for the incremental decompression and reconstruction pipeline is assigned.

[0040] The second working unit described above can perform the following operations: call the decompression module to decompress the upgrade file (i.e., the differential patch file), and at the same time read the corresponding old version file (i.e., the old version file of the same firmware) from the local Flash memory; merge the decompressed upgrade file and the read old version file to reconstruct a complete new version file in memory; and call the burning module to write the reconstructed new version file into the Flash memory.

[0041] Optionally, after each data block is written to the Flash memory, the programming module writes a status record in a preset reserved area of ​​the Flash; wherein, the status record includes the index number and check value of the data block, and the status record is used as the basis for resuming interrupted transmission when the device to be upgraded restarts abnormally.

[0042] Specifically, when the device to be upgraded restarts abnormally, the system can perform breakpoint detection based on the status record and initiate a resume transmission, thereby improving the reliability of the entire upgrade process.

[0043] Example 2 To further illustrate the specific implementation of this application, this embodiment provides a firmware upgrade scheme, including a cloud-based preparation process and a device-side execution process. These two processes are described below.

[0044] The cloud preparation process includes the following steps P1 to P3: Step P1: Version comparison and difference generation; The device firmware adopts a layered architecture design, which can be divided into two categories: Basic firmware: Contains core system components, such as the operating system kernel and key hardware abstraction layers, and is the minimum necessary set for system operation; Extended layer firmware refers to functional modules that can be independently updated or added to on top of the base layer, such as device drivers, applications, and configuration files.

[0045] Based on this architecture, as a preferred implementation, the cloud server uses a differentiated content generation strategy to generate upgrade files (such as .bin files) for each firmware: To address changes in the extension layer, this application prioritizes an efficient incremental upgrade strategy, transmitting and processing only the differing parts to save bandwidth, storage space, and upgrade time. Specifically, the cloud server maintains complete firmware files (usually .bin files) for both the old and new versions. For each changed extension layer file, the cloud server compares and calculates the old and new versions using a binary differential algorithm (such as BSDiff) to generate a Delta Patch file, which serves as the upgrade file.

[0046] It is worth mentioning that during the differential calculation process, the algorithm actively ensures that the generated differential data is aligned with the physical block boundaries of the device's Flash memory. This block alignment optimization aims to minimize unnecessary erase operations when the device merges the differential data, reconstructs the complete new firmware version, and writes it to Flash, thereby significantly improving programming efficiency and extending the lifespan of the Flash memory.

[0047] In response to changes to the base layer, this application adopts a robust full upgrade strategy to ensure the integrity and reliability of the core system. If the base layer files are changed, the cloud server will directly use its complete new version image as the upgrade file for the firmware.

[0048] Whether it's the base layer or the extension layer, for brand-new files introduced into the system for the first time, the cloud server also retains the complete new version image and uses it as the upgrade file for that firmware.

[0049] It is understandable that the above classification of firmware according to hierarchical architecture, and the use of differential patch files as upgrade files for extended layer firmware, is merely a preferred implementation method. In practical applications, firmware categories can be disregarded, and complete image files can be used directly as upgrade files for each firmware.

[0050] Step P2: Build a structured upgrade package; Package all the upgrade files generated in the previous step (including the complete new version image file and differential patch files) together with a core version manifest file (such as manifest.xml file), organize them according to a predetermined directory structure, and compress them as a whole (such as using the LZMA algorithm) to finally generate an upgrade package (usually in a package format, such as .ipe file).

[0051] The above version manifest file is a machine-readable manifest and contains the following metadata: File list: Identifiers for all upgrade files within the upgrade package; Version information: The new version number for each upgrade file; Digital digest: The hash value of each upgrade file, used by the device to verify the integrity of the data content; Topology dependencies: These describe the topology dependencies between various firmware files to be upgraded, thereby guiding the device to determine a safe upgrade order; for example, driver B depends on kernel A, and application C depends on library D. Expected system hash value: Used to help judge whether the entire upgrade process was successful and the data was complete.

[0052] Step P3: Release the upgrade package.

[0053] The upgrade package generated in the previous step is published to the firmware upgrade server. Before publication, the cloud server digitally signs the upgrade package, attaching the signature to the package or distributing it with the package. When the device initiates an upgrade request, the firmware upgrade server transmits the upgrade package to the network device to be upgraded.

[0054] The execution process on the device side includes the following steps D1 to D7: Step D1: Receive and verify the upgrade package; After receiving the upgrade package from the network or local storage medium, the device first verifies the digital digest and digital signature of the upgrade package to ensure the integrity of the content and the reliability of the source of the upgrade package. Once the verification is successful, it can proceed to the next process.

[0055] Step D2: Parse the version manifest file and generate an upgrade task queue; The version manifest file contained in the upgrade package is parsed to obtain the hash values ​​and version information of each new upgrade file recorded therein. Based on this manifest, the corresponding old version file (i.e., the firmware file currently running on the device that is about to be upgraded and replaced, usually in binary format) is read one by one and its hash value is calculated. The calculation result is compared with the hash values ​​of the new version files recorded in the version manifest file, thereby dividing all upgrade files into the following two categories: Unchanged files: The hash values ​​of the old and new versions of the file are the same, indicating that the content has not changed; Modified file: The hash values ​​of the old and new versions of the file are inconsistent, indicating that the content has changed.

[0056] Furthermore, based on the firmware's hierarchical structure, the aforementioned "modified files" are further divided into the following two categories: Files used for incremental upgrades: The hash values ​​of the old and new version files are inconsistent, and the file belongs to the extension layer. In this case, the file is actually a differential patch file applicable to the old version file. Files used for full upgrades: The hash values ​​of the old and new version files are inconsistent, and the file belongs to the base layer. In this case, the file is actually a complete new version image file.

[0057] This step aims to filter the version list and avoid redundant downloading and processing of "unchanged files". For "unchanged files", the system will no longer record them in the upgrade task queue, and subsequent processes will not perform any further downloading, decompression, or burning operations on them, thus saving bandwidth and upgrade time.

[0058] To further improve efficiency, the classification results obtained from this comparison can be cached in the device memory or even directly recorded in the upgrade task queue, so that they can be reused directly in subsequent upgrade processes and avoid duplicate calculations.

[0059] In addition, the version manifest file also records the topological dependencies between each firmware to be upgraded. For upgrade files in the upgrade package, such as independent bin files like the Bootloader, the system analyzes their dependencies (e.g., Bootloader takes priority). Based on the topological dependencies, it determines the upgrade order of all firmware to be upgraded (i.e., files requiring incremental upgrades and files requiring full upgrades), thereby generating a linear upgrade task queue that conforms to the dependency order. This upgrade task queue guides subsequent processes to execute upgrade operations in the correct logical order, ensuring that dependent files are always listed before files that depend on them, avoiding system startup failures or functional abnormalities due to incorrect upgrade order, and ensuring the logical correctness and efficiency of the upgrade process.

[0060] Step D3: Perform task scheduling according to the upgrade task queue; This step initiates a control coordinator, which acts as the core task scheduler. Its responsibility is to process each priority level in the upgrade task queue sequentially. Following a descending priority order, the control coordinator assigns the upgrade files for each priority level to the corresponding work unit for processing.

[0061] When assigning work units, it is important to consider the upgrade mode (incremental upgrade, full upgrade) of the upgrade file and assign the corresponding work unit accordingly. For example, files requiring a full upgrade should be assigned to the work unit responsible for the full decompression pipeline; files requiring an incremental upgrade should be assigned to the work unit responsible for the incremental decompression and reconstruction pipeline.

[0062] In addition, for each priority level, tasks can be divided into blocks according to the following intelligent block-splitting strategy before scheduling: Strategy 1: If the current priority includes large files (such as system.bin files) exceeding a preset threshold, then the files are vertically divided into blocks of a fixed size (such as 4KB), and multiple working units are called in parallel to complete the tasks of each data block; Strategy 2: If the current priority includes two or more small files smaller than the preset threshold (being at the same priority indicates no dependency conflict), then multiple work units are called in parallel to complete the tasks of each small file; Understandably, if the current priority only includes a small file smaller than the preset threshold, then that file will be assigned as a whole task to a single work unit.

[0063] The system supports load balancing and dynamically adjusts task allocation to avoid overloading any particular work unit. Specifically, the control coordinator monitors the load status of all available work units in the system in real time and implements dynamic and intelligent task allocation, distributing tasks that can be executed in parallel within the current priority (such as multiple small files or multiple data blocks of a large file) to multiple idle work units (such as CPU cores) to achieve block-based parallel processing.

[0064] In addition, the system supports heterogeneous acceleration. When CPU resources are detected to be scarce, tasks can be assigned to work units with hardware acceleration capabilities (such as GPUs, DSPs, and other heterogeneous computing units) to maximize the utilization of heterogeneous computing resources and improve processing speed.

[0065] This section provides an example of a heterogeneous device architecture, including: Multi-core CPU: The main CPU core is responsible for parsing the upgrade package header and task scheduling, distributing decompression and verification tasks, while other CPU cores are responsible for performing decompression and burning operations; GPU / DSP: When CPU resources are scarce or decompression algorithms (such as LZMA, Zlib) are computationally intensive, the system automatically switches to GPU / DSP co-acceleration. FPGA integration: used to implement CRC32 calculation in the verification module, greatly improving the verification speed (e.g., 10 times faster than software).

[0066] Step D4: Full decompression pipeline; For the upgrade files scheduled here, perform the following processing operations: Dynamic double buffering mechanism: The system pre-allocates two memory buffers of equal size (e.g., 4KB) (Buffer A and Buffer B), forming a circular buffer. Under certain conditions, the two buffers switch roles. For example, when Buffer A is full and Buffer B is completely read, the write target of the decompression module is switched to Buffer B, and the read source of the programming module is switched to Buffer A; correspondingly, when Buffer B is full and Buffer A is completely read, the write target of the decompression module is switched back to Buffer A, and the read source of the programming module is switched back to Buffer B.

[0067] Parallel decompression and programming: During pipeline operation, the decompression module writes the currently decompressed data block to buffer A; simultaneously, the programming module reads the previously decompressed data block from buffer B and writes it to Flash memory. After both operations are completed, a hardware signal or software flag triggers a role reversal of the buffers, allowing processing of the next data block to continue. The decompression module then writes to buffer B, while the programming module reads the next data block from buffer A. This design allows the two originally serial, I / O-intensive tasks of decompression and programming to be executed completely in parallel, eliminating idle time spent waiting for each other.

[0068] Zero-copy programming: To completely eliminate the overhead of CPU involvement in data transfer, the system employs DMA for zero-copy programming. Whenever a piece of data is ready, the system automatically configures the DMA controller, eliminating the need for CPU intervention in the copy process. Specifically, when a piece of data is ready in the buffer, the programming module does not call the memory copy function. Instead, it directly writes the starting physical address of the buffer and the target physical address of the Flash memory into the DMA controller's transfer descriptor. Then, DMA transfer is initiated, and the DMA controller automatically completes the data transfer from the buffer to the Flash controller. After the transfer is complete, the DMA controller generates an interrupt signal, which updates the buffer state and triggers the next buffer role swap. This mechanism significantly reduces CPU load, significantly improves data transfer efficiency, and minimizes data path latency.

[0069] Dynamic buffer adjustment strategy: The system continuously monitors the actual write speed of the Flash memory and uses this as feedback parameters to dynamically adjust the size of the two buffers. When the Flash write speed is consistently lower than a preset threshold, it indicates that the programming stage has become a pipeline bottleneck. To optimize overall throughput and reduce peak memory usage pressure, the control coordinator automatically reduces the size of each buffer from the default value (e.g., 4KB) to a smaller size (e.g., 2KB). This adjustment brings dual optimizations: Firstly, reducing the single-block data capacity directly shortens the actual single programming time of the Flash, allowing the programming module to release the buffer faster and enabling the decompression module to obtain a smoother write flow; secondly, smaller buffers reduce the demand on the device's contiguous physical memory, improving system stability under memory-constrained environments. Buffer size adjustments can be made dynamically based on actual performance monitoring, achieving an optimal balance between resources and performance.

[0070] Pooling management strategy for the buffer: When starting the upgrade process, two 4KB buffers are pre-allocated for each work unit, dedicated to decompression and burning buffers. This application manages this memory pool, prohibiting dynamic allocation / release of memory during the upgrade process, and using it only within the pool, reducing memory fragmentation and allocation overhead, and improving system stability. If the memory pool encounters an anomaly, the system can automatically reclaim and reallocate it, thus ensuring that the upgrade is not interrupted.

[0071] Step D5: Incremental decompression and reconstruction pipeline; For the upgrade files scheduled here, perform the following processing operations: For files requiring incremental upgrades, the corresponding old version file is read from the local Flash memory, while the decompression module decompresses the corresponding differential patch file in the upgrade package. The decompressed differential patch file and the read old version file are merged and reconstructed directly in memory to create a complete new version file. The programming module then writes the complete new version file to the Flash memory. This step benefits from cloud-based "block alignment optimization," which allows for more efficient use of physical storage units when writing the merged data to the Flash memory, reducing the number of erase / write cycles.

[0072] This step changes the conventional data processing logic, improving "full decompression" to "differential patch decompression + real-time merging", reducing the amount of data that needs to be streamed from the source and comprehensively improving upgrade efficiency.

[0073] Step D6: Atomic commit during the burning process, and resume interrupted download after abnormal restart; This step introduces block-level atomic operations and state persistence mechanisms during the data burning process to ensure the reliability and recoverability of the upgrade process. The specific implementation is as follows: Block-level atomic commit: After each successful data block programming, the system immediately writes a corresponding status record to a preset reserved area in the Flash memory. This record contains at least the data block index number and an integrity check value (such as a CRC check value). This operation constitutes an atomic transaction, meaning that the writing of the status record and the programming of the data block are logically considered an inseparable whole. If the record writing fails, it is considered that the programming of the data block was unsuccessful, and the system can perform a rollback or retry accordingly.

[0074] This mechanism ensures the reliability of each data write and prevents firmware corruption caused by write errors.

[0075] Resume-from-Break Mechanism: If an unexpected interruption occurs during the upgrade process (such as power failure, system reset, etc.), and the device restarts and enters the upgrade process again, breakpoint detection is performed first: the system reads all status records in the preset reserved area and verifies the validity of each checksum; it locates the last successfully verified data block and identifies it as the last successfully submitted breakpoint. Based on this breakpoint information, the system automatically resumes the upgrade process to the next data block after the breakpoint. All data blocks before this breakpoint are considered to have been successfully processed and do not need to be re-decompressed or re-burned, thus avoiding repeated operations and significantly improving upgrade efficiency.

[0076] This application only requires a very small amount of Flash memory to store the index and checksum, and it can achieve the ability to resume interrupted downloads throughout the entire process.

[0077] Step D7: Overall verification and system activation.

[0078] After completing the streaming burning and atomic commit of all files, the system performs a final consistency check and state transition to ensure that the new firmware is complete, reliable, and can boot correctly. This step is implemented as follows: The upgrade process no longer involves any data writing operations. The system calculates a system-level digital digest (such as calculating the concatenated hash value of the entire firmware partition or all upgraded files) based on all the new firmware data already burned into the Flash memory. Then, it compares this calculated hash value with the expected system hash value recorded in the version manifest file.

[0079] If the comparison is consistent, it indicates that the upgrade process was successful and the data is complete. The system then updates the system boot flag, triggering a device restart to make the new firmware effective.

[0080] If the comparison is inconsistent, it indicates that the upgrade process deviated from expectations. The system will mark this upgrade process as a failure and report the error through the log.

[0081] This application innovatively introduces a dynamic double-buffering mechanism and zero-copy burning technology, establishing a highly efficient "decompression-burning" pipeline on the device side. The decompression module and the burning module work in parallel through a circular buffer, realizing streaming data processing and reducing memory usage from the entire firmware size to a few data blocks (such as two 4KB buffers). At the same time, it eliminates the overhead of CPU participation in data copying, greatly improving data transmission efficiency and CPU utilization.

[0082] This application provides reliability assurance for every step of the pipeline operation through atomic commit and breakpoint resume mechanism, ensuring that even if an unexpected interruption occurs during the upgrade process, it can be accurately recovered from the breakpoint, avoiding data corruption and repeated operations, making the entire upgrade process both efficient and reliable.

[0083] This application designs a block-based parallel decompression strategy. On the one hand, it can split large files into multiple data blocks, assigning a working unit to each data block to achieve vertical parallel processing. On the other hand, it can distribute small files of the same priority to different working units to achieve horizontal parallel processing. Simultaneously, it supports heterogeneous acceleration and load balancing, greatly improving firmware upgrade efficiency and fully utilizing device computing resources. Furthermore, memory pooling management provides pre-allocated, fragmented, and stable memory resources for all parallel computations, avoiding the latency and uncertainty caused by dynamic memory allocation and ensuring the system's real-time performance and stability in high-concurrency scenarios.

[0084] This application employs an incremental optimization mechanism. Data optimization is performed on the upgrade package source in the cloud. For extended-layer firmware supporting incremental upgrades, a differential algorithm generates difference patch files between the old and new versions, significantly reducing the upgrade package size. Correspondingly, on the device side, in coordination with the cloud, the upgrade method for extended-layer firmware is improved: the differential patch file is decompressed on the device, and a complete new version file is reconstructed based on the decompressed differential patch file and the local old version file. This fundamentally reduces the total amount of data requiring streaming decompression, significantly saving upgrade time and network bandwidth, and reducing the pressure on device computing and storage resources during the upgrade process, achieving efficiency improvements from the cloud to the device. Furthermore, on the device side, by comparing the old and new version files, unchanged files can be skipped, avoiding any subsequent processing and operations on such files, further reducing data processing volume and improving upgrade efficiency.

[0085] In summary, the incremental optimization mechanism of this application reduces the amount of data at the source, the block-based parallel decompression strategy enables the device to process this data with powerful computing capabilities, and the streaming collaborative burning achieves parallel decompression and burning with an efficient pipeline architecture. These three elements work together to achieve a comprehensive breakthrough in firmware upgrades in terms of speed, resource consumption, and reliability.

[0086] Example 3 This embodiment illustrates the implementation details of the entire firmware upgrade scheme through a specific example.

[0087] Suppose an upgrade package for a network device contains upgrade files for the following firmware, and the dependencies between the firmware (upgrade files) are as follows: Bootloader (boot.bin): No dependencies, must be started first; The Linux kernel (kernel.bin) depends on boot.bin for loading; 3. Device tree and basic drivers (dtb_drivers.bin): Depends on kernel.bin; Root file system (rootfs.bin): depends on kernel.bin and basic drivers; Upper-layer application (app.bin): depends on rootfs.bin.

[0088] By parsing the version manifest file, the dependencies between the various firmware files to be upgraded are determined. Then, the file identifiers of all upgrade files are arranged in order of priority to obtain the upgrade task queue, as shown below: boot.bin ->kernel.bin ->(dtb_drivers.bin, rootfs.bin) ->app.bin Among them, dtb_drivers.bin and rootfs.bin have the same priority and can be processed in parallel.

[0089] Based on the aforementioned upgrade task queue, task scheduling is executed to complete the following four stages: Phase 1, serial processing A working unit (e.g., CPU core 1) is allocated to the first-priority boot.bin file. This working unit calls the decompression module and the burning module in parallel to decompress and burn boot.bin. During this stage, other working units can be in standby mode or used to perform other auxiliary operations.

[0090] The second stage involves parallel processing of data blocks within the file. Upon completion of the boot.bin burning process, the second-priority kernel.bin is immediately processed. Since kernel.bin is a large file, it is split into multiple data blocks (e.g., Block A, Block B, Block C...), and a working unit is assigned to each data block. For example, Block A is assigned to the recently idle CPU core 1, Block B to CPU core 2, and so on. All working units decompress the different data blocks of kernel.bin in parallel and burn them.

[0091] The third stage involves hybrid parallelism between file-level and data block-level operations. Once kernel.bin is successfully burned, the third-priority dtb_drivers.bin and rootfs.bin are immediately processed.

[0092] Since dtb_drivers.bin is a small file, it is assigned a unit of work, such as CPU core 3.

[0093] Since rootfs.bin is a large file, it is split into data blocks. Suppose it is split into three data blocks (e.g., R1, R2, R3), each of which is assigned a single working unit, for example, to CPU core 1, CPU core 2, and CPU core 4 respectively.

[0094] At this time, the four CPU cores can simultaneously decompress and burn different files or different data blocks of the same file, which can maximize the use of multi-core resources.

[0095] Fourth stage, serial processing Once dtb_drivers.bin and rootfs.bin have finished burning, app.bin (the fourth priority file) is processed immediately. A work unit is assigned to it, which calls the decompression module and the burning module in parallel to decompress and burn app.bin.

[0096] Assuming that only rootfs.bin and app.bin change in this upgrade, and rootfs.bin undergoes an incremental upgrade while app.bin undergoes a full upgrade, then: First, during the generation of the upgrade task queue, boot.bin, kernel.bin, and dtb_drivers.bin will be marked as "unchanged" and will not be recorded in the upgrade task queue, thus skipping subsequent processing.

[0097] Second, during the task scheduling phase, when processing rootfs.bin, after assigning a work unit to it, the work unit no longer calls the decompression module to execute the standard decompression algorithm, but instead starts the incremental decompression and reconstruction process: decompressing rootfs.bin, reading the old version file corresponding to rootfs.bin stored locally, reconstructing the decompressed file and the read file in memory to generate a complete new version file, and then calling the burning module to burn it.

[0098] As can be seen, by establishing an upgrade task queue based on the above-mentioned dependency relationship, and combining two-level parallel scheduling at the file level and the data block level within the file, this application can fully tap the potential of multi-core and heterogeneous computing resources while strictly ensuring the correctness of the upgrade process logic, and effectively meet the strict requirements of streaming decompression and burning for data processing speed.

[0099] Example 4 Based on the same inventive concept, this embodiment provides a firmware upgrade device applied to a device to be upgraded, as shown in the schematic diagram below. Figure 2 As shown, it specifically includes: The first module 210 is used to obtain an upgrade package; wherein, the upgrade package includes an upgrade file of the firmware to be upgraded, and also includes a version list file for recording the dependency relationships between the firmware to be upgraded; The second module 220 is used to construct an upgrade task queue according to the dependency relationship; wherein, the upgrade task queue includes file information of all firmware upgrade files to be upgraded in order of priority; The third module 230 is used to allocate a working unit to the upgrade file of the current priority for each priority in the upgrade task queue. The working unit calls the decompression module and the burning module in parallel to decompress and burn the upgrade file. The decompression module is used to decompress the upgrade file and write the currently decompressed data block into the first buffer. The burning module is used to read the previously decompressed data block from the second buffer and write it into the Flash memory. The first buffer and the second buffer are of the same size and form a circular buffer. When either buffer is full and the other buffer is completely read, a buffer role swap operation is performed. The fourth module 240 is used to restart the device to be upgraded so that the new firmware takes effect after processing all priorities of the upgrade task queue.

[0100] Optionally, the device further includes: The adjustment module is used to adjust the size of the first buffer and the second buffer in the same direction according to the write speed of the Flash memory while the decompression module and the burning module are called in parallel to decompress and burn the upgrade file.

[0101] Optionally, the programming module reads the previously decompressed data block from the second buffer and writes it to the Flash memory in the following manner: Write the starting physical address of the second buffer and the target physical address of the Flash memory into the transfer descriptor of the DMA controller; initiate DMA transfer, and the DMA controller moves the previously decompressed data block in the second buffer to the Flash memory.

[0102] Optionally, the third module assigns work units to upgrade files of the current priority in the following ways: If the upgrade files of the current priority include large files whose file size is greater than a preset threshold, then the large files are split into data blocks of fixed size, and a working unit is assigned to each data block. If the upgrade files of the current priority include two or more small files whose file size is less than a preset threshold, then a working unit is assigned to each of the small files.

[0103] Optionally, the device may also include: The recording module is used to write a status record to a preset retention area after each data block is written to the Flash memory by the burning module; wherein, the status record includes the index number and check value of the data block, and the status record is used as the basis for resuming interrupted transmission when the device restarts abnormally.

[0104] Optionally, the file information includes an upgrade mode, which includes a full upgrade and an incremental upgrade. The device further includes: The incremental upgrade module is used to assign a second working unit responsible for the incremental decompression and reconstruction pipeline to each priority in the upgrade task queue. If the upgrade file of the current priority includes an upgrade file with the upgrade mode of incremental upgrade, the second working unit is assigned to the upgrade file with the upgrade mode of incremental upgrade. The second working unit completes the decompression, reconstruction and burning operation. The decompression, reconstruction, and burning operation includes: calling the decompression module to decompress the upgrade file and reading the corresponding old version file from the Flash memory; reconstructing the decompressed upgrade file and the read old version file to obtain a complete new version file; and calling the burning module to write the complete new version file into the Flash memory.

[0105] This application provides an electronic device that may include a memory and one or more processors. The memory stores computer program code, including computer instructions. When the processor executes the computer instructions, the electronic device can perform various functions or steps of the above-described method embodiments.

[0106] The structure of this electronic device can be referenced. Figure 3The structure of the electronic device 100 shown.

[0107] For example, the processor mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0108] This application also provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the various functions or steps of the above method embodiments.

[0109] The aforementioned computer-readable storage media include, but are not limited to, any of the following: USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and other media capable of storing program code.

[0110] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps of the above method embodiments.

[0111] The electronic devices, computer-readable storage media, and computer program products provided in this application embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0112] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various variations or substitutions can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A firmware upgrade method, characterized in that, The method is applied to the device to be upgraded, and the method includes: Obtain the upgrade package; wherein, the upgrade package includes the upgrade file of the firmware to be upgraded, and also includes a version manifest file for recording the dependency relationships between the firmware to be upgraded; Based on the dependencies, an upgrade task queue is constructed; wherein, the upgrade task queue includes file information of all firmware upgrade files to be upgraded, arranged in order of priority; For each priority level in the upgrade task queue, a working unit is assigned to the upgrade file of the current priority. The working unit concurrently calls the decompression module and the burning module to decompress and burn the upgrade file. The decompression module decompresses the upgrade file and writes the currently decompressed data block into a first buffer. The burning module reads the previously decompressed data block from a second buffer and writes it into the Flash memory. The first buffer and the second buffer are of the same size and form a circular buffer. When either buffer is full and the other buffer is completely read, a buffer role swap operation is performed. After processing all priorities in the upgrade task queue, the device to be upgraded is restarted to make the new firmware take effect.

2. The method according to claim 1, characterized in that, The method further includes: While the decompression module and the burning module are called in parallel to decompress and burn the upgrade file, the size of the first buffer and the second buffer are adjusted in the same direction according to the writing speed of the Flash memory.

3. The method according to claim 1, characterized in that, The programming module specifically reads the previously decompressed data block from the second buffer and writes it into the Flash memory in the following manner: Write the starting physical address of the second buffer and the target physical address of the Flash memory into the transfer descriptor of the DMA controller; initiate DMA transfer, and the DMA controller moves the previously decompressed data block in the second buffer to the Flash memory.

4. The method according to claim 1, characterized in that, The method specifically assigns work units to upgrade files of the current priority in the following way: If the upgrade files of the current priority include large files whose file size is greater than a preset threshold, then the large files are split into data blocks of fixed size, and a working unit is assigned to each data block. If the upgrade files of the current priority include two or more small files whose file size is less than a preset threshold, then a working unit is assigned to each of the small files.

5. The method according to claim 1, characterized in that, The method further includes: After each data block is written to the Flash memory, the programming module writes a status record to a preset reserved area; wherein, the status record includes the index number and check value of the data block, and the status record is used as the basis for resuming interrupted transmission in case of abnormal device restart.

6. The method according to claim 1, characterized in that, The file information includes upgrade modes, which include full upgrades and incremental upgrades. The method further includes: For each priority in the upgrade task queue, if the upgrade file of the current priority includes an upgrade file with the upgrade mode of incremental upgrade, then the upgrade file with the upgrade mode of incremental upgrade is assigned a second working unit responsible for the incremental decompression and reconstruction pipeline, and the second working unit completes the decompression, reconstruction and burning operation. The decompression, reconstruction, and burning operation includes: calling the decompression module to decompress the upgrade file and reading the corresponding old version file from the Flash memory; reconstructing the decompressed upgrade file and the read old version file to obtain a complete new version file; and calling the burning module to write the complete new version file into the Flash memory.

7. A firmware upgrade device, characterized in that, The device is applied to the equipment to be upgraded, and the device includes: The first module is used to obtain an upgrade package; wherein, the upgrade package includes an upgrade file for the firmware to be upgraded, and also includes a version manifest file for recording the dependencies between the firmware to be upgraded; The second module is used to construct an upgrade task queue based on the dependencies; wherein the upgrade task queue includes file information of all firmware upgrade files to be upgraded, arranged in order of priority. The third module is used to allocate a working unit to the upgrade file of the current priority for each priority in the upgrade task queue. The working unit calls the decompression module and the burning module in parallel to decompress and burn the upgrade file. The decompression module is used to decompress the upgrade file and write the currently decompressed data block into the first buffer. The burning module is used to read the previously decompressed data block from the second buffer and write it into the Flash memory. The first buffer and the second buffer are of the same size and form a circular buffer. When either buffer is full and the other buffer is completely read, a buffer role swap operation is performed. The fourth module is used to restart the device to be upgraded after processing all priorities in the upgrade task queue to make the new firmware take effect.

8. An electronic device, characterized in that, include: A memory, one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, and when the computer instructions are executed by the processor, the electronic device performs the method as described in any one of claims 1-6.

9. A computer-readable storage medium comprising computer instructions, characterized in that, When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-6.

Images