Firmware upgrade method, firmware upgrade system and related device

Abstract

A firmware upgrading method, a firmware upgrading system and related devices, the method is executed by a computing device including an upgrading device and a BMC, the upgrading interface of the upgrading device is connected with the upgrading interface of the BMC, the upgrading device further includes a plurality of output interfaces, one of the plurality of output interfaces is used to connect with one component to be upgraded to form a transmission channel, so that when a plurality of firmwares are upgraded, the upgrading device can obtain the upgrading package of the plurality of firmwares, and then send the matching upgrading package to the plurality of components to be upgraded through the plurality of transmission channels, so that the parallel upgrading of the plurality of firmwares is realized through the plurality of transmission channels of the upgrading device, and the firmware upgrading of the server can be realized in parallel, thereby improving the efficiency of the firmware upgrading.

Description

Technical Field

[0001] This application relates to the field of computers, and in particular to firmware upgrade methods, firmware upgrade systems and related equipment. Background Technology

[0002] Componentization technology for server hardware is a technique that breaks down server hardware into multiple independent components. These components may include, but are not limited to, computing components, acceleration components, memory expansion components, and heat dissipation components. Each component is responsible for a specific function. Through clearly defined interfaces and protocols, communication and collaboration between components are achieved. In this way, each component can be developed, tested, and deployed independently, reducing the coupling of the system and improving the maintainability, scalability, reusability, and testability of the system.

[0003] However, when upgrading hardware components in this architecture, the server needs to send firmware upgrade packages to each hardware component via the baseboard management controller (BMC) chip. The BMC chip establishes communication connections with each hardware component through pins. However, the number of pins on the BMC chip is limited, and each pin has a specific purpose. The number of pins available for firmware upgrades is limited; for example, only one pin might be dedicated to the upgrade interface. During component upgrades, the BMC chip can only perform firmware upgrades on multiple hardware components sequentially. That is, the BMC chip establishes a connection with the first component through the upgrade pin interface, transmits the upgrade package to the first component, then establishes a connection with the second component, transmits the upgrade package to the second component, and so on, completing the upgrade of multiple firmware components. This sequential upgrade method significantly increases the upgrade time. For example, if there are 5 firmware components to be upgraded, and each firmware upgrade takes an average of 2 minutes, the sequential upgrade time would reach 10 minutes. This inefficiency greatly prolongs the customer's business interruption time, affects server operation, and degrades the user experience. Summary of the Invention

[0004] This application provides a firmware upgrade method, a firmware upgrade system, and related equipment to solve the problem that server firmware upgrades can only be performed serially, resulting in low firmware upgrade efficiency.

[0005] In a first aspect, this application provides a firmware upgrade method, which is executed by a computer device including an upgrade device and a baseboard management controller (BMC). The upgrade interface of the upgrade device is connected to the upgrade interface of the BMC. The upgrade device also includes multiple output interfaces, one of which is used to connect with a component to be upgraded to form a transmission channel. The method includes the following steps: the upgrade device receives a firmware upgrade request, then obtains multiple firmware upgrade packages, then sends matching upgrade packages in parallel to multiple components to be upgraded through multiple transmission channels, and finally obtains the upgrade results of the multiple components to be upgraded.

[0006] The method described in the first aspect involves connecting the upgrade interface of the upgrade device to the upgrade interface of the BMC, and then connecting multiple output interfaces of the upgrade device to multiple components to be upgraded to form a transmission channel. This allows the upgrade device to obtain upgrade packages for multiple firmwares when multiple firmwares are being upgraded, and then send matching upgrade packages to multiple components to be upgraded through multiple transmission channels. In this way, multiple firmwares can be upgraded in parallel through the multiple transmission channels of the upgrade device. This makes the server firmware upgrade no longer dependent on the number of pins of the BMC chip, avoids the impact of firmware upgrades on server business operations, and improves the user experience.

[0007] In one possible implementation, the upgrade device is implemented using a complex programmable logic device (CPLD) or a field-programmable gate array (FPGA). The upgrade device is either integrated into the BMC or externally attached to the BMC.

[0008] It should be noted that the hardware components containing multiple firmware units include computing components, acceleration components, memory expansion components, and heat dissipation components. The computing components include a CPU, Double Data Rate (DDR) synchronous dynamic random access memory, and a power supply. The acceleration components include a carrier board and an accelerator card interconnection switch. The accelerator cards include one or more of the following: Graphics Processing Unit (GPU), Distributed Processing Unit (DPU), and Neural Processing Unit (NPU). The memory expansion components include a carrier board and also include one or more of the following: memory expansion chips, Dual In-line Memory (DIMM) modules, and Memory-in-the-Mortar (SCM) media. The heat dissipation components include one or more of the following: air cooling and liquid cooling.

[0009] Optionally, when the upgrade device is externally connected to the BMC, the upgrade device is an independent device from the BMC chip. It establishes communication connections with the BMC chip and various components through interfaces. The upgrade interface between the upgrade device and the BMC chip may include, but is not limited to, an inter-integrated circuit (I2C) interface, a serial peripheral interface (SPI), or a universal asynchronous receiver transmitter (UART). The output interfaces between the upgrade device and acceleration components, memory expansion components, and heat dissipation components may include I2C interfaces, SPI interfaces, and UART interfaces, etc. These communication connections can be direct or indirect, and this application does not impose specific limitations. In specific implementations, the upgrade device establishes a communication connection with the BMC chip through an out-of-band bus, such as an SPI bus or an SMBUS bus. The upgrade device deploys a corresponding out-of-band bus controller to implement the above communication connection. The upgrade device also establishes a communication connection with computing components (such as the CPU) and the base board through a high-speed bus, such as a PCIe bus or a UB bus, and this application does not impose specific limitations.

[0010] Optionally, when the upgrade device is integrated into the BMC, the upgrade device is packaged inside the BMC chip or MCU chip. The upgrade device establishes communication connections with multiple components through output interfaces, which may include I2C interfaces, SPI interfaces, and UART interfaces, etc. The upgrade device communicates with I / O components, storage components, and acceleration components through an out-of-band bus. This out-of-band bus may include, but is not limited to, a synchronous serial peripheral interface (SPI), a system management bus (SMBUS), an intelligent platform management interface (IPMI), etc. The upgrade device may also deploy a corresponding out-of-band bus controller to achieve communication connections with I / O components, storage components, and acceleration components. The upgrade device communicates with computing components through a high-speed bus, such as a PCIe bus, a UB bus, etc. The upgrade device may also deploy a corresponding high-speed bus controller, such as a PCIe endpoint (EP) controller, a UB EP controller, etc., which is not specifically limited in this application.

[0011] By implementing the above-described method, the upgrade device provided in this application is highly flexible in deployment, resulting in high reliability and feasibility of the solution. Furthermore, by attaching or integrating the upgrade device into the BCM, the upgrade interface of the BMC can be expanded. Firmware upgrades can be implemented using the pins of the upgrade device, and multiple firmware upgrades can be performed in parallel through the multiple transmission channels of the upgrade device. This eliminates the dependence of server firmware upgrades on the number of pins in the BMC chip, preventing firmware upgrades from affecting server business operations and improving the user experience.

[0012] In one possible implementation, the upgrade device receives multiple firmware upgrade packages sent by the BMC, as well as channel information and component information corresponding to each firmware upgrade package. The component information includes information about the component to be upgraded that matches the firmware upgrade package, and the channel information includes information about the transmission channel corresponding to the firmware upgrade package. The channel information and component information are determined by the BMC based on the types of the multiple firmware upgrade packages and the component types.

[0013] In practice, the process of parsing the upgrade package to determine the corresponding component information can be as follows: First, the model and version information of the components connected to the BMC are obtained by scanning them. This can be achieved through device management protocols or device identification technology. The obtained device information is then compared with the firmware package's compatibility list to determine the hardware upgrade target applicable to the firmware package. Alternatively, a matching database of devices and firmware packages can be established, containing the device's model and version information as well as the firmware package's compatibility category. The hardware upgrade target corresponding to each firmware package can be determined by matching the database. Of course, other methods can also be used to match hardware upgrade targets, and this application does not impose specific limitations on them.

[0014] In practice, the process of parsing the upgrade package to determine its activation method and channel information can be as follows: After downloading the upgrade package, the update instructions are obtained from it. The contents of the update instructions are then parsed. These instructions may include the firmware update content, transmission channel requirements, and activation method. Based on these instructions, the available activation method and channel information for the upgrade package can be obtained. In some application scenarios, the update instructions may record specific update requirements for the firmware installation package, such as needing to copy it to a specific location on the device and use specific tools or menu options on the device to perform the upgrade. The BMC can also include this part as part of the channel information and send it to the upgrade device for upgrade.

[0015] By implementing the above method, multiple firmware packages can be parsed using the BMC to obtain the channel information and component information corresponding to each firmware package. Then, the channel information and component information corresponding to each firmware package are sent to the upgrade device, enabling the upgrade device to create a transmission channel based on the channel information of each firmware package. Then, according to the component information corresponding to each firmware package, the firmware package is sent to the matching component to be upgraded through the transmission channel. In this way, the upgrade device only needs to have the ability to transmit firmware packages in parallel, reducing the processing pressure on the upgrade device and improving the efficiency of firmware upgrade.

[0016] In one possible implementation, the multiple firmware upgrade packages can be different upgrade packages or the same upgrade packages, depending on the firmware requirements. Components upgraded using the same upgrade package can be components of the same model and version, such as two identical CPUs or two identical network cards. In this case, the upgrade packages used for upgrading components of the same model are completely identical. Components upgraded using the same upgrade package can also refer to components of the same model but different firmware versions. Different versions of the upgrade packages may have slight differences, and the manufacturer may use the same firmware upgrade package to upgrade the software of these devices. Components upgraded using the same upgrade package can also refer to components of different models and versions but belonging to the same product series. For example, a manufacturer may offer multiple models of devices belonging to the same product series, and these products can use the same upgrade package to update their software. It should be understood that the above examples are for illustrative purposes only and this application does not impose specific limitations.

