A multi-processing unit cooperative firmware upgrade method and system supporting atomic commit

Abstract

The application discloses a kind of multi-processing unit cooperative firmware upgrade method and system supporting atomicity submission, the system includes first processing unit, second processing unit, shared nonvolatile memory and storage access path selection unit.Sharing nonvolatile memory is selectively connected between different processing units by storage access path selection unit.First processing unit receives upgrade data by host interface and writes in shared nonvolatile memory, and second processing unit reads firmware from shared nonvolatile memory and executes upgrade.System is provided with upgrade atomicity control mechanism, for uniformly submitting upgrade after multiple processing units complete upgrade preparation, or executing overall rollback when any processing unit fails to upgrade.The application realizes the unified scheduling of multiple processing units, reduces hardware cost, improves upgrade reliability and consistency, and is suitable for acceleration card and multiprocessor system.

Description

Technical Field

[0001] This invention relates to the field of firmware upgrade technology for electronic devices, and in particular to a collaborative upgrade method and system applicable to systems containing multiple processing units such as dedicated acceleration chips and microcontrollers. Background Technology

[0002] Multi-processor unit systems, such as AI accelerator cards, smart network cards, or edge computing devices, typically include multiple processing units such as dedicated ASICs and MCUs. Each processing unit usually has independent firmware or configuration programs, and their upgrade methods have the following characteristics: dedicated ASICs typically have their firmware downloaded by the host and written to Flash via a PCIe interface; MCUs are upgraded via serial port, USB, or OTA; different processing units use different storage media or independent Flash chips.

[0003] Existing technologies have the following problems: fragmented upgrade paths and high system complexity; inconsistent firmware versions across multiple processing units may lead to system anomalies; lack of high-speed interfaces in MCUs, resulting in low upgrade efficiency; increased hardware costs due to multiple Flash designs; lack of a unified rollback mechanism in case of upgrade failure; and lack of a consistent upgrade control mechanism across processing units.

[0004] Therefore, it is necessary to provide a technical solution that enables unified scheduling of multiple processing units, shared storage, and high-reliability upgrades. Summary of the Invention

[0005] The technical problems to be solved by this invention include:

[0006] 1. How to share storage resources among multiple processing units to reduce costs;

[0007] 2. How to achieve unified upgrade scheduling for different processing units;

[0008] 3. How to achieve efficient upgrades when the MCU does not have a high-speed interface;

[0009] 4. How to avoid version inconsistencies during multi-processing unit upgrades;

[0010] 5. How to implement system-level rollback when upgrade fails;

[0011] 6. How to implement an atomic submission mechanism for multi-processing unit upgrades.

[0012] To address the shortcomings and deficiencies in existing technologies, the present invention aims to provide a multi-processing unit collaborative firmware upgrade method and system that supports atomic commits, enabling unified scheduling of multiple processing units, shared storage resources, and highly reliable and consistent upgrades, while reducing hardware costs and system complexity.

[0013] The multi-processing unit collaborative firmware upgrade system supporting atomic commit proposed in this invention includes: a first processing unit, a second processing unit, a shared non-volatile memory, and a storage access path selection unit; wherein,

[0014] The shared non-volatile memory selectively connects between the first processing unit and the second processing unit through the storage access path selection unit;

[0015] The first processing unit is configured to receive upgrade data through the host interface, write the upgrade data into the shared non-volatile memory, control the path switching of the storage access path selection unit, and record the upgrade status of each processing unit.

[0016] The second processing unit is configured to read firmware from the shared non-volatile memory and perform an upgrade operation when the shared non-volatile memory is connected to it;

[0017] The system is equipped with an upgrade atomicity control mechanism, which is used to submit the upgrade uniformly after all processing units have completed upgrade preparation, or to perform a system-wide rollback when any processing unit fails to upgrade.

[0018] The storage access path selection unit of the present invention is an electronic switch, a multiplexer, or a programmable interconnect structure, used to enable only one processing unit to access the shared non-volatile memory at any given time, thereby achieving physically isolated mutual exclusion access control.

