Multi-board-card interconnection computing system and firmware management method of multi-board-card interconnection equipment

Abstract

The invention discloses a multi-board-card interconnection computing system and a firmware management method of a multi-board-card interconnection device, and relates to the field of computers, the multi-board-card interconnection device is connected with a plurality of board cards and is used for dividing the plurality of board cards into a plurality of levels according to board card functions of the plurality of board cards, generating a plurality of board clip codes according to the board card models contained in the board cards of different levels, and generating a board card code according to the plurality of board clip codes; and the system initialization component is connected with the multi-board-card interconnection equipment and is used for determining hardware configuration information of the multi-board-card interconnection equipment according to the board card codes and carrying out firmware management on the multi-board-card interconnection equipment according to the hardware configuration information.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a firmware management method for a multi-board interconnected computing system and a multi-board interconnected device. Background Technology

[0002] To improve board utilization and save development time and costs, a single board is often used in multiple configurations. This leads to the question of how to differentiate between these configurations and the different configuration settings required for each. Conventional designs often use different firmware (FW) for different configurations to implement different functions for each port under different configurations. This also adds a workload to firmware management.

[0003] In related technologies, a single board is often used in multiple configurations, but existing technologies struggle to distinguish between these multiple configurations and the different configuration settings that result from them, leading to difficulties in firmware management. Currently, no effective solution has been proposed. Summary of the Invention

[0004] This application provides a firmware management method for a multi-board interconnected computing system and a multi-board interconnected device, to at least solve the problem in the related art that a board is often used in multiple configurations, but the prior art has difficulty distinguishing the multiple configurations of the board and the different configuration settings under different configurations, which leads to difficulties in firmware management.

[0005] This application provides a multi-board interconnect computing system, comprising: a multi-board interconnect device connected to multiple boards, configured to divide the multiple boards into multiple levels according to their board functions, generate multiple board sub-codes according to the board models included in the boards at different levels, and generate a board code based on the multiple board sub-codes; and a system initialization component connected to the multi-board interconnect device, configured to determine the hardware configuration information of the multi-board interconnect device according to the board code, and perform firmware management on the multi-board interconnect device according to the hardware configuration information.

[0006] In one exemplary embodiment, the system initialization component includes a processor configured to: read the board code from the multi-board interconnect device when the computing system starts up; determine the power-on sequence of the plurality of boards according to the board code; and control the plurality of boards to power on sequentially according to the power-on sequence.

[0007] In one exemplary embodiment, the system initialization component includes a firmware boot module, configured to: read the board code from the multi-board interconnect device after the plurality of boards have been powered on; match the hardware configuration information in preset configuration data according to the board code, wherein the preset configuration data is used to indicate the mapping relationship between the plurality of board codes and the plurality of hardware configuration information; and load a target firmware version into the plurality of boards according to the hardware configuration information, wherein the target firmware version corresponds to the hardware configuration information.

[0008] In one exemplary embodiment, the system initialization component includes a controller configured to: read the board code from the multi-board interconnect device when the plurality of boards have been powered on; monitor the in-situ status and operating status of the plurality of boards according to the board code; and generate first abnormality information for the target board if the in-situ status or operating status of the target board is abnormal among the plurality of boards.

[0009] In one exemplary embodiment, the controller, connected to the firmware boot module and the processor, is further configured to: read the hardware connection status and configuration information of the plurality of boards from the processor, wherein the power-on sequence is determined based on the hardware connection status and the configuration information; read the version information of the target firmware version from the firmware boot module; and verify the version information based on the hardware connection status and the configuration information.

[0010] In an exemplary embodiment, the controller is further configured to: send a firmware update instruction to the firmware boot module if the version information fails verification, wherein the firmware update instruction is used to instruct the firmware boot module to reload the firmware to the plurality of boards.

[0011] In one exemplary embodiment, the controller is further configured to: monitor the operational data of multiple components of the computing system, wherein the multiple components include at least: the multi-board interconnect device, the processor, the firmware boot module, and the operational data includes at least one of the following: operating temperature, power supply voltage, and power status; and generate second abnormal information of the target component when abnormal operational data of a target component is detected among the multiple components.

[0012] In one exemplary embodiment, the multi-board interconnect device includes a PCIe (Peripheral Component Interconnect Express) port connected to the firmware boot module for connecting a PCIe device to the multi-board interconnect device, wherein the plurality of boards include the PCIe device.

[0013] In an exemplary embodiment, the PCIe port includes N high-order ports and N low-order ports. The PCIe port is further configured to: determine the first identifier bit and the second identifier bit according to the number and type of the multiple connected PCIe devices, and send the first identifier bit and the second identifier bit to the firmware boot module, wherein N is a positive integer, and the first identifier bit and the second identifier bit are used to determine the bandwidth information of the PCIe port.

[0014] In an exemplary embodiment, the multi-board interconnect device is further configured to: detect the board model of the changed multiple boards when a change is detected in multiple boards connected to the multi-board interconnect device, and regenerate the board code according to the board model of the changed multiple boards; send the updated board code to the system initialization component to instruct the system initialization component to update the firmware version of the changed multiple boards according to the updated board code.

[0015] In one exemplary embodiment, the computing system further includes: a standby power rail, configured to provide power to the computing system when the computing system is in a power-off state, so that the multi-board interconnect device can identify the board models of the multiple boards and generate the multiple board sub-codes and the board code according to the board models of the boards at different levels.

[0016] This application also provides a firmware management method for a multi-board interconnect device, applied to the aforementioned multi-board interconnect computing system, comprising: dividing the multiple boards into multiple levels according to the board functions of the multiple boards connected to the multi-board interconnect device; generating multiple board sub-codes according to the board models included in the boards at different levels; generating a board code according to the multiple board sub-codes; determining the hardware configuration information of the multi-board interconnect device according to the board code; and performing firmware management on the multi-board interconnect device according to the hardware configuration information.

[0017] In an exemplary embodiment, determining the hardware configuration information of the multi-board interconnection device based on the board code, and performing firmware management on the multi-board interconnection device based on the hardware configuration information, includes: reading the board code from the multi-board interconnection device when the computing system starts up; determining the power-on sequence of the multiple boards based on the board code; and controlling the multiple boards to power on sequentially according to the power-on sequence.

[0018] In an exemplary embodiment, after the plurality of boards are powered on sequentially according to the power-on timing, the method further includes: matching the hardware configuration information in preset configuration data according to the board code, wherein the preset configuration data is used to indicate the mapping relationship between the plurality of board codes and the plurality of hardware configuration information; loading a target firmware version into the plurality of boards according to the hardware configuration information, wherein the target firmware version corresponds to the hardware configuration information.