[0017] Optionally, when multiple firmware updates require the same upgrade package, the BMC can send multiple identical upgrade packages to the upgrade device, or send a single upgrade package, which the upgrade device then sends to multiple firmware updates. The choice depends on the specific application scenario and is not specifically limited in this application. As another example, when multiple firmware updates require different upgrade packages, the BMC can send multiple different upgrade packages required by the different firmware updates to the upgrade device, and send the correspondence between the different upgrade packages and the components where the firmware resides to the upgrade device.

[0018] By implementing the above method, identical firmware packages are grouped together and then the same upgrade packages are sent to the upgrade device. These upgrade packages do not need to consider the matching components to be upgraded, because these components use the same upgrade package for upgrading. The BMC can only send information about the multiple components matched by the upgrade package in this group, without needing to determine the information corresponding to each component, thus reducing the processing pressure on the BMC and the amount of data transmitted by the BMC to the upgrade device. Furthermore, since multiple upgrade packages within the same group are identical, the BMC can also send only one upgrade package to the upgrade device, which then copies it and sends it to multiple firmware packages. This can further increase the data transmission volume between the BMC and the upgrade device, reduce network usage, and improve transmission efficiency.

[0019] In one possible implementation, the upgrade device sends upgrade results to the BMC, which then uses these results to display the upgrade progress of each component to be upgraded to the user.

[0020] In specific implementation, the upgrade device can report the transmission progress to the BMC based on the transmission progress. The BMC can then display this transmission progress to the user, allowing the user to see the progress of each firmware upgrade. Since the upgrade device transmits multiple upgrade packages to multiple components in parallel, the progress of multiple firmware upgrades seen by the user is also refreshed in parallel. For example, at time T1, the upgrade progress of firmware 1 is 50% and the upgrade progress of firmware 2 is 10%. At time T2, the upgrade progress of firmware 1 is 90% and the upgrade progress of firmware 2 is 50%. The above examples are for illustration only and are not intended to limit the scope of this application.

[0021] Optionally, the upgrade device may feed back the parallel upgrade progress of multiple firmwares to the BMC at a fixed frequency, or feed back the parallel upgrade progress of multiple firmwares to the BMC when the upgrade progress reaches a threshold. This application does not make any specific limitations.

[0022] By implementing the above-described method, users can promptly obtain the upgrade progress of each firmware through the firmware upgrade method provided in this application. Furthermore, each firmware is upgraded in parallel. Compared to the traditional serial upgrade method for upgrading multiple hardware components, the method provided in this application can improve the efficiency of firmware upgrades and enhance the user experience. For example, if there are 5 firmwares to be upgraded and each firmware upgrade takes 2 minutes, the serial upgrade would take 10 minutes. However, using the method provided in this application, the firmware upgrade can be completed in just 2 minutes, reducing the impact of firmware upgrades on user services and improving the user experience.

[0023] In one possible implementation, the upgrade results are also used by the BMC to determine the activation method of each firmware based on the upgrade progress, available activation methods, and preset rules of each component to be upgraded. The preset rules include the priority of different available activation methods. The available activation methods are obtained by the BMC after parsing the upgrade packages of multiple firmware. The priority of different available activation methods is determined according to the degree of impact of the available activation methods on the business.

[0024] In specific implementation, the preset rules can include the priority of different activation methods. The activation method with the lower the impact on the business has, the higher the priority. For example, seamless upgrade has the highest priority, followed by BMC restart upgrade, then OS restart upgrade, and AC power-down upgrade has the lowest priority. Seamless upgrade means that the upgrade can be completed after the firmware upgrade package is transmitted without any restart operation. Users can complete the firmware upgrade without being aware of it. BMC restart upgrade means that the upgrade needs to be completed after the firmware upgrade package is transmitted. OS restart means that the upgrade needs to be completed after the firmware upgrade package is transmitted. AC power-down upgrade means that the upgrade is completed by powering off and restarting the computing device. It should be understood that the above examples of different activation methods are for illustration and this application does not make specific limitations.

[0025] Optionally, the activation strategy prioritizes available activation methods with the greatest impact on business operations, placing them at lower priority and those with less impact on business operations at higher priority. Firmware with lower priority available activation methods is activated later, while firmware with higher priority available activation methods is activated earlier.

[0026] Optionally, the activation strategy may include the activation order of each firmware and a unified activation method for the firmware. Specifically, depending on the actual application scenario, it may be selected whether to activate in the order of activation, or to activate in a unified manner, or to activate some firmware one by one and some firmware uniformly. This application does not make specific limitations.

[0027] In practice, a unified activation strategy can select the lowest priority activation method from the available activation methods for each firmware and apply it uniformly. Alternatively, a sequential activation strategy can be further determined based on the activation method for each firmware and the firmware upgrade progress. For firmware with the same priority of available activation methods, the firmware with a slower upgrade progress will be activated later.

[0028] By implementing the above method, firmware upgrades can be made effective in the most efficient way, avoiding the impact on services caused by repeated power outages and restarts during the firmware upgrade process, reducing the impact of firmware upgrades on services, and improving the user experience.

[0029] It should be noted that the upgrade device provided in this application can be a computing device with processing capabilities. The upgrade device can obtain multiple upgrade packages from the BMC through the upgrade interface, and then send multiple upgrade packages in parallel to multiple components to be upgraded through multiple output interfaces to achieve parallel upgrade, and feed back the firmware upgrade results to the BMC according to the transmission progress.

[0030] Optionally, the upgrade device provided in this application may also have a storage device with storage capacity. The upgrade device can receive and store multiple upgrade packages sent by BMC through the upgrade interface. Multiple components to be upgraded can obtain multiple upgrade packages in parallel from the upgrade device to achieve parallel upgrade. Multiple components to be upgraded can report the firmware upgrade results to BMC according to the transmission progress of obtaining upgrade packages.

[0031] In one possible implementation, the firmware upgrade method provided in this application can also be applied to servers without a BMC. For example, if the server relies on a microcontroller unit (MCU) to implement firmware upgrades, then the BMC in the various implementations of the method described in the first aspect above can be replaced by an MCU, which will not be elaborated here.

[0032] Furthermore, the firmware upgrade method provided in this application can also be applied to other electronic devices besides servers. These electronic devices include processors and multiple components. When multiple components are upgraded, the firmware upgrade depends on the number of pins of the processor, which makes it impossible to upgrade the firmware in parallel. For example, hosts, chips, etc. in embedded fields such as instruments and meters. In this case, the BMC in each implementation of the method described in the first aspect above can be replaced with the processor of the electronic device, such as the central processing unit (CPU). This application does not make any specific limitation.

[0033] Secondly, a firmware upgrade system is provided, which includes an upgrade device, a baseboard management controller (BMC), and components. The upgrade interface of the upgrade device is connected to the upgrade interface of the BMC. The upgrade device also includes multiple output interfaces, one of which is used to connect with a component to be upgraded to form a transmission channel. The upgrade device is used to receive firmware upgrade requests, obtain multiple firmware upgrade packages, send matching upgrade packages to multiple components to be upgraded in parallel through multiple transmission channels, and obtain the upgrade results of multiple components to be upgraded.

[0034] In one possible implementation, the upgrade device is implemented using a complex programmable logic device (CPLD) or a field-programmable gate array (FPGA). The upgrade device is either integrated into the BMC or externally attached to the BMC.

[0035] In one possible implementation, the BMC is used to determine the channel information and component information corresponding to each firmware upgrade package in the multiple firmware upgrade packages based on the type and component type of the multiple firmware upgrade packages. The component information includes the information of the component to be upgraded matched by the firmware upgrade package, and the channel information includes the information of the transmission channel corresponding to the firmware upgrade package. The BMC is used to send multiple firmware upgrade packages, as well as the channel information and component information corresponding to each firmware upgrade package, to the upgrade device.

[0036] In one possible implementation, the upgrade device is used to send the upgrade results to the BMC, and the BMC is used to display the upgrade progress of each component to be upgraded to the user.

[0037] In one possible implementation, the BMC is used to parse multiple firmware upgrade packages to obtain the available activation methods for each firmware package. The BMC is used to determine the activation method for each firmware based on the upgrade progress of each component to be upgraded, the available activation methods, and preset rules. The preset rules include the priority of different available activation methods.

[0038] Thirdly, an upgrade device is provided. The upgrade interface of the upgrade device is connected to the upgrade interface of the baseboard management controller (BMC). The upgrade device also includes multiple output interfaces, one of which is used to connect with a component to be upgraded to form a transmission channel. The upgrade device includes logic circuitry and power supply circuitry. The power supply circuitry is used to supply power to the logic circuitry. The logic circuitry is used to implement the functions of the operation steps performed by the upgrade device in the method described in the first aspect.

[0039] In one possible implementation, the upgrade device is a chip independent of the BMC.

[0040] In one possible implementation, the upgrade device is integrated as a chip within the BMC.

[0041] Fourthly, a chip is provided, the chip including a logic circuit and a power supply circuit, the power supply circuit being used to supply power to the logic circuit, the logic circuit being used to implement the functions of the operation steps performed by the upgrading device in the method described in the first aspect.

[0042] Fifthly, a substrate management controller (BMC) is provided. The BMC includes an upgrade device, and the upgrade interface of the BMC is connected to the upgrade interface of the upgrade device. The upgrade device also includes multiple output interfaces, one of which is used to connect to a component to be upgraded to form a transmission channel. The BMC includes a computing unit and a memory. The memory is used to store instructions, which are used by the computing unit to execute functions to implement the operation steps performed by the BMC and the upgrade device in the method described in the first aspect.

[0043] In a sixth aspect, an upgrade apparatus is provided, comprising a computing unit and a memory for storing instructions that enable the computing unit to perform operational steps performed by the upgrade apparatus in the method described in the first aspect. Attached Figure Description

[0044] Figure 1 This is an architecture diagram of a firmware upgrade system provided in this application;

