Method and system for hot updating server firmware, and server

Abstract

This application proposes a method, system, and server for hot-updating server firmware, relating to the field of server maintenance. When applied to a BMC (Browser Control Center), the method includes: receiving a remote update command carrying target configuration data; responding to the remote update command, writing the target configuration data to a target non-volatile memory area associated with the MCP (Machine Processor) and decoupled from the BIOS mirror storage area; sending a reset command to the SCP (Processor Controller), which instructs the SCP to perform an independent reset on the MCP, which has an independent power domain, after detecting that the target configuration data has been written, so that the MCP restarts, loads the target configuration data from the target non-volatile memory area, and updates the firmware layer logic of the underlying hardware of the server system; and obtaining update status information returned by the MCP through an inter-processor communication channel. This solution can adjust the server's firmware configuration data or fix firmware layer security vulnerabilities without restarting the main server system.

Description

Technical Field

[0001] This application relates to the field of server maintenance, and more specifically, to a method, system, and server for hot-updating server firmware. Background Technology

[0002] Server firmware is the underlying software embedded in the server hardware, responsible for system initialization and hardware configuration. The Basic Input Output System (BIOS) is its core component. In ARM-based server systems, the BIOS not only handles system startup but also integrates configuration logic for underlying hardware parameters such as reliability, availability, and serviceability (RAS) policies and power management thresholds.

[0003] Currently, ARM architecture servers primarily use a method of storing the entire BIOS image in a dedicated flash memory area. This BIOS image is a single binary file containing firmware code, configuration data, and patch logic. When maintenance personnel need to adjust firmware configuration data such as server RAS fault handling policies, power management thresholds, or fix firmware-level security vulnerabilities, the existing solutions can only achieve this through two methods: First, by restarting the server to enter the BIOS settings interface, manually modifying the configuration parameters, and restarting again for the changes to take effect; second, by downloading a new BIOS image, flashing the entire firmware through the Baseboard Management Controller (BMC) or local tools, and performing a complete System-on-Chip (SoC) reset. Both of these operations force the server to shut down and restart, making it impossible for servers to meet the high availability requirements of data centers. In other words, when firmware configuration data needs to be adjusted or security vulnerabilities need to be fixed, business interruptions must be incurred.

[0004] Therefore, how to adjust firmware configuration data such as RAS fault handling strategies and power management thresholds, or fix firmware-level security vulnerabilities, while meeting the requirements of high availability of servers, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this application is to provide a method, system, and server for hot updating server firmware, which can adjust the firmware configuration data or fix firmware layer security vulnerabilities without restarting the main server system.

[0006] This application is implemented as follows: In a first aspect, this application provides a method for hot-updating server firmware, applied to a Baseboard Management Controller (BMC). The method includes: receiving a remote update instruction, the remote update instruction carrying target configuration data for updating firmware configuration data and / or firmware patch data of a server system; responding to the remote update instruction, writing the target configuration data into a target non-volatile memory area, the target non-volatile memory area being associated with a Management Controller Processor (MCP) and decoupled from a BIOS mirror memory area; sending a reset instruction to a System Controller Processor (SCP), the reset instruction instructing the SCP to perform an independent reset operation on the MCP, which has an independent power domain, after detecting that the target configuration data has been written, so that the MCP, upon restarting, loads the target configuration data from the target non-volatile memory area and updates the firmware layer logic of the underlying hardware of the server system accordingly; and obtaining update status information returned by the MCP through an inter-processor communication channel.

[0007] Secondly, this application provides a hot-update method for server firmware, applied to a Management and Control Processor (MCP). The MCP includes an independent power domain, and its associated target non-volatile memory area is decoupled from the BIOS image memory area of ​​the server system. The method includes: in response to a reset start occurring in its own power domain, loading target configuration data from the target non-volatile memory area to update the firmware layer logic of the underlying hardware of the server system, and returning update status information to the Baseboard Management Controller (BMC) via an inter-processor communication channel after loading is complete. The reset start occurs when the BMC, in response to a received remote update command, writes the target configuration data to the target non-volatile memory area and then sends a reset command to the System Control Processor (SCP) to instruct the SCP to perform an independent reset operation on the MCP after detecting that the target configuration data has been written. The remote update command carries target configuration data for updating firmware configuration data and / or firmware patch data for the server system.

