Firmware upgrading method, computer program product, device, and storage medium

Abstract

The present application relates to a firmware upgrading method, a computer program product, a device, and a storage medium. The method comprises: in response to receiving a first firmware upgrading signal, acquiring the state of a first link, the first link connecting a main controller to an external memory of the main controller; in response to determining that the first link is in an idle state, locking the first link, and returning a second firmware upgrading signal to a baseboard management controller; in response to the baseboard management controller receiving the second firmware upgrading signal, the baseboard management controller controlling the main controller to send a first control signal to a multiplexer, so as to control the multiplexer to switch to a second link, the second link connecting the baseboard management controller to the external memory of the main controller; and the baseboard management controller acquiring a configuration file in the external memory by means of the second link to perform firmware upgrading, the configuration file comprising a flashing code. By using the present method, the reliability of firmware upgrading can be improved.

Description

Firmware upgrade methods, computer program products, devices and storage media

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411606230.2, filed on November 12, 2024, entitled "Firmware Upgrade Method, Computer Program Product, Device and Storage Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of firmware upgrade technology, and in particular to a firmware upgrade method, computer program product, device and storage medium. Background Technology

[0004] With societal development, information technology is increasingly permeating all aspects of society. Servers, as carriers of data processing and storage, are highly integrated internally. To achieve a specific function, discrete components are typically not used to build modules; instead, integrated controllers paired with simple peripherals are employed. These dedicated controllers often implement complex or customizable functions. Therefore, external EEPROM (Electrically Erasable Programmable Read-Only Memory) or FLASH MEMORY (a type of electrically erasable programmable read-only memory) is used to store configuration files or firmware for use during startup or operation. However, when the configuration files or firmware need adjustment or modification, they must be upgraded.

[0005] In related technologies, the controller's dedicated programming program is called through the serial port or interface of these controllers to modify or upgrade the configuration file or firmware. The BMC (Baseboard Management Controller) connects to a dedicated controller, first pushing the modified configuration file or firmware to the controller's RAM (Random Access Memory) via I2C (Inter-Integrated Circuit), and then calling the controller's programming API (Application Programming Interface) to program the configuration file or firmware in RAM to the controller's EEPROM or FLASH MEMORY.

[0006] Each controller has a specific programming API. To program different controllers, the BMC needs to integrate the programming APIs of various controllers into its code. This not only increases the difficulty of BMC development but also generates large BMC programming files, requiring a larger external FLASH MEMORY to store the firmware, significantly increasing product costs. Summary of the Invention

[0007] This application provides a firmware upgrade method, computer program product, device, and storage medium that can improve the reliability of firmware upgrades.

[0008] Firstly, it provides firmware upgrade methods, including:

[0009] In response to receiving the first firmware upgrade signal, the status of the first link is obtained, and the first link is connected between the main controller and the external memory of the main controller;

[0010] In response to determining that the first link is in an idle state, the first link is locked and a second firmware upgrade signal is returned to the baseboard management controller;

[0011] In response to the baseboard management controller receiving a second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link, the second link connecting the baseboard management controller and the main controller's external memory; and

[0012] The baseboard management controller obtains the configuration file from the external storage via the second link to perform firmware upgrades.

[0013] In some embodiments, in response to receiving a first firmware upgrade signal, obtaining the status of the first link includes:

[0014] In response to the baseboard management controller receiving a firmware upgrade request, the baseboard management controller sends a first firmware upgrade signal to the main controller. The first firmware upgrade signal is a low-level signal.

[0015] In response to the main controller receiving the first firmware upgrade signal, it determines whether there is data being transmitted on the first link;

[0016] In response to determining that data is being transmitted on the first link, the first link is considered to be in a working state; and

[0017] If it is determined that there is no data being transmitted on the first link, then the first link is considered to be in an idle state.

[0018] In some embodiments, the second firmware upgrade signal is high, wherein the second firmware upgrade signal is an active high signal.

[0019] In some embodiments, the first link includes a first transmission line and a third transmission line, and the second link includes a second transmission line and a third transmission line, wherein...

[0020] The first transmission line connects the first terminal of the multiplexer to the main controller;

[0021] The second transmission line connects the first terminal of the multiplexer to the substrate management controller; and

[0022] The third transmission line connects the external memory and the second end of the multiplexer.

[0023] In some embodiments, in response to determining that the first link is idle, locking the first link and returning a second firmware upgrade signal to the baseboard management controller includes:

[0024] In response to determining that the first link is in an idle state, a locking command is triggered to lock the first link so that the first link remains in an idle state for a preset time period, and a second firmware upgrade signal is returned to the baseboard management controller. The second firmware upgrade signal is a high-level signal.

[0025] In some embodiments, the second link includes a second transmission line and a third transmission line. In response to the baseboard management controller receiving a second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link. The second link connects the baseboard management controller and the main controller's external memory, including:

[0026] In response to the baseboard management controller receiving a second firmware upgrade signal from the main controller, the baseboard management controller sends a first control signal to the multiplexer, the first control signal being a high-level signal; and

[0027] In response to the multiplexer receiving the first control signal, the multiplexer switches to the second transmission line so that the board management controller can transmit data with the external memory of the main controller through the second transmission line and the third transmission line.

[0028] In some embodiments, the baseboard management controller performs firmware upgrades by obtaining a configuration file from external storage via a second link, including:

[0029] In response to the baseboard management controller obtaining the configuration file from the external memory, the configuration file is parsed to obtain firmware upgrade data and burning code; and

[0030] Firmware upgrades are performed based on firmware upgrade data and burning code.

[0031] In some embodiments, the first link includes a first transmission line and a third transmission line. After the baseboard management controller obtains the configuration file in the external memory through the second link and performs a firmware upgrade, it includes:

[0032] In response to the baseboard management controller performing a firmware upgrade on the configuration file in the external memory, the baseboard management controller sends a second control signal to the multiplexer, the second control signal being a low-level signal; and

[0033] In response to the multiplexer receiving a second control signal, the multiplexer switches to the first transmission line so that the main controller can transmit data with the external memory of the main controller through the first transmission line and the third transmission line.

[0034] In some embodiments, there are multiple firmware upgrade requests, and the method further includes:

[0035] Generate a timestamp based on the generation time of each firmware upgrade request;

[0036] Obtain the configuration file download package and firmware upgrade request level carried by each firmware upgrade request. The configuration file download package includes the start position of the configuration file and the length of the configuration file.

[0037] The overall priority of each firmware upgrade request is determined based on a preset comprehensive priority calculation formula, timestamp, firmware upgrade request level, configuration file start position, and configuration file length; and

