A firmware upgrade method, system and electronic device

Abstract

The application discloses a firmware upgrading method, system and electronic equipment, and relates to the technical field of server management.The compressed packages of all firmware to be upgraded are integrated and packaged at one time, and then the upgrading files in the firmware upgrading package are automatically distributed according to firmware topological relations and then sent to corresponding firmware to be upgraded.Through the newly-added firmware topological relations, the specific distribution firmware of the upgrading files can be automatically identified, the hardware signals can be automatically distinguished and identified, and the upgrading efficiency is improved.Further, the firmware versions are upgraded based on the firmware coupling relations and the upgrading files, the updated versions of all firmware are correctly adapted, the abnormal functions and the communication interruption among the firmware are effectively prevented, and the technical effects of improving the stability and reliability of the system are achieved.

Description

Technical Field

[0001] This application relates to the field of server management technology, and in particular to a firmware upgrade method, system, and electronic device. Background Technology

[0002] During the firmware upgrade process of the rack server, the firmware of compute nodes, resource nodes, and local area network (LAN) nodes is upgraded in an unordered manner, with each firmware being uploaded and upgraded independently. As a result, some firmware is flashed and the system restarts directly, but other firmware that has a coupling relationship with this firmware, such as dependency and power-on / off, has not yet been adapted and updated. This causes the system to malfunction due to firmware version mismatch, and the communication between firmware is interrupted, which in turn causes the flashing and upgrading of other firmware to fail, reducing the stability and reliability of the system. Summary of the Invention

[0003] This application provides a firmware upgrade method, system, and electronic device to at least solve the problems in the related art where firmware upgrades in rack servers are carried out in an unordered and independent manner, resulting in version mismatch, functional abnormalities, and communication interruptions between firmware.

[0004] This application provides a firmware upgrade method, including: Obtain firmware upgrade package, firmware topology, and firmware coupling relationships; The upgrade files within the firmware upgrade package are distributed according to the firmware topology to the storage area corresponding to the firmware to be upgraded. The firmware version is upgraded based on the coupling upgrade sequence of the firmware coupling relationship and the upgrade files within the firmware to be upgraded.

[0005] This application also provides a server system, including a master node and a controlled node; wherein the master node is connected to the controlled node; The master control node is used to execute the steps of the firmware upgrade method described above.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above firmware upgrade methods.

[0007] This application addresses the issues of version mismatch, functional abnormalities, and communication interruptions between firmware due to the unordered and independent firmware upgrades used in rack servers. First, it obtains a firmware upgrade package. Compared to the inefficient conventional method of uploading and upgrading firmware files one by one, this application directly integrates and packages all compressed files of the firmware to be upgraded into a single firmware upgrade package, improving operational efficiency. The firmware topology records the hardware topology mapping between all firmware components under all nodes in the entire server system, including address information and logical dependencies, facilitating the distribution of upgrade files from the firmware upgrade package to the corresponding firmware to be upgraded. The firmware coupling records the master-slave relationships of runtime control and execution, resource allocation and initialization bindings, and power-on / off sequences among all firmware components under all nodes in the entire server, ensuring that the upgrade order is considered during the upgrade process to improve system stability. Second, based on the firmware topology, the upgrade files within the firmware upgrade package are distributed to the corresponding storage areas of the firmware to be upgraded. By leveraging newly added firmware topology relationships, the specific firmware to be distributed in the upgrade file is automatically identified, enabling automated differentiation and recognition of hardware signals and improving upgrade efficiency. Finally, based on the coupled upgrade order of firmware coupling relationships and the upgrade file within the firmware to be upgraded, the upgrade process is performed. Compared to the conventional independent upgrade method, this application considers the existence of multiple firmware components within the same node, where power-on timing dependencies or power-on / off coupling relationships exist. Therefore, by following the coupled upgrade order, it effectively avoids waste and logical conflicts caused by repetitive operations, effectively solves timing errors caused by disordered upgrades, ensures correct adaptation of all firmware update versions, effectively prevents functional abnormalities and communication interruptions between firmware, thereby improving system stability and reliability.

[0008] Therefore, this method can solve the technical problems caused by disordered and independent firmware upgrades within rack servers, which lead to version mismatches, functional abnormalities, and communication interruptions between firmware components. It achieves this by consolidating and packaging all firmware files to be upgraded into a single package, and then automatically distributing the upgrade files within the package based on the firmware topology. This process identifies hardware signals and improves upgrade efficiency. Furthermore, it upgrades firmware versions based on firmware coupling relationships and upgrade files, ensuring correct adaptation of all firmware updates, effectively preventing functional abnormalities and communication interruptions between firmware components, thereby improving system stability and reliability. Attached Figure Description

[0009] 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.

[0010] Figure 1 This application provides a schematic diagram of the architecture of a server system. Figure 2 A flowchart illustrating a firmware upgrade method provided in this application embodiment; Figure 3 A flowchart illustrating the processes of a management controller within a computing node, provided as an embodiment of this application; Figure 4 A flowchart illustrating the monitoring status during a firmware upgrade process, provided as an embodiment of this application; Figure 5 This is a structural diagram of a firmware upgrade device provided in an embodiment of this application. Detailed Implementation

[0011] 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.

[0012] 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.

[0013] 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.

[0014] The specific application environment architecture or specific hardware architecture on which the firmware upgrade method depends is described here.

[0015] Figure 1 This application provides a schematic diagram of the architecture of a server system, as shown in the embodiments. Figure 1As shown, a baseboard management controller is deployed on a single server motherboard, which is responsible for the server's northbound management, various out-of-band management, and compute node health monitoring; a rack management controller located in a rack (containing several servers) is responsible for the comprehensive management of the nodes in the rack, including power supply, heat dissipation, and assets. Figure 1 The master control node in a system can be a compute node. Controlled nodes can be resource nodes, LAN nodes, etc. Generally, the firmware managing the northbound traffic of a compute node is called a Baseboard Management Controller (BMC), while rack-mounted nodes are called Rack Management Controllers (RMC) or Chassis Management Controllers (CMC), etc. Figure 1 There is one compute node, multiple resource nodes, and multiple LAN nodes. Externally, the compute node appears as a BMC (Browser Control Center), therefore all inputs and outputs are from the BMC. The compute node requires firmware upgrades for management controllers (such as the BMC), Basic Input Output System (BIOS), Complex Programmable Logic Device (CPLD), Peripheral Component Interconnect Express (PCIe) (and other related hardware). Resource nodes require firmware upgrades for microcontroller units (MCUs) (or Micro Management Controllers (MMCs) and similar hardware), CPLDs, PCIe, etc. LAN nodes also require upgrades for MCUs, CPLDs, PCIe, etc. For these three node types, different firmware versions are needed for the same type of firmware on different nodes depending on the different hardware logic.

