BMC firmware generation method and device, BMC and storage medium

Abstract

The embodiment of the invention discloses a BMC firmware generation method and device, a BMC and a storage medium, and is applied to a first BMC, and the first BMC obtains a first identifier of a first server; the first identifier is used for indicating the type of the first server; searching and determining a first configuration file matched with the first server in a configuration file set according to the first identifier and a file name of each configuration file in the configuration file set managed by the first BMC; the file name of each configuration file in the configuration file set is determined according to the function of the configuration file and a set matching rule; constructing first BMC firmware based on the first configuration file; wherein the first BMC firmware is used for providing a function of managing the first server for the first BMC. By applying the method, the first BMC firmware suitable for the first server can be flexibly generated, the workload of maintaining the BMC firmware is reduced, and the compatibility of the BMC firmware is improved.

Description

Technical Field

[0001] This application relates to the field of server management technology, and in particular to a method, apparatus, BMC and storage medium for generating BMC firmware. Background Technology

[0002] With the rapid evolution of server architecture and the increasing diversity of hardware configurations, server manufacturers may maintain multiple sub-models or various hardware types within a single product line. These differentiated configurations include processor type, memory layout, number of expansion cards, motherboard version, backplane topology, power redundancy strategies, and thermal management solutions. This complexity presents challenges for the development and maintenance of the Baseband Controller (BMC).

[0003] In related technologies, BMC firmware is usually custom-developed for specific server models, requiring manual configuration of hardware initialization parameters, device trees, sensor mappings, debug channels, policy rules, and other components based on the model's characteristics. This approach is applicable when hardware is fixed and the number of server models is limited, but in the current context of large-scale deployment and rapid evolution of multiple models, it may lead to problems such as limiting system integration efficiency, lengthening delivery cycles, and increasing maintenance costs. Summary of the Invention

[0004] This application provides a method, apparatus, BMC, and storage medium for generating BMC firmware, which can flexibly generate BMC firmware suitable for various servers, reduce the workload of maintaining BMC firmware, and improve the compatibility of BMC firmware.

[0005] In a first aspect, one embodiment of this application provides a method for generating BMC firmware, applied to a first BMC, the first BMC being integrated on the motherboard of a first server, the first BMC being any one of a plurality of BMCs, and the first server being any one of a plurality of servers; the method includes: Obtain the first identifier of the first server; wherein the first identifier is used to indicate the type of the first server; Based on the first identifier and the filenames of each configuration file in the configuration file set managed by the first BMC, the first configuration file matching the first server is determined by searching in the configuration file set; wherein, the filename of each configuration file in the configuration file set is determined according to the function of the configuration file and the set matching rules; The first BMC firmware is constructed based on the first configuration file; wherein, the first BMC firmware is used to provide the first BMC with the function of managing the first server.

[0006] In this embodiment, the configuration file set managed by the first BMC includes multiple configuration files, each with a filename determined based on its function and matching rules. After obtaining the identifier of the first server, which indicates its type, the first configuration file matching the first server can be determined by searching the configuration file set based on the identifier and the filenames of the various configuration files. The first BMC firmware built using this first configuration file provides the first BMC with precise management capabilities for the first server. This design allows for flexible generation of BMC firmware suitable for various servers, facilitating BMC management, reducing the workload of maintaining BMC firmware, and improving BMC firmware compatibility.

[0007] In one optional implementation, based on the first identifier and the filenames of each configuration file in the configuration file set managed by the first BMC, a search is performed in the configuration file set to determine the first configuration file that matches the first server, including: Convert the first identifier into a first target identifier with a defined data format; Perform masking operations on the first target identifier with at least one mask sequence in sequence to obtain at least one operation result; Based on at least one calculation result and the filenames of each configuration file, search in the configuration file set to determine the first configuration file that matches the first server.

[0008] In the above embodiments, the server identifier indicates the type of server, and the file name of the configuration file is associated with the function of the configuration file. Therefore, by utilizing the compatibility between the server identifier and the file name of the configuration file, the first configuration file can be accurately selected from multiple configuration files.

[0009] In one optional implementation, the first target identifier is sequentially subjected to a masking operation with at least one mask sequence to obtain at least one operation result, including: The first target identifier is sequentially subjected to masking operations with at least one mask sequence to obtain at least one mask result that corresponds one-to-one; wherein, the maximum mask length in the at least one mask sequence is determined according to the first target identifier with a set data format; Each mask result is combined with its corresponding mask length to obtain the corresponding calculation result.

[0010] The above embodiments utilize the characteristics of masks to quickly filter, extract, and modify data bits. The first target identifier is sequentially subjected to mask operations with at least one mask sequence, and the resulting mask is then combined with the corresponding mask length. The resulting operation is more accurate, and the application of this operation result to filter configuration files is more accurate.

[0011] In one optional implementation, based on at least one calculation result and the filenames of each configuration file, a search is performed in the configuration file set to determine the first configuration file that matches the first server, including: For the first calculation result, in the set of configuration files, the configuration file that matches the first target file name indicated by the first calculation result is determined as the first reference configuration file; wherein, the first calculation result is any one of at least one calculation result; Regarding the second operation result, in the set of configuration files, the configuration file that matches the second target filename indicated by the second operation result is determined as the second reference configuration file; wherein, the second operation result is one of at least one operation result that is different from the first operation result; If the mask length used when obtaining the second operation result is greater than the mask length used when obtaining the first operation result, then the first reference configuration file is cleared. Among the reference configuration files corresponding to each calculation result, the reference configuration file retained after clearing some reference configuration files is determined to be the first configuration file matched by the first server.

[0012] In the above embodiments, the longer the mask length, the more detailed the configuration information carried in the configuration file matched by the calculation result. Therefore, applying the reference configuration file corresponding to the longer mask length to cover the reference configuration file corresponding to the shorter mask length makes the remaining configuration file more suitable for the server performance. On the other hand, it can also clean up storage space in a timely manner without storing irrelevant files, thereby improving processing speed.

[0013] In one optional implementation, based on at least one calculation result and the filenames of each configuration file, a search is performed in the configuration file set to determine the first configuration file that matches the first server, including: For any given operation result, the configuration file that matches the filename indicated by the operation result is selected as the reference configuration file from the set of configuration files. Among multiple reference configuration files, the first configuration file is determined; wherein, the first configuration file is the configuration file that matches the operation result obtained by applying the mask of the maximum length.

