Server board firmware upgrade system, method, device, equipment and media

Abstract

This application discloses a server board firmware upgrade system, method, apparatus, device, and medium, relating to the field of network equipment technology. The system includes a baseboard management controller (CPLD) and multiple boards. Each board includes at least a programmable memory (CPLD), a programmable logic device (PLD), a first identifier input circuit, and a second identifier input circuit. The CPLD dynamically updates the board's unique identifier and firmware version identifier through the first and second identifier input circuits. This solves the problem in server applications where multiple shared printed circuit boards cannot share CPLD firmware and EEPROM programming files, thus avoiding firmware upgrade omissions or errors caused by too many derivative boards. This not only reduces R&D workload but also improves user experience.

Description

Technical Field

[0001] This application relates to the field of network equipment technology, and in particular to a server board firmware upgrade system, method, apparatus, device and medium. Background Technology

[0002] With the development of IoT, big data, and AI technologies, servers are playing an increasingly important role. The unique identifier of each board in a server (i.e., the Part Number (PN), used to uniquely identify a component) must be uniquely written into the Electrically Erasable Programmable Read-Only Memory (EEPROM) and the User Flash Memory (UFM) of the Complex Programmable Logic Device (CPLD). This UFM is a flash area provided to users in the CPLD for storing important information; the data is not lost when the CPLD is powered off. In other words, even if the functionality of a newly created derivative board remains unchanged due to hardware modifications, the Baseboard Management Controller (BMC) development team needs to modify the board PN in the EEPROM programming file, and the CPLD development team also needs to modify the board PN stored in the UFM, for example, changing 101 to the corresponding 102 / 103 / 104. This has increased communication costs and workload across various sectors, and has also indirectly increased the difficulty of managing firmware (FW, which is a program written only to EEPROM or Flash) on both the R&D and client sides. Currently, issues have arisen where hardware modifications leading to derivative boards are not communicated to the BMC and CPLD development teams for compatibility, resulting in incorrect board information alarms and the inability to upgrade the firmware. Summary of the Invention

[0003] This application provides a system, method, apparatus, device, and medium for upgrading server board firmware, to at least solve the problem in the related art where the firmware of a server board cannot be upgraded when generating derivative boards.

[0004] This application provides a server board firmware upgrade system, including: a baseboard management controller and multiple boards, each board including at least a programmable memory, a programmable logic device, a first identification input circuit and a second identification input circuit;

[0005] Multiple boards include a target board and derivative boards of the target board; the programmable logic devices of the derivative boards update the programmable memory and the unique identifier of the first board in the programmable logic devices through the first identifier input circuit;

[0006] The programmable logic device of the derivative board keeps the first firmware version identifier the same as that of the target board, or changes the first firmware version identifier, through the second identifier input circuit.

[0007] When the baseboard management controller determines that the first preset condition is met, it upgrades the board. The first preset condition is that the second firmware version identifier in the HPM firmware upgrade file is the same as the first firmware version identifier, and the second board unique identifier in the HPM firmware upgrade file is the same as the board type and board serial number in the first board unique identifier; the board type and board serial number of the derived board and the target board are the same.

[0008] This application also provides a method for upgrading the firmware of a server's circuit board, applied to the aforementioned server's circuit board firmware upgrade system; the method includes:

[0009] The baseboard management controller obtains the first board unique identifier and the first firmware version identifier information of the board.

[0010] The baseboard management controller parses the hpm firmware upgrade file to obtain the second firmware version identifier and the second board unique identifier, and compares the second firmware version identifier with the first firmware version identifier;

[0011] If the second firmware version identifier is consistent with the first firmware version identifier, the baseboard management controller will compare the board type and board serial number in the second board unique identifier with the board type and board serial number in the first board unique identifier, respectively.

[0012] If the board type and board serial number are the same, the board management controller will perform an upgrade operation on the board.

[0013] This application also provides a server board firmware upgrade device, applied to the aforementioned server board firmware upgrade system; the server's board management controller includes:

[0014] The first acquisition module is used to acquire the first board card unique identifier and the first firmware version identifier information of the board card;

[0015] The second acquisition module is used to parse the hpm firmware upgrade file to obtain the second firmware version identifier and the second board unique identifier, and compare the second firmware version identifier with the first firmware version identifier;

[0016] The first comparison module is used to compare the board type and board serial number in the second board unique identifier with the board type and board serial number in the first board unique identifier if the second firmware version identifier is consistent with the first firmware version identifier.

[0017] The upgrade execution module is used to perform an upgrade action on the board if the board type and board serial number are the same.

[0018] This application also provides a server, including: a baseboard management controller and a board;

[0019] The board includes a programmable memory and a programmable logic device; the programmable logic device is used to execute the steps performed by the programmable logic device in the board firmware upgrade method of the above-mentioned server;

[0020] The baseboard management controller includes a processor and a memory; the memory stores computer-executable instructions; the baseboard management controller executes the computer-executable instructions stored in the memory, causing the processor to perform the steps executed by the baseboard management controller in the aforementioned server board firmware upgrade method.

[0021] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the board firmware upgrade method for any of the above-described servers.

[0022] This application achieves a unified firmware architecture design for multiple boards through hardware adjustments. Therefore, when new derivative boards are created due to hardware changes, developers do not need to modify the board PN in the programmable memory programming file or the board PN stored in the programmable logic device. Only the first identifier input circuit needs to be modified or controlled to update the unique identifier of the first board in the programmable memory and programmable logic device. Modifying, controlling, or maintaining the second identifier input circuit can update or maintain the first firmware version identifier in the programmable memory. This solves the problem in server applications where multiple boards sharing a common printed circuit board cannot share CPLD firmware and EEPROM programming files, thus avoiding problems such as missing or incorrect firmware upgrades due to too many derivative boards. This not only reduces development workload but also improves user experience. Attached Figure Description

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

[0024] Figure 1This is a schematic diagram of a portion of an hpm packaging configuration file in a related technology.

[0025] Figure 2 This is a schematic diagram of a server backplane management topology in related technologies;

[0026] Figure 3 This application provides an optimized server backplane management topology diagram.

[0027] Figure 4 A partial schematic diagram of an optimized hpm packaging configuration file provided in an embodiment of this application;

[0028] Figure 5 A schematic diagram of a UFM storage data structure provided in an embodiment of this application;

[0029] Figure 6 A schematic flowchart illustrating a server board firmware upgrade method provided in an embodiment of this application;

[0030] Figure 7 This is a schematic block diagram of a server structure provided in an embodiment of this application. Detailed Implementation

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

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

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

[0034] With the development of IoT, big data, and AI technologies, servers are playing an increasingly important role. As the number of server manufacturers increases, users purchase servers from various vendors. However, this brings with it the challenge of maintaining servers from different manufacturers. As is well known, after server delivery, changes in requirements and the resolution of long-term operational issues often necessitate firmware (FW) upgrades. A single server contains multiple FWs, including those for the motherboard BMC / Basic Input / Output System (BIOS), CPLD / Microcontroller Unit (MCU), backplane, fan board, switch board, and UBB board CPLD. Managing FWs from multiple server manufacturers exponentially increases this number. Therefore, effectively managing FW files from different manufacturers, platforms, and boards to prevent missed or accidental updates has become a pressing issue.

[0035] In related technologies, the HPM firmware upgrade file is used to solve this problem. The principle is to add manufacturer and board-specific information to the HPM configuration file and package it together with the original firmware file to generate the HPM file. During firmware upgrades, the BMC can obtain the board's unique identifier from the system and compare it with the manufacturer and board-specific information in the HPM file. If the comparison is normal, the upgrade proceeds; otherwise, the upgrade is abandoned. This perfectly solves the problem of having too many firmware files and being difficult to manage.