[0016] In such complex systems, various firmware versions exist, such as BMC firmware, BIOS firmware, CPLD firmware, and PCIe firmware. These form the foundation of hardware functionality, and their security, stability, and performance are crucial, requiring regular vulnerability patching, feature updates, and performance optimization. However, given the complex environment of distributed management controllers, firmware upgrades face numerous difficulties and challenges.

[0017] In conventional firmware upgrade solutions, maintenance personnel need to prepare upgrade packages for different types of firmware, such as BMC, RMC, BIOS, and CPLD, and manually upload and upgrade them machine by machine and layer by layer. This method is time-consuming and labor-intensive, and depends heavily on the maintenance personnel's familiarity with the machine's hardware topology, making it prone to errors.

[0018] More importantly, firmware distributed across different nodes (such as compute nodes, resource nodes, and LAN nodes) may have coupling relationships such as functional dependencies, version compatibility, or power-on / off timing. For example, there may be a binding between BIOS and PCIe, or between CPLD and BMC. Without such upgrade connections, the BMC might reboot immediately after firmware flashing, leaving the CPLD un-flashed. This would result in numerous functional anomalies after reboot. If a new BMC is then used to flash the CPLD for an upgrade, communication interruptions and version incompatibility would occur, preventing the CPLD from being flashed and upgraded. The firmware upgrade method provided in this application solves the above technical problems.

[0019] Figure 2 A flowchart of a firmware upgrade method provided in this application embodiment is shown below. Figure 2 As shown, applied to the master node, the method includes: S11: Obtain firmware upgrade package, firmware topology, and firmware coupling relationships; S12: Distribute the upgrade files in the firmware upgrade package according to the firmware topology to the storage area corresponding to the firmware to be upgraded. S13: Based on the firmware coupling relationship, the coupling upgrade sequence and the upgrade files in the firmware to be upgraded are used to upgrade the version of the firmware to be upgraded.

[0020] Specifically, obtaining the firmware upgrade package in step S11 requires responding to the user's firmware upgrade request. The user packages the firmware to be upgraded using a common compression tool. This compressed package may contain one or more firmware image files for different models and levels of controllers. Compared to the conventional approach that only upgrades the current firmware, this embodiment packages all firmware to be upgraded, effectively avoiding the need to upload upgrade files for each subsequent upgrade.

[0021] The packaged compressed file is encrypted using Hybrid Proxy Multisignature (HPM) or other vendor-provided keys. The key (or encryption algorithm) information includes, but is not limited to, vendor and product model information, and is used for the security and uniqueness of the package. The decryption key (or encryption algorithm) resides in the compute node's BMC program. This package is an encrypted compressed file containing image files of all firmware required for this upgrade.

[0022] Master node, that is Figure 1 The compute node's Base Control Center (BMC) provides a user interface (not limited to web interface, Redfish, or Intelligent Platform Management Interface (IPMI), etc., commonly used by BMCs) to transmit the integration package to the BMC's storage space via Ethernet or other links. This storage space can be the embedded Multi Media Card (eMMC) space within the compute board, or an external Secure Digital (SD) card. The BMC of each compute node initializes this area before power-on. Simultaneously, the BMC of the compute node (master node) pre-stores and maintains the firmware topology and coupling relationships of its host server system. When the user uploads the firmware upgrade package through the BMC's web interface, the BMC begins executing this method.

[0023] The firmware topology records the hardware topology mapping relationships between all firmware components contained in all nodes (such as compute nodes, resource nodes, LAN nodes, etc.) within the entire server system, including the board part number, version identifier, and communication address information (such as Internet Protocol (IP) address) for each firmware component. The firmware coupling relationship records the coupling sequence between all firmware components, including runtime dependencies, resource allocation, initialization binding, and power-on / off timing.

[0024] The BMC distributes upgrade files within the firmware upgrade package based on the firmware topology. Specifically, the BMC parses the filename of each upgrade file within the package, extracting information such as the target board part number and the target firmware name. Then, it searches for matching nodes and firmware within the firmware topology and, based on their communication address information, accurately distributes the upgrade files to the storage area corresponding to the node to which the firmware to be upgraded belongs. Within the firmware topology, different firmware to be upgraded are identified based on newly added hardware component identifiers to automatically determine whether the image file is for the compute node BMC, BIOS, etc., or for other nodes such as the MCU, CPLD, and PCIe. The main focus here is to verify that the upgrade file corresponds to the correct hardware; as long as the hardware is not changed, the corresponding hardware board part number remains unchanged. After the compute node BMC powers on, it can also determine the corresponding network address and its logical dependency based on the firmware topology.

[0025] The BMC, based on the coupling upgrade order defined by the firmware coupling relationship (e.g., upgrading all controlled nodes first, and then upgrading the compute node itself last; or within a node, upgrading the CPLD first, then the PCIe, and finally the BMC), coordinates with the firmware to be upgraded on each node to perform the version upgrade operation using the received upgrade files. The firmware coupling relationship here records the master-slave relationship of runtime control and execution, resource allocation binding relationship, and power-on / off sequence between firmware components. This relationship is used to determine the upgrade order and prevent system crashes caused by firmware version mismatches.

[0026] It's important to note that firmware upgrades may involve partial upgrades. These partial upgrades can occur within a single node type or across multiple node types. Regardless of the method, they are performed according to the coupled upgrade sequence. If multiple node types exist, the firmware upgrades within each node type are processed in parallel. For example, if two resource nodes have no dependencies, each resource node can perform its own firmware upgrade to improve efficiency. If there is one resource node and one compute node, the resource node can be upgraded first, followed by the compute node. Alternatively, the firmware can be upgraded synchronously within both nodes. In this case, the synchronous upgrade follows the coupled upgrade sequence within each node, except that the management controller of the compute node is initially reserved until all other firmware upgrades are completed. This sequence helps manage dependencies and isolate faults.