[0014] The above embodiments, as another way to determine the first configuration file among multiple configuration files, also rely on the fact that the longer the mask sequence, the more accurate the calculation result, and the first configuration file obtained in this way is more suitable for the server performance.

[0015] In one alternative implementation, the mask sequence is a binary sequence; the data format is set to binary format.

[0016] In the above embodiments, the mask of the binary sequence is calculated with the server identifier in binary format. The calculation process is simple and the processing efficiency is high.

[0017] In one optional implementation, obtaining the first identifier of the first server includes: Read the level status of the multiplexed pins connected to the DIP switch; The DIP switch value indicated by the DIP switch is determined based on the level status; The dial-up value is determined to be the first identifier of the first server.

[0018] The above embodiments, as one way to obtain the server's identifier, can directly obtain the identifier corresponding to the server by means of the level state of the multiple pins connected to the DIP switch.

[0019] In one optional implementation, obtaining the first identifier of the first server includes: By accessing the set register address, the first identifier of the first server, which is pre-stored at the set register address, is obtained.

[0020] The above embodiments, as another way to obtain the first identifier of the first server, read the first identifier stored at the set register address, which is simple to implement.

[0021] In one alternative implementation, accessing the set register address includes: The configuration register address is accessed by communicating with the configuration storage chip via the configuration bus; wherein, the configuration storage chip pre-configures and stores the first identifier of the first server.

[0022] The above embodiments access the setting register address through communication between the setting bus and the setting memory chip, which has high communication quality and can quickly and accurately obtain the first identifier of the first server.

[0023] Secondly, one embodiment of this application provides a BMC firmware generation apparatus, applied to a first BMC, the first BMC being integrated on the motherboard of a first server, the first BMC being any one of a plurality of BMCs, and the first server being any one of a plurality of servers; the apparatus includes: The data acquisition unit is configured to: acquire a first identifier of a first server; wherein the first identifier is used to indicate the type of the first server; The data processing unit is used to: search in the configuration file set according to the first identifier and the file names of each configuration file in the configuration file set managed by the first BMC to determine the first configuration file that matches the first server; wherein, the file name of each configuration file in the configuration file set is determined according to the function of the configuration file and the set matching rules; The data processing unit is also used to: construct a first BMC firmware based on a first configuration file; wherein the first BMC firmware is used to provide the first BMC with the function of managing the first server.

[0024] Thirdly, one embodiment of this application provides a baseboard management controller, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above methods.

[0025] Fourthly, one embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0026] Fifthly, one embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application 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.

[0028] Figure 1 A schematic diagram illustrating a single BMC applicable to a multi-purpose server model, as provided in an embodiment of this application; Figure 2 This is a schematic diagram of a server architecture provided in one embodiment of this application; Figure 3 A schematic diagram illustrating a method for generating BMC firmware according to an embodiment of this application; Figure 4 A schematic diagram illustrating an encoding rule provided in an embodiment of this application; Figure 5 A schematic diagram illustrating a DIP switch for identifying motherboard model and machine configuration, provided as an embodiment of this application; Figure 6 A schematic diagram illustrating the identification of motherboard model and machine configuration by a CPLD register is provided in one embodiment of this application; Figure 7 A schematic diagram illustrating a configuration file naming rule provided in an embodiment of this application; Figure 8 A schematic diagram illustrating the entire process of matching ID=0x73 in one embodiment of this application; Figure 9This is a schematic diagram illustrating the final selection of configuration files for various device models, provided as an embodiment of this application. Figure 10 A complete flowchart for generating BMC firmware is provided in one embodiment of this application; Figure 11 A schematic diagram of a BMC firmware generation device provided in an embodiment of this application; Figure 12 This is a schematic diagram of the structure of a BMC provided in an embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0030] For ease of understanding, the terms used in the embodiments of this application are explained below: (1) Baseboard Management Controller (BMC) is a microcontroller unit independent of the main system. It can remotely monitor the server hardware status, power on / off, and view logs. It is often used in data center management.

[0031] (2) BMC firmware is a software program that runs on the BMC chip. As its core software, BMC firmware mainly realizes the functions of managing server device information (recording server and component information, BMC itself information, etc.), server status monitoring and management (detecting the health status of components such as CPU, memory, hard disk, etc., adjusting fan speed, and reporting alarms when abnormal), server remote control management (power on / off, restart, firmware update, system installation, etc.), and maintenance management (log, user, BIOS, alarm, etc. management). It is the core control program for realizing out-of-band management of the server.

[0032] (3) Complex Programmable Logic Device (CPLD) is used to implement customized logic control functions, such as reset logic and power management. It is stable and reliable at the hardware level and is usually used on the motherboard or control board.

[0033] (4) Electrically Erasable Programmable Read-Only Memory (EEPROM) is used to store motherboard configuration information, calibration data, etc. Data can still be retained when power is off, and no external power supply is required.

[0034] (5) Microcontroller Unit (MCU) is a chip with a built-in processor, memory and interface. It is used to execute control logic, such as sensor reading and device control. It is the core of embedded devices.

[0035] (6) The information storage area of ​​the field replaceable unit (FRU) is used to store the serial number, version, etc. of components such as motherboard, fan, power supply, etc., to facilitate equipment management and maintenance record tracking.

[0036] (7) General-Purpose Input / Output (GPIO) can be flexibly set to high / low level and is used to control LEDs, read buttons, etc. It is a common way for devices to perform simple signal interaction.

[0037] (8) Inter-Integrated Circuit (I) 2 C), also known as a bidirectional two-wire synchronous serial bus, is a serial communication protocol based on two wires (SCL clock and SDA data). It supports communication between multiple master and slave devices and is often used for data transmission between various chips on the motherboard.

[0038] The number of any elements in the accompanying drawings is for illustrative purposes only and not as a limitation, and any naming is for distinction only and has no limiting meaning.

[0039] With the rapid evolution of modern server architectures and the increasing diversity of hardware configurations, server manufacturers often maintain multiple sub-models or various hardware combinations within a single product line. These differentiated configurations include processor type, memory layout, number of expansion cards, motherboard version, backplane topology, power redundancy strategies, and thermal management solutions. This complexity presents significant challenges to the development and maintenance of the Baseframe Management Console (BMC).

