Firmware management system, method, product and device

Abstract

The present application discloses a firmware management system, method, product and device, which relate to the field of server technology and are applied to a multi-node server including a mainboard node and a logic device. The method comprises: by respectively setting two mutually redundant flash memory devices on each mainboard node of the multi-node server on a management board and a mainboard node, and additionally setting a cache memory and a logic device for caching the target firmware on the management board, thereby realizing a heterogeneous collaborative upgrade architecture; and, by setting a flash memory device corresponding to each node on the management board, centralized management of the flash memory device can be realized, and the firmware version alignment and management of each node in the multi-node server can be realized with very little material change, thereby improving the efficiency of the firmware upgrade, saving a lot of system operation and maintenance time, and reducing the impact on user business.

Description

Technical Field

[0001] The present application relates to the field of server technology, and in particular to a firmware management system, method, product, and device. Background Art

[0002] With the rapid development of cloud computing, artificial intelligence, and high-performance computing technologies, multi-node, high-density server architectures have become essential data center infrastructure. This architecture typically integrates multiple computing nodes within a single chassis, collaboratively processing large-scale tasks (such as handling numerous concurrent requests, distributed storage, large-scale data processing, and high-performance computing) to achieve high-density computing. Furthermore, multi-node servers typically include multiple firmware components, such as the Basic Input Output System (BIOS), Baseboard Management Controller (BMC), and RAID (Redundant Array of Independent Disks) controller, requiring frequent firmware updates.

[0003] However, the firmware of multiple nodes in current multi-node servers is deployed in an isolated fashion. The firmware of each node is not interoperable, resulting in the inability to uniformly update the firmware across different nodes. Each node can only update its own firmware. This means that updating the firmware for the entire chassis requires updating the firmware of each node, resulting in inefficient and time-consuming firmware updates, which significantly impacts system operations and user services. Furthermore, as the number of devices in multi-node servers increases, the demand for fast firmware management and verifiability is also increasing. However, current multi-node servers lack security verification capabilities, and the non-interoperable firmware management architecture means that adding firmware verification functionality to nodes requires adding verification components to each node. Furthermore, the isolated firmware management approach across multiple nodes easily leads to fragmented firmware versions. For tasks requiring cross-node coordination (such as fan control and hard drive sharing), failure to ensure consistent firmware versions across nodes significantly increases the risk of issues. Therefore, current multi-node servers suffer from deficiencies in fast firmware updates, unified firmware management, and firmware security verification, and are no longer able to meet the needs of next-generation data centers. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a firmware management system, method, product, and device that can achieve firmware version alignment and management of each node in a multi-node server with minimal material changes, thereby improving the efficiency of firmware upgrades, saving a large amount of system operation and maintenance time, and reducing the impact on user services. The specific solution is as follows:

[0005] In a first aspect, the present application discloses a firmware management system, comprising:

[0006] A first firmware component located in each mainboard node of the multi-node server is configured to receive and forward a firmware upgrade request to a logic device;

[0007] a logic device located on a management board in the multi-node server, configured to receive a firmware upgrade request forwarded by the first firmware component, control the interface switching component to switch an interface of a cache memory on the management board to the first firmware component, and send a switching result to the first firmware component;

[0008] The first firmware component is further configured to receive a switching result sent by the logic device, and when the switching result is successful, use the target firmware to simultaneously upgrade the firmware in the first flash memory and the cache memory in the corresponding mainboard node, and send an upgrade completion notification to the logic device after the upgrade is completed;

[0009] The logic device is also used to receive the upgrade completion notification sent by the first firmware component, and uniformly copy the upgraded firmware in the cache memory to multiple second flash memories located on the management board and corresponding to each first flash memory, and then send a component restart notification to the second firmware component in the corresponding mainboard node to control the restart of the component to be upgraded.

[0010] In a second aspect, the present application discloses a firmware management method applied to a multi-node server, wherein the multi-node server includes a management board and multiple mainboard nodes, each mainboard node includes a first firmware component, a first flash memory, and a second firmware component, and the management board includes a second flash memory corresponding to each first flash memory, an interface switching component, a cache memory, and a logic device. The method includes:

[0011] When the first firmware component receives the firmware upgrade request, the first firmware component forwards the firmware upgrade request to the logic device, so as to switch the interface of the cache memory to the first firmware component through the interface switching component, and send the switching result to the first firmware component;

[0012] When the first firmware component receives the switching result, it analyzes the switching result. If the analysis result indicates that the switching is successful, it uses the target firmware to simultaneously upgrade the firmware in the first flash memory and the cache memory, and sends an upgrade completion notification to the logic device after the upgrade is complete.

[0013] When the logic device receives the upgrade completion notification, it reads the upgraded firmware in the cache memory, copies the upgraded firmware to the second flash memory corresponding to each first flash memory, and sends a component restart notification to the second firmware component to control the restart of the component to be upgraded.

[0014] In a third aspect, the present application discloses a firmware management product, including a computer program, which implements the aforementioned firmware management method when executed by a processor.

[0015] In a fourth aspect, the present application discloses an electronic device, comprising a processor and a memory; wherein the processor implements the aforementioned firmware management method when executing a computer program stored in the memory.

