Firmware management system, method, product and equipment

Abstract

The invention discloses a firmware management system, a firmware management method, a firmware management product and firmware management equipment, relates to the technical field of servers, is applied to a multi-node server comprising mainboard nodes and logic devices, and comprises the following steps: respectively arranging two mutually redundant flash memories on each mainboard node of the multi-node server on a management board and the mainboard nodes, according to the invention, the management board is additionally provided with the cache memory for caching the target firmware and the logic device, so that a heterogeneous collaborative upgrading architecture is realized, and the flash memories corresponding to the nodes are arranged on the management board, so that the centralized management of the flash memories can be realized, and the upgrading efficiency is improved. According to the method, the firmware version alignment and management of each node in the multi-node server can be realized with little material change, the firmware upgrading efficiency is improved, meanwhile, a large amount of system operation and maintenance time is saved, and the influence on user services is reduced.

Description

Technical Field

[0001] This application relates to the technical field of servers, and particularly 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, the multi-node high-density server architecture has become the infrastructure of data centers. This architecture usually integrates multiple computing nodes in a single chassis to collaboratively process large-scale tasks (such as handling a large number of concurrent requests, distributed storage, large-scale data processing, high-performance computing, etc.) to achieve high-density computing. Moreover, multiple firmware components are usually installed in multi-node servers, such as BIOS (Basic Input Output System), BMC (Baseboard Management Controller), RAID (Redundant Array of Independent Disks) controller, etc., and the firmware update frequency is relatively high.

[0003] However, the multiple node firmwares in current multi-node servers are deployed in an isolated manner, and the firmwares of each node are not interoperable, resulting in the inability to uniformly refresh the firmwares on different nodes. Moreover, each node can only refresh the firmware on its own node. When updating all the firmwares in the entire chassis, firmware refresh operations need to be performed on each node, resulting in low firmware update efficiency and long time consumption, which will have a greater impact on system operation and maintenance and user services. In addition, with the increase in devices in multi-node servers, the demand for fast firmware management and verifiability is also increasing. However, current multi-node servers lack a security verification function, and the non-interoperable firmware management architecture will require adding devices for implementing the verification function on each node when adding a firmware verification function to the nodes. Additionally, the isolated firmware management method between multiple nodes is extremely likely to cause the dispersion of firmware versions on each node. For tasks that require cooperation between multiple nodes (such as fan control, hard disk sharing, etc.), if the firmware versions of each node cannot be ensured to be aligned, the problem risk will be greatly increased. Therefore, current multi-node servers have defects in aspects such as fast firmware update, unified firmware management, and firmware security verification, and can no longer meet the requirements of the 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, which can achieve the alignment and management of firmware versions of each node in a multi-node server with few material modifications, improve the efficiency of firmware upgrade, save a large amount of system operation and maintenance time, and reduce the impact on user services. The specific solutions are as follows: In a first aspect, the present application discloses a firmware management system, including: A first firmware component located in each motherboard node of a multi-node server, configured to receive and forward a firmware upgrade request to a logic device; A logic device located on a management board in the multi-node server, configured to receive the firmware upgrade request forwarded by the first firmware component, control an 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; The first firmware component is further configured to receive the switching result sent by the logic device, and when the switching result indicates successful switching, use a target firmware to simultaneously upgrade the firmware in a first flash memory and the cache memory in the corresponding motherboard 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, 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 first flash memory, and then send a component restart notification to a second firmware component in the corresponding motherboard node to control the component to be upgraded to restart.

[0005] In a second aspect, the present application discloses a firmware management method, which is applied to a multi-node server. The multi-node server includes a management board and a plurality of motherboard nodes. Each motherboard 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. The method includes: When the first firmware component receives a firmware upgrade request, forward 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 a switching result to the first firmware component; After the first firmware component receives the switching result, parse the switching result. If the parsing result indicates successful switching, use the target firmware to simultaneously upgrade the firmware in the first flash memory and the cache memory, and send an upgrade completion notification to the logic device after the upgrade is completed; When the logic device receives the upgrade completion notification, read the upgraded firmware in the cache memory, uniformly copy the upgraded firmware to the second flash memories corresponding to each first flash memory, and send a component restart notification to the second firmware component to control the component to be upgraded to restart.

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

[0007] Fourthly, the present application discloses an electronic device, including a processor and a memory; wherein, when the processor executes the computer program stored in the memory, the foregoing firmware management method is implemented.