[0038] Each firmware upgrade request is sent to the baseboard management controller for processing based on its overall priority level.

[0039] In some embodiments, determining the overall firmware upgrade priority of each firmware upgrade request based on a preset comprehensive priority calculation formula, timestamp, firmware upgrade request level, configuration file start position, and configuration file length includes:

[0040] Retrieve the first weight value corresponding to the timestamp, the second weight value corresponding to the start position of the configuration file, and the third weight value corresponding to the length of the configuration file; and

[0041] The overall priority of each firmware upgrade request is calculated based on the preset comprehensive priority calculation formula, the first weight value, the firmware upgrade request level, the second weight value, and the third weight value.

[0042] The preset formula for calculating the overall priority is as follows:

[0043] Among them, W iIndicates the overall priority of the firmware upgrade corresponding to the i-th firmware upgrade request, X. i Y represents the first weight value corresponding to the i-th firmware upgrade request. i Z represents the firmware upgrade request level corresponding to the i-th firmware upgrade request. i B represents the second weight value corresponding to the i-th firmware upgrade request. i This represents the third weight value corresponding to the i-th firmware upgrade request, where n is the total number of firmware upgrade requests.

[0044] In some embodiments, sending each firmware upgrade request to the baseboard management controller for processing according to the overall priority level of each firmware upgrade request includes:

[0045] Each firmware upgrade request is added to the processing queue based on its overall priority level; and

[0046] Each firmware upgrade request is sent to the baseboard management controller for processing in the order they appear in the processing queue.

[0047] In some embodiments, firmware upgrade requests with high overall priority are placed at the head of the processing queue, while firmware upgrade requests with low overall priority are placed at the tail of the processing queue.

[0048] In some embodiments, the configuration file includes a first configuration file and a second configuration file, and the method includes:

[0049] Obtain firmware upgrade data, perform hash calculation on the firmware upgrade data, and obtain the target hash value;

[0050] Select a target hash value within a preset range as the key, encrypt the firmware upgrade data based on the key, and obtain the first configuration file;

[0051] Obtain the programming code, divide the programming code into multiple programming code segments;

[0052] Use a signature tool to generate a data signature for each burned code segment;

[0053] An authentication function is assigned to each programming code segment, and the data signature of each programming code segment and each programming code is encapsulated to obtain a second configuration file;

[0054] Obtain the key, data signature, and the first value of the authentication function, respectively; generate a configuration file identifier based on the product of the key, data signature, and the first value of the authentication function; and

[0055] The first and second configuration files are merged into a single configuration file, and the configuration file and its identifier are written into the upgrade area of ​​the external storage device.

[0056] In some embodiments, the external storage device further includes an encrypted region, which includes a first encrypted region and a second encrypted region, and the method further includes:

[0057] Obtain the key corresponding to the firmware upgrade data and store the key in the first encrypted area; and

[0058] Obtain the data signature and authentication function corresponding to each burned code segment, and store the data signature and authentication function corresponding to each burned code segment in the second encryption area.

[0059] In some embodiments, the firmware upgrade process by the baseboard management controller obtaining the configuration file from the external storage via the second link further includes:

[0060] The baseboard management controller obtains the key corresponding to the firmware upgrade data, the data signature corresponding to each burned code segment, and the authentication function from the encrypted area of ​​the external storage.

[0061] Obtain the first value of the key, data signature, and authentication function respectively, calculate the product of the first value of the key, data signature, and authentication function, and generate a verification value;

[0062] Obtain the configuration file identifier and determine whether the configuration file identifier matches the verification value; and

[0063] If the configuration file identifier matches the verification value, the configuration file verification is considered successful, and the baseboard management controller performs a firmware upgrade based on the configuration file.

[0064] In some embodiments, the configuration file in the external storage device includes a first configuration file and a second configuration file, and the method includes:

[0065] Configure the first configuration file to store firmware upgrade data, and configure the second configuration file to store flashing code; and

[0066] Both the firmware upgrade data and the burning code are encrypted.

[0067] In a second aspect, a computer program product is provided, comprising a computer program that, when executed by one or more processors, implements the steps of the method described in the first aspect.

[0068] Thirdly, a computer device is provided, including one or more processors; and a memory associated with the one or more processors, the memory being used to store computer-readable instructions that, when read and executed by the one or more processors, implement the steps of the method as described in the first aspect above.

[0069] Fourthly, this application provides a non-volatile computer-readable storage medium storing computer-readable instructions that, when executed by one or more processors, implement the steps of the method described in the first aspect above. Attached Figure Description

[0070] Figure 1 is a schematic diagram of the firmware upgrade structure in related technologies;

[0071] Figure 2 is a schematic diagram of firmware upgrade in another related technology;

[0072] Figure 3 is a schematic diagram of the firmware upgrade structure in some embodiments of this application;

[0073] Figure 4 is a schematic diagram of the firmware upgrade structure in some other embodiments of this application;

[0074] Figure 5 is a schematic diagram of the firmware upgrade structure in some embodiments of this application;

[0075] Figure 6 is a flowchart illustrating the firmware upgrade method in some embodiments of this application;

[0076] Figure 7 is a structural block diagram of a firmware upgrade device in some embodiments of this application;

[0077] Figure 8 is an internal structure diagram of a computer device in some embodiments of this application;

[0078] Figure 9 is an internal structure diagram of a computer program product in some embodiments of this application;

[0079] Figure 10 is an internal structure diagram of a non-volatile computer-readable storage medium in some embodiments of this application. Detailed Implementation

[0080] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0081] With societal development, information technology has gradually permeated all aspects of society. People's daily lives are increasingly inseparable from information and data. Especially with the development of cloud computing, big data, and AI (Artificial Intelligence), the information explosion necessitates servers as carriers for data processing and storage. Servers are also highly integrated internally. To achieve a specific function, discrete components are typically not used to build modules; instead, integrated controllers paired with simple peripherals are used. For example, to implement PCIE (Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard) to USB (Universal Serial Bus, a serial bus standard) functionality, a PCIE to USB Controller is used; to expand PCIE, a PCIE Switch (FCIE switch) is used; to expand SAS (Serial Attached Small Computer System Interface, a serial connection SCSI interface), a SAS Expander is used, and so on. These dedicated controllers or MCUs (Microcontroller Units) typically implement complex or customizable functions. Therefore, they are often paired with external EEPROM (Electrically Erasable Programmable Read-Only Memory) or FLASH (Electrically Erasable Programmable Read-Only Memory) to store configuration files or firmware for use during startup or operation. Since the configuration files or firmware are customizable, they also need to be adjusted and modified when problems occur, thus raising the issue of configuration file or firmware upgrades.