[0016] The present application discloses a firmware management system, comprising: a first firmware component located in each mainboard node of a multi-node server, for receiving and forwarding firmware upgrade requests to a logic device; a logic device located on a management board in the multi-node server, for receiving the firmware upgrade request forwarded by the first firmware component, and controlling the interface switching component to switch the interface of the cache memory on the management board to the first firmware component, and sending the switching result to the first firmware component; the first firmware component is also used to receive the switching result sent by the logic device, and when the switching result is a successful switching, uses the target firmware to simultaneously upgrade the firmware in the first flash memory and the cache memory in the corresponding mainboard node, and sends an upgrade completion notification to the logic device after the upgrade is completed; the logic device is also used to receive the upgrade completion notification sent by the first firmware component, and uniformly copy the upgraded firmware in the cache memory to multiple second flash memories located on the management board and corresponding to each first flash memory, and then send a component restart notification to the second firmware component in the corresponding mainboard node to control the restart of the component to be upgraded.

[0017] In this application, by setting two redundant flash memory memories on each mainboard node of a multi-node server on the management board and the mainboard node respectively, and additional cache memory and logic devices for caching target firmware are set on the management board, a heterogeneous collaborative upgrade architecture is realized. In addition, by setting flash memory memories corresponding to each node on the management board, centralized management of flash memory memories can be achieved, and firmware version alignment and management of each node in a multi-node server can be achieved with very little material changes, thereby improving the efficiency of firmware upgrades, saving a lot of system operation and maintenance time, and reducing the impact on user business. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0019] Figure 1 This is a schematic diagram of a firmware management system architecture disclosed in this application;

[0020] Figure 2 A schematic diagram of a specific multi-node server hardware structure disclosed in this application;

[0021] Figure 3 A schematic diagram of a specific multi-node server hardware structure disclosed in this application;

[0022] Figure 4 A schematic diagram of a specific multi-node server hardware structure disclosed in this application;

[0023] Figure 5 This is a flowchart of a specific firmware management method disclosed in this application. DETAILED DESCRIPTION

[0024] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0026] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0027] The present application discloses a firmware management system. Figure 1 As shown, the system includes:

[0028] The first firmware component 11 located in each mainboard node of the multi-node server is used to receive and forward a firmware upgrade request to the logic device 12 .

[0029] It should be pointed out that the firmware management system proposed in this application is specifically applied to multi-node servers. Compared with the traditional multi-node server that simultaneously deploys two redundant flash memory storages (i.e., Flash) in a single node (Node), such as BMC Flash (64MB), the structure is different. This application decouples the two redundant flash memory storages corresponding to each node in the multi-node server. Specifically, the two redundant flash memory storages are deployed on different nodes respectively.

[0030] Specifically, the multi-node server in the present application includes a management board (Control Board) and multiple motherboard nodes (Mother Board Node). Each motherboard node includes a first firmware component 11, a first flash memory 15 and a second firmware component 17. The management board includes a second flash memory 16 corresponding to each first flash memory 15, an interface switching component 13, a cache memory 14 and a logic device 12.

[0031] Among them, the first firmware component 11 is a chip that controls firmware upgrades, such as a BMC; the logic device 12 can specifically be a CPLD (Complex Programmable Logic Device), an FPGA (Field Programmable Gate Array), an MCU (Microcontroller Unit), and other devices.

[0032] In a specific embodiment, see Figure 2 As shown, Figure 2 A hardware structure diagram of a multi-node server is shown. The multi-node server includes one mainboard node and one management board. The first firmware component on the mainboard node is a management controller (such as a BMC), and the interface switching component on the management board is a multiplexer (MUX) for SPI (Serial Peripheral Interface). The first firmware component on the mainboard node can be labeled Firmware Chip 1, the first flash memory can be labeled Flash A, and the second firmware component can be labeled Firmware Chip 2. The multiplexer on the management board can be labeled SPI MUX, the second flash memory can be labeled Flash B (corresponding to Flash A), and the cache memory is a flash memory, specifically Flash C.

[0033] In another specific embodiment, see Figure 3 As shown, Figure 3The hardware structure diagram of a multi-node server is shown. The multi-node server includes a mainboard node and a management board. The mainboard node includes a first firmware component (such as a BMC), a second firmware component (such as a CPLD), a first flash memory (Flash A), and a BIOS (Basic Input / Output System) component. The interface switching component on the management board is a multiplexer (MUX) for SPI. The management board also includes a second flash memory (Flash B), a cache memory (Flash C), and a logic device (such as a CPLD).

[0034] In this embodiment, see Figure 4 As shown, Figure 4 The chassis of the multi-node server includes n motherboard nodes and one management board. Specifically, the firmware management system includes a first firmware component (i.e., BMC1) located in each motherboard node (e.g., motherboard node 1) of the multi-node server. This component (i.e., BMC1) can be used to receive firmware upgrade requests for components to be upgraded (e.g., BMC, BIOS, RAID controller, etc.) sent by a user terminal via a web or other means, and forward the firmware upgrade requests to a logic device (e.g., a complex programmable logic device, i.e., CPLD) located on the management board of the multi-node server via an I2C (Inter-Integrated Circuit) bus.

[0035] The logic device 12 located on the management board in the multi-node server is used to receive the firmware upgrade request forwarded by the first firmware component 11, and control the interface switching component 13 to switch the interface of the cache memory 14 on the management board to the first firmware component 11, and send the switching result to the first firmware component 11.

