Method and apparatus for updating baseboard management controller firmware

Abstract

The application provides an updating method and device for a substrate management controller firmware, which can be applied to the technical field of server management. The updating method comprises the following steps: obtaining a firmware image file of a substrate management controller; identifying a plurality of module feature data in the firmware image file; according to a type identifier field and a length field in the plurality of module feature data, segmenting a plurality of module firmware data from a plurality of data blocks of the firmware image file; in response to a selection operation on the plurality of module firmware data, determining at least one target module firmware data from the plurality of module firmware data; and performing an updating operation on firmware corresponding to the at least one target module firmware data through an updating interface corresponding to the at least one target module firmware data.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of server management, and particularly relates to a method and device for updating firmware of a baseboard management controller. BACKGROUND

[0002] The existing update method for firmware of a baseboard management controller is centralized. When facing local function repair or enhancement, the existing update method still needs to replace the firmware as a whole. The update method of replacing the firmware as a whole not only has high update risk and long time consumption, but also often causes service interruption due to restart, thereby affecting the stability and availability of the system. Therefore, a new modular update scheme is urgently needed. SUMMARY

[0003] In view of the above problems, the present application provides a method and device for updating firmware of a baseboard management controller, for improving the efficiency and security of updating firmware of a baseboard management controller.

[0004] According to a first aspect of the present application, a method for updating firmware of a baseboard management controller is provided, comprising: obtaining a firmware image file of the baseboard management controller, the firmware image file comprising a plurality of data blocks, the plurality of data blocks comprising a plurality of module characteristic data and a plurality of module firmware data, the module characteristic data comprising a type identification field and a length field, the type identification field being used for identifying a category of a management function implemented by the module firmware data, and the length field being used for indicating a data length of the data block; identifying the plurality of module characteristic data in the firmware image file; segmenting the plurality of module firmware data from the plurality of data blocks of the firmware image file according to the type identification field and the length field in the plurality of module characteristic data; determining at least one target module firmware data from the plurality of module firmware data in response to a selection operation on the plurality of module firmware data; and performing an update operation on firmware corresponding to the at least one target module firmware data through an update interface corresponding to the at least one target module firmware data.

[0005] The second aspect of the present application provides an updating device for a substrate management controller firmware, comprising: an acquisition module configured to acquire a firmware image file of a substrate management controller, the firmware image file comprising a plurality of data blocks, the plurality of data blocks comprising a plurality of module characteristic data and a plurality of module firmware data, the module characteristic data comprising a type identification field and a length field, the type identification field being configured to identify a category of a management function implemented by the module firmware data, and the length field being configured to indicate a data length of the data block to which the module characteristic data belongs; an identification module configured to identify the plurality of module characteristic data in the firmware image file; a segmentation module configured to segment the plurality of module firmware data from the plurality of data blocks of the firmware image file according to the type identification field and the length field in the plurality of module characteristic data; a target determination module configured to determine at least one target module firmware data from the plurality of module firmware data in response to a selection operation on the plurality of module firmware data; and an updating module configured to perform an updating operation on firmware corresponding to the at least one target module firmware data through an updating interface corresponding to the at least one target module firmware data.

[0006] The third aspect of the present application provides an electronic device, comprising a memory configured to store a firmware image file of a substrate management controller, the firmware image file comprising a plurality of data blocks, the plurality of data blocks comprising a plurality of module characteristic data and a plurality of module firmware data, the module characteristic data comprising a type identification field and a length field, the type identification field being configured to identify a category of a management function implemented by the module firmware data, and the length field being configured to indicate a data length of the data block to which the module characteristic data belongs; a processor communicatively connected with the memory and configured to: identify the plurality of module characteristic data in the firmware image file; segment the plurality of module firmware data from the plurality of data blocks of the firmware image file according to the type identification field and the length field in the plurality of module characteristic data; determine at least one target module firmware data from the plurality of module firmware data in response to a selection operation on the plurality of module firmware data; and provide the at least one target module firmware data to the substrate management controller; and the substrate management controller communicatively connected with the processor and configured to: receive the at least one target module firmware data from the processor through an updating interface; and perform an updating operation on firmware corresponding to the at least one target module firmware data according to the received at least one target module firmware data.

[0007] The fourth aspect of the present application further provides a computer readable storage medium having a computer program or instructions stored thereon, the computer program or instructions being executed by a processor to implement the steps of the above method.

[0008] In the embodiments of the present application, a complete firmware image file of a baseboard management controller is acquired, and the file is processed by using a preset module feature data format, so that a plurality of independently updatable function modules are automatically segmented and determined from the file. One or more target module firmware data are determined in response to a selection operation of a user on the independent modules. According to the selection result, independent and on-demand update operations are performed on the firmware through a special update interface corresponding to each target module. The present application breaks through the limitation of the existing centralized update, realizes on-demand and flexible modular update, ensures stable operation of a server system, greatly reduces update risk and resource consumption, and improves operation and maintenance efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0009] The above and other objects, features and advantages of the present application will become more apparent from the following description of the embodiments of the present application taken with reference to the accompanying drawings, in which:

[0010] Figure 1 A scenario diagram of application of an update method and device for firmware of a baseboard management controller according to an embodiment of the present application is schematically shown;

[0011] Figure 2 A flowchart of the update method for firmware of a baseboard management controller according to an embodiment of the present application is schematically shown;

[0012] Figure 3 An internal data diagram of a firmware image file according to an embodiment of the present application is schematically shown;

[0013] Figure 4 A flowchart of determination of module firmware data according to an embodiment of the present application is schematically shown;