[0040] Traditional BMC firmware is typically custom-developed for specific server models, requiring manual configuration of hardware initialization parameters, device trees, sensor mappings, FRU read strategies, debug channels, policy rules, and other components based on the model's characteristics. While this approach was suitable in the early days when hardware was fixed and the number of server models was limited, in today's context of large-scale deployments and rapid evolution of multiple models, it leads to problems such as limiting system integration efficiency, lengthening delivery cycles, and increasing maintenance costs.

[0041] Figure 1This is a schematic diagram of a single BMC adapting to multiple server models provided in an embodiment of this application. In this example, it is assumed that motherboard 1, motherboard 2 and motherboard 3 are of different models, that is, the models of the servers they belong to are different. BMC11 is adapted to at least these three motherboards.

[0042] Furthermore, in scenarios such as high-performance computing (HPC), hyperscale data centers, and edge computing, there may be small-batch changes to the motherboard and frequent replacements of custom components throughout the server's lifecycle. If each variant requires manually building, debugging, and releasing a separate BMC firmware, it not only consumes engineering resources but also easily introduces configuration errors, causing malfunctions in the management layer or breaks in the monitoring link, affecting system stability and maintainability.

[0043] The relevant technologies mainly address the above problems in the following ways: Method 1: Build BMC firmware separately for each model.

[0044] Different motherboards or models correspond to a separate set of BMC firmware or configuration information. Whenever a new model is released, or hardware parameters or functions are adjusted, manufacturers manually modify the BMC source code, implant exclusive parameters and templates, generate, debug, and maintain multiple sets of firmware and multiple configuration files, and then rebuild to generate the firmware package. As the number of product models increases, the workload of development and maintenance grows linearly or even exponentially, while also increasing the complexity of collaboration and the risk of human error.

[0045] The advantages of this approach are its strong targeting and ability to achieve optimal control strategies, with precise mapping of various hardware parameters (such as the number of sensors, fan arrangement, backplane layout, etc.). However, since most parameters are the same across different models, if a common parameter needs to be adjusted, then every source code needs to be adjusted, resulting in a long build cycle and requiring testing of all upgraded versions for each change. Maintenance costs are extremely high, there are numerous versions, and upgrades or patch releases are exceptionally difficult. It is impossible to form a shared logic layer, resulting in low development efficiency. System debugging is highly dependent on the physical hardware of specific models.

[0046] Furthermore, existing standalone firmware configuration solutions are highly susceptible to inconsistencies due to manual operation and version distribution issues, leading to problems such as incorrect firmware configurations and parameter deviations, which complicates quality assurance. When new models are launched or older models are upgraded, additional branches and firmware / configurations are often required, increasing management complexity. Version tracking and feature iteration are also extremely difficult, prone to confusion and omissions.

[0047] Method 2: Use unified firmware to set operating parameters separately for each model.

[0048] Compared to Method 1, this approach saves on maintenance costs and facilitates distribution and integration. However, it still suffers from extremely complex and redundant configuration files. This method requires maintaining a set of fine-grained parameters for each device model, which can easily lead to configuration chaos without strict configuration specifications. Furthermore, due to the lack of a dynamic hardware identification mechanism, manual differentiation and selection of parameter sets are still necessary. Even with configuration specifications, maintaining dozens of nearly identical but slightly different configurations for dozens of different configurations is still possible. This "uniform in form, fragmented in content" approach does not substantially reduce maintenance costs; it only provides superficial optimization during the firmware build phase and still suffers from complex configuration issues.

[0049] In summary, the single-model, single-firmware design pattern in Method 1 often leaves developers facing dozens or even hundreds of BMC versions. Each hardware tweak (such as sensor model replacement) requires rebuilding the firmware for all models, and each bug fix necessitates manual rollout to all models. Firmware upgrades also require manual verification of compatibility. Method 2, with its separate design of different operating parameters for different models, forces developers to copy numerous identical configuration files for each model. This results in extremely large firmware files due to redundant configurations, necessitating either reducing the number of compatible models or increasing the cost by increasing firmware storage chip capacity. Furthermore, if a setting exists in multiple models, all configuration files must be manually modified, significantly increasing repetitive workload.

[0050] Therefore, there is an urgent need for a mechanism that can automatically identify the server model and its hardware configuration, and dynamically load adaptation strategies, initialization parameters, and functional modules accordingly, in order to achieve the goal of adapting a single BMC firmware image to multiple server models. This will not only greatly reduce the workload of building and maintaining BMC firmware, but also help improve product delivery consistency, support rapid upgrades, and reduce maintenance costs.

[0051] After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0052] refer to Figure 2This diagram illustrates a server architecture provided in an embodiment of this application. The server architecture includes multiple servers, each with a BMC integrated on its motherboard. The method of this embodiment can be applied to any BMC. Taking the first BMC as an example, this first BMC is integrated on the motherboard of the first server. Typically, a server model represents a combination of a motherboard model and a set of hardware configurations. In this example, BMC41, BMC51, and BMC61 can respectively apply the method of this embodiment to generate firmware suitable for motherboard 4, motherboard 5, and motherboard 6. The corresponding firmware is configured in the corresponding BMC to provide management services for the corresponding server.

[0053] Of course, the methods provided in the embodiments of this application are not limited to... Figure 2 The application scenarios shown can also be used in other possible scenarios, and this application does not impose any limitations. Figure 2 The functions that each device in the application scenario shown can achieve will be described in subsequent method embodiments, and will not be elaborated on here.

[0054] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application.

[0055] The following is combined with Figure 2 The application scenarios shown illustrate the technical solutions provided in the embodiments of this application.

[0056] refer to Figure 3 This application provides a method for BMC firmware, including the following steps: S301: Obtain the first identifier of the first server.

[0057] S302: Based on the first identifier and the filenames of each configuration file in the configuration file set managed by the first BMC, search in the configuration file set to determine the first configuration file that matches the first server.

[0058] S303: Build the first BMC firmware based on the first configuration file.

