CXL switch firmware online upgrade, version rollback and multi-chip configuration synchronization method

Abstract

The application discloses a CXL switch firmware online upgrading, version rollback and multi-chip configuration synchronization method, comprising the following steps: receiving new firmware in an independent backup area; judging an atomic switching condition based on multi-source data, switching to the backup area when the condition is met, and initializing a new firmware environment based on the running state of a shared configuration area. The rollback control comprises the following steps: multi-dimensional health monitoring after switching, determining a rollback level according to the result and performing a differential rollback operation. The configuration synchronization comprises the following steps: obtaining a first chip configuration snapshot, consistency arbitration with a second chip, and synchronizing parameters to the second chip when synchronization is required. Through the independent backup storage area, atomic switching and configuration state inheritance, zero-interruption online upgrading of services is realized; through hierarchical rollback, microsecond-level rapid recovery is realized; and through configuration snapshot arbitration, multi-chip configuration consistency synchronization is realized.

Description

Technical Field

[0001] This invention relates to a method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of a CXL Switch, and particularly relates to the field of computer interconnection and firmware management technology. Background Technology

[0002] The CXL (Compute Express Link) Switch ASIC, as the core switching chip in the CXL Fabric, has firmware that controls core functions such as chip initialization, port configuration, routing table management, HDMI decoder programming, and error handling. Throughout the server's lifecycle, the CXL Switch firmware requires multiple upgrades to fix security vulnerabilities, optimize parameters, and support new features.

[0003] The existing CXL Switch firmware upgrade solution has the following drawbacks: First, firmware upgrades require service interruption. After the new firmware is burned, a cold reset or power-on restart is usually required for it to take effect. During the upgrade, all ports stop data forwarding, resulting in a complete interruption of communication between the connected CXL devices and the host, making true online upgrades impossible. Second, the rollback mechanism after a failed firmware upgrade relies on a cold reset, resulting in long recovery times and potentially cascading effects, further extending system recovery time. Third, in systems composed of multiple CXL Switch chips, there is a lack of consistency guarantees for firmware versions and configuration parameters across different chips. Administrators must operate chip by chip, and there is a lack of atomic version switching mechanisms. When some chips upgrade successfully while others fail, the system is in an uncertain state of version inconsistency, which can easily lead to intermittent failures. Furthermore, the existing solution lacks a mechanism for retaining and migrating configuration states during the firmware upgrade process. After the upgrade, a complete initialization process must be re-executed, extending the upgrade time and increasing risks. Summary of the Invention

[0004] This invention provides a method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch to overcome the shortcomings of existing technologies, such as the need to interrupt services for firmware upgrades, long rollback recovery time, lack of consistency guarantee for multi-chip configuration, and inability to retain and migrate configuration status.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] This invention discloses a method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of a CXL Switch, comprising: receiving a new firmware image through the management interface of the CXL Switch; residing the new firmware image in a backup storage area, wherein the backup storage area is independent of the current running area of ​​the CXL Switch firmware; determining whether a preset atomic switching condition is met in response to multi-source data characterizing the current firmware running state; if the atomic switching condition is met, atomically switching the firmware execution of the CXL Switch from the current running area to the backup storage area without interruption, and initializing the running environment of the new firmware image based on the running configuration state saved in the shared configuration area during the switching preparation phase.

[0007] Furthermore, receiving the new firmware image through the management interface of the CXL Switch specifically includes: dividing the complete new firmware image into multiple data segments; transmitting the multiple data segments one by one through the management interface; performing verification on each data segment after the transmission of each data segment is completed; and performing integrity verification on the complete new firmware image in the backup storage area after all data segments have been transmitted.

[0008] In one implementation, the running configuration state includes at least one of the following configuration parameters: port VCS home configuration, PBR routing table entry, and HDM decoder window mapping parameters.

[0009] Furthermore, the atomic switching of the firmware execution of the CXL Switch from the current running area to the backup storage area specifically includes: updating the value of the hardware boot pointer register within one clock cycle, so that it switches from pointing to the current running area to pointing to the backup storage area.

[0010] Furthermore, the uninterrupted switching specifically includes: at the moment of switching execution, temporarily storing the in-transit transactions of the CXL Switch input port in a virtual output queue; and after the switching is completed, resuming and forwarding the in-transit transactions from the virtual output queue.

[0011] In one implementation, the current running area and the backup storage area are two independently partitioned storage areas on the same physical storage medium, and the storage capacity of each partition is not less than the size of the complete firmware image.