[0045] Figure 2 This is a schematic diagram illustrating the connection relationship between an upgrade device and other components in a computing device, as provided in this application.

[0046] Figure 3 This is a schematic diagram of the structure of a firmware upgrade system provided in this application;

[0047] Figure 4 This is a schematic diagram of another firmware upgrade system provided in this application;

[0048] Figure 5 This is a flowchart illustrating the steps of a firmware upgrade method provided in this application;

[0049] Figure 6 This is a flowchart illustrating the steps of another firmware upgrade method provided in this application;

[0050] Figure 7 This is a schematic diagram of the structure of a chip provided in this application. Detailed Implementation

[0051] With the emergence of diverse computing power trends, more processor manufacturers have appeared and launched more processor products with different architectures. The iteration speed of various processors has also increased rapidly. The processor-related circuits on the motherboard are all derived from the reference designs provided by the processor manufacturers. Different processor manufacturers provide completely different reference designs. Therefore, the entire industry has put forward higher requirements for servers in terms of cross-architecture shared components, cross-generational evolution, shortened time to market (TTM), and reduced total cost of operation (TCO). Further development of the industry requires the construction of a more open and standardized server architecture, improved development efficiency, increased component reusability, and more flexibility and differentiation.

[0052] To achieve the above objectives, server hardware modularization technology has emerged. Server hardware modularization technology is a technology that breaks down server hardware into multiple independent components, each responsible for a specific function. Through clearly defined interfaces and protocols, communication and collaboration between components are achieved. In this way, each component can be developed, tested, and deployed independently, reducing the coupling of the system and improving the system's maintainability, scalability, reusability, and testability.

[0053] However, when hardware components in a modular server undergo firmware upgrades (firmware refers to the fixed software program running in the hardware, used to implement hardware drivers, and acts as a bridge between hardware devices and software), the baseboard management controller (BMC) chip needs to send firmware upgrade packages to each hardware component. The BMC chip establishes communication connections with each hardware component through pins. However, the number of pins on the BMC chip is limited, and each pin has its corresponding purpose. Usually, only one pin can be used for firmware upgrades. During component upgrades, the BMC chip can only upgrade the firmware of multiple hardware components serially. That is, the BMC chip establishes a connection with the first component through the upgrade pin interface, transmits the upgrade package of the first component to the first component, then establishes a connection with the second component through the upgrade interface, transmits the upgrade package of the second component to the second component, then establishes a connection with the third component through the upgrade interface, and so on, to complete the upgrade of multiple firmware. This serial upgrade method greatly prolongs the upgrade time. For example, if there are 5 firmware files to be upgraded and each firmware upgrade takes an average of 2 minutes, the serial upgrade time will reach 10 minutes. This upgrade inefficiency greatly prolongs the customer's business interruption time, affects the operation of server business, and reduces the user experience.

[0054] To address the issue that firmware upgrades for multiple hardware components in the aforementioned modular server can only be performed serially, resulting in disruptions to server operations and a poor user experience, this application proposes a firmware upgrade scheme based on the modular server architecture. This scheme is executed by a computing device including an upgrade unit and a BMC (Browser Controller). The upgrade unit's upgrade interface is connected to the BMC's upgrade interface. The upgrade unit also includes multiple output interfaces, one of which is used to connect to a component to be upgraded, forming a transmission channel. This allows the upgrade unit to acquire upgrade packages for multiple firmware components during upgrades and then send matching upgrade packages to the components through multiple transmission channels. This parallel upgrade of multiple firmware components via the upgrade unit's multiple transmission channels eliminates the dependence of server firmware upgrades on the number of pins in the BMC or MCU chip, preventing firmware upgrades from impacting server operations and improving the user experience.

[0055] The technical solution to be protected in this application will be described in detail below with reference to the accompanying drawings.

[0056] Figure 1 This is a schematic diagram of a firmware upgrade system provided in this application. This firmware upgrade system can be deployed on a computing device 100, such as... Figure 3 As shown, the computing device 100 may include a Basic Computing Unit (BCU) 110, an Extension Unit (EXU) 120, components 130, and an upgrade device 140. The computing device 100 uses the BCU 110 in conjunction with the Extension Unit 120 to support the specifications and form factors of motherboards required for different scenarios. Furthermore, the same computing device may include one BCU 110 and one Extension Unit 120, or it may include multiple BCUs 110 and one Extension Unit 120, or it may include one BCU 110 and multiple Extension Units 120. The number of components 130 may also be one or more; this application does not impose a specific limitation. It should be understood that... Figure 1 The example provided is based on a base board 110, an expansion board 120, and multiple components 130. This application does not impose any specific limitations.

[0057] The base board 110, expansion board 120, upgrade device 140, and component 130 are interconnected by communication links, which can be direct or indirect. Figure 1 In this configuration, the base board 110 is directly connected to multiple components 130 and the upgrade device 140, and indirectly connected to the expansion board 120. In some embodiments, the base board 110 can also be directly connected to the expansion board 120. Figure 1The expansion board 120 is indirectly connected to the component 130; in some embodiments, the expansion board 120 may also be directly connected to the component. Figure 1 The upgrade device 140 is indirectly connected to the component 130. In some embodiments, the upgrade device 140 may also be directly connected to the component. It should be understood that... Figure 1 An example connection method is provided, but this application does not impose any specific limitations.

[0058] In this architecture, the base board 110, expansion board 120, and upgrade device 140 are communicatively connected to component 130 via high-speed buses such as PCIe, Compute Express Link (CXL), or unified bus (UB or Ubus). In specific implementations, the connection methods include: a soft connection using cables, or a hard connection using connectors.

[0059] Figure 1 The computing device 100 shown can be a physical server or an edge computing device. It can be a single server or an edge computing device, or a node in a server cluster. In a specific implementation, the computing device 100 can be a component-based architecture server as described above.

[0060] The computing device 100 can also be other electronic devices besides servers. This electronic device includes a processor and multiple components. When multiple components undergo firmware upgrades, the number of processor pins is crucial, making it impossible to upgrade the firmware in parallel. Electronic devices that meet this condition can be computing devices 100, such as hosts, chips, etc. in embedded fields like instruments and meters. It should be understood that the computing device 100 can be any other device that has multiple component upgrade requirements, but due to the limited number of processor pins used during upgrades, the components in the computing device 100 cannot be upgraded serially. Examples will not be listed here.

[0061] It should be noted that, Figure 1 The component 130 shown is an example illustrative when the computing device 100 is a modular server. When the computing device 100 is a chip, component 130 may not be included. Figure 1 The components shown may be missing, such as heat dissipation components, expansion board 120, or memory expansion components, etc. The architecture can be adjusted according to the actual application scenario.

[0062] The base board 110 includes a CPU, double data rate (DDR) memory, and related power supplies, providing general-purpose computing capabilities and expansion interfaces for peripheral storage, input / output (I / O), and acceleration. The base board supports CPUs from different series and manufacturers, including Kunpeng, Intel, and AMD. Optionally, the base board supports heterogeneous processors, meaning it can support different types of processors. For example, the base board supports CPUs, as well as any processor or any combination thereof, including application-specific integrated circuits (ASICs), programmable logic devices (PLDs), complex programmable logical devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), systems-on-chips (SoCs), software-defined infrastructure (SDI) chips, and artificial intelligence (AI) chips.

[0063] Expansion board 120 includes one or more of the following: Baseboard Management Controller (BMC) chip, management system, bridge chip (e.g., Platform Controller Hub (PCH) in Intel systems), and microcontroller unit (MCU). Expansion board 120 extends the management of base board 110, serving as the management center for the entire server and providing management functions such as hardware status monitoring, deployment, energy saving, and security. The BMC chip can also be referred to as the motherboard management controller. It should be understood that... Figure 1 Although the management system and bridge chip are not shown, they may exist in actual applications. Furthermore, the expansion board 120 may include MCUs with other functions according to business requirements. This application does not make any specific limitations.

[0064] Optionally, the BMC mentioned above can be connected to the expansion board either as a chip via a slot or as an insert card. For ease of description, the following embodiments use the BMC as a chip as an example.

[0065] Component 130 is a general term for a class of devices or equipment. These components, based on their functions, include storage units (STUs), input / output units (IOUs), acceleration units (ACUs), memory expansion units (MEUs), thermal components, computing components, and management components. The base board supports different CPU series such as Kunpeng, Intel, and AMD, while the expansion board provides management functions and power supply for the base board and various expansion components. With the support of the expansion board, various options are available for power supplies and heat sinks.

[0066] It is worth noting that a base board or expansion board containing devices such as a processor, memory, and baseboard management controller can also be used as a component. Furthermore, a server may only include the base board 110 and component 130, excluding the expansion board 120; this application does not impose specific limitations. An MCU can also be used as a component, or deployed on the base board 110; this application also does not impose specific limitations.

[0067] The storage components include hard disk backplanes, expansion boards, and PCIe switches, which expand the system's storage and support various media and forms such as hard disk drives (HDDs), solid-state drives (SSDs), non-volatile memory express (NVMe), or storage-class memory (SCM).

[0068] The IO components include components such as the Riser, which enable the expansion of system IO and support PCIe standard cards and Open Compute Project (OCP) cards.

[0069] Acceleration components include Riser, carrier board, accelerator card interconnect switch, etc., providing system acceleration component expansion and interconnection functions.

[0070] The memory expansion components include a carrier board, memory expansion chips, dual in-line memory modules (DIMMs), SCM media, etc., providing the system with the function of expanding memory bandwidth and content capacity.

[0071] Heat dissipation components are used to dissipate heat from computing devices or hardware within computing devices, including combinations of air cooling, liquid cooling, or a combination of both. It should be understood that the structure, type, and quantity of heat dissipation components do not constitute a limitation on the technical solution to be protected in this application.

[0072] Computing components, including central processing units (CPUs), memory, and other devices that provide general computing capabilities.

[0073] Management components, including devices that provide device management, such as board management controllers.

