Firmware upgrade method and apparatus, storage medium, electronic device, and program product

Abstract

Embodiments of the present application relate to the field of computers, and provide a firmware upgrade method and apparatus, a storage medium, an electronic device, and a program product. The firmware upgrade method comprises: executing a first firmware upgrade operation on a standby partition of a baseboard management controller; when the first firmware upgrade operation is completed, performing first upgrade verification on the upgraded standby partition, the first upgrade verification being used for verifying whether an upgrade result of the standby partition meets an expected firmware upgrade condition; when the upgrade result meets the expected firmware upgrade condition, performing an active-standby switchover operation on an active partition and the upgraded standby partition, the active-standby switchover operation being used for indicating that the active partition is set as a new standby partition and the upgraded standby partition is set as a new active partition; and executing a second firmware upgrade operation on the new standby partition. By using the above-described solution, the problem of low efficiency in firmware upgrading in the related technology is solved.

Description

Firmware upgrade methods and devices, storage media, electronic devices and software products

[0001] Cross-reference of related applications

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

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

[0004] In embedded systems and server management, firmware upgrades for the Baseboard Management Controller (BMC) are crucial for ensuring system security and performance improvement. However, existing BMC firmware upgrade methods are prone to service interruptions during the upgrade process, failing to guarantee security and efficiency, thus resulting in low firmware upgrade efficiency.

[0005] Therefore, the related technologies suffer from the technical problem of low firmware upgrade efficiency. Summary of the Invention

[0006] This application provides a firmware upgrade method and apparatus, storage medium, electronic device and program product, to at least solve the technical problem of low efficiency in firmware upgrades in related technologies.

[0007] According to one embodiment of this application, a firmware upgrade method is provided, comprising: performing a first firmware upgrade operation on a spare partition of a baseboard management controller, wherein the baseboard management controller includes a primary partition and a spare partition; upon completion of the first firmware upgrade operation, performing a first upgrade verification on the upgraded spare partition, wherein the first upgrade verification is used to verify whether the upgrade result of the spare partition meets the expected conditions for firmware upgrade; and if the upgrade result meets the expected conditions for firmware upgrade, performing a primary / supplementary switching operation on the primary partition and the upgraded spare partition, wherein the primary / supplementary switching operation is used to instruct the primary partition to be set as the new spare partition and the upgraded spare partition to be set as the new primary partition;

[0008] Perform a second firmware upgrade on the new spare partition.

[0009] According to another embodiment of this application, a firmware upgrade apparatus is provided, comprising: a first upgrade unit configured to perform a first firmware upgrade operation on a spare partition of a baseboard management controller, wherein the baseboard management controller includes a primary partition and a spare partition; a verification unit configured to perform a first upgrade verification on the upgraded spare partition after the first firmware upgrade operation is completed, wherein the first upgrade verification is used to verify whether the upgrade result of the spare partition meets the expected conditions for firmware upgrade; a switching unit configured to perform a primary / supplementary switching operation on the primary partition and the upgraded spare partition when the upgrade result meets the expected conditions for firmware upgrade, wherein the primary / supplementary switching operation is used to instruct the primary partition to be set as a new spare partition and the upgraded spare partition to be set as a new primary partition; and a second upgrade unit configured to perform a second firmware upgrade operation on the new spare partition.

[0010] According to yet another embodiment of this application, a non-volatile computer-readable storage medium is also provided, wherein a computer program is stored in the non-volatile computer-readable storage medium, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0011] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein a computer program is stored in the memory and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0012] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the methods in various embodiments of this application.

[0013] The embodiments provided in this application ensure that the primary partition (i.e., the currently running partition) can still provide services during the upgrade by performing a firmware upgrade on the backup partition first, thereby avoiding system downtime and service interruption caused by the upgrade. Before switching between the primary and backup partitions, a first upgrade verification is performed on the upgraded backup partition to ensure that the firmware upgrade result meets the expected conditions. Only when the upgrade result of the backup partition passes the verification is the primary / backup switch performed, and then the firmware is upgraded on the new backup partition. This ensures that the firmware versions of the primary and backup partitions are always consistent, improving the redundancy and stability of the system. Through the first upgrade verification, potential problems during the upgrade process can be detected in time, such as firmware not meeting the expected conditions, thereby avoiding switching problematic firmware to the primary state, effectively reducing the system failure rate, and ensuring the security of the upgrade process. In summary, the embodiments provided in this application realize the automation and intelligence of firmware upgrades, not only reducing manual intervention and human error, but also avoiding long downtime and high failure probability caused by a one-time update by performing phased upgrades (upgrading the backup partition first, then the primary partition), thereby achieving the technical effect of improving the efficiency of firmware upgrades and solving the technical problem of low efficiency in firmware upgrades in related technologies. Attached Figure Description

[0014] Figure 1 is a hardware structure block diagram of a firmware upgrade method according to an embodiment of this application;

[0015] Figure 2 is a flowchart of a firmware upgrade method according to this application;

[0016] Figure 3 is a schematic diagram of another firmware upgrade method according to this application;

[0017] Figure 4 is a schematic diagram of another firmware upgrade method according to this application;

[0018] Figure 5 is a schematic diagram of another firmware upgrade method according to this application;

[0019] Figure 6 is a structural block diagram of a firmware upgrade device according to an embodiment of this application. Detailed Implementation

[0020] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] The methods and embodiments provided in this application can be executed in a computer terminal or similar computing device. Taking a computer terminal as an example, FIG1 is a hardware structure block diagram of a computer terminal for a firmware upgrade method according to an embodiment of this application. As shown in FIG1, the computer terminal may include one or more (only one is shown in FIG1) processors 102 (processors 102 may include, but are not limited to, microprocessors MCUs or programmable logic devices FPGAs, etc.) and a memory 104 configured to store data. The computer terminal may also include a transmission device 106 configured for communication and an input / output device 108. Those skilled in the art will understand that the structure shown in FIG1 is only illustrative and does not limit the structure of the computer terminal. For example, the computer terminal may also include more or fewer components than shown in FIG1, or have a different configuration than shown in FIG1.

[0023] The memory 104 may be configured to store computer programs, such as application software programs and modules, like the computer program corresponding to the mapping relationship determination method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the aforementioned method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0024] The transmission device 106 is configured to receive or transmit data via a network. Examples of such networks may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module configured to communicate wirelessly with the Internet.

[0025] As an optional solution, as shown in Figure 2, a firmware upgrade method includes the following steps:

[0026] S202, Perform the first firmware upgrade operation on the spare partition of the baseboard management controller, wherein the baseboard management controller includes a primary partition and a spare partition;

[0027] S204, after the first firmware upgrade operation is completed, perform a first upgrade verification on the upgraded backup partition, wherein the first upgrade verification is used to verify whether the upgrade result of the backup partition meets the expected conditions of the firmware upgrade.

[0028] S206, if the upgrade result meets the expected conditions of the firmware upgrade, perform a primary / backup switch operation on the primary partition and the upgraded backup partition. The primary / backup switch operation is used to indicate that the primary partition is set as the new backup partition and the upgraded backup partition is set as the new primary partition.

[0029] S208 performs a second firmware upgrade operation on the new spare partition.

[0030] Optionally, in this embodiment, the Baseboard Management Controller (BMC) is an embedded microcontroller, often used for remote monitoring and management of servers and storage devices. It can operate independently of the main processor, providing real-time monitoring of system status, performing firmware updates, and restarting and recovering the system in case of failure.

[0031] Optionally, in this embodiment, the BMC is typically configured with two firmware storage partitions: a primary partition and a backup partition. The primary partition may, but is not limited to, the partition where the currently running firmware resides, while the backup partition is used to store new or backup firmware versions.

