Method for updating firmware of an expansion card and electronic device

Abstract

The application discloses a firmware updating method of an expansion card and an electronic device. A controller receives a firmware updating task. A target firmware version number corresponding to a first expansion card is compared with a current firmware version number to obtain a comparison result. In a case where the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, a firmware image file of the first expansion card is written into a firmware storage space of the first expansion card, and a firmware loading instruction is sent to the first expansion card, so that the first expansion card loads the firmware image file. In the process of loading the firmware image file by the first expansion card, the current firmware version number corresponding firmware is used for service processing. After the first expansion card completes loading the firmware image file, the target firmware version number corresponding firmware is used for service processing. Resources used for loading the firmware image file by the first expansion card and resources used for service processing by the first expansion card are isolated.

Description

Technical Field

[0001] This application relates to the field of firmware update technology, and in particular to firmware update methods and electronic devices for expansion cards. Background Technology

[0002] With the rapid development of artificial intelligence, high-performance computing, and cloud computing, modern servers are integrating an increasing number of expansion cards, including network interface cards (NICs), graphics processors (GPUs), and storage controllers. These expansion cards all rely on firmware to implement their core functions. As the underlying software running on the device hardware, firmware typically requires periodic updates. Currently, updating the firmware of expansion cards requires dedicated update tools and processes from different manufacturers and for different types of expansion cards. Furthermore, these update tools and processes need to run within the host operating system, inevitably impacting the expansion card's operational processes. Therefore, how to manage firmware updates for expansion cards in servers without affecting business operations has become a pressing issue. Summary of the Invention

[0003] This application provides a firmware update method and electronic device for expansion cards, so as to at least solve the problem in the related art of how to manage firmware updates of expansion cards in servers without affecting business processing.

[0004] This application provides a firmware update method for an expansion card, including: The controller receives firmware update tasks, which include the target firmware version number and firmware image file corresponding to the first expansion card. The target firmware version number corresponding to the first expansion card is compared with the current firmware version number to obtain the comparison result; If the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card, and a firmware loading command is sent to the first expansion card so that the first expansion card can load the firmware image file. Specifically, during the loading of the firmware image file by the first expansion card, business processing is performed using the firmware corresponding to the current firmware version number, and after the first expansion card has finished loading the firmware image file, business processing is performed using the firmware with the target firmware version number. The resources used by the first expansion card to load the firmware image file and the resources used by the first expansion card to perform business processing are isolated.

[0005] This application also provides a firmware update device for an expansion card, comprising: The acquisition module is used to receive firmware update tasks through the controller. The firmware update task includes the target firmware version number corresponding to the first expansion card and the firmware image file. The processing module is used to compare the target firmware version number corresponding to the first expansion card with the current firmware version number to obtain the comparison result; The processing module is also used to write the firmware image file of the first expansion card into the firmware storage space of the first expansion card when the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, and to send a firmware loading instruction to the first expansion card so that the first expansion card loads the firmware image file. Specifically, during the loading of the firmware image file by the first expansion card, business processing is performed using the firmware corresponding to the current firmware version number, and after the first expansion card has finished loading the firmware image file, business processing is performed using the firmware with the target firmware version number. The resources used by the first expansion card to load the firmware image file and the resources used by the first expansion card to perform business processing are isolated.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the firmware update method of any of the above-described expansion cards.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the firmware update method for any of the above-described expansion cards.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the firmware update method for any of the above-described expansion cards.

[0009] According to this application, a controller receives a firmware update task, which includes a target firmware version number corresponding to the first expansion card and a firmware image file. The target firmware version number corresponding to the first expansion card is compared with the current firmware version number to obtain a comparison result. If the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card, and a firmware loading command is sent to the first expansion card to load the firmware image file. During the loading of the firmware image file by the first expansion card, business processing is performed using the firmware corresponding to the current firmware version number, and after the first expansion card has finished loading the firmware image file, business processing is performed using the firmware corresponding to the target firmware version number. The resources used by the first expansion card to load the firmware image file are isolated from the resources used for business processing by the first expansion card. In this scheme, the controller can directly write the firmware image file into the firmware storage space of the first expansion card, allowing the expansion card to load and update it. Furthermore, the resources for firmware updates are isolated from the resources for business processing, enabling the expansion card to perform out-of-band firmware updates independently of the host business processing. The firmware update process does not affect the normal business processing flow, thus achieving full-process management and independent updates of the expansion card firmware. Attached Figure Description

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

[0011] Figure 1 A system architecture diagram of a firmware update method for an expansion card provided in this application embodiment; Figure 2 A flowchart of a firmware update method for an expansion card provided in this application embodiment. Figure 1 ; Figure 3 A flowchart of a firmware update method for an expansion card provided in this application embodiment. Figure 2 ; Figure 4 A schematic diagram illustrating the information reporting and task distribution process of a firmware update method for an expansion card provided in this application embodiment; Figure 5 A flowchart illustrating the firmware version update method for an expansion card provided in this application embodiment; Figure 6 A structural diagram of a firmware update device for an expansion card provided in an embodiment of this application; Figure 7This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

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

[0014] With the rapid development of artificial intelligence, high-performance computing, and cloud computing, modern servers are integrating an increasing number of expansion cards. A typical server may contain 1-2 network interface cards (NICs) for network communication, 4-8 graphics processors (GPUs) for parallel computing acceleration, and multiple storage controllers and other accelerator devices. These expansion cards all rely on firmware configured within them to implement their core functions. Firmware, as the underlying software running on the device hardware, is responsible for hardware initialization, function implementation, and performance optimization. Device manufacturers typically release firmware updates regularly to fix security vulnerabilities, improve performance, or add new features.

[0015] Currently, the main technical problems in updating and managing the firmware of expansion cards in servers are as follows: Fragmented update methods: Different manufacturers and types of expansion cards often use their own dedicated update tools and processes. Administrators need to log into the operating system and execute different commands for different expansion cards, resulting in low management efficiency and a high risk of errors.

[0016] Dependence on the host operating system: Current firmware updates typically require running agents or dedicated tools within the host operating system. This means that firmware update operations share the same environment and resources as business processes. If an anomaly occurs during the firmware update process (such as a system crash or driver conflict), it will affect business processes, potentially leading to business interruptions or even server startup failures.