[0019] In an exemplary embodiment, after the plurality of boards are powered on sequentially according to the power-on timing, the method further includes: monitoring the in-situ status and operating status of the plurality of boards according to the board code; and generating first abnormal information of the target board if the in-situ status or operating status of the target board is abnormal among the plurality of boards.

[0020] In an exemplary embodiment, after controlling the plurality of boards to power on sequentially according to the power-on timing, the method further includes: obtaining the hardware connection status and configuration information of the plurality of boards, and obtaining the version information of the target firmware version, wherein the power-on timing is determined according to the hardware connection status and the configuration information; and verifying the version information according to the hardware connection status and the configuration information.

[0021] In an exemplary embodiment, after verifying the version information based on the hardware connection status and the configuration information, the method further includes: if the version information fails verification, issuing a firmware update instruction to the firmware boot module to instruct the firmware boot module to reload the firmware to the plurality of boards.

[0022] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the firmware management method of any of the above-described multi-board interconnection devices when executing the computer program.

[0023] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the firmware management method for any of the above-described multi-board interconnection devices.

[0024] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the firmware management method for any of the above-described multi-board interconnection devices.

[0025] This application provides a multi-board interconnect computing system, including a multi-board interconnect device and a system initialization component. The multi-board interconnect device establishes connections with multiple boards, first dividing the boards into multiple levels according to their functions, then automatically generating board sub-codes based on the specific board models contained in different levels, and finally generating board codes. This coding is achieved by identifying the characteristics of different boards. The system initialization component connects to the multi-board interconnect device, determines the hardware configuration information of the multi-board interconnect device based on the board codes, and realizes firmware management of the multi-board interconnect device. Using the above system, boards are coded and managed according to their functions, and board configuration information is accurately identified based on the coding information, and firmware management is performed on the boards. This solves the problem in related technologies where a single board often applies to multiple configurations, but existing technologies struggle to distinguish between these multiple configurations and the different configuration settings resulting from different configurations, leading to difficulties in firmware management. Attached Figure Description

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

[0027] Figure 1 This is a hardware structure block diagram of a multi-board interconnected computing system according to an embodiment of this application;

[0028] Figure 2 This is a structural block diagram of a multi-board interconnected computing system according to an embodiment of this application;

[0029] Figure 3 This is a configuration block diagram of a SKU ID according to an embodiment of this application;

[0030] Figure 4 This is a flowchart illustrating the identification process of a SKU ID according to an embodiment of this application;

[0031] Figure 5 This is a schematic diagram of a PCIe X16 port structure according to an embodiment of this application;

[0032] Figure 6 This is a flowchart of a firmware management method for a multi-board interconnect device according to an embodiment of this application. Detailed Implementation

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

[0034] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0035] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0036] The specific application environment architecture or specific hardware architecture on which the firmware management method for multi-board interconnected devices depends is described here.

[0037] The methods and embodiments provided in this application can be executed in a multi-board interconnected computing system or a similar computing device. Taking a multi-board interconnected computing system as an example, Figure 1 This is a hardware structure block diagram of a multi-board interconnected computing system according to an embodiment of this application. Figure 1 As shown, a multi-board interconnected computing system may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The aforementioned multi-board interconnected computing system may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned multi-board interconnect computing system. For example, the multi-board interconnect computing system may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0038] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the operating system startup method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thus implementing the aforementioned method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0039] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for a multi-board interconnected computing system. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0040] This embodiment provides a computing system with interconnected multiple boards. Figure 2 This is a structural block diagram of a multi-board interconnected computing system according to an embodiment of this application, such as... Figure 2 As shown, the system includes:

[0041] The multi-board interconnection device 22 is connected to multiple boards 23 and is used to divide the multiple boards into multiple levels according to the board functions of the multiple boards, generate multiple board sub-codes according to the board models contained in the boards at different levels, and generate board codes according to the multiple board sub-codes.

[0042] It should be noted that multi-board interconnect devices refer to devices or systems in a computer system used to facilitate high-speed communication and data exchange between multiple functional boards. The core of such devices lies in their ability to effectively manage the interconnection between multiple boards (such as GPUs (Graphics Processing Units, microprocessors specifically designed to process graphics and image data), network interface cards, storage expansion cards, etc.), ensuring that they work together and improving the overall performance and efficiency of the system.

[0043] At the technical level, multi-board interconnect devices typically rely on high-speed network protocols such as PCI Express (PCIe), InfiniBand, and Ethernet to enable communication between boards. This involves not only physical connectors and slots, but also complex electrical design, signal integrity analysis, and the software and firmware used to configure, manage, and monitor these boards.

[0044] It's worth noting that multi-board interconnect devices are widely used in related technical fields, especially in high-performance computing (HPC), data centers, cloud computing, artificial intelligence (AI), and machine learning. This architecture, by distributing computing, storage, networking, and acceleration functions across multiple boards and enabling high-speed interconnection between them, can significantly improve the overall performance and flexibility of the system. Below are several specific application examples of multi-board interconnect devices to demonstrate the role of multi-board interconnect device systems in real-world scenarios:

[0045] 1. AI Servers: AI servers typically handle massive amounts of data and complex computational tasks, therefore they often employ multi-board interconnect architectures to enhance computing and data processing capabilities. For example, in the DGX system, multiple GPU boards are connected to the switch board (SW board) via high-speed interconnect technologies such as PCIe, enabling direct communication between GPUs and greatly improving the efficiency of parallel computing. Simultaneously, the storage board connects to the motherboard via PCIe, providing high-speed NVMe storage, while the network board is responsible for connecting to external networks, providing the necessary bandwidth.

[0046] 2. Hyperscale Data Centers: In hyperscale data centers, server clusters need to handle a large number of data communication and computing tasks. Multi-board interconnect devices can include network boards (such as 100G / 200G / 400G Ethernet cards), storage boards (such as NVMe-over-Fabrics storage expansion), and compute acceleration boards (such as FPGA or ASIC accelerators). These boards are interconnected with the motherboard and other servers via high-speed networks such as RDMA (Remote Direct Memory Access) to form a large-scale, high-efficiency computing and storage network.

[0047] 3. Cloud Computing Platform: Cloud computing platforms need to provide scalable computing and storage resources. Multi-board interconnect devices can include various types of boards, such as high-performance computing boards, elastic storage boards, and virtualized network boards. Servers in a cloud computing architecture can dynamically add or remove these boards, dynamically adjusting resource allocation according to tenant needs. This flexibility enables cloud service providers to respond quickly to changing computing demands while maintaining high efficiency and cost-effectiveness.