[0008] Thirdly, this application provides a server firmware hot-update system, comprising: a baseboard management controller (BMC) for executing the method as described in any one of the first aspects; a system control processor (SCP) for receiving a reset command sent by the baseboard management controller (BMC) and performing an independent reset operation on the power domain of the management control processor (MCP) in response to the reset command; the management control processor (MCP) having an independent power domain for loading target configuration data from a target non-volatile memory area after reset and updating the firmware layer logic of the underlying hardware of the server system according to the target configuration data; and a non-volatile memory device including a first area for storing a BIOS image and a second area decoupled from the first area and serving as the target non-volatile memory area.

[0009] Fourthly, this application provides a server including a hot update system for server firmware as described in the third aspect.

[0010] Compared with the prior art, this application has at least the following advantages or beneficial effects: This application proposes a hot-update method for server firmware. It separates the modifiable content (i.e., firmware configuration data and / or firmware patch data) originally embedded in the BIOS image from the BIOS image and stores it independently in a target non-volatile memory area associated with the Management Controller (MCP), thereby decoupling the firmware configuration data and / or firmware patch data from the BIOS image. Furthermore, utilizing the MCP with its independent power domain, and with the BMC acting as the control center, upon receiving a remote update command, the target configuration data is written to the aforementioned target non-volatile memory area, subsequently triggering an independent reset of the MCP. Since the MCP reset does not affect the operation of the main system, and after restarting, it can independently load the latest target configuration data from the target non-volatile memory area and directly update the underlying hardware firmware logic, it is possible to adjust the server's firmware configuration data or fix firmware security vulnerabilities without restarting the server's main system. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of an embodiment of a server firmware hot update method according to this application; Figure 2This is a flowchart illustrating the steps of the management control processor (MCP) loading target configuration data from the target non-volatile memory area after a reboot, according to one embodiment of this application. Figure 3 This is a flowchart of yet another embodiment of a server firmware hot update method according to this application; Figure 4 This is a structural block diagram of an embodiment of a server firmware hot update system according to this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0014] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0015] To facilitate understanding of the technical solutions provided in this application, some concepts will be introduced below.

[0016] 1. Baseboard Management Controller (BMC): The Baseboard Management Controller is an independent microcontroller that provides out-of-band management capabilities. In this application, the Baseboard Management Controller (BMC) serves as the hot update control hub, responsible for receiving remote update commands, writing target configuration data to the target non-volatile memory area, triggering a soft reset of the Management Control Processor (MCP) through the System Control Processor (SCP), and polling update status information to complete closed-loop feedback.

[0017] 2. System Control Processor (SCP): This is responsible for distributing platform-level power and reset signals. In this application, after receiving the reset command from the Baseboard Management Controller (BMC), the SCP only performs an independent reset operation on the power domain of the Management Control Processor (MCP), without triggering a reset of the main CPU or memory.

[0018] 3. Management Control Processor (MCP): The Management Control Processor is a logical entity dedicated to thermal management and power control. In this application, the Management Control Processor (MCP) has the following characteristics: First, it has an independent power domain and reset control; second, its associated firmware configuration data and firmware patch data are decoupled from the Basic Input / Output System (BIOS) image.

[0019] 4. Basic Input / Output System (BIOS): This refers to the underlying firmware executed during the main processor's boot process, including the Unified and Extensible Firmware Interface (UEFI). In this application, the BIOS specifically refers to the main firmware image stored in the BIOS partition in flash memory, excluding the configuration parameters and hot-patching logic of the Management and Control Processor (MCP).

[0020] In existing ARM architecture servers, the BIOS compiles configuration options and executable code into a single image. When it's necessary to modify options such as RAS policies, power thresholds, or fix firmware-level security vulnerabilities, there are only two ways to achieve this: one is to reboot into the BIOS setup interface, manually adjust the parameters, and reboot again for the changes to take effect; the other is to download a new BIOS image, flash it, and perform a complete system-level chip reset. Both of these operations force the server to shut down and restart.

[0021] In developing this application, the inventors discovered that the fundamental reason why existing ARM architecture servers must shut down and restart when adjusting firmware configuration data or fixing firmware-level security vulnerabilities is that the BIOS image bundles firmware code, configuration data, and patch logic into a single binary file for storage. Furthermore, all configuration modifications and vulnerability fixes require replacing the entire BIOS image or entering the BIOS settings interface, both of which inevitably involve resetting the main system-on-a-chip (SoC). Specifically, although some platforms support remote management by the Baseboard Management Controller (BMC), the BMC cannot directly modify BIOS behavior because the BIOS code and configuration are tightly coupled to the main Central Processing Unit (CPU) boot process and lack an independent operating domain.