[0074] The upgrade device 140 can be a storage device with data storage capabilities. Specifically, the cache device may include volatile memory or non-volatile memory, or both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory is random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are used, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked direct random access memory (SLDRAM), and direct rambus RAM (DRRAM). Other examples include hard disks, USB flash drives, flash memory, SD cards, Memory Sticks, etc., where hard disks include hard disk drives (HDDs), solid-state drives (SSDs), and mechanical hard disks (HDDs), etc., which are not specifically limited in this application.

[0075] The upgrade device 140 can also be a computing device with data processing and storage capabilities. In specific implementations, the computing device may include a processor and memory. The processor may include integrated circuits and / or devices, wherein the integrated circuit may be a programmable logic device (PLD) or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The memory may include volatile memory or non-volatile memory, or both. The description of volatile memory or non-volatile memory can be found in the foregoing and will not be repeated here. In some embodiments, the computing device may also include a motherboard for printing the processor, also known as a printed circuit board (PCB). Optionally, the computing device may also be a processor based on an advanced instruction set machine (ARM) architecture; this application does not specifically limit this.

[0076] In this application, the upgrade device 140 can be connected to the upgrade interface of the BMC chip. The upgrade device 140 also includes multiple output interfaces. One of the multiple output interfaces is connected to a component 130 to be upgraded to form a transmission channel. When multiple firmwares are upgraded, the upgrade device 140 can obtain upgrade packages of multiple firmwares and then send matching upgrade packages to multiple components to be upgraded through multiple transmission channels, thereby realizing the parallel upgrade of multiple firmwares.

[0077] because Figure 1 The computing device shown has a large number of components, making it difficult to clearly define the connection relationship between the upgrade device 140 described above and the BMC and component 130. To facilitate a better understanding of this application, an example is provided below. Figure 2 This is a schematic diagram illustrating the connection relationship between an upgrade device provided in this application and other components in a computing device, such as... Figure 2 As shown, the upgrade interface of the upgrade device 140 provided in this application is connected to the upgrade interface of the BMC chip 121, and the output interface of the upgrade device 140 is connected to multiple components 130 and the base board 110 (in some cases, the base board can also be used as a component) to form a transmission channel. It can be understood that through... Figure 2The connection method shown allows the pins of the BMC used for firmware upgrades to connect with the upgrade device. The upgrade device connects with multiple components through multiple idle pins, thus solving the problem that the limited number of BMC pins during multiple firmware upgrades means that only serial upgrades are possible, enabling parallel firmware upgrades.

[0078] Optionally, the upgrade device 140 is a device independent of the BMC chip or MCU chip, establishing communication connections with the BMC chip or MCU chip and various components 130 through interfaces. The upgrade interface between the upgrade device 140 and the BMC or MCU chip may include, but is not limited to, an inter-integrated circuit (I2C) interface, a serial peripheral interface (SPI), or a universal asynchronous receiver transmitter (UART). The output interfaces between the upgrade device 140 and multiple components 130 may include I2C interfaces, SPI interfaces, and UART interfaces, etc. These communication connections can be direct or indirect, and this application does not impose specific limitations. In specific implementations, the upgrade device 140 establishes communication connections with the BMC chip, storage components, I / O components, and acceleration components through an out-of-band bus, such as an SPI bus or an SMBUS bus. The upgrade device 140 is equipped with a corresponding out-of-band bus controller to implement these communication connections. The upgrade device 140 establishes a communication connection with the computing components (such as the CPU) and the base board 110 via a high-speed bus, such as the PCIE bus, UB bus, etc., which are not specifically limited in this application.

[0079] Optionally, when the upgrade device 140 is packaged inside a BMC chip or an MCU chip, the upgrade device 140 establishes communication connections with multiple components through output interfaces, which may include I2C interfaces, SPI interfaces, and UART interfaces, etc. The upgrade device 140 communicates with I / O components, storage components, and acceleration components through an out-of-band bus. This out-of-band bus may include, but is not limited to, a synchronous serial peripheral interface (SPI), a system management bus (SMBUS), an intelligent platform management interface (IPMI), etc. The upgrade device 140 may also be deployed with a corresponding out-of-band bus controller to achieve communication connections with I / O components, storage components, and acceleration components. The upgrade device 140 communicates with computing components through a high-speed bus, such as a PCIe bus, a UB bus, etc. The upgrade device 140 may also be deployed with a corresponding high-speed bus controller, such as a PCIe endpoint (EP) controller, a UB EP controller, etc., which are not specifically limited in this application.

[0080] In one possible implementation, if the computing device 100 has a BMC chip, and firmware upgrades rely on the BMC, the upgrade device 140 can be as follows: Figure 1 The upgrade device 140 shown is an external component of the BMC chip. For example, it is a chip including memory, a processor, and interfaces, deployed on expansion board 120 along with the BMC. Alternatively, the upgrade device 140 can be deployed outside of expansion board 120 as a separate component 130; this application does not specifically limit its deployment. In some embodiments, the upgrade device 140 can also be packaged within the BMC chip, specifically as a cache device or as a computing device. The descriptions of the cache device and computing device are given above and will not be repeated here. Figure 1 This is for illustrative purposes only. In actual implementation, the upgrade device 140 can be flexibly deployed according to the actual application scenario. This application does not impose any specific limitations.

[0081] In one possible implementation, if the computing device 100 does not have a BMC chip and firmware upgrades rely on the MCU, then the upgrade device can also be externally mounted to the MCU chip, as part of the expansion board 120, deployed on the expansion board 120 together with the MCU. Alternatively, the upgrade device 140 can also be deployed outside the expansion board 120 as a separate component 130, which is not specifically limited in this application. In some embodiments, the upgrade device 140 can also be integrated into the MCU chip, which is not specifically limited in this application. In specific implementations, the upgrade interface of the upgrade device 140 can be connected to the upgrade interface of the MCU, and the output interface can be connected to multiple components. It should be understood that the connection method between the upgrade device 140 and the MCU can refer to the connection method between the upgrade device and the BMC chip, which will not be repeated here.

[0082] It should be noted that, as can be seen from the foregoing content, Figure 1 This is a structural example when computing device 100 is used as a modular server. When computing device 100 is an electronic device that has a requirement for parallel firmware upgrades but cannot be upgraded in parallel due to limitations in the number of processor pins, the upgrade device can exist independently outside the processor of the electronic device or be packaged inside the processor. The connection method can refer to the content above when computing device 100 is used as a modular server, and will not be repeated here.

[0083] It needs to be explained that, Figure 1 An example of an upgrade device 140 is given. In practice, one or more upgrade devices can be deployed within the computing device 100. The number of upgrade devices can be determined according to the actual application scenario. For example, if the processing power of a single upgrade device is insufficient, or the storage space is insufficient, or if the firmware upgrade has different requirements for the transmission channel, multiple upgrade devices can be used to complete the parallel upgrade of multiple firmware.

[0084] Furthermore, the upgrade device 140 and BMC 150 can be further divided into multiple unit modules, for example, Figure 3 This is a schematic diagram of the structure of a firmware upgrade system provided in this application. Figure 3 In the example shown, the firmware upgrade system is deployed in computing device 200, which is Figure 1 The computing device 100 and the upgrade device 140 are computing devices with data processing and data storage capabilities, and the upgrade device 140 is a device that exists independently outside of the BMC chip.

[0085] As can be seen from the foregoing, the upgrade device 140 provided in this application has multiple deployment options. Figure 3 This is an example of one deployment scheme; in some embodiments, Figure 3The BMC150 in the BMC can also be replaced by an MCU or a CPU, and this application does not make a specific limitation. In some other embodiments, when the upgrade device 140 is packaged inside the BMC, the unit modules in the upgrade device 140 can be deployed in the BMC150, which will not be elaborated on here.

[0086] In this application scenario, the BMC150 may include an acquisition unit 151, a parsing unit 152, and an activation unit 153, while the upgrade device 140 may include a receiving unit 141, a sending unit 142, and a progress feedback unit 143. It should be understood that... Figure 3 This is an exemplary division method. The BMC150 and the upgrade device 140 may also include more or fewer units. For example, the BMC150 may also include a security verification unit, which is used to verify the upgrade package received by the receiving unit 141. After successful verification, the upgrade package is sent to the parsing unit 152 for parsing. For example, the sending unit 142 and the progress feedback unit 143 in the upgrade device 140 may be merged into one unit to simultaneously realize the functions of transmitting the upgrade package and providing feedback on the transmission progress. It should be understood that the above examples are for illustration, and the specific unit modules can be determined according to the actual application scenario. This application does not make any specific limitations.

[0087] The functions of each unit module in the computing device 200 are explained below.

[0088] The acquisition unit 151 in the BMC150 is used to acquire multiple firmware upgrade packages.

[0089] In a specific implementation, after receiving multiple firmware upgrade requests from a user, the computing device 200 acquires the upgrade packages for the multiple firmwares using the acquisition unit 151. These upgrade requests can be manually triggered by the user; for example, if the user selects to upgrade firmware A, B, and C, the BMC 150 can send the upgrade packages for firmware A, B, and C to the receiving unit 141. Alternatively, the upgrade requests can be automatically triggered; for example, if a new upgrade package for firmware A, B, and C is available, the BMC can send the upgrade package to the receiving unit 141. These examples are for illustrative purposes only and are not intended to limit the scope of the application. The upgrade packages sent by the BMC 150 to the receiving unit 141 can be obtained externally, such as a new version firmware upgrade package downloaded from the device manufacturer's website, or obtained in other ways; these are not specifically limited in this application.

[0090] The parsing unit 152 in BMC150 is used to parse multiple firmware upgrade packages, determine the component corresponding to each upgrade package (i.e., the firmware upgrade object), and the activation method corresponding to each upgrade package. The activation method is used to make the firmware installation package effective after it is transmitted to the matching component to be upgraded. For example, the activation method may include restarting the server to make the firmware installation package effective, or restarting the BMC to make the firmware installation package effective, etc. It should be noted that devices such as the CPU and memory in the base board 110 also have firmware upgrade requirements, and the upgrade package also includes the upgrade package corresponding to the base board 110. To make this application easier to understand, the following description uses components as examples. The upgrade method for the base board is similar to that for components, and will not be repeated here.