[0059] In this embodiment, the configuration file set managed by the first BMC includes multiple configuration files, each with a filename determined based on its function and matching rules. After obtaining the identifier of the first server, which indicates its type, the first configuration file matching the first server can be determined by searching the configuration file set based on the identifier and the filenames of the various configuration files. The first BMC firmware built using this first configuration file provides the first BMC with precise management capabilities for the first server. This design allows for flexible generation of BMC firmware suitable for various servers, facilitating BMC management, reducing the workload of maintaining BMC firmware, and improving BMC firmware compatibility.

[0060] Regarding the S301, to enable the same BMC firmware to adapt to various motherboard models and their corresponding hardware configurations, the system adopts an automatic identification method based on hardware identifiers. This method can automatically obtain the unique number of the current server (which can also be called the server identifier) ​​when the BMC powers on or restarts, and automatically load the configuration parameters of the corresponding server model based on the unique number.

[0061] First, the encoding rules for the identifier of each server will be explained.

[0062] Each server (or motherboard) is assigned a unique hexadecimal number based on an 8-bit or more (e.g., 1 byte, 2 bytes) hardware serial number at the factory. Servers within the same series or category (such as multiple models within the same product line) may use the same prefix, while different series / categories use different prefixes. This hardware number is called the server's identifier, and each identifier indicates the corresponding server type.

[0063] Figure 4 This is a schematic diagram illustrating an encoding rule provided in an embodiment of this application. See also... Figure 4 The server with motherboard A configured for air cooling is identified by ID=0X73, the server with motherboard B configured for liquid cooling is identified by ID=0X33, the server with motherboard B configured for 24 drives is identified by ID=0XF3, and the server with motherboard B configured for 40 drives is identified by ID=0XF7. In this example, for instance, the high four bits of 7 indicate air cooling configuration, and the high four bits of 3 indicate liquid cooling configuration.

[0064] In practical applications, during device power-on initialization or configuration refresh, the unique serial number of the device model is automatically read first through a call to the underlying driver interface. Depending on the actual hardware circuit design, the unique serial number can be integrated into a CPLD chip, EEPROM chip, DIP switches on the motherboard, or an embedded controller register. Reading methods include, but are not limited to, directly reading the DIP switch status via GPIO ports and combining it into a numerical serial number; using I... 2 The C / SPI bus sends communication commands to read the number from a specific memory cell.

[0065] Taking the first BMC and the first server as examples, the different reading methods will be explained below: Method 1: GPIO identification method.

[0066] In this method, an 8-bit DIP switch is reserved on the motherboard of the first server to set the code that distinguishes the motherboard model and machine configuration. Each DIP switch can be manually set to a high level (1) or a low level (0). All 8 bits are connected to the 8 GPIO input pins of the BMC chip. When the BMC system powers on or restarts, it sequentially reads the level state of each GPIO and combines the 8 levels bit by bit into an 8-bit binary value, i.e., one byte, which forms a numbering range of 0-255. Theoretically, this can support the differentiation and identification of 256 different motherboard models and machine configurations for unique identification. Through this byte value, the firmware can automatically load parameters corresponding to the motherboard model and machine configuration, achieving automatic model adaptation. Figure 5 This is a schematic diagram illustrating a DIP switch used to identify the motherboard model and machine configuration, as provided in an embodiment of this application.

[0067] The encoding methods for the unique serial number of a model include, but are not limited to, fixed-length (such as 1 byte, 2 bytes, N bytes) or variable-length hexadecimal representation, binary representation, ASCII encoding, etc.

[0068] For example, the process of obtaining the first identifier of the first server in method 1 can be implemented through steps A1-A3: A1: Reads the level status of the multiplexer pin connected to the DIP switch.

[0069] See Figure 3 The voltage levels of the multiple pins connected to the DIP switch, from high to low, are low, high, high, high, low, low, high, and high.

[0070] A2: Determine the DIP switch value indicated by the DIP switch based on the level status.

[0071] Optionally, the DIP switch value indicated by the DIP switch is determined to be 01110011 based on the above level state. For convenience, it can be represented in hexadecimal, in which case the DIP switch value is 0X73.

[0072] A3: Determine the dial code value as the first identifier of the first server.

[0073] In the example above, the first identifier is 0X73.

[0074] Method 2: CPLD or EEPROM register identification method.

[0075] In some motherboard designs, a 1-byte model identifier register can be preset and stored by a CPLD or EEPROM device on the motherboard. The BMC chip can utilize I... 2 The C bus communicates with the CPLD or EEPROM, reading a 1-byte value from a specified register address as a motherboard model and system configuration identifier. The BMC automatically applies the obtained identifier value to the local hardware configuration and management policy, enabling differentiated management for different system models. If a register read error occurs or the identifier is invalid, the system will log the error and switch to the default security configuration. Figure 6 This is a schematic diagram illustrating the identification of motherboard model and machine configuration by a CPLD register, as provided in an embodiment of this application.

[0076] In this method, the configuration storage chip pre-configures and stores the first identifier of the first server. Communication with the configuration storage chip via a configuration bus allows access to the configuration register address, retrieving the first identifier of the first server pre-stored at that address. This method utilizes I... 2 The C / SPI bus sends communication commands to read the identifier from a specific memory cell.

[0077] In this embodiment, both methods can be deployed according to different hardware platforms, and can be used in combination to balance accidental touch prevention and flexibility. Furthermore, during subsequent batch maintenance or expansion to new models, only adjustments to the DIP switches or chip parameters are needed to achieve the desired result without recompiling the BMC firmware, significantly simplifying firmware compatibility and reducing maintenance costs. In practical applications, the software module should support automatic identification and configuration of the serial number reading mode for different hardware platforms to ensure accurate acquisition of unique serial numbers.

[0078] Therefore, methods for obtaining the server's identifier include, but are not limited to, using hardware DIP switches, CPLD registers, MCU registers, EEPROM, and I... 2 The identifier is read from the C / SPI bus or obtained through a preset storage area, and various direct or indirect methods are used to synthesize the hardware status into an identifier. Any combination of the above encoding rules and reading methods can be implemented, allowing for flexible adjustment of identifier encoding and reading technologies according to product scenarios.

[0079] Regarding S202, based on the first identifier and the filenames of each configuration file in the configuration file set managed by the first BMC, the first configuration file matching the first server is determined by searching in the configuration file set.