[0036] In this embodiment, see Figure 4 As shown, the firmware management system also includes a logic device 12 (such as a complex programmable logic device, i.e., CPLD) located on the management board. This device can be used to control the interface switching component 13 (i.e., SPI MUX) on the management board to switch the interface of the cache memory 14 (i.e., Flash C) to the first firmware component 11 (i.e., BMC1) and send the switching result to the first firmware component 11 (i.e., BMC1); at the same time, the switching result can also be sent to the second firmware component 17 (i.e., Firmware Chip 2, such as CPLD) on the mainboard node 1; wherein the switching result refers to whether the SPI path of Flash C is successfully obtained.

[0037] It should be noted that when multiple mainboard nodes in a multi-node server simultaneously require firmware upgrades, the first firmware components (e.g., BMCs) in the corresponding multiple mainboard nodes will simultaneously forward upgrade instructions to the logic device 12 (e.g., CPLD) on the management board. At this time, the logic device 12 (e.g., CPLD) on the management board can, based on the time priority of the received upgrade instructions, switch the SPI of the cache memory 14 (i.e., Flash C) on the management board to the first firmware component (i.e., BMC) of the node that first sent the upgrade request through the GPIO (General-purpose input / output) port and the interface switching component 13 (e.g., SPI MUX). Furthermore, the SPI switching is not performed when the upgrade process is already in progress. Through the above switching method, the firmware upgrade of multiple nodes can be carried out in an orderly manner, avoiding upgrade confusion and abnormal phenomena caused by the simultaneous firmware upgrade of multiple nodes, thereby meeting the demand for simultaneous firmware upgrade of multiple nodes.

[0038] Also, see Figure 4 As shown, the firmware management system further includes an interface switching component (ie, SPIMUX) and a cache memory (ie, Flash C) located on the management board.

[0039] The first firmware component 11 is also used to receive the switching result sent by the logic device 12, and when the switching result is successful, use the target firmware to simultaneously upgrade the firmware in the first flash memory 15 and the cache memory 14 in the corresponding mainboard node, and send an upgrade completion notification to the logic device 12 after the upgrade is completed.

[0040] In this embodiment, the first firmware component 11 in the firmware management system can also be used to receive the switching result sent by the logic device 12 (such as CPLD) on the management board and parse the switching result. If the parsing result indicates that the SPI path of Flash C is successfully obtained, it means that the switching is successful. At this time, the target firmware (such as the latest version of the firmware for the component to be upgraded uploaded by the user) can be used to simultaneously upgrade the firmware in the first flash memory 15 (i.e., Flash A) and the cache memory 14 (i.e., Flash C). After the upgrade is completed, an upgrade completion notification is sent to the logic device 12 (such as CPLD) on the management board.

[0041] Furthermore, if the parsing result indicates a switch failure, the first firmware component 11 can also be configured to upgrade the firmware in the first flash memory 15 using the target firmware, and after the upgrade is complete, send an upgrade completion notification to the logic device 12. For example, if the parsing result indicates that the SPI path to the cache memory 14 (i.e., Flash C) was not successfully acquired, indicating a switch failure, the target firmware can be used to upgrade the firmware in the first flash memory 15 (i.e., Flash A) first. After the upgrade is complete, an upgrade completion notification can be sent to the logic device 12 (e.g., CPLD) on the management board. Furthermore, after the upgrade is complete, the firmware versions in Flash A and Flash B can be compared so that the first firmware component 11 (e.g., BMC) can be booted from the higher-version Flash.

[0042] The logic device 12 is also used to receive the upgrade completion notification sent by the first firmware component 11, and uniformly copy the upgraded firmware in the cache memory 14 to multiple second flash memories 16 located on the management board and corresponding to each first flash memory 15, and then send a component restart notification to the second firmware component in the corresponding main board node to control the restart of the component to be upgraded.

[0043] In this embodiment, the firmware management system further includes: a plurality of second flash memories 16 corresponding to the first flash memories 15 in each mainboard node and located on the management board.

[0044] In this embodiment, see Figure 4 As shown, the firmware management system further includes a plurality of second flash memories (ie, Flash B) corresponding to the first flash memories (ie, Flash A) in each mainboard node and located on the management board.

[0045] For details, see Figure 4 As shown, the logic device (such as CPLD) on the management board can also be used to receive the upgrade completion notification sent by the first firmware component (i.e., BMC) in the mainboard node 1, then read the upgraded firmware from the current cache memory (Flash C), and then uniformly copy the read upgraded firmware to the second flash memory (Flash B) corresponding to each first flash memory (Flash A), and send a restart notification for the first firmware component (BMC) to the second firmware component (such as CPLD) on the mainboard node.

[0046] Specifically, the logic device may include: a reading module for reading the upgraded firmware from the cache memory; a verification module for verifying the upgraded firmware to obtain a verification result; and a copying module for, if the verification result indicates that the upgraded firmware has passed verification, copying the upgraded firmware to the second flash memory corresponding to each first flash memory. In this embodiment, after receiving the upgrade completion notification, the logic device 12 (e.g., CPLD) may first read the upgraded firmware from the cache memory 14 (Flash C), and then verify the read upgraded firmware using a preset verification algorithm to obtain a corresponding verification result. The verification algorithm includes, but is not limited to, MD5 (Message Digest Algorithm Version 5), SHA-1 (Secure Hash Algorithm 1), SHA-256 (Secure Hash Algorithm 256), CRC32 (Cyclic Redundancy Check 32-bit), and other algorithms. If the verification result indicates that the upgraded firmware has passed verification, the upgraded firmware may be copied to the second flash memory (Flash B) corresponding to each first flash memory.

