A firmware over-the-air upgrade method based on neural processing unit semantic deconstruction

Abstract

The application provides a firmware over-the-air upgrading method based on semantic deconstruction of a neural processing unit, comprising: a cloud device cutting a to-be-upgraded firmware image into multiple firmware blocks, converting each firmware block into a latent vector by using an encoder model of an autoencoder, and generating an OTA latent vector package; after a target device receives the package, loading a decoder model into a neural processing unit, decoding and reconstructing a latent vector sequence, and obtaining a reconstructed firmware block; using a double buffering or ring buffering combined with a direct memory access streaming write mechanism to write the reconstructed firmware block into a target storage area, and controlling firmware activation according to a block-level check, an image-level check and a reconstruction consistency check result. The application changes a firmware upgrading package from a traditional binary compression package into a latent vector package, uses an NPU to perform firmware deconstruction, reduces a transmission volume and a CPU load, reduces an intermediate storage space occupation, and improves upgrading reliability.

Description

Technical Field

[0001] This invention relates to the field of OTA (Over-The-Air) technology for embedded systems, and in particular to a firmware over-the-air upgrade method based on semantic deconstruction of neural processing units. Background Technology

[0002] With the rapid development of embedded systems, edge computing, and IoT technologies, Over-The-Air (OTA) firmware upgrades have become a key means for various smart devices (such as industrial edge gateways, in-vehicle smart cockpits, smartphones, and wearable devices) to achieve functional iteration, vulnerability patching, and performance optimization. In a typical OTA upgrade process, the cloud server packages the firmware image to be upgraded into an upgrade package, transmits it to the target device over the network, and after downloading it, the target device's central processing unit (CPU) performs decompression, differential merging, and verification operations. Finally, the new firmware is written to a non-volatile storage medium (such as eMMC, UFS, NAND Flash, or SPI Flash), and the new firmware is activated by the bootloader after a reboot.

[0003] Currently, mainstream OTA upgrade solutions typically employ mechanisms such as A / B partitioning, full image processing, differential packets, traditional compression algorithms (e.g., LZMA, Zstd, gzip), breakpoint resumption, signature verification, and bootloader rollback. Among these, compression and differential techniques can reduce the transmission size of the upgrade package to some extent, while A / B partitioning and rollback mechanisms improve the reliability of the upgrade. However, existing solutions still have the following technical problems in practical applications:

[0004] First, the data representation format of upgrade packages is simplistic. Existing OTA upgrade packages still primarily use binary images, differential blocks, or traditional compressed blocks as their carriers. The content of the upgrade package is essentially still the raw binary data to be written to the storage medium or its compressed representation. This data representation format fails to fully utilize the increasingly prevalent heterogeneous computing resources (such as neural processing units) in current edge computing devices to perform semantic-level compression and reconstruction of data.

[0005] Second, the utilization rate of heterogeneous computing power on the edge is insufficient. Taking a device equipped with the Rockchip RK3588 chip as an example, this chip has a built-in Neural Processing Unit (NPU) with a computing power of up to 6 TOPS, which can efficiently execute neural network inference tasks. However, in the current OTA upgrade process, computationally intensive tasks such as decompression, differential merging, and verification are still entirely handled by the CPU, while the NPU is idle and does not participate in the firmware reconstruction process, resulting in a waste of heterogeneous computing power on the edge.

[0006] Third, the intermediate storage space is relatively large. In the traditional OTA process, the device often needs to download the complete compressed package or the intermediate image after differential merging before writing it to the target partition. This "download / decompress first, then write" mode requires the device to reserve a large amount of temporary storage space (usually 1.5 to 2 times the size of the firmware image). For edge devices with limited storage resources, this may lead to upgrade failure or additional storage costs.

[0007] Fourth, the integrity verification mechanism is relatively simple. Existing solutions primarily use integrity verification to determine whether transmission packets are damaged or tampered with, with little focus on designing activation conditions around neural network reconstruction results, block-level reconstruction consistency, and image-level reconstruction consistency. Even if the NPU participates in certain data processing tasks, there is a lack of corresponding verification and control mechanisms to ensure that its output meets the semantic consistency requirements of firmware reconstruction.