[0027] In this embodiment, the unordered and independent firmware upgrades within the rack server lead to version mismatches, functional abnormalities, and communication interruptions between firmware. First, a firmware upgrade package is obtained. Compared to the inefficient conventional method of uploading and upgrading firmware files one by one, this application directly integrates and packages all compressed files of the firmware to be upgraded into a single firmware upgrade package, improving operational efficiency. The firmware topology records the hardware topology mapping between all firmware components under all nodes in the entire server system, including address information and logical dependencies, facilitating the distribution of upgrade files from the firmware upgrade package to the corresponding firmware to be upgraded. The firmware coupling relationship records the master-slave relationship of runtime control and execution, resource allocation and initialization binding relationships, and power-on / off sequence relationships between all firmware components under all nodes in the entire server, ensuring that the upgrade order is considered during the upgrade process to improve system stability. Second, the upgrade files within the firmware upgrade package are distributed according to the firmware topology, and sent to the corresponding storage area of ​​the firmware to be upgraded. By leveraging newly added firmware topology relationships, the specific firmware to be distributed in the upgrade file is automatically identified, enabling automated differentiation and recognition of hardware signals and improving upgrade efficiency. Finally, based on the coupled upgrade order of firmware coupling relationships and the upgrade file within the firmware to be upgraded, the upgrade process is performed. Compared to the conventional independent upgrade method, this application considers the existence of multiple firmware components within the same node, where power-on timing dependencies or power-on / off coupling relationships exist. Therefore, by following the coupled upgrade order, it effectively avoids waste and logical conflicts caused by repetitive operations, effectively solves timing errors caused by disordered upgrades, ensures correct adaptation of all firmware update versions, effectively prevents functional abnormalities and communication interruptions between firmware, thereby improving system stability and reliability.

[0028] Therefore, this method can solve the technical problems caused by disordered and independent firmware upgrades within rack servers, which lead to version mismatches, functional abnormalities, and communication interruptions between firmware components. It achieves this by consolidating and packaging all firmware files to be upgraded into a single package, and then automatically distributing the upgrade files within the package based on the firmware topology. This process identifies hardware signals and improves upgrade efficiency. Furthermore, it upgrades firmware versions based on firmware coupling relationships and upgrade files, ensuring correct adaptation of all firmware updates, effectively preventing functional abnormalities and communication interruptions between firmware components, thereby improving system stability and reliability.

[0029] In some embodiments, the upgrade files within the firmware upgrade package are distributed according to the firmware topology to the storage area corresponding to the firmware to be upgraded, including: Obtain the board part number, version identifier, and communication address information corresponding to the firmware topology; Within the firmware upgrade package, the upgrade file is identified and processed based on the board part number information to obtain the corresponding target node; Within the target node, the upgrade file is identified and processed based on the existing target firmware to be upgraded and version identification information to obtain the target upgrade file corresponding to the target firmware to be upgraded on the target node. Based on the communication address information, the target upgrade file is distributed to the corresponding storage area of ​​the target firmware to be upgraded.

[0030] Specifically, the firmware topology is obtained. This topology is a data structure containing the board part number information (e.g., PN13373, PN03601), version identifier information (e.g., D1.0.2, E1.0.2), and communication address information (e.g., 192.168.0.100) for each upgradable firmware. Table 1 shows the firmware topology table. As shown in Table 1, three segments of information are identified in the name of the firmware to be upgraded. The first segment is the individual components, the second segment is the board part number information, which indicates which node it belongs to, and the third segment, E1.0.2, is the stage + version number. E, D, and P represent stages in the engineering process, such as Engineering Verification Test (EVT), Design Verification Plan (DVP), and Production Verification Test (PVT). Some firmware does not need to be upgraded every time, so there may be cases where the compute node is DVT, but the resource node only uses the EVT motherboard. .bin and .jed are different image formats. The naming convention is to list the component first (though part number followed by component can also be used). This firmware naming provides a clear overview of the current motherboard and component status. The internal process involves first identifying the part number and then transmitting all firmware for the corresponding node. Each node then performs the appropriate upgrade based on the component and version number. Here, PNxxxx represents the board's part number; one board can be considered a node IP address, so PNxxxx represents all images corresponding to the same IP address that need to be upgraded.

[0031] Table 1 Firmware Topology Relationship Table

[0032] Based on the identified target upgrade file, the BMC compares and queries the topology mapping. The BMC communicates with the corresponding MCU via IP (not limited to this method). The BMC identifies the part number information and distributes the corresponding firmware image file to the storage area of ​​the target node through a local area network, VLAN, or dedicated management network within the machine, based on the image matching the corresponding node IP.

[0033] The main steps are as follows: 1. Traverse all decompressed upgrade files within the firmware upgrade package. For each file, such as MCU-PN03601-E1.0.2.bin, the image processing module parses its filename and extracts the board part number PN03601. Then, it searches for all entries with the board part number PN03601 in the firmware topology, thus determining that the target node for this upgrade file is resource node 1. 2. After determining that the target node is resource node 1, the BMC further obtains the list of firmware to be upgraded on that node (for example, there are actually three firmwares on this node: MCU, CPLD, and PCIe). Then, the image processing module parses the filename again and extracts the version identification information MCU and E1.0.2. By matching the MCU with the list of firmware to be upgraded on resource node 1, it is confirmed that this file is used to upgrade the MCU firmware on this node. Combined with the version number, it is finally determined that MCU-PN03601-E1.0.2.bin is the target upgrade file corresponding to the target firmware (MCU) to be upgraded on the target node (resource node 1). Similarly, the file CPLD-PN03601-E1.0.jed will be identified as the target upgrade file for the CPLD on resource node 1. 3. The communication address of the MCU on resource node 1 is known to be 192.168.0.101. Subsequently, the BMC sends the target upgrade file (MCU-PN03601-E1.0.2.bin) as a data stream to the designated storage area of ​​the device with IP address 192.168.0.101 (i.e., the MCU of resource node 1) via the management network.

[0034] The distribution process provided in this embodiment first identifies the board part number to ensure that the upgrade file is not mistakenly sent to a node with a mismatched hardware model, effectively avoiding flashing failures or device damage caused by firmware incompatibility with the hardware. Then, it identifies the target firmware to be upgraded using version identification information and existing firmware, ensuring that each upgrade file can find its unique corresponding firmware within the same node, effectively avoiding file mismatches. Based on accurate distribution using communication address information, the entire process is automated and intelligent, improving the accuracy and efficiency of distribution.

[0035] In some embodiments, the upgrade process is performed based on the firmware coupling relationship, the upgrade order, and the upgrade files within the firmware to be upgraded, including: Obtain the target node type corresponding to the target node where the firmware to be upgraded is located; Obtain the target coupled upgrade order of the firmware to be upgraded on the target node, corresponding to the coupled upgrade order. The firmware version to be upgraded is processed according to the target coupling upgrade order, target node type, and upgrade file.

[0036] Specifically, there are multiple firmware files to be upgraded. These multiple firmware files may reside on the same node or on multiple nodes. Therefore, we first determine the target node type: whether it contains only the master node, only the controlled nodes, or both. Based on the different target nodes, we determine the corresponding coupling upgrade order and then upgrade the firmware version accordingly.