[0022] Therefore, the existing solution, which requires server shutdown and restart, has the following drawbacks: First, any BIOS configuration change or version upgrade forces a system restart, causing interruptions to databases, virtual machines, and other services. Large data centers need to coordinate downtime windows, making it difficult to meet the "99.999% availability" Service Level Agreement (SLA) requirements for telecom-grade systems. Second, when new firmware vulnerabilities (such as the ARM architecture anomaly level 3 privilege escalation vulnerability) are disclosed, the existing solution cannot patch them at runtime. Even if the vulnerability only affects the management control processor (MCP) related functions, the entire BIOS must be upgraded during the maintenance window, leaving the system continuously exposed to attack risks. Third, the BIOS tightly couples configuration and code into a single image. Even if only a temperature threshold is modified, the entire firmware must be replaced, resulting in coarse-grained updates, high risks, and complex rollbacks.

[0023] Based on this, this application proposes a decoupled hot update mechanism based on the Baseboard Management Controller (BMC) driver. The core idea of ​​this mechanism is to separate the modifiable content (i.e., firmware configuration data and / or firmware patch data) originally embedded in the BIOS image from the BIOS image and store it independently in a target non-volatile memory area associated with the Management Controller Processor (MCP), thereby decoupling the configuration / patch from the BIOS image. Furthermore, utilizing the Management Controller Processor (MCP) with its independent power domain, and with the Baseboard Management Controller (BMC) acting as the control center, upon receiving a remote update command, the target configuration data is written to the aforementioned target non-volatile memory area, subsequently triggering an independent reset of the Management Controller Processor (MCP). Since the reset of the Management Controller Processor (MCP) does not affect the operation of the main system, and after restarting, it can independently load the latest target configuration data from the target non-volatile memory area and directly update the firmware layer logic of the underlying hardware, hot adjustment of firmware configuration and hot patching of firmware vulnerabilities are achieved without restarting the server's main system.

[0024] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings. Unless otherwise specified, the various embodiments and features described below can be combined with each other.

[0025] Please see Figure 1 The server firmware hot update method is applied to the baseboard management controller (BMC), and the method includes: Step S101: Receive a remote update instruction, the remote update instruction carrying target configuration data for updating firmware configuration data and / or firmware patch data of the server system.

[0026] In step S101, the Baseboard Management Controller (BMC) first receives an update instruction from the remote operation and maintenance platform, providing a data source and triggering basis for subsequent operations. This remote update instruction carries the target configuration data required for this update, which takes two forms: firmware configuration data for adjusting server operating parameters, and / or firmware patch data for fixing security vulnerabilities. For example, the firmware configuration data may include BIOS-configurable operating parameters such as reliability, availability, and serviceability (RAS) policies (e.g., error correction and fault isolation policies), power management thresholds (e.g., over-temperature protection thresholds, voltage regulation thresholds), secure boot options, processor core count configuration, and memory frequency settings.

[0027] Step S102: In response to the remote update command, the target configuration data is written to the target non-volatile storage area, which is associated with the management control processor MCP and decoupled from the BIOS mirror storage area.

[0028] It should be noted that the aforementioned target non-volatile memory area has two key characteristics: firstly, it is associated with the Management Controller Processor (MCP), meaning this target non-volatile memory area is specifically prepared for the MCP for its subsequent access and loading; secondly, this target non-volatile memory area is physically or logically completely decoupled from the Basic Input / Output System (BIOS) image storage area (exemplarily physically isolated, logically separated, or address space separated), and independent of each other. Therefore, the Baseboard Management Controller (BMC), in response to the aforementioned remote update command, writes the target configuration data to a specific target non-volatile memory area, effectively separating the variable content originally embedded in the BIOS image, achieving decoupled storage of firmware configuration data and firmware patch data from the BIOS image. In other words, it performs an atomic replacement of the original firmware configuration data and firmware patch data without modifying the main system's BIOS image itself. As a result, subsequent firmware updates no longer require modification or replacement of the large BIOS image, thus avoiding the resulting need for a main system reset.

[0029] Step S103: Send a reset command to the system control processor SCP. The reset command is used to instruct the system control processor SCP to perform an independent reset operation on the management control processor MCP with an independent power domain after detecting that the target configuration data has been written. This is to enable the management control processor MCP to load the target configuration data from the target non-volatile storage area after restarting, and update the firmware layer logic of the underlying hardware of the server system accordingly.