[0017] Lack of out-of-band management support: Current device management can generally be divided into out-of-band management and in-band management. In-band management can be understood as management control information and service data being transmitted through the same physical / logical channel, sharing the service network, and management traffic occupying service bandwidth; out-of-band management can be understood as management control information and service data being transmitted through different physical / logical channels, having independent dedicated channels, and management and service are physically isolated.

[0018] Currently, most remote device management is achieved through in-band management, such as remote desktop access for servers. These methods rely on the device's operating system for management and maintenance, and may fail to provide remote maintenance when system malfunctions. Out-of-band management, on the other hand, is a hardware-based approach. It uses dedicated hardware modules or special remote management cards to provide a management interface and performs remote maintenance and management of devices through dedicated data channels. This is completely independent of the device's operating system and can even be performed remotely while the device is powered off. Most servers now provide out-of-band management interfaces to ensure the security of core devices. However, current out-of-band management solutions primarily focus on firmware updates for the Baseboard Management Controller (BMC) itself, lacking support for out-of-band updates of expansion cards such as network interface cards (NICs) and graphics processing units (GPUs).

[0019] Service interruption during updates: Firmware updates for most expansion cards require a device reboot to take effect, while traditional solutions often require a complete server reboot. For devices such as GPUs, the BMC in existing solutions can upload firmware, but a full system reboot is still required for the update. For servers carrying critical business operations, a complete reboot is extremely costly.

[0020] Security shortcomings: The firmware update process is usually controlled by tools on the host and lacks an independent verification mechanism. Once the host is compromised, attackers can use the update tools to implant malicious firmware into the expansion card, achieving persistent residency.

[0021] Lack of centralized management and auditing: In large data centers, it is difficult to manage and track the firmware versions of expansion cards for hundreds of servers in a unified manner. Administrators cannot easily obtain firmware version information for each device, nor can they ensure that the firmware of all devices is in a secure and compliant state.

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

[0023] like Figure 1 As shown, Figure 1The system architecture diagram for the firmware update method of the expansion card provided in this application embodiment includes at least: a host processor, at least one expansion card, a BMC, at least one management controller (Micro Controller Unit, MCU), and a firmware management platform. The expansion card can be of various types and includes firmware storage space for storing the firmware image file required for firmware updates. The host processor can be considered the service side of the expansion card, used to run the server's operating system and applications. The host processor and each expansion card can be connected via a management bus. The BMC and MCU run on the management side of the expansion card.

[0024] It should be noted that the BMC is the core component for out-of-band management of the expansion card. Physically independent of the host processor, it connects to a dedicated management network and firmware management platform, enabling data transmission with the remote management platform, which can be understood as the cloud. The BMC includes a communication interface, a firmware storage module, and a control module. The BMC can obtain firmware update tasks from the firmware management platform through the communication interface and report the expansion card's version number, status, etc., to the platform. Additionally, the BMC can store the expansion card's firmware image file obtained from the firmware management platform into the firmware storage module. The control module interacts with the MCU and manages and coordinates the entire expansion card firmware update process.

[0025] It should be noted that at least one MCU is physically independent of the host processor and BMC, connecting to at least one expansion card via a dedicated management bus or switching chip, and connecting to the BMC via a board-level communication bus. The number of MCUs can be at least one; that is, one MCU can be configured to connect to each expansion card, or a separate MCU can be configured for each type of expansion card. Figure 1 The example shows three MCUs: MCU1 as a GPU manager, connecting and managing expansion card 1 (GPU); MCU2 as a network card manager, connecting and managing expansion card 2 (network card); and MCU3 as a memory card manager, connecting and managing expansion card 3 (memory card). Of course, more MCUs can be set up; or only one MCU can be set up to connect expansion card 1, expansion card 2 and expansion card 3 respectively. This application embodiment does not make specific limitations.

[0026] Each MCU can include: a device discovery module, a firmware verification module, an update control module, and a firmware storage module. The device discovery module is used to identify the expansion cards it is connected to and obtain the device information and current firmware version of each expansion card. The firmware verification module is used to perform digital signature verification on the firmware image file before firmware update to ensure the legality and integrity of the firmware source, and to perform integrity verification on the firmware of the expansion card after firmware update. The update control module is used to send firmware update commands to the expansion card, transmit the firmware image file, and monitor the firmware update process of the expansion card. The firmware storage module is used to store the firmware image file received from the BMC.

[0027] like Figure 2 As shown, Figure 2 A flowchart illustrating a firmware update method for an expansion card provided in an embodiment of this application, the firmware update method for the expansion card may include the following steps: 201. Receive firmware update tasks via the controller.

[0028] In this embodiment of the application, the controller can refer to Figure 1 The BMC and / or MCU in the controller receive a firmware update task, which includes the target firmware version number corresponding to the first expansion card and the firmware image file.

[0029] It should be noted that there is no limit to the number of the first expansion cards. The first expansion card can be understood as the expansion card connected and managed by the controller. The target firmware version number is the firmware version number that the first expansion card needs to reach. The firmware image file can be a data file of firmware that supports the target firmware version number. In order for the first expansion card to reach the target firmware version number, the first expansion card needs to write and load the firmware image file.

[0030] 202. Compare the target firmware version number corresponding to the first expansion card with the current firmware version number to obtain the comparison result.

[0031] In this embodiment, the first expansion card definitely has firmware during normal operation. Therefore, the current firmware version number of the first expansion card can be obtained. This current firmware version number is the version number of the firmware currently configured in the first expansion card. It's conceivable that not all first expansion cards have firmware updates; some may not have updated firmware, but they still receive the target firmware version number. Therefore, it's necessary to compare the target firmware version number and the current firmware version number corresponding to the first expansion card to obtain the comparison result. For first expansion cards where the target firmware version number and the current firmware version number are the same, there's no need for further steps. This comparison result indicates whether the target firmware version number and the current firmware version number are the same or different.

[0032] 203. If the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, write the firmware image file of the first expansion card into the firmware storage space of the first expansion card, and send a firmware loading command to the first expansion card so that the first expansion card loads the firmware image file.