[0048] 4. HPC Clusters: In HPC (High-Performance Computing) clusters, multi-board interconnects are used to improve the processing speed of computationally intensive tasks. For example, an HPC system may contain multiple GPU-accelerated boards and high-performance network boards, interconnected via PCIe and high-speed networks such as InfiniBand or high-speed Ethernet, enabling efficient data transfer between computing nodes. This architecture delivers maximum computing performance with minimal latency, making it ideal for high-precision scientific computing applications such as large-scale simulations, weather forecasting, and genomics.

[0049] As can be seen from the examples above, multi-board interconnect devices can provide highly customized high-performance computing, storage, and networking resources in specific applications across different fields, meeting the needs of various complex scenarios. The advantages of this architecture lie in its flexibility, scalability, and efficient resource management, enabling system designers to flexibly configure and optimize hardware resources according to actual workloads and performance requirements.

[0050] It should be noted that, in this embodiment, the multi-board interconnect device, as the core of the multi-board interconnect computing system, not only provides high-performance computing resources and high-speed data transmission capabilities, but also possesses intelligent identification and configuration functions. It can parse the type information of each board, such as GPU accelerator cards, network interface cards, and storage expansion cards, and generate unique board codes. This encoding mechanism ensures that even with frequent interchange between boards, the system can quickly and accurately identify the type and function of each board.

[0051] In one optional embodiment, the boards connected to the multi-board interconnect device are divided into three levels: the first level boards are motherboards, the second level boards are main control chips such as switch boards, and the third level boards are the outermost boards, such as GPU boards.

[0052] It's important to note that the first-tier boards are the core of the entire system, containing major computing resources such as the CPU, BIOS, BMC, and memory slots. The SKU ID (Stock Keeping Unit Identifier, a code used to uniquely identify a specific product configuration) on the motherboard is typically reserved for future expansion; it has no current practical application, but it ensures sufficient flexibility to adapt to future configuration changes. The second-tier boards primarily handle data exchange, signal processing, or control logic tasks. For example, a switch board manages the routing and bandwidth allocation of high-speed interconnect signals such as PCIe. In AI systems, this might include dedicated chips like FPGAs and ASICs for accelerating data processing. The SKU IDs of the second-tier boards are used to distinguish different main control chip types or manufacturers. The third-tier boards are typically hardware directly geared towards specific functions or applications, such as GPU boards for graphics rendering and AI computing acceleration. The SKU IDs of these boards are used to distinguish expansion types or chassis height configurations.

[0053] It's important to note that categorized connectivity means that each board connects to the corresponding interface or bus based on its tier. In multi-board interconnect devices, each tier has a corresponding connection point, such as a PCIe slot or a SATA (Serial ATA, a computer bus interface standard) interface. Boards connect to the system through these points and communicate with other boards or system components. This design ensures both hardware configuration flexibility and maintains a clear and scalable system architecture, making it a key strategy for building complex systems.

[0054] The system initialization component 24 is connected to the multi-board interconnection device and is used to determine the hardware configuration information of the multi-board interconnection device according to the board code, and to perform firmware management on the multi-board interconnection device according to the hardware configuration information.

[0055] Through the above system, multi-board interconnection devices establish connections with multiple boards. First, the boards are categorized according to the multiple levels of the multi-board interconnection device. Then, board sub-codes are automatically generated based on the board model of different levels, and finally, a board code is generated. This code is achieved by identifying the characteristics of different boards. The system initialization component connects to the multi-board interconnection device and determines the hardware configuration information of the multi-board interconnection device based on the board code, realizing firmware management of the multi-board interconnection device. Using the above system, boards are coded and managed according to their functions. The coding information accurately identifies the board configuration information and performs firmware management, thus solving the problem in related technologies where a single board often applies to multiple configurations, but existing technologies struggle to distinguish between these multiple configurations and the different configuration settings resulting from different configurations, leading to difficulties in firmware management.

[0056] In one exemplary embodiment, the system initialization component includes a processor configured to: read the board code from the multi-board interconnect device when the computing system starts up; determine the power-on sequence of the plurality of boards according to the board code; and control the plurality of boards to power on sequentially according to the power-on sequence.

[0057] The system initialization components essentially include a processor (such as a Complex Programming Logic Device (CPLD)). After system startup, the processor immediately reads the board codes from the multi-board interconnect device, then analyzes the codes to determine the power-on sequence of multiple boards, ensuring orderly power supply. Based on the predetermined sequence, the processor precisely controls the sequential power-on of each board, achieving a smooth system startup.

[0058] It should be noted that the power-on sequence decision is based on the functional priority of the boards, their power requirements, and their dependencies on other hardware components. For example, the processor may prioritize starting the power management module, followed by the system main control board, and then the GPU accelerator card or network interface card with a heavier load. This ensures an orderly system startup, reduces the power load during startup, and improves the overall stability of the system.

[0059] It should be noted that the processor-controlled sequential power-on is achieved through direct or indirect methods. It may directly send control signals to the power management circuits of each board, or it may indirectly transmit commands through multi-board interconnect devices. Regardless of the method, the goal is to ensure that each board is powered at the appropriate time, avoiding unnecessary energy waste and reducing hardware risks during the boot process.

[0060] The implementation of this mechanism has significantly enhanced the stability and reliability of multi-board interconnect systems, providing a solid foundation for the computing system during the startup phase.

[0061] Optionally, the system initialization component includes a firmware boot module, configured to: read the board code from the multi-board interconnect device after the multiple boards have been powered on; match the hardware configuration information in preset configuration data according to the board code, wherein the preset configuration data is used to indicate the mapping relationship between the multiple board codes and the multiple hardware configuration information; and load a target firmware version into the multiple boards according to the hardware configuration information, wherein the target firmware version corresponds to the hardware configuration information.

[0062] The system initialization components also include a firmware boot module (BIOS, Basic Input Output System). After each board powers on, it immediately obtains the board code from the multi-board interconnect device. Subsequently, the module determines the hardware configuration information matching the board code based on the mapping relationship in the preset configuration data. Finally, based on this hardware configuration information, it accurately deploys the target firmware version to each board, ensuring that the version matches the hardware configuration.