[0008] Fifth, in weak network or high-latency communication environments (such as satellite communication and long-distance wireless transmission), traditional OTA upgrade packages (especially full image packages) are still relatively large in size, have long transmission times, and low success rates. Although differential packet and compression technologies can alleviate this problem to some extent, their compression ratio is limited by the entropy value of binary data, making it difficult to achieve orders-of-magnitude reductions.

[0009] Therefore, there is a need for an OTA technology that can transform firmware upgrade packages from traditional binary compressed packages into potential vector packages and enable the target device to use neural processing units to reconstruct firmware blocks from the potential vector stream. This would reduce transmission volume, reduce CPU load, shorten intermediate image dwell time, and form a technology solution that is different from traditional firmware compression / differential OTA. Summary of the Invention

[0010] The purpose of this invention is to address the problems of large upgrade package size, high CPU decompression load, large intermediate image storage occupation, and lack of NPU computing power participation in the upgrade link in traditional firmware OTA upgrades. This application provides a firmware over-the-air upgrade method based on neural processing unit semantic deconstruction.

[0011] Technical solution: An over-the-air firmware upgrade method based on semantic deconstruction of neural processing units.

[0012] Firstly, a firmware over-the-air upgrade method based on semantic deconstruction of neural processing units is provided, including:

[0013] The cloud device divides the firmware image to be upgraded into multiple firmware blocks, inputs each firmware block into the encoder model of the autoencoder, obtains the potential vector corresponding to each firmware block, and generates an OTA potential vector package containing the potential vector, model version information, block index table and verification information.

[0014] The target device receives the OTA potential vector packet, loads the decoder model into the neural processing unit according to the model version information, and submits the potential vector sequence to the neural processing unit for decoding and reconstruction to obtain the reconstructed firmware block;

[0015] The target device uses a streaming write mechanism to write the reconstructed firmware block to the target storage area and controls firmware activation based on the reconstructed consistency verification result.

[0016] According to the first aspect, in one possible implementation, the cloud device divides the firmware image to be upgraded into multiple firmware blocks, including: dividing the firmware image to be upgraded into multiple firmware blocks according to at least one of Flash pages, ELF segments, file system blocks, driver modules or functional modules, and assigning a corresponding block number and target write address to each firmware block.

[0017] According to the first aspect, or any implementation of the first aspect above, the generation of the OTA potential vector packet further includes: calculating a block-level check value for each firmware block, calculating an image-level check value for the complete firmware image to be upgraded, and encapsulating the block-level check value and the image-level check value into the OTA potential vector packet.

[0018] According to the first aspect, or any implementation of the first aspect above, the target device submits the latent vector sequence to the neural processing unit for decoding and reconstruction, including: the target device loading a decoder model that matches the runtime of the neural processing unit based on the model version information and quantization parameters carried in the OTA latent vector package; the target device submits the latent vector sequence corresponding to each firmware block as an input tensor to the neural processing unit to execute the inference of the decoder model according to the block index table order, and outputs the reconstructed firmware block.

[0019] According to the first aspect, or any implementation of the first aspect above, the streaming write mechanism includes: the target device adopts a double buffer to receive the reconstructed firmware block output by the neural processing unit, wherein the first buffer receives the first reconstructed firmware block currently decoded and output, and the second buffer is used by the direct memory access controller to write the previous reconstructed firmware block into the target storage area, forming a decoding and writing pipeline.

[0020] According to the first aspect, or any implementation of the first aspect above, the reconstruction consistency verification result is obtained through the following steps: calculating a block-level hash or cyclic redundancy check on the reconstructed firmware block and comparing it with the block-level check value carried in the OTA potential vector packet to obtain a block-level verification result; after all firmware blocks are written, calculating an image-level hash or signature on the firmware image in the target storage area and comparing it with the image-level check value carried in the OTA potential vector packet to obtain an image-level verification result; when both the block-level verification result and the image-level verification result are passed, the reconstruction consistency verification is determined to be passed.

[0021] According to the first aspect, or any implementation of the first aspect above, controlling firmware activation based on the reconstruction consistency verification result includes: when the reconstruction consistency verification passes, the target device writes a new firmware activation flag to the bootloader or upgrade management partition; when the reconstruction consistency verification fails, the target device prohibits writing the activation flag and retains the old firmware boot path.