[0082] Please refer to Figure 1. Related Technology 1: On the PCB (Printed Circuit Board), the IC (Integrated Circuit) main controller connects to an external EEPROM (Electrically Erasable Programmable Read-Only Memory) via I2C, or to an external FLASH (Electrically Erasable Programmable Read-Only Memory) via SPI (Serial Peripheral Interface). The EEPROM or FLASH stores the IC main controller's configuration file or firmware. In a field environment, a serial port tool or JTAG (Joint Test Action Group) programmer is connected to a computer on one end, and to the IC main controller's UART (Universal Asynchronous Receiver / Transmitter) or JTAG interface on the other end. The configuration file or firmware in the external EEPROM or FLASH of the IC main controller can be updated using the programming program on the computer.

[0083] However, the above implementation method requires firmware upgrades to be performed in the field environment, and cannot be upgraded remotely. It also depends on the programming program on the computer. Different IC main controllers have different programming programs, and it is necessary to switch between different programming programs, which affects the timeliness of programming and is inefficient.

[0084] Referring to Figure 2, on the PCB (Printed Circuit Board), the IC master controller connects to an external EEPROM via I2C or to an external FLASH via SPI. The EEPROM or FLASH stores the IC master controller's configuration file or firmware. Additionally, the BMC (Baseboard Management Controller) on the PCB also interconnects with the IC master controller via I2C. The BMC can be remotely logged into, and the modified configuration file or firmware can be pushed to the IC master controller's RAM via I2C. The BMC code then calls the controller's programming API to program the configuration file or firmware from RAM to the controller's EEPROM or SPI FLASH via I2C or SPI.

[0085] However, in the implementation of the aforementioned related technology 2, each controller has a specific programming API. In order to program different controllers, the BMC needs to integrate the programming APIs of various controllers into its code, which increases the difficulty of BMC development. Furthermore, because it is necessary to integrate the programming APIs of various different controllers, the generated BMC programming file is very large, requiring the BMC to configure a larger external FLASH to store the firmware, which greatly increases the cost of the product.

[0086] In other words, in related technologies, there are two ways to upgrade the configuration files or firmware of these MCUs or dedicated controllers. The first method requires calling the controller's dedicated programming program through the controller's UART serial port or JTAG interface to modify or upgrade the configuration file. However, this method is only suitable for field environments and not for remote upgrades. The second method involves the BMC having an I2C connection to the MCU or dedicated controller. The modified configuration file or firmware is first pushed to the controller's RAM via I2C, and then the controller's programming API is called to program the configuration file or firmware in RAM to the controller's EEPROM or SPI FLASH. Although this method does not require a field environment and can be upgraded remotely via the BMC, each controller has a specific programming API. To program different controllers, the BMC needs to integrate the programming APIs of various controllers into its code. This not only increases the difficulty of BMC development but also generates large BMC programming files, requiring the BMC to configure larger external FLASH to store the firmware, significantly increasing product costs.

[0087] In some embodiments, this application provides a firmware upgrade device, as shown in FIG3. The firmware upgrade device provided in FIG3 includes a main controller (IC main controller), a baseboard management controller (BMC), a multiplexer (MUX), and an EEPROM (Electrically Erasable Programmable Read-Only Memory). The main controller is connected to the baseboard management controller. The first terminal of the multiplexer is connected to the main controller and the baseboard management controller respectively via an I2C transmission line. The second terminal of the multiplexer is connected to the external memory (EEPROM) of the main controller via an I2C transmission line.

[0088] Please refer to Figure 4. The firmware upgrade device shown in Figure 4 includes a main controller (IC main controller), a baseboard management controller (BMC), a multiplexer (MUX), and FLASH (electrically erasable programmable read-only memory). The main controller is connected to the baseboard management controller. The first end of the multiplexer is connected to the main controller and the baseboard management controller via a transmission line (SPI) respectively. The second end of the multiplexer is connected to the external memory (FLASH) of the main controller via a transmission line (SPI).

[0089] It is understandable that Figures 3 and 4 are used to distinguish different types of external storage devices. As can be seen from Figures 3 and 4, the transmission lines corresponding to different external storage devices are different, but the operation principle of firmware upgrade is the same. Signal transmission is performed between the main controller and the baseboard manager to execute logic judgments, control the multiplexer to switch the transmission lines, and then obtain the configuration file or firmware stored in the external storage device for use during startup or operation. Firmware upgrade is performed based on the obtained configuration file or firmware.

[0090] In some implementations, if the external memory of the IC master controller is an EEPROM, as shown in Figure 3, the main controller and the EEPROM are connected via an I2C bus. A MUX (multiplexer) is added between the EEPROM and the main controller. The first end of the EEPROM is connected to the second end of the MUX via a third transmission line (I2C). The first end of the MUX is connected to the main controller via a first transmission line, and the first end of the MUX is connected to the board management controller via a second transmission line. This MUX is a 2-to-1 MUX. This multiplexer can switch between the first and second transmission lines on the side of the multiplexer closest to the board management controller and the main controller. That is, the I2C line on the left side of the multiplexer (the I2C line between the IC master controller and the MUX or the I2C line between the BMC and the MUX) is switched to the I2C line on the right side (the third transmission line that connects the multiplexer to the external memory). The MUX switches one I2C master at a time.

[0091] If the external memory of the IC main controller is FLASH, as shown in Figure 4, and the transmission line between the main controller and the FLASH is an SPI bus, a MUX is added between the FLASH and the main controller. The first end of the FLASH is connected to the second end of the MUX via a third transmission line (SPI). The first end of the MUX is connected to the main controller via a first transmission line, and the first end of the MUX is connected to the baseboard management controller via a second transmission line. This MUX is also a 2-to-1 MUX. This multiplexer implementation can switch between the first and second transmission lines on the side of the multiplexer closest to the baseboard management controller and the main controller. That is, the SPI on the left side of the multiplexer (the SPI line between the IC main controller and the MUX or the SPI line between the BMC and the MUX) is switched to the SPI on the right side (the third transmission line that connects the multiplexer to the external memory).