[0019] The shared non-volatile memory described in this invention is divided into multiple logical partitions, including: ASIC image area A, ASIC image area B, MCU firmware area A, MCU firmware area B, parameter area, and metadata area. The metadata area is used to store the upgrade status, current running version, version to be submitted, and rollback flag of each processing unit.

[0020] The upgrade process of the atomicity control mechanism described in this invention is divided into a preparation phase and a submission phase;

[0021] During the preparation phase, the first processing unit receives upgrade data and writes it into the shared non-volatile memory, each processing unit performs upgrade preparation operations, and reports the preparation completion status upon completion.

[0022] During the submission phase, the first processing unit determines whether all processing units have completed the upgrade preparation. If all have completed the preparation, the unit switches to the new version. If there are any cases where the upgrade is incomplete or has failed, the unit performs a rollback operation to restore the old version.

[0023] The upgrade atomicity control mechanism described above is an atomic operation. The new versions of multiple processing units only take effect simultaneously when all upgrades are successful; otherwise, all are retained or restored to the old versions.

[0024] Furthermore, the upgrade atomicity control mechanism also includes a power failure recovery mechanism, which is used to read the upgrade status of the metadata area when the system restarts abnormally. If it is in an incomplete commit state, a rollback operation is automatically performed.

[0025] In this invention, the first processing unit is a dedicated ASIC, the second processing unit is an MCU, and the host interface is a PCIe interface. The upgrade data is transmitted from the host to the first processing unit via the PCIe interface, written to the shared non-volatile memory by the first processing unit, and finally read from the shared non-volatile memory by the second processing unit.

[0026] Based on the above system, this invention also proposes a multi-processing unit collaborative firmware upgrade method that supports atomic commits, comprising the following steps:

[0027] Step S1: System initialization. After the system is powered on, it is connected to the first processing unit by default via shared non-volatile memory. The first processing unit reads the current valid firmware to complete the configuration. The second processing unit starts from the internal boot or old firmware.

[0028] Step S2, upgrade triggered, the host sends upgrade command and upgrade data to the first processing unit through the host interface;

[0029] Step S3, upgrade data writing: The first processing unit writes the upgrade data to the corresponding backup partition of the shared non-volatile memory and updates the upgrade status of the metadata area.

[0030] Step S4, upgrade from the processing unit. The first processing unit switches the access permission of the shared non-volatile memory to the second processing unit through the storage access path selection unit. The second processing unit reads the corresponding firmware and performs the upgrade operation. After completion, it updates the upgrade status of the metadata area.

[0031] Step S5, atomic commit and rollback: The first processing unit reads the upgrade status of all processing units in the metadata area. If all upgrades are successful, the version is committed and the new version takes effect simultaneously. If any processing unit upgrade fails, the entire system is rolled back to the old version before the upgrade.

[0032] Furthermore, it also includes a power outage recovery step: if the system experiences an abnormal power outage and restart during the upgrade process, the first processing unit reads the commit status of the metadata area. If a valid commit has not been completed, a rollback operation is automatically performed to restore the system to the valid version before the upgrade.

[0033] Furthermore, it also includes a security verification step: after receiving the upgrade data, the first processing unit first performs firmware signature verification and integrity verification. Only after the verification is passed can the data be written to the shared non-volatile memory. At the same time, through partition access control, the second processing unit is restricted to accessing only its own corresponding firmware partition and cannot access the mirror partition of the first processing unit.

[0034] The beneficial effects of the multi-processing unit collaborative firmware upgrade method and system supporting atomic commits of the present invention include:

[0035] 1. By using a shared Flash memory instead of a multi-Flash solution, the number of memory chips used is reduced, thus lowering hardware costs;

[0036] 2. Centralized upgrades are achieved through PCIe, providing a unified upgrade entry point and avoiding increased system complexity caused by multi-path upgrades;

[0037] 3. No need for direct connection of the MCU to the high-speed interface; the upgrade data is written at high speed through the high-speed interface of the first processing unit, which solves the problem of low upgrade efficiency caused by the lack of a high-speed interface for the MCU.