[0047] That is, when the logic device 12 on the management board performs a firmware upgrade on the first firmware component (such as the BMC), if the verification result indicates that the upgraded firmware has passed the verification, that is, it has not been attacked by an attacker such as injecting malicious code, then the upgraded firmware can be uniformly copied to multiple second flash memories 16 (FlashB) corresponding to all first flash memories 15 (Flash A), and a restart notification for the first firmware component 11 (such as the BMC) is sent to the second firmware component 17 (such as the CPLD) to control the first firmware component 11 (i.e., the BMC) to restart from the first flash memory 15 (Flash A) or the second flash memory 16 (Flash B), thereby completing the entire firmware upgrade process of the first firmware component 11 (i.e., the BMC).

[0048] Among them, the verification module can specifically include: a first parsing unit, used to parse the upgraded firmware during the reading process to obtain the hash message authentication code corresponding to the upgraded firmware; a loading and operation unit, used to load the plaintext key pre-stored in the logic device, and perform a hash operation on the upgraded firmware based on the plaintext key using a secure hash algorithm to obtain a hash operation result; a comparison unit, used to compare the hash operation result with the hash message authentication code bit by bit to obtain a comparison result; a generation unit, used to generate a verification result indicating that the upgraded firmware has passed the verification if the comparison result shows that the hash operation result matches the hash message authentication code. That is, when performing verification, the verification module first reads the upgraded firmware from the cache memory 14 (i.e., Flash C) and parses the upgraded firmware during the reading process to obtain a hash message authentication code (i.e., HMAC) corresponding to the upgraded firmware; then, the plaintext key stored locally in the logic device 12 (e.g., CPLD) is loaded, and then, based on the plaintext key and using a secure hash algorithm (e.g., SHA256 algorithm), a hash operation is performed on the upgraded firmware to obtain a corresponding hash operation result, and the hash operation result is compared bit by bit with each character in the hash message authentication code to obtain a corresponding comparison result; if the comparison result indicates that the hash operation result is consistent with the hash message authentication code, it indicates that the verification is successful, and a verification result indicating that the upgraded firmware has passed the verification can be generated. Through the above-mentioned centralized security verification mechanism, the firmware can be protected and can resist attacks such as firmware hijacking and malicious code injection. In addition, by centrally managing the second flash memory 16 (i.e., FlashB) corresponding to each mainboard node on the management board, the system can realize cross-node abnormal behavior perception, thereby improving the security of firmware upgrades.

[0049] The reading module may specifically include: a reading unit configured to read the upgraded firmware from the cache memory 14 according to a preset data block size to obtain multiple firmware data blocks; correspondingly, the first parsing unit may specifically include: a second parsing unit configured to parse the firmware data blocks during the reading process to obtain a hash message authentication code corresponding to the upgraded firmware. In this embodiment, the reading module may read the upgraded firmware stored in the cache memory 14 (i.e., Flash C) according to a preset block size (e.g., 512 bytes), and parse the read data blocks during the reading process to obtain a hash message authentication code (i.e., HMAC tag) corresponding to the upgraded firmware.

[0050] Specifically, the second parsing unit may include a third parsing unit configured to parse the firmware data block based on the address bus, data bus, and control signals of the cache memory 14 during the reading process to obtain a hash message authentication code corresponding to the upgraded firmware. In this embodiment, the parsing unit may parse the firmware data block based on the address bus (e.g., A0-A23), data bus (e.g., D0-D7), and control signals (e.g., CS (chip select signal, active low), WE (write signal), OE (read signal)) of the cache memory 14 (i.e., Flash C) during the reading process to obtain a hash message authentication code corresponding to the upgraded firmware.

[0051] Specifically, the loading and calculation unit may include: a loading unit for loading an encrypted key pre-stored in the logic device; a decryption unit for decrypting the encrypted key to obtain a plaintext key; and a hash calculation unit for sequentially performing a hash operation on each firmware data block based on the plaintext key and using a secure hash algorithm to obtain a hash result. In this embodiment, the loading and calculation unit may first load the encrypted key stored locally in the CPLD of the management board, then decrypt the encrypted key to obtain a plaintext key. Based on the decrypted plaintext key, the unit then sequentially performs a hash operation on each firmware data block using a secure hash algorithm (such as the SHA256 algorithm), such as performing an exclusive-OR operation (ipad padding and opad padding in the HMAC standard) on the input data block and the plaintext key to obtain the corresponding hash result. Using the encrypted key further improves the security of the firmware verification process, preventing attacks such as malicious code injection by attackers.