[0008] The present application discloses a firmware management system, including: a first firmware component located in each motherboard node of a multi-node server, configured to receive and forward a firmware upgrade request to a logic device; a logic device located on a management board in the multi-node server, configured to receive the firmware upgrade request forwarded by the first firmware component, and control an interface switching component to switch the interface of a cache memory on the management board to the first firmware component, and send a switching result to the first firmware component; the first firmware component is further configured to receive the switching result sent by the logic device, and when the switching result is successful switching, upgrade the firmware in a first flash memory and the cache memory in the corresponding motherboard node simultaneously using a target firmware, 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 first flash memory, and then send a component restart notification to a second firmware component in the corresponding motherboard node to control the component to be upgraded to restart.

[0009] In the present application, by respectively disposing two mutually redundant flash memories on each motherboard node of the multi-node server on the management board and the motherboard node, and additionally disposing a cache memory and a logic device for caching the target firmware on the management board, a heterogeneous collaborative upgrade architecture is realized. Moreover, by disposing flash memories corresponding to each node on the management board, centralized management of the flash memories can be achieved, the firmware versions of each node in the multi-node server can be aligned and managed with very few material changes, the efficiency of firmware upgrade is improved, a large amount of system operation and maintenance time is saved, and the impact on user services is reduced. Description of the Drawings

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0011] Figure 1 It is a schematic diagram of a firmware management system architecture disclosed in the present application; Figure 2 It is a schematic diagram of a specific hardware structure of a multi-node server disclosed in the present application; Figure 3A schematic diagram of a specific multi-node server hardware structure disclosed in this application; Figure 4 A schematic diagram of a specific multi-node server hardware structure disclosed in this application; Figure 5 A flowchart of a specific firmware management method disclosed in this application. Specific embodiments

[0012] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.

[0013] It should be noted that in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in this application are used to distinguish similar objects, rather than to describe a specific order or sequence.

[0014] To enable those skilled in the art of this technology to better understand the solution of this application, the following further detailed description of this application will be made in conjunction with the accompanying drawings and specific embodiments.

[0015] An embodiment of this application discloses a firmware management system. Refer to Figure 1 As shown, the system includes: The first firmware component 11 located in each motherboard node of the multi-node server, which is used to receive and forward firmware upgrade requests to the logic device 12.

[0016] It should be pointed out that the firmware management system proposed in this application is specifically applied to a multi-node server. Different from the traditional structure of deploying two mutually redundant flash memories (i.e., Flash), such as BMC Flash (64MB), in a single node (Node) at the same time, this application decouples the two mutually redundant flash memories corresponding to each node in the multi-node server. Specifically, the two mutually redundant flash memories are respectively deployed on different nodes.

[0017] Specifically, the multi-node server in the present application includes a control board and multiple motherboard nodes. Each motherboard node includes a first firmware component 11, a first flash memory 15, and a second firmware component 17. The control 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.

[0018] Among them, the first firmware component 11 is a chip for controlling firmware upgrade, such as BMC, etc.; the logic device 12 can specifically be a CPLD (Complex Programmable Logic Device), an FPGA (Field Programmable Gate Array), an MCU (Microcontroller Unit), etc.

[0019] In a specific implementation, refer to Figure 2 as shown in Figure 2 Fig. shows a hardware structure diagram of a multi-node server. This multi-node server includes 1 motherboard node and 1 control board. The first firmware component on the motherboard node is a management controller (such as BMC), and the interface switching component on the control board is a multiplexer (MUX) for SPI (Serial Peripheral Interface); among them, the first firmware component on the motherboard node can be marked as Firmware Chip 1, the first flash memory can be marked as Flash A, and the second firmware component can be marked as Firmware Chip 2; the multiplexer on the control board can be marked as SPI MUX, the second flash memory can be marked as Flash B (corresponding to Flash A), and the cache memory is a flash memory, which can specifically be marked as Flash C.