[0038] 4. Mutual exclusion access is achieved through physical path switching, ensuring that only one processing unit accesses the shared memory at any given time, thus avoiding resource conflicts caused by multiple units accessing the shared memory;

[0039] 5. Supports a failure rollback mechanism to avoid system anomalies caused by unit upgrade failures and improve system reliability;

[0040] 6. Multiple processing unit versions take effect simultaneously, avoiding system failures caused by version inconsistencies and achieving cross-device consistency;

[0041] 7. It ensures that the upgrade either succeeds completely or fails completely, achieving atomic control of multi-unit upgrades;

[0042] 8. Supports power outage recovery, avoiding equipment damage caused by system power outages during the upgrade process and improving the fault tolerance of the upgrade process. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0044] Figure 1 This is a schematic diagram of the multi-processing unit collaborative firmware upgrade system of the present invention;

[0045] Figure 2This is a flowchart illustrating the multi-processing unit collaborative firmware upgrade method of the present invention;

[0046] Figure 3 This is a schematic diagram of the logical partitioning structure of the shared non-volatile memory of the present invention;

[0047] Figure 4 This is a schematic diagram of the state machine inside the first processing unit during the firmware upgrade process of this invention;

[0048] Figure 5 This is a schematic diagram illustrating the principle of the upgraded atomicity control mechanism of this invention. Detailed Implementation

[0049] The invention will be further described in detail below with reference to the specific embodiments and accompanying drawings. Except for the contents specifically mentioned below, the processes, conditions, and experimental methods for implementing the invention are all common knowledge and general knowledge in the art, and the invention does not have any particular limitations.

[0050] The scope of protection of this invention is not limited to the following embodiments. All variations and advantages that can be conceived by those skilled in the art within the technical scope disclosed in this invention are included in this invention and are protected by the appended claims.

[0051] like Figure 1 As shown, the present invention provides a multi-processing unit collaborative firmware upgrade system, including a host, a first processing unit, a second processing unit, a shared non-volatile memory, and a storage access path selection unit.

[0052] The shared non-volatile memory is selectively connected between the first processing unit and the second processing unit through the storage access path selection unit; the storage access path selection unit may be an electronic switch, a multiplexer or a programmable interconnect structure.

[0053] The first processing unit may be a dedicated ASIC, used to receive upgrade data through a host interface, preferably a PCIe interface; write the upgrade data into shared non-volatile memory; control the switching of the storage access path selection unit; and record the upgrade status of each processing unit.

[0054] The second processing unit may be an MCU, used to read firmware when connected to a shared non-volatile memory; and to perform firmware upgrade operations.

[0055] Furthermore, the shared non-volatile memory includes multiple logical partitions, such as... Figure 3As shown, these are the ASIC image area A, ASIC image area B, MCU firmware area A, MCU firmware area B, parameter area, and metadata area, respectively. Preferably, the shared non-volatile memory model is W25Q512JVEIQ, with a capacity of 512Mbit.

[0056] The metadata area is used to store the upgrade status, current running version, version to be submitted, and rollback flag of each processing unit.

[0057] The first processing unit contains a state machine for controlling the upgrade process, such as... Figure 4 As shown, the state machine includes the following states: idle state, receive data state, program state (erase / write flash state), verification state, preparation state, error state, wait for upgrade completion state, check state, commit state, and rollback state.

[0058] The transitions between states are based on preset conditions. The default state is idle. Upon receiving upgrade data from the host, the system enters the receiving state. After receiving the data, it enters the programming state. After writing the data, it enters the verification state. If verification fails, it enters the error state. If verification passes, it enters the preparation state, notifying each processing unit to perform the upgrade. Afterward, it enters the waiting state for upgrade completion, followed by the checking state. If all upgrades are successful, it enters the commit state. If any processing unit fails, it enters the rollback state. This state machine enables the first processing unit to control the entire upgrade process.

[0059] Furthermore, the system is equipped with an upgrade atomicity control mechanism, which is implemented as follows:

[0060] 1. The upgrade will be implemented in phases, including a preparation phase and a submission phase.