[0030] It should be noted that step S103 above, through the independent reset design of the Management and Control Processor (MCP), transforms the firmware update operation, which originally required a complete system shutdown, into an operation that is imperceptible to the main system. Because the MCP is designed with an independent power domain, the independent reset operation of the MCP is strictly limited to the MCP itself, completely unaffected by the continuous operation of the main CPU or the business continuity carried on it. After restarting, the MCP automatically loads the latest written target configuration data from its associated target non-volatile storage area and updates the firmware layer logic of the underlying hardware in the server system in real time based on this data, such as adjusting the control policy of the Power Processing Unit (PPU) or applying security patches.

[0031] For example, the Baseboard Management Controller (BMC) can send a reset command to the System Control Processor (SCP) via a hardware channel (e.g., SMLink or I²C). SMLink stands for System Management Link, and I²C stands for Inter-Integrated Circuit, a two-wire serial communication protocol. Additionally, this underlying hardware typically includes at least one of the following: a Power Processing Unit (PPU), system sensors, a clock generator, a voltage regulator module, and a fan control unit.

[0032] Step S104: Obtain the updated status information returned by the management control processor MCP through the inter-processor communication channel.

[0033] It should be noted that after the Management Control Processor (MCP) loads the corresponding target configuration data via a reboot, it will send corresponding update status information to the Baseboard Management Controller (BMC) through a dedicated inter-processor communication channel (such as Mailbox, email, or message passing mechanism). This update status information clearly indicates whether the hot update operation was successfully completed or encountered an error. This allows maintenance personnel to monitor the server's firmware status in real time, ensuring the reliability and traceability of the entire update process. Specifically, when the inter-processor communication channel is Mailbox, after the MCP completes initialization, it writes the update status information to the Mailbox area in shared memory and triggers an interrupt notification to the BMC. The BMC then polls the Mailbox area to obtain the update status information, thus forming a closed-loop feedback. Notably, this Mailbox area can be located in the platform's shared SRAM (Static Random Access Memory), has ECC protection (Error Correction Code Protection), and can coexist with the SCMI protocol (System Control and Management Interface Protocol) but is physically isolated (SCMI is used for command issuance, and Mailbox is used for asynchronous status reporting).

[0034] In summary, the technical solution of this application achieves decoupling of firmware configuration data and / or firmware patch data from the BIOS image by writing the target configuration data to a target non-volatile memory area associated with the management control processor MCP and decoupled from the basic input / output system BIOS image storage area. Based on this, utilizing the management control processor MCP with its independent power domain, the baseboard management controller BMC triggers the system control processor SCP to perform an independent reset operation on the management control processor MCP after the target configuration data is written. This allows the management control processor MCP to independently load the target configuration data and update the firmware layer logic of the underlying hardware after restarting.

[0035] Because the target configuration data is decoupled from the BIOS image storage area, updates do not require modification or replacement of the BIOS image itself, avoiding the main system-on-a-chip (SoC) reset required in traditional solutions. Simultaneously, the management and control processor (MCP) has an independent power domain, and its reset process is completely independent of the main CPU. Running databases, virtual machines, and other services remain unaffected, thus meeting the stringent high availability requirements of data centers. In other words, since the target configuration data is stored independently of the BIOS image, firmware configuration data and firmware patch data can be updated as independent units, eliminating the need to replace the entire BIOS image even for a change in a temperature threshold, as is common in traditional solutions. This fine-grained update approach reduces operational risks and provides a foundation for subsequent version management and differentiated maintenance. For example, in the event of an urgent security vulnerability, firmware patches can be deployed remotely and quickly, significantly shortening the system's exposure time and aligning with the defense-in-depth security principle.

[0036] Based on the aforementioned scheme, in some implementations of this application, the step of writing the target configuration data into the target non-volatile storage area includes: writing the target configuration data into the target non-volatile storage area, and setting a pending status flag in a predetermined status register of the shared storage area after the writing is completed. The reset instruction is further used to instruct the system control processor SCP to perform an independent reset operation on the power domain of the management control processor MCP when it detects that the pending status flag has been set and the verification of the target configuration data is valid.

[0037] Understandably, the above implementation, by introducing a pending status flag and a verification mechanism, adds an acknowledgment step to the writing of target configuration data and the reset triggering of the management control processor (MCP). This effectively avoids erroneous resets caused by incomplete or corrupted target configuration data, ensuring that the target configuration data loaded by the MCP at each reset and startup is complete and valid. This further ensures the reliability of the hot update process.