[0037] If it's only a master node or a controlled node, then the version upgrade needs to be performed according to the corresponding target coupling upgrade order within each node. If both of these node types are included, then in addition to performing the version upgrade according to the corresponding target coupling upgrade order within each node, the master node's management controller must be kept unupgraded from beginning to end. The management controller should only be upgraded after all other firmware upgrades are completed.

[0038] The different target node types provided in this embodiment can identify the different strategies of the master node and the controlled node in the upgrade process. Furthermore, it can optimize the target coupling upgrade order within each node, realize serial upgrades within the node, and also consider the dependency relationship between the master node and the controlled node, thereby improving firmware upgrade efficiency.

[0039] In some embodiments, the upgrade process is performed on the version of the firmware to be upgraded according to the target coupling upgrade order, target node type, and upgrade file, including: When the target node type is a controlled node and the number of target nodes is greater than one, obtain the target coupling upgrade order corresponding to each target node; Within their respective target nodes, each node performs parallel upgrades on the firmware version to be upgraded according to its corresponding target coupling upgrade sequence and upgrade file.

[0040] Specifically, for scenarios with multiple controlled nodes, such as Figure 1 As shown, it is assumed that the target node has multiple resource nodes and multiple LAN nodes, that is, the number of controlled nodes is greater than one.

[0041] Based on the firmware coupling relationship, firmware upgrades between these controlled nodes are independent of each other (for example, a failed MCU upgrade on resource node 1 will not affect the CPLD upgrade on the LAN node). Therefore, the BMC (master node) will adopt a parallel upgrade strategy.

[0042] BMC first obtains the target coupling upgrade order within each controlled node (Resource Node 1, Resource Node 2, ..., LAN Node). For example: Resource Node 1: CPLD-PCIe-MCU; Resource Node 2: CPLD-PCIe-MCU; LAN Node: CPLD-PCIe-MCU.

[0043] Then, the BMC simultaneously sends an upgrade start command to the controllers (such as MCUs) of all controlled nodes. Upon receiving the command, each controlled node's MCU independently and in parallel begins upgrading its internal firmware according to its own sequence and the received upgrade files. For example, while resource node 1's MCU is upgrading its CPLD, resource node 2's MCU is also upgrading its CPLD, and the LAN node's MCU is also upgrading its CPLD. These upgrade processes overlap and run in parallel.

[0044] This embodiment provides a method for parallel upgrade processing of multiple target nodes when there are only controlled nodes. The overall upgrade time depends on the longest serial upgrade time within a single node, rather than the number of nodes, thus shortening the upgrade time and improving upgrade efficiency.

[0045] In some embodiments, the upgrade process is performed on the version of the firmware to be upgraded according to the target coupling upgrade order, target node type, and upgrade file, including: When the target node type is a controlled node and a master node, and the number of controlled nodes is greater than one, obtain the first target coupling upgrade order corresponding to each target node; Retain the unupgraded version of the management controller within the master node; Within their respective target nodes, each node performs parallel upgrades on the firmware version to be upgraded according to its corresponding first target coupling upgrade order and corresponding upgrade files. After the firmware to be upgraded in the controlled node is completed, the firmware version of the management controller is upgraded according to the upgrade file of the management controller.

[0046] Specifically, for scenarios where there are both master control nodes and multiple controlled nodes, limiting the firmware upgrade timing of the master control node, such as the management controller, is key to implementing a bottom-up, north-to-south strategy.