[0063] It should be noted that the firmware boot module is responsible for loading and booting the firmware during system startup. The module first ensures that all boards have been powered on, and then accesses the board codes in the multi-board interconnect device. The code is essentially a series of numbers or letters, and each code corresponds to a unique identifier for a specific board in the system, containing key information such as the board model, function, and interface configuration.

[0064] It should be noted that the mapping data describes a one-to-one correspondence between the board code and the corresponding hardware configuration information, ensuring that the module can accurately identify the hardware requirements of each board. This mapping relationship may be stored in SPI memory, NVRAM (Non-Volatile Random Access Memory), or the internal database of the system initialization components for easy lookup and matching.

[0065] It should be noted that SPI memory, or Serial Peripheral Interface memory, refers to memory chips that communicate using a serial peripheral interface (SPI).

[0066] Loading the target firmware version is the final task of the firmware boot module. Based on the hardware configuration information, the module retrieves the matching firmware version from storage and loads it onto the corresponding board. The selection of the firmware version must ensure complete compatibility with the board's hardware characteristics to avoid system failures caused by version incompatibility or misconfiguration. The loading process may involve firmware data transfer, decompression, verification, and writing steps to ensure the firmware is deployed to the board without loss and correctly.

[0067] This embodiment significantly improves the flexibility and maintainability of multi-board interconnect systems through automated configuration and firmware version management, reducing the risk of errors during hardware updates or software maintenance. The intelligent decision-making of the firmware boot module ensures the accuracy and efficiency of the system startup process.

[0068] Optionally, the system initialization component includes a controller, configured to: read the board code from the multi-board interconnection device after the multiple boards have been powered on; monitor the presence and operation status of the multiple boards according to the board code; and generate first abnormal information for the target board if the presence or operation status of the target board is abnormal among the multiple boards.

[0069] In an optional embodiment, the system initialization component further includes a controller (BMC, Baseboard Management Controller). After ensuring all boards are powered on, the controller reads the board codes from the multi-board interconnect device. It then continuously monitors the presence and operational status of each board based on these codes, enabling real-time tracking of the hardware status. If an anomaly is detected in the presence or operational status of a specific board (i.e., the target board), the controller immediately generates anomaly information for rapid system fault identification and response.

[0070] It should be noted that the controller, as a crucial component of the system initialization system, is responsible not only for loading and guiding hardware configuration but also for monitoring and fault detection during system operation. In this embodiment, after system startup, the controller can identify and locate each board by reading the board codes in the multi-board interconnection device. The board code is a unique identifier used in the system to identify and distinguish various types of hardware, facilitating accurate monitoring of the boards.

[0071] It's important to note that the monitoring process involves the controller continuously monitoring the presence and operational status of each board to ensure the system hardware operates at the expected health level. The presence status reflects whether the board is correctly inserted and connected to the system, while the operational status involves the board's performance parameters, temperature, voltage, and current, used to assess whether the hardware is functioning properly. This monitoring mechanism provides the system with real-time hardware health reports, helping to prevent potential failures and ensuring stable system operation.

[0072] In summary, by reading the board code and continuously monitoring the hardware status, the controller constructs an intelligent and responsive system monitoring and fault detection platform, which greatly improves the reliability of the computing system and ensures hardware stability and data security under high-intensity computing tasks.

[0073] Optionally, the controller, connected to the firmware boot module and the processor, is further configured to: read the hardware connection status and configuration information of the plurality of boards from the processor, wherein the power-on sequence is determined based on the hardware connection status and the configuration information; read the version information of the target firmware version from the firmware boot module; and verify the version information based on the hardware connection status and the configuration information.

[0074] In this embodiment, the controller first reads the connection status and configuration details of the multiple boards from the processor to ensure that the power-on sequence matches the actual hardware situation. Next, the controller queries the firmware boot module for the target firmware version information, compares the hardware status with the configuration, verifies the appropriateness of the firmware version, and ensures the stability and security of the system operation.

[0075] It should be noted that the target firmware version information includes the firmware version number, compatibility list, feature description, and known issues. The controller reads this information and compares it with the hardware connection status and configuration information obtained from the processor to perform version verification. This process includes checking whether the firmware version supports the current hardware configuration, whether it matches the hardware performance, and whether there are any incompatibility issues with the current configuration, aiming to prevent system failures or performance degradation caused by improper firmware version selection.

[0076] Optionally, the controller is further configured to: send a firmware update instruction to the firmware boot module if the version information fails verification, wherein the firmware update instruction is used to instruct the firmware boot module to reload the firmware to the plurality of boards.

[0077] If the firmware version information fails to meet the verification standard, an update command is immediately sent to the firmware boot module, which instructs the module to reload the firmware to each board, ensuring a high degree of coordination between hardware and software.

[0078] It should be noted that the firmware update process involves multiple steps, including file transfer, decompression, integrity verification, writing to hardware, and reboot verification. Before updating the firmware, the module performs a comprehensive check on the new firmware version to ensure it is compatible with the board hardware and free of viruses or errors. During the update process, the module also monitors the board's power status to prevent firmware corruption or hardware failure caused by power outages during the update. After the update is complete, the system reboots, and the firmware boot module performs version verification again to ensure successful firmware update and normal hardware operation.

[0079] This mechanism demonstrates the crucial role of the controller in hardware and software management within multi-board interconnect systems. Through an automated firmware update process, the controller can promptly correct software configuration issues, eliminate hardware compatibility obstacles, and ensure the computing system maintains high efficiency and stability even in the face of hardware changes or new firmware versions. This is one of the key technologies in modern computing system design for achieving dynamic hardware configuration and seamless firmware upgrades.

[0080] Optionally, the controller is further configured to: monitor the operating data of multiple components of the computing system, wherein the multiple components include at least: the multi-board interconnect device, the processor, the firmware boot module, and the operating data includes at least one of the following: operating temperature, power supply voltage, and power status; and generate second abnormal information of the target component when abnormal operating data of a target component is detected among the multiple components.

[0081] In this embodiment, the controller also undertakes the task of data monitoring, closely monitoring the status of multiple components in the computing system, including multi-board interconnect devices, processors, firmware boot modules, etc. The monitored indicators include key data such as operating temperature, power supply voltage, and power status. If the operating data of any component, such as the target component, deviates from the normal range, abnormal information is immediately generated to prompt the system to pay attention to and repair potential fault points.

[0082] It's important to note that monitoring operational data is a crucial responsibility of the controller, ensuring the computing system's hardware components are in a healthy working state. The controller periodically collects and analyzes operational data from each component. For example, operating temperature reflects whether the hardware is overheating, supply voltage indicates the stability of the power supply, and power status provides information on the component's power supply status, including power-on, standby, and power-off states. This data is essential for assessing the real-time operating status of the hardware, predicting potential failure points, and maintaining overall system stability.