[0012] Furthermore, after initializing the runtime environment of the new firmware image, the process further includes: performing a self-test on the new firmware image running in the backup storage area; determining whether the upgrade was successful based on the self-test result; and if the self-test fails, triggering an atomic rollback operation to switch the firmware execution of the CXL Switch back to the current runtime area.

[0013] Furthermore, the multi-source data characterizing the current firmware operating status includes at least one of the following status information: port link status, bit error rate, and historical transaction success rate.

[0014] This application provides an intelligent rollback control method for CXL Switch firmware, comprising: executing the online upgrade method described in the first aspect of this application to complete the firmware execution switch from the current running area to the backup storage area; after the switch is completed, performing multi-dimensional health monitoring on the CXL Switch, wherein the multi-dimensional health monitoring includes monitoring at least two of the following: port link status, bit error rate, routing table consistency, HDM decoder status, and critical transaction response; determining the rollback level based on the results of the multi-dimensional health monitoring, wherein the rollback level includes at least a first rollback level and a second rollback level, wherein the recovery time of the first rollback level is shorter than that of the second rollback level; and performing the corresponding rollback operation based on the determined rollback level.

[0015] As one implementation method, determining the rollback level based on the results of the multi-dimensional health monitoring specifically includes: for each monitoring dimension, calculating the confidence score of that dimension based on the measured value of that dimension and a preset benchmark value and degradation threshold; weighting and summing the confidence scores of all monitoring dimensions to obtain a comprehensive health index; and determining the rollback level based on the comparison results between the comprehensive health index and multiple preset health threshold intervals.

[0016] This application provides a configuration synchronization method for multiple CXL switch chips, applied to a system containing at least two CXLS switch chips. The method includes: in response to a firmware upgrade event, obtaining a configuration snapshot of a first CXL switch chip, the configuration snapshot containing version information of multiple configuration fields; performing consistency arbitration between the configuration snapshot of the first CXL switch chip and the current configuration of a second CXL switch chip; if the arbitration result indicates that configuration synchronization is required, then synchronizing the configuration parameters of the first CXL switch chip to the second CXL switch chip.

[0017] As one implementation, the step of arbitrating the consistency of the configuration snapshot of the first CXL Switch chip with the current configuration of the second CXLSwitch chip specifically includes: for each configuration domain, calculating the version affinity (K_{d}) between the first chip and the second chip in that configuration domain; performing a weighted summation of the version affinity (K_{d}) of all configuration domains to obtain the win rate (P) of the first chip relative to the second chip; if the win rate (P) is lower than a preset synchronization activation threshold, it is determined that configuration synchronization is required.

[0018] This application provides a CXL Switch firmware online upgrade device, comprising: a management interface module for receiving a new firmware image through the CXL Switch's management interface; a storage control module for residing the new firmware image in a backup storage area, wherein the backup storage area is independent of the current running area of ​​the CXL Switch firmware; a switching judgment module for determining whether a preset atomic switching condition is met in response to multi-source data characterizing the current firmware running state; and an atomic switching and initialization module for atomically switching the firmware execution of the CXL Switch from the current running area to the backup storage area without interruption when the atomic switching condition is met, and initializing the running environment of the new firmware image based on the running configuration state saved in the shared configuration area during the switching preparation phase.

[0019] According to a fifth aspect of this application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement a method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of a CXL Switch.

[0020] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of a CXL Switch.

[0021] The beneficial effects achieved by this invention are as follows: By setting up a backup storage area independent of the current operating area, the reception and storage of new firmware images can be realized without affecting the normal operation of the current operating area; through an atomic switching mechanism, firmware execution is switched from the current operating area to the backup storage area without interruption, and the running configuration state saved in the shared configuration area is used to initialize the new firmware operating environment, thereby completing online firmware upgrades without interrupting data plane traffic, solving the problem of traditional upgrades requiring service interruption. Through multi-dimensional health monitoring after the switch is completed, and determining differentiated rollback levels based on the monitoring results, hierarchical recovery from microsecond-level fast rollback to millisecond-level configuration reconstruction rollback is achieved, significantly shortening the system recovery time after upgrade failure. Through the standardized format of configuration snapshots and weighted arbitration based on version affinity, consistent configuration synchronization and atomic version switching are achieved in multi-chip systems, avoiding intermittent failures caused by version inconsistency. In addition, by saving the running configuration state in the shared configuration area, the new firmware can inherit the key configurations before the upgrade after startup, without having to re-execute the complete initialization process, shortening the system readiness time after the upgrade. Attached Figure Description