[0092] There are two GPIO (General Purpose Input / Output) pins between the BMC and the main controller. The BMC sends the first firmware upgrade signal, UPDATE_EN_N (active low, default high), to the I2C main controller. This signal informs the I2C main controller that it is about to upgrade the main controller's configuration file or firmware via the BMC. The main controller sends the second firmware upgrade signal, UPDATE_LOCK (active high, default low), back to the BMC. This signal stops accessing or writing to the external EEPROM or FLASH after the main controller receives the UPDATE_EN_N signal from the BMC and it goes low, ensuring that the I2C or SPI bus is locked in an idle state. An idle state refers to the state of the system or device when it is not performing any tasks; it is in a state of inactivity or unused operation. The second firmware upgrade signal, UPDATE_LOCK, then goes high back to the BMC. The purpose of this design is to enhance the stability and reliability of BMC firmware upgrades, ensuring that the IC master controller's access to the I2C or SPI bus of EEPROM or FLASH is in an idle state and locked. Only then is the BMC allowed to switch the MUX channel. This avoids data loss caused by the BMC switching to the MUX channel when there is still data activity on the I2C or SPI bus, which could lead to system crashes in severe cases.

[0093] There is one GPIO pin between the BMC and the MUX, sent by the BMC to the MUX. This is the control signal MUX_SEL, used to control MUX switching. By default, MUX_SEL is low, and the first end of the MUX switches to the first transmission line for data transmission with the main controller, meaning the main controller can access the external memory connected to the second end of the MUX. When the BMC needs to upgrade the main controller's configuration file or firmware, after receiving a high-level UPDATE_LOCK signal from the main controller, the BMC switches the control signal MUX_SEL high. At this point, the first end of the MUX switches to the second transmission line for data transmission with the board management controller, allowing the BMC to directly access the external memory. The BMC can then directly modify, read, write, and refresh the configuration file or firmware in the external memory without relying on the main controller's programming API. This way, the board management controller can develop a generic programming code module for external memory without needing to know which main controller it is or integrate programming APIs for different main controllers.

[0094] Referring to Figure 5, in actual server circuits, multiple IC master controllers typically require EEPROM or FLASH upgrades. The actual topology would be as shown in Figure 5, where the I2C or SPI transmission lines of each MUX are cascaded to the transmission lines of the baseboard management controller, forming a daisy-chain topology. Additionally, there are two GPIOs between each master controller and the baseboard management controller, used to transmit the x-th first firmware upgrade signal UPDATE_ENx_N and the x-th second firmware upgrade signal UPDATE_LOCKx, respectively. Each multiplexer also has one GPIO between itself and the baseboard management controller, used for transmitting the x-th control signal MUXx_SEL, where x can be the order in which the firmware upgrade requests are executed.

[0095] In a cascaded configuration, the baseboard management controller upgrades the EEPROM or FLASH of one main controller simultaneously, executing the corresponding firmware upgrade requests in the order requested by the host computer to upgrade the system firmware.

[0096] In some embodiments, as shown in FIG6, a firmware upgrade method is provided, the method comprising the following steps:

[0097] Step 101: In response to receiving the first firmware upgrade signal, obtain the status of the first link, and connect the main controller and the external memory of the main controller through the first link.

[0098] In some embodiments, in response to the baseboard management controller receiving a firmware upgrade request, the baseboard management controller sends a first firmware upgrade signal to the main controller, the first firmware upgrade signal being a low-level signal; in response to the main controller receiving the first firmware upgrade signal; it is determined whether there is data transmission on the first link; in response to determining that there is data transmission on the first link, the first link is considered to be in a working state; in response to determining that there is no data transmission on the first link, the first link is considered to be in an idle state.

[0099] When the baseboard management controller receives a firmware upgrade request from a host controller, it sends a first firmware upgrade signal (UPDATE_EN_N shown in the diagram) to the host controller via a GPIO pin. This firmware upgrade signal is a low-level signal. Upon receiving this signal, the host controller checks whether there is data transmission between itself and the external memory. For example, if the external memory is determined to be EEPROM, it checks the SPI transmission line for data transmission; if it is determined to be FLASH, it checks the I2C transmission line for data transmission. If data transmission is detected on the I2C line, the system enters a waiting state; if no data transmission is detected, the corresponding transmission line is locked to ensure that no data is transmitted between the host controller and the external memory during subsequent link switching, thus enhancing system stability and reliability.

[0100] In some embodiments, the type of external memory of the main controller can be obtained, and the transmission line can be determined by the type of external memory, i.e., the first link can be determined. It can be determined whether there is data being transmitted on the first link, and then the state of the first link can be determined. In response to determining that there is data being transmitted on the first link, the first link is considered to be in a working state; in response to determining that there is no data being transmitted on the first link, the first link is considered to be in an idle state.

[0101] Step 102: In response to determining that the first link is in an idle state, the first link is locked and a second firmware upgrade signal is returned to the baseboard management controller.

[0102] In some embodiments, in response to determining that the first link is in an idle state, a locking command is triggered to lock the first link so that the first link remains in an idle state for a preset time period, and a second firmware upgrade signal is returned to the baseboard management controller. The second firmware upgrade signal is a high-level signal.

[0103] For example, in response to determining that the first link is in an idle state, a locking command is triggered to lock the first link so that the first link remains in an idle state for a preset time period. The preset time period can be the time period from the start of the locking time to the end of the firmware upgrade request. After the locking is completed, the main controller returns a second firmware upgrade signal (UPDATE_LOCK shown in the figure) to the baseboard management controller. The second firmware upgrade signal is a high-level signal.

[0104] Step 103: In response to the baseboard management controller receiving the second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link, and the second link connects the baseboard management controller and the external memory of the main controller.

[0105] In some embodiments, in response to the baseboard management controller receiving a second firmware upgrade signal returned by the main controller, the baseboard management controller sends a first control signal to the multiplexer, the first control signal being a high-level signal; in response to the multiplexer receiving the first control signal, the multiplexer switches to the second transmission line corresponding to the second pin, so that the baseboard management controller can transmit data with the external memory of the main controller through the second transmission line and the third transmission line.

[0106] For example, after the baseboard management controller receives the second firmware upgrade signal returned by the main controller and goes high, the baseboard management controller sends a first control signal (MUX_SEL high-level signal) to the multiplexer (MUX) that controls the main controller's I2C or SPI bus. The multiplexer switches the second pin closest to the baseboard management controller, changing the original first transmission line between the main controller and the multiplexer corresponding to the first pin to the second transmission line between the baseboard management controller and the multiplexer corresponding to the second pin for data transmission. In this way, the baseboard management controller can directly communicate with the main controller's external memory through the second transmission line, enabling the baseboard management controller to obtain the configuration file in the external memory.

[0107] Step 104: The baseboard management controller obtains the configuration file in the external storage through the second link to perform firmware upgrade.

