Firmware security upgrading method and device for chip and medium

Abstract

The invention provides a firmware security upgrading method and equipment of a chip and a medium, and relates to the technical field of firmware security upgrading of the chip, the method comprises the following steps: dividing an upgrading mirror image packet into a plurality of data segments which are continuous in sequence, and sending each data segment to firmware in sequence according to the sequence of the data segments; when each data segment is received, writing the received data segment into a temporary storage partition of the flash memory, and calling a Hash algorithm to update the accumulated Hash value of the current data segment until all the data segments are received, so as to obtain a final Hash value of the upgrading mirror image package; verifying the validity of the digital signature; copying the complete upgrading mirror image package in the temporary storage partition to a target partition; the written upgrade mirror image package is read back from the target partition, and the hash value of the read-back upgrade mirror image package is recalculated; if the read-back Hash value of the upgrading mirror image package is the same as the final Hash value, it is confirmed that upgrading succeeds; according to the method, the security and success rate of chip firmware upgrading can be remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of firmware security upgrade technology for chips, and in particular to a method, device and medium for firmware security upgrade of chips. Background Technology

[0002] Security is crucial for ensuring reliable device operation during firmware upgrades. Existing firmware upgrade solutions typically employ direct flashing or overwrite methods, writing the new firmware to a storage partition and verifying its signature via a secure boot mechanism upon the device's next reboot. However, this approach has significant drawbacks: if the firmware written during the upgrade process has been tampered with or corrupted, the device only discovers the problem after a reboot, by which time the corrupted firmware may have already caused the system to fail to boot, malfunction, or even become permanently unusable. This is especially true in multi-core chip architectures, where firmware often contains image files for multiple cores, making the upgrade process more complex, and traditional solutions struggle to effectively identify malicious firmware before writing. Furthermore, current firmware upgrade verification operations are mostly performed at the software level, making keys and signatures vulnerable to theft or tampering, and lacking real-time mechanisms to ensure the integrity of upgrade data. This fails to meet the end-to-end protection requirements of trusted firmware sources, complete transmission, and reliable writing in high-security scenarios. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows: According to a first aspect of this application, a firmware security upgrade method for a chip is provided, comprising the following steps: S100, in response to receiving the parameter information of the upgrade image package sent by the host, determines whether to allow the upgrade based on the parameter information of the upgrade image package; S200, if the upgrade is allowed, the host is notified to divide the upgrade image package into several consecutive data segments according to the memory size of the chip, and to send each data segment to the firmware in sequence according to the order of the data segments. S300, upon receiving a data segment, writes the received data segment to the temporary storage partition of the flash memory and calls the hash algorithm to update the cumulative hash value of the current data segment until all data segments have been received, and obtains the final hash value of the upgrade image package; S400: Obtain the digital signature and public key from the host, and call the hardware security module to verify the legitimacy of the public key; the legitimacy verification includes verifying the integrity and trustworthiness of the public key; S500: If the public key verification passes, the final hash value, digital signature, and public key are sent to the hardware security module. The hardware security module uses the public key to decrypt the digital signature and compares the decryption result with the final hash value to verify the validity of the digital signature. If the digital signature verification is successful, the complete upgrade image package in the temporary partition will be copied to the target partition. After copying, the S700 reads back the written upgrade image package from the target partition and recalculates the hash value of the read-back upgrade image package. If the hash value of the upgrade image package read back is the same as the final hash value, the upgrade is confirmed to be successful.

[0004] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described firmware security upgrade method for FPGA chips.

[0005] According to another aspect of this application, an electronic device is also provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0006] The present invention has at least the following beneficial effects: The firmware security upgrade method for the chip of this invention implements a "signature verification before writing" upgrade protection mechanism by performing signature verification before writing firmware to flash memory. This effectively prevents damaged or tampered firmware from entering the storage partition, fundamentally eliminating the risk of device bricking due to upgrading faulty firmware. The method of segmented reception and hash value calculation while receiving data not only adapts to the limited memory resources of the FPGA chip but also enables real-time monitoring of integrity during data transmission, ensuring that each data segment is not tampered with or lost. A hardware security module is introduced for public key verification and signature verification, placing key management and cryptographic operations in a hardware isolation ring. In this context, the risk of software-level key exposure is avoided, significantly improving the reliability and anti-attack capability of the verification process; fourth, through the design of the temporary storage partition, the physical isolation between the upgrade data and the running firmware is achieved, so that even if the signature verification fails, it will not affect the normal operation of the current system, ensuring the business continuity of the device; fifth, after the image copy is completed, a readback verification step is added to perform secondary confirmation on the data written to the flash memory, effectively avoiding data inconsistency problems caused by bad blocks in the flash memory or write anomalies, forming a closed-loop protection of the entire link from transmission, signature verification to storage, significantly improving the security and success rate of FPGA chip firmware upgrades. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 A flowchart illustrating a firmware security upgrade method for a chip provided in an embodiment of the present invention. Detailed Implementation

[0009] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0010] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0011] The following will refer to Figure 1 The flowchart shown illustrates a firmware security upgrade method for a chip, introducing a firmware security upgrade method for one type of chip.

[0012] The firmware security upgrade method for this chip may include the following steps: S100, in response to receiving the parameter information of the upgrade image package sent by the host, determines whether to allow the upgrade based on the parameter information of the upgrade image package.

[0013] The method in this embodiment can be applied to ASIC chips or FPGA chips. The firmware receives upgrade requests from the host through a communication interface supported by the chip (such as PCIe, Ethernet, or UART). The parameters carried in the request include: target partition identifier (such as "boot", "app", etc.), total size of the upgrade image package, image version number, image type identifier (such as FPGA bitstream, HPS firmware, etc.), and upgrade trigger source. The firmware first accesses the flash memory partition table to check if the target partition exists and if the type matches; then it reads the remaining space of the partition and compares it with the image package size; next, it reads the current firmware version from the partition header and compares it with the version number in the request (if downgrading or repeated upgrades are prohibited, a higher version number is required); at the same time, it queries the system status (such as whether other cores are busy or performing critical tasks). If all checks pass, the firmware records the context information of this upgrade (such as target partition, size, version) and returns "upgrade allowed" confirmation; otherwise, it returns the corresponding error code and terminates the process.