[0022] According to the first aspect, or any implementation of the first aspect above, the method further includes: after the target device restarts, the bootloader boots the new firmware according to the activation flag; if the new firmware does not report a startup success flag within a preset time, the bootloader clears the activation flag and rolls back to the old firmware; if the new firmware reports a startup success flag, the new firmware is marked as a stable version.

[0023] According to the first aspect, or any implementation of the first aspect above, the method further includes a degradation process: when the neural processing unit is unavailable, the decoder model fails to load, or the model version is mismatched, the target device stops the upgrade and reports to the cloud, or requests the cloud to send a traditional compressed upgrade package, or calls the central processing unit to execute a downgraded decoder model for low-speed reconstruction.

[0024] According to the first aspect, or any implementation of the first aspect above, the streaming write mechanism further includes: the target device uses a ring buffer to receive the reconstructed firmware block output by the neural processing unit, wherein the write pointer points to the buffer currently being written by the direct memory access controller, the decode pointer points to the buffer currently receiving the decoded output of the neural processing unit, and when the buffer pointed to by the decode pointer is full, the write pointer and the decode pointer are swapped.

[0025] The technical solution provided in this application changes the data representation of firmware OTA packages by transforming them from traditional binary compressed packages or differential packages into potential vector packages that can be deconstructed by an NPU decoder. It also shifts the firmware deconstruction task from traditional CPU-side decompression to the NPU of the edge SoC, improving the utilization of heterogeneous computing power on the edge. Furthermore, it reduces the occupancy of complete intermediate images and improves write efficiency through a pipelined mechanism of NPU decoding, double buffering / ring buffering, and DMA writing. Finally, it improves the reliability of OTA upgrades by controlling firmware activation through block-level, image-level, and reconstructed consistency checks. This solution can be used in combination with existing A / B partitioning, secure signature, and rollback mechanisms.

[0026] In a second aspect, a firmware over-the-air upgrade system based on neural processing unit semantic deconstruction is provided, the system comprising a module for performing the method described in the first aspect and any of its implementations.

[0027] Thirdly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the method described in the first aspect and any of its implementations.

[0028] Fourthly, a computer program product is provided that, when the computer program product is run on an electronic device, causes the electronic device to perform the method described in the first aspect and any of its implementations.

[0029] The technical effects of the aforementioned aspects can be referenced from each other, and will not be elaborated further here.

[0030] Beneficial effects: This application reduces the transmission size of the upgrade package and the decompression load on the central processing unit by transforming the firmware upgrade package from a traditional binary compressed package to a potential vector package and utilizing the target device's neural processing unit for streaming decoding and reconstruction. Simultaneously, this application employs a streaming write mechanism combining double buffering and direct memory access, reducing intermediate storage space usage and improving the reliability of over-the-air firmware upgrades through multi-level reconstruction consistency checks. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the overall solution process of the present invention.

[0032] Figure 2 This is a schematic diagram of the process of generating OTA potential vector packets in the cloud according to the present invention.

[0033] Figure 3 This is a schematic diagram of the NPU streaming decoding and DMA streaming writing process on the target device side of the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, “at least one” and “one or more” refer to one or more (including two).

[0035] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0036] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0037] This application provides a firmware over-the-air (OTA) upgrade method based on neural processing unit (NPU) semantic deconstruction. This method transforms the firmware upgrade package from a traditional binary compressed package into a potential vector package, and enables the target device to utilize the NPU to reconstruct firmware blocks from the potential vector stream. This reduces transmission volume, decreases the load on the central processing unit (CPU), and shortens intermediate image dwell time. This method can be applied to edge computing devices, embedded systems, and heterogeneous system-on-chip (SoC) devices. For example, it can be applied to development boards equipped with RK3588 chips, industrial edge gateways, and smart cockpit domain controllers—devices requiring OTA firmware upgrades.

[0038] Figure 1 This is a flowchart illustrating the firmware over-the-air upgrade method based on neural processing unit semantic deconstruction provided in an embodiment of this application. It should be noted that this method does not rely on... Figure 1 The specific order described below is a limitation. It should be understood that in other embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0039] Step S101: The cloud device obtains the firmware image to be upgraded and divides the firmware image to be upgraded into multiple firmware blocks.