[0032] Optionally, in this embodiment, the first firmware upgrade operation and the second firmware upgrade operation refer to upgrading the firmware of the spare partition and the new spare partition, respectively, to update the firmware version, add new features, and fix known issues. The first firmware upgrade operation is performed on the spare partition, while the second firmware upgrade operation is performed on the original primary partition (now the new spare partition) after the primary / standby switchover.

[0033] Optionally, in this embodiment, the first upgrade verification is a series of checks performed after the first firmware upgrade operation is completed, in order to verify whether the upgraded firmware meets the predetermined expected conditions, such as the functional integrity of the firmware, the normal operation of the service, and the correctness of the configuration file.

[0034] Optionally, in this embodiment, the firmware upgrade expected conditions are used to indicate the standards that should be met after the firmware upgrade, including but not limited to firmware stability, compatibility, performance indicators, etc., to ensure that the upgraded BMC can operate normally and that service continuity is not affected.

[0035] Optionally, in this embodiment, the primary / standby switchover operation is performed after the first upgrade verification confirms that the upgrade result meets the expected conditions. The purpose is to convert the current primary partition into a new standby partition, and at the same time promote the upgraded standby partition to a new primary partition, so as to ensure that the system runs on the latest firmware version.

[0036] Optionally, in this embodiment, a first firmware upgrade operation is performed on the BMC's backup partition. The goal is to update the firmware version to fix known issues and improve system performance and security. During the upgrade process, the primary partition continues to operate, ensuring the continuity of system services.

[0037] Next, after the first firmware upgrade operation is completed, the upgraded backup partition is subjected to the first upgrade verification to ensure that the new firmware meets the expected conditions and to avoid system failures caused by firmware problems.

[0038] If the first upgrade verification confirms that the upgrade result meets the expected conditions, then a primary / standby switchover operation is performed, setting the primary partition as the new standby partition and the upgraded standby partition as the new primary partition. This ensures that the system runs on the latest stable firmware version.

[0039] Finally, a second firmware upgrade operation is performed on the new backup partition (i.e., the original primary partition), thereby ensuring the firmware version consistency between the primary and backup partitions and enhancing the redundancy and reliability of the system.

[0040] During implementation, the first firmware upgrade operation involves multiple steps, including firmware upload, verification, flashing, and bootloader (bootloader) settings. Firmware upload involves transferring the new firmware file to the backup partition; firmware verification checks the integrity of the uploaded firmware file; firmware flashing writes the firmware content to the backup partition; and setting the bootloader instructs the system to load the firmware from the upgraded backup partition after reboot.

[0041] The first upgrade verification, performed after the firmware upgrade, involves a series of automated tests, such as functional module verification, health status checks, performance tests, and compatibility checks, to verify whether the upgrade results meet expectations. If any unexpected conditions are detected, such as firmware malfunctions, performance degradation, or configuration errors, the first upgrade verification will prevent the primary / standby switchover operation from being executed, thus preventing the system from operating in an unstable state.

[0042] The primary / standby switchover operation is performed after the first upgrade verification is confirmed to be correct. By switching the partition role, the system can run the latest version of firmware without interrupting service, while providing an upgrade preparation state for the new standby partition.

[0043] Finally, a second firmware upgrade operation is performed on the new backup partition, ensuring firmware version consistency between the primary and backup partitions and further enhancing system redundancy and reliability. This upgrade method is not only suitable for large-scale server management environments such as data centers and cloud service infrastructures, but also for remote devices, high-availability systems, and critical industry applications, providing a more secure, efficient, and intelligent solution for firmware upgrades.

[0044] The embodiments provided in this application ensure that the primary partition (i.e., the currently running partition) can still provide services during the upgrade by performing a firmware upgrade on the backup partition first, thereby avoiding system downtime and service interruption caused by the upgrade. Before switching between the primary and backup partitions, a first upgrade verification is performed on the upgraded backup partition to ensure that the firmware upgrade result meets the expected conditions. Only when the upgrade result of the backup partition passes the verification is the primary / backup switch performed, and then the firmware is upgraded on the new backup partition. This ensures that the firmware versions of the primary and backup partitions are always consistent, improving the redundancy and stability of the system. Through the first upgrade verification, potential problems during the upgrade process can be detected in a timely manner, such as firmware not meeting the expected conditions, thereby avoiding switching problematic firmware to the primary state, effectively reducing the system failure rate, and ensuring the security of the upgrade process. In summary, the embodiments provided in this application realize the automation and intelligence of firmware upgrades, not only reducing manual intervention and human error, but also avoiding long downtime and high failure probability caused by a one-time update by performing phased upgrades (upgrading the backup partition first, then the primary partition), thereby achieving the technical effect of improving the efficiency of firmware upgrades.

[0045] As an optional solution, the upgraded spare partition is verified, including:

[0046] The upgraded backup partition is subjected to a first verification, which verifies whether the basic state of the upgraded backup partition meets the first expected condition.

[0047] If the basic state meets the first expected condition, a second verification is performed on the upgraded backup partition. The second verification is used to verify whether the upgrade module of the upgraded backup partition meets the second expected condition.

[0048] If the upgrade module meets the second expected condition, the upgrade result is determined to meet the expected condition for firmware upgrade.

[0049] Optionally, in this embodiment, the first verification is a verification of the basic state of the upgraded backup partition. The basic state includes, but is not limited to, the running state of the BMC service, the correctness of the configuration file, the thread running state, the BMC restart record, and the average CPU (Central Processing Unit) utilization. The first expected condition sets the qualification standard for these states to ensure that the new firmware can run stably.

[0050] Optionally, in this embodiment, the second verification is performed after the first verification confirms that the basic state is normal. The modified functional modules in the upgraded spare partition are verified, including newly added, deleted or modified modules, to verify whether their functions are normal and whether they meet the expected performance and functional requirements. These expected conditions constitute the second expected conditions to ensure that the upgraded firmware can provide all the necessary functions.

[0051] Optionally, in this embodiment, a first verification is performed to comprehensively check the basic state of the backup partition to confirm the stability of the new firmware under minimum operating conditions. Then, after the basic state verification passes, a second verification is performed, focusing on the modified functional modules in the new firmware to ensure the normal operation and performance improvement of the required functions. This phased verification process not only systematically checks the applicability and functionality of the new firmware but also identifies potential faults and performance issues in advance, avoiding greater impact after primary / backup switching, thereby ensuring the safety, effectiveness, and fault-free nature of the entire upgrade process.

[0052] The embodiments provided in this application effectively prevent upgrade failures and potential system malfunctions through a meticulous two-stage verification process, thereby improving upgrade efficiency and system reliability.

[0053] As an optional approach, a first verification is performed on the upgraded spare partition, including:

[0054] Obtain the list of partition configuration files for the upgraded spare partition, where the list of partition configuration files indicates the setting information of the configuration files in the upgraded spare partition;

[0055] If the number of configuration files is incorrect or the settings do not meet the expected configuration conditions, it is determined that the basic state of the upgraded standby partition does not meet the first expected conditions.

[0056] Optionally, in this embodiment, the partition configuration file list is a part of the BMC basic health status detection configuration file, used to indicate the configuration file settings information in the upgraded spare partition, including the configuration file name, location, version, and important setting parameters, etc.

[0057] Optionally, in this embodiment, the configuration expected conditions are a set of expected conditions established to ensure that the configuration file is set correctly, including the integrity and correctness of the configuration file and specific setting requirements that match the new firmware version, such as file existence checks and configuration parameter correctness verification.