[0033] In this embodiment, if the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, it means that the firmware configured in the first expansion card has been updated. Therefore, the controller can write the firmware image file of the first expansion card into the firmware storage space of the first expansion card and send a firmware loading instruction to the first expansion card. The firmware loading instruction is used to instruct the first expansion card to load the firmware image file to realize the firmware update. After receiving the firmware loading instruction, the first expansion card can start loading the firmware image file. Once the firmware image file is loaded, the firmware update of the first expansion card is complete.

[0034] Specifically, during the loading of the firmware image file by the first expansion card, business processing is performed using the firmware corresponding to the current firmware version number, and after the first expansion card has finished loading the firmware image file, business processing is performed using the firmware with the target firmware version number. The resources used by the first expansion card to load the firmware image file and the resources used by the first expansion card to perform business processing are isolated.

[0035] Depend on Figure 1 As can be seen, for the expansion card, its host processor controls the service side to perform data processing, while the BMC and MCU control the management side to perform firmware updates. To ensure that the firmware update process does not affect the service side's data processing, the resources for loading the firmware image file and the resources for service processing on the first expansion card can be isolated. This ensures that the service side and management side do not interfere with each other and resources are not mixed. In addition, the process of loading the firmware image file on the first expansion card can be considered as the firmware update process. At this time, the firmware that can run normally on the first expansion card is still the firmware corresponding to the current firmware version number. Therefore, during the process of loading the firmware image file on the first expansion card, service processing is still performed using the firmware corresponding to the current firmware version number before the firmware update. After the first expansion card finishes loading the firmware image file, the firmware that can run normally on the first expansion card has been updated to the firmware corresponding to the target firmware version number. At this time, service processing can be performed using the firmware corresponding to the target firmware version number after the firmware update. This ensures that there is a complete and normal firmware to support service side data processing in the three stages of loading, without affecting service operation.

[0036] In this embodiment, a controller receives a firmware update task, which includes a target firmware version number corresponding to the first expansion card and a firmware image file. The target firmware version number corresponding to the first expansion card is compared with the current firmware version number to obtain a comparison result. If the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card, and a firmware loading command is sent to the first expansion card to load the firmware image file. During the loading of the firmware image file by the first expansion card, business processing is performed using the firmware corresponding to the current firmware version number, and after the first expansion card has finished loading the firmware image file, business processing is performed using the firmware corresponding to the target firmware version number. The resources used by the first expansion card to load the firmware image file are isolated from the resources used for business processing by the first expansion card. In this scheme, the controller can directly write the firmware image file into the firmware storage space of the first expansion card, allowing the expansion card to load and update it. Furthermore, the resources for firmware updates are isolated from the resources for business processing, enabling the expansion card to perform out-of-band firmware updates independently of the host business processing. The firmware update process does not affect the normal business processing flow, thus achieving full-process management and independent updates of the expansion card firmware.

[0037] like Figure 3 As shown, Figure 3 Another flowchart of a firmware update method for an expansion card provided in an embodiment of this application, the firmware update method for the expansion card may further include the following steps: 301. Obtain the presence signal of each expansion card.

[0038] In this embodiment of the application, before receiving the firmware update task, it is necessary to determine how many expansion cards are connected in total, which expansion cards are in the present state, and which expansion cards are offline and not connected. Therefore, the present signal of each expansion card can be obtained. Since the MCU and the expansion card can be connected through the management bus, the MCU can actively scan through the management bus or obtain the present signal of each expansion card by listening to the hot-plug event of the expansion card. The present signal can indicate whether the expansion card is in the present state or not in the present state.

[0039] 302. Based on the presence signals of each expansion card, determine the first expansion card that is in the presence state.

[0040] In this embodiment of the application, after obtaining the presence signal of each expansion card, the presence signal can be parsed to determine the first expansion card that is in the presence state. For expansion cards that are not in the presence state, no subsequent firmware update is performed, and only the first expansion card that is in the presence state is updated.

[0041] 303. Read the current firmware version number corresponding to the first expansion card.

[0042] In this embodiment of the application, after the first expansion card is determined, the current firmware version number of the first expansion card can be read. The current firmware version number is the version number of the firmware currently running on the first expansion card, which can be read directly through the management bus.

[0043] In some embodiments, the MCU can acquire the presence signal of each expansion card by receiving a device discovery instruction from the BMC. That is, after the server is powered on, the BMC can first send a device discovery instruction to the MCU. This device discovery instruction is used to instruct the MCU to discover the first expansion card that is connected to it. Therefore, after receiving the device discovery instruction, the MCU can acquire the presence signal of each expansion card to determine the first expansion card.

[0044] In some embodiments, reading the current firmware version number corresponding to the first expansion card may specifically include: sending firmware version query commands to the first expansion card respectively; receiving firmware version data reported by the first expansion card respectively; and parsing the firmware version data to obtain the current firmware version number corresponding to the first expansion card.

[0045] It should be noted that when the MCU reads the current firmware version number corresponding to the first expansion card, it can do so through the management bus. Specifically, it can send a firmware version query command to the first expansion card through the management bus. This firmware version query command tells the first expansion card that it is currently querying its own firmware version number, so that the first expansion card can upload the version number of the firmware it is running. At this time, the MCU can receive the firmware version data reported by the first expansion card, and then parse the firmware version data to obtain the current firmware version number corresponding to the first expansion card.

[0046] 304. Report the identifier of the first expansion card to the firmware management platform.

[0047] In this embodiment of the application, after determining that the first expansion card is in the present state, the MCU can report the first expansion card to the firmware management platform so that the firmware management platform can issue a firmware update task to the first expansion card. Therefore, the identifier of the first expansion card can be reported to the firmware management platform.

[0048] In some embodiments, since the discovery of the first expansion card is performed by the MCU, and there is only an interaction channel between the BMC and the firmware management platform, the MCU can first report the identifier of the first expansion card to the BMC, and then the BMC can report the identifier of the first expansion card to the firmware management platform.

[0049] 305. Receive firmware update tasks issued by the firmware management platform.

[0050] In this embodiment of the application, after receiving the identifier of the first expansion card, the firmware management platform knows that the currently in-place expansion card is the first expansion card. Then, the firmware management platform can determine what firmware version number the first expansion card needs to reach, and then issue a firmware update task.