[0022] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0023] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0024] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0025] Example 1

[0026] Terminology Explanation

[0027] Backup storage area: refers to the storage area used to store new firmware images. Its characteristic is that during firmware upgrades and other operations, this area is logically and operationally independent from the storage area of ​​the currently running firmware, so that operations on the backup storage area do not affect the normal operation of the currently running area.

[0028] Current running area: refers to the storage area where the CXL Switch chip is currently executing its firmware code.

[0029] Management interface: refers to the communication channel used by the CXL Switch chip to receive management commands and data, which may include standard CXL specification-defined protocol interfaces such as CCI and MCTP.

[0030] Multi-source data: refers to a set of status information from different monitoring dimensions or types used to characterize the current health and stability of the CXL Switch chip.

[0031] Atomic switching conditions: refer to a set of preset logical judgment criteria. The switching operation of the firmware execution area is allowed only when all these criteria are met, so as to ensure the determinism and security of the system.

[0032] Shared configuration area: refers to a public storage area that can be accessed by different firmware versions before and after the switch, mainly used to save and transfer the running configuration status during the switch preparation phase.

[0033] Running configuration status: refers to the set of parameters managed by the firmware at runtime that reflect the current working status of the CXL Switch, such as port VCS home configuration, PBR routing table entries, HDM decoder window mapping parameters, etc.

[0034] Virtual output queue: refers to the hardware buffer in the CXL Switch chip used to temporarily buffer in-transit transactions (such as CXL.mem read and write requests) of input ports under specific conditions (such as the moment of switching).

[0035] Self-test: refers to the internal verification process performed by the new firmware image after startup on its own functional modules and the key hardware status of the chip.

[0036] Rollback level: refers to the different recovery strategy levels divided according to the severity of system anomalies or failures. Different levels correspond to different recovery operations and recovery time targets.

[0037] Configuration snapshot: refers to a standardized data set formed by serializing multiple configuration field information of the CXL Switch chip at a specific moment.

[0038] Version affinity: A metric used to quantify how similar the versions of two different chips are in a specific configuration domain. The higher the value, the smaller the version difference.

[0039] Win rate: In the arbitration process of multi-chip configuration synchronization, it is a comprehensive indicator used to quantify the superiority or compatibility of the configuration version of one chip (as the configuration source) with respect to the configuration version of another chip (as the configuration target) at the global level.

[0040] like Figure 1 As shown, a method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of a CXL Switch includes:

[0041] S101: Receives new firmware images via the management interface of the CXL Switch;

[0042] S102: Relocate the new firmware image to backup storage area 2, wherein backup storage area 2 is independent of the current running area 1 of the CXL Switch firmware;

[0043] S103: In response to multi-source data representing the current firmware operating state, determine whether the preset atomic switching conditions are met;

[0044] S104: If the atomic switching condition is met, the firmware execution of the CXL Switch is atomically switched from the current running area 1 to the backup storage area 2 without interruption, and the running configuration state saved in the shared configuration area 3 during the switching preparation phase is used to initialize the running environment of the new firmware image.

[0045] In this embodiment, steps S101 to S104 work together to achieve online, uninterrupted firmware upgrades for the CXL Switch. Specifically, by securely transmitting and storing the new firmware image in a backup storage area 2 that is physically or logically isolated from the current operating area 1, upgrade preparation can be completed without affecting current service traffic. The switching judgment condition S103 relies on multi-source data, ensuring that the switching is only performed when the chip state is healthy and stable, thus improving the upgrade success rate. The final atomic switching operation S104 is completed in a very short time (such as one clock cycle) and utilizes the complete operating state saved in the shared configuration area 3, enabling the new firmware to seamlessly take over the original service flow. This collectively solves the problems of low system availability and high upgrade risk caused by service interruption and configuration loss in traditional firmware upgrade schemes, achieving a comprehensive technical effect of zero service interruption and smooth state migration.