[0014] Figure 5 A flowchart of determination of a starting position according to an embodiment of the present application is schematically shown;

[0015] Figure 6 A flowchart of firmware update of a baseboard management controller according to an embodiment of the present application is schematically shown;

[0016] Figure 7 A structural block diagram of an update device for firmware of a baseboard management controller according to an embodiment of the present application is schematically shown;

[0017] Figure 8 A block diagram of an electronic device suitable for implementing the update method for firmware of a baseboard management controller according to an embodiment of the present application is schematically shown. DETAILED DESCRIPTION

[0018] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. It is to be understood, however, the descriptions are merely examples, and are not intended to limit the scope of the present application. In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present application. However, it would be apparent to those skilled in the art that the present application can be practiced without these specific details. In other instances, well-known structures and functions have not been described in detail in order to avoid obscuring the concepts of the application.

[0019] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used herein, the term "includes" and tautological expressions thereof, such as "including," "includes," "include," "contains," "containing," and so forth, mean the term "comprises," as long as the above-mentioned terms do not exclude other features, steps, operations, elements, and / or components.

[0020] All terms used herein, including technical and scientific terms, have the same meanings as those generally understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having meanings consistent with the context of the present specification, and should not be interpreted in an idealized or overly formal manner.

[0021] In the case of using expressions similar to "at least one of A, B, and C, etc.", it should be generally interpreted as including any one of A, B, and C, etc., in the meaning as understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but not be limited to a system having A alone, a system having B alone, a system having C alone, a system having both A and B, a system having both A and C, a system having both B and C, and / or a system having A, B, and C together, etc.).

[0022] Embodiments of the present application provide a method and apparatus for updating firmware of a baseboard management controller.

[0023] Figure 1 An application scenario diagram of a method and apparatus for updating firmware of a baseboard management controller according to embodiments of the present application is schematically shown.

[0024] As Figure 1 shown, the application scenario 100 mainly consists of a firmware update management apparatus 104, a baseboard management controller 102, and firmware 101 running thereon. The firmware update management apparatus 104 is connected to the baseboard management controller 102 through a network 103 to maintain the firmware 101 thereof.

[0025] The baseboard management controller 102 is a physical hardware controller of the server, and the firmware 101 is underlying software executed on the baseboard management controller 102 and is an actual carrier for implementing all remote monitoring, diagnosis and management functions, and the reliability thereof is crucial to the stability of the server. The firmware update management device 104 plays the role of an intelligent update executor and is responsible for executing the firmware update method. In the running process, the firmware update management device 104 first acquires a new firmware image file for updating, and the new firmware image file contains a plurality of structured data blocks.

[0026] The firmware update management device 104 is configured to identify the module feature data in the file and automatically segment a plurality of independently operable module firmware data according to the module feature data. The firmware update management device 104 determines one or more target module firmware data in response to a selection of an administrator. The firmware update management device 104 performs on-demand and modularized update operations on the currently running firmware 101 on the baseboard management controller 102 through an update interface corresponding to the target module, so as to improve the flexibility, stability and maintainability of the firmware 101 without interrupting the overall service.

[0027] The following will be based on Figure 1 The scenario described, through Figures 2-6 The update method for the firmware of the baseboard management controller is described in detail.

[0028] Figure 2 A flowchart of the update method for the firmware of the baseboard management controller according to the embodiments of the present application is schematically shown.

[0029] As Figure 2 shown, the update method for the firmware of the baseboard management controller of the embodiments includes operations S210-S250.

[0030] In operation S210, a firmware image file of a baseboard management controller is acquired.

[0031] In the embodiments of the present application, the firmware image file includes a plurality of data blocks, the plurality of data blocks include a plurality of module feature data and a plurality of module firmware data, the module feature data includes a type identifier field and a length field, the type identifier field is used to identify the category of the management function implemented by the module firmware data, and the length field is used to indicate the data length of the data block.

[0032] It should be noted that the firmware image file is not an existing single executable file that cannot be segmented, but a specially designed composite file. The server or hardware manufacturer has already performed structured processing according to the modularization idea in the compilation and construction stage. This file can usually be obtained from the official support website of the manufacturer to ensure the reliability, integrity and compatibility with the hardware of the source thereof.

[0033] In operation S220, a plurality of module feature data in the firmware image file are identified.

[0034] In the embodiment of the present application, the firmware image file can be scanned in full according to a preset module feature header format standard, so as to identify all data blocks conforming to the preset format standard as module feature data. For example, the module feature header can contain fixed start identifier, module type code, version number, data length and check code fields, and each functional module feature data can be accurately located by matching the field format.

[0035] In operation S230, a plurality of module firmware data are segmented from a plurality of data blocks of the firmware image file according to type identification fields and length fields in the plurality of module feature data.

[0036] In the embodiment of the present application, after the module feature data are identified, the data of corresponding length is intercepted from the position where the module feature data is located according to the length field of the module feature data, so as to obtain the complete and independently updatable functional module firmware data. Meanwhile, the segmented module firmware data can be classified according to the type identification field, such as power management module, fan control module or temperature monitoring module, etc., so as to provide basis for subsequent selective update.

[0037] In operation S240, at least one target module firmware data is determined from the plurality of module firmware data in response to a selection operation on the plurality of module firmware data.

[0038] In the embodiment of the present application, all the segmented functional modules are presented in a list form on the management interface for the administrator to select. One or more modules to be updated can be determined according to actual needs, such as firmware update needs of specific hardware or for solving specific problems. After receiving the selection operation, the selected functional module is determined as the target module firmware data for this update.

[0039] In operation S250, a firmware corresponding to the at least one target module firmware data is updated through an update interface corresponding to the at least one target module firmware data.