[0014] This step incorporates multiple checks before the upgrade begins, preventing upgrade failures or system anomalies caused by invalid partitions, insufficient space, version errors, or system conflicts. It ensures that the upgrade operation is performed only under safe and appropriate conditions, improving the robustness and success rate of the upgrade process.

[0015] Furthermore, step S100 includes the following steps: S110, obtain parameter information of the upgrade image package sent by the host; the parameter information includes at least: target partition identifier, total size of the upgrade image package, image version number, image type identifier, and trigger source of the upgrade operation.

[0016] The firmware listens for upgrade requests from the host via a physical communication interface supported by the chip (such as PCIe Endpoint, Gigabit Ethernet, or UART). When the host-side tool initiates an upgrade command, it first encapsulates the parameter information of the upgrade image package into a predefined data packet (such as TLV format or a fixed structure) and sends it to the firmware via a communication protocol. After receiving the data packet, the upgrade management module in the firmware parses out the following key fields: Target partition identifier: a string or enumeration value, such as "boot", "app", "core0_fw", etc., used to specify which partition of flash memory the image will be written to.

[0017] Total size of the upgrade image package: an integer value in bytes, used for subsequent space checks and segmented transfers.

[0018] Mirror version number: For example, "v2.1.0", which can be a semantic version number or an incrementing number for version comparison.

[0019] Image type identifier: Distinguish the purpose of the image, such as FPGA bitstream (.rbf), HPS bare metal firmware, Linux kernel image, etc. Different types may correspond to different partition type requirements.

[0020] Upgrade trigger source: Optional, such as "user manual", "scheduled task", "remote management", etc., for subsequent auditing or policy judgment.

[0021] The firmware stores these parameters in a temporary memory structure and starts a timeout timer to prevent subsequent steps from getting stuck.

[0022] By clearly defining parameter information, the firmware can accurately obtain the complete context of the upgrade operation, laying a data foundation for subsequent checks and avoiding misjudgments caused by incomplete information; at the same time, the standardization of parameter parsing provides interface compatibility for unified access of different host tools.

[0023] S120: Access the flash memory's partition table based on the target partition identifier, check if the target partition exists and if the partition type matches the image type identifier. If the partition does not exist or the type does not match, terminate the upgrade process.

[0024] The firmware maintains a flash memory partition table, typically stored in a fixed area of ​​the flash memory (such as the start block) or in the chip's OTP memory. The partition table records the name / identifier, starting physical address, size, type (e.g., "bootable," "data storage," "temporary storage"), and current status of each partition. The firmware iterates through the partition table to find a match based on the target partition identifier parsed by the S110. If no match is found, an error log is logged (e.g., "partition does not exist"), and a failure status code is returned to the host via the communication interface. Simultaneously, resources are released, and the upgrade is terminated. If a partition is found, the firmware further checks whether the partition type field is compatible with the image type identifier: for example, "image type identifier = FPGA bitstream" requires the partition type to be "FPGA configuration partition"; "image type identifier = HPS firmware" requires the partition type to be "executable firmware partition." If a mismatch occurs, an error is also returned, and the upgrade terminates.

[0025] This step verifies the existence and type compatibility of partitions in advance, preventing the image from being written to the wrong partition (such as writing the FPGA bitstream to the HPS firmware partition), thus avoiding the system failing to boot due to partition content corruption. This check eliminates upgrade errors from the source and ensures the logical consistency of the storage layout.

[0026] S130: If the partition exists and the type matches, and the remaining space of the target partition is less than the total size of the upgrade image package, then terminate the upgrade process; otherwise, proceed to S140.