[0046] Taking a specific application scenario as an example, in an AI training server, the administrator wants to fix a security vulnerability in the CXL Switch firmware through an online upgrade. First, the management software transmits the new firmware image segment by segment to backup storage area 2 via the CCI interface (S101). During this period, the CXL Switch continues to run the old firmware from the current running area 1, handling high-speed data exchange requests between the GPU and the CXL memory pool, without the business being aware of it. After all data segments have been transmitted and verified (S102), the system collects the current port link status, bit error rate, etc. as multi-source data (S103) to determine that the current chip load is stable and meets the switching conditions. Subsequently, the system atomically updates the firmware execution pointer from pointing to the current running area 1 to pointing to backup storage area 2 within one clock cycle (S104), and the CXL.mem transactions in transit at the moment of switching are temporarily stored in the virtual output queue. After the new firmware starts, it immediately reads and restores the running configuration state, including VCS configuration and routing table, from the shared configuration area 3, starts the business processing pipeline, and resumes the temporarily stored transactions from the virtual output queue to continue forwarding. The entire upgrade process is completely transparent to the application undergoing AI training, enabling online firmware upgrades with zero business interruption.

[0047] In one embodiment, step S101 of receiving the new firmware image is further optimized. Step S101 specifically includes: dividing the complete new firmware image into multiple data segments; transmitting the multiple data segments one by one through the management interface; performing verification on each data segment after its transmission is completed; and performing integrity verification on the complete new firmware image in backup storage area 2 after all data segments have been transmitted. Specifically, "dividing the complete new firmware image into multiple data segments" ensures reliable transmission even for large-capacity firmware images and supports breakpoint resume functionality. "Transmitting the multiple data segments one by one through the management interface" provides fine-grained control over the transmission process. "Performing verification on each data segment after its transmission is completed" can detect and correct potential transmission errors early in the transmission process, improving transmission reliability. "Performing integrity verification on the complete new firmware image in backup storage area 2 after all data segments have been transmitted" is the final barrier to ensure that the complete image written to backup storage area 2 is untampered and the data is intact. Furthermore, based on the above principles, this segmented transmission and segmented verification method effectively avoids the time-consuming problem of retransmitting large blocks of data when they fail to be transmitted at once, and ensures the correctness of the new firmware image before storage. As a specific implementation, the "data segment" in the segmented transmission can correspond to a fixed-size "segment"; the "verification" can be CRC verification or hash verification; and the "integrity verification" can use end-to-end SHA-256 hash verification or digital signature verification.

[0048] In one embodiment, the aforementioned runtime configuration state includes at least one of the following configuration parameters: port VCS attribution configuration, PBR routing table entries, and HDM decoder window mapping parameters. This scheme clarifies the specific state categories that need to be saved from the current runtime environment to shared configuration area 3 during the handover preparation phase. Port VCS attribution configuration determines the port occupancy relationship between different virtual channels; PBR routing table entries are the core basis for packet forwarding; and HDM decoder window mapping parameters define the mapping relationship between host memory addresses and CXL device memory addresses. Saving these states ensures that after the new firmware starts, the CXL Switch can maintain completely consistent connectivity, routing logic, and memory access semantics with the previous version, without requiring services to be aware of firmware changes. Furthermore, based on the above principles, this approach ensures the continuity of critical network topology and memory mapping configuration after firmware upgrades, avoiding link interruptions or address access errors due to configuration loss. As a specific implementation, the runtime configuration state can also include other runtime management parameters such as QoS (Quality of Service) policies and port link width configurations to ensure complete consistency between the new firmware runtime environment and the old environment.

[0049] In one embodiment, for the atomic switching of firmware execution of the CXL Switch from the current running area 1 to the backup storage area 2, the operation S104 specifically includes: updating the value of the hardware boot pointer register within one clock cycle, changing its pointer from pointing to the current running area 1 to pointing to the backup storage area 2. This scheme reveals a core hardware mechanism for achieving "atomic" switching. The hardware boot pointer register is a key hardware unit that determines where firmware execution is loaded from when the chip is reset or started. By constraining the update operation of its value to be completed within one clock cycle, it is ensured that, from the perspective of an external observer, the switching of the firmware execution source is an indivisible instantaneous action without intermediate states. This constitutes the physical basis for uninterrupted switching and data plane transaction temporary storage. Furthermore, combined with the above principles, this method can achieve deterministic switching of the firmware execution source with extremely low hardware overhead and extremely high reliability, which is the fundamental guarantee for realizing online upgrades.