[0040] In the embodiment of the present application, the target module firmware data refers to the new firmware package segmented from the complete image and selected for this update. The update interface is a network channel reserved on the baseboard management controller for receiving the firmware package. The firmware refers to the underlying software running on the current hardware module and to be replaced by the new firmware package.

[0041] In the embodiments of the present application, by obtaining a structured composite firmware image, independent functional module firmware is automatically identified and segmented. Accordingly, a single or multiple target modules are flexibly selected, and precise updating is performed through a special interface. Modular incremental updating of the baseboard management controller is achieved, effectively avoiding system redundancy and risks caused by full updating, and significantly improving the efficiency and reliability of firmware maintenance.

[0042] The following describes in detail the updating of the baseboard management controller firmware including operations S210-S250.

[0043] In the embodiments of the present application, the firmware image file in operation 210 is composed of a composite file structure. The firmware image file can be regarded as a container, and the container contains a plurality of independent functional module data blocks. Each functional module data block represents a specific function of the baseboard management controller, such as a power management module, a fan and temperature monitoring module, a storage monitoring module, a network interface management module, and the like.

[0044] It should be noted that each data block is composed of two parts: module characteristic data and module firmware data. The module characteristic data represents the metadata before the module firmware data, which is equivalent to the name card or file header of each module. A unified, predefined format standard is followed to enable the updating system to accurately scan and parse.

[0045] Figure 3 An internal data schematic diagram of the firmware image file according to the embodiments of the present application is schematically shown.

[0046] As shown in Figure 3 The firmware image file includes a plurality of interval identifiers 301, module characteristic data 302, and module firmware data 303. The module characteristic data 302 includes a plurality of key fields, such as a type identifier field for identifying the specific management function category implemented by the module firmware data, for example, 0x0001 representing a power module and 0x0002 representing a temperature control module. This enables the system to understand the purpose of each module firmware data and clearly display it on the user interface.

[0047] For example, the length field is a numerical value for indicating the total byte length of the current data block including the module characteristic data itself and the module firmware data, which is calculated from the characteristic header identifier. The version field records the version number of the current module firmware data. The version field is compared with the installed module version on the baseboard management controller to determine whether updating is needed. The check code field represents a check value calculated based on the module data, for example, a check value calculated from all characteristic data except the check code itself. After the module is segmented, the check sum can be recalculated and compared with the value of this field to verify the integrity of the module data.

[0048] The module firmware data 303 is the actual business logic carrier following the module feature data. It contains all executable codes, configuration files, parameters and resource data required to implement a specific function. This part is written into the corresponding flash memory of the baseboard management controller.

[0049] It should be noted that, in order to further enhance the readability of the file structure and the robustness of the parsing, a spacing identifier 301 is also included between two adjacent complete module data blocks. The spacing identifier 301 is used to clearly distinguish the end of a module and the beginning of the next module during parsing, preventing parsing confusion due to length field errors and other abnormal situations.

[0050] In the embodiments of the present application, the complete firmware image is divided into a plurality of sequentially arranged data blocks, each data block being composed of module feature data and module firmware data. The module feature data, as metadata, contains standardized fields such as type identifier, length, version and check code, for module identification, version comparison and integrity check; the module firmware data is the functional code entity. Through the preset feature header and optional spacing identifier, the system can automatically parse, check and segment independent functional modules, supporting on-demand, secure and reliable precise updating.

[0051] In the embodiments of the present application, the above operation 220 can further include identifying any preset spacing identifier in the firmware image file, and determining the data segment immediately following any preset spacing identifier as module feature data, the module feature data being a data segment of a preset fixed length.

[0052] In the embodiments of the present application, the firmware image file further includes a plurality of preset spacing identifiers, the preset spacing identifier being a specific byte sequence in the firmware binary content that is non-functional between different module data blocks. As a clear and robust logical delimiter between different module data blocks, even in the case of an error in the length field of a module, the parsing program can still re-synchronize by scanning this spacing identifier, thereby skipping the damaged module and continuing to parse the subsequent correct module, improving the fault tolerance and robustness of the entire parsing process.

[0053] For example, the preset spacing identifier is a fixed 4-byte data. The identification operation specifically includes scanning and locating the identifier, and further verifying whether the data segment immediately following the identifier starts with another preset module feature header identifier. Only after the double verification passes, a data segment of a preset fixed length, for example, 14 bytes, following the starting point of the feature header identifier is confirmed as valid module feature data.

[0054] It should be noted that the header area of the firmware image file can also include a metadata block recording the total number of preset interval identifiers contained in the image file. The parsing program can read this number as an expected value before starting the scanning. After the scanning is completed, if the number of interval identifiers found does not match the expected value, the system can immediately determine that the firmware image file is structurally damaged or incomplete, thereby aborting the update process in advance to avoid potential risks to the device.

[0055] In the embodiments of the present application, a preset interval identifier is introduced in the modular baseboard management controller firmware architecture as a robust delimiter between modules. The module feature data is accurately located by scanning the identifier and cooperating with a double verification mechanism. The firmware image header also has a metadata block recording the total number of interval identifiers, which is used for quantity expectation verification before scanning, and a complete parsing fault-tolerant mechanism from positioning, verification to integrity checking is constructed.

[0056] In the embodiments of the present application, the operation 220 can further include, for any module feature data identified, reading a check field in the module feature data; calculating a check value according to the same algorithm as that for generating the check field, from the binary content of the module feature data excluding the check field; comparing the check value with the original check value read from the check field to obtain a comparison result; and aborting the update operation for the module firmware data in a case where the comparison result represents that the check value and the original check value are inconsistent.