[0091] Optionally, before parsing multiple firmware upgrade packages and determining the firmware corresponding to each upgrade package, the parsing unit 152 can perform a security check on the upgrade package to ensure its security and integrity. If the check is successful, the upgrade package can be parsed; if the check fails, the user can be notified of information such as firmware upgrade failure or upgrade package security check failure.

[0092] In practical implementation, security verification can be achieved in various ways. For example, security verification can be implemented through signature verification. Before the firmware upgrade package is released, the device manufacturer signs the firmware using a private key and then embeds the public key into the device. After receiving the firmware upgrade package, the device uses the public key to verify the firmware upgrade package to ensure that it has not been tampered with. Security verification can also be implemented through hash verification. The hash value of the upgrade package is calculated and compared with a pre-calculated hash value. Hash algorithms can include Message Digest Algorithm 5 (MD5), Secure Hash Algorithm 1 (SHA-1), etc. Security verification can also be achieved through methods such as encryption compression and authentication to restrict access. It should be understood that the above examples are for illustrative purposes only and this application does not impose specific limitations.

[0093] Optionally, when parsing multiple firmware upgrade packages, the parsing unit 152 can determine the type and available activation methods of each upgrade package, and then match the components to be upgraded based on the upgrade package type and available activation methods. Specifically, this can be achieved by first scanning connected components to obtain their model and version information, which can be implemented through device management protocols or device identification technology. The obtained device information is then compared with a firmware package compatibility list to determine the applicable hardware upgrade target for the firmware package. Alternatively, the device model and version information provided by the user can be compared with a firmware package compatibility list to determine the applicable hardware upgrade target for the firmware package. Alternatively, a device-firmware package matching database can be established, containing device model and version information as well as firmware package compatibility categories, and the hardware upgrade target corresponding to each firmware package can be determined by matching the database. Of course, other methods can also be used to match hardware upgrade targets, and this application does not impose specific limitations on them.

[0094] Optionally, if multiple upgrade devices 140 exist, after determining the component corresponding to each firmware upgrade package, the parsing unit 152 can determine the upgrade device 140 and channel information corresponding to each upgrade package based on the upgrade package type and component type. The channel information is used to instruct the upgrade device 140 to create a corresponding transmission channel to transmit the upgrade package to the component corresponding to the upgrade package through that transmission channel. It should be understood that different components may have different file formats, sizes, and transmission method requirements for their upgrade packages when performing firmware upgrades, and some upgrade devices 140 may not be able to meet these transmission requirements. For example, some firmware may require a high-speed network connection to download large firmware files, and some firmware may require specific transmission protocols or tools to complete the transmission process. Therefore, the parsing unit 152 needs to determine the upgrade device 140 and channel information corresponding to each upgrade package based on the upgrade package type and component type. The above examples are for illustrative purposes only and are not intended to limit the scope of the application.

[0095] The receiving unit 141 in the upgrade device 140 is used to receive multiple firmware upgrade packages, component information corresponding to the upgrade packages, and channel information corresponding to each upgrade package sent by the parsing unit 152 of the BMC 150. After determining the upgrade device 140 corresponding to each upgrade package, the parsing unit 152 can send the above information to each upgrade device 140.

[0096] The sending unit 142 of the upgrade device 140 is used to send corresponding upgrade packages to each component. The sending unit 142 can transmit multiple firmware upgrade packages in parallel.

[0097] In a specific implementation, the sending unit 142 can create a transmission channel based on the channel information corresponding to each upgrade package received by the receiving unit 141. Different upgrade packages correspond to different transmission channels. The upgrade package is sent to the component corresponding to the upgrade package through the transmission channel, thereby meeting the transmission requirements of different firmware and avoiding firmware upgrade failure due to mismatch of transmission channels.

[0098] Optionally, the sending unit 142 can determine the write address based on the component information corresponding to the upgrade package and write the upgrade package into the storage space of the component to be upgraded. The upgrade device 140 can store the write address of each component in advance. Alternatively, when the BMC sends the firmware installation package to the upgrade device 140, it can send the component information and write address corresponding to each firmware installation package to the upgrade device together. This application does not make any specific limitations.

[0099] Furthermore, when multiple firmwares require different upgrade packages, each upgrade package can be written into the storage space of the matching component to be upgraded based on the component information corresponding to each upgrade package; when multiple firmwares require the same upgrade package, the matching relationship between the upgrade package and the component can be disregarded, and the upgrade package can be directly written into the storage space of each component to be upgraded.

[0100] Optionally, after parsing multiple upgrade packages, the BMC's parsing unit can group the multiple upgrade packages. Identical upgrade packages can be grouped together. During the upgrade process, this group of firmware upgrade packages does not need to match the corresponding components to be upgraded. Therefore, a group of identical firmware upgrade packages and multiple components to be upgraded can be sent to the upgrade device 140 for upgrade, further improving the upgrade efficiency.

[0101] The progress feedback unit 143 of the upgrade device 140 can provide feedback on the transmission progress to the BMC 150 based on the transmission progress of the sending unit 142. The BMC 150 can then display this transmission progress to the user, allowing the user to see the progress of each firmware upgrade. Since the sending unit 142 transmits multiple upgrade packages to multiple components in parallel, the progress of multiple firmware upgrades seen by the user is also refreshed in parallel. For example, at time T1, the upgrade progress of firmware 1 is 50% and the upgrade progress of firmware 2 is 10%. At time T2, the upgrade progress of firmware 1 is 90% and the upgrade progress of firmware 2 is 50%. The above examples are for illustration only and are not intended to limit the scope of this application.

[0102] The activation unit 153 of BMC150 can generate an activation policy, which includes the activation method of each firmware. According to the activation policy, the activation method is sent to each component. Multiple components can reload the upgraded firmware according to the activation method they receive.

[0103] Furthermore, after the parsing unit 152 determines the available activation methods for each firmware upgrade package, the activation unit 153 can determine the activation strategy for multiple firmware upgrades according to preset rules based on the available activation methods for different firmware upgrade packages. This activation strategy includes the activation method for each firmware. The preset rules can include the priority of different activation methods, with activation methods having a lower impact on business operations having higher priority. For example, seamless upgrade has the highest priority, followed by BMC restart upgrade, then OS restart upgrade, and AC power-down upgrade has the lowest priority. Seamless upgrade refers to the upgrade being completed immediately after the firmware upgrade package is transmitted, without any restart operation, allowing the user to complete the firmware upgrade without any awareness. BMC restart upgrade refers to the upgrade requiring a BMC restart after the firmware upgrade package is transmitted. OS restart refers to the upgrade requiring a restart after the firmware upgrade package is transmitted. AC power-down upgrade refers to the upgrade being completed by powering off and restarting the computing device. It should be understood that the above examples of different activation methods are for illustrative purposes only and are not intended to limit the scope of this application.

[0104] Optionally, the activation strategy prioritizes available activation methods with the greatest impact on business operations, placing them at lower priority and those with less impact on business operations at higher priority. Firmware with lower priority available activation methods is activated later, while firmware with higher priority available activation methods is activated earlier.

[0105] Optionally, the activation strategy may include the activation order of each firmware and a unified activation method for the firmware. Specifically, depending on the actual application scenario, it may be selected whether to activate in the order of activation, or to activate in a unified manner, or to activate some firmware one by one and some firmware uniformly. This application does not make specific limitations.

[0106] In practical implementation, the unified activation strategy can select the lowest priority activation method from the available activation methods for each firmware. For example, the available activation method for firmware 1 is to restart the server, the available activation method for firmware 2 is to restart the BMC, and the available activation method for firmware 3 is to activate without any impact on the business. The activation method with the lowest impact on the business has higher priority. Therefore, the activation method of firmware 3 has the highest priority, and the activation method of firmware 1 has the lowest priority. The unified activation method for firmware 1 to firmware 3 is the activation method of firmware 1, which is to restart the server. It should be understood that the above examples are for illustration only and this application does not impose specific limitations.

[0107] Optionally, the sequential activation strategy can be further determined based on the activation method of each firmware and the firmware upgrade progress. For firmware with the same activation method priority, the firmware with a slower upgrade progress will be activated later. Using the example above, if the upgrade progress of firmware 3 is higher than that of firmware 2, and firmware 2 is higher than that of firmware 1, and firmware 3 has the highest activation method priority while firmware 1 has the lowest, then firmware 3 can be activated without notice, firmware 2 can be activated by restarting the BMC, and then firmware 1 can be activated by restarting the server. If firmware 1 completes its upgrade first, it can wait for firmware 2 to complete its upgrade before performing an AC power-down to complete the upgrades of both firmware 1 and firmware 2. This is because the BMC will also restart after the AC power-down restart. If firmware 2 is upgraded first and then firmware 1 is upgraded, the user will have to wait for the BMC to restart and then for the AC power-down restart, wasting time and reducing the user experience. It should be understood that the above example is for illustrative purposes only and this application does not impose specific limitations.

[0108] It should be understood that preset rules can also be configured with more content based on actual application scenarios. By setting preset rules, the optimal activation strategy can be determined to achieve synchronous activation of all firmware and improve the user experience.

[0109] Figure 4 This is a schematic diagram of another firmware upgrade system provided in this application. This firmware upgrade system is deployed in a computing device 200, which is... Figure 1 The computing device 100 in the middle should be understood. Figure 3 This application provides a schematic diagram of the software structure of a computing device in an application scenario where the upgraded device 140 is transformed into a computing device with data processing and storage capabilities. Figure 4 This application provides a schematic diagram of the software structure of a computing device in an application scenario where the upgrade device 140 is a storage device with storage capabilities. Furthermore, besides the upgrade device 140 being externally mounted on the BMC chip, other deployment schemes, such as replacing the BMC150 with an MCU or CPU, and the option of encapsulating the upgrade device 140 within the BMC150, can be referenced. Figure 4 The description of the embodiments will not be repeated here.