[0058] Optionally, in this embodiment, the correct configuration file settings are crucial for BMC firmware upgrades, directly affecting whether the new firmware can run correctly and whether system services can be provided normally. Therefore, in the first verification phase, by obtaining the partition configuration file list, the system can automatically identify the existence, version information, and parameter settings of the configuration files, compare them with the expected configuration conditions, and ensure that the configuration file settings match the new firmware version and that the configuration files themselves are not missing or incorrectly configured. If the number of configuration files is found to be incorrect or the setting information does not meet the expected conditions during the check, the system will automatically determine that the basic state of the upgraded backup partition does not meet the first expected conditions, avoiding switching the problematic firmware to the primary state, reducing the system failure rate, and ensuring the security and efficiency of the upgrade process.

[0059] The embodiments provided in this application offer implementation guidance for configuration file verification during BMC dual-partition upgrades, ensuring the correctness and stability of the new firmware at the configuration level.

[0060] As an optional approach, after obtaining the list of partition configuration files for the upgraded spare partition, the method also includes:

[0061] If the number of configuration files is correct and the settings meet the expected configuration conditions, obtain the running logs of the upgraded standby partition;

[0062] Check the records in the operation log that fall within the first detection time period;

[0063] If abnormal restart records are found in the records of the first detection period, it is determined that the basic state of the upgraded backup partition does not meet the first expected condition.

[0064] Optionally, in this embodiment, the runtime log records detailed information about the BMC during runtime, including service status, error records, restart events, performance data, etc., which is an important basis for analyzing the health status of the system.

[0065] Optionally, in this embodiment, the first detection time period is a preset time window used to check the system's operating status for a period of time after the BMC upgrade, to ensure that the system runs stably under the new firmware.

[0066] Optionally, in this embodiment, the abnormal restart record is used to record abnormal restart events recorded in the operation log, which may indicate that the system has serious stability problems and requires further investigation and handling.

[0067] Understandably, this embodiment involves checking the operation logs of the upgraded backup partition. Verifying the correctness and completeness of the configuration file is fundamental to ensuring the stable operation of the new firmware, while analyzing the operation logs provides a deep verification of the system's operational status. By acquiring the operation logs of the upgraded backup partition, the system can check for any abnormal reboot records within the first detection period. This is a crucial indicator of the stability of the new firmware in actual operation. If an abnormal reboot record is detected, it indicates that the new firmware has encountered a significant problem during operation and cannot meet the system stability requirements of the first expected condition. Therefore, the basic state is considered unsatisfactory, and the system will not perform subsequent primary / backup switchover operations until the problem is resolved. This ensures that the firmware version of the primary partition is not affected by the upgrade failure, maintaining the continuity and security of system services.

[0068] The embodiments provided in this application enable the timely detection of potential problems in the upgraded firmware by checking the operation logs, thus avoiding the need to switch firmware with stability risks to the primary state and providing stronger reliability and security.

[0069] As an optional approach, after checking the records in the operation log that fall within the first detection time period, the method also includes:

[0070] If no abnormal restart records are found in the records of the first detection period, obtain the service running status of each service in the upgraded backup partition, and obtain the thread running status of each thread associated with each service.

[0071] If the service running status does not meet the expected service conditions or the thread running status does not meet the expected thread conditions, it is determined that the basic state of the upgraded backup partition does not meet the first expected condition.

[0072] Optionally, in this embodiment, the service operation status of each service is used to indicate the operation status of various system services in the backup partition after the upgrade, including but not limited to whether the service starts normally, whether the service status meets expectations, and the service resource usage.

[0073] Optionally, in this embodiment, the expected service conditions are preset standards for the normal operation of the system service, ensuring the stability and efficiency of the service, including successful service startup, correct service status, and reasonable use of service resources.

[0074] Optionally, in this embodiment, the thread running status of each thread is used to indicate the running status of each thread in the system service and is an important part of the service health status. Abnormal thread running status may cause service failure.

[0075] Optionally, in this embodiment, the expected conditions for the thread are preset standards for the normal operation of the thread, ensuring the stability and responsiveness of the thread, including the correct start of the thread, the normal state of the thread, and the reasonable use of thread resources.

[0076] Optionally, in this embodiment, after confirming that the system has not experienced any abnormal restarts during the first detection period, it is necessary to further verify the running status of all services and threads to ensure that the new firmware can stably run all necessary services and that each service's threads can execute correctly. Stable operation of services and threads is the cornerstone of normal BMC operation; any service startup failure or abnormal thread state can affect the overall functionality and performance of the system. Therefore, by obtaining the running status of services and service threads in the upgraded backup partition, the system can comprehensively assess its health status. Once an operating status that does not meet expectations is found, the system will immediately determine that the basic status does not meet expectations, stop the primary / backup switch, and continue until the running status of services and threads passes verification, ensuring that the upgraded BMC can achieve the expected stability and performance requirements at the service and thread levels.

[0077] The embodiments provided in this application improve the reliability of system upgrades and enhance the protection of system stability and service continuity through the inspection mechanism of service and thread running status.

[0078] As an optional approach, after obtaining the service status of each service in the upgraded spare partition, the method also includes:

[0079] If the service running status meets the expected service conditions and the thread running status meets the expected thread conditions, obtain the average CPU utilization of the upgraded backup partition during the second detection period.

[0080] If the average utilization of the central processing unit is greater than a preset threshold, it is determined that the basic state of the upgraded spare partition does not meet the first expected condition.

[0081] If the average utilization of the central processing unit is less than or equal to a preset threshold, the basic state of the upgraded spare partition is determined to meet the first expected condition.

[0082] Optionally, in this embodiment, the second detection time period is a time window used to monitor the central processing unit (CPU) usage in real time after the firmware upgrade, to ensure that the new firmware does not cause excessive CPU load in actual operation.

[0083] Optionally, in this embodiment, the average utilization rate of the central processing unit is the average CPU utilization rate during the second detection period, which is an important performance indicator. An excessively high average utilization rate may indicate that the system has a performance bottleneck or resource consumption problem.

[0084] Optionally, in this embodiment, the expected service conditions and expected thread conditions are preset service and thread running states as standards to ensure that all necessary services and threads can run stably after the BMC upgrade, meeting business needs and performance requirements.

[0085] Understandably, after the first two steps of the initial verification—checking the service and thread running status—are confirmed to be correct, the system proceeds to check the average CPU utilization. Average CPU utilization is a crucial indicator of system performance and resource usage. Excessively high or unstable CPU utilization may indicate a resource bottleneck or improper resource management by the new firmware, leading to performance degradation or system instability. By monitoring the average CPU utilization during the second detection period and comparing it to a preset threshold, the system can accurately determine whether the new firmware's performance in actual operation meets expectations. This ensures that the upgraded spare partition also meets the first expected condition in terms of CPU resources, providing completeness and depth to the verification process.

[0086] The embodiments provided in this application not only enhance the performance verification of system upgrades, but also provide a strong reference for BMC resource management, ensuring that the upgraded system can operate stably within the preset resource usage range, and avoiding performance degradation or system instability caused by excessive resource consumption.

[0087] As an optional solution, a second verification is performed on the upgraded spare partition, including:

[0088] The configuration file associated with the first firmware upgrade is parsed to obtain the configuration information of the upgrade module. The configuration file is used to store the module information to be upgraded in the first firmware upgrade operation.

[0089] Read the configuration information and perform a module check on at least one module in the upgrade module, wherein at least one module is a module in the upgrade module whose verification item is set to the enabled state.