[0061] The steps for the preparation phase are as follows: Figure 2 As shown, the first processing unit receives upgrade data and writes it into the shared non-volatile memory, verifies the upgrade data, notifies each processing unit to perform upgrade preparation operations, and switches the flash memory to each processing unit in sequence as needed; after each processing unit completes its work, it reports the preparation completion status.

[0062] The execution steps during the submission phase are as follows: The first processing unit determines whether all processing units have completed preparation; if the conditions are met, the system switches to the new version and updates the startup pointer or flag; otherwise, a rollback operation is performed to restore the old version.

[0063] Furthermore, PCIe resume upgrades can be used. Compared to PCIe bandwidth, upgrade data packets can be quickly retransmitted even if the transmission is interrupted.

[0064] 2. Atomicity definition: The upgrade submission is an atomic operation, that is, the new version of multiple processing units only takes effect when all upgrades are successful, otherwise all are kept or restored to the old version.

[0065] 3. Power-off recovery mechanism: In the event of an abnormal system restart, the metadata area status is read. If the commit is incomplete, a rollback is automatically performed. The upgrade result is updated in the metadata area, including the error code in case of failure. Additionally, the host is notified of the upgrade completion via a PCIe interrupt, and the host reads the metadata area to obtain the upgrade result.

[0066] Furthermore, the upgrade data path of this invention involves the host transmitting data to the first processing unit via a PCIe interface, the first processing unit writing the data to a shared non-volatile memory, and finally transmitting it to the second processing unit. This path enables indirect upgrades of the second processing unit. All upgrade packages are stored in the shared memory unit.

[0067] Furthermore, the system is equipped with an access control mechanism that allows only one processing unit to access the shared non-volatile memory at any given time, and physical isolation is achieved through the storage access path selection unit.

[0068] Meanwhile, the present invention also provides a multi-processing unit collaborative firmware upgrade method supporting atomic commit, based on the above system, including the following steps:

[0069] Step 1: System initialization. After the system is powered on, the default shared non-volatile memory is connected to the first processing unit. The first processing unit reads the currently valid firmware in the shared non-volatile memory and completes the configuration. The second processing unit starts from its internal Boot or old firmware.

[0070] Step 2, upgrade triggered: The host sends an upgrade command and upgrade content to the first processing unit via PCIe. The upgrade content includes new firmware for the first processing unit and new firmware for the second processing unit.

[0071] Step 3, data writing: The first processing unit writes its own new firmware to the corresponding backup partition of the shared non-volatile memory, writes the new firmware of the second processing unit to the corresponding backup partition of the shared non-volatile memory, and updates the upgrade status of each processing unit in the metadata area.

[0072] Step 4: The second processing unit is upgraded. The first processing unit controls the storage access path selection unit to switch the access permission of the shared non-volatile memory to the second processing unit. The second processing unit reads the firmware from the corresponding backup partition, performs the upgrade operation, and writes the upgrade completion status back to the metadata area after the upgrade is completed.

[0073] Step 5, atomic commit, such as Figure 5As shown, the first processing unit reads the upgrade status of all processing units in the metadata area. If all processing units have completed the upgrade, a version commit operation is performed to update the current valid version to the new version. If any processing unit fails to upgrade, a rollback operation is performed to restore the old version before the upgrade.

[0074] Step 6, exception handling: If a system power outage occurs during the upgrade process, the first processing unit will read the commit status of the metadata area after the system restarts. If a valid commit has not been completed, a rollback operation will be automatically executed.

[0075] Example 1: Single ASIC + Single MCU

[0076] 1. System Composition

[0077] The system in this embodiment includes: a first processing unit, which is an ASIC; a second processing unit, which is an MCU; a shared Flash memory, which serves as a shared non-volatile memory; and a storage access path selection unit, which is an analog switch.

[0078] 2. Work Process

[0079] (1) System initialization

[0080] After the system is powered on, the Flash is connected to the ASIC by default; the ASIC reads the currently valid firmware in the Flash and completes the configuration; the MCU boots from its internal Boot or old firmware.

[0081] (2) Upgrade trigger

[0082] The host sends upgrade commands to the ASIC via PCIe, and the upgrade includes new firmware for both the ASIC and the MCU.