[0057] For example, the check field is a fixed 2-byte check code at the end of the module feature data. The calculation and comparison process is specifically: after identifying a 14-byte module feature data, first isolate the first 12 bytes (including 4-byte feature header identifier, 2-byte module type code, 2-byte version field and 4-byte length field), and execute a preset algorithm on the binary content of the 12 bytes to generate a real-time calculated 16-bit check value. The 16-bit check value is compared with the original check value stored in the 13th and 14th bytes of the module feature data. If the check value and the original check value are inconsistent, it is determined that the module feature data has been damaged in the transmission or storage process, and the entire firmware update process will be immediately aborted, and an abnormal log containing the module type and error location is recorded to prevent dangerous operations based on error data, ensuring the safety and reliability of the update process.

[0058] It should be noted that the check field can be a cyclic redundancy check algorithm. When the update operation is aborted, not only the process is stopped, but also a detailed error log is generated. The error log can also explicitly record the offset position of the module feature data that fails the check, the function module represented by the type identification field, and the calculated check value and the original check value read from the field. The error log can be used to locate firmware build errors or diagnose data corruption problems during file transfer by developers.

[0059] In the embodiments of the present application, a check field is set in the module feature data. By calculating the data content except the check field in real time and comparing it with the stored original check value, the integrity of the metadata is verified. This check mechanism can accurately locate the damage of the data during transmission or storage. Once inconsistency is found, the update is immediately aborted and a detailed error log is generated. This effectively prevents dangerous operations based on erroneous metadata, significantly improving the security and reliability of the firmware update process.

[0060] The process of determining the module firmware data corresponding to the management function category is described below.

[0061] Figure 4 A flowchart for determining module firmware data according to an embodiment of the present application is schematically shown.

[0062] As shown in Figure 4 The operation S230 can further include operations S401-S404.

[0063] In operation S401, the management function category identified by the type identification field in any module feature data is determined as the management function category of the corresponding module firmware data.

[0064] For example, the firmware image file includes a plurality of preset interval identifiers. After a piece of module feature data is parsed, the type identification field is read. The type identification field is located at the 5th and 6th bytes of the feature header. In this example, the value read is 0x0001 in hexadecimal. The system internally maintains a preset mapping table that associates 0x0001 with the string "power management module". Therefore, the function category of the firmware data subsequent to this piece of feature data is determined as "power management module", so as to be explicitly displayed on the user interface and to provide a basis for subsequent dependency checks.

[0065] In operation S402, the starting position of any module feature data is determined according to the preset interval identifier.

[0066] In the embodiments of the present application, after the module feature data is parsed, the type identification field used to define the module function in the module feature data is extracted. The type identification field is a preset digital code. The digital code is used as an index to query the module function mapping table. The module function mapping table corresponds different digital codes to specific function names, such as power management and temperature control management. The management function category of the module firmware data is accurately determined through the query, for subsequent logical processing and interface presentation.

[0067] In operation S403, the continuous data segment is intercepted according to the starting position of any module feature data as a reference, and the data length is indicated by the length field of any module feature data.

[0068] In the embodiments of the present application, when the system completes the parsing of a module, it starts a pattern matching process in the remaining data stream of the firmware image to search for a preset interval identifier as the boundary between modules. The preset interval identifier can be a unique, non-functional byte sequence. When the byte sequence is successfully located, the first byte immediately after the end position of the byte sequence is marked as the starting position of the module feature data of the next new module, thereby preparing for parsing the next module.

[0069] In operation S404, the module feature data is removed from the intercepted data segment to obtain the module firmware data corresponding to the determined management function category.

[0070] For example, the firmware image is scanned to locate the preset interval identifier, thereby determining the starting position of the module feature data immediately after it. The type identification field, such as 0x0001, is read from the module feature data to determine that it is a power management module, and the length field, such as 0x000012A0, i.e. 4768 bytes, is read. According to the length field, a data block containing 4768 bytes is intercepted. By removing the fixed 14-byte module feature data from the data block, 4754-byte module firmware data corresponding to the power management module is obtained.

[0071] In the embodiments of the present application, by parsing the module feature data in the firmware image, the module function category is automatically identified according to the type identification field, and the corresponding module firmware data is accurately segmented according to the length field. The automatic identification and extraction of the function module are realized, which lays a foundation for subsequent on-demand update, interface display and dependency analysis, and significantly improves the automation degree and operation precision of firmware management.

[0072] Figure 5 The flowchart for determining the starting position according to the embodiments of the present application is schematically shown.

[0073] As Figure 5As shown, the operation S402 can further include operation S501 to operation S502.

[0074] In operation S501, an offset of an end position of the preset interval identifier to be located relative to a reference position is calculated based on the reference position being the start position of the firmware image file.

[0075] In the embodiment of the present application, the preset index table is preset in the header of the firmware image file, and the preset index table stores accurate offset addresses of all preset interval identifiers in the firmware image file. Based on the preset index table, a time-consuming scanning of the entire file is not needed, and the index table can be directly queried to obtain the byte offset of the end position of the target interval identifier relative to the beginning of the file. The index-based direct positioning manner improves the efficiency and speed of firmware analysis.

[0076] In operation S502, a next logical byte position corresponding to the sum of the reference position and the offset is determined as the start position of the module characteristic data next to the preset interval identifier.

[0077] In the embodiment of the present application, the start memory address of the firmware image file is arithmetically added to the offset obtained from the index table in the previous step. The calculation result points to the last byte of the target interval identifier in the file, and the first byte next to the last byte is the logical starting point of the module characteristic data of the next module.