[0036] The following example illustrates the technical solution of using hpm files for firmware upgrades. An hpm file is a partially encrypted file packaged by a firmware manager. It is based on the existing firmware files of programmable chips (CPLD / BMC / Basic Input / Output System (BIOS) / Expander / Microcontroller Unit (MCU)), encrypted using configuration files and packaging tools, ultimately generating a firmware upgrade file that is only compatible with the current board, effectively avoiding accidental flashing issues between different manufacturers, platforms, and boards.

[0037] Figure 1 This document shows a configuration file used when packaging with hpm, where the board PN serves as the unique identifier for the board. Figure 2 This paper illustrates a common backplane management topology in servers. The BMC manages the backplane through the Inter-Integrated Circuit (I2C), a simple, bidirectional two-wire synchronous serial bus mainly used to connect microcontrollers and their peripherals. Figure 2In this system, the BMC, as the server's management chip, primarily relies on I2C for communication and monitoring of devices and components. The board's PN (Programmable Component Number) is crucial as it serves as the board's unique identifier. It is stored on the backplane in the EEPROM and the CPLD's UFM (User Function Meter), with the format YZxx-yyyyy-zzz. Here, xx represents the board type, yyyyy represents the board serial number, and zzz represents a derived board under this serial number. For example, YZBB-01234-101 is a backplane, while YZBB-01234-102 is its derived board (sharing the same PCB but with different Bill of Materials (BOM)).

[0038] After each normal operation of the BMC, it reads the PN number stored in the EEPROM and CPLD's UFM via I2C. If they match, the system continues to run without alarming; if they do not match, an alarm is triggered and the online upgrade function is disabled. When performing a FW upgrade, the BMC parses the board PN in the hpm file and compares it with the PN read from the CPLD's UFM. If they match, the upgrade is performed; if they do not match, an alarm is triggered and the upgrade is rejected.

[0039] The aforementioned technical solution addresses the problem of managing numerous firmware (FW) from multiple vendors and boards. However, in practical applications, the application scenarios of boards are complex and varied. For example, due to structural issues, Mylar (Metal-to-Metal Adhesion) may be added to a board; high-speed connectors may be replaced due to signal quality problems; or high-cost materials may be replaced to reduce costs. In all these situations, the board's PN (Proof-of-Concept) cannot remain unchanged, leading to the creation of derivative boards, such as the YZBB-01234-102 / 103 / 104 boards. Even if these derivative boards have no functional changes, the development of the Baseboard Management Controller (BMC) requires modification of the board PN in the EEPROM burning file, and the development of the CPLD also requires modification of the board PN stored in the UFM, for example, changing it from 101 to the corresponding 102 / 103 / 104. This brings more communication costs and workload to various fields, and also increases the difficulty of firmware (FW) management between the development and client sides. Currently, there are issues where hardware modifications to generate derivative boards fail to notify BMC and CPLD development teams for compatibility, leading to incorrect board information alarms and the inability to upgrade the firmware.

[0040] Therefore, this application provides a server board firmware upgrade system, including: a baseboard management controller (BMC) and multiple boards, each board including at least a programmable memory (e.g., EEPROM), a programmable logic device (e.g., CPLD), a first identification input circuit and a second identification input circuit;

[0041] Multiple boards include a target board and derivative boards of the target board; the programmable logic device of the derivative board updates the first board unique identifier (i.e., the first PN number) in the programmable memory and programmable logic device through the first upper identifier input circuit so that it is different from the first board unique identifier of the target board.

[0042] The programmable logic device of the derivative board can maintain the first firmware version identifier the same as the target board through the second identifier input circuit, or change the first firmware version identifier to be different from the target board.

[0043] When the baseboard management controller determines that the first preset condition is met, it upgrades the board. The first preset condition is that the second firmware version identifier in the HPM firmware upgrade file is the same as the first firmware version identifier, and the second board unique identifier (i.e., the second PN number) in the HPM firmware upgrade file is the same as the board type and board serial number in the first board unique identifier; the board type and board serial number of the derived board and the target board are the same.

[0044] Specifically, the baseboard management controller is used for managing the server motherboard. More specifically, it's a dedicated microcontroller on the motherboard used to monitor and manage system hardware status. It operates independently of the system's main CPU and remains active even when the system is shut down, enabling remote management and monitoring. The main functions of the baseboard management controller include: real-time monitoring of sensor data such as temperature, voltage, fan speed, and power consumption; for example, reading CPU temperature sensor data via the IPMI protocol and triggering alarms or automatic frequency reduction when thresholds are exceeded; remote power on / off and restart (even if the host system crashes); remote KVM (keyboard, video, mouse) functionality, controlling the host BIOS interface via the network; remotely mounting ISO images for system installation or maintenance; recording system events (such as power failures and hardware replacements) to the SEL (System Event Log); and role-based access control (such as administrators, operators, and read-only users).

[0045] A circuit board (or simply "board") typically refers to various functional cards that can be inserted into the motherboard's expansion slots, in addition to the motherboard itself. Examples of circuit boards include backplanes, fan boards, switch boards, and Universal Breakout Boards (UBBs). Of course, circuit boards are not limited to these listed types; they can be other types as long as they frequently share a PCB and contain programmable devices such as CPLDs or MCUs capable of running code. These will not be listed exhaustively here.

[0046] The programmable memory in the board can be, for example, EEPROM, flash memory, ferroelectric RAM (FRAM), magnetoresistive RAM (MRAM), etc. The programmable logic devices in the board can be, for example, CPLD, field-programmable gate arrays (FPGA), MCUs, and other programmable devices capable of running code.

[0047] Both the first and second identifier input circuits can be pull-up / pull-down resistor groups. Specifically, the first identifier input circuit can be a first pull-up / pull-down resistor group, and the second identifier input circuit can be a second pull-up / pull-down resistor group. The number of pull-up / pull resistors in the first pull-up / pull-down resistor group can be the same as the number of digits of the unique identifier of the first board, and the number of pull-up / pull resistors in the second pull-up / pull-down resistor group can be the same as the number of digits of the firmware version identifier. In this embodiment, the selection of pull-up / pull resistors needs to comprehensively consider factors such as signal integrity, power consumption, drive capability, and stability. The resistance value of the pull-up / pull resistors can be 1kΩ to 10kΩ, for example, using 4.7kΩ or 10kΩ pull-up resistors. The key factors for resistance value selection are: 1. Drive capability: The drive current of the I / O pins of the CPLD is limited (e.g., typically 5mA to 20mA), and it is necessary to avoid using too low a resistance value, which would result in excessive current. For example, if VCC=3.3V, a 1kΩ pull-up resistor will generate approximately 3.3mA of current, and it must be ensured that it does not exceed the pin's maximum current; 2. Signal integrity: low resistance (e.g., 1kΩ) can speed up signal rise / fall times, but may increase reflections and electromagnetic interference (EMI), while high resistance (e.g., 47kΩ) will prolong signal transition time, and timing requirements must be met; 3. Power consumption: low resistance pull-up resistors continuously consume power (I=VCC / R) when the signal is low, while high resistance can reduce static power consumption; 4. External interference: high impedance lines (e.g., high resistance pull-up) are susceptible to noise and must be used in conjunction with filter capacitors (e.g., 100nF in parallel).

[0048] Specifically, the pull-up or pull-down function of each resistor in the pull-up / pull-down resistor group can be switched by modifying the circuit, or by controlling the controllable switch between the resistor and the pull-up power supply and ground point.

[0049] In other embodiments, the first or second identifier input circuit can be any other circuit. The circuit is acceptable as long as it can input multi-bit signals to the programmable logic device of the board and can change the level of each input signal according to control.