[0051] In some embodiments, since the interaction channel exists only between the BMC and the firmware management platform, the firmware management platform can send a firmware update task to the BMC, which then sends the task to the MCU. The MCU parses the firmware update task to obtain the target firmware version number and firmware image file corresponding to the first expansion card. Alternatively, the BMC can parse the firmware update task to obtain the target firmware version number and firmware image file corresponding to the first expansion card, and then send these two files to the MCU. The MCU ultimately obtains the target firmware version number and firmware image file corresponding to the first expansion card.

[0052] 306. Obtain the historical firmware version number corresponding to the first expansion card.

[0053] 307. Compare the target firmware version number corresponding to the first expansion card with the current firmware version number to obtain the first comparison result corresponding to the first expansion card.

[0054] 308. Compare the target firmware version number and the historical firmware version number corresponding to the first expansion card to obtain the second comparison result corresponding to the first expansion card.

[0055] In this embodiment, during the continuous operation of the first expansion card, its configured firmware needs to be constantly updated. Each firmware update changes the firmware version number, and it increments according to a certain pattern. For example, the firmware version number might start at 1.0, become 2.0 after one update, and then become 3.0 after another update. It's conceivable that to distinguish each firmware update, the firmware version number after each update is a completely new version number, not the same as the previous one. Even if the firmware image file required for the firmware update may have the same content, the version number will be different. Therefore, in addition to comparing the target firmware version number with the current firmware version number, it is also necessary to compare the target firmware version number with the first expansion card. The firmware version numbers of the expansion card are compared with those of previous versions. In other words, the historical firmware version numbers of the first expansion card need to be obtained. These historical firmware version numbers are all the firmware version numbers that the first expansion card has updated in the past. At this time, in addition to comparing the target firmware version number with the current firmware version number to obtain the first comparison result, the target firmware version number also needs to be compared with the historical firmware version number to obtain the second comparison result. The second comparison result can indicate whether the target firmware version number and the historical firmware version number are the same. For the first expansion card, the target firmware version number is compared with the current firmware version number and the historical firmware version number respectively, so as to obtain the first comparison result and the second comparison result of the first expansion card.

[0056] 309. If the first comparison result indicates that the target firmware version number is inconsistent with the current firmware version number, and the second comparison result indicates that the target firmware version number is inconsistent with the historical firmware version number, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card, and a firmware loading command is sent to the first expansion card so that the first expansion card loads the firmware image file.

[0057] In this embodiment of the application, when there are first comparison results and second comparison results for the first expansion card, when screening whether the first expansion card needs a firmware update, it is necessary to combine the first comparison results and the second comparison results to make a judgment. For the first expansion card that needs a firmware update, its target firmware version number must be a brand new firmware version number, which is different from the current firmware version number and also different from the historical firmware version number. Therefore, it is necessary to screen out the first expansion card whose target firmware version number is different from the current firmware version number and also different from the historical firmware version number.

[0058] In some embodiments, when screening the first expansion card, it is necessary to select the first expansion card whose target firmware version number is a brand new firmware version number, which is different from the current and historical firmware version numbers. This can accurately determine the first expansion card that actually has a firmware update, and avoid the situation where the update is a backward update to a historical firmware version.

[0059] In some embodiments, writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card may specifically include: performing signature verification on the firmware image file to obtain a verification result; and writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card if the verification result indicates that the verification is successful.

[0060] It should be noted that after the MCU obtains the firmware image file, since the firmware image file has already undergone transmission and parsing between the firmware management platform and the BMC, as well as transmission between the BMC and the MCU, in order to avoid abnormal situations during transmission, the MCU can first verify the firmware image file before writing it to the firmware storage space of the first expansion card. Only if the verification passes can it be written to the firmware storage space of the first expansion card. This verification can be a signature verification of the firmware image file, obtaining the digital signature of the firmware image file and verifying it. Of course, other verification methods can also be used, such as hash algorithms. If the verification result indicates that the verification passed, it means that the current firmware image file is a complete and tamper-proof file, and then the firmware image file of the first expansion card can be written to the firmware storage space of the first expansion card.

[0061] In some embodiments, before writing the firmware image file into the firmware storage space of the first expansion card, the MCU can perform signature verification on the firmware image file to ensure that the firmware image file is intact and has not been tampered with, while also ensuring that the source of the firmware image file is trustworthy, and to the greatest extent possible, ensuring that writing the firmware image file into the firmware storage space of the first expansion card will not affect the security of the first expansion card.

[0062] In some embodiments, writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card may specifically include: obtaining the data volume of the firmware image file; determining the file transfer method corresponding to the data volume based on the data volume; and writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card according to the file transfer method.

[0063] It should be noted that the connection between the MCU and each expansion card can include multiple methods. This means that when the MCU writes the firmware image file of the first expansion card into the firmware storage space of the first expansion card, it can use multiple file transfer methods. The selection of the corresponding file transfer method can be based on the size of the firmware image file. Therefore, the MCU can obtain the data volume of the firmware image file and determine the file transfer method corresponding to that data volume. The file transfer method for firmware image files with larger data volumes is different from that for firmware image files with smaller data volumes. After determining the file transfer method, the firmware image file of the first expansion card can be written into the firmware storage space of the first expansion card according to that file transfer method.

[0064] Furthermore, based on the data volume, the corresponding file transfer method is determined. Specifically, this may include: when the data volume is greater than or equal to a preset data volume threshold, the corresponding file transfer method is determined to be the write method via the switching chip; when the data volume is less than the preset data volume threshold, the corresponding file transfer method is determined to be the transfer method via the management bus.

[0065] It should be noted that, in determining the file transfer method corresponding to the data volume, a preset data volume threshold can be set to accurately measure the data volume. If the data volume of the firmware image file is greater than or equal to the preset data volume threshold, it indicates that the current firmware image file is a large file and requires high bandwidth transmission. The file transfer method can be determined to be the write method via a switching chip. This switching chip can be a PCIeDMA chip. The MCU acts as the PCIe master device and directly writes the firmware image file into the firmware storage space of the first expansion card via the PCIe DMA chip. This method is suitable for the transmission and rapid updates of large-capacity firmware and large-volume files. Conversely, if the data volume of the firmware image file is less than the preset data volume threshold, it indicates that the current firmware image file is a small file and can be transmitted with lower bandwidth. In this case, the file transfer method is determined to be the transfer method via the management bus. This management bus can include various types of buses such as I2C, I3C, and SMBus. This method is suitable for the transmission of smaller data volume files.