[0040] Step S102: The cloud device inputs each firmware block into the encoder model of the autoencoder to obtain the latent vector corresponding to each firmware block and generates an OTA latent vector package.

[0041] Step S103: The target device receives the OTA potential vector packet and loads the decoder model into the NPU according to the model version information.

[0042] Step S104: The target device submits the potential vector sequence to the NPU for decoding and reconstruction to obtain the reconstructed firmware block.

[0043] Step S105: The target device uses a streaming write mechanism to write the reconstructed firmware block to the target storage area and controls firmware activation based on the reconstructed consistency verification result.

[0044] In some embodiments, the specific implementation of the cloud device dividing the firmware image to be upgraded into multiple firmware blocks in step S101 above includes: logically dividing the firmware image to be upgraded into multiple appropriately sized firmware blocks according to at least one of the following partitioning methods: Flash page size, ELF segment boundary, file system block size, driver module (such as .ko file), or functional module. For example, for the Linux root file system (RootFS), it can be divided according to the SquashFS or EXT4 file system block size; for the kernel image or bootloader, it can be divided according to ELF segment, page alignment, or fixed-length blocks. The cloud device assigns a corresponding block number and target write address (i.e., the starting offset of the firmware block in the target storage medium) to each firmware block.

[0045] In some embodiments, step S102 above, the process of the cloud device generating the OTA potential vector packet further includes: calculating a block-level checksum (e.g., block-level hash or cyclic redundancy check CRC) for each firmware block, calculating an image-level checksum (e.g., overall hash, signature, or password-based message authentication code CMAC) for the complete firmware image to be upgraded, and encapsulating these checksums into the OTA potential vector packet. Optionally, the OTA potential vector packet also carries model version information, quantization parameters (e.g., INT8, INT16, or FP16), a block index table, a target address, and metadata such as activation conditions and failure policies. This OTA potential vector packet differs from traditional binary compressed packets or differential packets; its core data is the potential vector representation of the firmware block.

[0046] In some embodiments, to adapt to the target device's NPU (e.g., the 6TOPS NPU built into the RK3588 chip), the cloud device can export the decoder model to a model format supported by the target NPU runtime, such as the RKNN format, when training the autoencoder. Optionally, the cloud device verifies the reconstruction consistency of the decoder model with the firmware block during the training or export phase. Only firmware blocks that meet preset hash matching, error threshold, or semantic consistency requirements are allowed to be included in the OTA potential vector package.

[0047] In some embodiments, in step S103 above, after the target device receives the OTA potential vector packet, it first performs packet integrity verification. Specifically, this includes: signature verification, version number comparison, target device model and hardware platform compatibility checks, and decoder model version matching checks on the OTA potential vector packet. If the verification passes, the target device extracts the corresponding decoder model file from local storage or the packet body based on the model version information and quantization parameters carried in the packet, and loads the model into the NPU's runtime memory through the NPU driver, completing the memory allocation of the input / output tensors and putting the NPU in a ready state.

[0048] In some embodiments, the specific implementation of the target device submitting the latent vector sequence to the NPU for decoding and reconstruction in step S104 includes: the target device submits the latent vector sequence corresponding to each firmware block as an input tensor to the NPU to perform inference calculations of the decoder model, according to the order of the block index table. The NPU hardware accelerates the execution of operations such as deconvolution and fully connected layers to reconstruct the low-dimensional latent representation back to the original data space and outputs the reconstructed firmware block. The size of the reconstructed firmware block is the same as the size of the original firmware block corresponding to step S101.

[0049] Optionally, the target device can submit multiple potential vector blocks to the NPU at once in batches or using a sliding window approach to improve decoding throughput. After each reconstructed firmware block is output, the target device can calculate the block-level hash or CRC of the block in real time and compare it with the block-level checksum carried in the OTA potential vector packet. If the comparison results match, the block-level checksum is considered to have passed; if they do not match, the upgrade process is interrupted and reported to the cloud or error handling is triggered.