[0038] Specifically, in practical applications, after the Baseboard Management Controller (BMC) writes the target configuration data to the target non-volatile memory area, it does not immediately trigger subsequent actions. Instead, it first sets a pending status flag in the predetermined status register of the shared memory area, essentially leaving a "data ready" marker. Subsequently, when the Baseboard Management Controller (BMC) sends a reset command to the System Control Processor (SCP), the SCP performs a double check before executing the reset operation: firstly, it checks whether the pending status flag in the predetermined status register has been set; secondly, it verifies the validity of the written target configuration data. Only when the pending status flag exists and the data verification is valid will the SCP perform an independent reset operation on the power domain of the Management Control Processor (MCP).

[0039] Based on the aforementioned scheme, in some implementations of this application, the target non-volatile storage area includes a first storage partition and a second storage partition. The step of writing the target configuration data into the target non-volatile storage area includes: writing the target configuration data into the first storage partition, while retaining the historical configuration data stored in the second storage partition.

[0040] In the above implementation, by dividing the target non-volatile storage area into two storage partitions, a data foundation is provided for possible rollback operations. If a problem occurs during the loading or application of newly written target configuration data, the Management Control Processor (MCP) can read historical configuration data from the second storage partition for recovery at any time. This avoids the server firmware layer from malfunctioning due to abnormal new data, thereby improving the fault tolerance and reliability of hot update operations.

[0041] Based on the aforementioned scheme, in some implementations of this application, the step of loading target configuration data from the target non-volatile storage area after the management control processor (MCP) restarts includes: if the management control processor (MCP) fails to load the target configuration data, or fails to verify the digital signature carried by the target configuration data, or if the firmware layer logic of the underlying hardware of the server system is abnormal when updating the target configuration data, historical configuration data is loaded from the second storage partition, and the firmware layer logic of the underlying hardware is restored to the historical state.

[0042] In the above implementation, when the Management Control Processor (MCP) loads the target configuration data from the target non-volatile storage area after restarting, it undergoes multiple checks. If the MCP fails to load the data, finds the digital signature carried by the target configuration data to be invalid during verification, or encounters an execution exception when updating the firmware layer logic of the underlying hardware based on the target configuration data despite successful loading and verification, the MCP will immediately initiate a rollback process if any of these exceptions are triggered. At this point, the MCP will no longer use the newly written target configuration data but will instead load previously retained historical configuration data from the second storage partition, thereby restoring the firmware layer logic of the underlying hardware to its pre-update state. This avoids the risk of server firmware layer failure due to update failure, further improving the reliability of hot updates.

[0043] Based on the aforementioned scheme, in some implementations of this application, the target configuration data carries a digital signature and version metadata, wherein the version metadata includes version information of the firmware patch data. See also... Figure 2 When the Management and Control Processor (MCP) loads target configuration data from the target non-volatile storage area after a reboot, the process includes: the MCP verifying the validity of the digital signature and reading the current BIOS version information written by the BIOS firmware in the shared storage area; loading and applying the target configuration data only when the digital signature is valid and the current BIOS version information is lower than the version information of the firmware patch data; otherwise, the loading of the target configuration data is aborted and the current legacy firmware configuration is executed.

[0044] Understandably, the above implementation method, by introducing digital signature verification and version comparison mechanisms, enables the Management and Control Processor (MCP) to determine whether firmware patch data needs to be loaded, thereby avoiding functional overlap with the Basic Input / Output System (BIOS).

[0045] Specifically, in practical applications, when the Management and Control Processor (MCP) loads target configuration data from the target non-volatile memory area after a reboot, it first verifies the validity of the digital signature carried by the target configuration data to ensure that the data source is trustworthy and has not been tampered with. After successful verification, the MCP reads the current BIOS version information pre-written by the BIOS firmware in the shared memory area and compares it with the version information of the firmware patch data carried in the target configuration data. Only when the digital signature is valid and the current BIOS version is lower than the firmware patch version is it considered that the BIOS has not yet included the patch's fix content. In this case, the MCP loads and applies the target configuration data. Otherwise, if the digital signature is invalid, or the current BIOS version has reached or exceeded the firmware patch version, it indicates that the BIOS itself has the corresponding repair capabilities, and the MCP will abort loading and continue executing the current old firmware configuration.

[0046] Based on the aforementioned scheme, in some implementations of this application, the target non-volatile storage area includes a decoupled third storage partition and a fourth storage partition. The step of writing the target configuration data into the target non-volatile storage area includes: writing the firmware configuration data into the third storage partition and writing the firmware patch data into the fourth storage partition.