[0066] In some embodiments, the matching switching chip or management bus is selected based on the actual size of the firmware image file, and the firmware image file is written into the firmware storage space of the first expansion card. This can adapt to various firmware update scenarios, improve the efficiency of file writing and firmware updates, and avoid wasting bandwidth resources.

[0067] In some embodiments, writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card may specifically include: obtaining the hot update configuration parameters of the first expansion card; and writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card when the hot update configuration parameters indicate that the first expansion card supports hot updates.

[0068] It should be noted that for the expansion card, it not only needs to connect to the host processor to complete data processing on the service side, but also needs to connect to the MCU to complete firmware updates on the management side. The first expansion card can simultaneously support data processing on the service side and firmware updates on the management side through resource isolation. That is to say, during the process of the first expansion card loading the firmware image file for firmware update, it can synchronously interact with the host processor for data processing. This synchronous process is called hot update. Therefore, the hot update configuration parameters of the first expansion card can be obtained first. The hot update configuration parameters are attribute information carried by each expansion card and can be read directly. The hot update configuration parameters can be used to indicate whether the first expansion card supports hot update. If the hot update configuration parameters indicate that the first expansion card supports hot update, it means that the current first expansion card can simultaneously perform data processing on the service side and firmware updates on the management side. Then, without any other operations, the MCU can directly write the firmware image file of the first expansion card into the firmware storage space of the first expansion card.

[0069] Furthermore, for expansion cards that do not support hot updates, the method may also include: when it is detected that the hot update configuration parameters of the second expansion card indicate that the second expansion card does not support hot updates, sending a data processing pause command to the second expansion card so that the second expansion card pauses data processing based on the data processing pause command; and upon receiving the data processing pause confirmation information reported by the second expansion card, writing the firmware image file of the second expansion card into the firmware storage space of the second expansion card.

[0070] It should be noted that, besides the first expansion card which can simultaneously support data processing on the service side and firmware updates on the management side, some expansion cards cannot simultaneously support data processing on the service side and firmware updates on the management side. They either load a firmware image file for firmware updates or interact with the host processor for data processing. For these expansion cards, data processing needs to be paused before a firmware update. Therefore, when the hot update configuration parameters of the second expansion card indicate that it does not support hot updates, it means that the second expansion card cannot simultaneously perform data processing on the service side and firmware updates on the management side. To perform a firmware update, data processing must be paused first. Since the data processing of the second expansion card consists of data processing tasks issued by the host processor, and the host processor only connects to the expansion card, the MCU can send a data processing pause command to the second expansion card. The pause command is used to instruct the second expansion card to pause data processing. Upon receiving the pause command, the second expansion card can pause data processing accordingly. This can be achieved by sending an interrupt notification to the host processor, informing it that a firmware update is required and data processing needs to be paused, thus preventing the host processor from issuing new tasks. After confirming that data processing has been paused, the second expansion card can report the pause confirmation information to the MCU, indicating that data processing is no longer in progress and the firmware update can proceed. Therefore, upon receiving the pause confirmation information from the second expansion card, the MCU can write the firmware image file of the second expansion card into its firmware storage space and initiate the loading of the firmware image file by the second expansion card.

[0071] In some embodiments, after the second expansion card has finished loading the firmware image file and completed the firmware upgrade, a continuation notification can be sent to the host processor again to inform the host processor that the current firmware update is complete and data processing can continue, and the host processor can continue to issue new tasks.

[0072] In some embodiments, for the first expansion card that supports hot updates, the firmware image file can be written directly. For the second expansion card that does not support hot updates, data processing needs to be paused for firmware updates. This ensures the smooth completion of firmware updates and avoids confusion between data processing on the business side and firmware updates on the management side, which could lead to business-side failures.

[0073] In some embodiments, writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card may specifically include: when there are multiple first expansion cards, obtaining the firmware update priority of each first expansion card, wherein the firmware update priority is determined according to the type of the first expansion card, the size of the firmware image file and the current load; and writing the firmware image file of each first expansion card into the firmware storage space of each first expansion card in sequence according to the firmware update priority.

[0074] It should be noted that the MCU can connect to multiple expansion cards, and there can be at least one primary expansion card in use. This means that among the expansion cards connected to the MCU, there may be only one primary expansion card requiring a firmware update, or there may be multiple primary expansion cards requiring firmware updates. If there are multiple primary expansion cards, the MCU needs to write the firmware image files to the corresponding primary expansion card's firmware storage space sequentially. Therefore, there will be a certain firmware update priority order among the multiple primary expansion cards; the higher the firmware update priority, the earlier the MCU writes the firmware image file. Thus, the MCU can obtain the firmware update priority of each primary expansion card and write the firmware image files to the corresponding primary expansion card's firmware storage space sequentially according to this priority.

[0075] It should be noted that the firmware update priority can be determined based on the type of the first expansion card, the size of the firmware image file, and the current load. Different types of expansion cards have different priorities, which can be set according to the purpose of each expansion card. Similarly, firmware image files of different sizes also have different priorities. It's conceivable that larger firmware image files require longer writing times, while smaller firmware image files require shorter writing times. Therefore, smaller firmware image files can be written first, meaning the first expansion card corresponding to a smaller firmware image file has a higher priority than the first expansion card corresponding to a larger firmware image file. Of course, this firmware update priority can also be adjusted according to the current load.

[0076] In some embodiments, combined with Figure 1 As can be seen from the architecture diagram, the firmware image files received by the MCU can be sent by the BMC. When the BMC sends firmware image files to the MCU, there is also a priority order for each first expansion card. Therefore, the BMC can send the firmware image files of each first expansion card to the MCU in sequence according to the firmware update priority of each first expansion card. After receiving the firmware image file of each first expansion card, the MCU can directly write it into the firmware storage space of the first expansion card, and then receive the firmware image file of the next first expansion card.

[0077] Of course, the BMC can directly send the firmware image files of all the first expansion cards to the MCU. Then, when the MCU writes the firmware image files to the firmware storage space of the first expansion cards, it writes them sequentially according to the firmware update priority. If the MCU receives a firmware image file of a first expansion card with a lower firmware update priority while writing one of the first expansion cards to the firmware storage space, it will continue to write the firmware image file of the first expansion card with the higher firmware update priority. However, if it receives a firmware image file of a first expansion card with a higher firmware update priority, it will first pause the writing process of the first expansion card with the lower firmware update priority and then start writing the firmware image file of the first expansion card with the higher firmware update priority.