[0020] In another specific implementation, refer to Figure 3 as shown in Figure 3A hardware structure diagram of a multi-node server is shown. The multi-node server includes 1 main board node and 1 management board. The main board node includes a first firmware component (such as BMC), a second firmware component (such as CPLD), a first flash memory (Flash A), and a BIOS (Basic InputOutput 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 logic devices (such as CPLD).

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

[0022] The logic device 12 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.

[0023] In this embodiment, refer to Figure 4 as shown, the firmware management system also includes a logic device 12 (such as a complex programmable logic device, i.e., CPLD) 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 (such as BMC1), and send the switching result to the first firmware component 11 (i.e., BMC1). At the same time, it can also send the switching result to the second firmware component 17 (i.e., Firmware Chip 2, such as CPLD) on the main board node 1. The switching result refers to whether the SPI path of Flash C is successfully obtained.

[0024] It should be noted that when there are firmware upgrade requirements for multiple motherboard nodes in a multi-node server simultaneously, the first firmware components (such as BMC) in the corresponding multiple motherboard nodes will forward upgrade instructions to the logic device 12 (such as CPLD) on the management board at the same time. At this time, the logic device 12 (such as CPLD) on the management board can, according to the time priority order of the received upgrade instructions, and through the GPIO (General-purpose input / output) port and the interface switching component 13 (such as SPI MUX), switch the SPI of the cache memory 14 (i.e., Flash C) on the management board to the side of the first firmware component (i.e., BMC) of the node that sent the upgrade request first; moreover, when the upgrade process has already started, the SPI switching will not be performed. Through the above switching method, the firmware upgrade of multiple nodes can be carried out in an orderly manner, avoiding the upgrade chaos and abnormal phenomena caused by multiple nodes performing firmware upgrades simultaneously, thus meeting the requirement of multiple nodes performing firmware upgrades simultaneously.

[0025] In addition, as shown in Figure 4 the firmware management system also includes an interface switching component (i.e., SPI MUX) and a cache memory (i.e., Flash C) located on the management board.

[0026] 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 switching, use the target firmware to upgrade the firmware in the first flash memory 15 and the cache memory 14 in the corresponding motherboard node simultaneously, and send an upgrade completion notification to the logic device 12 after the upgrade is completed.

[0027] 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 firmware in the first flash memory 15 (i.e., Flash A) and the cache memory 14 (i.e., Flash C) can be upgraded simultaneously using the target firmware (such as the latest version of the firmware uploaded by the user for the component to be upgraded), and after the upgrade is completed, an upgrade completion notification is sent to the logic device 12 (such as CPLD) on the management board.

[0028] In addition, the first firmware component 11 can also be used to upgrade the firmware in the first flash memory 15 using the target firmware if the parsing result indicates a switching failure, and send a notification of the completion of the upgrade to the logic device 12 after the upgrade is completed. For example, if the parsing result indicates that the SPI path of the cache memory 14 (i.e., Flash C) is not successfully obtained, it indicates a switching failure. At this time, the firmware in the first flash memory 15 (i.e., Flash A) can be preferentially upgraded using the target firmware, and a notification of the completion of the upgrade is sent to the logic device 12 (such as CPLD) on the management board after the upgrade is completed. In addition, after the upgrade is completed, the firmware versions in Flash A and Flash B can be compared to start the first firmware component 11 (such as BMC) from the higher version of Flash.

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

[0030] 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 motherboard node and located on the management board.

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

[0032] Specifically, referring to Figure 4 As shown, the logic device (such as CPLD) on the management board can also be used to receive the notification of the completion of the upgrade sent by the first firmware component (i.e., BMC) in the motherboard 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 memories (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 motherboard node.

[0033] 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 passes the verification, uniformly copying the upgraded firmware to the second flash memories corresponding to the first flash memories. In this embodiment, when the logic device 12 (such as a CPLD) receives an upgrade completion notification, it can 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; among them, the verification algorithm includes but is not limited to algorithms such as MD5 (Message-Digest Algorithm 5), SHA-1 (Secure Hash Algorithm 1), SHA-256 (Secure Hash Algorithm 256), CRC32 (Cyclic Redundancy Check 32-bit), etc.; if the verification result indicates that the upgraded firmware passes the verification, at this time, the upgraded firmware can be uniformly copied to the second flash memories (Flash B) corresponding to the first flash memories.

[0034] That is, when the logic device 12 on the management board performs firmware upgrade on the first firmware component (such as BMC), if the verification result indicates that the upgraded firmware passes the verification, that is, it has not been attacked by an attacker injecting malicious code, etc., at this time, the upgraded firmware can be uniformly copied to the multiple second flash memories 16 (Flash B) corresponding to all the first flash memories 15 (Flash A), and a restart notification for the first firmware component 11 (such as BMC) is sent to the second firmware component 17 (such as CPLD) to control the first firmware component 11 (i.e., 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., BMC).

[0035] Among them, the verification module may specifically include: a first parsing unit, configured 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, configured 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, configured to compare the hash operation result and the hash message authentication code bit by bit to obtain a comparison result; a generation unit, configured to generate a verification result indicating that the upgraded firmware passes the verification if the comparison result shows that the hash operation result matches the hash message authentication code. That is, when the verification module performs verification, it 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 the hash message authentication code corresponding to the upgraded firmware (i.e., HMAC, Hash-based Message Authentication Code); then, it loads the plaintext key locally stored in the logic device 12 (such as CPLD), and then performs a hash operation on the upgraded firmware based on the plaintext key using a secure hash algorithm (such as SHA256 algorithm) to obtain the corresponding hash operation result, and compares each character in the hash operation result and the hash message authentication code bit by bit to obtain the corresponding comparison result; if the comparison result shows that the hash operation result is consistent with the hash message authentication code, it indicates that the verification is successful, and at this time, a verification result indicating that the upgraded firmware passes the verification can be generated. Through the above centralized security verification mechanism, the protection of the firmware can be realized, attacks such as firmware hijacking and malicious code injection can be resisted, and by centrally managing the second flash memories 16 (i.e., FlashB) corresponding to each main board node on the management board, the cross-node abnormal behavior perception of the system can be realized, thereby improving the security of firmware upgrade.

[0036] Among them, 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 a plurality of 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 the hash message authentication code corresponding to the upgraded firmware. In this embodiment, the reading module can read the upgraded firmware stored in the cache memory 14 (i.e., Flash C) according to a preset block size (such as 512 bytes), and parse the read data blocks during the reading process to obtain the hash message authentication code (i.e., HMAC tag) corresponding to the upgraded firmware.

[0037] 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 the hash message authentication code corresponding to the upgraded firmware. In this embodiment, during the reading process, the parsing unit may parse the firmware data block based on the address bus (such as A0 - A23), data bus (such as D0 - D7), and control signals (such as CS (chip select signal, active low), WE (write signal), OE (read signal)) of the cache memory 14 (i.e., Flash C), so as to obtain the hash message authentication code corresponding to the upgraded firmware.

[0038] Specifically, the loading and operation unit may include: a loading unit, configured to load the encrypted key pre-stored in the logic device; a decryption unit, configured to perform a decryption operation on the encrypted key to obtain the plaintext key; and a hash operation unit, configured to perform a hash operation on each firmware data block in sequence based on the plaintext key using a secure hash algorithm to obtain a hash operation result. In this embodiment, the loading and operation unit may first load the encrypted key locally stored in the CPLD of the management board, then perform a decryption operation on the encrypted key to obtain the plaintext key, and perform a hash operation on each firmware data block in sequence based on the obtained plaintext key using a secure hash algorithm (such as the SHA256 algorithm), such as performing an exclusive OR operation (referring to the ipad padding and opad padding in the HMAC standard) on the input data block and the plaintext key, to obtain the corresponding hash operation result. By using the encrypted key, the security of the firmware verification process can be further improved, and attacks such as malicious code injection by attackers can be avoided.

[0039] Further, the logic device 12 can also be used to generate a verification result indicating that the firmware verification after upgrade fails if the comparison result shows that the hash operation result does not match the hash message authentication code, and send a re - flashing notice to the first firmware component 11; correspondingly, the first firmware component 11 can also be used to receive the re - flashing notice sent by the logic device 12, obtain a new target firmware, and trigger the step of upgrading the firmware in the first flash memory 15 and the cache memory 14 in the corresponding motherboard node simultaneously using the target firmware to generate a new verification result; if all the new verification results generated within a preset time indicate verification failure, or the number of consecutive new verification results that are verification failures reaches a preset failure count, the current firmware upgrade process is stopped, and an alarm message indicating firmware upgrade failure is generated. In this embodiment, if the comparison result shows 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 can also generate a verification result indicating firmware verification failure, and then send a re - flashing notice to the first firmware component 11 (such as BMC); then, when the first firmware component 11 (such as BMC) receives the re - flashing notice, it first obtains a new target firmware, and uses the target firmware to upgrade the firmware in the first flash memory 15 (i.e., Flash A) and the cache memory 14 (i.e., Flash C) simultaneously, and performs corresponding verification operations to generate a new verification result; if multiple new verification results generated within a preset time (such as within 20 minutes) all indicate verification failure, or the number of consecutive new verification results that are verification failures reaches a preset failure count (such as three consecutive failures), the current firmware upgrade process is stopped, the flashing permission of the corresponding motherboard node is stopped, and an alarm message indicating firmware upgrade failure can be generated.

[0040] 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 count, such as three verification failures within 20 minutes, the flashing permission of the corresponding motherboard node is stopped, and an alarm message indicating firmware upgrade failure can be generated.

[0041] It should be noted that the second firmware component 17 located in the motherboard 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.

[0042] In this embodiment, refer to Figure 4As shown, the firmware management system further includes a second firmware component (such as a CPLD) located in the motherboard node (such as motherboard node 1), which can specifically be used to control the component to be upgraded, such as the first firmware component (BMC) to restart 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 restarts and the flashing program is completed; among them, the component to be upgraded is located in the motherboard node, including but not limited to BMC, BIOS, RAID controller, etc.

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

[0044] Among them, the programmable logic device 12 can specifically 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 strategy, and control the management controller to restart from the target flash memory. It should be noted that when the first firmware component (such as BMC) restarts, the selection of the Flash needs to be performed first. Specifically, the programmable logic device (such as 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 a preset memory selection strategy, and use it as the target flash memory for firmware upgrade, and then control the management controller (such as BMC) to restart from the selected target flash memory.

[0045] It should be noted that the BMC specifically starts from Flash A or Flash B, which can be determined by the second firmware component 17 (such as CPLD) on the motherboard node through the MUX on the management board. This method can ensure that during R & D debugging, a single node can power on itself and complete the firmware loading and refreshing operations.

[0046] 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 motherboard 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 the firmware update of any motherboard node will trigger the update of the second flash memory (Flash B), the second flash memory (Flash B) can be used as the default flash memory.

[0047] In a specific embodiment, the programmable logic device can also be used to detect whether the management board is present; if the management board is present, the second flash memory is used as the target flash memory; if the management board is not present, the first flash memory is used as the target flash memory. That is, the programmable logic device located in the motherboard node can detect the presence status of the management board. If the detection result indicates that the management board is present, the second flash memory (i.e., Flash B) is preferentially used as the target flash memory for the firmware to be upgraded, such as the restart of the BMC. If the management board is not present, it means that the corresponding firmware information cannot be obtained from the management board for BMC restart. At this time, the first flash memory (i.e., Flash A) can be used as the target flash memory.

[0048] In a specific embodiment, the programmable logic device is further configured to, if it receives a memory switching instruction including a specified flash memory sent by the management controller, use the specified flash memory as the target flash memory, and trigger a 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.

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

[0050] Specifically, the firmware management system may further include: a first condition monitoring module for real-time monitoring of the health status of the management controller to obtain the controller health status; a first judgment module for judging whether the management controller is abnormal based on the controller health status; and a first control module for, if the management controller is abnormal, controlling the management controller to restart from another flash memory other than the target flash memory. In this embodiment, a condition monitoring module for real-time monitoring of the health status of the management controller (such as BMC) may also be set in the firmware management system, a judgment module for making an abnormality judgment on the controller health status monitored by the first condition monitoring module, and a control module for, when the management controller is abnormal, controlling the management controller (such as BMC) to restart from another flash memory other than the target flash memory, that is, selecting another flash memory different from the current flash memory for restart. For example, when the current target flash memory is Flash B and it is detected that the management controller (such as BMC) is abnormal, the control module replaces the BMC to start Flash A and enables the BMC to perform a reloading operation. By monitoring the health status of the management controller (such as BMC) for firmware upgrade and restart operations, it can ensure that the firmware upgrade is performed when the management controller is healthy, and it can timely detect the abnormality of the management controller (such as BMC), avoiding upgrade failures caused by the abnormality of the management controller.

[0051] In a specific implementation manner, the first condition monitoring module specifically includes: a first condition monitoring unit for real-time monitoring of the health status of the management controller through a watchdog timer to obtain the controller health status; correspondingly, the first control module specifically includes: a first control unit for, if the output level of a preset pin does not flip when reaching the interruption interval of the watchdog timer, determining that the management controller is abnormal and controlling the management controller to restart from another flash memory other than the target flash memory. That is, the health status of the management controller (such as BMC) is real-time monitored through the WDT (watchdog timer), and if the WDT does not flip according to the preset scheme when reaching the preset time interval, it is considered that the management controller (such as BMC) has hung up. At this time, another flash memory different from the current flash memory can be selected for restart. For example, when the watchdog timer reaches the preset interruption interval (32 ms), it interrupts once, and the output level of the P1.0 pin flips once. If it does not flip, it can be determined that the management controller is abnormal. At this time, another flash memory redundant to the current flash memory can be selected for restart.

[0052] In this embodiment, the firmware management system may further include: a second condition monitoring module, configured to monitor the health status of the logic device in real time to obtain the device health status; a second judgment module, configured to judge whether the logic device is abnormal based on the device health status; and a second control module, configured to, if the logic device is abnormal, control the management controller to restart from the first flash memory. In this embodiment, as shown in Figure 3 during the process of uniformly copying the upgraded firmware to the second flash memories (Flash B) corresponding to the first flash memories (Flash A), the health status of the logic devices (such as CPLD) on the management board can be monitored through the I2C bus between the management board and the CPLD on the management board, and then it can be judged whether the CPLD is abnormal based on the health status of the CPLD. If it is abnormal, the management controller (such as BMC) is switched to the first flash memory (Flash A) to start through the CPLD on the main board node. By monitoring the health status of the logic devices (such as CPLD) on the management board for firmware upgrade and restart operations, it can ensure that the firmware upgrade is performed when the logic devices are healthy, and the abnormalities of the logic devices can be discovered in time to avoid upgrade failures caused by logic device abnormalities.

[0053] Specifically, the second control module may specifically include: a statistics unit, configured to, if the logic device is in a hung state, count the duration of the logic device in the hung state to obtain the hung duration; a judgment unit, configured to judge whether the hung duration exceeds a preset duration; and a second control unit, configured to, if the hung duration exceeds the preset duration, control the management controller to restart from the first flash memory. That is, it is judged whether the logic device (such as CPLD) is in a hung state for a long time. If the CPLD on the management board does not respond after exceeding the preset time, the management controller (such as BMC) is switched to the first flash memory (Flash A) to start through the CPLD on the main board node.

[0054] It should be noted that when it is necessary to perform a firmware upgrade on the BIOS component on the Figure 3 main board node, it still needs to be controlled by the first firmware component (such as BMC) (such as receiving and forwarding upgrade requests). The BIOS component is only responsible for starting the Flash, and the rest of the upgrade logic remains unchanged, which is the same as the Figure 2 firmware upgrade process.

[0055] It can be seen that in the embodiment of the present application, two mutually redundant flash memories on each motherboard node of the multi-node server are respectively arranged on the management board and the motherboard node, and a cache memory and a logic device for caching the target firmware are additionally arranged on the management board, thereby realizing a heterogeneous collaborative upgrade architecture. Moreover, by arranging the flash memories corresponding to each node on the management board, centralized management of the flash memories can be achieved, and the firmware versions of each node in the multi-node server can be aligned and managed with very few material changes, improving the efficiency of firmware upgrade, saving a large amount of system operation and maintenance time, and reducing the impact on user services.

[0056] In addition, the embodiment of the present application is applied to a multi-node server, adopting a heterogeneous collaborative processing architecture. Through the mutual cooperation of the BMC and CPLD on the motherboard 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, and using the BMC and CPLD on the motherboard node, dual-Flash redundancy fault tolerance of the BMC is achieved, thereby improving the security and efficiency of firmware upgrade, centrally managing the Flash of each motherboard node, saving a large amount of system operation and maintenance time, and increasing the security of user service operation. At the same time, it overcomes the bottlenecks in aspects such as firmware management difficulty, maintenance time length, and prevention of malicious attacks in the traditional solution, provides a multi-node firmware upgrade verification solution with high alignment, low duration, and high reliability for scenarios such as large-scale data centers, and provides infrastructure for building a new generation of intelligent data centers.

[0057] 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 motherboard nodes. Each motherboard 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. Refer to Figure 5 As shown, the method includes: Step S11: When the first firmware component receives a firmware upgrade request, forward the firmware upgrade request to the logic device to switch the interface of the cache memory to the first firmware component through the interface switching component, and send a switching result to the first firmware component.

[0058] Step S12: After the first firmware component receives the switching result, parse the switching result. If the parsing result indicates that the switching is successful, use the target firmware to upgrade the firmware in both the first flash memory and the cache memory at the same time, and send an upgrade completion notification to the logic device after the upgrade is completed.

[0059] Step S13: After the logic device receives the upgrade completion notification, it reads the upgraded firmware in the cache memory, uniformly copies the upgraded firmware to the second flash memories corresponding to the respective first flash memories, and sends a component restart notification to the second firmware component to control the restart of the component to be upgraded.

[0060] Among them, the specific working processes of the above steps can refer to the corresponding content disclosed in the foregoing embodiments, and will not be elaborated here.

[0061] It can be seen that in the embodiment of the present application, by respectively arranging two mutually redundant flash memories on each motherboard node of the multi-node server on the management board and the motherboard node, and additionally arranging a cache memory and a logic device for caching the target firmware on the management board, a heterogeneous collaborative upgrade architecture is realized. Moreover, by setting the flash memories corresponding to each node on the management board, centralized management of the flash memories can be achieved, the firmware versions of each node in the multi-node server can be aligned and managed with very few material changes, the firmware upgrade efficiency is improved, a large amount of system operation and maintenance time is saved, and the impact on user services is reduced.

[0062] The embodiment of the present application also provides a firmware management device. For the description of the features in the corresponding embodiment of the firmware management device, reference can be made to the relevant description of the corresponding embodiment of the firmware management method, which will not be elaborated here one by one.

[0063] The embodiment of the present application also provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the foregoing embodiments of the firmware management method.

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

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

[0066] The embodiment of the present application also provides a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any one of the foregoing embodiments of the firmware management method.

[0067] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium storing a computer program, where the computer program, when executed by a processor, implements the steps in any of the above firmware management method embodiments.

[0068] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner 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 to exceed the scope of the present application.

[0069] The above has introduced in detail a firmware management system, method, product, and device provided by the present application. Specific examples have been used herein to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the present application.

Claims

1. A firmware management system, characterized in that, Comprising: A first firmware component located in each motherboard node of a multi-node server, 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, configured to receive the firmware upgrade request forwarded by the first firmware component, and control an interface switching component to switch the interface of a cache memory on the management board to the first firmware component, and send a switching result to the first firmware component; The first firmware component is further configured to receive the switching result sent by the logic device, and when the switching result indicates successful switching, use a target firmware to simultaneously upgrade the firmware in a first flash memory and the cache memory in the corresponding motherboard 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 a second firmware component in the corresponding motherboard node to control the component to be upgraded to restart.

2. The firmware management system according to claim 1, wherein The logic device includes: A reading module, configured to read the upgraded firmware from the cache memory; A verification module, configured to verify the upgraded firmware to obtain a verification result; A copying module, configured to, if the verification result indicates that the upgraded firmware passes the verification, uniformly copy the upgraded firmware to the second flash memories corresponding to each of the first flash memories.

3. The firmware management system according to claim 2, wherein The verification module includes: A first parsing unit, configured to parse the upgraded firmware during the 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 based on the plaintext key using a secure hash algorithm to obtain a hash operation result; A comparison 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, configured to, if the comparison result indicates that the hash operation result matches the hash message authentication code, generate a verification result indicating that the upgraded firmware passes the verification.

4. The firmware management system according to claim 3, wherein The reading module includes: A reading unit, configured to read the upgraded firmware from the cache memory in accordance with a preset data block size to obtain a plurality of firmware data blocks; Correspondingly, the first parsing unit includes: 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.

5. The firmware management system according to claim 4, characterized in that The second parsing unit includes: A third parsing unit, configured to parse the firmware data blocks based on an address bus, a data bus, and control signals of the cache memory during the reading process to obtain a hash message authentication code corresponding to the upgraded firmware.

6. The firmware management system according to claim 4, wherein The loading and operation unit includes: A loading unit, configured to load an encrypted key pre-stored in the logic device; A decryption unit, configured to perform a decryption operation on the encrypted key to obtain a plaintext key; A hash operation unit is configured to perform hash operations on each of the firmware data blocks in sequence based on the plaintext key and using a secure hash algorithm to obtain hash operation results.

7. The firmware management system according to claim 3, wherein The logic device is further configured to, if the comparison result indicates that the hash operation result does not match the hash message authentication code, generate a verification result indicating that the verification of the upgraded firmware fails, and send a re-burning notice to the first firmware component. Correspondingly, the first firmware component is further configured to receive the re-burning notice sent by the logic device, obtain a new target firmware, and trigger the step of upgrading the firmware in the first flash memory and the firmware in the cache memory in the corresponding motherboard node simultaneously using the target firmware to generate a new verification result. If each of the new verification results generated within a preset time indicates verification failure, or the number of consecutive new verification results that are verification failures reaches a preset failure count, the current firmware upgrade process is stopped, and an alarm message indicating firmware upgrade failure is generated.

8. The firmware management system according to claim 1, wherein The first firmware component is further configured to, if the parsing result indicates a switching failure, upgrade the firmware in the first flash memory using the target firmware, and send an upgrade completion notice to the logic device after the upgrade is completed.

9. The firmware management system according to any one of claims 1 to 8, characterized in that The first firmware component is a management controller, the interface switching component is a multiplexer, and the second firmware component is a programmable logic device.

10. The firmware management system according to claim 9, 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 strategy, and control the management controller to restart from the target flash memory.

11. The firmware management system according to claim 10, wherein 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 the target flash memory. Wherein, the default flash memory is the second flash memory.

12. The firmware management system according to claim 10, wherein The programmable logic device is further configured to detect whether the management board is present; if the management board is present, use the second flash memory as the target flash memory; if the management board is not present, use the first flash memory as the target flash memory.

13. The firmware management system according to claim 10, characterized in that, The programmable logic device is further configured to, if it receives a memory switching instruction including a specified flash memory sent by the management controller, use the specified flash memory as the target flash memory, 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 and the second flash memory.

14. The firmware management system according to claim 10, wherein It further includes: A first condition monitoring module configured to monitor the health status of the management controller in real time to obtain the controller health status. A first judgment module configured to judge whether the management controller is abnormal based on the controller health status. A first control module configured to, if the management controller is abnormal, control the management controller to restart from another flash memory other than the target flash memory.

15. The firmware management system according to claim 14, wherein The first condition monitoring module includes: The first condition monitoring unit is used to monitor the health status of the management controller in real time through a watchdog timer to obtain the controller health status; Correspondingly, the first control module includes: The first control unit is used to determine that the management controller is abnormal if the output level of a preset pin does not flip when reaching the interruption interval of the watchdog timer, and control the management controller to restart from another flash memory except the target flash memory.

16. The firmware management system according to claim 9, wherein It further includes: The second condition monitoring module is used to monitor the health status of the logic device in real time to obtain the device health status; The second judgment module is used to judge whether the logic device is abnormal based on the device health status; The second control module is used to control the management controller to restart from the first flash memory if the logic device is abnormal.

17. The firmware management system according to claim 16, wherein The second control module includes: The statistics unit is used to count the duration of the logic device in a hung state to obtain the hung duration if the logic device is in a hung state; The judgment unit is used to judge whether the hung duration exceeds a preset duration; The second control unit is used to control the management controller to restart from the first flash memory if the hung duration exceeds the preset duration.

18. A firmware management method, characterized in that, Applied to a multi-node server, the multi-node server includes a management board and multiple main board nodes. Each main board 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. The method includes: When the first firmware component receives a firmware upgrade request, forward the firmware upgrade request to the logic device to switch the interface of the cache memory to the first firmware component through the interface switching component, and send a switching result to the first firmware component; After the first firmware component receives the switching result, parse the switching result. If the parsing result indicates that the switching is successful, use the target firmware to upgrade the firmware in both the first flash memory and the cache memory at the same time, and send an upgrade completion notification to the logic device after the upgrade is completed; After the logic device receives the upgrade completion notification, read the upgraded firmware in the cache memory, uniformly copy the upgraded firmware to the second flash memories corresponding to each first flash memory, and send a component restart notification to the second firmware component to control the components to be upgraded to restart.

19. A computer program product, comprising a computer program / instructions, characterized in that, The computer program / instructions, when executed by a processor, implement the firmware management method described in claim 18.

20. An electronic device, characterized in that, It includes a processor and a memory; wherein, when the processor executes the computer program saved in the memory, it implements the firmware management method described in claim 18.

Images