[0108] In some embodiments, in response to the baseboard management controller obtaining the configuration file in the external memory, the configuration file is parsed to obtain firmware upgrade data and burning code; and firmware upgrade is performed based on the firmware upgrade data and burning code.

[0109] For example, the baseboard management controller can obtain a configuration file from the external memory. This configuration file includes firmware upgrade data and programming code. The baseboard management controller can then program and refresh the firmware of the IC main controller and its external memory (EEPROM or FLASH) based on the programming code—that is, a general-purpose EEPROM or FLASH programming code module—to achieve firmware upgrades. In this way, the baseboard management controller code does not need to integrate programming APIs for different main controllers, significantly reducing the size of the generated programming file. The baseboard management controller also does not need a large external memory to store the configuration file, greatly reducing product costs.

[0110] In this application, upon receiving a first firmware upgrade signal, the status of the first link is obtained; upon determining that the first link is idle, the first link is locked, and the first link connects the main controller and the external memory of the main controller, returning a second firmware upgrade signal to the baseboard management controller; upon receiving the second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link, and the second link connects the baseboard management controller and the external memory of the main controller; the baseboard management controller obtains the configuration file in the external memory through the second link for firmware upgrade, and the configuration file includes the burning code. Thus, by first determining the status of the first link and then controlling the multiplexer to switch between different links when the first link is idle, the stability of firmware upgrades can be improved. Obtaining the configuration file in the external memory for firmware upgrades avoids integrating the burning APIs of different main controllers into the baseboard management controller, greatly reducing the difficulty of code development. The method of this application can improve the reliability of firmware upgrades.

[0111] In some implementations, after the baseboard management controller obtains the configuration file in the external memory and performs a firmware upgrade via the second link, the following steps are taken: in response to the baseboard management controller performing a firmware upgrade on the configuration file in the external memory, the baseboard management controller sends a second control signal to the multiplexer, the second control signal being a low-level signal; in response to the multiplexer receiving the second control signal, the multiplexer switches to the first transmission line corresponding to the first pin, so that the main controller can transmit data with the external memory of the main controller via the first transmission line and the third transmission line.

[0112] For example, after the baseboard management controller completes the firmware burning of the external memory of the main controller, the baseboard control manager sends a second control signal to the multiplexer. The second control signal is a low-level signal. When the multiplexer receives the low-level second control signal (MUX_SEL) sent by the baseboard manager, the multiplexer switches to the first transmission line corresponding to the first pin, so that the main controller can transmit data with the external memory of the main controller through the first transmission line and the third transmission line (the transmission line between the multiplexer and the external memory). This realizes the switching of the second transmission line between the baseboard management controller and the multiplexer corresponding to the second pin to the original first transmission line between the main controller and the multiplexer corresponding to the first pin for data transmission, returning to the initial state. The baseboard management controller continues to wait for the firmware upgrade request issued by the host computer.

[0113] In some implementations, there are multiple firmware upgrade requests, and the firmware upgrade method further includes: generating a timestamp based on the generation time of each firmware upgrade request, and obtaining a first weight value corresponding to the timestamp; obtaining the configuration file download package and firmware upgrade request level carried by each firmware upgrade request, wherein the configuration file download package includes the starting position of the configuration file and the length of the configuration file; obtaining a second weight value corresponding to the starting position of the configuration file and a third weight value corresponding to the length of the configuration file; determining the overall firmware upgrade priority of each firmware upgrade request based on a preset comprehensive priority calculation formula, the first weight value corresponding to each firmware upgrade request, the firmware upgrade request level, the second weight value, and the third weight value; adding each firmware upgrade request to a processing queue according to the level of the overall firmware upgrade priority, wherein firmware upgrade requests with higher overall firmware upgrade priorities are located at the head of the processing queue, and firmware upgrade requests with lower overall firmware upgrade priorities are located at the tail of the processing queue; prioritizing the processing of firmware upgrade requests with higher overall priorities; and sequentially sending each firmware upgrade request to the baseboard management controller for processing according to the order of each firmware upgrade request in the processing queue.

[0114] In some embodiments, the firmware upgrade request level can be set as needed, such as the importance of the host computer initiating the firmware upgrade request, the firmware that needs to be upgraded first, and other factors. The starting position and length of the configuration file indicate the complexity of the configuration file processing. This application considers the impact of factors such as timestamps, the starting position of the configuration file, the length of the configuration file, and the firmware upgrade request level on firmware upgrade requests. A preset comprehensive priority calculation formula can be set according to different influencing factors. The comprehensive priority of each firmware upgrade request is calculated according to the preset comprehensive priority calculation formula. The firmware upgrade requests are then sent to the baseboard management controller for execution sequentially according to the comprehensive priority level of each firmware upgrade request, which can scientifically improve the efficiency of firmware upgrades.

[0115] The preset formula for calculating the overall priority is as follows:

[0116] Among them, W i Indicates the overall priority of the firmware upgrade corresponding to the i-th firmware upgrade request, X. i Y represents the first weight value corresponding to the i-th firmware upgrade request. i Z represents the firmware upgrade request level corresponding to the i-th firmware upgrade request. i B represents the second weight value corresponding to the i-th firmware upgrade request. i This represents the third weight value corresponding to the i-th firmware upgrade request, where n is the total number of firmware upgrade requests.

[0117] In one feasible implementation, this application can also obtain the association relationship between the firmware to be upgraded and other firmware upgrade requests corresponding to other firmware upgrade requests. It iterates through the firmware to be upgraded corresponding to each firmware upgrade request. When a firmware to be upgraded has an association relationship with any other firmware to be upgraded, the other firmware to be upgraded that have an association relationship are set as a group. For example, assuming that a firmware upgrade is performed on any group of firmware to be upgraded, firmware upgrades can be performed on the other firmware to be upgraded in the same group according to their overall upgrade priority. By considering the dependencies between multiple firmware to be upgraded when performing multi-firmware upgrade control, the reliability of multi-firmware upgrades can be effectively improved, avoiding problems such as upgrade failures or system anomalies caused by dependencies between firmware to be upgraded.

[0118] In some embodiments, the configuration file of this application includes a first configuration file and a second configuration file. The method includes: acquiring firmware upgrade data, performing hash calculation on the firmware upgrade data to obtain a target hash value; selecting a target hash value within a preset range as a key, encrypting the firmware upgrade data based on the key to obtain a first configuration file; acquiring flashing code, dividing the flashing code to obtain multiple flashing code segments; generating a data signature for each flashing code segment using a signature tool; assigning an authentication function to each flashing code segment, and encapsulating each flashing code segment and the data signature of each flashing code to obtain a second configuration file; acquiring the first value of the key, the data signature, and the first value of the authentication function respectively, and generating a configuration file identifier based on the product of the key, the data signature, and the first value of the authentication function; merging the first configuration file and the second configuration file into a configuration file, and writing the configuration file and the configuration file identifier into the upgrade area of ​​the external storage device.