[0047] Based on the above embodiments, the system has one master control node and N controlled nodes, such as resource nodes and LAN nodes. The BMC, acting as the management controller of the master control node, first obtains the first target coupling upgrade order within all controlled nodes (e.g., CPLD-PCIe-MCU) and its own order within the master control node (e.g., CPLD-PCIe-BIOS-BMC). The logic of the first target coupling upgrade order within each target node is identical. Then, it retains its own (management controller's) un-upgraded version, i.e., it does not perform the BMC firmware upgrade operation for the time being. The old version of the firmware program still runs in the BMC's memory. Next, the BMC sends instructions to all controlled nodes to upgrade in parallel according to their respective first target coupling upgrade orders. During the upgrade process, the BMC remains online, monitoring the progress of each node through a heartbeat mechanism. For example, the BMC continuously receives status reports from the MCU of resource node 1, such as CPLD upgrade complete, PCIe upgrade, etc. Finally, after confirming that the firmware to be upgraded within all controlled nodes has been completed (e.g., receiving upgrade completion messages from all nodes), the BMC will begin executing the upgrade process of the master control node's BMC. In other words, only after all controlled nodes have completed their upgrades, and after other firmware such as CPLD, PCIe, and BIOS on the compute nodes have been successfully upgraded, will the BMC call the pre-distributed BMC upgrade file (such as BMC-PN13373-D1.0.2.bin) to upgrade its own firmware version.

[0048] This embodiment provides an upgrade method that places the management controller upgrade of the master node at the end of the entire process. If the northbound firmware (such as BIOS) upgrade fails, causing a blue screen in the compute node's operating system, the administrator can still use the BMC, which has not yet been upgraded and is still online, to log in to the server to troubleshoot the problem. This bottom-up order conforms to hardware dependency logic, with the underlying hardware (such as CPLD) preparing the new operating environment first, and the upper-layer software (such as BMC) adapting last. This reduces the risk of communication protocol errors due to version incompatibility and enhances the reliability of the upgrade process.

[0049] In some embodiments, the process of determining the target coupling upgrade order includes: Obtain the power-on timing parameters of the hardware components corresponding to the firmware to be upgraded within the same node; The startup sequence of hardware components during the node power-on process is determined based on the power-on timing parameters; The target coupling upgrade order is generated based on the startup order; in the target coupling upgrade order, the firmware with an earlier startup time has a higher upgrade priority than the firmware with a later startup time.

[0050] Specifically, the target coupling upgrade sequence is not arbitrarily set, but rather based on the physical characteristics of the hardware, arranged from north to south. During the system implementation phase, the power-on timing parameters of each hardware component on each node are determined. Taking the compute node as an example, its detailed power-on sequence is as follows: T0: The entire machine is connected to power, and the management controller powers on first. T1: After the BMC starts up, it powers on the CPLD via GPIO control. T2: After the CPLD starts up, it begins to generate the various voltage rails required by the board level and powers on PCIe devices, memory, PCH, etc., in sequence. T3: Under the control of the CPLD, the PCIe devices complete initialization. T4: The PCH powers on and releases the CPU's reset signal. T5: The CPU begins to read BIOS code from the SPI Flash and executes it.

[0051] Based on the principle that hardware booting earlier in the sequence has a fundamental role in the operation of other hardware and should therefore be upgraded first, the system automatically analyzes these parameters to generate the target coupling upgrade order. That is, although the BMC boots earliest, it has the highest upgrade risk and is the management core, so its priority is set to the lowest, meaning it's upgraded last. The CPLD boots at time T2 and is the power manager for all other hardware (except the BMC), so it has the highest priority. PCIe devices complete initialization at time T3 and are the bus foundation, so their priority is next. The BIOS is loaded at time T5 and depends on the normal operation of the CPLD and PCIe, so its priority is after them. Ultimately, the default target coupling upgrade order generated by the system for the compute node is: CPLD, PCIe, BIOS, BMC. In this order, the CPLD, with its earlier boot sequence, has the highest upgrade priority, while the BMC, with its later boot sequence, has the lowest upgrade priority.

[0052] The upgrade order determination process provided in this embodiment is based on objective data such as the hardware power-on timing parameters, and applies the rule that upgrades are prioritized for earlier startup sequences, thereby automatically generating the target coupling upgrade order. This ensures that the upgrade order is strictly consistent with the physical startup logic of the hardware, effectively avoiding functional abnormalities caused by timing errors. Moreover, when the hardware design changes (such as replacing it with a different model of CPLD), the upgrade order can be automatically updated without manual configuration modifications, improving the system's adaptability.

[0053] In some embodiments, the method further includes: During the upgrade process, the status of the node where the firmware to be upgraded is located is monitored and processed according to preset time intervals. If the firmware to be upgraded reports an upgrade error, the rollback mechanism will be triggered to roll back the firmware version to the version before the upgrade.

[0054] Specifically, upgrades are performed independently on each node, with notifications displayed on the web interface via a unified reporting mechanism to the compute node's BMC. Before the upgrade begins, images are verified sequentially. During the upgrade process, the upgrade progress of each controller is monitored in real time via heartbeats or periodic status reports, such as "Uploading," "Verifying," "Flashing," and "Completed." If any firmware fails at a critical stage, such as upload failure, verification failure, or flashing timeout, and reports a failure, its corresponding BMC / MCU immediately interrupts the upgrade process and triggers a rollback mechanism to revert to a previously unupgraded firmware version.

[0055] This embodiment provides a status monitoring system throughout the entire firmware upgrade process, allowing real-time monitoring of the upgrade progress of each firmware version and immediate detection of any problems. The rollback mechanism effectively prevents devices from becoming bricked or malfunctioning due to firmware flashing failures. When upgrade problems occur, no manual intervention or complex recovery operations are required; the system automatically reverts to a known, stable, and functional state, greatly reducing upgrade risks, ensuring the consistency of the entire management plane is not disrupted, and guaranteeing business continuity.

[0056] In some embodiments, the process of determining the rollback mechanism includes: Retrieve the un-upgraded version stored on the local node where the firmware to be upgraded is located; and roll back the firmware version to the un-upgraded version on the local node. Alternatively, in response to a rollback request issued by the management controller, the firmware version to be upgraded is rolled back to the un-upgraded version recorded in the management controller according to the rollback request.

[0057] Specifically, a dedicated rollback partition for backups is allocated in the storage medium of each node (whether it is a master node or a controlled node). Before initiating any firmware upgrade, the node automatically copies a copy of the currently running, stable firmware image into this rollback partition.

[0058] Taking the failed PCIe firmware upgrade of the LAN node as an example, before the upgrade begins, the LAN node's MCU has already backed up the current old PCIe firmware (such as V1.0) to the local rollback partition. When the upgrade to the new PCIe firmware (such as V2.0) fails, the LAN node's MCU does not require any external commands; it automatically reads the V1.0 firmware image from the local rollback partition and performs the flashing operation to complete the rollback.

[0059] Alternatively, the management controller (BMC) can initiate a coordinated rollback request. The BMC broadcasts a special rollback instruction to all relevant nodes, including both successful and failed upgrades, containing the target version number to which the node is expected to roll back. This version number is stored in the BMC's version database, i.e., the un-upgraded version recorded within the management controller. Upon receiving this coordinated rollback request, each node retrieves the firmware for that version from the storage location specified by the BMC or its own backup area, based on the version number in the request, and performs the rollback operation. In this way, all nodes within the entire system ultimately roll back to the same globally consistent un-upgraded version.

[0060] The two rollback mechanisms provided in this embodiment are: local rollback, which is fast, independent of the network and master node, and suitable for handling local, non-critical failures of a single node, enabling rapid recovery; and collaborative rollback, which ensures global version consistency throughout the distributed system.

[0061] In some embodiments, the method further includes: If the firmware to be upgraded is the firmware corresponding to the management controller of the main control node, and the other firmware has not been upgraded, and the firmware to be upgraded is abnormal, then the upgrade process will be interrupted. If the firmware to be upgraded is the first target firmware other than the management controller, and the firmware upgrade is abnormal, then the first target firmware is skipped and the remaining firmware other than the management controller and the first target firmware is selected for upgrade processing.

[0062] Specifically, the master control node (BMC) itself was being upgraded. The BMC began flashing its firmware, but an anomaly occurred during the flashing process (e.g., power outage, image corruption). Since the firmware of other nodes, such as the controlled nodes and other compute nodes, had not been upgraded previously, and the BMC, as the central controller, would cause the entire management system to crash if the upgrade failed, the upgrade process was proactively interrupted.

[0063] If an upgrade anomaly occurs while the firmware is being upgraded to the primary target firmware, the management controller will not interrupt the entire upgrade process. Instead, it will log the failure of the primary target firmware upgrade, skip the problematic primary target firmware, and continue upgrading the remaining firmware. For example, the BMC will continue to instruct the upgrade of the BIOS firmware on the compute nodes and notify other controlled nodes to continue their upgrade tasks.

[0064] When different firmware upgrades fail as described in this embodiment, it is necessary to distinguish the importance of the firmware and implement a refined exception handling strategy to ensure system security while also improving upgrade efficiency and success rate.

[0065] In some embodiments, if the number of error messages reported by the firmware to be upgraded during the firmware upgrade process exceeds a first preset number, the method further includes: The frequency with which the process receiving feedback error information is located; If the frequency exceeds the first preset level, it is determined that there is an anomaly in the firmware upgrade package; Determine the target process in which the abnormal information corresponds to a frequency greater than the first preset level; Determine the abnormal upgrade file based on the target process within the firmware upgrade package; Replace the faulty upgrade file with a new upgrade file, and repackage it into a firmware upgrade package before uploading it to the server system.

[0066] Specifically, suppose that during a firmware upgrade involving 100 nodes, 25 nodes report upgrade anomalies. This number (25) is greater than a first preset number (e.g., preset to 20). A typical solution might roll back each node one by one, but this embodiment will initiate root cause analysis.

[0067] The frequency of anomalies in each process was calculated. For example, in the CPLD flashing process, anomaly number 21 accounted for 84% of all anomalies 25, far exceeding the first preset level (such as the preset level of 50%). Therefore, BMC determined that the problem was not caused by hardware failure of individual nodes, but rather by a systemic anomaly in the entire firmware upgrade package.

[0068] Next, BMC determined that the process with the most concentrated abnormal information was the CPLD flashing process. Then, within the firmware upgrade package, BMC traced back to the files related to the CPLD flashing process, namely the CPLD image files of all nodes (such as CPLD-PN13373-D1.0.jed, CPLD-PN03601-E1.0.jed, etc.), thus confirming that these CPLD image files were the abnormal upgrade files.

[0069] Ultimately, BMC can display a message on the web interface: "Batch upgrade failed. Reason: The CPLD image in the package is incompatible with the hardware. Please replace the faulty upgrade file in the attachment with the correct version and repackage and upload." Following the prompts, the user replaces all CPLD images, regenerates the package, and uploads it again, resolving the issue.

[0070] This embodiment provides a proactive approach to locating abnormal upgrade files. Conventional methods involve checking each file individually, which is time-consuming and labor-intensive. This embodiment locates abnormal upgrade files by determining the process distribution and frequency of abnormal information. This shortens troubleshooting time and improves operational efficiency in batch upgrade scenarios.

[0071] In some embodiments, if the number of error messages reported by the firmware to be upgraded during the firmware upgrade process exceeds a first preset number, the method further includes: Obtain the process priority and the process in which the feedback error information is located during the firmware upgrade process; If the process priority of the process containing the exception information meets the first priority, then the exception upgrade file is determined based on the target process containing the process that meets the first priority. Replace the faulty upgrade file with a new upgrade file, and repackage it into a firmware upgrade package before uploading it to the server system.

[0072] Specifically, assume that 25 nodes report anomalies. The total number of anomalies, 25, is greater than the first preset number of 20. However, the anomalies are relatively scattered, and no single process has a frequency that significantly exceeds 50% (log processes account for 60%, but may be ignored due to their low priority; communication processes account for 32%).

[0073] The system retrieves the preset priorities of all processes. Inter-node communication processes have the highest priority. Non-critical logging processes do not have the highest priority. Since the process priorities corresponding to the eight exceptions occurring in the inter-node communication process meet the highest priority, it is determined that although the number of exceptions in this process is not the highest, its severity is the highest, and it will be addressed first. Therefore, the system ignores the exceptions of non-critical processes and directly locates the target process and associated files causing the exception based on this high-priority inter-node communication process, thereby determining the escalation file for the exception.

[0074] Ultimately, BMC prompted the user that the upgrade had failed due to an abnormality in the core communication process. Following the instructions, the user replaced the old upgrade file with a new one, regenerated the package, and uploaded it again, resolving the issue.

[0075] In this embodiment, when multiple anomalies occur, conventional solutions might prioritize frequently occurring but potentially non-critical issues based on the majority rule. This embodiment, by introducing process priorities, ensures that even if high-priority processes have a small number of anomalies, the system can still detect them and use them as anomaly upgrade files, thus guaranteeing system stability and security.

[0076] In some embodiments, before distributing the upgrade files within the firmware upgrade package according to the firmware topology, the method further includes: The firmware upgrade package is encrypted before being uploaded to the user interface to obtain an encrypted firmware upgrade package. Obtain the decryption key used to decrypt the firmware upgrade package; If the encrypted firmware upgrade package is successfully decrypted using the decryption key, the process proceeds to the step of distributing the upgrade files within the firmware upgrade package according to the firmware topology. If the decryption of the encrypted firmware upgrade package fails using the decryption key, an error message will be output, and the process will return to the step of obtaining the firmware upgrade package.

[0077] Specifically, regarding the verification of the firmware package's legitimacy, on the user side, when generating the firmware upgrade package, the user must encrypt the compressed package using a specific tool and key that matches the server. For example, using the HPM tool and the product key provided by the manufacturer, the folder containing all firmware can be packaged and encrypted into a .hpm or .enc file. This encrypted file is the encrypted firmware upgrade package.

[0078] When a user uploads the file through BMC's web interface, BMC's background process first stores the file in a temporary buffer. Then, BMC reads a pre-set decryption key from its firmware security area. This key is programmed at the factory and is paired with the encryption key. BMC then calls the decryption algorithm and uses the decryption key to attempt to decrypt the uploaded encrypted package.

[0079] If the decryption process completes successfully and the file structure within the compressed package can be correctly identified, it indicates that the package's source is trustworthy and its content is complete. At this point, BMC confirms the verification has passed and proceeds to the subsequent distribution processing steps. If an error occurs during the decryption process, such as a key mismatch, incorrect file format, or unsupported decompression algorithm, it indicates that the package may belong to another device model, have been tampered with, or be corrupted. In this case, BMC will not continue any further operations. Upon receiving feedback, BMC will clear the temporary buffer and return to the state of waiting for the user to upload a new file, i.e., returning to the step of obtaining the firmware upgrade package from the server system.

[0080] The firmware package validation provided in this embodiment ensures upgrade security from the source. It effectively prevents hardware damage caused by using firmware from the wrong device model, improving the supply and operational security of the server system.

[0081] In some embodiments, after distributing the upgrade file to the storage area corresponding to the firmware to be upgraded, and before the upgrade process, the method further includes: Perform integrity verification on the upgrade files of the firmware to be upgraded; If the integrity verification passes, the process proceeds to the steps of upgrading the firmware version based on the firmware coupling relationship and the upgrade files within the firmware to be upgraded.

[0082] Specifically, the integrity verification of the upgrade file primarily prevents errors that occur during data transmission. The algorithm used for integrity verification is not limited; it can be the same as or different from the algorithm used in conventional solutions. For example, when distributing the file, the BMC will include a checksum for that file, such as a Message Digest 5 (MD5) value or a Cyclic Redundancy Check 32-bit (CRC32) value. After receiving the complete file, the MCU of resource node 1 uses the same algorithm to calculate a real-time checksum for the received file content. The MCU then compares this real-time calculated checksum with the original checksum provided by the BMC. If the verification passes, the subsequent upgrade process proceeds; if the verification fails, the upgrade process is interrupted.

[0083] The integrity verification of the upgrade file provided in this embodiment ensures the reliability of the transmission process from BMC to each controlled node.

[0084] In some embodiments, when communication between the firmware upgrade package and the server system is interrupted, the method further includes: Obtain the first sub-firmware upgrade package that has been uploaded to the server system; wherein, the firmware upgrade package is uploaded during the upload process by unpacking at least one sub-firmware upgrade package; The second sub-firmware upgrade package that was not uploaded was determined based on the first sub-firmware upgrade package; Once communication is normal, the second sub-firmware upgrade package is re-uploaded to the server system according to the unpacking sequence.

[0085] Specifically, when uploading a firmware upgrade package (such as a 200MB encrypted compressed file), BMC's web server supports Hypertext Transfer Protocol (HTTP) chunked upload or similar fragmentation technology. The user's client (the user's browser) will split this large file into at least one sub-firmware upgrade package (i.e., fragments, such as fragment 1, fragment 2, ..., fragment 40) according to a preset fragment size (such as 5MB per fragment), and upload them sequentially.

[0086] Suppose the network suddenly interrupts transmission of fragment 20. BMC's web server has successfully received and stored fragments 1 through 19 (i.e., the first sub-firmware upgrade package), but fragments 20 through 40 (i.e., the second sub-firmware upgrade package) have not yet been uploaded. BMC will record the received fragment indices.

[0087] Once network communication is restored, the user clicks the "Continue Upload" button. At this point, BMC determines the missing fragments (20-40) based on the recorded fragment indices (1-19). Then, BMC sends a resume command to the client, instructing the client to start uploading only from fragment 20. The client re-uploads fragments 20 to 40 one by one, following the original unpacking order. After receiving all fragments, BMC reassembles these sub-firmware upgrade packages in sequence, restoring them to a complete firmware upgrade package, before performing subsequent decryption and decompression operations.

[0088] This embodiment introduces a segmented upload and breakpoint resume mechanism, ensuring that only a few lost segments are retransmitted after a network interruption, rather than the entire file. This improves the upload success rate of large firmware packages and shortens the effective transmission time.

[0089] 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.

[0090] Figure 3 A flowchart illustrating the processes of a management controller within a computing node, as provided in this application embodiment, is shown below. Figure 3 As shown, within the compute node, users upload firmware upgrade packages to different programs within the management controller. After verification, these packages are stored in the storage module, then decrypted, decompressed, parsed, and distributed as an image. This image is then distributed to other firmware within the compute node for upgrades, and to firmware on other nodes for upgrades as well. Distribution to other nodes is achieved through communication methods such as local area networks (LANs), virtual local area networks (VLANs), or dedicated management networks.

[0091] Figure 4 This application provides a flowchart illustrating the monitoring status during a firmware upgrade process, as shown in the embodiments of the present application. Figure 4 As shown, the steps are as follows: On the user side: S21: Packaging and encryption to generate firmware upgrade package; S22: Upload firmware upgrade package; On the compute node side: S23: Initialization work for power-on, topology mapping relationship, and upgrade process.

[0092] S24: Determine whether the firmware upgrade package is trustworthy. If it is trustworthy, proceed to step S25; if it is not trustworthy, proceed to step S26. S25: Storage decryption; S26: Output an error message; On the user side: S27: Confirm repackaging.

[0093] On the compute node side: S28: Determine if decryption was successful. If successful, proceed to step S29; otherwise, proceed to step S30. S29: Decompression and analysis; S30: Output error message.

[0094] S31: Determine if the parsing was successful. If successful, proceed to step S32; otherwise, proceed to step S33. S32: Microcontroller unit for distributing node images to other nodes; S33: Output error message.

[0095] The microcontrollers of other nodes perform step S34 before being distributed to the controllers of other nodes: S34: Initialization of power-on and upgrade processes.

[0096] After the controllers are distributed to other nodes, proceed to step S35: S35: Determine if the image file is complete. If it is complete, proceed to step S36; otherwise, proceed to step S37. S36: Determine whether the upgrade was successful. If successful, proceed to step S38; otherwise, proceed to step S39. S37: Initiate a retransmission of the command to the management controller; S38: Indicates successful image file upgrade; S39: Roll back to the version before the upgrade; S40: Determine whether the rollback was successful. If successful, proceed to step S41; otherwise, proceed to step S42. S41: Notify the user that the rollback was successful; S42: Prompt the user to indicate that the rollback failed; On the compute node side: At this time, other firmware inside the management controller also needs to upgrade its own image file, proceeding to step S43; S43: Determine if the upgrade was successful. If successful, proceed to step S44; otherwise, proceed to step S45. S44: The image file upgrade was successful.

[0097] S45: Roll back to the version before the upgrade; S46: Determine whether the rollback was successful. If successful, proceed to step S47; otherwise, proceed to step S48. S47: Notify the user that the rollback was successful; S48: Prompt the user to indicate that the rollback failed.

[0098] Furthermore, embodiments of this application also provide a firmware upgrade device. Figure 5 A structural diagram of a firmware upgrade device provided in an embodiment of this application is shown below. Figure 5 As shown, the device includes: Module 11 is used to acquire firmware upgrade package, firmware topology and firmware coupling relationship; The distribution processing module 12 is used to distribute the upgrade files in the firmware upgrade package according to the firmware topology relationship, so as to distribute them to the storage area corresponding to the firmware to be upgraded. The upgrade processing module 13 is used to upgrade the firmware version based on the firmware coupling relationship, the coupling upgrade sequence, and the upgrade files in the firmware to be upgraded.

[0099] For a description of the features in the corresponding embodiment of the device, please refer to the relevant description of the corresponding embodiment of the firmware upgrade method, which will not be repeated here.

[0100] Embodiments of this application also provide a server system, including a master node and a controlled node; wherein the master node is connected to the controlled node; The master node is used to execute the steps of the firmware upgrade method described above.

[0101] It should be noted that, in Figure 1 In this system, the master node is the computing node, and the controlled nodes are the resource nodes and the LAN nodes.

[0102] 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 firmware upgrade method embodiments described above.

[0103] 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 firmware upgrade method embodiments described above when running.

[0104] 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 drive, magnetic disk, or optical disk.

[0105] 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 upgrade method embodiments described above.

[0106] 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 upgrade method embodiments described above.

[0107] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-chip (SoC), a CPLD, an MCU, etc. The terms "system," "computing device," or "apparatus" used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also known as a program, software, software application, application (App), script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0108] 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.

[0109] The firmware upgrade method, system, and electronic device provided in this application have 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 for the purpose of helping to understand the method and its core ideas. 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 scope of protection.

Claims

1. A firmware upgrade method, characterized in that, Applied to the master node, including: The firmware upgrade package, firmware topology, and firmware coupling relationships are obtained. The firmware upgrade package is obtained by integrating and packaging all compressed files of the firmware to be upgraded. The firmware topology records the hardware topology mapping relationship between all firmware components contained under all nodes in the entire server system, recording the address information and logical dependencies of all firmware. Different firmware to be upgraded are identified based on the hardware new component identifier within the firmware topology to automatically identify the storage area corresponding to the image file. The firmware coupling relationship refers to the power-on timing dependency or power-on / off coupling relationship among multiple firmware components. The upgrade files within the firmware upgrade package are distributed according to the firmware topology to the storage area corresponding to the firmware to be upgraded. Specifically, this includes: obtaining the board part number, version identifier, and communication address information corresponding to the firmware topology; identifying the upgrade files within the firmware upgrade package based on the board part number information to obtain the corresponding target node; identifying the upgrade files within the target node based on the existing target firmware to be upgraded and the version identifier information to obtain the target upgrade file corresponding to the target firmware to be upgraded on the target node; and distributing the target upgrade file to the corresponding storage area corresponding to the target firmware to be upgraded based on the communication address information. The firmware version is upgraded based on the coupling upgrade sequence of the firmware coupling relationship and the upgrade files within the firmware to be upgraded.

2. The firmware upgrade method according to claim 1, characterized in that, The upgrade process for the firmware to be upgraded is performed based on the coupling upgrade sequence of the firmware coupling relationship and the upgrade files within the firmware to be upgraded, including: Obtain the target node type corresponding to the target node where the firmware to be upgraded is located; Obtain the target coupling upgrade order of the firmware to be upgraded on the target node, corresponding to the coupling upgrade order; The firmware version to be upgraded is upgraded according to the target coupling upgrade sequence, the target node type, and the upgrade file.

3. The firmware upgrade method according to claim 2, characterized in that, The firmware version to be upgraded is upgraded according to the target coupling upgrade order, the target node type, and the upgrade file, including: When the target node type is a controlled node and the number of target nodes is greater than one, the target coupling upgrade order corresponding to each target node is obtained; Within their respective target nodes, each node performs parallel upgrades on the firmware version to be upgraded according to its corresponding target coupling upgrade sequence and upgrade file.

4. The firmware upgrade method according to claim 2, characterized in that, The firmware version to be upgraded is upgraded according to the target coupling upgrade order, the target node type, and the upgrade file, including: When the target node type is a controlled node and a master node, and the number of controlled nodes is greater than one, the first target coupling upgrade order corresponding to each target node is obtained; Retain the unupgraded version of the management controller within the master node; Within their respective target nodes, each node performs parallel upgrades on the firmware version to be upgraded according to its corresponding first target coupling upgrade order and corresponding upgrade files. After the firmware to be upgraded in the controlled node is upgraded, the firmware version of the management controller is upgraded according to the upgrade file of the management controller.

5. The firmware upgrade method according to claim 3 or 4, characterized in that, The process of determining the target coupling upgrade sequence includes: Obtain the power-on timing parameters of the hardware components corresponding to the firmware to be upgraded within the same node; The startup sequence of hardware components during the node power-on process is determined based on the power-on timing parameters. A target coupling upgrade order is generated based on the startup order; wherein, in the target coupling upgrade order, the firmware with an earlier startup time has a higher upgrade priority than the firmware with a later startup time.

6. The firmware upgrade method according to claim 1, characterized in that, The method further includes: During the upgrade process, the status of the node where the firmware to be upgraded is located is monitored and processed according to preset time intervals. If the firmware to be upgraded reports an upgrade error, a rollback mechanism is triggered to roll back the firmware version to the version before the upgrade.

7. The firmware upgrade method according to claim 6, characterized in that, The process of determining the rollback mechanism includes: Obtain the un-upgraded version stored in the local node where the firmware to be upgraded is located; and roll back the firmware version to the un-upgraded version in the local node; Alternatively, in response to a rollback request issued by the management controller, the version of the firmware to be upgraded is rolled back to the un-upgraded version recorded in the management controller according to the rollback request.

8. The firmware upgrade method according to claim 4, characterized in that, The method further includes: If the firmware to be upgraded is the firmware corresponding to the management controller of the main control node, and the other firmware has not been upgraded, and the firmware to be upgraded is abnormal, then the upgrade process is interrupted. If the firmware to be upgraded is the first target firmware other than the management controller, and the firmware upgrade is abnormal, then the first target firmware is skipped and the remaining firmware other than the management controller and the first target firmware is selected for upgrade processing.

9. The firmware upgrade method according to claim 6, characterized in that, If the number of error messages reported by the firmware to be upgraded during the firmware upgrade process exceeds a first preset number, the method further includes: The frequency with which the process receiving feedback error information is located; If the frequency exceeds a first preset level, then it is determined that the firmware upgrade package is abnormal. Determine the target process in which the abnormal information corresponds to a frequency level greater than a first preset level; Within the firmware upgrade package, an abnormal upgrade file is determined based on the target process; The abnormal upgrade file is replaced with a new upgrade file, and then repackaged within the firmware upgrade package before being uploaded to the server system.

10. The firmware upgrade method according to claim 6, characterized in that, If the number of error messages reported by the firmware to be upgraded during the firmware upgrade process exceeds a first preset number, the method further includes: Obtain the process priority and the process in which the feedback error information is located during the firmware upgrade process; If the process priority corresponding to the process where the abnormal information is located meets the first priority, then the abnormal upgrade file is determined according to the target process where the process priority that meets the first priority is located. The abnormal upgrade file is replaced with a new upgrade file, and then repackaged within the firmware upgrade package before being uploaded to the server system.

11. The firmware upgrade method according to claim 1, characterized in that, Before distributing the upgrade files within the firmware upgrade package according to the firmware topology, the process further includes: The firmware upgrade package is encrypted before being uploaded to the user interface to obtain the encrypted firmware upgrade package. Obtain the decryption key used to decrypt the firmware upgrade package; If the encrypted firmware upgrade package is successfully decrypted using the decryption key, the process proceeds to the step of distributing the upgrade files within the firmware upgrade package according to the firmware topology. If the decryption of the encrypted firmware upgrade package fails using the decryption key, an error message is output, and the process returns to the step of obtaining the firmware upgrade package.

12. The firmware upgrade method according to any one of claims 2 to 4, characterized in that, After distributing the upgrade files to the storage area corresponding to the firmware to be upgraded, the process before upgrade processing also includes: The integrity verification process is performed on the upgrade file of the firmware to be upgraded; If the integrity verification passes, the process proceeds to the step of upgrading the firmware version based on the coupling upgrade sequence according to the firmware coupling relationship and the upgrade file in the firmware to be upgraded.

13. A server system, characterized in that, It includes a master control node and a controlled node; wherein the master control node is connected to the controlled node; The master control node is used to execute the steps of the firmware upgrade method according to any one of claims 1 to 12.

14. 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 firmware upgrade method as described in any one of claims 1 to 12.

Images