[0050] In one embodiment, for the aforementioned uninterrupted switching, operation S104 specifically includes: at the instant of switching execution, temporarily storing the in-transit transactions of the CXL Switch input port in a virtual output queue; after the switching is completed, retrieving and forwarding the in-transit transactions from the virtual output queue. This scheme describes how to achieve firmware switching without interrupting service traffic. During the extremely short time of an atomic switching operation, newly arriving or processing CXL transactions (such as memory read / write) may be lost due to the brief unavailability of the execution logic. By setting up a virtual output queue at the input port and enabling a transaction stall mechanism at the instant of switching, these in-transit transactions can be safely cached. Once the new firmware starts from backup storage area 2 and completes runtime environment initialization, the cached old transactions can be immediately retrieved from the virtual output queue and processed and forwarded according to the new firmware logic. Furthermore, based on the above principles, this method can effectively guarantee that no data plane transactions will be lost during the critical operation window of firmware switching, thus ensuring business continuity for upper-layer applications.

[0051] In one embodiment, the aforementioned current operating area 1 and backup storage area 2 are two independently partitioned storage areas within the same physical storage medium, with each partition having a storage capacity no less than the size of the complete firmware image. This scheme defines a physical implementation of a dual-bank storage architecture. The two partitions reside in the same Flash or other non-volatile storage medium, but address mapping or hardware protection mechanisms ensure that read / write operations on one partition do not affect the data integrity and accessibility of the other. The requirement that each partition's capacity be no less than the size of the complete firmware image ensures that at least one complete, bootable firmware copy is always available, providing a physical basis for upgrades and rollbacks. Furthermore, based on the above principles, this approach achieves high availability of firmware storage without significantly increasing hardware costs, providing necessary physical redundancy for online upgrades and intelligent rollbacks.

[0052] In one embodiment, following the operation after initializing the runtime environment of the new firmware image mentioned above, after step S104, the following steps are also included: performing a self-test on the new firmware image running in the backup storage area 2; determining whether the upgrade was successful based on the self-test result; and if the self-test fails, triggering an atomic rollback operation to switch the firmware execution of the CXL Switch back to the current runtime area 1. This scheme establishes a basic upgrade failure protection mechanism. After the new firmware starts and restores its configuration, its "self-test" process is used to verify whether its key functional modules (such as SerDes, memory controller, routing engine, etc.) are initialized normally and whether their internal states are consistent. If the self-test fails, it indicates that the new firmware may not run correctly, and the system will immediately "trigger an atomic rollback operation," that is, again using an atomic switching mechanism similar to S104 to quickly switch the hardware boot pointer register back to point to the current runtime area 1, and use the information in the shared configuration area 3 to restore the state of the old firmware. This constitutes the simplest safety net to prevent defective new firmware from causing the system to be unavailable for a long time. Furthermore, based on the above principles, this method can automatically identify and correct fatal firmware defects in a very short time after the upgrade, quickly restoring the system to a known, stable older version state, and significantly shortening the fault recovery time.

[0053] In one embodiment, the multi-source data characterizing the current firmware operating status mentioned above includes at least one of the following status information: port link status, bit error rate, and historical transaction success rate. This scheme lists key status information sources used to determine atomic switching conditions. Port link status reflects the stability of physical layer connections; bit error rate directly measures signal transmission quality; and historical transaction success rate assesses the reliability of the chip's forwarding function from an application layer perspective. These multi-source data comprehensively reflect the health status of the CXL Switch from different dimensions. Only when all of them are at a good level does it indicate that the system is in a stable state suitable for high-risk operations (such as firmware switching), thus approving the execution of atomic switching. This improves the accuracy of upgrade decisions. Furthermore, combining the above principles, this approach provides a scientific and dynamic decision-making basis for the critical operation of firmware switching through multi-dimensional, real-time operational status feedback, avoiding the risks that may arise from forced upgrades when the system is unstable.

[0054] In one embodiment, this application provides an intelligent rollback control method for CXL Switch firmware. The method includes: executing the online upgrade method as described in any one of claims 1 to 8 to complete the firmware switch from the current running area to the backup storage area; after the switch is completed, performing multi-dimensional health monitoring on the CXL Switch, including monitoring at least two of port link status, bit error rate, routing table consistency, HDM decoder status, and critical transaction responses; determining the rollback level based on the results of the multi-dimensional health monitoring, the rollback level including at least a first rollback level and a second rollback level, wherein the recovery time of the first rollback level is shorter than that of the second rollback level; and performing the corresponding rollback operation based on the determined rollback level. In this application embodiment, this method introduces a more refined and intelligent failure handling closed loop on top of online upgrades. Multi-dimensional health monitoring continues after the upgrade, enabling the detection of compatibility or performance issues that were not detected by self-testing but gradually exposed during actual operation. Depending on the severity of the problem (e.g., port jitter only versus core routing table corruption), the system automatically matches different recovery strategies (e.g., fast switchover or configuration rebuild), achieving an optimal balance between recovery time and processing granularity.