[0090] Optionally, in this embodiment, the second verification is used to indicate the verification of the functional integrity and correctness of the upgrade module after the first verification confirms that there are no errors, so as to ensure that the upgraded BMC can provide all the necessary functional modules and that these modules can operate normally.

[0091] Optionally, in this embodiment, the first firmware upgrade management configuration file records the configuration information of all modified modules in the firmware upgrade operation, including the name, version, function description, and whether verification is enabled of the upgrade module, which is used to guide the execution of the second verification.

[0092] Optionally, in this embodiment, the upgrade module is a functional module that is updated during the firmware upgrade operation, including modules that are added, deleted, or modified, and functional verification is required to ensure its correctness and stability.

[0093] Optionally, in this embodiment, the verification item is a parameter defined in the configuration file to control whether module verification is enabled. It is usually set to 0 or 1, where 0 means verification is not enabled and 1 means verification is enabled.

[0094] Understandably, in this embodiment, by accurately parsing and utilizing the first firmware upgrade management configuration file, the system ensures that it can accurately identify which modules have been modified during the upgrade operation and require subsequent functional verification. By reading the configuration file, the system can obtain detailed information about each upgrade module, including the module name, version information, and whether verification is enabled. Then, it performs functional checks on the modules set to verification enabled one by one to ensure that these modules can run correctly in the new firmware, with complete and stable functionality. The implementation of this verification process not only improves the efficiency of firmware upgrades and avoids redundant verification of all modules, but also ensures that the functional modules of the BMC after the upgrade can meet the expected requirements.

[0095] The embodiments provided in this application ensure the correctness and stability of functional modules in the new firmware version, optimize the verification process, improve the efficiency of firmware upgrades, and are suitable for scenarios with extremely high requirements for the stability of functional modules, thereby helping to improve the overall operating efficiency and service continuity of the system.

[0096] As an optional approach, at least one module in the upgrade module is subjected to a module check, including:

[0097] Extract the interface name and request parameters for each check item of at least one module from the configuration information;

[0098] Using the interface name and request parameters, execute an application interface request triggered on at least one module, wherein the application interface request is used to obtain the first response value of at least one module;

[0099] Based on the comparison between the first response value and the second response value indicated in the configuration information, it is determined whether the upgrade module meets the second expected condition.

[0100] Optionally, in this embodiment, the configuration information is the module details parsed from the first firmware upgrade management configuration file, including interface name, request parameters, expected return value, etc., which is used to guide module checks.

[0101] Optionally, in this embodiment, the Application Programming Interface (API) request is a software communication method used to call the module's functional interface, test its input, output and responsiveness, and is the core step of module checking.

[0102] Optionally, in this embodiment, the first response value is the actual response value returned by the module after executing the API request, including but not limited to status codes, error messages, and data returns. The second response value is the expected response value defined in the configuration information, that is, the response value that the module should return under normal operating conditions, used to compare with the first response value to verify the correctness of the module.

[0103] Understandably, in this embodiment, the check items for each module are first obtained from the configuration information, including the name of its functional interface and request parameters. Then, by executing API requests, the input, output and responsiveness of the module in the new firmware version are tested to obtain the first response value. Finally, these actual response values ​​are compared with the expected response values ​​defined in the configuration information to determine whether the module can run correctly and meet the expected functional and performance indicators.

[0104] The embodiments provided in this application ensure that after the BMC dual-partition firmware upgrade, the new version of the module can provide services stably and reliably, avoiding system failures caused by abnormal module functions, and are suitable for various scenarios with strict verification requirements for functional modules.

[0105] As an optional approach, based on the comparison between the first response value and the second response value indicated in the configuration information, it is determined whether the upgrade module meets the second expected condition, including:

[0106] If the first response value and the second response value are consistent, it is determined that the upgrade module meets the second expected condition;

[0107] If the first response value and the second response value are inconsistent, it is determined that the upgrade module does not meet the second expected condition.

[0108] Optionally, in this embodiment, by comparing the actual operating results with the expected results, it is possible to intuitively determine whether the module's functional performance in the upgraded BMC environment meets the expected standards. If the response values ​​of all modules are consistent with expectations, it means that the module's functions are stable and the data processing is correct, meeting the upgraded functional and performance requirements. The system can then safely perform a primary / standby switchover, promoting the upgraded standby partition to the new primary partition. If the response value of any module is inconsistent with expectations, it indicates that the module is malfunctioning in the new environment, potentially indicating functional errors or performance issues. The primary / standby switchover operation needs to be paused, and the module further debugged and optimized until all modules pass verification, ensuring that their functions and data processing meet the second expected condition.

[0109] The embodiments provided in this application provide security for subsequent primary / backup switching, ensuring that the upgraded BMC environment can stably run all necessary functional modules and meet business needs and performance requirements.

[0110] As an optional approach, at least one module in the upgrade module is subjected to a module check, including at least one of the following:

[0111] A module check is performed on the first module included in at least one module, wherein the first module is a newly added module in the upgrade module;

[0112] A module check is performed on a second module included in at least one module, wherein the second module is a module deleted from the upgrade module;

[0113] A module check is performed on at least one third module included in the module, wherein the third module is a module modified in the upgrade module.

[0114] Optionally, in this embodiment, functional verification is performed on the newly added modules (first module), deleted modules (second module), and modified modules (third module) in the upgrade module. This verification process is differentiated based on the module type (added, deleted, modified), ensuring that different types of modules can undergo functional verification appropriate to their characteristics, thereby confirming the functional integrity and stability of the modules in the new firmware version. For the newly added first module, it is necessary to verify whether its function is correctly implemented and whether it can be seamlessly integrated with the existing system; for the deleted second module, it is necessary to confirm that its deletion will not affect the normal operation of other modules in the system, and whether there are suitable alternatives for the original functions; for the modified third module, it is necessary to verify whether its modification has achieved the expected performance improvement or problem fix, and whether it will introduce new functional anomalies. The implementation of this process ensures the functional integrity and stability of the upgraded BMC environment.

[0115] As an alternative approach, after performing a second firmware upgrade on the new spare partition, the method also includes:

[0116] After the second firmware upgrade operation is completed, a second upgrade verification is performed on the new backup partition after the upgrade. The second upgrade verification is used to verify whether the upgrade result of the new backup partition after the upgrade meets the expected conditions of the firmware upgrade.

[0117] Optionally, in this embodiment, after the firmware upgrade operation is completed on the new backup partition, a comprehensive test and verification of the upgrade result is performed to confirm whether it meets the expected conditions for firmware upgrade. The expected conditions for firmware upgrade include system performance indicators, correct operation of functional modules, and resource usage status, which are important standards for measuring the success of the firmware upgrade. The implementation of the second upgrade verification ensures that the new backup partition can run stably on the latest firmware version after the upgrade, with complete functionality and performance meeting the standards, providing a security guarantee for subsequent primary / backup switching. If the second upgrade verification result shows that the upgrade result of the new backup partition meets expectations, the system will prepare for primary / backup switching, promoting the new backup partition to the primary partition; if the verification result does not meet expectations, the system will suspend the primary / backup switching operation, troubleshoot and repair the new backup partition until all verification conditions are met, ensuring that the upgraded BMC environment can run stably and meet business needs and performance requirements.

[0118] As an alternative approach, the method also includes:

[0119] The primary partition functioned normally during the first firmware upgrade operation;

[0120] The new primary partition functioned normally during the second firmware upgrade operation.

[0121] Optionally, in this embodiment, the partition in the BMC that was not upgraded (the primary partition during the first firmware upgrade operation, and the new primary partition during the second firmware upgrade operation) continues to function normally. During the firmware upgrade operation, another partition of the BMC should be able to seamlessly take over all management and service functions to ensure the stability and continuity of the system during the upgrade process. This requirement is crucial for ensuring business continuity and system stability, especially in critical business scenarios where any service interruption can have a significant impact.