[0080] The filename of each configuration file in the configuration file set is determined based on its function and the matching rules set. For example, the function of a configuration file might be to implement liquid cooling, and the matching rules might include a match with the server exceeding a certain threshold. The naming rules for the configuration files are explained below: Optionally, all configuration files for the motherboard / model should be named using the rule "Number Type-Number Value-Prefix Mask Length": For example, ID-0x30-4.conf, ID-0x73-8.conf. The first segment is the number type, the second segment is the hexadecimal number value, and the third segment is the decimal mask length (equivalent to matching the first N bits). For example, 4 represents matching the first 4 bits (i.e., the high 4 bits); 8 represents a completely exact match (i.e., the complete 8 bits). The meanings of the other bits are similar and will not be elaborated here. Figure 7 This is a schematic diagram of a configuration file naming rule provided in an embodiment of this application.

[0081] This application embodiment protects the automatic association method between configuration files and machine number (server identifier). For example, the file name may explicitly include keyword elements such as the unique machine number, number prefix, and mask length, or a dedicated explicit field within the file content may be used to declare the number. Additionally, a mechanism can be introduced to directly or indirectly associate configuration files with the unique hardware number through keywords, achieving the effect of automatically selecting or filtering applicable configuration files based on the number or prefix.

[0082] Optionally, the process of determining the first configuration file of the first server among multiple configuration files can be achieved through steps B1-B3: B1: Convert the first identifier to the first target identifier in the set data format.

[0083] The data format can be set to binary format. For example, if the first identifier is 0X73, then the first target identifier is 01110011.

[0084] B2: Perform masking operations on the first target identifier with at least one mask sequence in sequence to obtain at least one operation result.

[0085] In this example, the mask sequence is a binary sequence. Optionally, the maximum mask length in at least one mask sequence is determined based on a first target identifier with a defined data format. In a specific example, if the first target identifier is 8 bits of binary data, then the number of mask sequences is 9, the maximum mask length is 8, and the mask sequences are as follows: 00000000, 10000000, 11000000, 11100000, 11110000, 11111000, 11111100, 11111100, 11111110, 11111110, 11111111.

[0086] Optionally, the process of obtaining at least one calculation result can be achieved through steps B21-B22: B21: Perform masking operations on the first target identifier with at least one mask sequence in sequence to obtain at least one mask result.

[0087] The mask operation takes the logical AND operation as an example. For example, if the first target identifier is 01110011 and the mask sequence is 00000000, the corresponding mask result is 0X00.

[0088] B22: Combine each mask result with the corresponding mask length to obtain the corresponding operation result.

[0089] Following the example above, in this instance, the mask length is 0, so the corresponding calculation result after grouping is ID-0X00-0.conf.

[0090] B3: Based on at least one calculation result and the filenames of each configuration file, search in the configuration file set to determine the first configuration file that matches the first server.

[0091] The process of determining the first configuration file from the configuration file set can be implemented in the following two ways: Method 1: Matching results are overwritten sequentially.

[0092] The following example illustrates the method using two different operation results (the first operation result and the second operation result). Optionally, this method can be implemented through steps B31-B34.

[0093] B31: Based on the first operation result, in the configuration file set, determine the configuration file that matches the first target file name indicated by the first operation result as the first reference configuration file.

[0094] For example, if the first result is ID-0X00-0.conf, and the first target file it indicates is also named ID-0X00-0.conf, then the first reference configuration file can be determined.

[0095] B32: Based on the result of the second operation, in the set of configuration files, determine the configuration file that matches the second target file name indicated by the result of the second operation as the second reference configuration file.

[0096] For example, the second result of the operation is ID-0X40-2.conf, which indicates the second target file name ID-0X40-2.conf, and can determine the second reference configuration file.

[0097] B33: If the mask length used when obtaining the second operation result is greater than the mask length used when obtaining the first operation result, then clear the first reference configuration file.

[0098] For example, the mask length used when obtaining the second operation result is 2, and the mask length used when obtaining the first operation result is 0. Considering that the longer the mask length, the more detailed the matching configuration file, the first reference configuration file can be cleared and the second reference configuration file can be retained.

[0099] B34: In the reference configuration files corresponding to each calculation result, determine the reference configuration file to be retained after clearing some reference configuration files, which is the first configuration file matched by the first server.

[0100] In practical applications, for any given calculation result, it may or may not match a reference configuration file. Among the reference configuration files that can be matched, it can be determined that the reference configuration file retained after clearing some reference configuration files is the first configuration file matched by the first server.

[0101] In this embodiment, a matching algorithm is used to match the server's identifier (supporting identifiers of any length, such as 8 bits, 12 bits, 16 bits, 32 bits, N bits, etc.) with the filename of the configuration file and the length of the prefix mask (matching the first N bits / first N hexadecimal digits / first N characters of the identifier). The mask length is flexibly configurable, supporting both broad classification and precise single-type recognition; the algorithm originates from the implementation of filenames, content fields, or external indexes, and is not limited by the identifier length.

[0102] For example, Figure 8 This is a schematic diagram illustrating the entire process of matching ID=0x73, provided as an embodiment of this application. Figure 8 It can be seen that ID-0X73-8.conf is ultimately used as the configuration parameter for the current model.

[0103] See Figure 8 After obtaining the server identifier, the system automatically calculates a 0-bit to N-bit mask for the identifier, where N is the maximum bit length of the identifier. For example, if the identifier is 8 bits, the mask length will be 0 to 8 bits respectively.

[0104] Taking ID=0x73 as an example, the prefix value corresponding to the mask is generated step by step, and the corresponding configuration file is searched.

[0105] Mask 0 bits: Universal for all machine types, mask prefix is ​​0x00, file is ID-0x00-0.conf, the most general configuration applied to all machine types; Mask 2 bits: Take the high 2 bits (the high 2 bits of 0x73 are 0x40), file is ID-0x40-2.conf, the high 2 bits are subdivided to the configuration of a specific machine type; Mask 4 bits: Take the high 4 bits (the high 4 bits of 0x73 are 0x70), file is ID-0x70-4.conf; Mask 8 bits (exact match): file is ID-0x73-8.conf, the dedicated configuration for the current server model, containing all specific parameters.