[0055] In one embodiment, the process of determining the rollback level based on the results of multi-dimensional health monitoring is further optimized. This process specifically includes: for each monitoring dimension, calculating a confidence score for that dimension based on the measured value, a preset baseline value, and a degradation threshold; weighted summing of the confidence scores for all monitoring dimensions to obtain a comprehensive health index; and determining the rollback level based on a comparison of the comprehensive health index with multiple preset health threshold intervals. This scheme provides a quantitative, comprehensive decision-making mechanism. The "confidence score" of each dimension maps its continuous physical measurement value (such as bit error rate) to a standardized health score (e.g., 0.0 to 1.0). Then, different "weights" are assigned to each dimension based on its importance to the overall health of the system, and a comprehensive health index is obtained through weighted summation. Finally, by comparing the comprehensive index with multiple preset threshold intervals, the current system is objectively determined to be "healthy," "slightly abnormal," or "severely abnormal," thereby triggering different rollback levels (e.g., success, L1 rollback, L2 rollback). Furthermore, combining the above principles, this approach overcomes the misjudgments that might result from a single-dimensional "veto" decision. By mathematically integrating multi-dimensional information, rollback decisions become more scientific and robust, avoiding unnecessary escalation and rollback or delayed responses to serious issues. As a specific implementation method, multi-dimensional health monitoring can include monitoring five dimensions: port link status, bit error rate, routing table consistency, HDM decoder status, and critical transaction response. The weights can be set based on expert experience; for example, critical transaction response has the highest weight.

[0056] In one embodiment, this application provides a configuration synchronization method for multiple CXL switch chips, applied to a system containing at least two CXL switch chips. The method includes: in response to a firmware upgrade event, obtaining a configuration snapshot of a first CXL switch chip, the configuration snapshot containing version information for multiple configuration fields; performing consistency arbitration between the configuration snapshot of the first CXL switch chip and the current configuration of a second CXL switch chip; if the arbitration result indicates that configuration synchronization is required, then synchronizing the configuration parameters of the first CXL switch chip to the second CXL switch chip. In this embodiment, the method solves the consistency problem between firmware version and configuration parameters in a multi-chip environment. By extracting and serializing a "configuration snapshot" of a base chip (first chip), complete information on multiple fields such as firmware version, port configuration, and routing table is contained. Then, a "consistency arbitration" mechanism is used to determine whether the current configuration of the target chip (second chip) is consistent with the base chip; if inconsistent, a "synchronization" operation is triggered. This enables the multi-chip system to operate with a unified and correct configuration state, avoiding intermittent failures caused by configuration conflicts.