[0078] In some embodiments, by setting firmware update priorities for each first expansion card, the firmware update process can be performed sequentially, which not only improves the orderliness of the entire firmware update process, but also avoids firmware update errors caused by arbitrary firmware update order.

[0079] In some embodiments, if the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card, and a firmware loading command is sent to the first expansion card so that the first expansion card loads the firmware image file. The process may further include: during the loading of the firmware image file by the first expansion card based on the firmware loading command, monitoring the loading progress of the first expansion card in real time; when the loading progress indicates that loading is complete, obtaining the real-time firmware version number of the first expansion card after loading; and determining that the firmware update of the first expansion card is complete when the real-time firmware version number and the target firmware version number are detected to be the same.

[0080] It should be noted that after the first expansion card receives the firmware load command, it can load the firmware image file based on the command. This loading process takes a certain amount of time, and the MCU needs to know whether the first expansion card has completed the loading and whether there are any faults. Therefore, during the loading process, the MCU can monitor the loading progress in real time. This can be done by the MCU actively querying the first expansion card for the loading progress or by the first expansion card actively informing the MCU of the loading progress. After the MCU determines that the first expansion card has completed loading the firmware image file based on the loading progress, it also needs to verify whether the firmware update has been successful. Therefore, the MCU can obtain the real-time firmware version number of the first expansion card after loading. If the first expansion card has successfully loaded the firmware image file and completed the firmware update, the real-time firmware version number should be the same as the target firmware version number. Therefore, when the real-time firmware version number and the target firmware version number are detected to be the same, it can be determined that the firmware update of the first expansion card is complete.

[0081] In some embodiments, if the real-time firmware version number and the target firmware version number are different, it indicates that an abnormality has occurred in the loading process of the first expansion card, resulting in a loading error. In this case, the first expansion card can reload the firmware image file. If the real-time firmware version number and the target firmware version number of the first expansion card are still different after reloading, it may be that there is a problem with the firmware image file or that the first expansion card itself is faulty. Therefore, loading error information can be output so that the staff can check the first expansion card.

[0082] In some embodiments, by monitoring the loading progress of the first expansion card, the MCU can know in real time whether the first expansion card has been loaded, and promptly verify the firmware of the loaded first expansion card, thereby realizing real-time monitoring and effective management of the expansion card firmware update process by the MCU.

[0083] In some embodiments, if the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card, and a firmware loading instruction is sent to the first expansion card so that the first expansion card loads the firmware image file. The process may further include: during the loading of the firmware image file by the first expansion card based on the firmware loading instruction, when a loading failure information reported by the first expansion card is received, reading the firmware image file with the historical firmware version number from the firmware storage space of the first expansion card; and issuing a rollback instruction to the first expansion card based on the firmware image file with the historical firmware version number so that the first expansion card loads the firmware image file with the historical firmware version number according to the rollback instruction.

[0084] It should be noted that after the first expansion card receives the firmware load command, it can load the firmware image file based on the command. During the loading process, the first expansion card itself may have some faults, the network environment in which the first expansion card is located may be abnormal, or there may be undetected errors in the firmware image file. These may all cause the first expansion card to malfunction during the firmware image file loading process. If the first expansion card detects a fault, it can report the fault information to the MCU. Therefore, if the MCU receives the loading fault information from the first expansion card, it means that there is an abnormality in the loading process of the first expansion card. In order to ensure the normal operation of the firmware of the first expansion card, the first expansion card can first perform a rollback operation to reset the firmware version number. To roll back to a historical firmware version number, the firmware image file of the historical firmware version number can be read from the firmware storage space of the first expansion card. This historical firmware version number may be a firmware version number that the first expansion card has configured during its previous operation. Then, based on the firmware image file of the historical firmware version number, a rollback command can be sent to the first expansion card. This rollback command can be used to instruct the first expansion card to roll back the configured firmware version to the historical firmware version number. Therefore, after receiving the rollback command, the first expansion card can load the firmware image file of the historical firmware version number from the firmware storage space. After the first expansion card has finished loading the firmware image file of the historical firmware version number, the real-time firmware version number of the first expansion card is the historical firmware version number.

[0085] In some embodiments, after the MCU sends a rollback command to the first expansion card, it can also output the loading fault information so that the staff can check the first expansion card.

[0086] like Figure 4 As shown, Figure 4 This diagram illustrates the information reporting and task distribution process for the firmware update method of the expansion card provided in this application embodiment. It mainly involves the interaction between the firmware management platform, the BMC, and the MCU. First, after the server powers on, the BMC sends a device discovery command to the MCU, enabling the MCU to discover each connected expansion card. Upon receiving the device discovery command, the MCU can actively scan or listen for hot-plug events via a dedicated management bus to discover all connected expansion cards. Then, for each discovered expansion card, the MCU reads its device identifier and current firmware version number and reports it to the BMC. The BMC can summarize all received information to obtain a firmware list and report it to the firmware management platform. The firmware management platform can then issue a firmware update task to the BMC based on this firmware list. The BMC parses the firmware update task to determine the first expansion card to be updated and its corresponding firmware image file. This completes the pre-update process, and the firmware update begins.

[0087] like Figure 5 As shown, Figure 5 The firmware update flowchart of the expansion card firmware update method provided in this application embodiment mainly involves the interaction between the firmware management platform, BMC, MCU, and the first expansion card, which is the expansion card that needs to be updated. First, after receiving the firmware update task issued by the firmware management platform, the BMC can parse the firmware image file corresponding to the first expansion card. Then, the BMC can send the firmware image file to the MCU connected to the first expansion card. The MCU can store the firmware image file in the firmware storage module and then perform digital signature verification on the firmware image file. After successful verification, for the first expansion card that supports hot updates, the firmware image file can be directly written to the firmware storage space of the first expansion card. For expansion cards that do not support hot updates, the MCU will send a data processing pause command to the expansion card. After receiving the data processing pause command, the expansion card will send a data processing pause command to the main... The host processor sends an interrupt notification to the primary processor, informing it that data processing needs to be paused. After the expansion card confirms that data processing has been paused, it can report a data processing pause confirmation message to the MCU. At this point, the MCU can write the firmware image file into the firmware storage space of the expansion card. After writing is complete, the MCU can send a firmware loading command to the first expansion card, enabling the first expansion card to load the firmware image file based on this command. The MCU monitors the progress of the first expansion card loading the firmware image file in real time, and verifies the firmware version and integrity of the first expansion card after loading is complete. If the verification is successful, it can send a data processing resumption command to expansion cards that do not support hot updates, enabling the expansion card to continue data processing based on this command. The MCU can also report the firmware update results of the first expansion card to the BMC. The BMC summarizes the firmware update results of all first expansion cards and reports them together to the firmware management platform. This completes the firmware update process for the expansion card.

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