[0083] This monitoring mechanism demonstrates the controller's proactive monitoring and fault early warning capabilities during system operation, providing a fundamental guarantee for the long-term stable operation of the computing system. Through continuous data collection and analysis, the controller can proactively identify and address potential hardware problems, reducing system maintenance costs and improving system availability and user satisfaction.

[0084] Optionally, the multi-board interconnect device includes: a PCIe port connected to the firmware boot module for connecting a PCIe device to the multi-board interconnect device, wherein the multiple boards include the PCIe device.

[0085] Multi-board interconnect devices integrate PCIe ports and are directly linked to the firmware boot module. Their function is to provide access points for PCIe devices, enabling these devices to connect to the system's multi-board interconnect architecture, where the multiple boards that make up the system contain these PCIe devices.

[0086] It's important to note that PCIe ports, or Peripheral Component Interconnect Standard ports, are high-speed expansion bus interfaces in modern computer systems. They are widely used to connect various high-performance devices, such as graphics processors, network adapters, and storage controllers, to the motherboard. In server and AI systems, the high-speed data transmission capabilities of PCIe ports make them the preferred interface for connecting high-speed peripherals and accelerators, significantly improving overall system performance and meeting the demands of large-scale data processing and high-concurrency computing.

[0087] In this embodiment, the firmware boot module is directly connected to the PCIe port in the multi-board interconnect device, enabling it to directly read and configure the status and firmware of the PCIe device, thereby enhancing the system's management and control capabilities over the PCIe device.

[0088] In summary, the integration of PCIe ports into multi-board interconnect devices not only simplifies hardware connections but also directly facilitates interaction between the firmware boot module and the PCIe device, providing a solid foundation for system-level device management and firmware updates. This design is an indispensable part of building high-performance, highly reliable server and AI systems, contributing to improved system scalability and maintenance efficiency.

[0089] Optionally, the PCIe port includes N high-order ports and N low-order ports. The PCIe port is further configured to: determine the first identifier bit corresponding to the N high-order ports and the second identifier bit corresponding to the N low-order ports according to the number and type of the multiple connected PCIe devices, and send the first identifier bit and the second identifier bit to the firmware boot module, wherein N is a positive integer, and the first identifier bit and the second identifier bit are used to determine the bandwidth information of the PCIe port.

[0090] PCIe ports are divided into two types: high-order bits and low-order bits, totaling 2N bits, where N represents a positive integer. This design allows the port to flexibly adapt to different numbers and types of PCIe device connections. The port has an intelligent identification function, which can determine the first and second identifier bits based on the number and type of connected devices. These two identifier bits are then transmitted to the firmware boot module to clarify the PCIe port's bandwidth information, ensuring efficient communication and reasonable resource allocation between devices.

[0091] In this embodiment, the port is not limited to a traditional single signal path, but is innovatively divided into a high-order port and a low-order port, which together form a 2N-bit composite port. This design allows the port to automatically adjust the signal path according to the number and type of PCIe devices actually connected, realizing dynamic bandwidth allocation and meeting the different bandwidth requirements of different types of devices.

[0092] Optionally, the multi-board interconnect device is further configured to: detect the board model of the changed multiple boards when a change is detected in multiple boards connected to the multi-board interconnect device, and regenerate the board code according to the board model of the changed multiple boards; send the updated board code to the system initialization component to instruct the system initialization component to update the firmware version of the changed multiple boards according to the updated board code.

[0093] Multi-board interconnect devices possess dynamic monitoring and adaptation capabilities. Once a change in the connected board array is detected, the system immediately initiates a process to analyze the type of the newly connected component. Subsequently, based on the updated hardware configuration, the board coding system is reconstructed. After this dynamic coding update, the system automatically transmits the new coding to the system initialization component, guiding it to accurately match and update the firmware version of the corresponding board based on the latest coding information. This ensures that the firmware of all components within the system remains synchronized with the current hardware environment, optimizes overall performance, and reduces operational instability caused by firmware version mismatches.

[0094] The system initialization component, as the core control unit during server startup, is responsible for loading and configuring firmware to ensure that hardware components are initialized as expected. In this embodiment, it intelligently identifies the specific type and function of each board based on the dynamically updated board codes provided by the multi-board interconnection device, thereby loading the most suitable firmware version, completing the personalized initialization and configuration of hardware components, and improving the overall system response speed and processing efficiency.

[0095] This mechanism is particularly important in highly dynamic, high-load server environments, such as AI computing nodes or cloud computing data centers, where hardware configurations may be frequently adjusted to adapt to different computing tasks or load requirements. Through dynamic monitoring and real-time firmware updates, the system can seamlessly adapt to hardware changes, avoiding system restarts or performance degradation caused by configuration updates, and providing users with continuous and stable computing services.

[0096] Optionally, the computing system further includes: a standby power rail, used to provide power to the computing system when the computing system is in a power-off state, so that the multi-board interconnect device can identify the board models of the multiple boards and generate the multiple board sub-codes and the board code according to the board models of the boards at different levels.

[0097] The computing system integrates a key component called the standby power rail, which enables continuous power supply to critical components (such as multi-board interconnect devices) even when the system is powered off. This ensures that the multi-board interconnect devices can continuously identify the connected board types and then automatically generate detailed board sub-codes and comprehensive board codes based on the identified board models, laying the foundation for rapid initialization and firmware matching after the system is powered on.

[0098] A standby power rail, specifically, is a circuit designed to provide low-power power to specific, essential components in a system when the system is inactive or completely powered off. These components typically include memory storing system status information, clock circuitry, and control chips such as the Baseboard Management Controller (BMC) responsible for firmware management and hardware monitoring. In this embodiment, the standby power rail ensures that even when the server is completely powered down, multi-board interconnect devices can utilize this low-power power to continuously monitor and identify the board models connected to the system, providing accurate configuration information for subsequent system startup.

[0099] In situations where the system requires hot-swapping or frequent startup and shutdown within a short period, continuous power supply from the standby power rail allows multi-board interconnected devices to instantly identify board changes and generate corresponding codes without waiting for the system to fully power on. This accelerates firmware updates and system initialization, significantly improving server availability and response speed.

[0100] Obviously, the embodiments described above are only some embodiments of this application, and not all embodiments. To better understand the above method, the following description, in conjunction with embodiments, illustrates the process, but is not intended to limit the technical solutions of the embodiments of this application. Specifically:

[0101] In one optional embodiment, this application performs hierarchical management of the board according to its functional application. SKU_ID is defined as an 8-bit [0:7] data, and [5:7] is defined as the first-level board SKUID (i.e., board sub-code). In the default state, [0:7] are all pull-up in the first-level board and designed to be all 1s. The current motherboard segment SKU ID is RSV. [2:4] is defined as the second-level board SKU ID. This ID can be used to distinguish the main control chip type. According to the rules, the corresponding PIN can be pulled down. [0:1] is defined as the third-level board SKU ID, which can be used to distinguish the expansion type (such as GPU or UBB platform) or the chassis height configuration (6U or 4U).

[0102] While sending the board_ID and SKU ID to the CPLD, BIOS, and BMC through the I / O expander chip, BP_ID0 / ID1 is defined in each PCIeport, and pull-up and pull-down processing is performed according to rules in the downlink configuration. Combined with some BP (Board Presence) presence logic PINs, bandwidth allocation and silkscreen display are performed under different configurations.

[0103] The following combination Figure 3 A supplementary explanation of the structure of SKU_ID (i.e., the board code mentioned above) is provided, such as... Figure 3 As shown, Figure 3 The configuration block diagram for SKU_ID is shown below:

[0104] To facilitate identification of different model configurations, the motherboard (MB) adds an 8-bit SKU ID and connects it to the BMC, BIOS, and MB's CPLD respectively, so that different logic processing can be performed according to different model configurations.

[0105] 1. Based on the system hierarchy, the boards are divided into three levels;

[0106] 2. Each level is divided according to function, and one level may contain 1-2 motherboards;

[0107] 3. The first level is the motherboard. All ID pins are pulled up on the motherboard and connected to the BMC, BIOS and CPLD. The entry method is not limited to GPIO or through the I2C gpio expander chip.

[0108] 4. SKU ID[5:7] is used for RSV functionality on the motherboard, but it is not currently in practical application.

[0109] 5. The second level is mostly SW boards (Switch boards, mainly responsible for data routing and switching) or RT boards (Router boards, similar to switch boards, but more focused on network signal routing and processing) depending on the AI ​​model application, occupying [2:4] of the SKUID. This SKU ID is mainly used to distinguish the manufacturer type of the functional board to support the diverse needs of the current SW (Switch) chip and RT (Router) chip manufacturers.

[0110] 6. The third level is often the outermost board for multi-system interconnection. For AI models, the third-level SKU ID is mostly used to indicate the GPU board model. It can be used to identify the GPU BOX and UBB (Universal Baseboard, an OAM board defined by the OCP specification) BOX, as well as the product classification of different models.

[0111] 7. Furthermore, for UBB applications, a UBB SKU ID design can be added at the third level to identify different manufacturers' UBB and OAM (OCP Accelerator Module, a modular hardware standard designed to accelerate computing tasks) types.

[0112] Accordingly, based on Figure 3 In addition to the SKU ID encoding design shown, this application also provides an optional SKU ID identification process, such as... Figure 4 As shown, it includes the following steps:

[0113] 1. After the system is powered on, the BMC and CPLD begin reading the SKU ID;

[0114] 2. Combining the board ID, the CPLD performs power-on timing guidance for different SKU configurations;

[0115] 3. The BMC checks the configuration information under the obtained SKU ID against the read machine information and reports any abnormal information.

[0116] 4. The BIOS waits for the power-on signal. After receiving the power-on signal, it reads the SKU ID and boots and starts the system according to the configuration corresponding to that SKU ID.

[0117] According to another optional embodiment of this application, while sending the board_ID and SKU ID to the CPLD, BIOS and BMC through the I / O expander chip, BP_IDO / ID1 (i.e. the first and second identifier bits mentioned above) is defined in each PCIeport, and pull-up and pull-down processing is performed according to rules in the downlink configuration. Combined with some BP in-place logic PINs, bandwidth allocation and silkscreen display are performed under different configurations.

[0118] The following description uses a complete PCIe x16 port as an example to illustrate this embodiment. The specific implementation block diagram is as follows: Figure 5 As shown:

[0119] 1. Divide each PCIe x16 PORT into high 8 bits (equivalent to the above N high-bit ports, N is 8 in this embodiment) and low 8 bits (equivalent to the above N low-bit ports), and each group of X8 signals has two ID bits [0:1];

[0120] 2. On the motherboard side, each ID PIN is pulled down and then flipped through a MOS transistor before being connected to the CPU's I / O expander chip;

[0121] 3. In Default mode, the BP ID corresponding to each PCIe x16 PORT is 1111;

[0122] 4. Depending on the device type, there may be situations where an X16 device has X8 uplink and no downlink connection, X8 downlink and no uplink connection, or X8 configured as two X2 connections.

[0123] 5. There are also cases where the BIOS cannot recognize the device. For example, a PCIe x8 may be configured as both 2 NVMe BP and 2 NVMe M.2. In this case, it is necessary to add the corresponding device's in-situ ID to assist in identification and configuration.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0125] Embodiments of this application also provide a firmware management method for a multi-board interconnect device, applied to the aforementioned multi-board interconnect computing system. Figure 6 This is a firmware management method for a multi-board interconnect device according to an embodiment of this application, such as... Figure 6 As shown, the method includes the following steps:

[0126] Step S602: Divide the multiple boards into multiple levels according to the board functions of the multiple boards connected to the multi-board interconnection device, generate multiple board sub-codes according to the board models included in the boards of different levels, and generate board codes according to the multiple board sub-codes.

[0127] Step S604: Determine the hardware configuration information of the multi-board interconnection device according to the board code, and perform firmware management on the multi-board interconnection device according to the hardware configuration information.

[0128] Using the above methods, multi-board interconnection devices can automatically generate board codes for various types of connected boards. This coding is achieved by identifying the characteristics of different boards. Then, based on the board codes, the hardware configuration information of the multi-board interconnection device is determined, thereby realizing a precise firmware management strategy and optimizing the system's operating status. By adopting the above scheme, boards are coded and managed according to their functions. The board configuration information is accurately identified based on the coding information, and firmware management is performed on the boards. This solves the problem in related technologies where a single board is often used in multiple configurations, but existing technologies struggle to distinguish between these multiple configurations and the different configuration settings resulting from different configurations, leading to difficulties in firmware management.