[0050] This application embodiment achieves a unified firmware architecture design for multiple boards through hardware adjustments. Therefore, when new derivative boards are created due to hardware changes, developers do not need to modify the board PN in the programmable memory programming file or the board PN stored in the programmable logic device. Only the first identifier input circuit needs to be modified or controlled to update the unique identifier of the first board in the programmable memory and programmable logic device. Modifying, controlling, or maintaining the second identifier input circuit can update or maintain the first firmware version identifier in the programmable memory. This solves the problem in server application scenarios where multiple boards sharing a common printed circuit board cannot share CPLD firmware and EEPROM programming files, thus avoiding problems such as missing or incorrect firmware upgrades due to too many derivative boards. This not only reduces development workload but also improves user experience.

[0051] In some optional implementations, if the second firmware version identifier is inconsistent with the first firmware version identifier, the board management controller outputs the corresponding second alarm message and refuses to upgrade the board.

[0052] In some optional implementations, if the board management controller is inconsistent in either the board type or the board serial number, it outputs a corresponding third alarm message and refuses to upgrade.

[0053] In some optional embodiments, each board also includes an analog switch; the analog switch is located on the communication link between the baseboard management controller and the programmable memory;

[0054] After power-on, the programmable logic device of the derivative board turns off the analog switch and turns on the analog switch when the second preset condition is met. The second preset condition is that the unique identifier of the first board in the programmable memory and the programmable logic device has been updated based on the first identifier input circuit, and the first firmware version identifier of the programmable logic device has been updated based on the second identifier input circuit.

[0055] The board management controller upgrades the board when the analog switch is turned on and the first preset condition is met.

[0056] An analog switch is an electronic component used to control the on / off state of analog signals. Its function is similar to a mechanical switch, but it is controlled by electronic signals and offers advantages such as high speed, long lifespan, and high integration. Selecting an analog switch requires comprehensive consideration of factors such as signal integrity, power consumption, number of channels, voltage compatibility, and switching characteristics. Specifically, a lower on-resistance (Ron) results in less signal attenuation, especially for open-drain buses like I2C that rely on pull-up resistors. On-resistance can be, for example, 1Ω to 20Ω (low Ron, such as 1Ω, reduces signal voltage drop, suitable for high-speed I2C). High Ron, however, leads to longer signal rise times, potentially triggering timing violations (such as the SCL / SDA rise time requirements of I2C). The bandwidth must meet the maximum speed requirements of I2C. Standard mode (100kHz): bandwidth > 1MHz is sufficient. Fast mode (400kHz): bandwidth > 5MHz is recommended. High-speed mode (3.4MHz): bandwidth > 30MHz is required (e.g., the ADG1608 has a bandwidth of 160MHz). Channel capacitance, including input and output capacitance, is crucial. Excessive capacitance will reduce signal rise / fall speed and increase latency. The power supply voltage (VDD) must cover the logic level range of the I2C bus. For example, a 3.3V I2C system requires switches with VDD ≥ 3.3V. When the switch is open, the isolation between channels must be sufficiently high (e.g., > 50dB@1MHz) to avoid signal crosstalk. Switches with low standby current should be selected.

[0057] In addition, after the analog switch is turned on, the baseboard management controller obtains the first firmware version identifier stored in the programmable logic device and records the first firmware version identifier into the corresponding register to facilitate the comparison of firmware version identifiers.

[0058] The following example illustrates the optimized server board management topology.

[0059] Figure 3 This illustrates the optimized backplane (a type of board) management topology. (By...) Figure 3 It can be observed that some adjustments have been made to the hardware design based on the original topology. Figure 3 In this process, an analog switch is added to the I2C link between the BMC and the EEPROM. Its enable signal is connected to the general-purpose input / output (GPIO) pin of the CPLD to control the on / off state of the analog switch. At the same time, 4 bits of PN_ID and 2 bits of FW_ID are connected to the CPLD's GPIO through pull-up and pull-down resistors.

[0060] Specifically, the enable signal of the analog switch is pulled up by hardware by default to enable BMC to access EEPROM via I2C even after the CPLD hangs.

[0061] Use pull-up and pull-down resistors to connect the 4-bit PN_ID to the CPLD's GPIO. The PN_ID for board 101 is 0001, for board 102 it's 0010, and so on, with the PN_ID for board 109 being 1001. Use pull-up and pull-down resistors to connect the 2-bit FW_ID to the CPLD's GPIO. 01 indicates that this board uses FW1, 10 indicates that this board uses FW2, and 11 indicates that this board uses FW3. That is, the FW_ID for boards 101 / 102 / 103 is 01, the FW_ID for boards 104 / 105 / 106 is 10, and the FW_ID for boards 107 / 108 / 109 is 11.

[0062] In this embodiment, when a new derivative board is created due to hardware changes, developers do not need to modify the board PN in the programmable memory (e.g., EEPROM) programming file or the board PN stored in the programmable logic device (e.g., CPLD). Only the pull-up and pull-down functions of the pull-up and pull-down resistors in the first pull-up and pull-down resistor group need to be modified to update the unique identifier of the first board in the programmable memory and programmable logic device. Modifying or maintaining the pull-up and pull-down functions of the pull-up and pull-down resistors in the second pull-up and pull-down resistor group is sufficient to update or maintain the first firmware version identifier in the programmable memory. This solves the problem in server applications where multiple shared printed circuit board (PCB) boards cannot share CPLD firmware and EEPROM programming files, thus avoiding firmware upgrade omissions or errors caused by too many derivative boards. This not only reduces development workload but also improves user experience.

[0063] Printed Circuit Boards (PCBs) are core components of electronic devices. They use pre-designed conductive copper foil patterns to achieve electrical connections between electronic components (such as chips, resistors, and capacitors) and provide mechanical support for these components. The basic structure of a PCB includes an insulating substrate (such as FR-4 epoxy resin fiberglass board), conductive copper layers (formed by etching), pads (for soldering components), and vias (connecting lines between different layers). PCBs can be classified according to complexity as single-sided boards, double-sided boards, and multilayer boards (such as the PCBs with more than 10 layers in mobile phones).

[0064] In this embodiment, not only was a unified firmware architecture design for multiple boards achieved through hardware adjustments, but the BMC / CPLD code was also adaptively modified. Ultimately, a unified firmware architecture design was completed through dynamic adaptation. Regarding the CPLD code modification, for example… Figure 3The analog switch control signals, PN_ID, and FW_ID shown are all connected to the CPLD. The CPLD needs to develop code to switch the analog switch control signals at appropriate times. Simultaneously, the CPLD needs to dynamically adjust relevant information in the EEPROM and UFM based on PN_ID and FW_ID to complete the board's PN adaptation. Regarding the BMC code modification, specifically, it changes from parsing and comparing the board's PN to parsing and comparing FW_ID with the board's PN in this embodiment, thereby enabling the function of upgrading the FW of multiple boards with a single hpm file.

[0065] In this embodiment of the application, when a new derivative board is generated based on the target board, if the firmware version of the derivative board is the same as that of the target board, then the firmware version identifier of the target board can be used, that is, there is no need to change the firmware version identifier of the derivative board.

[0066] In addition, the embodiments of this application also modify the hpm configuration file. The original configuration file only contained the board PN, while the modified configuration file is as follows: Figure 4 As shown, a firmware version identifier (i.e., FW_ID information) has been added to indicate the firmware version.

[0067] Specifically, such as Figure 4 As shown, a "FwDistinguish" field is added to the hpm configuration file to identify the version of the FW file. The "FwDistinguish" field corresponds one-to-one with the FW_ID, and the "FwDistinguish" field remains consistent across different boards sharing the same FW version. That is, in the hpm configuration files of boards 101 / 102 / 103, the "FwDescription" field is YZBB01234101 and the "FwDistinguish" field is 0x01; in the hpm configuration files of boards 104 / 105 / 106 with the FW_ID, the "FwDescription" field is YZBB01234104 and the "FwDistinguish" field is 0x02; and in the hpm configuration files of boards 107 / 108 / 109, the "FwDescription" field is YZBB01234107 and the "FwDistinguish" field is 0x03.