[0050] In some embodiments, the streaming write mechanism in step S105 specifically includes: the target device using a double buffer to receive the reconstructed firmware block output by the NPU. The first buffer receives the first reconstructed firmware block currently decoded by the NPU, while the second buffer is used by the direct memory access (DMA) controller to write the previous reconstructed firmware block to the target storage area (e.g., eMMC, UFS, NAND Flash, or SPI Flash). When the first buffer is full, the roles of the two buffers are swapped, forming a decoding and writing pipeline. In this way, the target device does not need to fully restore the entire firmware image in local memory before writing it as a whole; instead, it decodes and writes simultaneously, significantly reducing intermediate storage space usage.

[0051] Alternatively, the streaming write mechanism can also be implemented using a ring buffer. In a ring buffer implementation, the write pointer points to the buffer currently being written to by the DMA controller, and the decode pointer points to the buffer currently receiving NPU decoded output. When the buffer pointed to by the decode pointer is full, the write and decode pointers are swapped. Ring buffers can further reduce buffer management overhead and are suitable for scenarios where the decoding rate matches the write rate.

[0052] In some embodiments, the reconstruction consistency verification result is obtained through the following steps: First, a block-level hash or CRC is calculated for each reconstructed firmware block and compared with the block-level checksum carried in the OTA potential vector packet to obtain the block-level verification result. Second, after all firmware blocks have been written, an image-level hash or signature is calculated for the complete firmware image in the target storage area and compared with the image-level checksum carried in the OTA potential vector packet to obtain the image-level verification result. When both the block-level verification result and the image-level verification result are passed, the reconstruction consistency verification is determined to be successful.

[0053] Optionally, after writing to the target storage area, the target device can also read back the corresponding firmware block from the storage area and perform verification again to detect whether an error occurred during the writing process. This readback verification can serve as an additional reliability enhancement measure.

[0054] In some embodiments, the specific method for controlling firmware activation based on the reconstruction consistency verification result includes: when the reconstruction consistency verification passes, the target device writes a new firmware activation flag to the bootloader or upgrade management partition; when the reconstruction consistency verification fails, the target device prevents the writing of the activation flag and retains the old firmware boot path. In this way, only firmware that has undergone complete and correct NPU decoding, reconstruction, and verification has the opportunity to be activated, avoiding firmware boot failures due to decoding errors or transmission corruption.

[0055] In some embodiments, the method provided in this application further includes a health check and rollback mechanism after firmware activation. Specifically, after the target device restarts, the bootloader boots the new firmware based on the activation flag. If the new firmware does not report a successful boot flag to the watchdog or monitoring process within a preset time (e.g., 30 seconds or 1 minute), the bootloader clears the activation flag and triggers a rollback, rebooting to the old firmware version. If the new firmware successfully reports a successful boot flag, it is marked as a stable version. This mechanism is compatible with existing A / B partition rollback mechanisms and can be used as a supplement to the method of this invention.

[0056] In some embodiments, the method provided in this application further includes a degradation processing path. When one of the following abnormal conditions occurs: NPU hardware unavailable, decoder model loading failure, model version mismatch, NPU runtime exception, or insufficient memory, the target device can suspend the current upgrade process and report to the cloud server. Optionally, the target device can request the cloud to send a traditional compressed upgrade package (e.g., a binary package compressed with LZMA, Zstd, or gzip), and then the CPU can perform the traditional decompression and writing process. Alternatively, the target device can call the CPU to execute a downgraded decoder model (e.g., using the CPU to run a lightweight decoder) for low-speed reconstruction. The above degradation path is an alternative to improve engineering availability and does not change the innovative chain of this invention, which is based on potential vector OTA packages, edge-side NPU streaming destructuring, DMA streaming writing, and reconstruction consistency activation.

[0057] In some embodiments, the method provided in this application can also be used in combination with existing A / B partitioning systems, secure signature mechanisms, and bootloader rollback mechanisms. For example, when the target device adopts an A / B partitioning scheme, the reconstructed firmware block can be directly written to the inactive partition, and the active partition flag can be switched after verification. As another example, when a cloud device generates a potential OTA vector packet, it can digitally sign the entire packet body, and the target device can verify the signature upon receipt to ensure the packet's origin is trustworthy.