[0129] Optionally, the hardware configuration information of the multi-board interconnection device is determined according to the board code, and firmware management of the multi-board interconnection device is performed according to the hardware configuration information, including: reading the board code from the multi-board interconnection device when the computing system starts; determining the power-on sequence of the multiple boards according to the board code; and controlling the multiple boards to power on sequentially according to the power-on sequence.

[0130] At the moment the computing system starts up, the board coding information of the multi-board interconnection device is read. This coding then determines the power-on sequence of each board in the entire system. Based on this, the system controls the boards to power on in sequence, ensuring the smooth and optimized hardware initialization process.

[0131] Server startup signifies the system waking from its silent state and entering the initialization process. At this stage, the board codes for multi-board interconnected devices become crucial. These codes, stored within the device, contain a comprehensive description of all connected boards. From these codes, the system can parse the type, quantity, and hierarchy information of each board. This process is undoubtedly the initial stage of the system's self-identification of its hardware configuration, providing a foundation for subsequent resource allocation and firmware management.

[0132] Power-on sequencing is a hardware initialization strategy based on board coding, specifying the power-on order of boards in a multi-board interconnected device. In complex systems, different boards may have different power and initialization requirements. A reasonable power-on sequence can avoid power conflicts during the power-on process and reduce the risk of hardware failure. For example, powering on the lower-level infrastructure boards, such as power management boards or network interface boards first, and then starting the upper-level compute-intensive GPU accelerator cards or storage devices, ensures the rational utilization of system resources and the orderly initialization of hardware.

[0133] The sequential power-on of control boards is part of the computing system's initialization firmware management. Relying on a power-on sequence strategy, the system, through firmware or BIOS programs, can precisely control the power state of each board in a predetermined order, ensuring a smooth transition of hardware components to operational status. This mechanism not only improves server startup efficiency but also reduces hardware compatibility issues caused by improper power-on sequence, thus ensuring system stability and security.

[0134] Optionally, after controlling the multiple boards to power on sequentially according to the power-on timing, the method further includes: matching the hardware configuration information in preset configuration data according to the board code, wherein the preset configuration data is used to indicate the mapping relationship between the multiple board codes and the multiple hardware configuration information; loading a target firmware version into the multiple boards according to the hardware configuration information, wherein the target firmware version corresponds to the hardware configuration information.

[0135] After controlling each board to start up according to the power-on sequence, the system takes further action. Based on the board code, it searches for matching hardware configuration information in the preset configuration data. Then, according to the configuration information, it accurately loads the target firmware version that is compatible with it to each board, ensuring perfect compatibility between the firmware and the hardware.

[0136] It should be noted that the preset configuration data records the correspondence between different board codes and their corresponding hardware configuration information. This dataset is typically pre-defined by the system designer or maintenance personnel to guide the server in quickly identifying and loading the correct firmware version based on the current hardware layout during startup. In the configuration data, the board code serves as an index, while the hardware configuration information details the board's function, type, quantity, and hierarchy, providing a basis for firmware loading decisions.

[0137] This embodiment demonstrates the intelligence and automation of firmware management in computing systems. By combining board coding with preset configuration data, the system can automatically identify the current hardware environment and load the most suitable firmware version, reducing the need for manual intervention and improving the efficiency of system startup and configuration. This mechanism is particularly important in AI servers and high-performance computing platforms, allowing the system to flexibly respond to changing hardware configurations and ensuring that the correct firmware version is launched under any configuration, maximizing the utilization of hardware resources and meeting the needs of high-performance computing.

[0138] Optionally, after the multiple boards are powered on sequentially according to the power-on timing, the method further includes: monitoring the presence and operation status of the multiple boards according to the board code; and generating first abnormal information of the target board if the presence or operation status of the target board is abnormal among the multiple boards.

[0139] After each control board starts up according to the power-on sequence, the system continues to operate, using the board code to monitor the status of these boards in real time, covering their presence and operational performance; if the status of any board deviates from normal, the system immediately generates an anomaly report, specifically marking the problematic board, which facilitates quick location and repair.

[0140] It's important to note that board coding is not merely an indicator of hardware configuration at startup; it's crucial for the system to monitor hardware status in real time. Through coding, the system can track the actual location (presence) and operational status (running status) of each board—whether a compute card, storage card, or network interface card. This functionality is vital for maintaining stable server operation, especially in large-scale AI cluster environments, enabling the immediate detection and reporting of any hardware issues that may impact performance or security.

[0141] Optionally, after controlling the multiple boards to power on sequentially according to the power-on sequence, the method further includes: obtaining the hardware connection status and configuration information of the multiple boards, and obtaining the version information of the target firmware version, wherein the power-on sequence is determined according to the hardware connection status and the configuration information; and verifying the version information according to the hardware connection status and the configuration information.

[0142] After controlling each board to start up according to the power-on sequence, the system further obtains the hardware connection status, configuration details, and the version information of the currently loaded firmware. Based on the collected hardware status and configuration data, the system verifies the firmware version information to ensure that the hardware and firmware versions match correctly.

[0143] It's important to note that hardware connection status refers to the actual connection status of each board within the server. It clarifies the physical connection status between boards and between boards and the motherboard, including whether they are connected, the type of connection (e.g., PCIe, SATA), and the stability of the connection. This information is crucial for firmware configuration during system initialization, guiding the firmware on how to correctly identify and interact with hardware resources, avoiding initialization failures or performance issues caused by connection problems.

[0144] Optionally, after verifying the version information based on the hardware connection status and the configuration information, the method further includes: if the version information fails verification, issuing a firmware update instruction to the firmware boot module to instruct the firmware boot module to reload the firmware to the plurality of boards.

[0145] After the version information verification fails, the system immediately takes action, sending an update command to the firmware boot module to instruct it to reload the firmware to each board, ensuring the matching of hardware and firmware versions and the stable operation of the system.

[0146] This embodiment enables the system to automatically monitor and update firmware versions, reducing the need for manual intervention and improving the level of automated server management and maintenance. In large-scale cluster and cloud environments, this mechanism significantly reduces system downtime caused by firmware version issues, improves operational efficiency, and is of great significance for ensuring business continuity and user data security.

[0147] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the firmware management method for a multi-board interconnect device.

[0148] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the firmware management method for multi-board interconnection devices at runtime.

[0149] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0150] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the firmware management method embodiments of the multi-board interconnection device described above.

[0151] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the firmware management method embodiments of the multi-board interconnect device described above.