[0052] Furthermore, the logic device 12 can also be used to generate a verification result indicating that the upgraded firmware verification failed if the comparison result shows that the hash operation result does not match the hash message authentication code, and send a re-burning notification to the first firmware component 11; accordingly, the first firmware component 11 can also be used to receive the re-burning notification sent by the logic device 12, and obtain the new target firmware, triggering the step of using the target firmware to simultaneously upgrade the firmware in the first flash memory 15 and the cache memory 14 in the corresponding mainboard node to generate a new verification result; if each new verification result generated within the preset time indicates that the verification failed, or the number of new verification results generated continuously for verification failure reaches the preset number of failures, the current firmware upgrade process is stopped, and an alarm message of firmware upgrade failure is generated. In this embodiment, if the comparison result indicates that the hash operation result does not match the hash message authentication code (i.e., HMAC), the logic device 12 located on the management board may further generate a verification result indicating that the firmware verification has failed, and then send a re-burning notification to the first firmware component 11 (e.g., BMC). Then, when the first firmware component 11 (e.g., BMC) receives the re-burning notification, it first obtains a new target firmware, and uses the target firmware to simultaneously upgrade the firmware in the first flash memory 15 (i.e., Flash A) and the cache memory 14 (i.e., Flash C), and performs corresponding verification operations to generate a new verification result. If multiple new verification results generated within a preset time (e.g., within 20 minutes) all indicate verification failure, or if the number of consecutively generated new verification results indicating verification failure reaches a preset number of failures (e.g., three consecutive failures), the current firmware upgrade process is stopped, the burning permission of the corresponding mainboard node is terminated, and an alarm message indicating a firmware upgrade failure may be generated.

[0053] In addition, the first firmware component 11 (such as BMC) can also count the number of verification failures within a preset time. If the number of verification failures within the preset time exceeds the preset number, such as three verification failures within 20 minutes, the burning permission of the corresponding mainboard node will be stopped, and an alarm message of firmware upgrade failure can be generated.

[0054] It should be noted that the second firmware component 17 located in the mainboard node is specifically used to control the component to be upgraded to restart from the first flash memory or the second flash memory to complete the firmware upgrade of the component to be upgraded.

[0055] In this embodiment, see Figure 4As shown, the firmware management system also includes a second firmware component (such as a CPLD) located in a mainboard node (such as mainboard node 1), which can be specifically used to control the components to be upgraded, such as restarting the first firmware component (BMC) from the first flash memory (Flash A) or the second flash memory (Flash B), thereby completing the entire firmware upgrade process of the component to be upgraded, that is, the first firmware component (BMC). At this time, the BMC is restarted and the burning program is completed; wherein, the components to be upgraded are located in the mainboard node, including but not limited to the BMC, BIOS, RAID controller, etc.

[0056] In a specific implementation, the first firmware component 11 is a management controller (such as a BMC), the interface switching component 13 is a multiplexer (such as an SPI MUX), and the second firmware component 17 is a programmable logic device (such as a CPLD).

[0057] Specifically, the programmable logic device 12 can be used to select a target flash memory from the first flash memory 15 and the second flash memory 16 according to a preset memory selection policy, and control the management controller to reboot from the target flash memory. It should be noted that when the first firmware component (e.g., the BMC) reboots, it must first select a flash memory. Specifically, the programmable logic device (e.g., the CPLD) can first select a flash memory from the first flash memory 15 (Flash A) and the second flash memory 16 (Flash B) according to the preset memory selection policy, and use it as the target flash memory for the firmware upgrade. The programmable logic device then controls the management controller (e.g., the BMC) to reboot from the selected target flash memory.

[0058] It should be pointed out that whether the BMC is started from Flash A or Flash B can be determined by the second firmware component 17 (such as CPLD) on the mainboard node through the MUX on the management board. This method can ensure that during R&D and debugging, a single node can power on itself and complete the firmware loading and refresh operations.

[0059] In addition, the programmable logic device can also be used to select a preset default flash memory from the first flash memory 15 and the second flash memory 16 and use the default flash memory as the target flash memory; wherein the default flash memory is the second flash memory. In this embodiment, the programmable logic device (such as a CPLD) located in the mainboard node can pre-select a flash memory from the first flash memory 15 (Flash A) and the second flash memory 16 (Flash B) as the default flash memory. Preferably, since the second flash memory (Flash B) is located on the management board and firmware updates for any mainboard node trigger updates to the second flash memory (Flash B), the second flash memory (Flash B) can be used as the default flash memory.

[0060] In a specific embodiment, the programmable logic device can also be used to detect whether the management board is in place; if the management board is in place, the second flash memory is used as the target flash memory; if the management board is not in place, the first flash memory is used as the target flash memory. In other words, the programmable logic device located in the mainboard node can detect the presence of the management board. If the detection result indicates that the management board is in place, the second flash memory (i.e., Flash B) is preferentially used as the target flash memory for firmware upgrades, such as restarting the BMC. If the management board is not in place, it indicates that the corresponding firmware information cannot be obtained from the management board for restarting the BMC. In this case, the first flash memory (i.e., Flash A) can be used as the target flash memory.

[0061] In a specific embodiment, the programmable logic device is also used to use the specified flash memory as the target flash memory if it receives a memory switching instruction containing a specified flash memory sent by the management controller, and trigger the step of controlling the management controller to restart from the target flash memory; wherein, the specified flash memory is any one of the first flash memory 15 and the second flash memory 16.

[0062] In this embodiment, the programmable logic device located in the motherboard node can also control the Flash memory required for restart through a management controller (such as a BMC). Specifically, when the BMC wants to load firmware from another Flash memory, it can proactively notify the second firmware component 17 (such as a CPLD) on the motherboard node via an I2C instruction. When the second firmware component 17 (such as a CPLD) receives this notification, it can use the flash memory specified in the notification as the target flash memory and control the management controller (such as the BMC) to restart from the target flash memory (i.e., the newly specified flash memory), thereby completing the entire firmware upgrade process.