[0122] The embodiments provided in this application ensure that the currently running primary partition remains operational during any firmware upgrade operation, whether during the first firmware upgrade operation or as a new primary partition after the completion of the second firmware upgrade operation. This control mechanism ensures that a portion of the BMC is always running stably and providing necessary services during firmware upgrades, avoiding service interruptions caused by firmware updates and contributing to business continuity and system stability.

[0123] As an optional approach, a first firmware upgrade operation is performed on the spare partition of the baseboard management controller, including:

[0124] Upload the first firmware to the backup partition, whereby the first firmware is used to perform the first firmware upgrade operation on the backup partition;

[0125] Before performing a primary / standby switchover on the primary partition and the upgraded standby partition, the method also includes:

[0126] If the upgrade result meets the expected conditions for firmware upgrade, the first firmware is burned to the spare partition, and the spare partition after burning is determined as the spare partition after the upgrade.

[0127] Optionally, in this embodiment, firstly, the first firmware is uploaded to the backup partition via the BMC's remote management interface, completing the firmware file transfer. Subsequently, the system performs firmware verification to ensure the integrity of the first firmware and its compatibility with the current operating environment. If the firmware verification passes, the system performs health status checks and functional module verification on the upgraded backup partition, including but not limited to the running status of services required by the BMC, the correctness of configuration files, the normal startup of BMC threads, average CPU utilization, and the input / output responses of functional modules, ensuring that the new firmware version meets all expected firmware upgrade conditions. If the upgrade result passes all tests and verifications, the system performs a burning operation, permanently storing the first firmware on the backup partition, completing the first firmware upgrade operation, and designating this partition as the upgraded backup partition. At this point, the upgraded backup partition is ready, awaiting subsequent primary / backup switchover operations to be officially put into use with the new firmware version.

[0128] The embodiments provided in this application, through the process and verification mechanism of performing the first firmware upgrade operation on the backup partition, ensure the stable operation of the new firmware version on the backup partition, as well as the comprehensive testing and verification before the primary / backup switch, avoiding system failures or performance degradation caused by upgrade failures, and providing important guarantees for business continuity and system stability.

[0129] As an optional solution, a primary / standby failover operation is performed on the primary partition and the upgraded standby partition, including:

[0130] Configure the bootloader, which instructs the baseboard management controller to load and run from the new primary partition after a reboot;

[0131] Restart the baseboard management controller.

[0132] Optionally, in this embodiment, the bootloader is a program that runs when the BMC starts, responsible for loading and initializing the operating system or firmware environment, and can be configured to specify which partition to load and run from.

[0133] Optionally, in this embodiment, restarting refers to the process of shutting down and restarting the BMC, which is usually performed after a firmware upgrade operation to ensure the correct loading and operation of the new firmware version.

[0134] Optionally, in this embodiment, the system first configures a bootloader to instruct the BMC to load and run from the upgraded backup partition after a reboot, ensuring the correct loading of the new firmware version. This configuration can be achieved by modifying the BMC's boot configuration file or by sending corresponding configuration commands through a remote management interface. Next, the system will perform a BMC reboot operation. At this time, the BMC will boot from the new primary partition according to the latest bootloader configuration, load and run the new firmware version, and officially put the new firmware version into use. The reboot operation needs to be performed with caution, ensuring that it is performed when the system is under low business pressure to avoid unnecessary impact on business operations. After the primary / backup switch is completed, the system should be monitored for a period of time to ensure that the new firmware version can run stably, meet business needs and performance requirements, and avoid potential problems from negatively impacting system operation.

[0135] Through the embodiments provided in this application, the primary / backup switchover operation process and bootloader setting mechanism ensure that the new firmware version can be correctly loaded and run in the BMC dual-partition upgrade strategy, and at the same time, the primary / backup switchover operation is officially completed.

[0136] As an optional approach, after performing upgrade verification on the upgraded spare partition, the method also includes:

[0137] If the upgrade result does not meet the expected conditions for firmware upgrade, an alarm message indicating the failure of the first firmware upgrade operation will be reported, and the firmware version of the upgraded backup partition will be rolled back to the state before the first firmware upgrade operation.

[0138] Optionally, in this embodiment, the alarm information is the information reported by the system when the upgrade result does not meet the expected conditions for firmware upgrade, which is used to indicate that the first firmware upgrade operation failed and to provide a basis for troubleshooting and repair.

[0139] Optionally, in this embodiment, rollback means restoring the firmware version of the upgraded backup partition to the version before the first firmware upgrade operation in the event of upgrade verification failure, so as to ensure the stable operation of the system.

[0140] Optionally, in this embodiment, if the upgrade verification fails, the system will automatically report an alarm message, clearly indicating that the first firmware upgrade operation failed, and providing detailed fault information and rollback instructions. The system administrator can then troubleshoot and repair the problem based on the alarm message. After the alarm message is reported, the system will perform a rollback operation, restoring the firmware version of the upgraded backup partition to the version before the first firmware upgrade operation, ensuring that the system can run stably on the old firmware version and avoiding potential faults or performance issues from affecting services.

[0141] The embodiments provided in this application ensure that the system can recover quickly even in the event of a firmware upgrade failure, thus guaranteeing business continuity and system stability.

[0142] As an alternative, if the upgrade result does not meet the expected conditions for the firmware upgrade, one of the following situations may occur:

[0143] The upgraded backup partition's basic condition does not meet the initial expected conditions;

[0144] The upgraded module for the backup partition does not meet the second expected condition.

[0145] Optionally, in this embodiment, situations where the upgrade result does not meet the expected conditions for firmware upgrade include the basic state failing to meet the first expected condition and the upgrade module failing to pass the verification of the second expected condition. The first expected condition for the basic state relates to the overall operating status of the BMC, including but not limited to system performance and resource usage. If the basic state of the upgraded backup partition fails to meet these preset standards, the upgrade result will be considered as not meeting expectations. The second expected condition for the upgrade module focuses on the correct operation and performance of the new functional module. If the new functional module fails the verification or exhibits functional abnormalities, the upgrade result will also be considered as not meeting expectations.

[0146] The embodiments provided in this application ensure that even if the preset performance and functional standards are not met during the firmware upgrade process, the system can quickly restore stable operation by reporting alarm information and rolling back the firmware version, thus avoiding potential failures or performance problems from adversely affecting business operations.

[0147] As an alternative, the aforementioned firmware upgrade method can be applied to BMC dual-partition upgrade scenarios in the server and storage field. In this scenario, firmware upgrades can fix known security vulnerabilities, improving the overall security of the system; upgrade firmware to resolve bugs (vulnerabilities) and performance issues in previous versions, improving the stability and reliability of the system; and add new features and improve existing functions, enhancing their response speed and processing capabilities.

[0148] Typically, a BMC (Backup Management System) uses two partitions for dual-mirror backups. Dual-mirror backups ensure redundant storage of critical data. If one partition fails or its data is corrupted, the other partition can still provide usable data. Dual-mirror backups improve system reliability and availability; if one partition fails, the system can quickly switch to the backup.

[0149] Currently, there are generally three ways to upgrade a BMC dual-partition system: Method 1: Upgrade only the backup partition. After the upgrade is complete, switch the partitions to make the new firmware effective. Method 2: Upgrade both partitions to the new firmware simultaneously. Method 3: Upgrade the backup partition first. After a successful upgrade, switch to the backup partition to boot and silently upgrade the old firmware version on the main partition to the latest version.