[0152] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0153] The firmware management method for a multi-board interconnected computing system and a multi-board interconnected device provided in this application has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A computing system with interconnected multi-board cards, characterized in that, include: A multi-board interconnection device, connected to multiple boards, is used to divide the multiple boards into multiple levels according to their board functions, generate multiple board sub-codes according to the board models contained in the boards at different levels, and generate a board code based on the multiple board sub-codes. The system initialization component is connected to the multi-board interconnection device and is used to determine the hardware configuration information of the multi-board interconnection device according to the board code, and to perform firmware management on the multi-board interconnection device according to the hardware configuration information.

2. The computing system with multi-board interconnection according to claim 1, characterized in that, The system initialization component, including a processor, is used for: When the computing system starts up, the board code is read from the multi-board interconnect device; The power-on sequence of the plurality of boards is determined according to the board code; The multiple boards are powered on sequentially according to the power-on sequence.

3. The computing system with multi-board interconnection according to claim 2, characterized in that, The system initialization component, including a firmware boot module, is used for: After the multiple boards have been powered on, the board code is read from the multi-board interconnect device; The hardware configuration information is matched with the board code in the preset configuration data, wherein the preset configuration data is used to indicate the mapping relationship between multiple board codes and multiple hardware configuration information; The target firmware version is loaded into the plurality of boards according to the hardware configuration information, wherein the target firmware version corresponds to the hardware configuration information.

4. The computing system with multi-board interconnection according to claim 3, characterized in that, The system initialization component, including a controller, is used for: After the multiple boards have been powered on, the board code is read from the multi-board interconnect device; Monitor the presence and operation status of the multiple boards according to the board codes; If the target board has an abnormal presence or operation status among the multiple boards, the first abnormality information of the target board is generated.

5. The computing system with multi-board interconnection according to claim 4, characterized in that, The controller, connected to the firmware boot module and the processor, is further configured to: The processor reads the hardware connection status and configuration information of the plurality of boards, wherein the power-on sequence is determined based on the hardware connection status and the configuration information; Read the version information of the target firmware version from the firmware boot module; The version information is verified based on the hardware connection status and the configuration information.

6. The computing system with multi-board interconnection according to claim 5, characterized in that, The controller is also used for: If the version information fails verification, a firmware update command is sent to the firmware boot module, wherein the firmware update command is used to instruct the firmware boot module to reload the firmware to the multiple boards.

7. The computing system with multi-board interconnection according to claim 4, characterized in that, The controller is also used for: The operation data of multiple components of the computing system is monitored, wherein the multiple components include at least: the multi-board interconnect device, the processor, and the firmware boot module, and the operation data includes at least one of the following: operating temperature, power supply voltage, and power status; If abnormal operation data of the target component is detected among the multiple components, a second abnormality information of the target component is generated.

8. The computing system with multi-board interconnection according to claim 3, characterized in that, The multi-board interconnection device includes: A PCIe port, connected to the firmware boot module, is used to connect a PCIe device to the multi-board interconnect device, wherein the multiple boards include the PCIe device.

9. The computing system with multi-board interconnection according to claim 8, characterized in that, The PCIe port includes N high-order ports and N low-order ports. The PCIe port is also used to: determine the first identifier bit corresponding to the N high-order ports and the second identifier bit corresponding to the N low-order ports according to the number and type of the multiple connected PCIe devices, and send the first identifier bit and the second identifier bit to the firmware boot module, wherein N is a positive integer, and the first identifier bit and the second identifier bit are used to determine the bandwidth information of the PCIe port.

10. The computing system with multi-board interconnection according to claim 1, characterized in that, The multi-board interconnection device is also used for: If changes are detected in multiple boards connected to the multi-board interconnect device, the board model of the changed multiple boards is detected, and the board code is regenerated based on the board model of the changed multiple boards. The updated board code is sent to the system initialization component to instruct the system initialization component to update the firmware version of the changed multiple boards according to the updated board code.

11. The computing system with multi-board interconnection according to claim 1, characterized in that, The computing system also includes: The standby power rail is used to provide power to the computing system when the computing system is in a power-off state, so that the multi-board interconnect device can identify the board models of the multiple boards and generate the multiple board sub-codes and the board code according to the board models of the boards at different levels.

12. A firmware management method for a multi-board interconnection device, characterized in that, A computing system for multi-board interconnection as described in any one of claims 1 to 11, comprising: The multiple boards connected to the multi-board interconnect device are divided into multiple levels according to their board functions. Multiple board sub-codes are generated according to the board models contained in the boards at different levels, and a board code is generated according to the multiple board sub-codes. The hardware configuration information of the multi-board interconnection device is determined based on the board code, and firmware management is performed on the multi-board interconnection device based on the hardware configuration information.

13. The firmware management method for a multi-board interconnection device according to claim 12, characterized in that, The hardware configuration information of the multi-board interconnection device is determined based on the board code, and firmware management of the multi-board interconnection device is performed based on the hardware configuration information, including: When the computing system starts up, the board code is read from the multi-board interconnect device; The power-on sequence of the plurality of boards is determined according to the board code; The multiple boards are powered on sequentially according to the power-on sequence.

14. The firmware management method for a multi-board interconnection device according to claim 13, characterized in that, After controlling the multiple boards to power on sequentially according to the power-on timing, the method further includes: The hardware configuration information is matched with the board code in the preset configuration data, wherein the preset configuration data is used to indicate the mapping relationship between multiple board codes and multiple hardware configuration information; The target firmware version is loaded into the plurality of boards according to the hardware configuration information, wherein the target firmware version corresponds to the hardware configuration information.

15. The firmware management method for a multi-board interconnection device according to claim 13, characterized in that, After controlling the multiple boards to power on sequentially according to the power-on timing, the method further includes: Monitor the presence and operation status of the multiple boards according to the board codes; If the target board has an abnormal presence or operation status among the multiple boards, the first abnormality information of the target board is generated.

16. The firmware management method for a multi-board interconnection device according to claim 15, characterized in that, After controlling the multiple boards to power on sequentially according to the power-on timing, the method further includes: The hardware connection status and configuration information of the multiple boards are obtained, as well as the version information of the target firmware version, wherein the power-on sequence is determined based on the hardware connection status and the configuration information; The version information is verified based on the hardware connection status and the configuration information.

17. The firmware management method for a multi-board interconnection device according to claim 16, characterized in that, After verifying the version information based on the hardware connection status and the configuration information, the method further includes: If the version information fails verification, a firmware update command is sent to the firmware boot module to instruct the firmware boot module to reload the firmware to the multiple boards.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 12 to 17.

19. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as claimed in any one of claims 12 to 17.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 12 to 17.

Images