[0119] In this application, the configuration file can be split into a first configuration file and a second configuration file. The first configuration file is used to store firmware upgrade data-related information, and the second configuration file is used to store flashing code-related information. The firmware upgrade data and flashing code are encrypted respectively, which can reduce the possibility of the configuration file being stolen during data transmission and further improve the security of firmware upgrade.

[0120] In some embodiments, firmware upgrade data can be obtained, features can be extracted from the firmware upgrade data, hash calculation can be performed based on the extracted firmware upgrade data features to obtain a target hash value, and the target hash value of any character range can be selected as a key to encrypt the firmware upgrade data to obtain a first configuration file. By encrypting the firmware upgrade data with a key obtained by processing the firmware upgrade data features, the accuracy of verification can be improved.

[0121] The programming code can be divided into multiple segments based on the operational phase of the business functions. According to the size of each segment and its storage location on external storage, a signature tool generates a data signature for each segment. An authentication function is assigned to each segment, establishing a mapping between each segment and its authentication function. The authentication function can be the business interface call function corresponding to each segment. By configuring signature authentication for these functions, subsequent verification of the second configuration file can be performed by calling the authentication function of each segment to verify its corresponding data signature, thus enabling the verification of the second configuration file.

[0122] In addition to the upgrade area, the external storage device of this application also includes an encryption area, which includes a first encryption area and a second encryption area. The method further includes: obtaining the key corresponding to the firmware upgrade data and storing the key corresponding to the firmware upgrade data in the first encryption area; obtaining the data signature and authentication function corresponding to each burning code segment and storing the data signature and authentication function corresponding to each burning code segment in the second encryption area.

[0123] In some implementations, the firmware upgrade process by the baseboard management controller (BMD) obtaining the configuration file from the external storage via the second link further includes: the BMD obtaining the key corresponding to the firmware upgrade data, the data signature corresponding to each burned code segment, and the authentication function from the encrypted area of ​​the external storage; obtaining the first value of the key, the data signature, and the authentication function respectively; calculating the product of the first value of the key, the data signature, and the authentication function to generate a verification value; obtaining the configuration file identifier and determining whether the configuration file identifier matches the verification value; and, in response to determining that the configuration file identifier matches the verification value, considering the configuration file verification successful, and the BMD performing the firmware upgrade according to the configuration file.

[0124] The configuration file in this application may include a configuration file identifier, which may be written to the beginning of the configuration file. The configuration file identifier may be the product of the first value of the key corresponding to the data, the data signature corresponding to the burning code, and the authentication function, etc.

[0125] This application establishes an encrypted area in an external storage device to store the key corresponding to the firmware upgrade data, the data signature corresponding to the burning code, and the authentication function. During subsequent authentication, the data in the encrypted area can be parsed first to obtain the data signature and authentication function corresponding to the key burning code of the firmware upgrade data. Then, the configuration file identifier in the upgrade area can be obtained. By determining whether the configuration file identifier matches the data signature and authentication function corresponding to the key burning code of the firmware upgrade data, the configuration file can be verified, thereby enhancing the security of firmware upgrades.

[0126] It should be understood that although the steps in the flowchart of Figure 6 are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in Figure 6 may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0127] In some embodiments, as shown in FIG7, a firmware upgrade device is provided, including: an acquisition module 20, a control module 21, and an upgrade module 22, wherein:

[0128] The acquisition module 20 is used to acquire the status of the first link in response to receiving the first firmware upgrade signal, wherein the first link connects the main controller and the external memory of the main controller.

[0129] Control module 21 is used to lock the first link and return a second firmware upgrade signal to the baseboard management controller in response to determining that the first link is in an idle state; in response to the baseboard management controller receiving the second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link, and the second link connects the baseboard management controller and the external memory of the main controller.

[0130] Upgrade module 22 is used by the baseboard management controller to obtain the configuration file in the external memory through the second link for firmware upgrade. The configuration file includes the burning code.

[0131] In some embodiments, other implementations of the firmware upgrade method that the above-described apparatus can achieve include the following steps:

[0132] In response to receiving the first firmware upgrade signal, the status of the first link is obtained as follows:

[0133] In response to the baseboard management controller receiving a firmware upgrade request, the baseboard management controller sends a first firmware upgrade signal to the main controller. The first firmware upgrade signal is a low-level signal.

[0134] In response to the main controller receiving the first firmware upgrade signal, it determines whether there is data being transmitted on the first link;

[0135] In response to the determination that data is being transmitted on the first link, the first link is considered to be in a working state;

[0136] If it is determined that there is no data being transmitted on the first link, then the first link is considered to be in an idle state.

[0137] In some embodiments, other implementations of the firmware upgrade method that the above-described apparatus can achieve include the following steps:

[0138] In response to determining that the first link is in an idle state, the first link is locked, and a second firmware upgrade signal is returned to the baseboard management controller, including:

[0139] In response to determining that the first link is in an idle state, a locking command is triggered to lock the first link so that the first link remains in an idle state for a preset time period, and a second firmware upgrade signal is returned to the baseboard management controller. The second firmware upgrade signal is a high-level signal.

[0140] In some embodiments, other implementations of the firmware upgrade method that the above-described apparatus can achieve include the following steps:

[0141] The second link includes a second transmission line and a third transmission line. In response to the baseboard management controller receiving a second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link. The second link connects the baseboard management controller and the main controller. The external memory includes:

[0142] In response to the baseboard management controller receiving the second firmware upgrade signal returned by the main controller, the baseboard management controller sends a first control signal to the multiplexer, the first control signal being a high-level signal;

[0143] In response to the multiplexer receiving the first control signal, the multiplexer switches to the second transmission line corresponding to the second pin, so that the board management controller can transmit data with the external memory of the main controller through the second transmission line and the third transmission line.

[0144] In some embodiments, other implementations of the firmware upgrade method that the above-described apparatus can achieve include the following steps:

[0145] The baseboard management controller performs firmware upgrades by obtaining configuration files from external storage via a second link, including:

[0146] In response to the baseboard management controller obtaining the configuration file in the external memory, the configuration file is parsed to obtain firmware upgrade data and burning code;

[0147] Firmware upgrades are performed based on firmware upgrade data and burning code.

[0148] In some embodiments, other implementations of the firmware upgrade method that the above-described apparatus can achieve include the following steps:

[0149] The first link includes a first transmission line and a third transmission line. After the baseboard management controller obtains the configuration file in the external memory through the second link and performs firmware upgrade, it includes:

[0150] In response to the firmware upgrade of the configuration file in the external memory by the baseboard management controller, the baseboard management controller sends a second control signal to the multiplexer. The second control signal is a low-level signal.

[0151] In response to the multiplexer receiving the second control signal, the multiplexer switches to the first transmission line corresponding to the first pin, so that the main controller can transmit data with the external memory of the main controller through the first transmission line and the third transmission line.

[0152] In some embodiments, other implementations of the firmware upgrade method that the above-described apparatus can achieve include the following steps:

[0153] Firmware upgrade requests can be multiple, and the methods also include:

[0154] Generate a timestamp based on the generation time of each firmware upgrade request, and obtain the first weight value corresponding to the timestamp;

[0155] Obtain the configuration file download package and firmware upgrade request level carried by each firmware upgrade request. The configuration file download package includes the start position of the configuration file and the length of the configuration file. Obtain the second weight value of the start position of the configuration file and the third weight value corresponding to the length of the configuration file.

[0156] The overall priority of each firmware upgrade request is determined based on the preset comprehensive priority calculation formula, the first weight value corresponding to each firmware upgrade request, the firmware upgrade request level, the second weight value, and the third weight value.

[0157] Each firmware upgrade request is added to the processing queue according to its overall priority level. Firmware upgrade requests with higher overall priority levels are placed at the head of the processing queue, while firmware upgrade requests with lower overall priority levels are placed at the tail of the processing queue.

[0158] Each firmware upgrade request is sent to the baseboard management controller for processing in the order they appear in the processing queue.

[0159] The preset formula for calculating the overall priority is as follows:

[0160] Among them, W i Indicates the overall priority of the firmware upgrade corresponding to the i-th firmware upgrade request, X. iY represents the first weight value corresponding to the i-th firmware upgrade request. i Z represents the firmware upgrade request level corresponding to the i-th firmware upgrade request. i B represents the second weight value corresponding to the i-th firmware upgrade request. i This represents the third weight value corresponding to the i-th firmware upgrade request, where n is the total number of firmware upgrade requests.

[0161] For limitations on the firmware upgrade device, please refer to the limitations on the firmware upgrade method above, which will not be repeated here. Each module in the aforementioned firmware upgrade device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0162] In some embodiments, as shown in FIG9, this application also provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by one or more processors, the computer is able to perform the firmware upgrade methods provided by the above methods.

[0163] In some embodiments, a computer device is provided, which may be a server, and its internal structure may be as shown in Figure 8. The computer device includes a processor, memory, a network interface, and a database connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile computer-readable storage medium and internal memory. The non-volatile computer-readable storage medium stores an operating system, computer-readable instructions, and a database. The internal memory provides an environment for the operation of the operating system and computer-readable instructions in the non-volatile computer-readable storage medium. The database of the computer device stores data applied by a firmware upgrade method. The network interface of the computer device is used to communicate with external terminals via a network connection. When the computer-readable instructions are executed by the processor, a firmware upgrade method is implemented.

[0164] Those skilled in the art will understand that the structure shown in Figure 8 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. The computer device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0165] In some embodiments, a computer device is provided, including one or more processors; and a memory associated with the one or more processors, the memory storing computer-readable instructions that, when read and executed by the one or more processors, perform the following steps:

[0166] Step 101: In response to receiving the first firmware upgrade signal, obtain the status of the first link, and connect the main controller and the external memory of the main controller through the first link.

[0167] Step 102: In response to determining that the first link is in an idle state, the first link is locked and a second firmware upgrade signal is returned to the baseboard management controller.

[0168] Step 103: In response to the baseboard management controller receiving the second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link, and the second link connects the baseboard management controller and the external memory of the main controller.

[0169] Step 104: The baseboard management controller obtains the configuration file in the external storage through the second link to perform firmware upgrade.

[0170] In some embodiments, as shown in FIG10, this application provides a non-volatile computer-readable storage medium storing computer-readable instructions thereon, which, when executed by one or more processors, implement the following steps:

[0171] Step 101: In response to receiving the first firmware upgrade signal, obtain the status of the first link, and connect the main controller and the external memory of the main controller through the first link.

[0172] Step 102: In response to determining that the first link is in an idle state, the first link is locked and a second firmware upgrade signal is returned to the baseboard management controller.

[0173] Step 103: In response to the baseboard management controller receiving the second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link, and the second link connects the baseboard management controller and the external memory of the main controller.

[0174] Step 104: The baseboard management controller obtains the configuration file in the external storage through the second link to perform firmware upgrade.

[0175] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0176] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0177] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A firmware upgrade method characterized by, include: In response to receiving the first firmware upgrade signal, the status of the first link is obtained, and the first link is connected between the main controller and the external memory of the main controller; In response to the first link being in an idle state, the first link is locked, and a second firmware upgrade signal is returned to the baseboard management controller; In response to the baseboard management controller receiving a second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link, the second link connecting the baseboard management controller and the external memory of the main controller; as well as The baseboard management controller obtains the configuration file in the external storage via the second link to perform firmware upgrades.

2. The method of claim 1, wherein, The step of obtaining the status of the first link in response to receiving the first firmware upgrade signal includes: In response to the baseboard management controller receiving a firmware upgrade request, the baseboard management controller sends a first firmware upgrade signal to the main controller; In response to the main controller receiving a first firmware upgrade signal, it determines whether there is data being transmitted on the first link; In response to determining that data is being transmitted on the first link, the first link is considered to be in a working state; and In response to determining that no data is being transmitted on the first link, the first link is considered to be in an idle state.

3. The method of claim 2, wherein, The first firmware upgrade signal is a low-level signal, wherein the first firmware upgrade signal is an active low-level signal.

4. The method of claim 1, wherein, The step of locking the first link and returning a second firmware upgrade signal to the baseboard management controller in response to determining that the first link is idle includes: In response to determining that the first link is in an idle state, a locking command is triggered to lock the first link so that the first link remains in an idle state for a preset time period, and a second firmware upgrade signal is returned to the baseboard management controller.

5. The method of claim 4, wherein, The second firmware upgrade signal is a high level, wherein the second firmware upgrade signal is a high-level active signal.

6. The method of claim 1, wherein, The first link includes a first transmission line and a third transmission line, and the second link includes a second transmission line and the third transmission line, wherein, The first transmission line connects the first terminal of the multiplexer to the main controller; The second transmission line connects the first terminal of the multiplexer to the baseboard management controller; and The third transmission line connects the external memory and the second end of the multiplexer.