[0150] Each of the above upgrade methods has its own drawbacks. Method 1 has the problem that if the two versions differ significantly, and the new version malfunctions, the old version's service will not meet the demands. Method 2 has the problem that the upgrade takes a long time, causing business downtime, and the prolonged upgrade time increases the probability of upgrade failure. Method 3 has the problem that it first upgrades the backup partition, and after a successful upgrade, switches to the backup partition to boot. Then, it silently upgrades the primary partition. Due to the lack of firmware functionality verification, if the firmware malfunctions, although booting will succeed, both BMC firmware partitions will have been upgraded to a malfunctioning version, rendering the functionality unusable and the upgrade failing.

[0151] To avoid the aforementioned drawbacks, this application provides a BMC dual-partition upgrade method, in which the old firmware is silently upgraded to the latest version in the newly upgraded partition, ensuring version consistency, saving upgrade time, and ensuring the reliability of service provision.

[0152] The BMC dual-partition upgrade process mainly includes: upgrading device selection, firmware upload, firmware verification, firmware burning, bootloader configuration, BMC restart, and silent upgrade.

[0153] First, upgrade the backup partition. If the upgrade is successful, switch to the backup partition to boot. After the upgrade takes effect, perform a BMC health check to verify the functionality of the modified modules (added, deleted, and modified modules) in the new firmware. If the BMC health check is successful and the modified module functionality verification is successful, then a silent upgrade of the primary partition is performed to maintain firmware consistency between the primary and backup partitions. If the BMC health check fails or the modified module functionality verification fails, the upgrade is considered a failure, the silent upgrade of the primary partition is not performed, and the system restarts from the primary partition.

[0154] Optionally, the dual-partition upgrade process is shown in Figure 3, including:

[0155] Step S302: BMC initiates firmware upgrade process;

[0156] Step S304: Upgrade the backup partition image;

[0157] Step S306, upgrade complete, BMC restart;

[0158] Step S308, Basic health status detection of BMC;

[0159] Step S310: Under the condition that the basic health status is healthy, perform BMC modification module function verification;

[0160] Step S312: If the BMC modification module function verification passes, upgrade the original primary partition image;

[0161] Step S314: If the BMC modification module fails the function verification or the basic health status is unhealthy, report a backup partition image upgrade failure warning.

[0162] Step S316: The BMC switches back to the original primary partition for boot.

[0163] Understandably, the upgrade process involves the BMC upgrading to the new firmware on the backup partition. The upgrade steps include: device selection, firmware upload, firmware verification, firmware flashing, bootloader setup, and BMC reboot. The BMC switches to the backup partition and boots the new firmware. The BMC performs a basic health check, verifying its own health. If its health is not OK, it reports a backup partition image upgrade failure alarm. Instead of a silent upgrade to the original primary partition, the BMC switches back to the original primary partition and reboots from there. If its health is OK, it verifies the modified functional modules in the new firmware, including added, deleted, and modified modules. If the verification of modified functional modules fails, it reports a backup partition image upgrade failure alarm. Instead of a silent upgrade to the original primary partition, the BMC switches back to the original primary partition and reboots from there. If the verification of modified functional modules succeeds, the original primary partition image is upgraded.

[0164] Optionally, the detection process for the basic health status of the BMC, as shown in Figure 4, includes:

[0165] Step S402: Parse the health monitoring configuration file;

[0166] Step S404: Traverse the BMC configuration file list;

[0167] Step S406: Check if the configuration file is correct;

[0168] Step S408: If the configuration file is correct, continuously detect, obtain and record the current CPU usage.

[0169] Step S410: Check the BMC operation log or system event log for any abnormal restart records during the detection period.

[0170] Step S412: In the absence of any abnormal restart records, traverse the BMC service list;

[0171] Step S414: Check the service running status;

[0172] Step S416: If the service is running normally, iterate through the thread running states under the service process;

[0173] Step S418: Check the thread running status;

[0174] Step S420: Calculate the average CPU utilization under normal thread running conditions;

[0175] Step S422: If the average CPU utilization does not exceed the set threshold, determine the basic health status of BMC as healthy.

[0176] Step S424: If the configuration file is incorrect, there is an abnormal restart record, the service is not running normally, the thread is not running normally, or the average CPU utilization exceeds the set threshold, determine that the BMC basic health status is unhealthy.

[0177] Understandably, the process involves parsing the BMC basic health status detection configuration file. This file contains: a list of services required by the BMC, a list of BMC configuration files, a CPU utilization threshold, and the path to the BMC runtime log or system event log. The process iterates through the BMC configuration file list, checking for correctness. If a configuration file exists and certain settings meet expectations, it is considered correct; otherwise, it is incorrect, the health status detection fails, and the process exits. The current CPU utilization is then retrieved and recorded. The BMC runtime log or system event log is used to check for any abnormal restarts during the detection period. If an abnormal restart occurs, the health status detection fails, and the process exits. The BMC service list is iterated through, checking service running status. If a service's running status is abnormal, the health status detection fails, and the process exits; otherwise, it succeeds. All associated threads under the service process are iterated through, checking their running status. If a thread's running status is abnormal, the health status detection fails, and the process exits. Finally, the average CPU utilization is calculated. If the average CPU utilization exceeds a set threshold, the health status detection fails, and the process exits. The health status check has been completed and the process has ended normally.

[0178] Optionally, the module function verification process can be modified, as shown in Figure 5, including:

[0179] Step S502: Parse the modified module verification configuration file;

[0180] Step S504: Traverse the verification modules;

[0181] Step S506: Determine whether the current verification module is set to enable verification;

[0182] Step S508: With verification enabled, iterate through all the check items of the module;

[0183] Step S510: Extract the interface and parameters;

[0184] Step S512: Execute the API request and obtain the response;

[0185] Step S514: Verify whether the response matches the expected return from the module interface;

[0186] Step S516: If the verification matches, determine that the function verification of the modified module has passed;

[0187] Step S518: If the verification fails, determine that the function verification of the modified module has failed.

[0188] If the current verification module is not set to enable verification, the system will return to the next verification module for judgment.

[0189] Understandably, the process involves parsing the configuration file, iterating through the validation modules, traversing all check items within each module, extracting the interfaces and parameters from the configuration, executing the API request function, and returning the request response. The validation response is then compared to the expected return value of the module interface in the configuration. If the validation does not match, the validation fails, and the process exits directly. Once all modified module functionalities have been validated, the process terminates normally.

[0190] According to the embodiments provided in this application, externally triggered BMC upgrades only require upgrading the backup partition and activating the boot backup partition. The newly booted system will automatically update the backup partition based on the BMC health status, the modified functional modules, and the differences in firmware content.

[0191] Silent upgrades to older firmware versions are performed on a backup partition to ensure uninterrupted service and save upgrade time. After the upgrade, a health check is performed to verify the reliability of the new firmware and ensure system stability during operation. All modified functional modules in the new firmware are fully verified, including added, deleted, and modified functions, to enhance the security of firmware upgrades.

[0192] Upgrading via a backup partition ensures the primary partition remains available throughout the upgrade process, preventing system downtime and improving service continuity. Silently upgrading older firmware to the latest version reduces overall upgrade time and improves management efficiency. Automatic updates ensure firmware version consistency between the primary and backup partitions, preventing potential problems caused by version incompatibility. If problems arise during the upgrade process, disabling automatic updates effectively prevents system failures due to upgrade failures, ensuring system security.