[0078] For example, it is assumed that the firmware image file is loaded, and its start position (reference position) is 0x0000. The system first analyzes the index table in the file header, and the table records the positions of all module interval identifiers. The system queries from the table to obtain the end position of the first preset interval identifier, and the offset of the end position relative to the reference position is 0x0FFFF. Then, the system adds the reference position 0x0000 and the calculated offset 0x0FFFF to obtain the absolute address 0x0FFFF. The system determines that the next logical byte position of the address, i.e., 0x10000, is the exact start position of the module characteristic data of the next module next to the interval identifier. The analysis program starts reading and analyzing the new module characteristic data from the accurate address 0x10000.

[0079] In the embodiment of the present application, the module interval identifier is located by presetting the index table, and the accurate start position of the module characteristic data is quickly calculated by using the reference address and the offset. The analysis efficiency is improved from linear search to direct positioning, and the analysis speed of the firmware module is greatly accelerated, thereby providing performance guarantee for large-scale firmware upgrade.

[0080] The process of determining the target module firmware data is described below.

[0081] In the embodiments of the present application, the operation 240 can further include controlling the client to display the function description and version information corresponding to the plurality of module firmware data; and in the case that the selection instruction for at least one module firmware data is received from the client, the module firmware data pointed by the selection instruction is determined as the target module firmware data.

[0082] In the embodiments of the present application, the parsed module function and version information are sent to the client interface for display. When the user checks a specific module on the interface and submits, the client generates a selection instruction containing the unique identifier of the module and returns it to the system. After receiving the instruction, the system determines the corresponding module firmware data from the segmented plurality of module data according to the identifier, and locks it as the target module firmware data to be updated.

[0083] For example, the administrator sees the list of power module v1.2 and fan module v2.0 on the web interface. When the power module v1.2 in the list is determined and clicked to update, an update request is sent. After parsing the update request, the 4754-byte power module firmware data at 0x0001 in the memory is located and confirmed as the target module firmware data.

[0084] In the embodiments of the present application, the parsed module function and version information are displayed through the client interface, and the user interaction instruction is received and the corresponding target firmware data is accurately located. The on-demand selection and accurate control of modular update are realized, which effectively avoids the resource waste and system risk caused by the whole update, and significantly improves the flexibility and operation efficiency of firmware management.

[0085] In the embodiments of the present application, the operation 250 can further include encapsulating the target module firmware data and the update instruction into an update task package. Through the preset remote update interface, the update task package is sent to the logical processing unit corresponding to the target module in the baseboard management controller. The logical processing unit receives and parses the update task package, performs the write and replace operation of the firmware, thereby completing the independent update of the single module.

[0086] In the embodiments of the present application, the operation 250 can further include backing up the current running firmware data corresponding to the function of the target module firmware data; in the case that the update operation through the update interface fails, a rollback operation is triggered, and the rollback operation is used to instruct the baseboard management controller to reload the backed-up firmware data.

[0087] In the embodiments of the present application, before performing the update, the firmware currently running in the target module is completely copied to a reserved non-volatile storage partition. If any preset failure condition occurs during the update process, such as a write verification failure or a module startup timeout, the update is automatically aborted and an atomic operation is triggered to write back the data of the backup partition to the working partition, so that the module is safely restored to the state before the update.

[0088] For example, when updating a power module, the current firmware data of the power module is first backed up to a reserved area of the non-volatile storage. After writing the new firmware data, if the verification code does not match the expected value, resulting in an update failure, a rollback mechanism is immediately triggered. The contents of the partition are copied back to the working area of the power module, and the administrator is reported of the update failure and the automatic recovery.

[0089] In the embodiments of the present application, through the pre-update firmware backup and the automatic rollback mechanism, the module can be immediately restored to a normal working state when an update failure is detected. This safeguard measure effectively prevents system failures caused by firmware upgrade failures, significantly improving the reliability of the firmware update process and the safety of device operation.

[0090] In the embodiments of the present application, when the update operation starts, the update start time of the update operation is recorded; the firmware update result corresponding to the firmware data of at least one target module is monitored; in the case that the firmware update result represents that the update operation ends, the update end time is recorded; and according to the firmware update result, the update start time and the update end time, an update report is generated, the update report including the identification, the update state and the update time consumption of the firmware data of at least one target module.

[0091] In the embodiments of the present application, when the update task is started, the current timestamp is captured and recorded. The update state of the module is continuously monitored through polling or a callback mechanism. When the state becomes successful or failed, the timestamp is recorded again, and the structured log record is generated as the update report in combination with the module identification, the final state and the difference between the two timestamps.

[0092] For example, when updating a fan module, the log record is “20**-*0-**07:00:00- fan module (0x0002) update starts”. After the update is completed, a successful code is returned, and the log record is “20**-*0-**07:00:15- update ends”. Finally, the report is generated: “module 0x0002 update is successful, and the time consumption is 15 seconds”.

[0093] In the embodiments of the present application, by recording the start and end times of the firmware update and automatically calculating the time consumption, the structured upgrade report is generated in combination with the module identification and the state information. The precise monitoring and quantitative evaluation of the upgrade process are realized, complete audit basis is provided for system maintenance, and the traceability and operation and maintenance efficiency of firmware management are significantly improved.

[0094] In the embodiments of the present application, the operation 250 can further include identifying a version identification field in the module feature data, determining version information of the target module firmware data from the version identification field, performing compatibility verification on the version information of the target module firmware data and version information of the target module firmware data currently running in the baseboard management controller, and performing the subsequent update operation when the compatibility verification passes.