[0083] (3) Data writing

[0084] The ASIC performs the following operations: writes its new firmware to the ASIC_B area of ​​the Flash; writes the new firmware of the MCU to the MCU_B area of ​​the Flash; and updates the state of the metadata area to: ASIC_state=PREPARED, MCU_state=INIT.

[0085] (4) MCU upgrade

[0086] The ASIC controls the analog switch to switch the Flash from the ASIC to the MCU; the MCU performs the following operations: reads the firmware from the MCU_B area of ​​the Flash; writes it to its own execution area or internal Flash; after the upgrade is completed, writes the status back to the Flash's metadata area: MCU_state=OK.

[0087] (5) Atomic submission

[0088] The ASIC reads the upgrade status from the metadata area. If ASIC_state == OK and MCU_state == OK, it performs the following operations: sets active_version=NEW and commit_flag=1; otherwise, it sets rollback_flag=1 and performs a rollback operation.

[0089] (6) Rollback mechanism

[0090] If the upgrade fails, the ASIC restores active_version to point to the old version, while the MCU keeps the old firmware unchanged to ensure system version consistency.

[0091] (7) Power outage recovery

[0092] If a system power failure occurs during the upgrade process, after the system restarts, the ASIC will read the status of the metadata area. If the commit_flag has not been set, a rollback operation will be automatically performed to restore the valid version before the upgrade.

[0093] Example 2: Enhanced Security Against Attacks

[0094] This embodiment adds a security enhancement mechanism based on embodiment 1, as follows:

[0095] (1) Signature verification mechanism

[0096] After receiving the upgraded firmware, the ASIC first performs firmware signature verification and firmware integrity verification. Only after the verification is passed can the firmware be written to the shared Flash memory.

[0097] This embodiment uses the Elliptic Curve Digital Signature Algorithm (ECDSA), with the public key stored in the secure storage area of ​​the first processing unit (such as OTP). The hash algorithm used is SHA-256, which has advantages such as high computational efficiency, mature implementation, and high security.

[0098] (2) Access control mechanism

[0099] Access isolation is achieved through permission configuration of analog switches or partition password protection mechanisms. The MCU cannot access the ASIC image partition in Flash, preventing the firmware from being maliciously tampered with or read.

[0100] (3) Upgrade authorization mechanism

[0101] Upgrade operations must meet preset authorization conditions, including successful firmware signature verification and a valid and compliant version number. Upgrade requests that do not meet the authorization conditions will be rejected directly.

[0102] The beneficial effects of this embodiment are that it can effectively prevent malicious firmware injection, improve the security protection level of the system, and avoid device failure or data leakage caused by illegal upgrade operations.

[0103] Unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0104] As used in this invention, the term "comprising" is an open-ended expression, meaning it includes the contents specified in this invention but does not exclude other aspects.

[0105] As used in this invention, the term "and / or" includes any one or more of the related listed items and all combinations thereof.

[0106] The scope of protection of this invention is not limited to the above embodiments. All variations and advantages that can be conceived by those skilled in the art within the technical scope disclosed in this invention are included in this invention and are protected by the appended claims.

Claims

1. A multi-processing unit collaborative firmware upgrade system supporting atomic commit, characterized in that, include: The system comprises a first processing unit, a second processing unit, a shared non-volatile memory, and a memory access path selection unit; wherein... The shared non-volatile memory selectively connects between the first processing unit and the second processing unit through the storage access path selection unit; The first processing unit is configured to receive upgrade data through the host interface, write the upgrade data into the shared non-volatile memory, control the path switching of the storage access path selection unit, and record the upgrade status of each processing unit. The second processing unit is configured to read firmware from the shared non-volatile memory and perform an upgrade operation when the shared non-volatile memory is connected to it; The system is equipped with an upgrade atomicity control mechanism, which is used to submit the upgrade uniformly after all processing units have completed upgrade preparation, or to perform a system-wide rollback when any processing unit fails to upgrade.