[0063] Specifically, the firmware management system may further include: a first status monitoring module for real-time monitoring of the health of the management controller to determine the controller health status; a first judgment module for determining whether the management controller is abnormal based on the controller health status; and a first control module for controlling the management controller to restart from a flash memory other than the target flash memory if the management controller is abnormal. In this embodiment, the firmware management system may further include a status monitoring module for real-time monitoring of the health of the management controller (e.g., the BMC); a judgment module for determining abnormalities in the controller health status monitored by the first status monitoring module; and a control module for controlling the management controller (e.g., the BMC) to restart from a flash memory other than the target flash memory if an abnormality occurs in the management controller, i.e., selecting a flash memory different from the current flash memory for restart. For example, if the current target flash memory is Flash B and an abnormality is detected in the management controller (e.g., the BMC), the control module may replace the BMC with Flash A for startup and cause the BMC to reload. By monitoring the health of the management controller (such as BMC) to perform firmware upgrade and restart operations, it can be ensured that the firmware upgrade is performed when the management controller is healthy. In addition, abnormalities of the management controller (such as BMC) can be discovered in a timely manner to avoid upgrade failures caused by abnormalities of the management controller.

[0064] In one specific embodiment, the first status monitoring module specifically includes: a first status monitoring unit for monitoring the health of the management controller in real time via a watchdog timer to determine the health of the controller; and correspondingly, a first control module specifically includes: a first control unit for determining that the management controller is abnormal if the output level of a preset pin does not flip within the watchdog timer's interrupt interval, and controlling the management controller to reboot from a flash memory other than the target flash memory. Specifically, the health of the management controller (e.g., BMC) is monitored in real time via the watchdog timer (WDT). If the WDT does not flip according to a preset scheme within a preset interval, the management controller (e.g., BMC) is considered to be dead, and a flash memory different from the current flash memory may be selected for reboot. For example, when the watchdog timer reaches the preset interrupt interval (32ms), it interrupts once, and the output level of the P1.0 pin flips once. If it does not flip, the management controller is determined to be abnormal, and a flash memory that is redundant with the current flash memory may be selected for reboot.

[0065] In this embodiment, the firmware management system may further include: a second status monitoring module for monitoring the health status of the logic device in real time to obtain the health status of the device; a second judgment module for judging whether the logic device has an abnormality based on the health status of the device; and a second control module for controlling the management controller to restart from the first flash memory if the logic device has an abnormality. In this embodiment, see Figure 3 As shown, while the upgraded firmware is being copied uniformly to the second flash memory (Flash B) corresponding to each first flash memory (Flash A), the health of the logic device (such as the CPLD) on the management board can be monitored via the I2C bus with the CPLD on the management board. Based on the CPLD's health, the CPLD is then determined to determine whether it has an abnormality. If so, the CPLD on the mainboard node switches the management controller (such as the BMC) to the first flash memory (Flash A) for startup. By monitoring the health of the logic device (such as the CPLD) on the management board to perform firmware upgrades and reboots, firmware upgrades can be performed while the logic device is healthy. Furthermore, any abnormalities in the logic device can be detected promptly, preventing upgrade failures caused by these abnormalities.

[0066] Specifically, the second control module may include: a counting unit for counting the duration of the logic device's hang state, if the logic device is in a hang state, to determine the hang duration; a judgment unit for determining whether the hang duration exceeds a preset duration; and a second control unit for controlling the management controller to restart from the first flash memory if the hang duration exceeds the preset duration. In other words, the module determines whether the logic device (e.g., CPLD) has been in a hang state for an extended period of time. If the CPLD on the management board does not respond after the preset time, the management controller (e.g., BMC) is switched to the first flash memory (Flash A) for startup via the CPLD on the mainboard node.

[0067] It should be pointed out that when Figure 3 When the BIOS component on the motherboard node in the system is upgraded, it still needs to be controlled by the first firmware component (such as BMC) (such as receiving upgrade requests and forwarding upgrade requests). The BIOS component is only responsible for starting the Flash, and the rest of the upgrade logic remains unchanged. Figure 2 The firmware upgrade process is the same as in .

[0068] It can be seen that the embodiment of the present application realizes a heterogeneous collaborative upgrade architecture by respectively setting two redundant flash memory memories on each mainboard node of the multi-node server on the management board and the mainboard node, and additionally setting a cache memory and a logic device for caching the target firmware on the management board. In addition, by setting the flash memory corresponding to each node on the management board, centralized management of the flash memory can be achieved, and the firmware version alignment and management of each node in the multi-node server can be achieved with very little material change, thereby improving the efficiency of firmware upgrades, saving a lot of system operation and maintenance time, and reducing the impact on user business.

[0069] In addition, the embodiment of the present application is applied to a multi-node server, adopting a heterogeneous collaborative processing architecture, and through the mutual cooperation of the BMC and CPLD on the mainboard node and the CPLD on the management board, and using the CPLD on the management board to manage and verify the startup Flash of all BMCs, the BMC and CPLD on the mainboard node are used to achieve dual Flash redundant fault tolerance of the BMC, thereby improving the security and efficiency of firmware upgrades, and centrally managing the Flash of each mainboard node, saving a lot of system operation and maintenance time, and increasing the security of user business operations. At the same time, it overcomes the bottlenecks of traditional solutions in terms of firmware management difficulty, maintenance time length, and prevention of malicious attacks, and provides a highly aligned, low-time, and highly reliable multi-node firmware upgrade verification solution for scenarios such as large-scale data centers, providing infrastructure for building a new generation of smart data centers.