[0106] In this embodiment of the application, based on the priority strategy of the configuration file, a step-by-step copying mechanism is generally adopted, with the mask length increasing gradually (equivalent to "from coarse to fine"). Finally, the functional configuration file in the application directory becomes the optimal configuration specific to the device model. In this way, the more precise mask configuration discovered later will automatically overwrite the previous coarse-grained configuration, realizing the progressive supplementation of configuration parameters and fine-grained adaptation to specific device models.

[0107] In this process, the configuration file overriding design eliminates the need for users to maintain complex independent configuration files. They only need to create high-precision exclusive configurations for some models with personalized needs, while low-precision general configurations are automatically inherited for other ordinary cases, greatly improving the convenience of maintenance and expansion.

[0108] Optionally, the overriding strategy can be defined based on any priority such as mask length, explicit priority value, file timestamp, new and old versions, loading order, etc.; in addition, multi-level overriding is allowed, for example, basic configuration combined with model-specific configuration can be cascaded to take effect; any implementation method of configuration selection and automatic overriding is covered without limitation.

[0109] Figure 9 This is a schematic diagram illustrating the final selection of configuration files for various device models, provided as an embodiment of this application. Figure 9 As can be seen, the final configuration file selected for the air-cooled motherboard A configuration is ID-0X73-8.conf, the final configuration file selected for the liquid-cooled motherboard A configuration is ID-0X30-4.conf, the final configuration file selected for the 24-drive configuration of motherboard B configuration is ID-0XC0-2.conf, and the final configuration file selected for the 40-drive configuration of motherboard B configuration is ID-0XC0-2.conf.

[0110] Method 2: Filtering among multiple matching results.

[0111] B35: For any operation result, in the set of configuration files, determine the configuration file that matches the filename indicated by the operation result as the reference configuration file.

[0112] B36: Among multiple reference configuration files, determine the first configuration file.

[0113] The difference between this method and method 1 is that it does not perform a clearing operation, but directly selects the configuration file that matches the operation result obtained by applying the mask with the maximum length from each reference configuration file as the first configuration file.

[0114] Once the system detects the existence of a matching file, it immediately copies (or links, assembles) the file to the actual effective configuration application directory and names it with the standard name of the invoked configuration function (such as Thermal.conf, Fan.conf, Power.conf, etc.) so that relevant services or daemons can load and resolve it subsequently. Specifically, this can be done by: checking file existence; copying and renaming the file to the application directory; and supporting other distribution methods such as network distribution and symbolic links. This mechanism is applicable to multiple configuration function files (thermal design, fan, power consumption, voltage, etc.), and the same model number can be generated and overwritten by multiple function configurations according to the above mask naming rules.

[0115] In this embodiment of the application, when multiple configuration files are matched, priority determination and selection can be performed based on mask length priority, file priority field, or predetermined order.

[0116] Involving S203, the first BMC firmware is built based on the first configuration file.

[0117] The first BMC firmware obtained here is used to provide the first BMC with the function of managing the first server. Optionally, the process of building the BMC firmware through configuration files can be found in relevant technologies, which will not be elaborated here.

[0118] This application embodiment employs a "hexadecimal identifier + prefix mask length" method to achieve a flexible motherboard / model category matching mechanism. Specifically, it iterates through all available configuration files and performs mask matching using the first N bits based on the filename number and prefix mask. Through flexible configuration of the mask length and prefix number, category-based identification can be achieved; that is, motherboards / models of the same major category can share a single configuration, while individual models requiring special configurations can use a longer prefix to achieve more accurate mask matching.

[0119] In order to improve the technical solution of this application, Figure 10 This document provides a complete flowchart for generating BMC firmware, as illustrated in an embodiment of this application. See also... Figure 10 This describes a complete process for automatically matching and loading the corresponding configuration file based on the device's unique identifier and mask length. The specific steps are as follows: 1. Triggering conditions: System startup or configuration refresh.

[0120] The process is triggered by system startup or an event requiring configuration refresh, entering the configuration loading logic.

[0121] 2. Read the device's unique serial number.

[0122] Call GPIO (General Purpose Input / Output) or I 2 The C (Integrated Circuit Bus) interface reads the unique serial number of the device (this serial number is used to distinguish different devices and ensure the uniqueness of the configuration).

[0123] 3. Determine the result of reading the number.

[0124] If the number reading fails, the default configuration will be loaded directly, and subsequent steps in the process will not be executed.

[0125] If the number is read successfully, proceed to the next step, "mask length" logic.

[0126] 4. Initialize the mask length (maskLen).

[0127] Initialize maskLen to 0 (maskLen represents the number of bits truncated from the high bits of the unique number, used as a prefix for generating the configuration file).

[0128] 5. Calculate the configuration file prefix.

[0129] Based on the current maskLen, extract the maskLen bits from the high-order bits of the device's unique ID to generate a configuration file prefix (e.g., if the unique ID is 12345 and maskLen=2, then the prefix is ​​12).

[0130] 6. Assembly configuration file name.

[0131] The calculated prefix is ​​used to assemble the configuration file name (e.g., prefix 12 corresponds to configuration file config_12.conf).

[0132] 7. Configuration file existence check

[0133] If the file exists, copy / overwrite the configuration file to the standard name of the application directory (ensuring the application can read the corresponding configuration), and then proceed to the system / feature loading configuration step.

[0134] If the file does not exist, proceed to the next step of maskLen range determination.

[0135] 8. Mask length range determination (whether maskLen is less than N)

[0136] N is a pre-set maximum mask length (for example, N = 5, indicating that at most 5-bit prefixes are attempted to be intercepted).

[0137] If maskLen < N, then increment maskLen by 1 (for example, changing from 0 to 1), go back to the step of calculating the configuration file prefix, and repeat the attempt to generate a new prefix and match the file.

[0138] If maskLen ≥ N, it means that all attempts of mask lengths have been completed and no matching configuration file has been found, then proceed to the next step.

[0139] 9. After all mask attempts

[0140] When no matching file is found after all attempts of maskLen (from 0 to N - 1), the process enters the system / function loading configuration step (at this time, the default configuration may be loaded, or the fallback logic for no matching configuration may be executed).