2. The multi-processing unit collaborative firmware upgrade system according to claim 1, characterized in that, The storage access path selection unit is an electronic switch, a multiplexer, or a programmable interconnect structure, used to ensure that only one processing unit has access to the shared non-volatile memory at any given time, thereby achieving physically isolated mutual exclusion access control.

3. The multi-processing unit collaborative firmware upgrade system according to claim 1, characterized in that, The shared non-volatile memory is divided into multiple logical partitions, including: ASIC image area A, ASIC image area B, MCU firmware area A, MCU firmware area B, parameter area, and metadata area.

4. The multi-processing unit collaborative firmware upgrade system according to claim 3, characterized in that, The metadata area is used to store the upgrade status, current running version, version to be submitted, and rollback flag of each processing unit.

5. The multi-processing unit collaborative firmware upgrade system according to claim 1, characterized in that, The upgrade process of the atomicity control mechanism is divided into a preparation phase and a submission phase. During the preparation phase, the first processing unit receives upgrade data and writes it into the shared non-volatile memory, each processing unit performs upgrade preparation operations, and reports the preparation completion status upon completion. During the submission phase, the first processing unit determines whether all processing units have completed the upgrade preparation. If all have completed the preparation, the unit switches to the new version. If there are any cases where the upgrade is incomplete or has failed, the unit performs a rollback operation to restore the old version.

6. The multi-processing unit collaborative firmware upgrade system according to claim 5, characterized in that, The upgrade atomicity control mechanism described above is an atomic operation. The new versions of multiple processing units only take effect simultaneously when all upgrades are successful; otherwise, all are retained or restored to the old versions.

7. The multi-processing unit collaborative firmware upgrade system according to claim 1, characterized in that, The upgrade atomicity control mechanism also includes a power failure recovery mechanism, which is used to read the upgrade status of the metadata area when the system restarts abnormally. If it is in an incomplete commit state, a rollback operation is automatically performed.

8. The multi-processing unit collaborative firmware upgrade system according to claim 1, characterized in that, The first processing unit is a dedicated ASIC, the second processing unit is an MCU, and the host interface is a PCIe interface. The upgrade data is transmitted from the host to the first processing unit via the PCIe interface, written to the shared non-volatile memory by the first processing unit, and finally read from the shared non-volatile memory by the second processing unit.

9. A multi-processing unit collaborative firmware upgrade method supporting atomic commit, characterized in that, The method of using the multi-processor unit collaborative firmware upgrade system as described in any one of claims 1-8 includes the following steps: Step S1: System initialization. After the system is powered on, it is connected to the first processing unit by default via shared non-volatile memory. The first processing unit reads the current valid firmware to complete the configuration. The second processing unit starts from the internal boot or old firmware. Step S2, upgrade triggered, the host sends upgrade command and upgrade data to the first processing unit through the host interface; Step S3, upgrade data writing: The first processing unit writes the upgrade data to the corresponding backup partition of the shared non-volatile memory and updates the upgrade status of the metadata area. Step S4, upgrade from the processing unit. The first processing unit switches the access permission of the shared non-volatile memory to the second processing unit through the storage access path selection unit. The second processing unit reads the corresponding firmware and performs the upgrade operation. After completion, it updates the upgrade status of the metadata area. Step S5, atomic commit and rollback: The first processing unit reads the upgrade status of all processing units in the metadata area. If all upgrades are successful, the version is committed and the new version takes effect simultaneously. If any processing unit upgrade fails, the entire system is rolled back to the old version before the upgrade.

10. The multi-processing unit collaborative firmware upgrade method according to claim 9, characterized in that, It also includes a power outage recovery step: if the system experiences an abnormal power outage and restart during the upgrade process, the first processing unit reads the commit status of the metadata area. If a valid commit has not been completed, a rollback operation is automatically performed to restore the system to the valid version before the upgrade. And / or, It also includes a security verification step: after receiving the upgrade data, the first processing unit first performs firmware signature verification and integrity verification. Only after the verification is passed can the data be written to the shared non-volatile memory. At the same time, through partition access control, the second processing unit is restricted to accessing only its own corresponding firmware partition and cannot access the mirror partition of the first processing unit.

Images