[0027] The firmware retrieves the total capacity and used size of the target partition from the partition table (calculated from file system metadata or partition header data) and calculates the remaining available space. For example, if an "app" partition is 8MB in total size and the currently stored firmware occupies 4MB, then 4MB is remaining. This remaining space is compared to the total size of the upgrade image package (let's say 6MB). If the remaining space is less than the required size, the firmware returns an "insufficient space" error and suggests the user clean up the partition or select another partition; if there is sufficient space, the process continues. Note that some partitions may require reserved space for boot information or backups; the firmware may deduct this reserved space based on a policy before comparison.

[0028] This step ensures that the target partition has enough physical space to accommodate the new image, preventing data truncation or partition overflow due to space exhaustion during the writing process, thus protecting the integrity of other data on the flash memory; this check also avoids the hassle of manual recovery after an upgrade failure due to insufficient space.

[0029] S140: If the image version number of the upgrade image package is not higher than the current firmware version number and the upgrade policy prohibits downgrading or repeated upgrades, then the upgrade process is terminated; otherwise, proceed to S150.

[0030] The firmware reads the current firmware version number from the header or metadata area of ​​the target partition. The version number comparison rules need to be predefined: typically, an integer incrementing algorithm (e.g., major version + minor version + revision number) or a semantic version comparison algorithm is used. If the current version number is v2.0.0 and the new image version number is v1.9.0, then the new version is lower than the current version. The firmware checks the preset upgrade strategy (usually stored in the configuration partition or determined by compilation options): If the policy is "prohibit downgrades", the process will terminate when the version number is lower than the current version.

[0031] If the policy is "prohibit repeated upgrades", the upgrade will also terminate when the version number is equal to the current version.

[0032] If the policy allows downgrading or forced overwrite, it can continue even if the version is not higher than the current one.

[0033] Meanwhile, the firmware can record the history of upgrade attempts to prevent repeated attempts within a short period of time. If the upgrade attempt fails, it will return an "Invalid Version" or "Downgrade Prohibited" error code.

[0034] Version checking and policy control prevent functional rollback due to accidental flashing of older firmware versions or wasted flash memory life due to repeated upgrades; for security update scenarios, forced version increments ensure that the device always runs the latest patched firmware, enhancing system security.

[0035] S150: If the system status does not allow the upgrade, terminate the upgrade process; otherwise, return an upgrade permission confirmation message to the host.

[0036] The firmware assesses whether the current system's operating status is suitable for performing the upgrade operation, and checks include, but are not limited to: Other core activities: If it is a multi-core SoC, check whether other CPU cores besides the current management core are performing critical tasks (such as real-time control, data plane processing). The status can be queried through inter-core communication. If any core is executing an uninterruptible task, it will return "System Busy".

[0037] Upgrade mutex: Check if other upgrade processes are running (possibly triggered by another core or remote management), and if so, wait or return a conflict.

[0038] Power / Temperature Status: The chip temperature and power supply status are read by sensors. If the temperature is too high or the voltage is unstable, the upgrade is postponed to prevent write failure.

[0039] Business continuity requirement: If the device is in peak business period and the policy prohibits interruption, the upgrade can be refused.

[0040] If all checks pass, the firmware saves the upgrade context (target partition, size, version, etc.) to memory and sends an "upgrade allowed" confirmation message to the host, while preparing to enter the S200 data transmission phase. If any condition is not met, the corresponding error code is returned and the process terminates.

[0041] System status checks ensure that upgrade operations do not interfere with critical business operations, avoiding service interruptions or data loss due to upgrades; at the same time, they prevent flash memory writing in harsh environments (such as high temperatures), reducing the risk of write failures or chip damage, and improving the reliability of upgrades and the availability of equipment.

[0042] S200, if the upgrade is allowed, the host is notified to divide the upgrade image package into several consecutive data segments according to the memory size of the FPGA chip, and to send each data segment to the firmware in sequence according to the order of the data segments. In this embodiment, it can be understood that the FPGA memory is usually small, while the upgrade image package is large. When verifying the upgrade image package, it is necessary to put the upgrade image package into memory. In order to avoid memory overflow, the entire upgrade image package is divided into multiple data segments.

[0043] Furthermore, dividing the upgrade image package into several sequentially consecutive data segments based on the memory size of the FPGA chip includes the following steps: S210, obtain the current available memory buffer capacity value QR inside the FPGA chip.

[0044] The firmware obtains the currently available memory buffer capacity using one of the following methods: Method 1: Reads the preset memory size information in the chip's hardware registers, such as the available memory size configured in the HPS's DDR controller, or the remaining capacity of the on-chip RAM (such as the M20K block). Method 2: Queries the remaining space of the current dynamic memory pool through the memory management unit, subtracts the reserved memory allocated to other tasks (such as the network protocol stack, log buffer), and obtains the net buffer size available for upgrade transmission. Method 3: In a multi-core system, the firmware sends a query request to other cores to summarize the currently available shared memory size for each core. The obtained capacity value QR is in bytes, for example, 128KB. The firmware stores this value in a local variable and updates it periodically during the upgrade process (e.g., re-querying after each data segment is received) to cope with dynamic changes.

[0045] This step accurately obtains the real-time available memory capacity, providing a precise basis for subsequent segmentation, avoiding buffer overflows or resource waste due to inaccurate memory estimation, and ensuring that the upgrade process adapts to the current operating state of the chip.

[0046] S220, if the total size of the upgrade image package QE≤QR, then the entire upgrade image package will be transmitted as a single data segment.

[0047] The firmware compares QR with the total size QE of the received upgrade image package (from S110). If QE ≤ QR, it indicates that the available memory is sufficient to hold the entire image package at once. The firmware sends a "single-segment transmission" command to the host, which encapsulates the entire image package into a single data segment, adds a segment header (containing segment number 1, total length, checksum start identifier, etc.), and then sends it all at once. When receiving the image, the firmware directly uses a single buffer to receive it completely, without segmentation processing.

[0048] In small image upgrade scenarios, the transmission process is simplified, inter-segment interaction overhead is reduced, upgrade efficiency is improved, and the complexity introduced by unnecessary segmentation processing logic is avoided.

[0049] S230, if QE > QR, then determine the number of data segments required based on QR: NUM = ceil(QE / QR); ceil() is the preset rounding function.

[0050] The firmware calculates the required number of data segments. For example, if QE = 500KB and QR = 128KB, then NUM = ceil(500 / 128) = 4, meaning 4 data segments are needed. Rounding up ensures that even if the last segment is less than the QR size, it will still be fully included. The firmware records the NUM value in the upgrade context structure and uses it as a control parameter for subsequent processes. Simultaneously, the firmware can send the NUM value to the host for preparation of segmented transmission.

[0051] The number of segments is precisely determined through mathematical calculations, ensuring that the length of each segment does not exceed the memory capacity. This fully utilizes available memory and avoids reception failures due to excessively large single segments, providing an executable path for large image upgrades.

[0052] S240, divide the upgrade image package into NUM data segments in sequence; the length of each data segment does not exceed QR, the length of the first NUM-1 data segments is QR, and the length of the NUM-th data segment is QE-(NUM-1)×QR.

[0053] The firmware (or host) performs the segmentation based on the above calculation results. Taking QE=500KB, QR=128KB, and NUM=4 as an example: the first three data segments are each 128KB in length, and the fourth data segment is 500 - 3 × 128 = 500 - 384 = 116KB in length. Before sending each data segment, the host encapsulates segment header information, including the segment sequence number (1~NUM), the segment length, the total number of segments NUM, and the image packet identifier. The firmware pre-allocates a receive buffer of the corresponding size based on the segment header and prepares for reception. The segmentation logic ensures that the data is continuous at the byte level; that is, the first segment contains bytes 0~131071, the second segment contains bytes 131072~262143, and so on, ensuring seamless reassembly after reception.

[0054] In this step, the strict continuous partitioning ensures the order and integrity of data during segmented transmission. The receiving end can write data sequentially to the temporary partition without complex reorganization logic, providing a continuous data stream foundation for subsequent hash calculations and signature verification.

[0055] Furthermore, after step S240, the method further includes the following steps: S250 reports the size of the currently available memory buffer to the host, enabling the host to dynamically determine the length of each data segment based on the size of the currently available memory buffer.

[0056] Before receiving a new data segment (especially before the first segment), the firmware sends the currently queried QR value to the host via the communication interface. Upon receiving the QR, the host uses it as the upper limit of the current segment length and dynamically calculates the actual length to be sent: if the remaining data to be sent is greater than the QR, the segment sends the QR bytes; if it is less than or equal to the QR, the segment sends all remaining data. For example, if the firmware reports a current QR of 120KB, the host will send a data segment ≤120KB. After receiving a segment, the firmware can report a new QR value (which may increase due to memory release by other tasks or decrease due to system load), and the host will adjust the length of the next segment accordingly.

[0057] The dynamic reporting mechanism enables the segment length to adapt to changes in FPGA chip memory resources in real time. For example, when other tasks release memory, subsequent segments can be larger to speed up transmission. When memory is preempted, the segment length can be automatically reduced to avoid buffer overflow and improve the upgrade process's adaptability to dynamic environments.

[0058] The S260 adjusts the length of subsequent data segments in real time based on firmware feedback during transmission to adapt to changes in the chip's memory resources.

[0059] In addition to the S250's reporting mechanism, the firmware continuously monitors the remaining buffer space during the reception of each data segment. If the remaining space is detected to be below a threshold (e.g., 10%), the firmware sends a "pause" or "decelerate" instruction to the host via an in-band signal (such as a special control message) or an out-of-band signal (such as a hardware interrupt). Upon receiving this instruction, the host immediately pauses transmission, waits for the firmware to process the current data and release part of the buffer, and then resumes transmission. During resumption, the firmware can report a new QR value, which the host uses to adjust the length of subsequent segments. Furthermore, if the firmware needs to temporarily reduce the buffer size due to memory pressure, it can also proactively send a new QR value, which the host will then use in subsequent segments.

[0060] The real-time feedback adjustment mechanism enables the upgrade transmission to be adaptive, and can cope with complex situations such as chip memory resources being preempted by other high-priority tasks and memory performance fluctuations caused by temperature changes, ensuring that the transmission process is stable and uninterrupted, and greatly improving the reliability and success rate of upgrades in real operating environments.

[0061] S300 writes each received data segment to a temporary storage partition in the flash memory and calls a hash algorithm to update the cumulative hash value of the current data segment until all data segments have been received, thus obtaining the final hash value of the upgrade image package.

[0062] Furthermore, step S300 includes the following steps: S310, obtain the first preset value N=1 and the intermediate variable X.

[0063] Before receiving data segments, the firmware initializes two variables: a segment counter N and a hash intermediate variable X. N is set to 1, indicating that the first data segment is about to be processed. X is used to store the intermediate state of the hash algorithm and is initialized to empty.

[0064] In practice, the firmware calls the hash initialization function of the hardware security module to set the internal hash register to a standard initial value (such as the initial hash value of SHA-256). At the software level, X can be a handle to the hardware hash context or a memory area storing intermediate hash values. The firmware also needs to obtain the total number of data segments M (i.e., NUM calculated in S230) as the basis for determining the end of the loop.

[0065] By performing explicit initialization operations, a correct starting state is established for segmented hash calculations, ensuring the continuity of subsequent incremental updates and avoiding hash calculation errors caused by uninitialized states.

[0066] S320, the Nth data segment QW N Write to the temporary partition of flash memory and call the hash algorithm based on X and QW. N Calculate QW N The corresponding cumulative hash value HA N; HA N Write to X; enter S330; M is the number of data segments.

[0067] The firmware receives the Nth data segment (denoted as QW) from the host. N First, the data segment is written to the temporary storage partition of the flash memory. The write operation must ensure that the addresses are contiguous and written sequentially in segment order for subsequent reassembly.

[0068] After the write operation is complete, the firmware calls a hash algorithm for incremental updates: it combines the current intermediate state X (i.e., the cumulative hash value of the first N-1 segments) with the newly received data segment QW. N Together, they are sent to the hash update interface of the hardware security module. The hardware security module uses an internal hash engine based on X and QW. N Calculate the new cumulative hash state HA N And return it to the firmware.

[0069] Firmware will HA N Save back to X, overwriting the old value, and use it as the input state for the next segment. It should be noted that HA... N This is not the final hash value, but rather the intermediate hash value up to the current segment. For example, for the first segment (N=1), X is the initial vector, and H1 = hash(QW1) is calculated; for the second segment, X = H1, and H2 = hash(H1||QW2) is calculated, and so on.

[0070] This step parallelizes persistent data storage with hash updates, ensuring secure data write-to-disk while maintaining real-time data integrity summaries. Hardware-accelerated hash updates reduce CPU load, and continuous transmission of intermediate states ensures the final hash value is completely consistent with the overall image.

[0071] S330, determine HA N Is this correct? If HA N If correct, proceed to S340; otherwise, stop firmware upgrade.

[0072] The firmware completes the hash update of the Nth data segment and obtains the cumulative hash value HA. N Next, it is necessary to verify whether the data segment is complete and has not been tampered with during transmission and storage. To this end, when the host sends each data segment, in addition to the data segment body, it also includes the expected cumulative hash value corresponding to that segment (this value is pre-calculated and stored in the image package metadata during image package generation, for example, by adding a field "Expected Cumulative Hash" to the segment header). The firmware parses this expected value from the segment header and denotes it as EXP_HA. N Then the firmware will use the HA calculated by the hardware security module. N With EXP_HA NPerform a byte-by-byte comparison. If the two are completely identical, it means that all data in the current data segment from the beginning to the end of the segment is consistent with the original data when the image packet was generated, and no bit flipping, packet loss, or malicious tampering has occurred. Then, HA is determined. N Correct, proceed to S340. If inconsistent, it indicates that this data segment is corrupted. The firmware will immediately stop the upgrade process, clear the data already written to the temporary partition, return a "data segment verification failed" error code to the host, and record the failure log for subsequent analysis.

[0073] By comparing the expected cumulative hash value in real time after each segment is received, integrity verification at the data segment level is achieved. This enables the detection of transmission errors or malicious tampering in the first instance, preventing errors from accumulating until the final stage and thus saving time and flash memory lifespan. At the same time, this segment-by-segment verification mechanism enhances the fault tolerance of the upgrade process to network fluctuations and storage errors, ensuring that only completely correct data is used for subsequent signature verification.

[0074] S340, if N < M, then obtain N = N + 1 and proceed to S320; otherwise, obtain the final hash value of the upgrade image package.

[0075] The firmware compares the current segment counter N with the total number of segments M. If N < M, it means there are still subsequent data segments to be processed. The firmware increments N by 1 and returns to S320 to wait for the next data segment. If N = M, it means all data segments have been processed. At this time, the HA stored in X... N This is the final hash value of the entire upgrade image package. The firmware obtains this final hash value from the hardware security module (which may require calling the `finalize` operation) and stores it in memory for use by subsequent steps (S500). At the same time, the firmware can release relevant resources and prepare to enter the signature verification stage.

[0076] A loop control mechanism ensures that all segments are processed sequentially, ultimately yielding an accurate and complete mirror hash value. This process automatically adapts to varying numbers of segments without manual intervention, providing reliable input for subsequent signature verification. The final hash value is retrieved promptly after the loop ends, preventing accidental loss of intermediate states.

[0077] S400: Obtain the digital signature and public key from the host, and call the hardware security module to verify the legitimacy of the public key; the legitimacy verification includes verifying the integrity and trustworthiness of the public key; After all data segments have been transmitted (or even before), the host sends the digital signature and public key to the firmware. The firmware then passes the public key data to the hardware security module, triggering a verification request. The hardware security module reads the pre-configured root public key (or root public key hash) from the chip's internal one-time programmable memory (such as eFuse). It then verifies the public key using one of the following methods: if the public key is accompanied by a digital certificate, it verifies the certificate signature using the root public key, extracts the public key, and compares it; if there is no certificate, it calculates the received public key hash and compares it with the root public key hash; or it directly uses the root public key to decrypt the public key's own signature information. If the verification is successful, the hardware security module stores the public key in its internal secure register for later use and returns a "valid" status; otherwise, it returns an error and may record the number of failures.

[0078] The system utilizes a hardware-isolated environment to verify the legitimacy of public keys, preventing attackers from bypassing signature verification by forging public keys. The root key is stored immutably in hardware, ensuring the absolute security of the root of trust and thus guaranteeing the reliability of subsequent signature verifications.

[0079] S500: If the public key verification passes, the final hash value, digital signature, and public key are sent to the hardware security module. The hardware security module uses the public key to decrypt the digital signature and compares the decryption result with the final hash value to verify the validity of the digital signature. The firmware sends the final hash value calculated in step S300, the digital signature received in step S400, and the verified public key to the hardware security module. The hardware security module uses the public key to perform an asymmetric decryption operation (such as RSA decryption) on the digital signature to obtain the decrypted hash value. This value is then compared byte-by-byte with the input final hash value. If they match completely, the signature verification passes, and the hardware security module returns a success flag; otherwise, it returns a failure flag. The entire process is completed internally in the hardware; the firmware only receives the result.

[0080] Hardware-accelerated signature verification is fast and secure, with the private key never exposed in the software environment. Only officially signed images can pass verification, effectively preventing malicious firmware injection. The verification process is executed in a hardware-isolated area, and the software cannot interfere with the result, ensuring that the verification cannot be bypassed.

[0081] Furthermore, after step S500 and before step S600, the method further includes the following steps: The S510 reads the written complete upgrade image package from the scratch partition.

[0082] After the signature verification in step S500 is successful, before copying the image package from the temporary partition to the target partition, the firmware first reads the entire upgrade image package data completely, starting from the beginning address of the temporary partition. The read operation is performed in the same order and length as the write operation, ensuring that the read data covers the entire content from the first byte to the last byte. During the read process, the firmware can enable the flash memory's ECC verification function. If an ECC error is detected, the error information is recorded and the process is prepared to terminate. The read data can be temporarily stored in a memory buffer or directly sent to the hardware security module for streaming processing to reduce memory usage.

[0083] By rereading the temporary data before replication, a data source is provided for subsequent secondary hash verification, ensuring that the data to be written to the target partition has been reconfirmed. This avoids the risks introduced by unexpected changes in the temporary data during the period between signature verification and replication (such as background task miswriting, data corruption caused by power fluctuations, etc.).

[0084] S520, recalculate the hash value of the complete upgrade image package.

[0085] The firmware reads the complete upgrade image package data from S510 and again calls the hash acceleration unit of the hardware security module to perform a complete hash calculation (rather than an incremental update). The hardware security module performs hash calculations on the input data from scratch and outputs a new hash value, denoted as H_verify. This calculation process is completely consistent with the calculation method of obtaining the final hash value H_final in step S300 (using the same hash algorithm, such as SHA-256). If the data volume is large, the firmware can use a streaming method to send the data in blocks to the hardware security module. The module automatically maintains the hash state internally and finally outputs the final result.

[0086] By performing independent secondary hash calculations, the integrity of the data in the temporary partition is independently verified, eliminating the sole reliance on the previously calculated final hash value. This provides a cross-validation mechanism that further enhances the credibility of data integrity.

[0087] S530: If the hash value of the complete upgrade image package is the same as the final hash value, the copying operation continues; otherwise, the temporary data is deemed corrupted and the upgrade process is terminated.

[0088] The firmware compares the H_verify calculated in step S520 with the final hash value H_final saved in step S300 byte by byte. If they are completely consistent, it indicates that the data in the temporary partition is completely consistent with the data used for signature verification and no changes have occurred, and the firmware continues to perform the copy operation in step S600. If they are inconsistent, it indicates that the data in the temporary partition is corrupted (possibly due to flash memory soft errors, read errors, or other accidental writes), and the firmware immediately terminates the upgrade process, clears the data in the temporary partition, and returns a "temporary data corrupted" error code to the host, while retaining the original firmware of the target partition unchanged.

[0089] This step adds a crucial "data consistency verification" safeguard after signature verification and before actual writing to the target partition. It effectively prevents erroneous writing caused by data corruption in the temporary storage area during the window between signature verification and copying. It ensures that only complete data that has undergone double verification will be finally deployed to the running partition, greatly improving the reliability and security of firmware upgrades.

[0090] If the digital signature verification is successful, the S600 will copy the complete upgrade image package from the temporary partition to the target partition.

[0091] After receiving the signature verification success notification, the firmware reads the entire image package data block by block, starting from the beginning address of the staging partition, and writes it to the pre-specified target partition (e.g., the "app" partition of the flash memory). Before copying, the hash value of the staging partition can be recalculated and compared with the final hash value to ensure that the staging data has not been accidentally modified. The writing process may involve operations such as erasing the target partition and page-by-page programming. If the target partition is a multi-core firmware package, each sub-image also needs to be written to its corresponding sub-partition. After copying is complete, the staging partition can be cleaned up or marked as reusable.

[0092] The image package is only written to the final partition after it has been signed and verified, preventing malicious or corrupted firmware from being flashed into the runtime area. The temporary storage area is isolated from the target area, so the original firmware can still boot even if power is lost during the copying process, ensuring the robustness of the system.

[0093] Furthermore, the upgrade image package contains multiple sub-images corresponding to different CPU cores, and the target partition contains multiple sub-partitions corresponding to each CPU core; the copying to the target partition in step S600 includes: writing each sub-image to its corresponding sub-partition.

[0094] After the digital signature verification in step S500 is successful, the firmware begins the image deployment operation. Since the upgrade image package contains multiple sub-images (e.g., Core0 firmware, Core1 firmware, Core2 firmware, Core3 firmware), and the target partition is pre-divided into multiple independent sub-partitions in the flash memory (e.g., "core0_partition", "core1_partition", "core2_partition", "core3_partition"), the firmware needs to complete fine-grained writing according to the following steps: Parsing the Image Package Structure: The firmware first accesses the complete upgrade image package stored in the staging partition and parses its predefined package format. The image package header records the metadata of each sub-image, including: the CPU core identifier (such as Core ID) to which the sub-image belongs, the starting offset address of the sub-image within the package, the length of the sub-image, the independent signature information of the sub-image, and the checksum, etc. The firmware traverses this metadata and constructs a sub-image write task list. In addition to firmware images, the firmware package can also contain non-firmware images, which can also be written to their corresponding target partitions through secure upgrades. Verifying the Existence and Capacity of Sub-Partitions: For each sub-image, the firmware looks up the corresponding sub-partition in the flash partition table based on its core identifier. It checks whether the sub-partition exists, whether the type matches (e.g., Core0 firmware should write to the "executable code partition"), and whether the remaining capacity of the sub-partition is greater than or equal to the size of the sub-image. If any sub-partition does not meet the conditions, the firmware terminates the entire upgrade process, returns an error code, and clears the staging area.

[0095] Sub-images are written sequentially: The firmware processes sub-images one by one according to the order recorded in the image header (usually consistent with the boot order). For each sub-image: Read sub-image data from the specified offset address of the temporary partition; If the sub-image is compressed or encrypted in the package, decompression or decryption is required (hardware security module assistance is needed). Write the sub-image data to the starting address of the corresponding target sub-partition. The writing method can be page-by-page programming or block writing to ensure that the data is completely written to disk. After writing is complete, you can optionally read back and verify immediately (or verify uniformly in step S700).

[0096] Update partition metadata: After all sub-images have been written, the firmware updates the header information of each sub-partition, such as the version number of the new firmware, the write timestamp, and the verification flag, for reading during the next secure boot.

[0097] Cleanup and Confirmation: After the firmware confirms that all sub-partitions have been written successfully, it can clear the used data in the temporary partition (or mark it as reusable) and write the completion status to the upgrade context record in memory.

[0098] For example, an upgrade image package for a quad-core SoC FPGA contains four sub-images: core0.bin (512KB), core1.bin (256KB), core2.bin (256KB), and core3.bin (128KB). After firmware parsing, these images are written to four consecutive sub-partitions in flash memory: core0 partition (offset 0x00000~0x7FFFF), core1 partition (0x80000~0xBFFFF), core2 partition (0xC0000~0xFFFFF), and core3 partition (0x100000~0x11FFFF). During the writing process, if the core2 partition has insufficient space (e.g., only 200KB), the firmware immediately reports an error and terminates the process.

[0099] By writing multi-core firmware to independent sub-partitions, physical isolation and independent management of each core's firmware are achieved, preventing firmware errors from one core from overwriting the code space of another. At the same time, this partition structure facilitates subsequent secure booting—each core can directly load firmware from its own dedicated partition without dynamically extracting it from the composite package, thus speeding up the boot process. Furthermore, independent writing allows for fine-grained upgrades to individual cores in the future (such as upgrading only the Core1 firmware) without affecting the operation of other cores, improving the flexibility and efficiency of upgrades.

[0100] After copying, the S700 reads back the written upgrade image package from the target partition and recalculates the hash value of the read-back upgrade image package.

[0101] The firmware reads the entire image package data that was just written, starting from the beginning address of the target partition. It then calls the hash acceleration unit (or software hash) of the hardware security module again to calculate its hash value, obtaining the readback hash value. This process needs to ensure that the amount of data read is consistent with that written and handle possible bad blocks or ECC errors.

[0102] Readback verification detects data inconsistencies caused by flash memory hardware failures (such as bad blocks), write errors, or bit flips, ensuring that the written data is completely consistent with the original image. This additional layer of checks further guarantees firmware integrity and avoids potential risks introduced by storage media issues.

[0103] Furthermore, in step S700, the upgrade image package that has been written is read back from the target partition, and the hash value of the read-back upgrade image package is recalculated. This includes: reading back each sub-image from each sub-partition, calculating the hash value of each sub-image, and comparing it one by one with the expected hash value of the corresponding sub-image in the upgrade image package.

[0104] After writing the multi-core sub-images to their respective sub-partitions in step S600, the firmware performs the final data integrity verification. Since the upgrade image package contains multiple sub-images, and each sub-image independently calculates and stores its own expected hash value during package generation (usually stored in the image package header or the metadata area of ​​each sub-image's header), the firmware needs to perform readback verification at the sub-image granularity. The specific steps are as follows: Obtaining the expected hash value of each sub-image: The firmware revisits the upgrade image package in the temporary storage partition (or retrieves the image package header information stored in memory) and parses out the expected hash value corresponding to each sub-image. These expected hash values ​​are calculated and stored independently for each sub-image during the image package generation stage, such as the hash value H0_exp for Core0 firmware, the hash value H1_exp for Core1 firmware, the hash value H2_exp for Core2 firmware, and the hash value H3_exp for Core3 firmware. The firmware saves these expected values ​​in memory for subsequent comparison.

[0105] Traversing Subpartitions: The firmware accesses each subpartition sequentially according to a predefined order (usually corresponding to the core number). For example, it first accesses the subpartition corresponding to Core0, then the Core1 subpartition, and so on. For each subpartition, the firmware performs the following operations: Starting from the beginning address of the sub-partition, read the complete sub-image data. The read length is equal to the size of the sub-image recorded in the upgrade image package.

[0106] The read data is sent to the hash acceleration unit of the hardware security module to recalculate the hash value of the sub-image, resulting in Hx_recalc (e.g., H0_recalc, H1_recalc, etc.).

[0107] The hardware security module returns the calculated hash value.

[0108] One-by-one comparison: The firmware compares the recalculated sub-image hash value Hx_recalc with the corresponding expected sub-image hash value Hx_exp obtained from the image packet header, byte by byte. For example, it compares whether H0_recalc is equal to H0_exp, whether H1_recalc is equal to H1_exp, and so on.

[0109] Processing and comparison results: If the hash values ​​of all sub-images match, it is confirmed that the entire upgrade image package is stored correctly in the target partition. The process then proceeds to S800, which reports a successful upgrade to the host.

[0110] If the hash value comparison of any sub-image fails, the firmware immediately terminates the upgrade process and takes appropriate measures based on the failure situation: for example, recording the specific sub-partition identifier of the failure (such as "Core2 firmware verification failed"), clearing the temporary partition data, keeping the original firmware of the target partition unchanged, and returning a detailed error code to the host to indicate which sub-image is corrupted.

[0111] Furthermore, to improve reliability, the firmware can enable the flash memory's ECC function during the readback process. If an uncorrectable ECC error is detected, it is also considered a verification failure. In addition, for critical sub-images (such as Core0 boot firmware), multiple readback comparisons can be performed to eliminate transient errors.

[0112] For example, suppose a quad-core system has an upgrade image package containing four sub-images. After the firmware is written, the Core0 firmware is read back from the Core0 sub-partition and its hash value is calculated to obtain H0_recalc, which is then compared with H0_exp recorded in the package. Next, H1_recalc is read back from the Core1 sub-partition and compared with H1_exp, which is also matched. The same operation is performed on Core2 and Core3. After all comparisons pass, the upgrade is confirmed to be successful.

[0113] By performing independent readback hash comparisons at the sub-image granularity, fine-grained integrity verification of multi-core firmware is achieved. Compared to performing a single readback verification on the entire image package, this method can precisely pinpoint which specific core's firmware was corrupted during the writing process (e.g., due to bad blocks in the flash memory of a specific sub-partition), thus providing more targeted error diagnosis information and facilitating subsequent repair or retry. Simultaneously, this sub-image-by-sub-image verification mechanism ensures that the firmware loaded on each CPU core is complete and reliable, preventing firmware corruption on one core from affecting the judgment of other cores, providing a solid guarantee for the reliable boot and operation of multi-core systems.

[0114] If the hash value of the upgrade image package read back is the same as the final hash value, the upgrade is confirmed to be successful.

[0115] The readback hash value calculated in step S700 is compared with the final hash value obtained in step S300 (or the copy saved by the hardware security module). If they match completely, the firmware returns an "upgrade successful" status to the host and can perform subsequent cleanup work (such as deleting temporary partition data, updating the boot counter, etc.). If they do not match, the upgrade is determined to have failed, and the firmware may trigger a retry mechanism (such as recopying or rolling back) and return an error code.

[0116] Only after final consistency confirmation is the upgrade declared successful, ensuring the integrity and availability of the new firmware on the storage medium. This completely eliminates firmware corruption caused by storage errors, ensuring that secure boot will pass verification smoothly on the next startup, achieving closed-loop protection throughout the entire firmware upgrade process.

[0117] In this embodiment, by performing signature verification before writing firmware to flash memory, a "verify signature before writing" upgrade protection mechanism is implemented, effectively preventing damaged or tampered firmware from entering the storage partition and fundamentally eliminating the risk of device bricking due to upgrading bad firmware. The segmented reception and hash value calculation method not only adapts to the limited memory resources of the FPGA chip but also enables real-time monitoring of integrity during data transmission, ensuring that each data segment is not tampered with or lost. A hardware security module is introduced for public key verification and signature verification, placing key management and cryptographic operations in a hardware-isolated environment, avoiding the risk of software-level key exposure and significantly improving the reliability and anti-attack capabilities of the verification process. Fourth, the design of a temporary storage partition achieves physical isolation between the upgrade data and the running firmware, ensuring that even if signature verification fails, it will not affect the normal operation of the current system and guaranteeing the business continuity of the device. Fifth, a readback verification step is added after image copying to perform secondary confirmation of the data written to flash memory, effectively avoiding data inconsistency problems caused by bad flash memory blocks or write anomalies, forming a closed-loop protection from transmission, signature verification to storage, significantly improving the security and success rate of FPGA chip firmware upgrades.

[0118] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0119] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0120] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0121] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0122] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0123] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0124] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0125] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0126] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0127] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0128] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0129] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0130] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0131] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0132] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0133] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0134] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A firmware security upgrade method for a chip, characterized in that, Includes the following steps: S100, in response to receiving the parameter information of the upgrade image package sent by the host, determines whether to allow the upgrade based on the parameter information of the upgrade image package; S200, if the upgrade is allowed, the host is notified to divide the upgrade image package into several consecutive data segments according to the memory size of the chip, and to send each data segment to the firmware in sequence according to the order of the data segments. S300, upon receiving a data segment, writes the received data segment to the temporary storage partition of the flash memory and calls the hash algorithm to update the cumulative hash value of the current data segment until all data segments have been received, and obtains the final hash value of the upgrade image package; S400: Obtain the digital signature and public key from the host, and call the hardware security module to verify the legitimacy of the public key; the legitimacy verification includes verifying the integrity and trustworthiness of the public key; S500: If the public key verification passes, the final hash value, digital signature, and public key are sent to the hardware security module. The hardware security module uses the public key to decrypt the digital signature and compares the decryption result with the final hash value to verify the validity of the digital signature. If the digital signature verification is successful, the complete upgrade image package in the temporary partition will be copied to the target partition. After copying, the S700 reads back the written upgrade image package from the target partition and recalculates the hash value of the read-back upgrade image package. If the hash value of the upgrade image package read back is the same as the final hash value, the upgrade is confirmed to be successful.