[0141] 10. System / function loading configuration

[0142] Regardless of whether a configuration file is finally matched or after all mask attempts, the system or function module loading configuration operation will ultimately be executed to complete the entire configuration process.

[0143] Figure 10 The process, by gradually increasing the mask length, intercepts prefixes of different lengths from the device unique number and attempts to match the corresponding configuration file strategy, realizes a flexible solution of preferentially matching precise configurations and secondly selecting default configurations, which not only ensures the personalization of device configurations but also avoids the risk of configuration missing through default configurations and mask length ranges.

[0144] In summary, the embodiments of this application improve the development and maintenance efficiency, minimize the problems caused by manual operations and scattered configurations to the greatest extent, and at the same time provide strong technical guarantees for product consistency, customer customization, on-site upgrade and maintenance. Specifically, it includes the following aspects: First, it greatly reduces the development and maintenance workload. By adopting the unique number + prefix mask scheme, a set of BMC firmware can run adaptively and reliably among multiple motherboards and models. Through a small number of highly reusable general configuration files and refined configurations for special models, the compatibility support for the entire product series can be achieved. Significantly reduces the development, testing, release and maintenance workload of firmware and configurations.

[0145] Second, improve configuration and functionality consistency. Multiple models share unified configuration rules and version management methods. For motherboards of the same category or series, a common configuration with the same prefix ensures consistency in hardware and functional parameters. Even when personalized settings are required, strict mask matching rules automatically distribute exclusive configurations, greatly improving parameter and functional consistency and reducing human error and on-site failures.

[0146] Third, it reduces firmware size and hardware costs. Assuming each device model has 10 functions requiring configuration files, the traditional approach would generate 2560 configuration files per model. However, with this solution, if only a few models (around 10) require individual configuration for each function, the number of configuration files will be significantly reduced to approximately 100, saving 95% of storage space.

[0147] Firmware eliminates the need to write and store configuration files separately for each model, thus greatly optimizing storage resources. More configuration items can be accommodated within the same storage space, improving system compatibility and scalability. Simultaneously, smaller capacity storage chips can be used to accommodate more configurations, further reducing hardware costs and improving resource utilization efficiency.

[0148] Fourth, it facilitates product upgrades, expansions, and rollbacks. Only a unique number and mask need to be assigned to each new motherboard or model, without affecting existing motherboards and their configurations. Batch upgrades and feature expansions require only adjustments to a few configuration files or firmware modules, eliminating the need for a complete rewrite. This easily supports the diverse and rapid evolution of multiple product series and facilitates upgrade rollbacks, improving R&D and operational efficiency.

[0149] Fifth, enhance the system's automation and intelligence. Through automatic identification, matching, and loading, the system can automatically adapt to the motherboard model and configuration after power-on or flashing, without manual intervention. This significantly reduces manpower investment in mass production and after-sales maintenance, supports remote or in-plant batch automatic deployment, and is especially suitable for unified management in high-density server scenarios such as large-scale data centers.

[0150] Sixth, enhanced flexibility and scalability. The hexadecimal encoding + mask length strategy allows the same configuration to serve multiple models, with flexible exceptions for special cases. It supports hierarchical tree-structured coverage management, easily adapting to market demands for product families and diverse versions, making the technical architecture more scalable and forward-looking.

[0151] like Figure 11 As shown, based on the same inventive concept as the above-described method for generating BMC firmware, this application also provides a device for generating BMC firmware. This device is applied to a first BMC and includes a data acquisition unit 111 and a data processing unit 112.

[0152] The data acquisition unit 111 is used to: acquire a first identifier of the first server; wherein the first identifier is used to indicate the type of the first server; The data processing unit 112 is configured to: search in the configuration file set according to the first identifier and the file names of each configuration file in the configuration file set managed by the first BMC to determine the first configuration file that matches the first server; wherein the file name of each configuration file in the configuration file set is determined according to the function of the configuration file and the set matching rules; The data processing unit 112 is further configured to: construct a first BMC firmware based on a first configuration file; wherein the first BMC firmware is used to provide the first BMC with the function of managing the first server.

[0153] In one alternative implementation, the data processing unit 112 is specifically used for: Convert the first identifier into a first target identifier with a defined data format; Perform masking operations on the first target identifier with at least one mask sequence in sequence to obtain at least one operation result; Based on at least one calculation result and the filenames of each configuration file, search in the configuration file set to determine the first configuration file that matches the first server.

[0154] In one alternative implementation, the data processing unit 112 is specifically used for: The first target identifier is sequentially subjected to masking operations with at least one mask sequence to obtain at least one mask result that corresponds one-to-one; wherein, the maximum mask length in the at least one mask sequence is determined according to the first target identifier with a set data format; Each mask result is combined with its corresponding mask length to obtain the corresponding calculation result.

[0155] In one alternative implementation, the data processing unit 112 is specifically used for: For the first calculation result, in the set of configuration files, the configuration file that matches the first target file name indicated by the first calculation result is determined as the first reference configuration file; wherein, the first calculation result is any one of at least one calculation result; Regarding the second operation result, in the set of configuration files, the configuration file that matches the second target filename indicated by the second operation result is determined as the second reference configuration file; wherein, the second operation result is one of at least one operation result that is different from the first operation result; If the mask length used when obtaining the second operation result is greater than the mask length used when obtaining the first operation result, then the first reference configuration file is cleared. Among the reference configuration files corresponding to each calculation result, the reference configuration file retained after clearing some reference configuration files is determined to be the first configuration file matched by the first server.

[0156] In one alternative implementation, the data processing unit 112 is specifically used for: For any given operation result, the configuration file that matches the filename indicated by the operation result is selected as the reference configuration file from the set of configuration files. Among multiple reference configuration files, the first configuration file is determined; wherein, the first configuration file is the configuration file that matches the operation result obtained by applying the mask of the maximum length.

[0157] In one alternative implementation, the mask sequence is a binary sequence; the data format is set to binary format.

[0158] In one optional implementation, the data acquisition unit 111 is specifically used for: Read the level status of the multiplexed pins connected to the DIP switch; The DIP switch value indicated by the DIP switch is determined based on the level status; The dial-up value is determined to be the first identifier of the first server.