[0110] exist Figure 4 In the example shown, BMC150 may include an acquisition unit 151, a parsing unit 152, and an activation unit 153; upgrade device 140 includes a storage unit 144; and component 130 includes a reading unit 131 and a progress feedback unit 132.

[0111] The acquisition unit 151 in the BMC150 is used to acquire upgrade packages for multiple firmware. See details for further information. Figure 3The relevant descriptions of the acquisition unit 151 in the embodiments will not be repeated here.

[0112] The parsing unit 152 in the BMC150 can parse each upgrade package and determine the component information corresponding to each upgrade package. A description of the parsing unit 152 can be found in [reference needed]. Figure 3 The description of the embodiments will not be repeated here.

[0113] Optionally, if multiple upgrade devices 140 exist, after the parsing unit 152 determines the component corresponding to each firmware upgrade package, it can determine the upgrade device 140 corresponding to each upgrade package based on the upgrade package type and component type. It should be understood that different components may have different file formats, sizes, and transmission method requirements for their upgrade packages when performing firmware upgrades. Some upgrade devices 140 may not be able to meet these transmission method requirements. Therefore, after determining the upgrade device 140 corresponding to each upgrade package, the address information of the upgrade device 140 can be sent to the component corresponding to each upgrade package.

[0114] Of course, before the BMC150 receives the firmware upgrade request sent by the user, the upgrade device 140 can be pre-assigned to each component, and the address information of the upgrade device 140 can be sent to the corresponding component, so that when the component is upgraded, it can obtain the upgrade package from the upgrade device 140 through the pre-stored address information.

[0115] The storage unit 144 in the upgrade device 140 is used to receive the upgrade package and the component information corresponding to the upgrade package sent by the parsing unit 152, and store them in the cache space of the upgrade device 140, waiting for the components 130 to obtain the upgrade packages they need.

[0116] The reading unit 131 in component 130 can retrieve the required upgrade packages from the upgrade device 140 according to the pre-stored address information. The progress feedback unit 132 feeds back the upgrade progress to the BMC 150, enabling the BMC 150 to display the progress of multiple firmware upgrades in parallel to the user. Multiple components can read upgrade packages from the upgrade device 140 in parallel, allowing for parallel firmware upgrades and improving the efficiency of firmware upgrades.

[0117] The BMC150's activation unit 153 can determine the activation strategy based on the available activation methods for each upgrade package parsed by the parsing unit 152, combined with the firmware upgrade progress and preset rules. It then performs a reboot upgrade on the firmware after the upgrade package transmission is complete, according to the activation strategy. The method for determining the activation strategy can be referred to the aforementioned... Figure 3 The relevant descriptions in the embodiments will not be repeated here.

[0118] In summary, this application provides an upgrade device that integrates or externally attaches to the BMC chip or MCU chip in the server, so that the server's firmware upgrade no longer depends on the number of pins of the BMC chip or MCU chip. Instead, the upgrade device enables parallel upgrades of multiple firmware versions, avoiding the impact of firmware upgrades on server business operations and improving the user experience.

[0119] The above text combines Figures 1 to 4 This application provides a detailed description of the firmware upgrade system and its various modules. The following section will combine... Figures 5 to 6 This application describes the firmware upgrade method provided. Figure 5 The firmware upgrade method shown is applied to Figure 3 The architecture of this embodiment, namely the firmware upgrade method in an application scenario where the upgrade device 140 is a computing device with data processing and storage capabilities, Figure 6 The firmware upgrade method shown is applied to Figure 4 The architecture of this embodiment represents another firmware upgrade method in an application scenario where the upgrade device 140 is a storage device with storage capabilities. Furthermore, Figure 5 In the method shown, the upgrade device 140 is externally mounted to the BMC chip. Other deployment options, such as replacing the BMC150 with an MCU or CPU, and the option of encapsulating the upgrade device 140 within the BMC150, can be referenced. Figure 5 The description of the embodiments will not be repeated here.

[0120] The two firmware upgrade methods are explained below.

[0121] like Figure 5 As shown, in Figure 3 Under the architecture shown, the firmware upgrade method provided in this application includes the following steps:

[0122] S410: The BMC receives multiple firmware upgrade requests sent by the user.

[0123] This step can be performed by Figure 3 The acquisition unit 151 in the embodiment is implemented.

[0124] It should be understood that Figure 5 Therefore Figure 3 The example provided illustrates a specific application scenario. In other application scenarios, the BMC can be replaced by either an MCU or a CPU. For details, please refer to [link / reference]. Figures 1-4 The relevant descriptions in the embodiments will not be repeated here.

[0125] The aforementioned firmware upgrade requests can be manually triggered by the user, such as when the user selects to upgrade firmware A, firmware B, and firmware C. Alternatively, the upgrade requests can be automatically triggered; for example, if new upgrade packages for firmware A, firmware B, and firmware C are currently available, the BMC can obtain the firmware upgrade requests for firmware A, firmware B, and firmware C. The above examples are for illustrative purposes only and are not intended to impose specific limitations.

[0126] In the specific implementation, after receiving multiple firmware upgrade requests sent by the user, the BMC can send a firmware upgrade request to the upgrade device, notifying the upgrade device to prepare to receive multiple firmware upgrade packages. The firmware upgrade request sent by the BMC to the upgrade device is different from the multiple firmware upgrade requests received by S410. The firmware upgrade request sent by the BMC to the upgrade device is used to notify the upgrade device that it is about to receive the upgrade package, while the multiple firmware upgrade requests received by the BMC in S410 are triggered by the user. There is a certain difference between the two.

[0127] S420: The BMC sends multiple firmware upgrade packages to the upgrade device.

[0128] This step can be performed by Figure 3 The parsing unit 152 and the receiving unit 141 in the embodiment are implemented.

[0129] As mentioned above, the upgrade interface of the upgrade device is connected to the upgrade interface of the BMC. Therefore, the BMC can send multiple firmware upgrade packages to the upgrade device through this upgrade interface. It should be understood that the BMC has a limited number of pins, most of which are occupied, and usually only one pin can be used as the upgrade interface. This means that firmware upgrades can only be performed serially. However, by connecting the upgrade interface of the upgrade device to the upgrade interface of the BMC, the BMC can directly send multiple firmware upgrade packages to the upgrade device. The upgrade device then establishes a transmission channel with multiple components, allowing multiple firmware upgrade packages to be transmitted in parallel through the upgrade device. This solves the problem that the BMC pin limitation restricts firmware upgrades to a serial manner, thus improving the efficiency of server firmware upgrades.

[0130] Optionally, before sending multiple firmware upgrade packages to the upgrade device, the BMC can respond to multiple firmware upgrade requests received by the S410 and obtain these multiple firmware upgrade packages. In specific implementation, the BMC can download the upgrade package required for each firmware from a third party based on the multiple firmware upgrade requests sent by the user, such as a new version firmware upgrade package downloaded from the device manufacturer's official website, or it can be obtained in other ways. This application does not make specific limitations.

[0131] Optionally, after obtaining multiple firmware upgrade packages, the upgrade packages can be parsed to determine the component information corresponding to the upgrade package, that is, the information of the matching components of the firmware, as well as the activation method corresponding to each upgrade package. The activation method is used to reload the upgraded firmware.

[0132] In practice, the process of parsing the upgrade package to determine the corresponding component information can be as follows: First, the model and version information of the components connected to the BMC are obtained by scanning them. This can be achieved through device management protocols or device identification technology. The obtained device information is then compared with the firmware package's compatibility list to determine the hardware upgrade target applicable to the firmware package. Alternatively, a matching database of devices and firmware packages can be established, containing the device's model and version information as well as the firmware package's compatibility category. The hardware upgrade target corresponding to each firmware package can be determined by matching the database. Of course, other methods can also be used to match hardware upgrade targets, and this application does not impose specific limitations on them.

[0133] In practice, the process of parsing the upgrade package to determine the corresponding activation method can be as follows: After downloading the upgrade package, obtain the update instructions from the upgrade package, and parse the contents of the update instructions. The update instructions may include the firmware update content and activation method. In some application scenarios, the update instructions may record the update method of the firmware installation package, such as needing to copy it to a specific location on the device and use specific tools or menu options on the device to perform the upgrade. BMC can also send this part as part of the channel information to the upgrade device for upgrade.

[0134] Optionally, before parsing multiple firmware upgrade packages and determining the corresponding firmware for each upgrade package, a security verification can be performed on the upgrade package to ensure its security and integrity. If the verification is successful, the upgrade package can be parsed; otherwise, information such as firmware upgrade failure or upgrade package security verification failure can be sent to the user. In specific implementations, security verification can be achieved in various ways, such as through signature verification, hash verification, encryption compression, authentication, or access restrictions. This application does not impose any specific limitations.

[0135] Optionally, if there are multiple upgrade devices, after determining the component corresponding to each firmware upgrade package, the upgrade device and channel information corresponding to each upgrade package can be determined according to each upgrade package type and component type. The channel information is used to instruct the upgrade device to create a transmission channel and transmit the upgrade package to the component corresponding to the upgrade package through the transmission channel. It should be understood that different components may have different file formats, sizes, and transmission method requirements when performing firmware upgrades. Some upgrade devices may not be able to meet these transmission requirements. For example, some firmware may require the use of large firmware files to complete the firmware upgrade. Generally, large firmware files refer to firmware files with a size exceeding several hundred megabytes (MB) or several gigabytes (GB). Such files require a long transmission time and have high requirements for transmission channels and storage space. Of course, the threshold for large firmware files varies in different application scenarios. In some cases, a file of several hundred megabytes is considered large, while in others, a file of tens of megabytes is considered large. Therefore, it is necessary to define the threshold for large firmware files based on the actual application scenario. Some firmware may also require specific transmission protocols or tools to complete the transmission process. The size of the upgrade package for such firmware files varies depending on different fields and industries, which depends on the type and purpose of the component.