[0193] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM (Read-Only Memory) / RAM (Random Access Memory), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0194] This embodiment also provides a firmware upgrade device, which is configured to implement the above embodiments and optional implementations, and will not be repeated for details already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0195] Figure 6 is a structural block diagram of a firmware upgrade device according to an embodiment of this application. As shown in Figure 6, the device includes:

[0196] The first upgrade unit 602 is configured to perform a first firmware upgrade operation on the backup partition of the baseboard management controller, wherein the baseboard management controller includes a primary partition and a backup partition.

[0197] The verification unit 604 is configured to perform a first upgrade verification on the upgraded backup partition after the first firmware upgrade operation is completed. The first upgrade verification is used to verify whether the upgrade result of the backup partition meets the expected conditions of the firmware upgrade.

[0198] The switching unit 606 is configured to perform a primary / backup switching operation on the primary partition and the upgraded backup partition when the upgrade result meets the expected conditions of the firmware upgrade. The primary / backup switching operation is used to indicate that the primary partition is set as the new backup partition and the upgraded backup partition is set as the new primary partition.

[0199] The second upgrade unit 608 is configured to perform a second firmware upgrade operation on the new spare partition.

[0200] As an optional solution, the verification unit 604 includes:

[0201] The first verification module is configured to perform a first verification on the upgraded backup partition, wherein the first verification is used to verify whether the basic state of the upgraded backup partition meets the first expected condition.

[0202] The second verification module is configured to perform a second verification on the upgraded backup partition when the basic state meets the first expected condition. The second verification is used to verify whether the upgrade module of the upgraded backup partition meets the second expected condition.

[0203] The determination module is set to determine whether the upgrade result meets the firmware upgrade expectation conditions if the upgrade module meets the second expectation conditions.

[0204] As an optional solution, the first verification module includes:

[0205] The first acquisition submodule is set to acquire the partition configuration file list of the upgraded spare partition, wherein the partition configuration file list is used to indicate the setting information of the configuration files in the upgraded spare partition;

[0206] The first determination submodule is configured to determine if the basic state of the upgraded standby partition does not meet the first expected condition in the event of an error in the number of configuration files or if the configuration information does not meet the expected configuration conditions.

[0207] As an optional solution, the device also includes:

[0208] The second acquisition submodule is configured to acquire the running logs of the upgraded backup partition after acquiring the list of partition configuration files of the upgraded backup partition, provided that the number of configuration files is correct and the setting information meets the expected configuration conditions.

[0209] The inspection submodule is configured to check the records in the runtime log that are in the first detection time period after obtaining the list of partition configuration files for the upgraded spare partition;

[0210] The second determining submodule is configured to determine that the basic state of the upgraded backup partition does not meet the first expected condition if there is an abnormal restart record in the records of the first detection time period after obtaining the partition configuration file list of the upgraded backup partition.

[0211] As an optional solution, the device also includes:

[0212] The third acquisition submodule is configured to, after checking the records in the operation log that are in the first detection time period, and if there are no abnormal restart records in the records of the first detection time period, acquire the service running status of each service in the upgraded backup partition, and acquire the thread running status of each thread associated with each service.

[0213] The third determination submodule is configured to, after checking the records in the operation log that are in the first detection time period, determine that the basic state of the upgraded backup partition does not meet the first expected condition if the service operation state does not meet the expected service conditions or the thread operation state does not meet the expected thread conditions.

[0214] As an optional solution, the device also includes:

[0215] The fourth acquisition submodule is configured to, after acquiring the service running status of each service in the upgraded backup partition, acquire the average CPU utilization of the upgraded backup partition in the second detection period, provided that the service running status meets the expected service conditions and the thread running status meets the expected thread conditions.

[0216] The fourth determination submodule is configured to determine that the basic state of the upgraded backup partition does not meet the first expected condition if the average utilization of the central processing unit is greater than a preset threshold after obtaining the service running status of each service in the upgraded backup partition.

[0217] The fifth determination submodule is configured to determine, after obtaining the service running status of each service in the upgraded backup partition, that the basic status of the upgraded backup partition meets the first expected condition if the average utilization of the central processing unit is less than or equal to a preset threshold.

[0218] As an optional solution, the second verification module includes:

[0219] The parsing submodule is configured to parse the configuration file associated with the first firmware upgrade to obtain the configuration information of the upgrade module. The configuration file is used to store the module information to be upgraded in the first firmware upgrade operation.

[0220] The inspection submodule is configured to read configuration information and perform module checks on at least one module in the upgrade module, wherein at least one module is a module in the upgrade module whose verification item is set to enabled.

[0221] As an optional approach, check the submodules, including:

[0222] Extract submodules, which are configured to extract the interface name and request parameters of each check item of at least one module from the configuration information;

[0223] The execution submodule is configured to execute an API request triggered by at least one module using an interface name and request parameters, wherein the API request is used to obtain a first response value from at least one module.

[0224] The sixth determining submodule is configured to determine whether the upgrade module meets the second expected condition based on the comparison result between the first response value and the second response value indicated in the configuration information.

[0225] As an optional solution, the sixth determination submodule includes:

[0226] The seventh determining submodule is configured to determine that the upgrade module meets the second expected condition if the first response value and the second response value are consistent.

[0227] The eighth determination submodule is configured to determine that the upgrade module does not meet the second expected condition if the first response value and the second response value are inconsistent.

[0228] As an optional approach, the submodules are inspected, including at least one of the following:

[0229] The first inspection submodule is configured to perform a module inspection on a first module included in at least one module, wherein the first module is a newly added module in the upgrade module;

[0230] The second inspection submodule is configured to perform a module inspection on a second module included in at least one module, wherein the second module is a module deleted from the upgrade module;

[0231] The third inspection submodule is configured to perform a module inspection on at least one third module included in the module, wherein the third module is a module modified in the upgrade module.

[0232] As an optional solution, the device also includes:

[0233] The third verification module is configured to perform a second upgrade verification on the new backup partition after the second firmware upgrade operation is performed and after the second firmware upgrade operation is completed. The second upgrade verification is used to verify whether the upgrade result of the new backup partition meets the expected conditions of the firmware upgrade.

[0234] As an optional solution, the primary partition functions normally during the first firmware upgrade operation;

[0235] The new primary partition functioned normally during the second firmware upgrade operation.

[0236] As an optional solution, the first upgrade unit 602 includes:

[0237] The upload module is configured to upload the first firmware to the backup partition, wherein the first firmware is used to perform a first firmware upgrade operation on the backup partition;

[0238] The device also includes:

[0239] The burning module is configured to burn the first firmware to the backup partition before performing a primary / backup switch operation on the primary partition and the upgraded backup partition, provided that the upgrade result meets the expected conditions for firmware upgrade, and to determine the backup partition after burning as the upgraded backup partition.

[0240] As an optional solution, the switching unit 606 includes:

[0241] The configuration module is configured to configure the bootloader, wherein the bootloader is used to instruct the baseboard management controller to load and run from the new primary partition after a reboot;

[0242] The restart module is configured to restart the baseboard management controller.

[0243] As an optional solution, the device also includes:

[0244] The reporting module is configured to report an alarm message indicating the failure of the first firmware upgrade operation if the upgrade result does not meet the expected conditions of the firmware upgrade after the upgrade verification of the upgraded backup partition, and to revert the firmware version of the upgraded backup partition to the state before the first firmware upgrade operation.

[0245] As an alternative, if the upgrade result does not meet the expected conditions for the firmware upgrade, one of the following situations may occur:

[0246] The upgraded backup partition's basic condition does not meet the initial expected conditions;

[0247] The upgraded module for the backup partition does not meet the second expected condition.