2. The firmware security upgrade method for a chip according to claim 1, characterized in that, Step S300 includes the following steps: S310, obtain the first preset value N=1 and the intermediate variable X; S320, the Nth data segment QW N Write to the temporary partition of flash memory and call the hash algorithm based on X and QW. N Calculate QW N The corresponding cumulative hash value HA N ; HA N Write to X; Enter S330; M is the number of data segments; S330, determine HA N Is this correct? If HA N If correct, proceed to S340; otherwise, stop firmware upgrade. S340, if N < M, then obtain N = N + 1 and proceed to S320; otherwise, obtain the final hash value of the upgrade image package.

3. The firmware security upgrade method for a chip according to claim 1, characterized in that, The step of dividing the upgrade image package into several consecutive data segments based on the memory size of the FPGA chip includes the following steps: S210, obtain the current available memory buffer capacity value QR inside the FPGA chip; S220, if the total size of the upgrade image package QE≤QR, then the entire upgrade image package will be transmitted as a data segment; S230, if QE > QR, then determine the number of data segments required based on QR: NUM = ceil(QE / QR); ceil() is the preset rounding up function; S240, divide the upgrade image package into NUM data segments in sequence; the length of each data segment does not exceed QR, the length of the first NUM-1 data segments is QR, and the length of the NUM-th data segment is QE-(NUM-1)×QR.