[0095] In the embodiments of the present application, the target firmware version is obtained by parsing the version identification field in the module feature data, and compared with the module version currently running in the device. When the same version is detected, the upgrade process is automatically terminated and the user is prompted that there is no need to update; when different versions are found, the preset compatibility rule library is further queried to verify the compatibility relationship between the new and old versions, and only when the version compatibility is confirmed, the subsequent update operation is allowed to be performed.

[0096] For example, when a power module firmware with a version number of "v1.2" is attempted to be installed, it is detected that the version of the power module installed on the device is also "v1.2". At this time, the interface is prompted that "the target version is the same as the current version, and there is no need to update", and the update button is disabled, thereby avoiding unnecessary operation and resource waste.

[0097] In the embodiments of the present application, through version identification comparison and compatibility rule verification, version duplication and compatibility risk are automatically identified before upgrading. This mechanism can effectively avoid the problems of repeated upgrading and version conflict, ensure the necessity and safety of the update operation, and significantly improve the intelligent level of firmware management and system stability.

[0098] In the embodiments of the present application, according to the type identification field of the at least one target module firmware data, a preset module dependency table is queried to determine other modules dependent on the at least one target module firmware data; in the case that there are other modules, the identification information of the other modules is associated with the identification information of the at least one target module firmware data, and prompt information representing common update is generated.

[0099] In the embodiments of the present application, according to the type identification of the selected target module, a preset dependency table is queried. The table defines the functional dependency and version compatibility requirements between modules. If it is found that the update of the target module will affect other modules, the system will analyze these dependency relationships and generate an explicit prompt information to be presented to the user for decision before performing the update.

[0100] For example, a user chooses to update the "network module" to v3.0. The system queries the dependency table and finds that this version requires a "firmware encryption module" version no lower than v2.5. If it is detected that the current encryption module version is v2.1, the system will pop up a prompt: "Warning: network module v3.0 requires encryption module v2.5 or higher. Please update the encryption module first."

[0101] It should be noted that each independent functional module is equipped with a dedicated remote update interface that supports network protocols such as the Hypertext Transfer Protocol and the Simple File Transfer Protocol. After determining the target module firmware data, the update management system calls the corresponding update interface and sends the new module firmware data package to the target module. After receiving the data, the target module first backs up the current firmware and executes the update program to write the new firmware. During the entire update process, progress information is fed back to the management system in real time, and the system is restarted after the update is completed, thereby completing the firmware update of a single or partial module without affecting the overall operation of the baseboard management controller system.

[0102] The following describes the process of updating the firmware of a baseboard management controller in conjunction with Figure 6 and specific embodiments.

[0103] Figure 6 A flowchart of the process of updating the firmware of a baseboard management controller according to an embodiment of the present application is schematically shown.

[0104] In an embodiment of the present application, as shown in Figure 6 , a complete baseboard management controller firmware image file is obtained and uploaded. The firmware image file contains a plurality of data blocks composed of a plurality of module characteristic data and module firmware data.

[0105] The firmware image file is scanned in its entirety to identify the plurality of module characteristic data in the file. According to the type identifier field, the length field, and the preset interval identifier between modules in these module characteristic data, the system can accurately segment the plurality of independent module firmware data from the data blocks. After segmentation, the control client displays the functional descriptions and version information of these modules. The user can respond to this display to perform a selection operation to determine at least one target module firmware data, supporting the selection of a single or batch of modules. After determining the target, the system also backs up the currently running firmware data before performing the update operation.

[0106] The update package is checked through an update interface corresponding to the target module. If the checking is successful, the firmware update operation is formally executed, and the updating process is monitored in real time. If the updating is successful, the system records the updated version and generates an update report. If any link in the process, such as checking or updating execution, fails, a rollback operation is triggered, indicating that the baseboard management controller reloads the backup firmware data, finally terminates the update and records the log, thereby ending the process.

[0107] Based on the above method for updating the firmware of the baseboard management controller, the application further provides an updating device for the firmware of the baseboard management controller. The following will be described in detail in combination with Figure 7 the device.

[0108] Figure 7 The structure block diagram of the updating device for the firmware of the baseboard management controller according to the embodiment of the application is schematically shown.

[0109] As Figure 7 shown, the updating device 700 for the firmware of the baseboard management controller of the embodiment includes an acquisition module 710, an identification module 720, a segmentation module 730, a target determination module 740, and an updating module 750.

[0110] The acquisition module 710 is configured to acquire the firmware image file of the baseboard management controller, the firmware image file including a plurality of data blocks, the plurality of data blocks including a plurality of module characteristic data and a plurality of module firmware data, the module characteristic data including a type identification field and a length field, the type identification field being configured to identify the category of the management function implemented by the module firmware data, and the length field being configured to indicate the data length of the data block. In an embodiment, the acquisition module 710 can be configured to perform the operation S210 described above, and details are not described herein again.

[0111] The identification module 720 is configured to identify the plurality of module characteristic data in the firmware image file. In an embodiment, the identification module 720 can be configured to perform the operation S220 described above, and details are not described herein again.

[0112] The segmentation module 730 is configured to segment the plurality of module firmware data from the plurality of data blocks of the firmware image file according to the type identification field and the length field in the plurality of module characteristic data. In an embodiment, the segmentation module 730 can be configured to perform the operation S230 described above, and details are not described herein again.

[0113] The target determination module 740 is configured to determine at least one target module firmware data from the plurality of module firmware data in response to a selection operation on the plurality of module firmware data. In an embodiment, the target determination module 740 can be configured to perform the operation S240 described above, and details are not described herein again.