[0047] Understandably, the above implementation isolates and categorizes firmware configuration data and firmware patch data, allowing for independent updates and management of these two data types. When only operational parameters need adjustment, only the contents of the third storage partition need updating, without affecting the fourth. Conversely, when only security vulnerabilities need fixing, only the fourth storage partition needs to be operated on. This fine-grained partition management avoids mutual interference between different types of data, reduces the complexity and risk of update operations, and provides more flexible support for subsequent version management and differential rollback.

[0048] Based on the aforementioned solution, this application also proposes a hot update method for server firmware, applied to a Management and Control Processor (MCP). The MCP includes an independent power domain, and its associated target non-volatile memory area is decoupled from the BIOS image memory area of ​​the server system. The method includes: in response to a reset start occurring in its own power domain, loading target configuration data from the target non-volatile memory area to update the firmware layer logic of the underlying hardware of the server system, and returning update status information to the Baseboard Management Controller (BMC) via an inter-processor communication channel after loading is complete. The reset start occurs when the Baseboard Management Controller (BMC), in response to a received remote update command, writes the target configuration data to the target non-volatile memory area and then sends a reset command to the System Control Processor (SCP) to instruct the SCP to perform an independent reset operation on the MCP after detecting that the target configuration data has been written. The remote update command carries target configuration data for updating the firmware configuration data and / or firmware patch data of the server system.

[0049] It is understood that this application also describes the hot update process of server firmware from the perspective of the management control processor (MCP). This process is based on the same inventive concept as the aforementioned hot update method with the baseboard management controller (BMC) as the execution entity, and the two cooperate to complete the uninterrupted maintenance of the firmware layer. The specific implementation of the management control processor (MCP) loading the target configuration data from the target non-volatile memory area and updating the underlying hardware firmware layer logic after independent reset can be referred to the corresponding description in the aforementioned method embodiment applied to the baseboard management controller (BMC), and will not be repeated here.

[0050] To enable those skilled in the art to more intuitively understand this application, a specific example will be provided below. This example will be exemplified by combining the overall technical paradigm of this application with some optional implementation details. It should be noted that the following illustration is intended to aid understanding and does not constitute an exhaustive list of all embodiments of this application, nor does it imply that this application must include all the details described below in its specific implementation.

[0051] Please see Figure 3 Suppose that the operation and maintenance platform needs to perform firmware layer maintenance on a running ARM architecture server. When applying the hot update method of this application, the specific process can be as follows: First, an update is triggered. The Baseboard Management Controller (BMC) receives a remote update command from the remote maintenance platform. This command carries the target configuration data, either firmware configuration data or firmware patch data. The BMC writes the target configuration data to the target non-volatile storage area, which specifically includes the MCP_CONFIG partition (third storage partition) and the MCP_PATCH partition (fourth storage partition). Simultaneously, a digital signature and version metadata are attached to the target configuration data. This version metadata includes version information for the firmware patch data.

[0052] Secondly, state synchronization and atomicity are guaranteed. After the Baseboard Management Controller (BMC) completes the write operation, it writes a "PENDING" status to the MCP_UPDATE_STATE register in the shared memory area, i.e., it writes a pending status flag to a predetermined status register in the shared memory area. The System Control Processor (SCP) polls this predetermined status register and only responds to subsequent reset commands sent by the Baseboard Management Controller (BMC) if it detects that the pending status flag is set (i.e., the status is "PENDING") and the checksum of the target configuration data is valid. This mechanism ensures that the operation from data write completion to reset triggering is atomic, avoiding configuration inconsistencies caused by the Management Control Processor (MCP) restarting in an intermediate state.

[0053] Next, the Management Control Processor (MCP) is restarted. In response to the reset command, the System Control Processor (SCP) only disconnects the power domain of the MCP and then re-energizes it; the main CPU continues to run, and services are unaffected.

[0054] Subsequently, the Management and Control Processor (MCP) is initialized. After restarting, the MCP loads the target configuration data from the target non-volatile memory area and verifies the validity of the digital signature. Simultaneously, the MCP reads the current BIOS version information written by the BIOS firmware in the shared memory area and compares it with the version information of the firmware patch data carried in the target configuration data. Only if the digital signature is valid and the current BIOS version is lower than the firmware patch data version, the MCP loads and applies the target configuration data to update the underlying hardware's firmware layer logic; otherwise, the MCP aborts loading the target configuration data and continues executing the current legacy firmware configuration.