[0068] The following example illustrates the process of upgrading a circuit board.

[0069] In some optional implementations, during the firmware upgrade process of the board, the baseboard management controller parses the hpm firmware upgrade file to obtain the second firmware version identifier and the second board unique identifier, and compares the second firmware version identifier with the first firmware version identifier of the board.

[0070] When the second firmware version identifier is consistent with the first firmware version identifier, the baseboard management controller compares the board type and board serial number in the second board unique identifier with the board type and board serial number in the first board unique identifier of the board respectively.

[0071] If the board type and board serial number are consistent, the baseboard management controller determines that the first preset condition is met.

[0072] In this embodiment, only the board type and board serial number in the board's unique identifier are compared. Specifically, only the xx and yyyyy fields in the board's PN (YZxx-yyyyy-zzz) are compared, not the zzz field. The derived board and its original board (i.e., the target board) have the same xx and yyyyy fields, differing only in the zzz field. If the second firmware version identifier in the hpm firmware upgrade file is also the same as the first firmware version identifier, then an upgrade can be performed. This allows for the upgrade of multiple board firmware versions using a single hpm file, while also preventing erroneous upgrades due to different firmware versions.

[0073] Specifically, when the Baseboard Management Controller (BMC) parses the hpm firmware upgrade file, it primarily identifies relevant information within the file to determine the device and firmware to be upgraded, and performs a validity verification to ensure the correct firmware upgrade. This includes:

[0074] 1. Identifying File Header Information: The HPM format file includes an HPM header and the original upgrade image file. The HPM header contains information such as the type of the card to be upgraded. After the BMC identifies the HPM format upgrade image file, it will first read its HPM header to determine whether the card to be upgraded is a BIOS, CPLD, or other type of card, and then call the corresponding upgrade program for that card to perform the upgrade.

[0075] II. Verification and Identification Information: Some hpm files also contain board identification information, such as the custom identification code ID of the motherboard or backplane CPLD, and the CPLD device's own Code ID. BMC will parse the hpm file, obtain these magic number structure data, and compare them with the actual working data of the board to be updated on the server. If they match, it means that the hpm file is prepared for this board, and the upgrade operation can continue; if they do not match, the upgrade will be terminated.

[0076] 3. Firmware Data Extraction: The BMC extracts the original upgrade image file from the hpm file, which contains the actual firmware data used to upgrade the board. For example, for a CPLD firmware upgrade, the CPLD firmware source file (usually a bin file) is extracted and then uploaded to the CPLD for updating.

[0077] IV. Firmware Integrity Verification: In some cases, the hpm file may also contain integrity verification information such as the firmware's MD5 checksum. After extracting the firmware data, BMC may calculate the MD5 value of the original upgrade image file and compare it with the checksum in the hpm file to ensure that the firmware has not been tampered with or damaged during transmission and storage. Only after the verification passes will the firmware upgrade process officially begin.

[0078] V. Perform the Upgrade Operation: After completing the above parsing and verification steps, BMC will write the extracted firmware data to the corresponding storage area of ​​the board to be upgraded (such as the flash memory of the CPLD, the BIOS chip, etc.) according to the preset upgrade process, thus completing the firmware upgrade. After the upgrade is completed, BMC may read the board's firmware version and other information again to confirm whether the upgrade was successful.

[0079] In some optional implementations, the baseboard management controller compares the second firmware version identifier with the first firmware version identifier of the board if it determines that the programmable memory (such as EEPROM) of the board matches the first unique identifier of the board stored in the programmable logic device (such as CPLD).

[0080] In other words, the identifier comparison process described in the previous embodiment only begins if the unique identifier of the first board stored in the programmable memory (such as EEPROM) matches that stored in the programmable logic device (such as CPLD). Here, every field of the board's unique identifier needs to be compared; only when all fields are identical will it be considered a match.

[0081] In this embodiment, after the BMC runs, it compares the unique board identifier (PN number) of the programmable memory and the programmable logic device. If an anomaly is found, an alarm is triggered and online upgrades are disabled. The firmware version identifier (FW_ID) is read and recorded. During FW upgrades, the hpm is first compared with the FW_ID in the programmable logic device, and then the board type and board serial number fields in the board PN are compared. Upgrades are only performed when both match, ensuring the accuracy and security of board FW upgrades and guaranteeing stable system operation.

[0082] In some alternative implementations, if the baseboard management controller determines that the programmable memory and the unique identifier of the first board stored in the programmable logic device are inconsistent, it outputs the corresponding first alarm message and disables the upgrade function for the board.

[0083] The first alarm message can be output locally or remotely. Local output methods include: 1. Using front panel indicator lights, such as color (red) or flashing lights; 2. Displaying alarm codes on a screen. Remote output methods include: 1. Sending alarms to the network management system via a Simple Network Management Protocol Trap (SNMP Trap); 2. Displaying alarm logs in real-time on a remote console; 3. Automatically pushing alarms via a configured Simple Mail Transfer Protocol Trap (SMTP) server or SMS gateway.

[0084] In some optional implementations, when the programmable logic device (such as a CPLD) determines that the second preset condition is not met, it writes the first board unique identifier of the board into the programmable logic device's own memory and the storage area of ​​the programmable memory based on the first identifier input circuit, and writes the first firmware version identifier into the programmable logic device's own memory based on the second identifier input circuit.

[0085] Specifically, when the first identifier input circuit and the second identifier input circuit are a first pull-up / pull-down resistor group and a second pull-up / pull-down resistor group, the programmable logic device receives the pull-up or pull-down signals of each resistor in the first pull-up / pull-down resistor group to obtain the first board unique identifier. The programmable logic device receives the pull-up or pull-down signals of each resistor in the second pull-up / pull-down resistor group to obtain the first firmware version identifier.

[0086] In this embodiment, one end of a pull-up or pull-down resistor is connected to a power source and the other end is grounded. There can be a controllable switch between the power source and the resistor, which can be used to switch the resistor to either a pull-up or pull-down resistor.

[0087] Specifically, the first board's unique identifier and / or the first firmware version identifier are stored in the user flash memory (UFM) of the programmable logic device.

[0088] In some optional implementations, the communication link between the programmable logic device and the programmable memory is a target integrated circuit interconnect bus (I2C) path;

[0089] Before the programmable logic device writes the first board's unique identifier into the programmable memory's storage area, it determines whether the target integrated circuit interconnect bus path is in integrated circuit interconnect bus master mode. If not, it switches to integrated circuit interconnect bus master mode.

[0090] After the programmable logic device writes the first board's unique identifier into the programmable memory's storage area, it switches the target integrated circuit interconnect bus path to the integrated circuit interconnect bus slave state.

[0091] I2C (Inter-Integrated Circuit) is a serial communication protocol that uses two wires (SDA and SCL) to communicate between multiple devices. On the I2C bus, devices can operate in two modes: Master mode and Slave mode. These two modes play different roles in the communication process:

[0092] In Master mode, the dominant device in I2C communication controls the entire communication process. The Master generates the clock signal (SCL) and controls the data transmission rate. The clock frequency can be set according to system requirements; common I2C standard mode uses 100kHz, fast mode uses 400kHz, and high-speed mode can reach 3.4MHz. The Master determines when to start and end a communication session. At the start of communication, the Master generates a start condition on the SDA line (SDA transitions from high to low when SCL is high); at the end of communication, it generates a stop condition (SDA transitions from low to high when SCL is high). The Master selects the Slave to communicate with by sending the slave device address. The address is typically 7 or 10 bits and is sent immediately after the start condition. The Master indicates the data transmission direction by sending the R / W bits (read / write bits) in the address frame. R / W=0 indicates a write operation (Master sends data to Slave), and R / W=1 indicates a read operation (Master receives data from Slave).