[0114] The updating module 750 is configured to perform an updating operation on the firmware corresponding to the at least one target module firmware data through an updating interface corresponding to the at least one target module firmware data. In an embodiment, the updating module 750 can be configured to perform the operation S250 described above, and thus details are not repeated here.

[0115] According to embodiments of the present application, any of the modules of the obtaining module 710, the identifying module 720, the dividing module 730, the target determining module 740 and the updating module 750 can be combined in one module, or any of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of the modules can be combined with at least part of the functions of other modules, and implemented in one module. According to embodiments of the present application, at least one of the obtaining module 710, the identifying module 720, the dividing module 730, the target determining module 740 and the updating module 750 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on board, a system on package, an application specific integrated circuit (ASIC), or any other reasonable manner of integrating or packaging a circuit, etc. or implemented by hardware or firmware, or implemented in any one of software, hardware and firmware or in a proper combination of any of them. Alternatively, at least one of the obtaining module 710, the identifying module 720, the dividing module 730, the target determining module 740 and the updating module 750 can be at least partially implemented as a computer program module which can perform corresponding functions when the computer program module is run.

[0116] Figure 8 A block diagram of an electronic device suitable for implementing the method for updating firmware of a baseboard management controller according to embodiments of the present application is schematically shown.

[0117] As shown in Figure 8 The electronic device 800 according to embodiments of the present application includes a processor 801 which can perform various appropriate actions and processes according to programs stored in a read only memory (ROM) 802 or loaded from a storage portion 808 into a random access memory (RAM) 803. The processor 801 can include, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special purpose microprocessor (e.g., an application specific integrated circuit (ASIC)), etc. The processor 801 can also include an on-board memory for cache use. The processor 801 can include a single processing unit or multiple processing units for performing different actions of the method processes according to embodiments of the present application.

[0118] In the RAM 803, various programs and data required for the operation of the electronic device 800 are stored. The processor 801, the ROM 802, and the RAM 803 are connected to each other via the bus 804. The processor 801 performs various operations of the method processes according to the embodiments of the present application by executing the programs stored in the ROM 802 and / or the RAM 803. It should be noted that the programs can also be stored in one or more memories other than the ROM 802 and the RAM 803. The processor 801 can also perform various operations of the method processes according to the embodiments of the present application by executing the programs stored in the one or more memories.

[0119] According to the embodiments of the present application, the electronic device 800 can further include an input / output (I / O) interface 805, which is also connected to the bus 804. The electronic device 800 can further include one or more of the following components connected to the input / output (I / O) interface 805: an input part 806 including a keyboard, a mouse, and the like; an output part 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), and the like, and a speaker, and the like; a storage part 808 including a hard disk, and the like; and a communication part 809 including a network interface card such as a LAN card, a modem, and the like. The communication part 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the input / output (I / O) interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like is mounted on the drive 810 as necessary, so that a computer program read therefrom is installed in the storage part 808 as necessary.

[0120] The present application also provides a computer readable storage medium, which can be included in the device / apparatus / system described in the above embodiments; or can exist separately without being assembled into the device / apparatus / system. The above computer readable storage medium carries one or more programs, when the one or more programs are executed, the method according to the embodiments of the present application is implemented.

[0121] According to an embodiment of the present application, the computer readable storage medium can be a non-transitory computer readable storage medium, for example, can include but not limited to: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this application, a computer readable storage medium can be any tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present application, the computer readable storage medium can include the ROM 802 and / or the RAM 803 described above, and / or one or more memory in addition to the ROM 802 and the RAM 803.

[0122] Embodiments of the present application also include a computer program product, which includes a computer program containing program codes for executing the methods shown in the flowcharts. When the computer program product is run in a computer system, the program codes are used to make the computer system implement the methods provided by the embodiments of the present application.

[0123] The above functions defined in the system / device / apparatus of the embodiments of the present application are performed when the computer program is executed by the processor 801. According to an embodiment of the present application, the system, device, module, unit, etc. described above can be implemented by computer program modules.

[0124] In one embodiment, the computer program can rely on tangible storage media such as optical storage media, magnetic storage media, etc. In another embodiment, the computer program can also be transmitted, distributed, and downloaded in the form of signals on network media. The computer program containing program codes can be transmitted by any appropriate network media, including but not limited to wireless, wired, etc., or any suitable combination of the foregoing.

[0125] In such an embodiment, the computer program can be downloaded and installed from the network by the communication part 809, and / or installed from the detachable medium 811. When the computer program is executed by the processor 801, the above functions defined in the system of the embodiments of the present application are performed. According to an embodiment of the present application, the system, device, apparatus, module, unit, etc. described above can be implemented by computer program modules.

[0126] According to embodiments of the present application, program code for implementing the computer programs provided by embodiments of the present application can be written in any combination of one or more programming languages, and can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The programming language includes, but is not limited to, such languages as Java, C++, python, "C" language, or the like. The program code can execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the remote computing device, or entirely on the remote computing device or server. In the latter scenario, the remote computing device can be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computing device, such as through the Internet using an Internet Service Provider.

[0127] The computer program instructions can also be loaded onto a computer or other programmable information processing apparatus to cause a series of operations to be performed on the computer or other programmable information processing apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable information processing apparatus implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0128] Those skilled in the art will understand that features recited in the various embodiments of the present application can be combined and / or integrated in a variety of ways, even if such combinations or integrations are not expressly noted in the present application. In particular, features recited in the various embodiments of the present application can be combined and / or integrated in ways that do not depart from the spirit and scope of the present application. All such combinations and / or integrations are within the scope of the present application.

[0129] The embodiments of the present application have been described above. However, these embodiments are merely for the purpose of illustration, and are not intended to limit the scope of the present application. Although the embodiments are described separately above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Those skilled in the art can make various substitutions and modifications without departing from the scope of the present application, and these substitutions and modifications shall fall within the scope of the present application.