4. The firmware security upgrade method for a chip according to claim 1, characterized in that, Step S100 includes the following steps: S110, Obtain parameter information of the upgrade image package sent by the host; the parameter information includes at least: target partition identifier, total size of the upgrade image package, image version number, image type identifier, and trigger source of the upgrade operation; S120: Access the flash memory's partition table based on the target partition identifier, check if the target partition exists and if the partition type matches the image type identifier. If the partition does not exist or the type does not match, terminate the upgrade process. S130: If the partition exists and the type matches, and the remaining space of the target partition is less than the total size of the upgrade image package, then terminate the upgrade process; otherwise, proceed to S140. S140: If the image version number of the upgrade image package is not higher than the current firmware version number and the upgrade policy prohibits downgrading or repeated upgrades, then the upgrade process is terminated; otherwise, proceed to S150. S150: If the system status does not allow the upgrade, terminate the upgrade process; otherwise, return an upgrade permission confirmation message to the host.

5. The firmware security upgrade method for a chip according to claim 1, characterized in that, After step S500 and before step S600, the method further includes the following steps: S510 reads the written complete upgrade image package from the scratch partition; S520, recalculate the hash value of the complete upgrade image package; S530: If the hash value of the complete upgrade image package is the same as the final hash value, the copying operation continues; otherwise, the temporary data is deemed corrupted and the upgrade process is terminated.

6. The firmware security upgrade method for a chip according to claim 1, characterized in that, The upgrade image package contains multiple sub-images corresponding to different CPU cores, and the target partition contains multiple sub-partitions corresponding to each CPU core; the copying to the target partition in step S600 includes: writing each sub-image to its corresponding sub-partition.

7. The firmware security upgrade method for a chip according to claim 6, characterized in that, Step S700 involves reading back the written upgrade image package from the target partition and recalculating the hash value of the read-back upgrade image package. This includes: reading back each sub-image from each sub-partition and calculating the hash value of each sub-image, comparing it one by one with the expected hash value of the corresponding sub-image in the upgrade image package.

8. The firmware security upgrade method for a chip according to claim 2, characterized in that, Following step S240, the method further includes the following steps: S250 reports the size of the currently available memory buffer to the host, enabling the host to dynamically determine the length of each data segment based on the currently available memory buffer size. The S260 adjusts the length of subsequent data segments in real time based on firmware feedback during transmission to adapt to changes in the FPGA chip's memory resources.

9. A non-transitory computer-readable storage medium, wherein the storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the firmware security upgrade method for the chip as described in any one of claims 1-8.

10. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 9.

Images