[0058] Figure 2 This is a schematic diagram illustrating the process of generating OTA potential vector packets in the cloud, as provided in an embodiment of this application. Figure 2 As shown, the cloud device first reads the firmware image to be released and divides it into firmware blocks 1 to N according to a preset partitioning method. Then, each firmware block is input into the encoder model to obtain latent vectors 1 to N. Simultaneously, the cloud device calculates a block-level checksum for each firmware block and an image-level checksum for the complete image. Finally, all latent vectors, block index tables, target addresses, model versions, quantization parameters, checksums, and other information are encapsulated into an OTA latent vector package.

[0059] Figure 3 This is a schematic diagram illustrating the process of NPU streaming decoding and DMA streaming writing on the target device side, as provided in an embodiment of this application. Figure 3 As shown, after the target device receives the OTA potential vector packet, it loads the decoder model into the NPU. The NPU decodes the potential vectors in block order and outputs a reconstructed firmware block. The reconstructed firmware block enters a double-buffering mechanism: buffer A receives the current decoded output, and buffer B is written to the storage medium by DMA. When buffer A is full, their roles are reversed, forming a pipeline. Each reconstructed firmware block can be verified at the block level before and after writing, and a mirror-level verification is performed after all blocks have been written. Finally, the activation flag is controlled based on the verification results.

[0060] The communication method provided in the embodiments of this application is described below with reference to specific examples. These examples do not constitute a limitation on the scope of protection of this application.

[0061] Example 1: Using an industrial edge gateway equipped with an RK3588 processor as the target device, running a Linux operating system and with firmware stored in eMMC. A new firmware version is released by a cloud server. The cloud server first divides the firmware image into multiple firmware blocks of 256KB each. Each firmware block is input to a pre-trained autoencoder and outputs a 64-dimensional latent vector. The cloud server encapsulates the latent vector sequence, block index table, target address, decoder model version (RKNN format, INT8 quantization), SHA256 hash value of each block, and SHA256 hash value of the complete image into an OTA latent vector package (extension .lvpkg). The edge gateway downloads this package via 4G / Wi-Fi. Upon receiving the package, the gateway verifies the signature and version, loads the decoder model into the NPU, and submits the latent vectors to the NPU sequentially. The NPU decodes the output and reconstructs the firmware block. The gateway employs a double-buffering mechanism, receiving NPU output while simultaneously writing the previous block to the corresponding partition in the eMMC via DMA. For each block decoded, the gateway calculates its SHA256 hash and compares it with the block hash within the packet. After all blocks are written, the gateway calculates the SHA256 hash of the entire partition image and compares it with the image hash within the packet. If the comparison passes, the gateway writes an activation flag to the Bootloader partition and then reboots. After rebooting, the Bootloader boots the new firmware, which reports a successful boot within 40 seconds, and the gateway marks the new firmware as a stable version.

[0062] Example 2: Building upon Example 1, suppose the NPU driver fails to load during the upgrade process (e.g., due to missing NPU firmware). Upon detecting this anomaly, the edge gateway aborts the upgrade, reports an "NPU unavailable" error to the cloud, and requests a traditional gzip compressed package. Upon receiving the request, the cloud sends the traditional firmware compressed package, which the gateway then decompresses and writes using its CPU, completing the upgrade. This downgrade path ensures the device's upgradeability.

[0063] Example 3: In another embodiment, the target device is an in-vehicle intelligent cockpit domain controller, whose firmware includes multiple functional modules (such as audio DSP firmware, Bluetooth firmware, and Wi-Fi firmware). The cloud-based system segments the firmware into functional modules and trains an independent encoder / decoder model for each module. The OTA latent vector packet carries multiple sub-packets, each corresponding to a functional module. The target device sequentially performs NPU decoding, DMA writing, and verification on each module. This approach enables selective upgrades at the module level, further reducing the amount of data transmitted.

[0064] It should be understood that the segmentation methods, block sizes, verification algorithms, model quantization accuracy, etc., described in the above embodiments are all exemplary illustrations, and those skilled in the art can select appropriate parameters and implementation methods according to actual application scenarios. The scope of protection of this application shall be determined by the scope of the claims.