[0055] Specifically, it also includes a rollback mechanism. The Management and Control Processor (MCP) employs a dual-buffered storage strategy, writing new patches to the working area (first storage partition) and retaining older versions in the backup area (second storage partition). If the MCP fails to load the target configuration data, fails to verify the digital signature carried by the target configuration data, or encounters a hardware initialization exception when updating based on the target configuration data, the MCP automatically loads historical configuration data from the backup area and restores the firmware layer logic of the underlying hardware to the historical state, while simultaneously setting the status register to the rollback complete state.

[0056] Finally, feedback is provided. The Management Control Processor (MCP) returns an update success status or rollback completion status to the Baseboard Management Controller (BMC) via an inter-processor communication channel (e.g., Mailbox). After the Baseboard Management Controller (BMC) polls this channel to obtain the status, it updates the display on the operations and maintenance platform. If a rollback is detected, an alarm is triggered and an audit log is recorded.

[0057] It should be noted that the Management and Control Processor (MCP) in this example can be implemented in several physical forms: a hard core integrated within the main system-on-a-chip (SoC) with independent clock and power gating; a programmable logic area integrated within the SoC; or a separate coprocessor chip communicating with the main system via board-level interconnect. Regardless of the physical form, the MCP is defined as a logical entity with independent reset capability, capable of being restarted by the baseboard management controller (BMC), and able to autonomously load configurations from a target non-volatile memory area decoupled from the BIOS mirror memory area and apply them to the underlying hardware controller after startup.

[0058] Please see Figure 4 Based on the same inventive concept as the aforementioned hot-update method using a Baseboard Management Controller (BMC) as the execution entity, this application also provides a server firmware hot-update system, comprising: a Baseboard Management Controller (BMC) for executing the server firmware hot-update method applied to the Baseboard Management Controller (BMC) as described in any of the preceding implementations; a System Control Processor (SCP) for receiving a reset command sent by the Baseboard Management Controller (BMC) and performing an independent reset operation on the power domain of a Management Control Processor (MCP) in response to the reset command; a Management Control Processor (MCP) having an independent power domain for loading target configuration data from a target non-volatile memory area after reset and updating the firmware layer logic of the underlying hardware of the server system according to the target configuration data; and a non-volatile memory device including a first area for storing a BIOS image and a second area decoupled from the first area and serving as the target non-volatile memory area.

[0059] Understandably, a hot update system for server firmware is built through the collaborative operation of the Baseboard Management Controller (BMC), System Control Processor (SCP), Management Control Processor (MCP), and non-volatile storage devices. This allows the firmware update process to be completed without resetting the main system-on-a-chip (SoC), enabling firmware configuration adjustments and vulnerability fixes to be completed without interrupting business operations.

[0060] Specifically, in practical applications, the Baseboard Management Controller (BMC) receives remote commands and executes business logic, writing the target configuration data to a second area in the non-volatile storage device. This second area is decoupled from the first area storing the BIOS image, achieving physical separation between the configuration data and the BIOS image. After the target configuration data is written, the BMC sends a reset command to the System Control Processor (SCP). In response to this reset command, the SCP performs an independent reset operation on the Management Control Processor (MCP), which has an independent power domain. After the MCP resets, it loads the target configuration data from the second area and updates the firmware layer logic of the underlying hardware of the server system accordingly.

[0061] It should be noted that the specific implementation process of the above system is described in the above embodiment of a hot update method for server firmware, and will not be repeated here.

[0062] Based on the aforementioned scheme, in some implementations of this application, the control processor MCP is physically implemented in any of the following forms: a hard core integrated inside the main system-on-a-chip (SoC) with independent clock and power gating; or a programmable logic area integrated inside the main system-on-a-chip (SoC); or an independent coprocessor chip that communicates with the main system through board-level interconnect.

[0063] Understandably, in actual product implementation, the Management and Control Processor (MCP) can take several physical forms. The first form is a hard core integrated within the main system-on-a-chip (SoC). This hard core has independent clock and power gating, achieving physical isolation within the SoC. The second form is a programmable logic area integrated within the SoC, implementing control logic through bitstream configuration. The third form is a separate coprocessor chip that communicates with the main system via board-level interconnects, achieving complete physical independence.

[0064] This application also provides a server including the server firmware hot update system described in any of the preceding implementations. It is understood that by integrating the aforementioned server firmware hot update system into the server product, the server itself possesses uninterrupted firmware hot update capabilities, enabling low-level maintenance without relying on external devices.