[0057] In one embodiment, the above-mentioned consistency arbitration process is further refined. Specifically, this process includes: calculating the version affinity (K_{d}) between the first chip and the second chip in each configuration domain; performing a weighted summation of the version affinity (K_{d}) across all configuration domains to obtain the win rate (P) of the first chip relative to the second chip; and determining that configuration synchronization is required if the win rate (P) is lower than a preset synchronization activation threshold. This scheme provides a probabilistic model-based intelligent arbitration mechanism. The "version affinity (K_d)" quantifies the degree of version difference between the two chips in a single configuration domain. Then, considering the different importance of different configuration domains to system stability (e.g., routing tables are more important than QoS policies), weights are assigned to each domain and a weighted summation is performed to obtain a comprehensive "win rate (P)". The win rate P reflects the degree to which the overall configuration of the first chip is superior to or compatible with the configuration of the second chip. Only when P is lower than a certain threshold (i.e., the superiority of the first chip's configuration is insufficient) is it determined that the configuration of the first chip needs to be synchronized to the second chip; otherwise, the current configuration of the second chip is considered acceptable or superior. This prevents slightly degraded configuration versions from being blindly synchronized to the entire system. Furthermore, based on the above principles, this approach enables fine-grained evaluation and selective synchronization of multi-source configuration versions, avoiding the potential propagation of configuration noise from "forcing the use of higher versions," and improving the long-term stability of multi-chip system configurations.

[0058] It should be noted that, in some optional implementations, the "management interface" can specifically be the CCI interface defined by the CXL specification, or a management channel based on MCTP over I2C / SMBus / PCIe. The "same physical storage medium" where the "current running area" and "backup storage area" are located can be external SPI NOR Flash or eMMC, or integrated SRAM or non-volatile memory within the chip. The determination of the "atomic switching condition" can be based not only on multi-source data, but also on other factors such as the firmware image's digital signature verification result, system time, and administrator commands. Different monitoring periods and sampling frequencies can be set for each dimension of the "multi-dimensional health monitoring," for example, port link status can be sampled once per second, and the bit error rate can be averaged every 5 seconds. The standardized format of the "configuration snapshot" can include information fields such as firmware version identifier, port configuration, routing table, HDM decoder configuration, QoS policy, and timestamp, and can be protected by encryption or hashing. The "first rollback level" (L1) can correspond to a recovery method that atomically and quickly switches back to the current running area and inherits the shared configuration area state, with an estimated recovery time of less than 100 microseconds; the "second rollback level" (L2) can correspond to a recovery method that requires restoring a configuration snapshot from the backup configuration area after switching back to the current running area, with an estimated recovery time of less than 10 milliseconds; a "third rollback level" (L3) can also exist, corresponding to a recovery method that requires retraining and complete initialization of the link, with an estimated recovery time of less than 1 second. The weights of each monitoring dimension in the weighted voting decision-making process... Static configuration is possible, for example: critical transaction response (0.4), port link status (0.3), bit error rate (0.2), and routing table consistency (0.1). The weight of each configuration domain during the version arbitration process... Static configuration is also possible, such as: routing table (0.5), HDMI decoder configuration (0.2), firmware version identifier (0.15), port configuration (0.1), and QoS policy (0.05). Before atomic bank switching, the dynamic running state of the current firmware (such as VOQ content and DMA state) can be stored as a "state seed point" in a dedicated double-buffered queue. After the new firmware starts, it can smoothly transition by using this seed point and the static state of the shared configuration area through a recursive reconstruction formula, avoiding firmware errors caused by transient state changes. The Wimbledon Arbitration Model can also be used to calculate the win rate of the chip as a configuration reference source, avoiding the propagation of degraded configurations. In the physical structure of dual-bank storage, a gradient thermal conductive layer and a phase change heat storage cavity can be added to the Flash package to balance the local heat generation during upgrade writing and improve long-term reliability. A micro-mechanical shear force triggered buffer lock can also be added to the power supply circuit to suppress voltage spikes during switching. For the connectors of the MCTP management channel, a spiral nested reverse dust collection groove design can be adopted to achieve self-cleaning using signal vibration, ensuring the reliability of the synchronization signal. Near the SerDes reference clock PLL, adaptive thermally compensated heat sinks triggered by gravity and centrifugal force can be installed to passively stabilize the clock temperature. For chip signal pins, a multi-level elastic micro-bump array can be deployed around them to compensate for long-term insertion and removal wear. Between the chip and the heat sink, an adaptive thermal stress compensation wedge block with shape memory alloy wire can be installed to prevent connector misalignment caused by thermal expansion. An interlocking protection device based on centrifugal force ratchet locking can also be installed on the side of the chip to prevent accidental impacts from causing false triggering of the Bank switching register. During multi-chip synchronous switching, the synchronization barrier signal can be dynamically compensated for timing by continuously sampling and predicting the local clock drift of each chip, ensuring that all chips complete switching within a nanosecond time window. The bit error rate threshold in health monitoring can be dynamically adjusted based on historical fluctuation variance and trends to balance sensitivity and false alarm rate. After the upgrade, changes in runtime counters such as CXL.mem transaction retry count and Poison event count can be collected to build a hidden variable for "configuration health" in order to detect potential logical errors after the configuration snapshot is loaded.

[0059] In some alternative implementations, the judgment logic of the "atomic switching condition" can be an AND gate logic, requiring all preset conditions (such as all dimensions being normal) to be met simultaneously. The "dividing the complete new firmware image into multiple data segments" can also be based on the logical modules within the image, rather than a fixed size. The "virtual output queue" can be an independent FIFO queue for each input port, or a shared buffer pool.

[0060] This application also provides a CXL Switch firmware online upgrade device. The device includes: a management interface module for receiving a new firmware image through the CXL Switch's management interface; a storage control module for residing the new firmware image in a backup storage area, wherein the backup storage area is independent of the current running area of ​​the CXL Switch firmware; a switching judgment module for determining whether a preset atomic switching condition is met in response to multi-source data characterizing the current firmware running state; and an atomic switching and initialization module for atomically switching the firmware execution of the CXL Switch from the current running area to the backup storage area without interruption when the atomic switching condition is met, and initializing the running environment of the new firmware image based on the running configuration state saved in the shared configuration area during the switching preparation phase. The modules of this device work collaboratively to implement the steps corresponding to those in the aforementioned method embodiments, achieving the same technical effect.

[0061] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method as described in any of the foregoing method embodiments.

[0062] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any of the foregoing method embodiments.

[0063] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch, characterized in that: include: Receive the new firmware image through the management interface of the CXL Switch; The new firmware image is stored in a backup storage area, wherein the backup storage area is independent of the current running area of ​​the CXL Switch firmware; In response to multi-source data characterizing the current firmware operating state, determine whether the preset atomic switching conditions are met; If the atomic switching condition is met, the firmware execution of the CXL Switch is atomically switched from the current running area to the backup storage area without interruption, and the running environment of the new firmware image is initialized based on the running configuration state saved in the shared configuration area during the switching preparation phase.

2. The method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch according to claim 1, characterized in that, Receiving the new firmware image through the management interface of the CXL Switch specifically includes: The complete new firmware image is divided into multiple data segments; The multiple data segments are transmitted segment by segment through the management interface; After each data segment is transmitted, a verification is performed on that data segment. After all data segments have been transferred, an integrity verification is performed on the complete new firmware image in the backup storage area.

3. The method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch according to claim 1, characterized in that, The running configuration status includes at least one of the following configuration parameters: port VCS home configuration, PBR routing table entry, and HDM decoder window mapping parameters.

4. The method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch according to claim 1, characterized in that, The atomic switching of the firmware execution of the CXL Switch from the current running area to the backup storage area specifically includes: Within one clock cycle, the value of the hardware boot pointer register is updated to switch it from pointing to the current running area to pointing to the backup storage area.

5. The method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch according to claim 1, characterized in that, The uninterrupted switching specifically includes: At the moment of switching execution, the in-transit transactions of the CXL Switch input port are temporarily stored in the virtual output queue; After the switchover is complete, the in-transit transactions are resumed and forwarded from the virtual output queue.

6. The method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch according to claim 1, characterized in that, The current running area and the backup storage area are two independently partitioned storage areas on the same physical storage medium, and the storage capacity of each partition is not less than the size of the complete firmware image.

7. The method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch according to claim 1, characterized in that, After initializing the runtime environment of the new firmware image, the following is also included: Perform a self-test on the new firmware image running in the backup storage area; Determine whether the upgrade was successful based on the self-test results; If the self-test fails, an atomic rollback operation is triggered, switching the firmware execution of the CXL Switch back to the current running area.

8. The method for online firmware upgrade, version rollback, and multi-chip configuration synchronization of CXL Switch according to claim 1, characterized in that, The multi-source data characterizing the current firmware operating status includes at least one of the following status information: port link status, bit error rate, and historical transaction success rate.

9. A smart rollback control method for CXL Switch firmware, characterized in that, include: The CXL Switch firmware online upgrade, version rollback, and multi-chip configuration synchronization method as described in any one of claims 1 to 8 is executed to complete the firmware execution switch from the current running area to the backup storage area; After the switch is completed, multi-dimensional health monitoring is performed on the CXL Switch. The multi-dimensional health monitoring includes monitoring at least two of the following: port link status, bit error rate, routing table consistency, HDM decoder status, and critical transaction response. Based on the results of the multi-dimensional health monitoring, a rollback level is determined. The rollback level includes at least a first rollback level and a second rollback level, wherein the recovery time of the first rollback level is shorter than that of the second rollback level. Based on the determined rollback level, perform the corresponding rollback operation.

10. The intelligent rollback control method for CXL Switch firmware according to claim 9, characterized in that, The determination of the rollback level based on the results of the multi-dimensional health monitoring specifically includes: For each monitoring dimension, a confidence score is calculated based on the measured value of that dimension, the preset benchmark value, and the degradation threshold. The comprehensive health index is obtained by weighted summation of the confidence scores of all monitoring dimensions; The rollback level is determined based on the comparison results between the comprehensive health index and multiple preset health threshold ranges.

Images