7. The method according to claim 1 or 6, characterized in that, The second link includes a second transmission line and a third transmission line. In response to the baseboard management controller receiving a second firmware upgrade signal, the baseboard management controller controls the main controller to send a first control signal to the multiplexer to control the multiplexer to switch to the second link. The second link connects the baseboard management controller and the main controller's external memory, which includes: In response to the baseboard management controller receiving a second firmware upgrade signal returned by the main controller, the baseboard management controller sends a first control signal to the multiplexer; and In response to the multiplexer receiving the first control signal, the multiplexer switches to the second transmission line so that the baseboard management controller can transmit data with the external memory of the main controller through the second transmission line and the third transmission line.

8. The method of claim 1, wherein, The baseboard management controller obtains the configuration file in the external storage via the second link to perform firmware upgrades, including: In response to the baseboard management controller obtaining the configuration file in the external memory, the configuration file is parsed to obtain firmware upgrade data and flashing code; and Firmware upgrade is performed based on the firmware upgrade data and the burning code.

9. The method according to claim 1 or 6, characterized in that, The first link includes a first transmission line and a third transmission line. After the baseboard management controller obtains the configuration file in the external memory through the second link and performs a firmware upgrade, it includes: In response to the baseboard management controller performing a firmware upgrade on the configuration file in the external memory, the baseboard management controller sends a second control signal to the multiplexer; and In response to the multiplexer receiving a second control signal, the multiplexer switches to the first transmission line so that the main controller can transmit data with the external memory of the main controller through the first transmission line and the third transmission line.

10. The method of claim 1, wherein, The method further includes: (The firmware upgrade request is multiple.) Generate a timestamp based on the generation time of each firmware upgrade request; Obtain the configuration file download package and firmware upgrade request level carried by each firmware upgrade request. The configuration file download package includes the start position of the configuration file and the length of the configuration file. The overall firmware upgrade priority of each firmware upgrade request is determined based on a preset comprehensive priority calculation formula, the timestamp, the firmware upgrade request level, the start position of the configuration file, and the length of the configuration file; and Each firmware upgrade request is sent to the baseboard management controller for processing based on the overall priority level of the firmware upgrade request.

11. The method of claim 10, wherein, The process of determining the overall priority of each firmware upgrade request based on a preset comprehensive priority calculation formula, the timestamp, the firmware upgrade request level, the start position of the configuration file, and the length of the configuration file includes: Obtain the first weight value corresponding to the timestamp, the second weight value of the start position of the configuration file, and the third weight value corresponding to the length of the configuration file; and The overall priority of each firmware upgrade request is calculated based on the preset comprehensive priority calculation formula, the first weight value, the firmware upgrade request level, the second weight value, and the third weight value. The preset comprehensive priority calculation formula is as follows: Among them, W i Indicates the overall priority of the firmware upgrade corresponding to the i-th firmware upgrade request, X. i Y represents the first weight value corresponding to the i-th firmware upgrade request. i Z represents the firmware upgrade request level corresponding to the i-th firmware upgrade request. i B represents the second weight value corresponding to the i-th firmware upgrade request. i This represents the third weight value corresponding to the i-th firmware upgrade request, where n is the total number of firmware upgrade requests.

12. The method of claim 10, wherein, The step of sending each firmware upgrade request to the baseboard management controller for processing according to the overall priority level of each firmware upgrade request includes: Each firmware upgrade request is added to the processing queue according to the overall priority level of each firmware upgrade; and Each firmware upgrade request is sent to the baseboard management controller for processing in the order they appear in the processing queue.

13. The method of claim 12, wherein, Firmware upgrade requests with higher overall priority are located at the head of the processing queue, while firmware upgrade requests with lower overall priority are located at the tail of the processing queue.

14. The method of claim 1, wherein, The configuration file includes a first configuration file and a second configuration file, and the method includes: Obtain firmware upgrade data, perform hash calculation on the firmware upgrade data, and obtain the target hash value; Select a target hash value within a preset range as a key, and encrypt the firmware upgrade data based on the key to obtain the first configuration file; Obtain the programming code, and divide the programming code into multiple programming code segments; Use a signature tool to generate a data signature for each burned code segment; An authentication function is assigned to each of the programming code segments, and the data signature of each programming code segment and each programming code is encapsulated to obtain a second configuration file; Obtain the key, the data signature, and the first value of the authentication function, respectively; generate a configuration file identifier based on the product of the key, the data signature, and the first value of the authentication function; and The first configuration file and the second configuration file are merged into a single configuration file, and the configuration file and its identifier are written into the upgrade area of ​​the external storage device.

15. The method of claim 14, wherein, The external storage device further includes an encrypted region, which comprises a first encrypted region and a second encrypted region. The method further includes: Obtain the key corresponding to the firmware upgrade data, and store the key corresponding to the firmware upgrade data in the first encrypted area; and Obtain the data signature and authentication function corresponding to each burned code segment, and store the data signature and authentication function corresponding to each burned code segment in the second encryption area.

16. The method of claim 15, wherein, The firmware upgrade process for the baseboard management controller, which obtains the configuration file from the external storage via the second link, also includes: The baseboard management controller obtains the key corresponding to the firmware upgrade data, the data signature corresponding to each burning code segment, and the authentication function from the encrypted area of ​​the external storage. Obtain the key, the data signature, and the first value of the authentication function respectively, calculate the product of the key, the data signature, and the first value of the authentication function, and generate a verification value; Obtain the configuration file identifier, and determine whether the configuration file identifier matches the verification value; and In response to the determination that the configuration file identifier matches the verification value, the configuration file verification is considered successful, and the baseboard management controller performs firmware upgrade according to the configuration file.

17. The method of claim 1, wherein, The configuration file in the external storage device includes a first configuration file and a second configuration file, and the method includes: The first configuration file is set to store firmware upgrade data, and the second configuration file is set to store flashing code; and The firmware upgrade data and the burning code are encrypted respectively.

18. A computer program product comprising a computer program, characterized in that, When the computer program is executed by one or more processors, it implements the steps of the method as described in any one of claims 1 to 17.

19. A computer device, comprising One or more processors; and a memory associated with the one or more processors, the memory to store computer readable instructions that, based on being read and executed by the one or more processors, implement steps of the method of any of claims 1-17.

20. A non-transitory computer readable storage medium, comprising: The non-transitory computer readable storage medium stores computer readable instructions that, based on being executed by one or more processors, implement steps of the method of any of claims 1-17.

Images