[0065] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for hot-updating server firmware, characterized in that, The method, applied to a baseboard management controller (BMC), includes: Receive a remote update instruction, the remote update instruction carrying target configuration data for updating firmware configuration data and / or firmware patch data of the server system; In response to the remote update command, the target configuration data is written to the target non-volatile storage area, which is associated with the management control processor (MCP) and decoupled from the BIOS mirror storage area. Send a reset command to the system control processor SCP. The reset command is used to instruct the system control processor SCP to perform an independent reset operation on the management control processor MCP with an independent power domain after detecting that the target configuration data has been written. This is to enable the management control processor MCP to load the target configuration data from the target non-volatile storage area after restarting, and update the firmware layer logic of the underlying hardware of the server system accordingly. The updated status information returned by the management and control processor (MCP) is obtained through the inter-processor communication channel.

2. The method according to claim 1, characterized in that, The step of writing the target configuration data into the target non-volatile storage area includes: writing the target configuration data into the target non-volatile storage area, and setting a pending status flag in a predetermined status register of the shared storage area after the writing is completed; The reset command is further used to instruct the system control processor SCP to perform an independent reset operation on the power domain of the management control processor MCP when it detects that the pending status flag is set and the verification of the target configuration data is valid.

3. The method according to claim 1, characterized in that, The target non-volatile storage area includes a first storage partition and a second storage partition; The step of writing the target configuration data into the target non-volatile storage area includes: writing the target configuration data into the first storage partition, while retaining the historical configuration data stored in the second storage partition.

4. The method according to claim 3, characterized in that, The step of loading target configuration data from the target non-volatile storage area after the management control processor (MCP) restarts includes: if the management control processor (MCP) fails to load the target configuration data, or fails to verify the digital signature carried by the target configuration data, or if the firmware layer logic of the underlying hardware of the server system is abnormal when updating the target configuration data, historical configuration data is loaded from the second storage partition, and the firmware layer logic of the underlying hardware is restored to the historical state.

5. The method according to claim 1, characterized in that, The target configuration data carries a digital signature and version metadata, the version metadata including version information of the firmware patch data; When the Management and Control Processor (MCP) loads target configuration data from the target non-volatile storage area after a reboot, the process includes: the MCP verifying the validity of the digital signature and reading the current BIOS version information written by the BIOS firmware in the shared storage area; loading and applying the target configuration data only when the digital signature is valid and the current BIOS version information is lower than the version information of the firmware patch data; otherwise, loading the target configuration data is aborted, and the current old firmware configuration is executed.

6. The method according to claim 1, characterized in that, The target non-volatile storage region includes a third storage partition and a fourth storage partition that are decoupled from each other; The step of writing the target configuration data to the target non-volatile storage area includes: writing the firmware configuration data to the third storage partition and writing the firmware patch data to the fourth storage partition.

7. A method for hot-updating server firmware, characterized in that, The method, applied to a management and control processor (MCP) comprising an independent power domain and whose associated target non-volatile memory region is decoupled from the BIOS image memory region of the server system, includes: In response to a reset startup in its own power domain, the target configuration data is loaded from the target non-volatile memory area to update the firmware layer logic of the underlying hardware of the server system, and after loading is completed, the update status information is returned to the baseboard management controller (BMC) through the inter-processor communication channel. The reset start-up refers to the Baseboard Management Controller (BMC) responding to a received remote update command by writing the target configuration data into the target non-volatile storage area and then sending a reset command to the System Control Processor (SCP). This instructs the SCP to perform an independent reset operation on the Management Control Processor (MCP) after detecting that the target configuration data has been written. The remote update command carries the target configuration data used to update the firmware configuration data and / or firmware patch data of the server system.

8. A server firmware hot update system, characterized in that, include: A substrate management controller (BMC) for performing the method as described in any one of claims 1-6; The system control processor SCP is used to receive a reset command sent by the baseboard management controller BMC, and to perform an independent reset operation on the power domain of the management control processor MCP in response to the reset command. The management and control processor (MCP) has an independent power domain for loading target configuration data from the target non-volatile memory area after a reset, and updating the firmware layer logic of the underlying hardware of the server system based on the target configuration data. The non-volatile storage device includes a first region for storing a BIOS image and a second region decoupled from the first region as the target non-volatile storage region.

9. The system according to claim 8, characterized in that, The physical control processor (MCP) can be implemented in any of the following forms: A hard core integrated within the main system-on-a-chip (SoC) with independent clock and power gating; or a programmable logic area integrated within the main SoC; or a separate coprocessor chip that communicates with the main system via board-level interconnect.

10. A server, characterized in that, Includes the server firmware hot update system as described in claim 8 or 9.

Images