[0093] In Slave mode, the Slave plays a passive role in I2C communication, responding to requests from the Master. The Slave continuously listens to the SCL and SDA lines, waiting for the Master to send the start condition and address. When the received address matches its own address, the Slave sends an acknowledge (ACK) signal, indicating readiness for communication. The Slave must synchronize with the SCL signal generated by the Master, sampling or sending data on the edge of the SCL signal. When the Master sends data, the Slave receives the data and sends an ACK after each byte (unless it's the last byte). When the Master requests data, the Slave sends the data and waits for the Master's ACK / NACK. If the Master sends a NACK, indicating that data reception is complete, the Slave stops sending. Some Slave devices can notify the Master of available data via an interrupt pin, improving communication efficiency.

[0094] Server boards can use various communication protocols beyond I2C, such as General Purpose Input Output (GPIO), Serial Peripheral Interface (SPI), Universal Asynchronous Receiver / Transmitter (UART), and ScanChain. GPIO allows the CPLD's GPIO pins to be configured as input or output interfaces, providing additional control and monitoring functions. For example, the BMC can communicate with the CPLD via GPIO to control power-on / off and detect button status. However, this method consumes more pins on the CPLD and other chips, which is inconvenient for signal routing and results in slower transmission speeds and limited data transfer. SPI is a synchronous full-duplex communication protocol that supports multiple slaves and can reach high clock frequencies, making it suitable for high-speed, short-distance communication. The CPLD can communicate with other devices, such as an MCU, via the SPI interface. If the CPLD only sends data to the MCU, the MCU can act as an SPI slave, connecting to the CPLD through pins such as CS, CLK, and DAT. UART is an asynchronous serial communication protocol with flexible baud rates, suitable for point-to-point transmission, and a simple protocol stack. CPLDs can use UART to communicate with other chips; however, a discrepancy in baud rates between the sender and receiver can lead to data transmission errors, and high-speed transmission may affect system real-time performance. ScanChain is a low-speed signal transmission protocol that converts parallel data into serial data. Using a ScanChain bus to connect the BMC and CPLD reduces the number of pins used by the BMC, enabling rapid information exchange between the BMC and CPLD. It can be used to transmit signals such as CPU error signals and fan speed control signals. Additionally, CPLDs can implement custom parallel interface communication via GPIO, enabling high-speed data transmission, but requiring strict timing control. This approach allows for flexible design of communication protocols and timings based on specific needs, making it suitable for situations with high data transmission speed requirements and relatively fixed communication scenarios.

[0095] In some optional implementations, the programmable logic device writes the first board unique identifier of the board into its own memory and the storage area of ​​the programmable memory, and writes the first firmware version identifier into its own memory. Then, it writes the target indication information (e.g., Write OK) into the corresponding status register. The target indication information is used to indicate that the second preset condition is met. Thus, the programmable logic device can subsequently determine whether the second preset condition is met based on the target indication information.

[0096] The status register of a CPLD (Complex Programmable Logic Device) stores the internal operating status, external event feedback, and configuration information. It serves as a crucial interface for status interaction between the CPLD and external controllers (such as MCUs and BMCs). Specifically, the status register records the operating status of key internal modules, such as power supply status (e.g., stable power supply, overvoltage / undervoltage alarms); clock module status (e.g., clock lockout, frequency normality); external interface status (e.g., I2C / SPI communication errors, GPIO level changes); and logic unit status (e.g., counter overflow, trigger status, current state machine stage). It captures external trigger events or internal exceptions and records them via flag bits, such as external interrupt signals (e.g., button triggers, sensor alarms); internal errors (e.g., configuration verification failure, logic conflicts); and operation completion flags (e.g., data transmission completed, configuration loading complete). It also stores the CPLD's configuration status or user-defined parameters, such as configuration mode; enable status (e.g., whether a functional module is activated); and version information (e.g., hardware version number, firmware compilation time). Status registers typically consist of a set of binary bits, each representing a specific meaning. The number of bits can be designed according to requirements (commonly 8-bit, 16-bit, or 32-bit). External controllers (such as MCUs) typically access the CPLD's status registers through parallel or serial interfaces (such as I2C).

[0097] The following example, using a circuit board as the backplane, illustrates the technical solution provided in the embodiments of this application.

[0098] Assuming the most complex application scenario, there are currently nine boards (YZBB-01234-101~109), where boards 101 / 102 / 103 share firmware version identifier FW1, boards 104 / 105 / 106 share firmware version identifier FW2, and boards 107 / 108 / 109 share firmware version identifier FW3. Under related technical solutions, nine versions of CPLD firmware and EEPROM programming files are required. However, with the implementation scheme of this application, only three versions of CPLD firmware and EEPROM programming files are needed.

[0099] Part 1: Hardware Design Modifications.

[0100] 1. For example Figure 3 As shown, the backplane schematic design was modified by adding an analog switch to the I2C link between the BMC and EEPROM. The enable signal of the switch is connected to the GPIO control of the CPLD. This signal is pulled up by the hardware by default to enable the BMC to access the EEPROM through I2C even if the CPLD hangs.

[0101] 2. Use pull-up and pull-down resistors to connect the 4-bit PN_ID to the GPIO of the CPLD. The PN_ID of 101 is 0001, the PN_ID of 102 is 0010, and so on. The PN_ID of 109 is 1001.

[0102] 3. Use pull-up and pull-down resistors to connect the 2-bit FW_ID to the GPIO of the CPLD. 01 indicates that this board uses FW1, 10 indicates that this board uses FW2, and 11 indicates that this board uses FW3. That is, the FW_ID of 101 / 102 / 103 is 01, the FW_ID of 104 / 105 / 106 is 10, and the FW_ID of 107 / 108 / 109 is 11.

[0103] In this embodiment, the correspondence between the PN_ID and FW_ID codes of boards 101 to 109 is clarified, providing a hardware foundation for board identification and functional differentiation, and constructing a hardware architecture for board information transmission and control.

[0104] Part Two: Modifying the hpm configuration file.

[0105] 1. For example Figure 4 As shown, add the "FwDistinguish" field to the hpm configuration file to identify the version of this FW file;

[0106] 2. The “FwDistinguish” field corresponds one-to-one with the FW_ID. For different boards using the same FW version, the “FwDistinguish” field remains consistent. Specifically, in the hpm configuration files for 101 / 102 / 103, the “FwDescription” field is YZBB01234101 and the “FwDistinguish” field is 0x01; in the hpm configuration files for 104 / 105 / 106, the “FwDescription” field is YZBB01234104 and the “FwDistinguish” field is 0x02; and in the hpm configuration files for 107 / 108 / 109, the “FwDescription” field is YZBB01234107 and the “FwDistinguish” field is 0x03.

[0107] This embodiment enables accurate recording and differentiated management of FW information for different boards using hpm files.

[0108] Part Three: Modification of CPLD Code.

[0109] 1. For example Figure 3 and Figure 5 As shown, after the CPLD is powered on, it immediately controls the analog switch to turn off via GPIO6, and the BMC cannot access the EEPROM.

[0110] 2. The CPLD reads the Status Register (SR) field stored in Page 2 of the UFM. If the value is Write OK, it means that the board PN and FW_ID have been dynamically adjusted, so proceed directly to step 6. If the value is not Write OK, it means that the CPLD is starting for the first time, so proceed to step 3.

[0111] 3. The CPLD identifies the PN_ID and, according to the correspondence between the PN_ID and the board PN, writes the actual board PN into Page 1 of the UFM;

[0112] 4. The CPLD simulates communication between the I2C Master and the EEPROM through the second I2C path, and writes the actual board PN to the corresponding position in the EEPROM;

[0113] 5. The CPLD identifies the FW_ID and, according to the above correspondence between the FW_ID and the "FwDistinguish" field, writes the FW_ID into Page 2 of the UFM, and writes the Write OK flag of the UFM and EEPROM into the status register (SR) field of the UFM.

[0114] 6. The CPLD converts the second I2C path to I2C Slave function, and at the same time controls the analog switch to be turned on through GPIO6, so that the BMC can access the EEPROM normally.

[0115] This embodiment completes the initialization of board information and the setting of communication permissions.

[0116] Part Four: Modification of BMC Code.

[0117] 1. After the BMC is running normally, read the PN number stored in the UFM of the EEPROM and CPLD via I2C. If they match, the system will run normally without alarms. If they do not match, an alarm will be triggered and the online upgrade function will be disabled.

[0118] 2. The BMC reads the FW_ID stored in the CPLD's UFM and records it in the register;

[0119] 3. When performing a backplane CPLD FW upgrade, the BMC parses the FW_ID and board PN fields in the hpm file and first compares them with the FW_ID read from the UFM. If the FW_ID does not match, an alarm is triggered and the upgrade is rejected. If the FW_ID matches, the BMC then compares the board PN field.

[0120] 4. If the xx and yyyyy fields in the board PN (YZxx-yyyyy-zzz) are consistent, it means that the PN and hpm file of multiple boards in this series can correspond. The BMC will perform the upgrade action; otherwise, it will issue an alarm and refuse to upgrade.

[0121] Through the above series of modifications, a solution was achieved where multiple PCB boards share the same CPLD firmware and EEPROM programming files, avoiding issues such as missing or incorrect firmware management caused by too many derivative boards. Furthermore, even if a new derivative board (such as 10A) is subsequently developed, due to the adaptive update function of PN_ID and the existence of FW_ID, existing BMC / CPLD code, EEPROM programming files, and hpm upgrade files can be directly used without causing any development work, and without any communication issues leading to missing firmware management for the 10A derivative board.

[0122] In summary, this embodiment of the application only requires a simple change to the original hardware link topology. Combined with modifications to the BMC and CPLD code, it solves the pain point of multiple shared PCB boards being unable to share CPLD firmware and EEPROM programming files, achieving unified firmware management. This effectively avoids risks such as firmware oversights and programming errors caused by a large number of derivative boards. While significantly reducing R&D workload, it also reduces customer complaints at the source, effectively improving the end-user experience and system reliability.

[0123] This application provides a method for upgrading server board firmware, which can be applied to the server board firmware upgrade system described in the above embodiments. The method is described in detail below with reference to the execution flow of the server board firmware upgrade method.

[0124] A method for upgrading server board firmware, such as Figure 6 As shown, it includes the following steps:

[0125] S101, The baseboard management controller obtains the first board unique identifier and the first firmware version identifier information of the board;

[0126] S102, the baseboard management controller parses the hpm firmware upgrade file to obtain the second firmware version identifier and the second board unique identifier, and compares the second firmware version identifier with the first firmware version identifier;

[0127] S103, if the second firmware version identifier is consistent with the first firmware version identifier, the baseboard management controller compares the board type and board serial number in the second board unique identifier with the board type and board serial number in the first board unique identifier, respectively.

[0128] S104 If the board type and board serial number are consistent, the baseboard management controller will perform an upgrade operation on the board.

[0129] In this embodiment, only the board type and board serial number in the board's unique identifier are compared. Specifically, only the xx and yyyyy fields in the board's PN (YZxx-yyyyy-zzz) are compared, not the zzz field. The derived board and its original board (i.e., the target board) have the same xx and yyyyy fields, differing only in the zzz field. If the second firmware version identifier in the hpm firmware upgrade file is also the same as the first firmware version identifier, then an upgrade can be performed. This allows for the upgrade of multiple board firmware versions using a single hpm file, while also preventing erroneous upgrades due to different firmware versions.

[0130] This application embodiment achieves a unified firmware architecture design for multiple boards through hardware adjustments. Therefore, when new derivative boards are generated due to hardware changes, developers do not need to modify the board PN in the programmable memory programming file or the board PN stored in the programmable logic device. Only the pull-up and pull-down functions of the pull-up and pull-down resistors in the first pull-up and pull-down resistor group need to be modified to update the unique identifier of the first board in the programmable memory and programmable logic device. Modifying or maintaining the pull-up and pull-down functions of the pull-up and pull-down resistors in the second pull-up and pull-down resistor group can update or maintain the first firmware version identifier in the programmable memory. This solves the problem in server application scenarios where multiple shared printed circuit board boards cannot share CPLD firmware and EEPROM programming files, thus avoiding problems such as missing or incorrect firmware upgrades due to too many derivative boards. This not only reduces the workload of development but also improves the user experience.

[0131] In some optional embodiments, before step S101, that is, before the baseboard management controller obtains the first board unique identifier and the first firmware version identifier information of the board, the following is also included:

[0132] S001, After the programmable logic device is powered on, it turns off the analog switch on the communication link between the board management controller and the programmable memory;

[0133] S002, if the programmable logic device determines that the programmable memory, the board unique identifier in the programmable logic device, and the firmware version identifier in the programmable logic device have been dynamically adjusted, then the analog switch is turned on.

[0134] Specifically, the target indication information can be used to determine whether the unique board identifier in the programmable memory and programmable logic device, as well as the firmware version identifier in the programmable logic device, has been dynamically adjusted.

[0135] In some optional embodiments, after step S001, that is, after the programmable logic device turns off the analog switch, the following steps are also included:

[0136] S003, if the programmable logic device determines that the programmable memory, the board unique identifier in the programmable logic device, and the firmware version identifier in the programmable logic device have not been dynamically adjusted, then based on the first pull-up and pull-down resistor group, the first board unique identifier of the board is written into the programmable logic device's own memory and the storage area of ​​the programmable memory, respectively, and based on the second pull-up and pull-down resistor group, the first firmware version identifier is written into the programmable logic device's own memory; the programmable logic device turns on the analog switch.

[0137] In some optional embodiments, before step S102, that is, before the baseboard management controller compares the second firmware version identifier with the first firmware version identifier, the method further includes:

[0138] The baseboard management controller compares the programmable memory of the board with the unique identifier of the first board stored in the programmable logic device.

[0139] In this embodiment, the identifier comparison process described in the previous embodiment only begins if the unique identifier of the first board stored in the programmable memory (such as EEPROM) and the programmable logic device (such as CPLD) matches. Here, each field of the board's unique identifier needs to be compared; only when all fields are identical will it be determined as a match.

[0140] In this embodiment, after the BMC runs, it compares the unique board identifier (PN number) of the programmable memory and the programmable logic device. If an anomaly is found, an alarm is triggered and online upgrades are disabled. The firmware version identifier (FW_ID) is read and recorded. During FW upgrades, the hpm is first compared with the FW_ID in the programmable logic device, and then the board type and board serial number fields in the board PN are compared. Upgrades are only performed when both match, ensuring the accuracy and security of board FW upgrades and guaranteeing stable system operation.

[0141] Furthermore, if the baseboard management controller determines that the unique identifier of the first board stored in the programmable memory and the programmable logic device is inconsistent, it will output a corresponding first alarm message and disable the board upgrade function. If the second firmware version identifier is inconsistent with the first firmware version identifier, the baseboard management controller will output a corresponding second alarm message and refuse to upgrade the board. If either the board type or the board serial number is inconsistent, the baseboard management controller will output a corresponding third alarm message and refuse to upgrade.

[0142] After the server board firmware upgrade is completed, a series of verification, configuration, and status recovery operations are required to ensure successful upgrade and stable system operation. For example, the BMC reads the current firmware version number of the board (such as CPLD, BIOS, network card, etc.) through interfaces such as I2C and SPI to confirm whether it is consistent with the upgrade package version; compares the read version number with the upgrade log or expected version to verify whether the upgrade was successfully written; restarts the board or server to check whether the hardware is initialized normally (such as fan speed, LED status, temperature sensor reading); verifies the core functions of the board (such as data transmission and reception of the network card, read and write performance of the storage controller); tests the communication between the board and other components through the BMC or management software; checks for communication errors or packet loss; performs load tests on the upgraded board (such as long-term high-bandwidth data transmission, intensive I / O operations) to verify stability; if the board configuration (such as BIOS settings, network card parameters) is cleared during the upgrade process, it needs to be restored from backup or template; updates the board status information (such as firmware version, health status) in the BMC database; and notifies the upper-level management system (such as IPMI, Redfish) that the firmware has been updated. In addition, the upgrade time, version number, and success / failure status need to be written to the BMC log; the firmware version, configuration changes, and test results before and after the upgrade should be summarized for administrator review.

[0143] For a description of the features in the embodiment of the server board firmware upgrade method and apparatus, please refer to the relevant description of the embodiment of the server board firmware upgrade system, which will not be repeated here.

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

[0145] Embodiments of this application also provide a server board firmware upgrade device, applied to any of the server board firmware upgrade systems provided in the above embodiments; the server's board management controller includes:

[0146] The first acquisition module is used to acquire the first board card unique identifier and the first firmware version identifier information of the board card;

[0147] The second acquisition module is used to parse the hpm firmware upgrade file to obtain the second firmware version identifier and the second board unique identifier, and compare the second firmware version identifier with the first firmware version identifier;

[0148] The first comparison module is used to compare the board type and board serial number in the second board unique identifier with the board type and board serial number in the first board unique identifier if the second firmware version identifier is consistent with the first firmware version identifier.

[0149] The upgrade execution module is used to perform an upgrade action on the board if the board type and board serial number are the same.

[0150] This application embodiment achieves a unified firmware architecture design for multiple boards through hardware adjustments. Therefore, when new derivative boards are generated due to hardware changes, developers do not need to modify the board PN in the programmable memory programming file or the board PN stored in the programmable logic device. Only the pull-up and pull-down functions of the pull-up and pull-down resistors in the first pull-up and pull-down resistor group need to be modified to update the unique identifier of the first board in the programmable memory and programmable logic device. Modifying or maintaining the pull-up and pull-down functions of the pull-up and pull-down resistors in the second pull-up and pull-down resistor group can update or maintain the first firmware version identifier in the programmable memory. This solves the problem in server application scenarios where multiple shared printed circuit board boards cannot share CPLD firmware and EEPROM programming files, thus avoiding problems such as missing or incorrect firmware upgrades due to too many derivative boards. This not only reduces the workload of development but also improves the user experience.

[0151] In some optional implementations, the programmable logic device includes:

[0152] The shutdown module is used to shut down the analog switch on the communication link between the board management controller and the programmable memory after power-on.

[0153] The first activation module is used to determine if the unique board identifier in the programmable memory and programmable logic device, as well as the firmware version identifier in the programmable logic device, have been dynamically adjusted, and then activate the analog switch.

[0154] In some optional embodiments, the programmable logic device further includes:

[0155] The second activation module is used to, if it is determined that the unique board identifier in the programmable memory and the programmable logic device, as well as the firmware version identifier in the programmable logic device, have not been dynamically adjusted, write the first unique board identifier of the board into the memory of the programmable logic device itself and the storage area of ​​the programmable memory based on the first pull-up and pull-down resistor group, and write the first firmware version identifier into the memory of the programmable logic device itself based on the second pull-up and pull-down resistor group; and activate the analog switch.

[0156] In some optional embodiments, the substrate management controller further includes:

[0157] The second comparison module is used to compare the programmable memory of the board with the first board unique identifier stored in the programmable logic device.

[0158] For a description of the features in the embodiment corresponding to the server board firmware upgrade device, please refer to the relevant description in the embodiment corresponding to the server board firmware upgrade method, which will not be repeated here.

[0159] Embodiments of this application also provide a server, such as Figure 7 As shown, it includes a baseboard management controller 10 and a board 20;

[0160] The board includes a programmable memory and a programmable logic device; the programmable logic device is used to execute the method steps executed by the programmable logic device in the above embodiment of the board firmware upgrade method for the server.

[0161] The baseboard management controller includes a processor and a memory; the memory stores computer-executable instructions; the baseboard management controller executes the computer-executable instructions stored in the memory, causing the processor to execute the method steps executed by the baseboard management controller in the above-described embodiment of the server board firmware upgrade method.

[0162] Specifically, there can be multiple boards, and derivative boards can be included. The baseboard management controller can be located on the server's motherboard. The server motherboard and boards are core hardware components; they have different functions but work closely together to support the server's computing, storage, networking, and other functions. The server motherboard is the "central nervous system" of the server, serving as the basic platform that carries all core hardware and connects various boards and peripherals. It not only provides physical support but also implements electrical connections and data interaction between components through circuit design. The functions of a server include: 1. Hosting core computing units: installing CPUs (supporting multiple CPUs, such as 2, 4, or even 8 CPUs, while ordinary PC motherboards typically only support 1 CPU), and memory (multi-channel, supporting Error Correcting Code (ECC) memory, with capacities up to TB); 2. Connecting key components: connecting cards (such as graphics cards and network cards) and storage devices (hard drives and solid-state drives, SSDs) via Peripheral Component Interconnect Express (PCIe) slots, Serial Advanced Technology Attachment (SATA) / Serial Attached SCSI (SAS) interfaces, M.2 interfaces, etc.; 3. Power and management: integrating a power management module, supporting redundant power supply access; and a built-in BMC (Baseboard Management Controller) to enable remote monitoring, fault diagnosis, and other maintenance functions; 4. Expansion and compatibility: supporting a large number of expansion interfaces (such as PCIe 4.0 / 5.0 slots, USB interfaces, and network interfaces), and being compatible with server-grade hardware. Server add-in cards are functional modules that insert into motherboard expansion slots to extend specific server functions and compensate for limitations of the motherboard's native capabilities. They are the core of a server's "modular" design and can be flexibly configured to meet specific needs.In addition to those mentioned above, server cards also include the following: 1. Network cards, such as gigabit / 10-gigabit network cards and fiber optic network cards, which expand the number of network interfaces or increase bandwidth to meet high-concurrency data transmission (such as data center cluster communication); 2. Storage cards, such as Redundant Array of Independent Disks (RAID) cards, which implement hard drive redundancy (such as RAID 0 / 1 / 5 / 6) to improve data security and read / write speed; Host Bus Adapter (HBA) cards, which connect to external storage devices to expand storage capacity; and Non-Volatile Memory Express (NVMe) accelerator cards, which directly connect to NVMe via PCIe. 3. SSDs, increasing storage IOPS (Input / Output Operations Per Second); 4. Computing accelerator cards, such as GPU cards, used for AI training, deep learning, and graphics rendering; FPGA cards, which implement customized computing (such as encryption / decryption, real-time data processing) through programmable logic; coprocessor cards, which offload specific tasks from the CPU (such as compression / decompression, video encoding); 5. Management cards, such as remote management cards, which operate independently of the host CPU and support remote power on / off, monitoring hardware status (temperature, voltage), system installation, etc.; 6. Interface expansion cards, such as USB expansion cards, serial port cards, and PCIe to PCI cards, which increase the types or number of motherboard interfaces and adapt to legacy devices (referring to hardware devices that follow older technical standards, interface protocols, or architectures).

[0163] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the embodiments of the board firmware upgrade method for any of the above-described servers when running.

[0164] In one exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks, as well as various memories mentioned in the above embodiments.

[0165] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the embodiments of the board firmware upgrade method for any of the above-described servers.

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

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

[0168] The foregoing has provided a detailed description of a server board firmware upgrade system, method, apparatus, device, computer-readable storage medium, and computer program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the methods and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A server board firmware upgrade system, characterized in that, include: The baseboard management controller and multiple boards, each of the boards including at least a programmable memory, a programmable logic device, a first identification input circuit and a second identification input circuit; The plurality of boards includes a target board and derivative boards of the target board; the programmable logic device of the derivative board updates the programmable memory and the first board unique identifier in the programmable logic device through the first identifier input circuit; The programmable logic device of the derivative board maintains the first firmware version identifier the same as that of the target board through the second identifier input circuit, or changes the first firmware version identifier. When the baseboard management controller determines that a first preset condition is met, it upgrades the board. The first preset condition is that the second firmware version identifier in the HPM firmware upgrade file is the same as the first firmware version identifier, and the second board unique identifier in the HPM firmware upgrade file is the same as the board type and board serial number in the first board unique identifier; the board type and board serial number of the derived board and the target board are the same; wherein, the HPM firmware upgrade file is an HPM file generated by adding board information to the HPM configuration file and packaging it together with the original firmware file. Each of the aforementioned boards also includes an analog switch; the analog switch is disposed on the communication link between the baseboard management controller and the programmable memory; After the programmable logic device of the derivative board is powered on, the analog switch is turned off, and the analog switch is turned on when the second preset condition is met. The second preset condition is that the unique identifier of the first board in the programmable memory and the programmable logic device has been updated based on the first identifier input circuit, and the first firmware version identifier of the programmable logic device has been updated based on the second identifier input circuit. The baseboard management controller upgrades the board when the analog switch is turned on and the first preset condition is met.

2. The system according to claim 1, characterized in that, The first identifier input circuit and / or the second identifier input circuit are pull-up and pull-down resistor groups.

3. The system according to claim 1, characterized in that, During the firmware upgrade process of the board, the baseboard management controller parses the hpm firmware upgrade file to obtain the second firmware version identifier and the second board unique identifier, and compares the second firmware version identifier with the first firmware version identifier of the board; When the second firmware version identifier is consistent with the first firmware version identifier, the baseboard management controller compares the board type and board serial number in the second board unique identifier with the board type and board serial number in the first board unique identifier of the board, respectively. If the board type and the board serial number are both consistent, the baseboard management controller determines that the first preset condition is met.

4. The system according to claim 3, characterized in that, When the baseboard management controller determines that the programmable memory of the board is consistent with the first board unique identifier stored in the programmable logic device, it compares the second firmware version identifier with the first firmware version identifier of the board.

5. The system according to claim 1, characterized in that, When the programmable logic device determines that the second preset condition is not met, it writes the first board unique identifier of the board into the programmable logic device's own memory and the storage area of ​​the programmable memory based on the first identifier input circuit, and writes the first firmware version identifier into the programmable logic device's own memory based on the second identifier input circuit.

6. The system according to claim 5, characterized in that, The communication link between the programmable logic device and the programmable memory is a target integrated circuit interconnect bus path; Before the programmable logic device writes the first board unique identifier of the board into the storage area of ​​the programmable memory, it determines that the target integrated circuit interconnect bus path is in integrated circuit interconnect bus master mode; if not, it switches to integrated circuit interconnect bus master mode. After the programmable logic device writes the first board's unique identifier into the storage area of ​​the programmable memory, it switches the target integrated circuit interconnect bus path to the integrated circuit interconnect bus slave mode.

7. The system according to claim 5, characterized in that, The programmable logic device writes the first board unique identifier of the board into its own memory and the storage area of ​​the programmable memory, and writes the first firmware version identifier into its own memory. Then, it writes the target indication information into the corresponding status register. The target indication information is used to indicate that the second preset condition is met.

8. The system according to claim 1, characterized in that, The unique identifier of the first board and / or the first firmware version identifier are stored in the user flash memory of the programmable logic device.

9. The system according to claim 4, characterized in that, If the baseboard management controller determines that the programmable memory is inconsistent with the unique identifier of the first board stored in the programmable logic device, it outputs the corresponding first alarm message and disables the upgrade function for the board.

10. The system according to claim 1, characterized in that, After the analog switch is turned on, the baseboard management controller obtains the first firmware version identifier stored in the programmable logic device and records the first firmware version identifier into the corresponding register.

11. The system according to claim 3, characterized in that, If the second firmware version identifier is inconsistent with the first firmware version identifier, the baseboard management controller outputs a corresponding second alarm message and refuses to upgrade the board.

12. The system according to claim 3 or 11, characterized in that, If the board type and the board serial number are inconsistent, the baseboard management controller will output the corresponding third alarm information and refuse to upgrade.

13. The system according to any one of claims 1-11, characterized in that, The board can be a backplane, fan board, switching board, or general expansion board.

14. A method for upgrading the firmware of a server's circuit board, characterized in that, A board firmware upgrade system applied to a server according to any one of claims 1-13; the method includes: The baseboard management controller obtains the first board unique identifier and the first firmware version identifier information of the board. The baseboard management controller parses the hpm firmware upgrade file to obtain the second firmware version identifier and the second board unique identifier, and compares the second firmware version identifier with the first firmware version identifier; If the second firmware version identifier is consistent with the first firmware version identifier, the baseboard management controller compares the board type and board serial number in the second board unique identifier with the board type and board serial number in the first board unique identifier, respectively. If the board type and the board serial number are both consistent, the baseboard management controller performs an upgrade operation on the board. Before the baseboard management controller obtains the first board unique identifier and the first firmware version identifier information of the board, the following is also included: After being powered on, the programmable logic device turns off the analog switch on the communication link between the substrate management controller and the programmable memory; If the programmable logic device determines that the programmable memory, the board unique identifier in the programmable logic device, and the firmware version identifier in the programmable logic device have been dynamically adjusted, then the analog switch is turned on.

15. A server board firmware upgrade device, characterized in that, A board firmware upgrade system for the server as described in any one of claims 1-13; The server's baseboard management controller includes: The first acquisition module is used to acquire the first board card unique identifier and the first firmware version identifier information of the board card; The second acquisition module is used to parse the hpm firmware upgrade file to obtain the second firmware version identifier and the second board unique identifier, and compare the second firmware version identifier with the first firmware version identifier; The first comparison module is used to compare the board type and board serial number in the second board unique identifier with the board type and board serial number in the first board unique identifier if the second firmware version identifier is consistent with the first firmware version identifier. The upgrade execution module is used to perform an upgrade action on the board if the board type and the board serial number are both consistent. Programmable logic devices include: A shutdown module is used to shut down the analog switch on the communication link between the baseboard management controller and the programmable memory after power-on. The first activation module is used to activate the analog switch when it is determined that the programmable memory and the board unique identifier in the programmable logic device, as well as the firmware version identifier in the programmable logic device, have been dynamically adjusted.

16. A server, characterized in that, include: Baseboard management controllers and boards; The board includes a programmable memory and a programmable logic device; the programmable logic device is used to perform the corresponding steps in the method as described in claim 14. The baseboard management controller includes a processor and a memory; the memory stores computer-executable instructions; the baseboard management controller executes the computer-executable instructions stored in the memory, causing the processor to perform the corresponding steps in the method as described in claim 14.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the method as described in claim 14.

18. A computer program product, characterized in that, Includes a computer program that causes a computer to perform the method as described in claim 14.

Images