[0248] The examples in this embodiment can be referred to the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0249] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0250] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0251] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0252] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0253] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0254] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0255] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium storing the computer program product, wherein the computer program, when executed by a processor, implements the steps of the methods in various embodiments of this application.

[0256] The examples in this embodiment can be referred to the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0257] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular hardware and software combination.

[0258] The above are merely optional embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A firmware upgrade method, characterized in that, include: A first firmware upgrade operation is performed on the spare partition of the baseboard management controller, wherein the baseboard management controller includes a primary partition and the spare partition; When the first firmware upgrade operation is completed, a first upgrade verification is performed on the upgraded backup partition, wherein the first upgrade verification is used to verify whether the upgrade result of the backup partition meets the expected conditions of firmware upgrade. If the upgrade result meets the expected conditions of the firmware upgrade, a primary / backup switch operation is performed on the primary partition and the upgraded backup partition, wherein the primary / backup switch operation is used to indicate that the primary partition is set as the new backup partition and the upgraded backup partition is set as the new primary partition; Perform a second firmware upgrade operation on the new spare partition.

2. The method according to claim 1, characterized in that, The verification of the upgraded backup partition includes: A first verification is performed on the upgraded backup partition, wherein the first verification is used to verify whether the basic state of the upgraded backup partition meets the first expected condition. If the basic state meets the first expected condition, a second verification is performed on the upgraded backup partition, wherein the second verification is used to verify whether the upgrade module of the upgraded backup partition meets the second expected condition. If the upgrade module meets the second expected condition, the upgrade result is determined to meet the firmware upgrade expected condition.

3. The method according to claim 2, characterized in that, The first verification of the upgraded backup partition includes: Obtain the partition configuration file list of the upgraded spare partition, wherein the partition configuration file list is used to indicate the setting information of the configuration files in the upgraded spare partition; If the number of configuration files is incorrect or the setting information does not meet the expected configuration conditions, it is determined that the basic state of the upgraded backup partition does not meet the first expected conditions.

4. The method according to claim 3, characterized in that, After obtaining the list of partition configuration files for the upgraded spare partition, the method further includes: If the number of configuration files is correct and the setting information meets the expected configuration conditions, obtain the running log of the upgraded spare partition; The records in the operation log that fall within the first detection time period are checked; If there are abnormal restart records in the records of the first detection time period, it is determined that the basic state of the upgraded backup partition does not meet the first expected conditions.

5. The method according to claim 4, characterized in that, After checking the records in the operation log that fall within the first detection time period, the method further includes: If there is no abnormal restart record in the records of the first detection time period, obtain the service running status of each service in the upgraded backup partition, and obtain the thread running status of each thread associated with each service; If the service running status does not meet the expected service conditions or the thread running status does not meet the expected thread conditions, it is determined that the basic status of the upgraded backup partition does not meet the first expected conditions.

6. The method according to claim 5, characterized in that, After obtaining the service running status of each service in the upgraded spare partition, the method further includes: If the service running status meets the expected service conditions and the thread running status meets the expected thread conditions, obtain the average CPU utilization of the upgraded spare partition during the second detection period. If the average utilization of the central processing unit is greater than a preset threshold, it is determined that the basic state of the upgraded spare partition does not meet the first expected condition. If the average utilization rate of the central processing unit is less than or equal to the preset threshold, it is determined that the basic state of the upgraded spare partition meets the first expected condition.

7. The method according to claim 2, characterized in that, The second verification of the upgraded spare partition includes: The configuration file associated with the first firmware upgrade is parsed to obtain the configuration information of the upgrade module, wherein the configuration file is used to store the module information upgraded in the first firmware upgrade operation; The configuration information is read, and at least one module in the upgrade module is checked, wherein the at least one module is a module in the upgrade module whose verification item is set to the enabled state.

8. The method according to claim 7, characterized in that, The module check of at least one module in the upgrade module includes: Extract the interface name and request parameters of each inspection item of the at least one module from the configuration information; Using the interface name and the request parameters, execute an application interface request triggered on the at least one module, wherein the application interface request is used to obtain a first response value from the at least one module; Based on the comparison result between the first response value and the second response value indicated in the configuration information, it is determined whether the upgrade module meets the second expected condition.

9. The method according to claim 8, characterized in that, The step of determining whether the upgrade module meets the second expected condition based on the comparison result between the first response value and the second response value indicated in the configuration information includes: If the first response value and the second response value are consistent, it is determined that the upgrade module meets the second expected condition; If the first response value and the second response value are inconsistent, it is determined that the upgrade module does not meet the second expected condition.

10. The method according to claim 7, characterized in that, The module check performed on at least one of the upgrade modules includes at least one of the following: A module check is performed on the first module included in the at least one module, wherein the first module is a newly added module in the upgrade module; A module check is performed on the second module included in the at least one module, wherein the second module is the module deleted from the upgrade module; A module check is performed on a third module included in the at least one module, wherein the third module is a modified module in the upgrade module.

11. The method according to any one of claims 1 to 10, characterized in that, After performing the second firmware upgrade operation on the new spare partition, the method further includes: Upon completion of the second firmware upgrade operation, a second upgrade verification is performed on the new backup partition after the upgrade. The second upgrade verification is used to verify whether the upgrade result of the new backup partition after the upgrade meets the expected conditions of the firmware upgrade.

12. The method according to any one of claims 1 to 10, characterized in that, The method further includes: The primary partition operates normally during the first firmware upgrade operation; During the second firmware upgrade operation, the new primary partition functions normally.

13. The method according to any one of claims 1 to 10, characterized in that, The first firmware upgrade operation performed on the spare partition of the baseboard management controller includes: The first firmware is uploaded to the backup partition, wherein the first firmware is used to perform the first firmware upgrade operation on the backup partition; Before performing the primary / standby switchover operation on the primary partition and the upgraded standby partition, the method further includes: If the upgrade result meets the expected conditions for firmware upgrade, the first firmware is burned to the spare partition, and the spare partition after burning is determined as the upgraded spare partition.

14. The method according to any one of claims 1 to 10, characterized in that, The master / slave switchover operation for the primary partition and the upgraded backup partition includes: A bootloader is configured to instruct the baseboard management controller to load and run from the new primary partition after a reboot; Restart the baseboard management controller.

15. The method according to any one of claims 1 to 10, characterized in that, After performing upgrade verification on the upgraded backup partition, the method further includes: If the upgrade result does not meet the expected conditions for the firmware upgrade, an alarm message indicating that the first firmware upgrade operation has failed is reported, and the firmware version of the upgraded backup partition is rolled back to the state before the first firmware upgrade operation.

16. The method according to claim 15, characterized in that, The upgrade result does not meet the expected conditions for the firmware upgrade, including one of the following: The basic state of the upgraded backup partition does not meet the first expected condition; The upgraded module of the upgraded backup partition does not meet the second expected condition.

17. A firmware upgrade device, characterized in that, include: The first upgrade unit is configured to perform a first firmware upgrade operation on the spare partition of the baseboard management controller, wherein the baseboard management controller includes a primary partition and the spare partition; The verification unit is configured to perform a first upgrade verification on the upgraded backup partition after the first firmware upgrade operation is completed, wherein the first upgrade verification is used to verify whether the upgrade result of the backup partition meets the expected conditions of firmware upgrade. The switching unit is configured to perform a primary / backup switching operation on the primary partition and the upgraded backup partition when the upgrade result meets the expected conditions of the firmware upgrade. The primary / backup switching operation is used to indicate setting the primary partition as the new backup partition and the upgraded backup partition as the new primary partition. The second upgrade unit is configured to perform a second firmware upgrade operation on the new spare partition.

18. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 16.

19. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 16.

20. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 16.

Images