[0159] In one optional implementation, the data acquisition unit 111 is specifically used for: By accessing the set register address, the first identifier of the first server, which is pre-stored at the set register address, is obtained.

[0160] In one optional implementation, the data acquisition unit 111 is specifically used for: The configuration register address is accessed by communicating with the configuration storage chip via the configuration bus; wherein, the configuration storage chip pre-configures and stores the first identifier of the first server.

[0161] The BMC firmware generation apparatus proposed in this application embodiment adopts the same inventive concept as the above-described BMC firmware generation method and can achieve the same beneficial effects, so it will not be described again here.

[0162] Based on the same inventive concept as the aforementioned BMC firmware generation method, this application also provides a baseboard management controller. For example... Figure 12 As shown, the baseboard management controller may include a processor 1201 and a memory 1202.

[0163] The processor 1201 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0164] Memory 1202, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited to this. Memory 1202 in the embodiments of this application may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0165] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned computer storage medium can be any available medium or data storage device that a computer can access, including but not limited to: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)) and other media capable of storing program code.

[0166] Alternatively, if the integrated units described above in this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes: mobile storage devices, random access memory (RAM), magnetic memory (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical memory (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor memory (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), etc.) and other media capable of storing program code.

[0167] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the BMC firmware generation methods discussed above. Since the principle by which the above computer program product solves the problem is similar to that of the BMC firmware generation method, the implementation of the above computer program product can be referred to the implementation of the method, and repeated details will not be described again.

[0168] The above embodiments are only used to provide a detailed description of the technical solutions of this application. However, the description of the above embodiments is only for the purpose of helping to understand the methods of the embodiments of this application and should not be construed as a limitation on the embodiments of this application. Any changes or substitutions that can be easily conceived by those skilled in the art should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for generating a BMC firmware, characterized by, The method is applied to a first BMC, the first BMC is integrated on a mainboard of a first server, the first BMC is any one of a plurality of BMCs, and the first server is any one of a plurality of servers; the method comprises: obtaining a first identifier of the first server; wherein the first identifier is used to indicate a type of the first server; finding, according to the first identifier and a file name of each configuration file in a configuration file set managed by the first BMC, a first configuration file matched by the first server in the configuration file set; wherein the file name of each configuration file in the configuration file set is determined according to a function of the configuration file and a set matching rule; constructing a first BMC firmware based on the first configuration file; wherein the first BMC firmware is used to provide a function of managing the first server for the first BMC.

2. The method of claim 1, wherein, The finding, according to the first identifier and the file name of each configuration file in the configuration file set managed by the first BMC, of the first configuration file matched by the first server in the configuration file set comprises: converting the first identifier into a first target identifier in a set data format; performing mask operations on the first target identifier and at least one mask sequence in sequence to obtain at least one operation result; finding, according to the at least one operation result and the file name of each configuration file, the first configuration file matched by the first server in the configuration file set.

3. The method of claim 2, wherein, The performing mask operations on the first target identifier and at least one mask sequence in sequence to obtain at least one operation result comprises: performing mask operations on the first target identifier and at least one mask sequence in sequence to obtain at least one mask result corresponding in one-to-one manner; wherein a maximum mask length in the at least one mask sequence is determined according to the first target identifier in the set data format; combining each mask result and a corresponding mask length to obtain a corresponding operation result.

4. The method of claim 2, wherein, The finding, according to the at least one operation result and the file name of each configuration file, of the first configuration file matched by the first server in the configuration file set comprises: for a first operation result, determining, in the configuration file set, a configuration file matched with a first target file name indicated by the first operation result as a first reference configuration file; wherein the first operation result is any one of the at least one operation result; for a second operation result, determining, in the configuration file set, a configuration file matched with a second target file name indicated by the second operation result as a second reference configuration file; wherein the second operation result is one of the at least one operation result different from the first operation result; if a mask length applied when the second operation result is obtained is greater than a mask length applied when the first operation result is obtained, clearing the first reference configuration file; in the reference configuration files corresponding to the operation results, determining, after a part of the reference configuration files are cleared, a reference configuration file remaining as the first configuration file matched by the first server.

5. The method of claim 2, wherein, The determining, according to the at least one operation result and the file name of each configuration file, the first configuration file matched by the first server in the configuration file set comprises: For any one operation result, determining, in the configuration file set, a configuration file matched with the file name indicated by the operation result as a reference configuration file; Determining a first configuration file from the multiple reference configuration files; wherein the first configuration file is a configuration file whose operation result is obtained by applying a mask with the maximum length.

6. The method according to any one of claims 2 to 5, characterized in that, The mask sequence is a binary sequence; and the set data format is a binary format.

7. The method according to any one of claims 1 to 5, characterized in that, The obtaining of the first identifier of the first server comprises: reading the level state of the multiple pins connected with the dial switch; determining the dial value indicated by the dial switch according to the level state; determining the dial value as the first identifier of the first server.

8. The method according to any one of claims 1 to 5, characterized in that, The obtaining of the first identifier of the first server comprises: obtaining the first identifier of the first server pre-stored in the set register address by accessing the set register address.

9. The method of claim 8, wherein, The accessing of the set register address comprises: accessing the set register address by setting the bus to communicate with a set storage chip; wherein the set storage chip pre-sets and stores the first identifier of the first server.

10. An apparatus for generating a BMC firmware, the apparatus comprising: The apparatus is applied to a first BMC, the first BMC is integrated on a mainboard of a first server, the first BMC is any one of multiple BMCs, and the first server is any one of multiple servers; the apparatus comprises: a data acquisition unit configured to acquire a first identifier of a first server; wherein the first identifier is used to indicate the type of the first server; a data processing unit configured to search, according to the first identifier and the file name of each configuration file in a configuration file set managed by the first BMC, the configuration file set to determine a first configuration file matched by the first server; wherein the file name of each configuration file in the configuration file set is determined according to the function of the configuration file and a set matching rule; the data processing unit is further configured to construct a first BMC firmware based on the first configuration file; wherein the first BMC firmware is used to provide the first BMC with a function of managing the first server.

11. A baseboard management controller comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 9.

12. A computer-readable storage medium having stored thereon computer program instructions, wherein, The computer program instructions are executed by the processor to implement the steps of the method in any one of claims 1 to 9.

Images