[0070] Correspondingly, the embodiment of the present application also discloses a firmware management method, which is applied to a multi-node server. The multi-node server includes a management board and multiple mainboard nodes. Each mainboard node includes a first firmware component, a first flash memory, and a second firmware component. The management board includes a second flash memory corresponding to each first flash memory, an interface switching component, a cache memory, and a logic device. Figure 5 As shown, the method includes:

[0071] Step S11: When the first firmware component receives the firmware upgrade request, it forwards the firmware upgrade request to the logic device, switches the interface of the cache memory to the first firmware component through the interface switching component, and sends the switching result to the first firmware component.

[0072] Step S12: After receiving the switching result, the first firmware component analyzes the switching result. If the analysis result indicates that the switching is successful, the target firmware is used to simultaneously upgrade the firmware in the first flash memory and the cache memory, and an upgrade completion notification is sent to the logic device after the upgrade is completed.

[0073] Step S13: After receiving the upgrade completion notification, the logic device reads the upgraded firmware in the cache memory, copies the upgraded firmware to the second flash memory corresponding to each first flash memory, and sends a component restart notification to the second firmware component to control the restart of the component to be upgraded.

[0074] Among them, the specific workflow of each of the above steps can refer to the corresponding content disclosed in the aforementioned embodiments, and will not be repeated here.

[0075] It can be seen that in the embodiment of the present application, by respectively setting the two redundant flash memory memories on each mainboard node of the multi-node server on the management board and the mainboard node, and additionally setting the cache memory and logic device for caching the target firmware on the management board, a heterogeneous collaborative upgrade architecture is realized. In addition, by setting the flash memory corresponding to each node on the management board, centralized management of the flash memory can be realized, and the firmware version alignment and management of each node in the multi-node server can be achieved with very little material change, and the efficiency of the firmware upgrade is improved, while saving a lot of system operation and maintenance time and reducing the impact on user business.

[0076] The embodiments of the present application further provide a firmware management device. For descriptions of features in the embodiments corresponding to the firmware management device, please refer to the relevant descriptions of the embodiments corresponding to the firmware management method, which will not be repeated here.

[0077] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above firmware management method embodiments.

[0078] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above firmware management method embodiments when running.

[0079] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0080] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above firmware management method embodiments are implemented.

[0081] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned firmware management method embodiments are implemented.

[0082] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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.

[0083] The above is a detailed introduction to a firmware management system, method, product, and device provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the present application.

Claims

1. A firmware management system, characterized in that: include: A first firmware component located in each mainboard node of the multi-node server is configured to receive and forward a firmware upgrade request to a logic device; The logic device located on the management board in the multi-node server is configured to receive the firmware upgrade request forwarded by the first firmware component, control the interface switching component to switch the interface of the cache memory on the management board to the first firmware component, and send the switching result to the first firmware component; the first firmware component is a management controller; The first firmware component is further configured to receive the switching result sent by the logic device, and when the switching result is successful, use the target firmware to simultaneously upgrade the firmware in the first flash memory and the cache memory in the corresponding mainboard node, and send an upgrade completion notification to the logic device after the upgrade is completed; The logic device is further configured to receive the upgrade completion notification sent by the first firmware component, and uniformly copy the upgraded firmware in the cache memory to a plurality of second flash memories located on the management board and corresponding to each of the first flash memories, and then send a component restart notification to the second firmware component in the corresponding mainboard node to control the restart of the component to be upgraded; The second firmware component is a programmable logic device; The logic device includes: a reading module for reading the upgraded firmware from the cache memory; a verification module for verifying the upgraded firmware to obtain a verification result; and a copy module for uniformly copying the upgraded firmware to the second flash memory corresponding to each first flash memory if the verification result indicates that the upgraded firmware has passed the verification.

2. The firmware management system according to claim 1, wherein: The verification module includes: A first parsing unit is configured to parse the upgraded firmware during a reading process to obtain a hash message authentication code corresponding to the upgraded firmware; a loading and operation unit, configured to load a plaintext key pre-stored in the logic device, and perform a hash operation on the upgraded firmware using a secure hash algorithm based on the plaintext key to obtain a hash operation result; a comparing unit, configured to compare the hash operation result with the hash message authentication code bit by bit to obtain a comparison result; A generating unit is configured to generate a verification result indicating that the upgraded firmware passes verification if the comparison result indicates that the hash operation result matches the hash message authentication code.

3. The firmware management system according to claim 2, characterized in that: The reading module includes: a reading unit, configured to read the upgraded firmware from the cache memory according to a preset data block size to obtain a plurality of firmware data blocks; Accordingly, the first parsing unit includes: The second parsing unit is used to parse the firmware data block during the reading process to obtain a hash message authentication code corresponding to the upgraded firmware.

4. The firmware management system according to claim 3, characterized in that: The second parsing unit includes: The third parsing unit is used to parse the firmware data block based on the address bus, data bus and control signal of the cache memory during the reading process to obtain a hash message authentication code corresponding to the upgraded firmware.

5. The firmware management system according to claim 3, characterized in that: The loading and computing unit comprises: A loading unit, configured to load an encrypted key pre-stored in the logic device; A decryption unit, configured to decrypt the encrypted key to obtain a plaintext key; The hash operation unit is used to perform a hash operation on each of the firmware data blocks in sequence based on the plaintext key and using a secure hash algorithm to obtain a hash operation result.