[0089] like Figure 6 As shown, embodiments of this application also provide a firmware update device for an expansion card, which may include: The acquisition module 601 is used to receive a firmware update task through the controller. The firmware update task includes the target firmware version number corresponding to the first expansion card and the firmware image file. Processing module 602 is used to compare the target firmware version number corresponding to the first expansion card with the current firmware version number to obtain the comparison result; The processing module 602 is further configured to, when the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, write the firmware image file of the first expansion card into the firmware storage space of the first expansion card, and send a firmware loading instruction to the first expansion card so that the first expansion card loads the firmware image file. Specifically, during the loading of the firmware image file by the first expansion card, business processing is performed using the firmware corresponding to the current firmware version number, and after the first expansion card has finished loading the firmware image file, business processing is performed using the firmware with the target firmware version number. The resources used by the first expansion card to load the firmware image file and the resources used by the first expansion card to perform business processing are isolated.

[0090] In some embodiments, the acquisition module 601 is further configured to acquire the presence signal of each expansion card; The processing module 602 is also used to determine the first expansion card in the present state based on the presence signal of each expansion card; The acquisition module 601 is also used to read the current firmware version number corresponding to the first expansion card.

[0091] In some embodiments, the processing module 602 is further configured to report the identifier of the first expansion card to the firmware management platform; The acquisition module 601 is also used to receive firmware update tasks issued by the firmware management platform.

[0092] In some embodiments, the processing module 602 is specifically used to send firmware version query commands to the first expansion card respectively; The acquisition module 601 is specifically used to receive firmware version data reported by the first expansion card. The processing module 602 is specifically used to parse the firmware version data to obtain the current firmware version number corresponding to the first expansion card.

[0093] In some embodiments, the acquisition module 601 is specifically used to acquire the historical firmware version number corresponding to the first expansion card; The processing module 602 is specifically used to compare the target firmware version number corresponding to the first expansion card with the current firmware version number to obtain the first comparison result corresponding to the first expansion card; The processing module 602 is specifically used to compare the target firmware version number and the historical firmware version number corresponding to the first expansion card to obtain the second comparison result corresponding to the first expansion card.

[0094] In some embodiments, the processing module 602 is specifically configured to, when the first comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, and the second comparison result indicates that the target firmware version number and the historical firmware version number are inconsistent, write the firmware image file of the first expansion card into the firmware storage space of the first expansion card, and send a firmware loading instruction to the first expansion card so that the first expansion card loads the firmware image file.

[0095] In some embodiments, the processing module 602 is specifically used to perform signature verification on the firmware image file and obtain the verification result; The processing module 602 is specifically used to write the firmware image file of the first expansion card into the firmware storage space of the first expansion card when the verification result indicates that the verification is successful.

[0096] In some embodiments, the acquisition module 601 is specifically used to acquire the data volume of the firmware image file; The processing module 602 is specifically used to determine the file transfer method corresponding to the data volume based on the data volume. The processing module 602 is specifically used to write the firmware image file of the first expansion card into the firmware storage space of the first expansion card according to the file transfer method.

[0097] In some embodiments, the processing module 602 is specifically used to determine that the file transfer method corresponding to the data volume is the write method via the switching chip when the data volume is greater than or equal to a preset data volume threshold. The processing module 602 is specifically used to determine the file transfer mode corresponding to the data volume as the transfer mode via the management bus when the data volume is less than the preset data volume threshold.

[0098] In some embodiments, the acquisition module 601 is specifically used to acquire the hot update configuration parameters of the first expansion card; The processing module 602 is specifically used to write the firmware image file of the first expansion card into the firmware storage space of the first expansion card when the hot update configuration parameters indicate that the first expansion card supports hot updates.

[0099] In some embodiments, the processing module 602 is further configured to send a data processing pause command to the second expansion card when it is detected that the hot update configuration parameters of the second expansion card indicate that the second expansion card does not support hot update, so that the second expansion card pauses data processing based on the data processing pause command; The processing module 602 is also used to write the firmware image file of the second expansion card into the firmware storage space of the second expansion card when it receives the data processing pause confirmation information reported by the second expansion card.

[0100] In some embodiments, the acquisition module 601 is specifically used to acquire the firmware update priority of each first expansion card when there are multiple first expansion cards. The firmware update priority is determined based on the type of the first expansion card, the size of the firmware image file, and the current load. The processing module 602 is specifically used to write the firmware image files of each first expansion card into the firmware storage space of each first expansion card in sequence according to the firmware update priority.

[0101] In some embodiments, the acquisition module 601 is further configured to monitor the loading progress of the firmware image file loaded by the first expansion card in real time during the process of the first expansion card loading the firmware image file based on the firmware loading instruction. The acquisition module 601 is also used to acquire the real-time firmware version number of the first expansion card after loading when the loading progress indicator shows that loading is complete; The processing module 602 is also used to determine that the firmware update of the first expansion card is complete when the real-time firmware version number and the target firmware version number are the same.

[0102] In some embodiments, the acquisition module 601 is further configured to, during the process of the first expansion card loading the firmware image file based on the firmware loading instruction, when receiving loading fault information reported by the first expansion card, read the firmware image file with the historical firmware version number from the firmware storage space of the first expansion card. The processing module 602 is also used to send a rollback command to the first expansion card based on the firmware image file with the historical firmware version number, so that the first expansion card loads the firmware image file with the historical firmware version number according to the rollback command.

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