Claims

1. A method of updating firmware of a baseboard management controller, the method comprising: The method comprises: obtaining a firmware image file of the baseboard management controller, the firmware image file comprising a plurality of data blocks, the plurality of data blocks comprising a plurality of module feature data and a plurality of module firmware data, the module feature data comprising a type identification field and a length field, the type identification field being used to identify a category of management functions implemented by the module firmware data, and the length field being used to indicate a data length of the data block; identifying the plurality of module feature data in the firmware image file, the firmware image file comprising a plurality of preset interval identifiers and a preset index table, the preset index table storing offset addresses of the plurality of preset interval identifiers in the firmware image file; determining, as a category of management functions corresponding to the module firmware data, a category of management functions identified by the type identification field in any module feature data; querying, from the preset index table, offset addresses of the preset interval identifiers relative to a reference position of a start position of the firmware image file, to determine an offset of an end position of a preset interval identifier to be located relative to the reference position; determining, as a start position of module feature data next to the preset interval identifier, a next logical byte position corresponding to a sum of the reference position and the offset; truncating, as a continuous data segment, a start position of any module feature data as a reference, according to a data length indicated by a length field of the any module feature data; removing the module feature data from the truncated data segment to obtain module firmware data corresponding to the determined category of management functions; in response to a selection operation on the plurality of module firmware data, determining at least one target module firmware data from the plurality of module firmware data; performing, through an update interface corresponding to the at least one target module firmware data, an update operation on firmware corresponding to the at least one target module firmware data.

2. The method of claim 1, wherein, The firmware image file comprises a plurality of preset interval identifiers. The identifying the plurality of module feature data in the firmware image file comprises: identifying any of the preset interval identifiers in the firmware image file, and determining, as the module feature data, a data segment next to any of the preset interval identifiers, the module feature data being a data segment of a preset fixed length.

3. The method of claim 1, wherein, The determining at least one target module firmware data from the plurality of module firmware data in response to a selection operation on the plurality of module firmware data comprises: controlling a client to display function descriptions and version information corresponding to the plurality of module firmware data; in a case where a selection instruction for the at least one module firmware data is received from the client, determining, as the target module firmware data, module firmware data pointed to by the selection instruction.

4. The method of claim 1, wherein, The module feature data further comprises a check field; after the identifying the plurality of module feature data in the firmware image file, the method further comprises: reading the check field in any of the identified module feature data; calculating, according to an algorithm same as that for generating the check field, binary content in the module feature data excluding the check field to determine a check value; comparing the check value with an original check value read from the check field to obtain a comparison result; in a case where the comparison result represents that the check value is inconsistent with the original check value, aborting the update operation on the module firmware data.

5. The method of claim 1, wherein, Before the update operation on the firmware corresponding to the function of the target module firmware data through the update interface corresponding to the at least one target module firmware data, the method further comprises: backing up the currently running firmware data corresponding to the function of the target module firmware data; in a case where the update operation through the update interface fails, triggering a rollback operation, the rollback operation being used to instruct the baseboard management controller to reload the backed-up firmware data.

6. The method of claim 1, wherein, The method further comprises: recording an update start time of the update operation when the update operation starts; monitoring a firmware update result corresponding to the at least one target module firmware data; recording an update end time in a case where the firmware update result represents that the update operation ends; generating an update report according to the firmware update result, the update start time and the update end time, the update report comprising an identification, an update state and an update time consumption of the at least one target module firmware data.

7. The method of claim 1, wherein, The module characteristic data comprises version identification information; before the update operation on the firmware corresponding to the at least one target module firmware data, the method further comprises: identifying a version identification field in the module characteristic data, and determining version information of the target module firmware data from the version identification field; performing compatibility check on the version information of the target module firmware data and version information of the target module firmware data currently running in the baseboard management controller; in a case where the compatibility check passes, performing a subsequent update operation. 8.An electronic device, characterized by: a memory, configured to store a firmware image file of a baseboard management controller, the firmware image file comprising a plurality of data blocks, the plurality of data blocks comprising a plurality of module characteristic data and a plurality of module firmware data, the module characteristic data comprising a type identification field and a length field, the type identification field being used to identify a category of management function implemented by the module firmware data, and the length field being used to indicate a data length of the data block; a processor, in communication connection with the memory, configured to: identify a plurality of module characteristic data in the firmware image file, the firmware image file comprising a plurality of preset interval identifications and a preset index table, the preset index table storing offset addresses of the plurality of preset interval identifications in the firmware image file; determine, as a category of management function corresponding to the module firmware data, a category of management function identified by the type identification field in any module characteristic data; query, from the preset index table, an offset address of the preset interval identification, to determine an offset amount of an end position of the preset interval identification relative to a reference position, taking the start position of the firmware image file as the reference position. determining a next logical byte position corresponding to a sum of the reference position and the offset as a starting position of the module feature data adjacent to the preset interval identifier; taking a starting position of any module feature data as a reference, and taking a continuous data segment according to a data length indicated by a length field of the any module feature data; removing the module feature data from the taken data segment to obtain module firmware data corresponding to the determined management function category; in response to a selection operation on the plurality of module firmware data, determining at least one target module firmware data from the plurality of module firmware data; and providing the at least one target module firmware data to a baseboard management controller; the baseboard management controller, in communication connection with the processor, is used for: receiving the at least one target module firmware data from the processor through an update interface; performing an update operation on firmware corresponding to a function of the at least one target module firmware data according to the received at least one target module firmware data.

Images