6. The firmware management system according to claim 2, characterized in that: The logic device is further configured to generate a verification result indicating that the upgraded firmware verification has failed, and send a re-burning notification to the first firmware component if the comparison result indicates that the hash operation result does not match the hash message authentication code; Correspondingly, the first firmware component is further configured to receive the re-burning notification sent by the logic device, obtain new target firmware, and trigger the step of simultaneously upgrading the firmware in the first flash memory and the cache memory in the corresponding mainboard node using the target firmware to generate a new verification result; If all new verification results generated within the preset time indicate verification failure, or the number of consecutively generated new verification results indicating verification failure reaches the preset number of failures, the current firmware upgrade process is stopped and an alarm message indicating firmware upgrade failure is generated.

7. The firmware management system according to claim 1, wherein: The first firmware component is further configured to upgrade the firmware in the first flash memory using the target firmware if the analysis result indicates that the switching fails, and send an upgrade completion notification to the logic device after the upgrade is completed.

8. The firmware management system according to any one of claims 1 to 7, characterized in that: The interface switching component is a multiplexer.

9. The firmware management system according to claim 8, characterized in that: The programmable logic device is configured to select a target flash memory from the first flash memory and the second flash memory according to a preset memory selection policy, and control the management controller to restart from the target flash memory.

10. The firmware management system according to claim 9, characterized in that: The programmable logic device is further configured to select a preset default flash memory from the first flash memory and the second flash memory, and use the default flash memory as a target flash memory; The default flash memory is the second flash memory.

11. The firmware management system according to claim 9, wherein: The programmable logic device is further used to detect whether the management board is in place; if the management board is in place, the second flash memory is used as the target flash memory; if the management board is not in place, the first flash memory is used as the target flash memory.

12. The firmware management system according to claim 9, characterized in that: The programmable logic device is further configured to, upon receiving a memory switching instruction including a designated flash memory sent by the management controller, use the designated flash memory as a target flash memory and trigger the step of controlling the management controller to restart from the target flash memory; The designated flash memory is any one of the first flash memory and the second flash memory.

13. The firmware management system according to claim 9, characterized in that: Also includes: A first status monitoring module is used to monitor the health status of the management controller in real time to obtain the health status of the controller; A first judgment module is used to judge whether the management controller has an abnormality based on the health status of the controller; The first control module is configured to control the management controller to restart from another flash memory other than the target flash memory if an abnormality occurs in the management controller.

14. The firmware management system according to claim 13, wherein: The first condition monitoring module includes: A first status monitoring unit is configured to monitor the health status of the management controller in real time through a watchdog timer to obtain the health status of the controller; Accordingly, the first control module includes: The first control unit is configured to determine that an abnormality exists in the management controller if the output level of the preset pin does not flip when the interrupt interval of the watchdog timer is reached, and control the management controller to restart from another flash memory other than the target flash memory.

15. The firmware management system according to claim 8, characterized in that: Also includes: A second status monitoring module is used to monitor the health status of the logic device in real time to obtain the health status of the device; A second judgment module is used to judge whether the logic device has an abnormality based on the health status of the device; The second control module is configured to control the management controller to restart from the first flash memory if an abnormality occurs in the logic device.

16. The firmware management system according to claim 15, characterized in that: The second control module includes: a statistical unit, configured to, if the logic device is in a hung state, count the duration of the logic device being in the hung state to obtain a hung duration; A judging unit, configured to judge whether the deadlock duration exceeds a preset duration; The second control unit is configured to control the management controller to restart from the first flash memory if the hang time exceeds a preset time.

17. A firmware management method, characterized in that: Applied to a multi-node server, the multi-node server includes a management board and multiple mainboard nodes, each of the mainboard nodes includes a first firmware component, a first flash memory, and a second firmware component, the management board includes a second flash memory corresponding to each first flash memory, an interface switching component, a cache memory, and a logic device, the method comprising: When the first firmware component receives a firmware upgrade request, the first firmware component forwards the firmware upgrade request to the logic device, so as to switch the interface of the cache memory to the first firmware component through the interface switching component, and sends a switching result to the first firmware component; the first firmware component is a management controller; When the first firmware component receives the switching result, it analyzes the switching result. If the analysis result indicates that the switching is successful, it uses the target firmware to simultaneously upgrade the firmware in the first flash memory and the cache memory, and sends an upgrade completion notification to the logic device after the upgrade is complete. When the logic device receives the upgrade completion notification, it reads the upgraded firmware in the cache memory, copies the upgraded firmware to the second flash memory corresponding to each of the first flash memories, and sends a component restart notification to the second firmware component to control the restart of the component to be upgraded; the second firmware component is a programmable logic device; The logic device includes: a reading module for reading the upgraded firmware from the cache memory; a verification module for verifying the upgraded firmware to obtain a verification result; and a copy module for uniformly copying the upgraded firmware to the second flash memory corresponding to each first flash memory if the verification result indicates that the upgraded firmware has passed the verification.

18. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the firmware management method of claim 17 is implemented.

19. An electronic device, characterized in that: The device comprises a processor and a memory; wherein, when the processor executes the computer program stored in the memory, the firmware management method according to claim 17 is implemented.

Images