[0104] like Figure 7 As shown, embodiments of this application also provide an electronic device, including a memory 701 and a processor 702. The memory 701 stores a computer program, and the processor 702 is configured to run the computer program to perform the steps in any of the above-described embodiments of the firmware update method for an expansion card.

[0105] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the firmware update method for an expansion card.

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

[0107] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the firmware update method embodiments of any of the above-described expansion cards.

[0108] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the firmware update method embodiments of the expansion card described above.

[0109] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, processors (CPUs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), microprocessors (MCUs), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

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

[0111] The firmware update method and electronic device for an expansion card provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A firmware update method for an expansion card, characterized in that, include: The controller receives firmware update tasks, which include the target firmware version number and firmware image file corresponding to the first expansion card. The target firmware version number corresponding to the first expansion card is compared with the current firmware version number to obtain the comparison result; If the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card, and a firmware loading instruction is sent to the first expansion card so that the first expansion card loads the firmware image file. Specifically, during the loading of the firmware image file by the first expansion card, business processing is performed using the firmware corresponding to the current firmware version number, and after the first expansion card finishes loading the firmware image file, business processing is performed using the firmware of the target firmware version number. The resources used by the first expansion card to load the firmware image file and the resources used by the first expansion card to perform business processing are isolated.

2. The firmware update method for an expansion card according to claim 1, characterized in that, Before receiving the firmware update task, the method further includes: Obtain the presence signal of each expansion card; Based on the presence signals of each expansion card, the first expansion card that is in the presence state is determined; Read the current firmware version number corresponding to the first expansion card.

3. The firmware update method for an expansion card according to claim 2, characterized in that, After determining the first expansion card in the present state based on the presence signals of each expansion card, the method further includes: The identifier of the first expansion card is reported to the firmware management platform; The firmware update receiving task includes: Receive the firmware update task issued by the firmware management platform.

4. The firmware update method for an expansion card according to claim 2, characterized in that, The step of reading the current firmware version number corresponding to the first expansion card includes: Send firmware version query commands to the first expansion card respectively; Receive firmware version data reported by the first expansion card respectively; The firmware version data is parsed to obtain the current firmware version number corresponding to the first expansion card.

5. The firmware update method for an expansion card according to claim 1, characterized in that, The step of comparing the target firmware version number corresponding to the first expansion card with the current firmware version number to obtain the comparison result includes: Obtain the historical firmware version number corresponding to the first expansion card; The target firmware version number corresponding to the first expansion card is compared with the current firmware version number to obtain the first comparison result corresponding to the first expansion card; The target firmware version number corresponding to the first expansion card is compared with the historical firmware version number to obtain the second comparison result corresponding to the first expansion card.

6. The firmware update method for an expansion card according to claim 5, characterized in that, When the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the step of writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card and sending a firmware loading command to the first expansion card to enable the first expansion card to load the firmware image file includes: If the first comparison result indicates that the target firmware version number is inconsistent with the current firmware version number, and the second comparison result indicates that the target firmware version number is inconsistent with the historical firmware version number, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card, and the firmware loading instruction is sent to the first expansion card so that the first expansion card loads the firmware image file.

7. The firmware update method for an expansion card according to claim 1, characterized in that, The step of writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card includes: The firmware image file is signed and verified to obtain the verification result; If the verification result indicates that the verification is successful, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card.

8. The firmware update method for an expansion card according to claim 1, characterized in that, The step of writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card includes: Obtain the data volume of the firmware image file; Based on the data volume, determine the file transfer method corresponding to the data volume; According to the file transfer method, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card.

9. The firmware update method for an expansion card according to claim 8, characterized in that, The step of determining the file transfer method corresponding to the data volume based on the data volume includes: When the data volume is greater than or equal to a preset data volume threshold, the file transfer method corresponding to the data volume is determined to be the write method via the switching chip. When the amount of data is less than the preset data amount threshold, the file transfer method corresponding to the amount of data is determined to be the transfer method via the management bus.

10. The firmware update method for an expansion card according to claim 1, characterized in that, The step of writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card includes: Obtain the hot update configuration parameters of the first expansion card; When the hot update configuration parameters indicate that the first expansion card supports hot updates, the firmware image file of the first expansion card is written into the firmware storage space of the first expansion card.

11. The firmware update method for an expansion card according to claim 10, characterized in that, The method further includes: When the hot update configuration parameters of the second expansion card indicate that the second expansion card does not support hot updates, a data processing pause command is sent to the second expansion card so that the second expansion card pauses data processing based on the data processing pause command; Upon receiving the data processing pause confirmation information reported by the second expansion card, the firmware image file of the second expansion card is written into the firmware storage space of the second expansion card.

12. The firmware update method for an expansion card according to claim 1, characterized in that, The step of writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card includes: When there are multiple first expansion cards, the firmware update priority of each first expansion card is obtained. The firmware update priority is determined based on the type of the first expansion card, the size of the firmware image file, and the current load. According to the firmware update priority, the firmware image files of each first expansion card are sequentially written into the firmware storage space of each first expansion card.

13. The firmware update method for an expansion card according to claim 1, characterized in that, When the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the method further includes writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card and sending a firmware loading command to the first expansion card so that the first expansion card loads the firmware image file. During the process of the first expansion card loading the firmware image file based on the firmware loading instruction, the loading progress of the first expansion card loading the firmware image file is monitored in real time. When the loading progress indicator shows that loading is complete, obtain the real-time firmware version number of the first expansion card after loading; When the real-time firmware version number and the target firmware version number are detected to be the same, it is determined that the firmware update of the first expansion card is complete.

14. The firmware update method for an expansion card according to claim 1, characterized in that, When the comparison result indicates that the target firmware version number and the current firmware version number are inconsistent, the method further includes writing the firmware image file of the first expansion card into the firmware storage space of the first expansion card and sending a firmware loading command to the first expansion card so that the first expansion card loads the firmware image file. During the process of the first expansion card loading the firmware image file based on the firmware loading instruction, when a loading failure information reported by the first expansion card is received, the firmware image file with the historical firmware version number is read from the firmware storage space of the first expansion card. Based on the firmware image file with the historical firmware version number, a rollback command is sent to the first expansion card, so that the first expansion card loads the firmware image file with the historical firmware version number according to the rollback command.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the firmware update method for an expansion card as described in any one of claims 1 to 14 when executing the computer program.

Images