[0065] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A firmware over-the-air upgrade method based on neural processing unit semantic deconstruction, characterized in that, The method includes: The cloud device divides the firmware image to be upgraded into multiple firmware blocks, inputs each firmware block into the encoder model of the autoencoder, obtains the potential vector corresponding to each firmware block, and generates an OTA potential vector package containing the potential vector, model version information, block index table and verification information. The target device receives the OTA potential vector packet, loads the decoder model into the neural processing unit according to the model version information, and submits the potential vector sequence to the neural processing unit for decoding and reconstruction to obtain the reconstructed firmware block; The target device uses a streaming write mechanism to write the reconstructed firmware block to the target storage area and controls firmware activation based on the reconstructed consistency verification result.

2. The method according to claim 1, characterized in that, The cloud device divides the firmware image to be upgraded into multiple firmware blocks, including: The firmware image to be upgraded is divided into multiple firmware blocks according to at least one of the following partitioning methods: Flash page, ELF segment, file system block, driver module, or functional module. Each firmware block is then assigned a corresponding block number and target write address.

3. The method according to claim 1, characterized in that, The generation of the OTA potential vector package also includes: Calculate a block-level checksum for each firmware block, calculate an image-level checksum for the complete firmware image to be upgraded, and encapsulate the block-level checksum and the image-level checksum into the OTA potential vector packet.

4. The method according to claim 1, characterized in that, The target device submits the potential vector sequence to the neural processing unit for decoding and reconstruction, including: The target device loads a decoder model that matches the runtime of the neural processing unit based on the model version information and quantization parameters carried in the OTA potential vector packet. The target device submits the potential vector sequence corresponding to each firmware block as an input tensor to the neural processing unit to perform inference of the decoder model according to the block index table order, and outputs the reconstructed firmware block.

5. The method according to claim 1, characterized in that, The streaming write mechanism includes: The target device employs a dual-buffered approach to receive the reconstructed firmware blocks output by the neural processing unit. The first buffer receives the first reconstructed firmware block currently decoded and output, while the second buffer is used by the direct memory access controller to write the previous reconstructed firmware block into the target storage area, forming a decoding and writing pipeline.

6. The method according to claim 1, characterized in that, The reconstruction consistency verification result is obtained through the following steps: Calculate a block-level hash or cyclic redundancy check for the reconstructed firmware block and compare it with the block-level check value carried in the OTA potential vector packet to obtain the block-level check result; After all firmware blocks have been written, calculate the image-level hash or signature of the firmware image in the target storage area, and compare it with the image-level verification value carried in the OTA potential vector packet to obtain the image-level verification result. When both the block-level verification result and the mirror-level verification result are passed, the reconstruction consistency verification is determined to be successful.

7. The method according to claim 6, characterized in that, The step of controlling firmware activation based on the reconstruction consistency verification result includes: When the reconstruction consistency check passes, the target device writes a new firmware activation flag to the bootloader or upgrade management partition; When the reconstructed consistency check fails, the target device is prohibited from writing the activation flag and the old firmware boot path is retained.

8. The method according to claim 7, characterized in that, The method further includes: After the target device restarts, the bootloader boots the new firmware according to the activation flag; If the new firmware does not report a successful startup flag within a preset time, the bootloader clears the activation flag and rolls back to the old firmware. If the new firmware reports a successful startup flag, then the new firmware will be marked as a stable version.

9. The method according to claim 1, characterized in that, The method also includes degradation processing: When the neural processing unit is unavailable, the decoder model fails to load, or the model version is mismatched, the target device stops the upgrade and reports to the cloud, or requests the cloud to send a traditional compressed upgrade package, or calls the central processing unit to execute a downgraded decoder model for low-speed reconstruction.

10. The method according to claim 1, characterized in that, The streaming write mechanism also includes: The target device uses a ring buffer to receive the reconstructed firmware block output by the neural processing unit. The write pointer points to the buffer currently being written by the direct memory access controller, and the decode pointer points to the buffer currently receiving the decoded output of the neural processing unit. When the buffer pointed to by the decode pointer is full, the write pointer and the decode pointer are swapped.

Images