[0136] In practice, the number of upgrade packages can be one or more, and they can be multiple different upgrade packages or multiple identical upgrade packages, depending on the firmware requirements. Components upgraded using the same upgrade package can be components of the same model and version, such as two identical CPUs or two identical network cards. In this case, the upgrade packages used for upgrading components of the same model are completely identical. Components upgraded using the same upgrade package can also refer to components of the same model but different firmware versions. Different versions of the upgrade packages may have slight differences, and the manufacturer may use the same firmware upgrade package to upgrade the software of these devices. Components upgraded using the same upgrade package can also refer to components of different models and versions but belonging to the same product series. For example, a manufacturer may provide multiple models of devices belonging to the same product series, and these products can use the same upgrade package to update their software. It should be understood that the above examples are for illustrative purposes only and this application does not impose specific limitations.

[0137] Optionally, when multiple firmware updates require the same upgrade package, the BMC can send multiple identical upgrade packages to the upgrade device, or send a single upgrade package, which the upgrade device then sends to multiple firmware updates. The choice depends on the specific application scenario and is not specifically limited in this application. As another example, when multiple firmware updates require different upgrade packages, the BMC can send multiple different upgrade packages required by the different firmware updates to the upgrade device, and send the correspondence between the different upgrade packages and the components where the firmware resides to the upgrade device.

[0138] S430: The upgrade device sends upgrade packages to multiple components.

[0139] This step can be performed by Figure 3 The sending unit 142 in the embodiment is implemented.

[0140] In its implementation, the upgrade device receives multiple firmware upgrade packages, corresponding component information, and channel information from the BMC150. Then, based on the component and channel information, the upgrade device creates multiple transmission channels and sends the upgrade packages to multiple components through these channels. Different upgrade packages correspond to different transmission channels, ensuring that the upgrade packages are sent to the corresponding components. This satisfies the transmission requirements of different firmware versions and prevents firmware upgrade failures due to transmission channel mismatches.

[0141] Optionally, the upgrade device can determine the write address based on the component information corresponding to the upgrade package, and write the upgrade package into the storage space of the component to be upgraded. If the upgrade packages required by multiple firmwares are different, each upgrade package can be written into the storage space of the corresponding component based on the component information corresponding to each upgrade package; if the upgrade packages required by multiple firmwares are the same, the upgrade package can be written into the storage space of each component to be upgraded.

[0142] S440: The upgrade device reports the progress of multiple firmware upgrades to the BMC in parallel.

[0143] This step can be performed by Figure 3 The progress feedback unit 143 in the embodiment is implemented.

[0144] In specific implementation, the upgrade device can report the transmission progress to the BMC based on the transmission progress. The BMC can then display this transmission progress to the user, allowing the user to see the progress of each firmware upgrade. Since the upgrade device transmits multiple upgrade packages to multiple components in parallel, the progress of multiple firmware upgrades seen by the user is also refreshed in parallel. For example, at time T1, the upgrade progress of firmware 1 is 50% and the upgrade progress of firmware 2 is 10%. At time T2, the upgrade progress of firmware 1 is 90% and the upgrade progress of firmware 2 is 50%. The above examples are for illustration only and are not intended to limit the scope of this application.

[0145] Optionally, the upgrade device may feed back the parallel upgrade progress of multiple firmwares to the BMC at a fixed frequency, or feed back the parallel upgrade progress of multiple firmwares to the BMC when the upgrade progress reaches a threshold. This application does not make any specific limitations.

[0146] Understandably, with the firmware upgrade method provided in this application, users can promptly learn the upgrade progress of each firmware, and the firmware is upgraded in parallel. Compared with the traditional serial upgrade method for firmware upgrades of multiple hardware components, the method provided in this application can improve the efficiency of firmware upgrades and enhance the user experience. For example, if there are 5 firmwares to be upgraded and each firmware upgrade takes 2 minutes, the serial upgrade would take 10 minutes. However, using the method provided in this application, the firmware upgrade can be completed in just 2 minutes, reducing the impact of firmware upgrades on user services and improving the user experience.

[0147] S450: The BMC determines the activation strategy for multiple components and sends the respective activation methods to the multiple components.

[0148] This step can be performed by Figure 3 The effective unit 153 in the embodiment is implemented.

[0149] In specific implementation, during S420, the BMC parses each upgrade package and determines the available activation method for each upgrade package. During S450, the BMC can determine the activation strategy for multiple firmware upgrades according to preset rules. This activation strategy includes the activation method for each firmware after the upgrade. The preset rules can include the priority of different activation methods. For example, seamless upgrade has the highest priority, followed by BMC restart upgrade, then OS restart upgrade, and AC power-down upgrade has the lowest priority. Seamless upgrade means that the upgrade is completed immediately after the firmware upgrade package is transmitted, without any restart operation, allowing the user to complete the firmware upgrade without any awareness. BMC restart upgrade means that the upgrade requires restarting the BMC after the firmware upgrade package is transmitted. OS restart upgrade means that the upgrade requires restarting the operating system after the firmware upgrade package is transmitted. AC power-down upgrade means that the upgrade is completed by powering off and restarting the computing device. It should be understood that the above examples of different activation methods are for illustrative purposes only and are not intended to limit the scope of this application.

[0150] Optionally, the activation strategy can also be determined according to preset rules and firmware upgrade progress. For example, if the available activation method for firmware 1 is AC power-down upgrade and the available activation method for firmware 2 is BMC reboot upgrade, and firmware 1 is upgraded first, then firmware 1 can wait for firmware 2 to be upgraded before performing AC power-down to complete the upgrade of firmware 1 and firmware 2. This is because BMC will also reboot after AC power-down reboot. If firmware 2 reboot upgrade is completed first and then firmware 1 reboot upgrade is performed, then the user will need to wait for BMC reboot and then wait for AC power-down reboot, which wastes time and reduces the user experience. It should be understood that the above examples are for illustration only and this application does not make specific limitations.

[0151] It should be understood that preset rules can also be configured with more content based on actual application scenarios. By setting preset rules, the optimal activation strategy can be determined to achieve synchronous activation of all firmware and improve the user experience.

[0152] It should be noted that S450 can be executed simultaneously or sequentially with S420 to S440, and this application does not make specific limitations.

[0153] S460: The component completes the firmware upgrade according to the received activation method. This step can be performed by... Figure 3 Component 130 in the embodiment is implemented.

[0154] The following is combined Figure 6 This application provides an explanation of another firmware upgrade method. Figure 6This describes a firmware upgrade method for applications where the upgrade device 140 is used for storage devices with storage capabilities. Furthermore, the upgrade device 140 is externally connected to the BMC chip. Other deployment options, such as replacing the BMC150 with an MCU or CPU, and the option of encapsulating the upgrade device 140 within the BMC150, can be found in [reference needed]. Figure 6 The description of the embodiments will not be repeated here. Figure 6 As shown, the method includes the following steps:

[0155] S510: The BMC receives multiple firmware upgrade requests sent by the user. This step can be performed by... Figure 4 The acquisition unit 151 in the embodiment is implemented.

[0156] For a detailed description of the S510 implementation, please refer to [link / reference]. Figure 3 and Figure 4 For further details regarding the acquisition unit 151 in the embodiments, please refer to... Figure 5 The relevant descriptions of S410 in the embodiments will not be repeated here.

[0157] It should be understood that Figure 6 Therefore Figure 4 The example provided illustrates a specific application scenario. In other application scenarios, the BMC can be replaced by either an MCU or a CPU. For details, please refer to [link / reference]. Figures 1-5 The relevant descriptions in the embodiments will not be repeated here.

[0158] S520: The BMC sends multiple firmware upgrade packages to the upgrade device.

[0159] This step can be performed by Figure 4 The parsing unit 152 and storage unit 144 in the embodiment are implemented.

[0160] It should be understood that the description of S520 can be found here. Figure 3 and Figure 4 The description of the parsing unit 152 and the storage unit 144 in the embodiments can also be found in... Figure 5 The relevant descriptions of S420 in the embodiments will not be repeated here.

[0161] S530: The BMC sends upgrade messages to multiple components. This step can be performed by... Figure 4 The parsing unit 152 in the embodiment is implemented.

[0162] In specific implementation, the upgrade message is used to instruct the component to obtain the upgrade package from the upgrade device. Optionally, the upgrade message may carry the address information of the upgrade device. If there are multiple upgrade devices 140, in S520, after the BMC determines the component corresponding to each firmware upgrade package, it can determine the upgrade device 140 corresponding to each upgrade package according to the upgrade package type and component type. S530 then sends the address information of the upgrade device 140 to the component corresponding to each upgrade package. Of course, before the BMC receives the firmware upgrade request sent by the user, it can pre-assign the upgrade device to each component and send the address information of the upgrade device to the corresponding component, so that when the component is upgraded, S530 does not need to carry the address information and can obtain the upgrade package from the upgrade device through the pre-stored address information. This application does not make specific limitations.

[0163] S540: The component obtains the upgrade package from the upgrade device. This step can be performed by... Figure 4 The reading unit 131 in the embodiment is implemented.

[0164] In practice, components can obtain upgrade packages from upgrade device 140 using pre-stored address information or address information carried in upgrade messages received by S530. It should be understood that by having multiple components obtain upgrade packages from upgrade device 140, parallel firmware upgrades within the components can be achieved, improving the user experience.

[0165] S550: The component reports the progress of multiple firmware upgrades in parallel to the BMC. This step can be performed by... Figure 4 The progress feedback unit 132 in the embodiment is implemented.

[0166] In specific implementation, each component can report its transmission progress to the BMC based on its own upgrade package reading progress. The BMC can display the reading progress reported by multiple components to the user, allowing the user to see the progress of each firmware upgrade. Since the upgrade device transmits multiple upgrade packages to multiple components in parallel, the firmware upgrade progress seen by the user is also refreshed in parallel. For example, at time T1, the upgrade progress of firmware 1 is 50% and the upgrade progress of firmware 2 is 10%. At time T2, the upgrade progress of firmware 1 is 90% and the upgrade progress of firmware 2 is 50%. The above example is for illustration only and is not specifically limited in this application.

[0167] Understandably, with the firmware upgrade method provided in this application, users can promptly learn the upgrade progress of each firmware, and the firmware is upgraded in parallel. Compared with the traditional serial upgrade method for firmware upgrades of multiple hardware components, the method provided in this application can improve the efficiency of firmware upgrades and enhance the user experience. For example, if there are 5 firmwares to be upgraded and each firmware upgrade takes 2 minutes, the serial upgrade would take 10 minutes. However, using the method provided in this application, the firmware upgrade can be completed in just 2 minutes, reducing the impact of firmware upgrades on user services and improving the user experience.

[0168] Optionally, each component may report its firmware upgrade progress to the BMC at a fixed frequency, or report the upgrade progress to the BMC when the upgrade progress reaches a threshold. This application does not impose any specific limitations.

[0169] S560: The BMC determines the activation strategy for multiple components and sends the respective activation methods to each component. This step can be performed by... Figure 4 The effective unit 153 in the embodiment is implemented.

[0170] For a detailed description of the S560 implementation, please refer to [link / reference]. Figure 5 The description of S450 in the embodiment will not be repeated here.

[0171] S570: The component completes the firmware upgrade according to the received activation method. This step can be performed by... Figure 4 Component 130 in the embodiment is implemented.

[0172] For a detailed description of the S570 implementation, please refer to [link / reference]. Figure 5 The description of S460 in the embodiment will not be repeated here.

[0173] In summary, this application provides an upgrade device that integrates or externally attaches to the BMC chip or MCU chip in the server, so that the server's firmware upgrade no longer depends on the number of pins of the BMC chip or MCU chip. Instead, the upgrade device enables parallel upgrades of multiple firmware versions, avoiding the impact of firmware upgrades on server business operations and improving the user experience.

[0174] The above text combines Figures 5 to 6 The firmware upgrade method provided in this application is described in detail below, and will be combined with... Figure 7 Describe the chip provided in this application.

[0175] Figure 7This is a schematic diagram of the structure of a chip provided in this application. The chip can be the upgrade device 140 mentioned above. Further, the chip 700 may include a power supply circuit 710 and a logic circuit 720. The power supply circuit 710 and the logic circuit 720 can be connected by wires, cables or other types of electrical connections, which are not specifically limited in this application.

[0176] The chip 700 is implemented using a CPLD or FPGA. Its upgrade interface connects to the upgrade interface of the Baseboard Management Controller (BMC). The chip 700 also includes multiple output interfaces, one of which is used to connect to a component to be upgraded, forming a transmission channel. For specific connection details, please refer to [reference needed]. Figure 1 and Figure 2 The relevant descriptions of the embodiments will not be repeated here.

[0177] In a specific implementation, the power supply circuit 710 is used to supply power to the logic circuit 720, enabling the logic circuit 720 to achieve the following: Figure 5 or Figure 6 The firmware upgrade method shown illustrates the functions achievable by the upgrade device. It should be noted that chip 700 can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the upgrade device 140 in the above method embodiments can be completed by the integrated logic circuitry of the chip 700's hardware or by software instructions. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor; this application does not impose specific limitations.

[0178] Optionally, the chip 700 may further include a memory for storing firmware upgrade packages for multiple components. The memory may be volatile or non-volatile, or a combination of both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory is random access memory (RAM), which serves as an external cache. The above examples are for illustrative purposes only and are not intended to limit the scope of the application.

[0179] It needs to be explained that, Figure 7 This is merely one possible implementation of an embodiment of this application. In actual applications, chip 700 may include more or fewer components, which is not limited here. For content not shown or described in the embodiments of this application, please refer to the foregoing. Figures 1-6 The relevant descriptions in the embodiments will not be repeated here.

[0180] This application provides a BMC (Building Control System) including an upgrade device. The upgrade interface of the BMC is connected to the interface of the upgrade device. The upgrade device also includes multiple output interfaces, one of which is used to connect with a component to be upgraded to form a transmission channel. The BMC includes a computing unit and a memory. The memory stores instructions for the computing unit to implement. Figures 1-6 The firmware upgrade method described in the embodiments.

[0181] This application provides a computer-readable storage medium, including: computer instructions stored in the computer-readable storage medium; when the computer instructions are executed on a computer, the computer causes the computer to perform the firmware upgrade method described in the above method embodiments.

[0182] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented in software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes a plurality of computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0183] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent repairs or substitutions within the technical scope disclosed in the present invention, and these repairs or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A firmware upgrade method characterized by comprising: The method is performed by a computer device including an upgrade device and a baseboard management controller (BMC), an upgrade interface of the upgrade device is connected with an upgrade interface of the BMC, the upgrade device further includes a plurality of output interfaces, one of the plurality of output interfaces is used to connect with one component to be upgraded to form a transmission channel, and the method includes the following steps: The upgrade device receives an upgrade request of a firmware; The upgrade device receives a plurality of firmware upgrade packages sent by the BMC, and channel information and component information corresponding to each firmware upgrade package, wherein the component information includes information of a component to be upgraded matched with the firmware upgrade package, the channel information includes information of a transmission channel corresponding to the firmware upgrade package, and the channel information and the component information are determined by the BMC according to types of the plurality of firmware upgrade packages and types of components; The upgrade device determines a plurality of transmission channels corresponding to the plurality of firmware upgrade packages according to the plurality of firmware upgrade packages, and sends matched upgrade packages to a plurality of components to be upgraded in parallel through the plurality of transmission channels, wherein different firmware upgrade packages correspond to different transmission channels; The upgrade device obtains upgrade results of the plurality of components to be upgraded.

2. The method of claim 1, wherein, The upgrade device is implemented by a complex programmable logic device (CPLD) or a field programmable logic gate array (FPGA), and is integrated in the BMC or externally connected to the BMC.

3. The method according to claim 1 or 2, characterized in that, The method further includes the following steps: The upgrade device sends the upgrade results to the BMC, and the upgrade results are used for the BMC to display upgrade progress of each component to be upgraded to a user.

4. The method of claim 3, wherein, The upgrade results are also used for the BMC to determine an effective mode of each firmware according to the upgrade progress of each component to be upgraded, available effective modes and preset rules, the preset rules include priorities of different available effective modes, the available effective modes are obtained by the BMC after analyzing the plurality of firmware upgrade packages, and the priorities of the different available effective modes are determined according to an influence degree of the available effective modes on business.

5. A firmware upgrade system, characterized by, The system includes an upgrade device, a baseboard management controller (BMC) and components, wherein an upgrade interface of the upgrade device is connected with an upgrade interface of the BMC, the upgrade device further includes a plurality of output interfaces, one of the plurality of output interfaces is used to connect with one component to be upgraded to form a transmission channel, The upgrade device is configured to receive an upgrade request of a firmware; The BMC is configured to determine channel information and component information corresponding to each firmware upgrade package in a plurality of firmware upgrade packages according to types of the plurality of firmware upgrade packages and types of components, wherein the component information includes information of a component to be upgraded matched with the firmware upgrade package, and the channel information includes information of a transmission channel corresponding to the firmware upgrade package; The BMC is configured to send the plurality of firmware upgrade packages, and the channel information and the component information corresponding to each firmware upgrade package to the upgrade device. The upgrading device is configured to determine, according to the plurality of firmware upgrade packages, a plurality of transmission channels corresponding to the plurality of firmware upgrade packages, and send the matched upgrade packages to the plurality of components to be upgraded in parallel through the plurality of transmission channels, wherein different firmware upgrade packages correspond to different transmission channels. The upgrading device is configured to obtain an upgrade result of the plurality of components to be upgraded.

6. The system of claim 5, wherein, The upgrading device is implemented by a complex programmable logic device (CPLD) or a field programmable logic gate array (FPGA), and is integrated into the BMC, or externally connected to the BMC.

7. The system of claim 5 or 6, wherein The upgrading device is configured to send the upgrade result to the BMC. The BMC is configured to display the upgrade progress of each component to be upgraded to a user.

8. The system of claim 7, wherein The BMC is configured to parse the plurality of firmware upgrade packages to obtain an available validation mode of each firmware upgrade package. The BMC is configured to determine a validation mode of each firmware upgrade package according to the upgrade progress of each component to be upgraded, the available validation mode, and a preset rule, wherein the preset rule includes priorities of different available validation modes.

9. An upgrading device, characterized in that The upgrade interface of the upgrading device is connected to an upgrade interface of a baseboard management controller (BMC), and the upgrading device further includes a plurality of output interfaces, one of which is configured to be connected to one component to be upgraded to form a transmission channel, and the upgrading device includes a logic circuit and a power supply circuit, the power supply circuit is configured to supply power to the logic circuit, and the logic circuit is configured to implement the functions of the operation steps performed by the upgrading device as described in any one of claims 1 to 4.

10. The upgrade device of claim 9, wherein, The upgrading device is a chip independent of the BMC.

11. The upgrade device of claim 9, wherein, The upgrading device is integrated into a chip in the BMC.

12. A chip, characterized by The chip includes a logic circuit and a power supply circuit, the power supply circuit is configured to supply power to the logic circuit, and the logic circuit is configured to implement the functions of the operation steps performed by the upgrading device as described in any one of claims 1 to 4.

13. A baseboard management controller (BMC) comprising: The BMC includes an upgrading device, an upgrade interface of the BMC is connected to an upgrade interface of the upgrading device, the upgrading device further includes a plurality of output interfaces, one of which is configured to be connected to one component to be upgraded to form a transmission channel, and the BMC includes a computing unit and a memory, the memory is configured to store instructions, and the instructions are configured to be executed by the computing unit to implement the functions of the operation steps performed by the upgrading device as described in any one of claims 1 to 4.

Images