Firmware upgrading method, server and supernode server

Abstract

The application discloses a firmware upgrading method, a server and a supernode server, and relates to the technical field of servers. The method comprises the following steps: obtaining the current machine working condition of a whole machine where a target device is located from a controller; determining the target firmware category and the target trigger condition of the target device according to firmware upgrading conditions; when the current machine working condition meets the target trigger condition, determining the target resource lock type according to the occupation of the target device to the machine resources or shared resources, and applying to the main controller; and when the current machine working condition still meets the target trigger condition and the resource lock authorization is obtained, performing a write operation on the target device. The application can solve the problem that related technologies cannot safely complete the whole machine firmware upgrading when multiple board cards and multiple types of firmware coexist, and can safely and efficiently complete the whole machine firmware upgrading when multiple board cards and multiple types of firmware coexist.

Description

Technical Field

[0001] This invention relates to the field of server technology, and in particular to a firmware upgrade method, a server, and a supernode server. Background Technology

[0002] With the rapid development of cloud computing, big data, and artificial intelligence computing power, the number of cards inserted into servers continues to grow. Firmware maintenance of the entire server is essential to ensure that it maintains high reliability and availability during long-term operation.

[0003] When performing firmware upgrades on servers with multiple boards, related technologies are prone to writing firmware under incorrect power supply or in-place conditions, causing write anomalies, device logic errors, or upgrade interruptions. This makes it impossible to safely and efficiently complete the firmware upgrade of the entire machine when multiple boards and different types of firmware coexist. Summary of the Invention

[0004] This invention provides a firmware upgrade method, a server, and a supernode server. When multiple boards and different types of firmware coexist, the method automatically identifies the firmware's operating condition and combines global resource locks and global state to ensure upgrade security and improve the overall firmware upgrade efficiency.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution: This invention provides a firmware upgrade method applied to a controller, comprising: When a firmware upgrade task is received from the target device, the current overall operating status of the device is obtained; Based on the firmware upgrade requirements, determine the target firmware category and target trigger conditions for the target device; When the current overall operating conditions meet the target triggering conditions, the target resource lock type to be requested by the target device is determined based on the target firmware type and the target device's occupation of overall or shared resources during the firmware upgrade process. Send a resource lock request to the main controller and receive an authorization or rejection result from the main controller based on the global state and the resource lock state; If the current overall system condition still meets the target triggering conditions and resource lock authorization is obtained, perform a write operation on the target device; The firmware upgrade conditions are determined based on detection data under at least two system operating conditions, and the target triggering conditions represent the system operating conditions and write permission status that must be met for the firmware to be allowed to be updated.

[0006] Another aspect of the present invention provides a firmware upgrade method applied to a main controller, comprising: Receive resource lock request requests sent from the controller. The resource lock request requests are used to request a resource lock of the target resource lock type. The target resource lock type is determined by the slave controller when the target triggering conditions are met under the current overall operating conditions, based on the target firmware type of the target device and the target device's occupation of overall or shared resources during the firmware upgrade process; The target trigger condition is determined by the slave controller based on the firmware upgrade condition. The firmware upgrade condition record is based on the firmware category and upgrade trigger condition determined by the detection data of the target device under at least two system operating conditions. The target trigger condition includes the target system operating condition that allows the upgrade and the write-allowed status of the target device under the target system operating condition. Based on the global state and resource lock state, the resource lock request can be authorized or denied. Returning an authorization result or a rejection result to the slave controller allows the slave controller to perform a write operation on the target device when the target triggering conditions are still met under the current overall operating conditions and an authorization result has been received.

[0007] The present invention also provides a server, including a master controller and at least one slave controller; The main controller is deployed on the server's motherboard, and each slave controller is deployed on the server's baseboard. The main controller and each slave controller communicate through an internal local area network. Each slave controller is used to implement the corresponding firmware upgrade method steps described above when executing a computer program stored in the memory; the master controller is used to implement the corresponding firmware upgrade method steps described above when executing a computer program.

[0008] Finally, the present invention also provides a supernode server, including multiple servers connected via an interconnect bus; each server includes a master controller and at least one slave controller; the master controller is deployed on the motherboard of the corresponding server, and each slave controller is deployed on the substrate of the corresponding server, and the master controller and each slave controller communicate through an internal local area network; each slave controller is used to implement the steps of the corresponding firmware upgrade method described above when executing a computer program stored in a memory; the master controller is used to implement the steps of the corresponding firmware upgrade method described above when executing a computer program.

[0009] The advantage of the technical solution provided by the present invention is that, since the firmware upgrade conditions are generated based on the detection data of the managed device under at least two system operating conditions, and the firmware category and upgrade trigger conditions are recorded, each target device obtains the corresponding target system operating condition and write-allowed status according to the firmware category to which it belongs. When a slave controller receives a firmware upgrade task from a target device, it determines whether the current overall operating condition meets the target triggering conditions before executing the write operation. It then requests a resource lock from the master controller corresponding to the resources occupied by the target device. The master controller decides to authorize or deny the write operation based on the global state and the resource lock status. This ensures that the write operation is only executed when the overall operating condition continuously matches the write-allowed state of the target device, and when the overall or shared resources are not occupied by other nodes. The device restart permission, power-off state, shared power domain, and shared bus are occupied by only one slave controller at any given time. Multiple slave controllers executing local firmware upgrade tasks in parallel will not conflict with each other. This ensures that the firmware write action corresponds to the actual overall operating condition of the target device, the target device's firmware type, and the overall global state and resource lock status. This avoids write failures, power domain anomalies, and bus conflicts caused by mismatches between the firmware type and the overall operating condition, or by multiple slave controllers simultaneously occupying the same overall or shared resources. It also reduces write failures caused by mismatches between the write timing and the device's power supply and in-situ status, thus achieving safe and efficient overall firmware upgrades. Furthermore, this invention also provides a corresponding server and supernode server for the firmware upgrade method, further making the method more practical, and the server and supernode server have corresponding advantages. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the present invention or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic flowchart of a firmware upgrade method provided by the present invention; Figure 2 A flowchart illustrating another firmware upgrade method provided by the present invention; Figure 3 A structural framework diagram of an exemplary embodiment of the firmware upgrade device provided by the present invention; Figure 4 A structural framework diagram of another exemplary embodiment of the firmware upgrade device provided by the present invention; Figure 5 A structural diagram of an exemplary embodiment of the electronic device provided by the present invention; Figure 6 A structural diagram of an exemplary embodiment of the server provided by the present invention; Figure 7 A flowchart illustrating the firmware upgrade method in an exemplary application scenario provided by the present invention; Figure 8 This is a schematic diagram of the firmware information collection process in an exemplary application scenario provided by the present invention; Figure 9 A flowchart illustrating another firmware upgrade method in an exemplary application scenario provided by the present invention; Figure 10 This is a schematic diagram illustrating different types of firmware upgrade processes in exemplary application scenarios provided by the present invention. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. In this specification and the aforementioned drawings, the terms "first," "second," "third," "fourth," etc., are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. The term "exemplary" means "serving as an example, embodiment, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as superior to or better than other embodiments.

[0013] With the development of next-generation information technologies such as cloud computing, big data, and artificial intelligence, the scale of data centers continues to expand. As the infrastructure of data centers, servers need to maintain high reliability and availability while undertaking computing, storage, and network services. Hardware requires maintenance from the time it goes online until it is taken out of use. The hardware management of servers is handled by out-of-band management units. These servers are equipped with a Baseboard Management Controller (BMC), which performs tasks such as hardware monitoring, firmware upgrades, and remote troubleshooting.

[0014] To improve computing density and functional scalability, server architectures with multiple boards working together are being adopted. In addition to the motherboard located at the front of the server, such servers are equipped with multiple universal base boards (UBBs) that are pluggable and mounted on the chassis or backplane. Each UBB is equipped with a micromanagement controller (MMC) to collect sensor data, field replaceable unit (FRU) information, firmware version information, and other management data for the local node. For ease of description, this invention refers to the management controller located on the motherboard as the master controller and the management controller located on the base board as the slave controller.

[0015] When performing batch upgrades of multiple controllers using related technologies, the upper-level device collects firmware files, performs simple verification, and then distributes them to each lower-level controller. Each device independently completes its own firmware update, which solves the cumbersome operation and network congestion caused by manual upgrades. However, this method only applies to the controller's firmware and does not cover complex programmable logic devices (CPLDs), switches, boot firmware, etc., making it difficult to adapt to scenarios with multiple boards and firmware. It lacks hierarchical distinction between master and slave controllers and permission boundaries between devices, making it prone to overstepping levels and incorrect firmware flashing. It lacks fault isolation between nodes; if a single device fails to upgrade, the entire upgrade process terminates. It also lacks a scheduling relationship that combines parallel and serial processes, forcing devices to queue and preventing multiple nodes from simultaneously performing local writes, resulting in a long upgrade time for the entire device. Another related technology's firmware update method only supports upgrades of a single type of firmware. This method sets up basic verification and flashing processes for CPLD and switch firmware separately, suitable for simple updates of a single type of firmware. The functions of this processing method are independent of each other, and it cannot uniformly manage the controller firmware, various baseboard firmware and switch firmware in the same process, and cannot complete the unified upgrade of the whole machine. It is not compatible with the management structure of the main controller and multiple slave controllers. All firmware is executed serially, while the number of server firmware is large, and the overall upgrade takes a long time. Its detection methods in the transmission process are relatively simple, only performing basic verification, lacking encrypted transmission and multi-level detection. Firmware data may be tampered with. Its fault location capability after upgrade problems occur is weak, and the troubleshooting is difficult.

[0016] As the number of managed devices on the substrate increases, each management unit becomes relatively independent, lacking unified scheduling and common relationships, thus increasing the complexity of firmware management. Different firmware within the server have different power supply domains, reset domains, in-situ conditions, link states, and upgrade activation methods. Some firmware remains powered on after the operating system is shut down, while others can only be recognized and written after the entire machine is powered on. The BMC firmware itself has dual-partition backup activation capability. Related technologies cannot comprehensively handle automatic firmware condition recognition, independent and parallel node execution, global resource coordination, and abnormal power failure protection, making it prone to writing under incorrect operating conditions, leading to write anomalies, logical errors, hardware damage, or upgrade interruptions.

[0017] To address the issue that when multiple slave controllers simultaneously perform firmware upgrades, it's impossible to guarantee that each device requiring upgrade is written under the same overall system operating conditions that match its power supply domain and link status, this invention, upon receiving a firmware upgrade task from a target device, determines the current overall system operating conditions and the target firmware category and trigger conditions based on the firmware upgrade requirements. If the current overall system operating conditions meet the target trigger conditions, the required target resource lock type is determined according to the target device's resource or shared resource usage during the firmware upgrade process, and a resource lock request is sent to the master controller. The master controller returns an authorization or rejection result based on the global state and the resource lock status. The slave controller only performs the write operation on the target device when the current overall system operating conditions still meet the target trigger conditions and the resource lock authorization is obtained. This method ensures that the write operations of each target device requiring firmware upgrades are simultaneously constrained by both the overall system operating conditions and global resource usage, guaranteeing the security and stability of multiple firmware upgrades.

[0018] The aforementioned firmware upgrade method can be implemented as a computer program product, installed and run in a server configured with a motherboard and multiple pluggable substrates. It is jointly executed by the main controller deployed on the motherboard and the slave controllers deployed on the substrates through an internal local area network. For example, it can realize the parallel upgrade processing of the BMC body firmware, Basic Input Output System (BIOS) firmware, CPLD firmware and switch firmware.

[0019] After introducing the technical solution of the present invention, the various non-limiting embodiments of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] Please see first. Figure 1 This invention provides a firmware upgrade method. This embodiment illustrates the firmware upgrade method performed from a controller. In some embodiments of this method, the method includes the following steps: S101: When a firmware upgrade task is received from the target device, obtain the current overall operating status.

[0021] The target device refers to the hardware device that requires firmware updates. It can be any one of the following: the main body of the slave controller, a complex programmable logic device, a switch, or a control device configured on the backplane. A firmware upgrade task refers to a firmware update command issued for the target device. The entire system refers to the server system comprised of the head unit control board, the main controller, one or more baseboards, slave controllers on each baseboard, and all managed devices managed by each slave controller. The overall system status refers to the operating status of the server system as a whole, including the system power-on and running status, the operating system normal shutdown with board power-on protection, and the system idle and restartable status. The current overall system status refers to the combined power supply and operating status of the server system; it describes the entire system, not just the local state of the target device itself.

[0022] In this step, the controller does not immediately write the firmware after receiving the upgrade task. Instead, it first reads the overall system status signals that the node can observe to determine the current overall system operating condition. For example, the current overall system operating condition can be determined based on a combination of the power supply unit's input status, the Power Good (PGOOD) signal level of each device, and whether the operating system is powered down. Alternatively, it can be determined based on a combination of the overall system power status indicated by the Advanced Configuration and Power Interface (ACPI) and the board presence signals. The invention does not impose any limitations on this, as long as the current power supply state and operating state of the system can be distinguished. For instance, the controller reads the presence signals from the node's General Purpose Input / Output (GPIO), reads PGOOD to determine if the target device's power supply remains effective, and reads the ACPI status to distinguish whether the system is in a working state or a soft shutdown state. Based on these data, the current overall system operating condition is determined.

[0023] S102: Determine the target firmware category and target trigger conditions for the target device based on the firmware upgrade conditions.

[0024] The firmware upgrade conditions are determined based on probe data under at least two system operating conditions. These conditions are generated from probe data of all managed devices under at least two system operating conditions, recording the firmware category and upgrade trigger conditions for each managed device. This represents the correspondence between each hardware device (i.e., the managed device) and its allowed write operating conditions within the entire system. This data can be recorded locally on the slave controller in the form of a data table, or it can be uniformly distributed by the master controller after each power-on of the slave controller. Probe data refers to the results obtained from accessing a managed device under a certain system operating condition. These results may include at least one of the following: whether the device identity is readable, whether the bus address is responded to, whether the presence signal is valid, and whether the device identifier was successfully read. The firmware upgrade conditions record the firmware category and upgrade trigger conditions corresponding to the managed device. Firmware category refers to the classification of managed devices according to the overall operating conditions under which they are allowed to be written. Upgrade trigger condition refers to the overall operating conditions corresponding to a specific firmware category that allow devices under that firmware category to write firmware. It is used to determine whether the current firmware upgrade operation is allowed and whether the managed device can write the firmware data to be upgraded. Target trigger condition indicates the overall operating conditions and write-allowed status that must be met for firmware to be updated. It is used to determine the target overall operating conditions that the target device must meet to allow the firmware to be updated, and the write-allowed status of the target device under the target overall operating conditions. Write-allowed status refers to the state value of the target device under the target overall operating conditions that indicates whether it can be written. The target overall operating conditions describe in which global state this type of firmware should perform the firmware upgrade operation. Target firmware category refers to the firmware category to which the target device being upgraded belongs.

[0025] In this step, for example, the controller retrieves the target firmware category and target trigger condition of the target device from the firmware upgrade conditions using the target device as the retrieval key. For example, the firmware upgrade conditions can be recorded using the device identifier as the primary key, with each record including the device identifier, firmware category, and upgrade trigger condition; or they can be recorded by firmware category, with multiple devices under the same firmware category sharing one upgrade trigger condition; of course, in addition to the above two recording formats, devices can be grouped by their physical location first, and then their respective upgrade trigger conditions can be attached within each group, as long as the target device can retrieve the corresponding target firmware category and target trigger condition. This invention does not impose any limitations on this. Since the firmware upgrade conditions originate from probe data under at least two system operating conditions, whether the same device can be written to under different system operating conditions is recorded separately. The resulting write permission status corresponds to the power supply, reset, and link requirements of the target device itself, eliminating the need for manual specification of the upgrade timing for each device in advance.

[0026] S103: When the current overall operating conditions meet the target triggering conditions, determine the type of target resource lock that the target device needs to apply for based on the target firmware type and the target device's occupation of overall or shared resources during the firmware upgrade process.

[0027] In this context, "system resources" refers to resources uniformly provided by the server and shared by multiple nodes. For example, system resources refer to resources shared by multiple devices or boards within the system, such as system restart operations, system power status, shared power domains, and shared buses. Shared resources refer to resources shared by multiple devices on the same bus or power domain, including the transmission bandwidth of the same bus and the power output of the same power domain. "Occupancy status" refers to whether the target device needs to exclusively occupy system resources or shared resources during firmware writing. "Target resource lock type" refers to the type of resource lock that the target device needs to request from the main controller for this write operation.

[0028] In this step, the controller first compares the current overall system operating condition with the target overall system operating condition defined by the target triggering conditions, and simultaneously compares the current write permission status of the target device. Only when both match does the process of determining the target resource lock type begin. For example, the occupancy status can be directly determined by the target firmware category, i.e., devices under the same firmware category share a resource occupancy attribute; it can also be determined by the controller querying the channel affiliation traversed by this write operation, i.e., determining which external bus or power domain this write operation will pass through; of course, in addition to the above two methods, it can also be determined by the controller searching a pre-stored device attribute table, as long as it can be determined whether this write operation will occupy overall system resources or shared resources. This invention does not impose any limitations on this. For example, if the target device does not need to change the overall system power supply state or exclusively occupy any external bus during this write operation, its occupancy status is recorded as not occupying overall system resources and not occupying shared resources. In this case, the determined target resource lock type is "no resource lock application required," and the controller can directly execute the subsequent write process.

[0029] S104: Send a resource lock request to the main controller and receive an authorization or rejection result from the main controller based on the global state and resource lock state. The resource lock request is used to request a resource lock of the target resource lock type.

[0030] In this context, the main controller refers to the management controller deployed on the server motherboard, which manages and schedules all slave controllers within the server. Global state refers to the state data maintained by the main controller, representing the current stage of the entire machine; in actual use, this can be implemented using a state machine. Resource lock state refers to the record information of whether each resource lock is currently occupied and which node holds it. A resource lock request is a message sent by a slave controller to the main controller requesting the allocation of a specific resource lock. An authorization result is the return result of the main controller agreeing to allocate the requested resource lock to the slave controller. A rejection result is the return result of the main controller disagreeing with the allocation.

[0031] In this step, the slave controller sends a resource lock request to the master controller via the internal LAN channel between the motherboard and the baseboard. The request message carries the target resource lock type and the node identifier of the slave controller. After receiving the request message, the master controller determines the global state and resource lock state, and returns an authorization result or a rejection result to the slave controller. For example, the request message can be carried by a remote procedure call message based on the internal LAN; it can also be carried by a resource operation request based on the Redfish management interface (an open server management standard developed by the Distributed Management Task Force (DMTF); of course, in addition to the above methods, a fixed-length message in a private format can also be used, as long as the target resource lock type and node identifier can be delivered to the master controller and the final result of whether the lock is allowed can be fed back to the slave controller. This invention does not impose any limitations on this. For example, if the controller determines that the target device needs to occupy a shared power domain during the upgrade process, the target resource lock type is a shared power domain lock. The slave controller sends a resource lock request to the master controller, requesting the shared power domain lock. The master controller determines whether the shared power domain has been occupied by another slave controller based on the global state and the resource lock state. If it has not been occupied and the global state allows it, the master controller returns an authorization result to the slave controller. If it has been occupied, the master controller either refuses or adds the slave controller to the waiting queue. After obtaining the shared power domain lock, the slave controller locks the power domain and performs a write operation. After the write operation is completed and verified, the slave controller releases the shared power domain lock. After receiving the release, the master controller can allocate the shared power domain lock to the next slave controller according to the waiting queue order.

[0032] S105: When the current overall system condition still meets the target triggering conditions and resource lock authorization is obtained, perform a write operation on the target device.

[0033] Among them, resource lock authorization refers to the right to hold such resource lock obtained from the controller after the main controller returns the authorization result, and write operation refers to the process of burning the firmware data to be written to the storage medium of the target device.

[0034] In this step, after the controller holds the resource lock authorization, it rereads the overall system status signal of its node and re-determines whether the current overall system condition meets the target triggering conditions. The writing process only begins if the condition is met again. During the writing process, the firmware data to be upgraded is written to the storage medium of the target device according to the channel corresponding to the target firmware category, and a read comparison is performed after the writing is completed. Since the overall system condition may change during the resource lock waiting period due to a new shutdown command, an unplanned power interruption, or a restart operation of another node, re-determining the overall system condition after holding the resource lock authorization ensures that the writing process does not occur in an already changed system condition. The overall system status refers to the overall state of the server system maintained by the master controller based on the overall system status and resource lock status of each slave controller. For example, it may include abnormal power failure state, power-on power-saving state, power-on initialization state, running state, and idle restartable state.

[0035] In the technical solution provided in this embodiment, since the firmware upgrade conditions are generated based on the detection data of the managed device under at least two system operating conditions, and the firmware category and upgrade trigger conditions are recorded, each target device obtains the corresponding target system operating condition and write-allowed status according to the firmware category it belongs to. When a slave controller receives a firmware upgrade task from a target device, it determines whether the current overall operating condition meets the target triggering conditions before executing the write operation. It then requests a resource lock from the master controller corresponding to the resources occupied by the target device. The master controller decides to authorize or deny the write operation based on the global state and the resource lock status. This ensures that the write operation is only executed when the overall operating condition continuously matches the write-allowed state of the target device, and when the overall or shared resources are not occupied by other nodes. The device restart permission, power-off state, shared power domain, and shared bus are occupied by only one slave controller at any given time. Multiple slave controllers executing local firmware upgrade tasks in parallel will not conflict with each other. This ensures that the firmware write action corresponds to the actual overall operating condition of the target device, the target device's firmware type, and the overall global state and resource lock status. This avoids write failures, power domain anomalies, and bus conflicts caused by mismatches between the firmware type and the overall operating condition, or by multiple slave controllers simultaneously occupying the same overall or shared resources. It also reduces write failures caused by mismatches between the write timing and the device's power supply and in-situ status, thus achieving safe and efficient overall firmware upgrades.

[0036] In the above embodiments, there is no limitation on how to specifically perform the write operation on the target device after obtaining resource lock authorization. In order to avoid the problem that the firmware writing process of the target device competes for resources with the services running on this node, and that the target device cannot provide normal services during the writing process, this embodiment also provides an exemplary first type of firmware writing implementation method, which may include the following: The target firmware of the target device is of type 1 firmware. The target device has a target running partition and a target backup partition. Under the current whole machine operating condition of whole machine power-on and running condition, the firmware to be upgraded of the target device is written to the target backup partition. After the firmware to be upgraded is written and verified, wait for the global state to enter the idle and restartable state. When the global state is in the idle and restartable state, apply for the whole machine restart lock from the main controller. After obtaining the whole machine restart lock, control the target device to restart, so as to switch to the target backup partition to run the firmware to be upgraded.

[0037] The first type of firmware refers to firmware for devices with two switchable storage partitions, where a reboot is required for the changes to take effect after writing to one partition. "System boot-up and operation status" refers to the server being powered on and running normally. "Firmware to be upgraded" refers to the firmware data to be written to the target device. "Write and verification passed" means that the firmware to be upgraded has been written and then read and compared, with the comparison result matching. "Target running partition" refers to the partition on the target device that is currently loading and running software. "Target backup partition" refers to the partition on the target device that serves as a backup to the target running partition and is not currently being loaded or running. "Idle and restartable state" refers to the global state maintained by the main controller, indicating that the entire machine is not currently processing any business operations and can be restarted. "System restart lock" refers to the resource lock corresponding to the permission to perform a restart operation on the entire machine.

[0038] In this embodiment, the target device can switch between two partitions during operation, so the writing process itself will not interrupt the running target device: the firmware to be upgraded is first written to the target backup partition, while the target device still loads and runs from the target running partition. The writing process and normal operation do not preempt each other. For example, the verification performed after writing can be done by comparing cyclic redundancy check codes; it can also be done by comparing the read data with the firmware image byte by byte; of course, in addition to the above two methods, digital signature verification can also be used, as long as it can be confirmed that the data written to the target backup partition is consistent with the firmware to be upgraded. This invention does not impose any limitations on this. For example, when the target device is the main controller or slave controller's main firmware, the flash memory of the target device is divided into partition zero and partition one. This time, it is loaded and run from partition zero, so the target running partition is partition zero and the target backup partition is partition one. The firmware to be upgraded is written to partition one and temporarily does not take effect after verification; thereafter, the target device does not restart immediately, but waits for the main controller to switch the global state to an idle and restartable state.

[0039] In this embodiment, a system reboot will cause multiple nodes on the system to reset simultaneously. Therefore, the reboot operation is not an action that each slave controller can perform independently, but rather requires requesting a system reboot lock from the master controller. For example, waiting for an idle rebootable state can be achieved by the slave controllers polling the global status published by the master controller at fixed intervals; or by the master controller actively broadcasting a notification to each slave controller when switching to the idle rebootable state; of course, in addition to the above two methods, it can also be achieved by the slave controllers being suspended by the master controller when requesting a system reboot lock, and then being woken up by the master controller when entering the idle rebootable state, as long as the reboot operation can occur in the idle rebootable state, this invention does not impose any limitations on this. For example, the firmware of both the master controller on the motherboard and the slave controllers on the substrate belongs to the first type of firmware. After multiple nodes complete the writing of their respective spare partitions, the master controller uniformly arranges for each node to enter the idle rebootable state sequentially and complete the reboot switch.

[0040] As can be seen from the above, this embodiment first writes the firmware to be upgraded to the target spare partition, and only after the verification is passed and the whole machine enters an idle and restartable state does it apply for a whole machine restart lock to switch. This ensures that the writing process and the operation process of the target device do not compete with each other, and that the new version of the firmware only takes effect after the whole machine restarts. This avoids service interruption caused by firmware switching during the process of the whole machine carrying services.

[0041] In the above embodiments, there are no limitations on how to ensure that the write channel is not occupied by other accesses during the process of writing the firmware to be upgraded to the spare partition. In order to avoid the problem of multiple nodes accessing the target device at the same time through the same bus, causing the write data to be out of order or the write to fail, this embodiment also provides an exemplary bus exclusive implementation method, which may include the following: Based on the target device's shared bus usage during firmware upgrade, determine that the required resource lock type is a shared bus lock; request a shared bus lock from the main controller; after obtaining the shared bus lock, write the firmware to be upgraded to the target spare partition, and release the shared bus lock after the firmware is written.

[0042] In this context, a shared bus refers to a communication bus that is shared and time-sharingly used by multiple devices on the same node, such as an Inter-Integrated Circuit (I2C) bus. A shared bus lock is a resource lock corresponding to the right to access this shared bus. Releasing a shared bus lock means returning the resource lock to the master controller, allowing other slave controllers to regain access to this shared bus.

[0043] In this embodiment, before the slave controller determines that the firmware is of the first type and prepares to write it to the spare partition, it first determines whether the channel to be written is a shared bus. For example, if a temperature sensor, a power control chip, and a target device are simultaneously connected to the first numbered I2C bus of this node, the slave controller will compete for the bus with the temperature acquisition process when writing to the target device through this bus. Therefore, before writing, this node requests a shared bus lock corresponding to the first numbered I2C bus. The master controller allocates this bus when it is not held by other nodes. After obtaining the lock, the slave controller writes the firmware to be upgraded page by page. After the writing is completed, the shared bus lock is immediately released, allowing the temperature acquisition of other nodes and the writing process of other devices to continue. Exemplarily, the shared bus lock can be set according to the physical number of the bus; it can also be set uniformly according to the power domain connected to the bus; of course, in addition to the above two methods, it can also be set according to the address range of the device connected to the bus, as long as only one slave controller occupies the same shared bus at the same time. This invention does not impose any limitations on this.

[0044] As can be seen from the above, this embodiment, by requesting a shared bus lock before writing to the spare partition and releasing it immediately after writing is completed, ensures that the write data of the target device is sent out by this node only through the bus at the same time, thus avoiding write reordering and write failure caused by multiple access disputes on the bus.

[0045] In the above embodiments, there is no limitation on how to determine that the whole machine has entered an idle and restartable state. In order to avoid the problem of restarting the whole machine while it is still carrying services or still performing maintenance operations, which would cause the ongoing services to be interrupted, this embodiment also provides an exemplary implementation method for determining idle and restartable state, which may include the following: The idle metric value of the whole machine is determined based on at least one of the user access status, operation and maintenance task status, system load status and abnormal alarm status. When the idle metric value of the whole machine is lower than the preset idle threshold, and the firmware upgrade task from the controller is completed and there is no operation and maintenance operation being performed on the whole machine, it is determined to enter the idle and restartable state.

[0046] Among them, user access status refers to the existence of management access requests and login sessions from users, including whether a session connection to the Redfish management interface (an open server management standard defined by the Distributed Management Task Force (DMTF)) has been established, whether an access request to the Intelligent Platform Management Interface (IPMI) exists, and whether a user login record exists. Operation and maintenance task status refers to whether there are still operation and maintenance tasks such as configuration synchronization and data backup being executed across the entire machine. System load status refers to the utilization rate of each processing unit and the overall power consumption of the machine. Anomaly alarm status refers to the presence of any unprocessed alarm events. The overall machine idle quantification value is a weighted sum of the values ​​of the above-mentioned statuses; a higher value indicates a busier overall machine. The preset idle threshold is a quantification threshold used to distinguish whether the entire machine is idle.

[0047] In this embodiment, the idle quantification value of the entire machine is obtained by summing the values ​​of the four states obtained by the slave controller. For example, within the most recent ten-minute time window, if there is a user login session (30 points), an IPMI access request (20 points), a configuration synchronization task (15 points), a processor utilization rate exceeding 50% (20 points), and an unprocessed alarm (15 points), then the idle quantification value of the entire machine within this time window is 100 points. The preset idle threshold is 40 points. Therefore, the entire machine is determined to enter the idle and restartable state only when the quantification value within a certain time window is lower than 40 points, the firmware upgrade task of this slave controller has been completed, and there are no ongoing maintenance operations within the entire machine. Exemplarily, the weights of the various states can be configured by the maintenance terminal; or they can be stored locally on the slave controller according to fixed empirical weights; of course, in addition to the above methods, they can also be uniformly specified by the master controller according to the machine model, as long as the idle degree of the entire machine can be quantified and compared with the threshold. This invention does not impose any limitations on this.

[0048] As can be seen from the above, this embodiment quantifies the idle state of the whole machine by using four types of states: user access, operation and maintenance tasks, system load and abnormal alarms. Combined with the two conditions of the completion of the firmware upgrade task of this node and the absence of operation and maintenance operations on the whole machine, the determination of the idle and restartable state no longer depends on a single signal, thus avoiding the whole machine from entering a restart when there are still sessions or tasks being executed.

[0049] In the above embodiments, there is no limitation on how to specifically perform the write operation on the target device after obtaining resource lock authorization. In order to avoid the problem that some devices remain powered on after the whole system operating system is shut down, and writing during the power-on operation will conflict with business read and write, this embodiment also provides an exemplary second type of firmware writing implementation method, which may include the following: The target firmware of the target device is classified as Category 2 firmware. Under the current system operating condition of normal operating system shutdown and board power-saving mode, it requests a shutdown power-saving lock from the main controller. This means the operating system has shut down normally and the target device's power supply domain remains valid. The shutdown power-saving lock is assigned when the global state is in shutdown power-saving mode. After obtaining the shutdown power-saving lock, if the power supply meets the task requirements, the system locks the overall power state, sets the controller restart prohibition attribute and AC power-off command sending operation prohibition attribute, and backs up the original firmware data of the target device. A write operation is then performed on the target device. After writing, the target device is verified. Only after successful verification is the upgrade marked as successful. If an abnormal power failure is detected during the writing process, the controller, upon power-up, performs a rollback or retry on the target device based on the locally backed-up original firmware and reports the power failure record to the main controller.

[0050] The second type of firmware refers to firmware that allows writing only when the device's power supply domain remains active after the operating system is shut down, and therefore the entire device is powered off. "Normal Operating System Shutdown and Board Power Preservation Condition" refers to the overall operating condition where the operating system exits through a normal shutdown process, but the power supply to each board remains active. "Power Supply Domain" refers to the area covered by a single power supply line that provides power to a device or group of devices. "Shutdown Power Preservation Lock" refers to the resource lock corresponding to the condition that the entire device remains powered on. "Shutdown Power Preservation State" refers to the global state maintained by the main controller that indicates the entire device has completed a normal operating system shutdown and is still powered on. "Task Power Requirement" refers to the amount of power required to write to the target device. "Controller Reboot Prohibited" is a flag that prevents the main controller and slave controller from resetting themselves during this writing process. "AC Power-Off Command Sending Prohibited" is a flag that prevents the issuance of AC power-off commands to the power supply unit. "Original Firmware Data" refers to a complete copy of the firmware currently being used on the target device.

[0051] In this embodiment, the target device remains powered on after the entire operating system is powered off. Therefore, the writing process is performed under the condition that the operating system is normally powered off and the board is powered on. At this time, there is no contention for the same timing resources between business read and write operations. For example, it can be a Complex Programmable Logic Device (CPLD), such as the motherboard CPLD, management board CPLD, fan board CPLD, switching board CPLD, and power distribution board CPLD. These devices belong to the second type of firmware. These devices undertake the timing and signal control tasks of the board when they are powered on and running. Writing while they are working would conflict with these tasks, so it is arranged to write when the operating system is powered off but still powered on. Exemplarily, the backup of the original firmware data can be saved to the flash memory partition on the controller; it can also be saved to the storage area of ​​the main controller, as long as it can be retrieved after a write failure. This invention does not impose any limitations on this.

[0052] In this embodiment, to prevent damage to the target device due to a sudden power outage halfway through the write process, the slave controller, after obtaining the power-saving lock, first checks whether the power supply unit can currently provide enough power for this write operation. For example, if the device has four power supply units and this write operation requires two of them to maintain output, the slave controller first reads the input status and number of power supply units in place. It only continues when it confirms that at least two power supply units are in normal output mode. After successful confirmation, the overall power supply status is locked, preventing the device from changing its power supply status during this write operation. A controller restart prohibition attribute is set to prevent the master or slave controller from resetting itself during this period, and an AC power-off command sending prohibition attribute is set to prevent the maintenance terminal from issuing power-off commands.

[0053] As can be seen from the above, this embodiment writes the second type of firmware under the condition that the operating system is normally shut down and the board is powered on, so that the writing process does not conflict with the timing control tasks undertaken by the device during power-on; by confirming that the power supply meets the task requirements and locking the power status of the whole machine before writing, and setting the controller restart prohibition attribute and the AC power-off command sending operation prohibition attribute, the writing process is not interrupted due to changes in the power supply status; by backing up the original firmware data before writing, the target device that has not completed the writing can be restored to the original version.

[0054] In the above embodiments, there are no limitations on how to determine whether the overall system operating condition is a normal shutdown of the operating system and a power-saving condition of the board. In order to avoid the problem of misjudging abnormal power failure as normal shutdown and thus writing under unstable power conditions, which may damage the target device, this embodiment also provides an exemplary operating condition confirmation method, which may include the following: The system detects the overall power status signal, the target device's power supply domain status signal, the power button status, the operating system shutdown record, the AC power failure record, and the power failure reset record. If the overall power status indicates that the operating system has been soft-shutdown, the target device's power supply domain is valid, the power button status is normal, there is an operating system normal shutdown record, and there are no AC power failure or power failure reset records, then the current overall operating condition is determined to be the operating system normal shutdown and board power preservation condition. If the normal shutdown judgment conditions are not met, and there is a power failure record, that is, if at least one of the following does not meet the normal shutdown judgment conditions: overall power status, target device power supply domain status signal, power button status, operating system shutdown record, AC power failure record, and power failure reset record, then it is determined to be an abnormal power failure. Entering the operating system normal shutdown and board power preservation condition is prohibited, and the issue is reported to the main controller, so that the main controller can switch the global state to the abnormal power failure state and call the locally backed-up original firmware for rollback or retry.

[0055] The overall power status signal can be provided by the ACPI status register or the power status register of the main controller, indicating the current AC power supply and operating system status of the entire machine. Taking ACPI as an example, ACPI state S5 indicates that the operating system is soft-shutdown but the target device's power supply domain remains active, and ACPI state S0 indicates that the entire machine is powered on and running. The power supply domain status signal indicates whether the output voltage of the power supply domain where the target device is located is within the normal range, and it generally uses the PGOOD signal. The power button status indicates whether the power button on the chassis panel has been pressed or whether there is a value recorded from a long time ago. The operating system shutdown record is an event record stored by the out-of-band management unit that shows the operating system has executed a complete shutdown process. The AC power failure record is an event record stored by the out-of-band management unit that shows an external AC input interruption has occurred. The power failure reset record is a record stored by the CPLD reset reason register that shows the target device has reset due to a voltage drop or due to power failure. The abnormal power failure state is the state in the global state maintained by the main controller that indicates that the entire machine has experienced an unplanned input power interruption. Power outage records include AC power outage records and power outage reset records.

[0056] In this embodiment, both normal shutdown and abnormal power failure may appear externally as if the operating system has stopped running and there is still residual power. Therefore, the controller not only checks whether the operating system has stopped running, but also checks the power failure and the previous shutdown process records. For example, if the PGOOD signal is high, the power supply domain status signal is valid, the overall power supply status signal indicates that the operating system has been soft-shutdown, there is a normal shutdown record for the operating system, and there are no AC power failure or power failure reset records, then this is considered a normal shutdown of the operating system and a power-saving condition for the board. If the power supply domain status signal of the target device is invalid, or there is an AC power failure record, or there is a power failure reset record, and there is no normal shutdown record for the operating system, then this is considered an abnormal power failure. In this case, even if there is still residual power, the second type of firmware writing process will not be initiated, and the determination result will be reported to the main controller.

[0057] In this embodiment, after receiving a report, the main controller switches the global state to an abnormal power-down state. Subsequently, for the target device that has already begun writing, it calls its locally backed-up original firmware to roll back or re-execute the writing process. For example, the aforementioned recorded information can be distinguished by the value of the CPLD reset reason register; it can also be distinguished by the event log record of the out-of-band management unit; of course, in addition to the above two, it can also be distinguished by the power-down flag bit in the battery backup domain, as long as normal shutdown and abnormal power-down can be distinguished, and this invention does not impose any limitations on this.

[0058] As can be seen from the above, this embodiment distinguishes between normal shutdown and abnormal power failure by simultaneously detecting six types of signals: the overall power status signal, the power supply domain status signal of the target device, the power button status, the operating system shutdown record, the AC power failure record, and the power failure reset record. This prevents the writing of the second type of firmware from being performed on the overall device with unstable power supply. Furthermore, by reporting the abnormal power failure to the main controller, which switches the global state and calls the locally backed-up original firmware to roll back or retry, the target device that has already started writing is restored to a usable state.

[0059] In the above embodiments, there is no limitation on how to specifically perform the write operation on the target device after obtaining resource lock authorization. In order to avoid the problem that some devices cannot be accessed at all when the whole machine is not powered on, and therefore the write cannot be completed, this embodiment also provides an exemplary third type of firmware writing implementation method, which may include the following: The target firmware of the target device is of type 3 firmware. It obtains the power-on status data of the whole machine, the power supply data of the target device, and the accessibility data of the target device. Based on the power-on status data of the whole machine, the power supply data of the target device, and the accessibility data of the target device, it determines that the current operating condition of the whole machine is the power-on running condition and that the target device meets the conditions of being in place and the link being stable. It then requests a shared bus lock from the main controller. When the shared bus lock is obtained, a write operation is performed on the target device.

[0060] The third type of firmware refers to firmware that can only be recognized and accessed after the entire system is powered on. System power-on status data indicates whether the system has successfully powered on, including whether ACPI is active, whether PGOOD is valid, whether the BIOS has completed its Power-On Self-Test (POST), and whether a crash signal exists. Target device power supply data indicates whether the target device's power domain is receiving power normally. Target device accessibility data indicates whether the target device can be addressed and read / written via the bus, including whether Vital Product Data (VPD) can be read, whether the presence signal is valid, and whether the bus address is responsive. Presence and link stability conditions refer to the combined condition that the target device is physically present and that communication on its bus is normal.

[0061] In this embodiment, the device corresponding to the third type of firmware is unreadable, not in place, and unresponsive on the bus when the entire operating system is powered off and the board is powered on. Therefore, its writing can only be performed after the entire system is powered on. For example, the hard disk backplane CPLD, the switch board CPLD, and the switch firmware all belong to the third type of firmware. This type of device loses power during the shutdown and power-on period and cannot be addressed via the bus. Its address only appears on the bus after the entire system is powered on. Exemplarily, the above three data items can be obtained by reading the ACPI status register, the PGOOD signal line, and the bus scan results from the slave controller; or they can be collected and distributed by the master controller. As long as it can be confirmed that the target device can be addressed after the entire system is powered on, the present invention does not impose any limitations on this.

[0062] As can be seen from the above, this embodiment confirms that the target device is indeed in place and the link is stable under the overall system power-on operation by simultaneously using three data: overall system power-on status data, target device power supply data, and target device accessibility data. This ensures that the writing of the third type of firmware does not occur under the overall system operation where the target device cannot be addressed. Furthermore, by requesting a shared bus lock before writing, other accesses on the same bus during the writing process will not compete with the target device for resources.

[0063] In the above embodiments, there are no limitations on how to handle abnormal situations after the write operation is completed. To avoid the problem of a write failure on a single node affecting the rest of the machine and causing the entire upgrade process to be terminated, this embodiment also provides an exemplary node-level rollback implementation method, which may include the following: If the firmware writing of the target device fails, the network is interrupted, there is an unexpected power outage, or the device becomes unresponsive, the firmware upgrade task of the target device is terminated only, and the original firmware that is pre-backed up locally is used to perform a rollback operation on the target device. After the firmware to be upgraded is written, a verification is performed. If the verification fails, the firmware upgrade task of the target device is terminated only, and the original firmware that is pre-backed up locally is used to perform a rollback operation on the target device.

[0064] Write failure refers to the target device returning an error response during the write process or the write not completing within the specified time. Network interruption refers to the unavailability of the internal LAN path between this node and the master controller. Unexpected power failure refers to an unplanned interruption of input power during the write process. Device unresponsiveness refers to the target device failing to respond to bus access within the specified time. Rollback operation refers to rewriting the target device with the locally backed-up original firmware, restoring the target device to the firmware version before the write.

[0065] In this embodiment, the judgment and handling of the above four types of abnormal situations are all completed locally by the slave controller of this node. Once any of the above situations is detected, the slave controller only terminates the firmware upgrade task corresponding to the target device on its own machine, and then retrieves the pre-backed-up original firmware from the backup area of ​​this node and rewrites it back to the target device. The firmware upgrade tasks of other devices managed by this controller and other nodes are not affected and continue to complete their respective writing processes. For example, if the I2C path between the switch and the target device is interrupted during the firmware writing process on a certain substrate, the slave controller of this node terminates this upgrade task and writes the switch firmware back to the original version. Other devices that have already completed the writing on the same node and the writing tasks that are in progress on other nodes are not affected. In addition, a read comparison is performed after the firmware to be upgraded is completed. For example, the verification here can be done by cyclic redundancy check comparison; it can also be done by byte-by-byte comparison; it can also be done by signature verification, as long as it can determine whether the writing result is consistent with the firmware to be upgraded. This invention does not impose any limitations on this. If this comparison fails, the firmware upgrade task for this target device will be terminated, and the original firmware that was previously backed up locally will be rolled back.

[0066] In this embodiment, after all tasks are completed, this node compiles statistics on the final firmware version, upgrade success and failure results, self-test status, and exception information for each node, and reports them to the main controller. For example, after summarizing the reports from each node, the main controller generates an upgrade report. The report includes records such as firmware source, upgrade time, device number, fault location, power failure record, and lock request record, for subsequent testing and version management.

[0067] As can be seen from the above, this embodiment limits anomaly detection and rollback to the target device and node where the anomaly occurs, so that the write failure of a single node, network interruption, unexpected power failure, device unresponsiveness or verification failure does not terminate other upgrade tasks within the whole machine. The remaining nodes can continue to complete their respective write processes, so that the firmware upgrade process of the whole machine is not interrupted due to local anomalies.

[0068] In the above embodiments, the method of generating firmware upgrade conditions is not limited. To avoid the problem that the firmware type and upgrade trigger conditions are manually and statically specified, and therefore do not match the actual hardware state after the model is changed or the board is plugged in or removed, this embodiment also provides an exemplary implementation method for generating firmware upgrade conditions, which may include the following: Under at least two of the following system operating conditions: system power-on and running, normal operating system shutdown with board power-on, and system idle and restartable, each managed device is detected. When a managed device has a running partition and a backup partition under system power-on and running conditions, and is allowed to switch between the running and backup partitions, if the backup partition is writable while the running partition is running, the managed device's firmware is classified as Type 1 firmware. The corresponding upgrade trigger condition is set as follows: when the system is running, writing to the backup partition is allowed; when the system enters an idle and restartable state, restarting to the backup partition is allowed. Under the following conditions: when the managed device is under normal operating system shutdown with board power-on, the power supply domain is still valid, the presence signal still indicates presence, and the device identifier is successfully read. If bus communication is normal, the firmware category of the managed device is determined to be Category 2 firmware, and the corresponding upgrade trigger conditions are set as follows: the overall power status indicates that the operating system has been normally shut down, the power supply domain is still valid, the presence signal is valid, and bus communication is normal. If the managed device is in a normal shutdown state with the operating system powered on and the board kept powered on, but the device identifier is unreadable, the device is not in place, or the bus is unresponsive, and the bus address response is normal and the presence signal is valid when the overall system is powered on, then the managed device is determined to be Category 3 firmware, and the corresponding upgrade trigger conditions are set as follows: the overall system is in a powered-on state, the power-on self-test is completed, the power supply domain is valid, the presence signal is valid, and the bus address response is normal. Based on the firmware category and corresponding upgrade trigger conditions of each managed device, firmware upgrade conditions are generated.

[0069] Among these, "Idle and Rebootable System" refers to the system's state when it is idle enough to perform a reboot. The backup partition is the target backup partition for the aforementioned write process. "Normal Bus Communication" means that access on the bus receives a response from the target device within a specified time. "Normal Bus Address Response" means that an access to the target device's bus address receives a response signal. "Power-On Self-Test Complete" means that the BIOS's power-on self-test process has ended without reporting any serious fault errors.

[0070] In this embodiment, the controller initiates an access to each managed device under the three overall operating conditions described above, and records the access results as probe data. The determination begins with the probe data from the overall system power-on and running condition. If the target device has a running partition and a backup partition, and switching between the two partitions is allowed, and the backup partition is writable while the running partition is running, then it is classified as the first type of firmware. If the above conditions are not met, the determination shifts to the probe data from the operating system normal shutdown and board power-on condition. If the power supply domain is still valid, the presence signal still shows as present, the device identifier is successfully read, and bus communication is normal, then it is classified as the second type of firmware. If the device identifier is unreadable, the device is not present, or the bus is unresponsive under the operating system normal shutdown and board power-on condition, but the bus address response is normal and the presence signal is valid under the overall system power-on and running condition, then it is classified as the third type of firmware. For example, the firmware of the management controller itself has two switchable partitions and the spare partition is writable when it is powered on, so it is classified as the first type of firmware; the motherboard CPLD, system management board CPLD, fan board CPLD, switch board CPLD and power distribution board CPLD are still powered and addressable when powered off, so they are classified as the second type of firmware; the firmware of the hard drive backplane CPLD and the switch-related firmware on the switch board is not addressable when powered off but is addressable after power-on, so it is classified as the third type of firmware.

[0071] In this embodiment, the signals used for the above-mentioned detection may include one or more of the following: PGOOD, ACPI operating state and shutdown state, BIOS power-on self-test state, CPLD reset reason register, presence signal, I2C response, VPD and FRU information. Specifically, PGOOD is used to determine whether the power supply domain of the target device is valid; the ACPI operating state (S0 state) indicates that the entire machine is powered on and running, while the shutdown state (S5 state) indicates that the operating system is soft-shutdown but may still maintain power supply; the BIOS power-on self-test state is used to determine whether the power-on self-test is complete and whether the link is stable; the CPLD reset reason register is used to distinguish between normal shutdown, abnormal power failure, and power failure reset; the presence signal is used to determine whether the board or device is physically present; the I2C response is used to determine whether the device can communicate and whether its address can be scanned; and the VPD and FRU information are used to read the device's identity, model, and serial number to determine whether it is present and whether it matches the model. For example, the above-mentioned detection can be performed once after the whole machine is powered on; it can also be performed when the whole machine's operating condition changes; or it can be performed by polling at a fixed period. As long as the detection data of each managed device can be obtained under at least two whole machine operating conditions, the present invention does not make any limitation in this regard.

[0072] In this embodiment, the process of generating firmware upgrade conditions is completed locally from the controller. The resulting firmware upgrade conditions are recorded with a correspondence between the device identifier, firmware category, and upgrade trigger condition, no longer relying on a configuration table pre-filled manually. For example, two servers of the same model may have different firmware category compositions recorded in their firmware upgrade conditions due to different circuit boards they are plugged into.

[0073] As can be seen from the above, this embodiment detects each managed device under at least two of the following conditions: the whole machine is powered on and running, the operating system is powered off and the board is powered on, and the whole machine is idle and can be restarted. The device is then classified into the first type of firmware, the second type of firmware, or the third type of firmware based on its partitioning capability, power supply domain validity, in-situ signal, bus readability, and link stability. This ensures that the upgrade trigger condition for each device is taken from its actual hardware state. As a result, when the model is changed or the board changes, the firmware upgrade condition that matches the hardware can be obtained without reconfiguration.

[0074] In the above embodiments, there is no limitation on whether the firmware upgrade conditions change after generation. To avoid the problem of using the old values ​​for firmware upgrade conditions after the hardware topology changes, leading to the selection of the writing timing according to the incorrect firmware category, this embodiment also provides an exemplary firmware upgrade condition update implementation method, which may include the following: When a target managed device is detected to have undergone board insertion / removal, topology change, firmware update, or firmware restart, the target managed device is re-detected under at least two of the following system conditions: system power-on operation, normal operating system shutdown with board power-on, and system idle and restartable operation. Based on the new detection data of the target managed device, the firmware category and upgrade trigger conditions of the target managed device are re-determined. Based on the new firmware category and new upgrade trigger conditions of the target managed device, the firmware upgrade conditions are updated.

[0075] Board insertion / removal refers to the action of installing or removing a board from a chassis or backplane, which can be detected by in-situ signals or changes in VPD. Topology change refers to a change in the connection relationship between devices, including changes in bus mounting relationships and power domain affiliation. Firmware update operation refers to the operation of introducing a new version image file for a specific firmware package. Firmware restart operation refers to the self-restart of the target device corresponding to a specific firmware package. Target managed device refers to the managed device that has undergone the above changes.

[0076] In this embodiment, the slave controller only re-probes the managed device that has changed, instead of re-probing all devices in the entire system. For example, if a substrate is replaced and the presence signal on that substrate changes, the slave controller of that node will re-probe each newly installed device on the substrate under both system power-on and operating system shutdown conditions with board power-on protection. Based on the new probe data, the firmware category and upgrade trigger conditions will be re-determined, and the new values ​​will replace the original records in the firmware upgrade conditions. Exemplarily, the re-probe can be triggered by an interrupt; it can also be triggered by polling after a signal change is detected; of course, in addition to the above two methods, the master controller can also issue a unified trigger command after receiving the topology report, as long as the probe data can be obtained again after the hardware change. This invention does not impose any limitations on this.

[0077] As can be seen from the above, this embodiment re-probes the target managed device and updates the firmware upgrade conditions based on the new detection data after detecting board insertion / removal, topology change, firmware package update operation, or firmware package restart operation. This ensures that the firmware category and upgrade trigger conditions always follow the current state of the hardware, avoiding incorrect flashing caused by selecting the writing time based on old, expired records.

[0078] Furthermore, this invention also provides a firmware upgrade method. This embodiment illustrates the firmware upgrade method performed by the main controller, such as... Figure 2 As shown, this embodiment may include the following: S201: Receive a resource lock request sent from the controller. The resource lock request is used to request a resource lock of the target resource lock type.

[0079] The main controller refers to the management controller deployed on the server motherboard. It is the server's only external management node and also the scheduling node that manages all slave controllers in a unified manner. A resource lock request is a message sent by a slave controller before it needs to operate on system resources or shared resources. This message carries the target resource lock type and the node identifier of the slave controller sending the request. The target resource lock type refers to the type of resource lock requested by the slave controller, which can include any one of the following: system restart lock, power-saving lock during shutdown, shared power domain lock, and shared bus lock.

[0080] In this step, the main controller receives resource lock request requests from each slave controller via an internal LAN channel. For example, the channel can be configured using a static Internet Protocol address plus a preset Media Access Control (MAC) address, assigning each node a fixed address; alternatively, it can be configured by dynamically allocating addresses and binding them to board identifiers. Of course, besides these two methods, a private link configuration based on chassis management can also be used, as long as an independent channel can be established between the main controller and each slave controller. This invention does not impose any limitations on this.

[0081] The target resource lock type is determined by the slave controller when the target triggering condition is met under the current overall system condition, based on the target firmware category of the target device and the target device's occupation of overall system resources or shared resources during the firmware upgrade process. The target triggering condition is determined by the slave controller based on the firmware upgrade condition. The firmware upgrade condition record is based on the firmware category and upgrade triggering condition determined by the detection data of the target device under at least two overall system conditions. The target triggering condition includes the target overall system condition that allows upgrade and the write-allowed status of the target device under the target overall system condition.

[0082] In this step, the master controller does not need to determine which type of lock to request itself. Instead, it receives the target resource lock type already determined by the slave controller and performs subsequent operations accordingly. Since the target resource lock type is determined by each slave controller based on its firmware type and write channel affiliation, the master controller only needs to process the lock occupancy status. The master controller receives the target trigger condition uploaded by the slave controller and uses this condition as reference information for subsequent processing. For example, the slave controller can include the value of the target trigger condition in the resource lock request; it can also report it separately; of course, in addition to the above methods, the master controller can also query the requesting slave controller after receiving the request, as long as the master controller can know the target trigger condition corresponding to this request. This invention does not impose any limitations on this.

[0083] S202: Authorize or deny resource lock request requests based on the global state and resource lock state.

[0084] The global state refers to the state quantity maintained by the main controller, representing the current stage of the entire machine. Its values ​​include abnormal power failure state, power-on backup state, power-on initialization state, running state, and idle restartable state. The resource lock state refers to the recorded information of whether each resource lock is currently occupied, which node occupies it, and for how long.

[0085] In this step, the master controller combines the current global state with the current resource lock state to determine whether to grant lock permission to the slave controller. This considers both the current state of the entire system (whether it allows the operation corresponding to the lock) and whether the lock is already held by another slave controller. For example, the master controller maintains a holder field and an occupancy flag for each lock. Only when the occupancy flag is empty and the current global state allows the operation will the master controller set the holder field to the slave controller requesting the lock; otherwise, the request is rejected, or the slave controller is placed in a waiting queue.

[0086] S203: Return an authorization result or rejection result to the slave controller so that the slave controller can perform a write operation on the target device when the current overall operating conditions still meet the target trigger conditions and an authorization result is received.

[0087] Here, an authorization result refers to the return result where the master controller agrees to allocate the requested resource lock to the slave controller. A rejection result refers to the return result where the master controller does not agree to the allocation.

[0088] In this step, the master controller can return the final result to the slave controller that initiated the request via the internal LAN. The slave controller will then determine again at this node whether the current overall operating condition still meets the target triggering condition. Only when it is determined again that the condition is met and the authorization result is received will the write operation be performed on the target device.

[0089] As can be seen from the above, this embodiment centrally receives resource lock request requests from each slave controller by the master controller, and uniformly authorizes or denies them according to the global state and resource lock state. This ensures that the whole machine restart permission, power-off power-saving state, shared power domain and shared bus are only open to one slave controller at any given time. When multiple slave controllers execute local firmware upgrade tasks in parallel, they will not change the same whole machine resources or shared resources at the same time. At the same time, since the target resource lock type and target triggering conditions are determined by the slave controller according to the detection data of its own node, the judgment work is distributed among the slave controllers. The scheduling process of the master controller is consistent with the actual working conditions of each slave controller on the whole machine.

[0090] It should be noted that there is no strict order of execution between the steps in this invention. As long as they conform to the logical order, these steps can be executed simultaneously or in a certain preset order. Figures 1-2 This is just an illustrative example and does not mean that this is the only possible execution order.

[0091] In the above embodiments, the master controller is not limited in how it grants or denies permissions for different global states. To avoid the problem of resource locks being opened to slave controllers during power-on initialization or abnormal power failure, resulting in writes being performed during unreliable power supply phases, this embodiment also provides an exemplary implementation method for global state-based decision-making, which may include the following: The global states include abnormal power-down state, power-on backup state, power-on initialization state, running state, and idle / rebootable state. Based on the global state and resource lock state, when the global state is idle / rebootable state and the target resource lock type corresponding to the resource lock request is a system-wide restart lock, the master controller allocates a system-wide restart lock. When the global state is power-on backup state and the target resource lock type corresponding to the resource lock request is a power-on backup lock, a power-on backup lock is allocated. In the power-on initialization state, the firmware upgrade task is paused, and the corresponding resource lock request is rejected until power-on initialization is complete and the system enters the running state. When the global state is running state and the target resource lock type corresponding to the resource lock request is a shared bus lock, a shared bus lock is allocated. When the global state is abnormal power-down state, the corresponding resource lock request is rejected, and the slave controller corresponding to the resource lock request is notified to pause the firmware upgrade task.

[0092] Among them, the abnormal power-down state refers to the global state indicating that the entire machine has experienced an unplanned input power interruption. The power-on power-preservation state refers to the global state indicating that the entire machine has completed a normal operating system shutdown but is still powered on. The power-on initialization state refers to the global state indicating that the entire machine has just been powered on and all controllers and buses are still in the initialization process. The running state refers to the global state indicating that the entire machine has completed its power-on self-test and the operating system is in normal operation. The idle and restartable state refers to the global state indicating that the entire machine is not currently processing any business and can perform a restart switch. The entire machine restart lock is the resource lock corresponding to the permission to perform a restart operation on the entire machine. The power-on power-preservation lock is the resource lock corresponding to the condition that the entire machine remains powered on. The shared bus lock is the resource lock corresponding to the access right to the same bus shared by multiple devices.

[0093] In this embodiment, a fixed correspondence is established between the global state and the target resource lock type; authorization is granted only when the two match. For example, if a slave controller requests a system restart lock while its global state is running, the master controller will not allocate it because the system is currently carrying services. However, if the same slave controller requests a system restart lock again after its global state switches to an idle restartable state, it will be allocated. Similarly, if a slave controller requests a shared bus lock during the power-on initialization phase, the master controller will first suspend its firmware upgrade task and reject the request. The request will be accepted only after power-on initialization is complete and the global state enters the running state. Furthermore, when the global state is in an abnormal power-down state, the master controller will reject all resource lock requests and notify the requesting slave controller to suspend its local firmware upgrade task.

[0094] As can be seen from the above, this embodiment maps the five global states to resource lock types one by one, so that the whole machine restart only occurs in the idle restartable state, the power-on write only occurs in the power-on state, and the bus write only occurs in the running state. Furthermore, it prevents resource locks from being opened to any slave controller during the power-on initialization phase and the abnormal power-off phase, thereby avoiding the write operation from occurring in a phase where the global state does not match its resource requirements, and ensuring the security of firmware upgrade operations.

[0095] In the above embodiments, there is no limitation on how the global state itself changes with the overall machine operation. To avoid the problem of being unable to determine which state to use as the basis for decision when multiple states coexist, resulting in contradictory results for different slave controllers at the same time, this embodiment also provides an exemplary implementation method for global state switching, which may include the following: When server power-on initialization is detected, the global state is switched to the power-on initialization state. When power-on initialization is complete and the server enters the overall machine startup and operation mode, the global state is switched to the running state. When the server enters the normal operating system shutdown and board power-saving mode, the global state is switched to the shutdown power-saving state. Based on the overall machine idle quantification value, overall machine operation and maintenance status, and the upgrade task status of each slave controller, it is determined whether the overall machine meets the idle restart condition. When it is determined that the server meets the idle restart condition, the global state is switched to the idle restartable state. When an abnormal power failure is detected, the global state is switched to the abnormal power failure state, and entering the shutdown power-saving state is prohibited while the global state is in the abnormal power failure state until the abnormal power failure is recovered. Among these, the abnormal power failure state has a higher priority than the shutdown power-saving state, the shutdown power-saving state has a higher priority than the power-on initialization state, the power-on initialization state has a higher priority than the idle restartable state, and the idle restartable state has a higher priority than the running state.

[0096] The "idle and restartable condition" refers to the combined condition that the entire machine is idle enough and there are no ongoing maintenance operations. "Abnormal power failure recovery" means that the machine's input power has been restored to normal and the main controller has reconfirmed the status of each node.

[0097] In this embodiment, the main controller performs global state switching according to the five scenarios described above. When multiple state switching conditions are met simultaneously, the highest priority value is selected as the current value. For example, if the entire machine has just been powered on and is still in the power-on initialization process, and an idle condition for a certain period is detected, the power-on initialization state is selected as the current global state according to priority. As another example, if the entire machine has entered a normal operating system shutdown and board power-saving mode, and an external power interruption is detected, the global state switches to the abnormal power-down state. Even if the power-saving condition is met again during the abnormal power-down state, the system does not switch back to the shutdown power-saving state until the external power is restored and the main controller reconfirms the status of each node.

[0098] In this embodiment, there is a coordination relationship among the idle restartable state, the power-off state, and the running state. The spare partition of the device corresponding to the first type of firmware can be written in the running state, but the restart switch must wait until entering the idle restartable state before it can be performed. Batch writing of the device corresponding to the second type of firmware is only performed in the power-off state. The device corresponding to the third type of firmware is only written under the condition of power-on operation and stable link. For example, the above priority relationship can be stored locally on the main controller in the form of a state priority table; it can also be implemented in the form of state machine transition conditions; of course, in addition to the above two methods, it can also be implemented in a state queue arranged by sequence number, as long as a unique value can be determined when multiple states are simultaneously established. The present invention does not impose any limitations on this.

[0099] As can be seen from the above, this embodiment sets the trigger conditions for state switching for five scenarios: power-on initialization, operation, power-on shutdown, idle restart, and abnormal power failure. It also sets a clear priority order for the five states, so that the main controller can obtain a unique global state value at any time, thereby making non-contradictory results when multiple nodes request resource locks simultaneously. Furthermore, since the abnormal power failure state has the highest priority and is prohibited from entering the power-on shutdown shutdown state during its existence, the writing of the second type of firmware will not start when the power supply has not been restored.

[0100] In the above embodiments, there are no limitations on how the firmware image to be upgraded enters the whole machine and is delivered to the node responsible for writing. In order to avoid the firmware file being replaced or sent to a node that is not under its management during the transmission process, causing the problem of incorrect flashing, this embodiment also provides an exemplary image distribution implementation method, which may include the following: Upon receiving a firmware image upload request, the system performs integrity and validity checks on the firmware image data. After both integrity and validity checks pass, it determines the management affiliation of the target device corresponding to the firmware image data based on pre-stored hardware topology relationships. If the target device belongs to the main controller, the firmware image data is added to the main controller's local upgrade queue. If the target device belongs to a slave controller, the firmware image data is encrypted and sent point-to-point to the corresponding target slave controller according to a preset binding relationship, allowing the target slave controller to perform a secondary verification of the received firmware image data. Each slave controller only receives firmware image data sent by the main controller according to the preset binding relationship.

[0101] Firmware image upload request refers to a message initiated by the operations and maintenance terminal through the external management interface, requesting the writing of a firmware image file to the server. Integrity verification refers to the verification of whether the firmware image file itself is corrupted, missing, and readable; it generally includes two checks: verification and digital signature. Validity verification refers to the verification of whether the firmware image file version and compatible device model match the server. The overall hardware topology relationship refers to the pre-stored correspondence between each device and its respective management node. Management affiliation refers to whether a target device is written by the master controller or a slave controller. The local upgrade queue refers to the sequence of upgrade tasks maintained by the master controller for each target device it is responsible for writing to. Preset binding relationship refers to the fixed correspondence between each slave controller and its subordinate target devices. Secondary verification refers to the integrity and validity verification performed again by the target slave controller after receiving the firmware image data.

[0102] In this embodiment, the main controller centralizes the access points of all firmware images at one location. It performs two checks on incoming images, one at the previous level, before determining ownership based on the overall hardware topology. For example, if a firmware image corresponds to the basic input / output system firmware or a complex programmable logic device on the motherboard, it belongs to the main controller and is added to its local upgrade queue. If a firmware image corresponds to a device on a substrate, it belongs to the slave controller of that substrate. The main controller encrypts the firmware according to a preset binding relationship and sends it point-to-point to that slave controller; other slave controllers will not receive this firmware. Upon receiving the firmware, the target slave controller performs another integrity and validity check, forming a two-stage multi-check process. Exemplarily, the encryption method used for point-to-point transmission can be symmetric key encryption, asymmetric key encryption, or a signed transmission method, as long as the firmware image transmission process on the internal local area network remains intact and its source is verifiable. This invention does not impose any limitations on this.

[0103] As can be seen from the above, this embodiment achieves this by having the main controller uniformly receive firmware image upload requests and sequentially perform integrity and validity checks, thus eliminating files that do not meet the requirements before distribution; by determining the management affiliation of the target device based on the overall hardware topology and encrypting it according to the preset binding relationship before sending it point-to-point, each slave controller only receives the firmware image belonging to its own node, thereby eliminating the possibility of cross-delivery and overriding; and by having the target slave controller perform secondary verification, any damage or replacement that occurs during data transmission can be detected before writing, ensuring secure firmware upgrades.

[0104] In the above embodiments, there are no limitations on how resource locks are continuously tracked after allocation and reclaimed under abnormal circumstances. To avoid the problem of a resource lock being occupied by a node that has been unresponsive for a long time, causing other nodes to be unable to acquire the lock and wait indefinitely, this embodiment also provides an exemplary implementation method for maintaining the state of resource locks, which may include the following: Record and update resource lock status; resource lock status includes lock type and lock status information. Lock types include whole machine restart lock, power-off lock, shared power domain lock, and shared bus lock. Lock status information includes occupancy status, holder ID, application time, and lease duration. When a target resource lock application request is received from a target slave controller, and the target lock resource corresponding to the lock type requested in the application request is in an occupied state, add the target slave controller to the lock allocation waiting queue. When the target lock resource is released, allocate the target lock resource to the slave controllers in the lock allocation waiting queue according to the order of the lock allocation waiting queue and based on the current global state. When the holding time of the target lock resource exceeds the lease duration, or the slave controller holding the target lock resource goes offline, release the target lock resource or set the target lock resource to a pending recovery state.

[0105] In this context, "Occupied Status" refers to whether a resource lock is currently held by a slave controller. "Holder Identifier" refers to the node number of the slave controller currently holding the resource lock. "Request Time" refers to the moment the slave controller submits its resource lock request. "Lease Duration" refers to the maximum time a slave controller is allowed to hold the resource lock. "Target Lock Resource" refers to the specific resource lock being requested. "Lock Allocation Waiting Queue" is a queue arranged in the order multiple slave controllers request the same target lock resource. "Pending Recovery Status" indicates that the resource lock is held but not yet available for allocation to other slave controllers.

[0106] In this embodiment, the master controller maintains a separate status record for each lock type and updates this record after each allocation, release, and timeout. For example, if the lease duration of a shared power domain lock is 30 minutes, and a slave controller acquires the lock at 9:00 AM, but fails to release it by 9:30 AM, the master controller determines in the record that the holding time has exceeded the lease duration and releases it, or, if the node's status cannot be confirmed, configures it to a pending recovery state. Similarly, if a slave controller holding a shared bus lock no longer responds to the master controller's polling on the internal LAN, it is considered offline, and the shared bus lock is either released or set to a pending recovery state. Furthermore, when multiple slave controllers request the same shared bus lock sequentially, the master controller queues them in the order their requests arrive, and allocates locks according to the queue order and the current global state after the lock is released.

[0107] As can be seen from the above, this embodiment records the occupancy status, holder identifier, application time and lease duration for each resource lock, and allocates them according to the lock allocation waiting queue order, and releases or sets them to a pending recovery state when the holding time exceeds the lease duration or the holder goes offline. This ensures that the resource lock will not be occupied for a long time due to the loss of response of individual nodes, and other nodes can obtain the corresponding whole machine resources or shared resources according to the queue order.

[0108] In the above embodiments, there is no limitation on how the master controller arranges the order of the slave controllers. To avoid the problem of write tasks that do not occupy shared resources queuing unnecessarily due to waiting for arbitration, and the problem of multiple firmware writes within the same node competing for local channels, this embodiment also provides an exemplary upgrade scheduling implementation method, which may include the following: Receive firmware categories and upgrade trigger conditions reported by each slave controller; determine the upgrade scheduling order of each slave controller based on the current global state, firmware categories of each slave controller, resource lock requests of each slave controller, and resource lock status; allow slave controllers that do not need to occupy whole machine resources or shared resources to execute local firmware upgrade tasks in parallel without conflicting with other slave controllers; execute local firmware upgrade tasks of slave controllers that need to occupy whole machine resources or shared resources according to the resource lock allocation order; wherein, upgrade tasks of multiple firmware within the same slave controller are executed serially in a preset order.

[0109] The upgrade scheduling order refers to the execution order of the local firmware upgrade tasks for each slave controller as arranged by the master controller. A slave controller that does not require the use of system resources or shared resources refers to a slave controller whose write operation is completed locally, does not change the system's power state, and does not exclusively occupy any external bus. The resource lock allocation order refers to the order in which the master controller allocates the same resource lock to different slave controllers. Multiple firmware upgrade tasks within the same slave controller refer to multiple write tasks sequentially queued in the local upgrade queue on the same node.

[0110] In this embodiment, the master controller first gathers the firmware categories and upgrade trigger conditions reported by each slave controller, and then considers them together with the current global state, the resource lock requests of each slave controller, and the resource lock status to determine the upgrade scheduling order for this round. For example, if a slave controller's write tasks in this round are all for local devices and do not require a system reboot or occupy the shared bus, then this slave controller does not need to wait for the resource lock allocation results of other nodes and can perform local writes simultaneously with other conflict-free nodes; if another slave controller needs to request a system reboot lock in this round, then this slave controller will queue up and execute according to the allocation order of the system reboot lock. In addition, multiple firmwares within the same slave controller, regardless of their category, are written serially one by one in the preset order arranged in the local upgrade queue, and two write tasks will not be started simultaneously. For example, the preset order of multiple firmwares within the same slave controller can be arranged according to the device's address on the bus from smallest to largest; it can also be arranged according to the physical location of the device on the board from nearest to farthest; or it can be arranged according to the grouping order of firmware categories, as long as multiple write tasks on the same node are not performed simultaneously, the present invention does not impose any limitations on this.

[0111] As can be seen from the above, this embodiment distinguishes whether each slave controller needs to occupy whole machine resources or shared resources, so that nodes that do not need to occupy shared resources can execute local firmware upgrade tasks in parallel with other conflict-free nodes, while nodes that need to occupy shared resources can execute according to the resource lock allocation order. This reduces the total time required for whole machine firmware upgrade and maintains the order of shared resource usage. Furthermore, by limiting the serial execution of multiple firmware upgrade tasks within the same slave controller, it avoids write failures caused by multiple write tasks competing for local channels on the same node.

[0112] In the above embodiments, to address the issue of how the main controller obtains and maintains firmware information across the entire machine, and to avoid the problem that the firmware version can only be queried node by node and cannot be obtained all at once, this embodiment also provides an exemplary implementation method for maintaining firmware information across the entire machine, which may include the following: The main controller also performs the following operations: establishes communication connections with each slave controller via the internal LAN; calls each slave controller through the management interface to collect firmware information of the managed devices of each slave controller, including at least one of firmware model, version number, historical upgrade progress, and device location information; aggregates the collected firmware information of each slave controller and synchronizes it to the message bus of the main controller; displays the overall firmware information to the user through a unified external management interface; and polls the online slave controllers according to a preset timer to update the overall firmware information.

[0113] The communication connection refers to the bidirectional communication link established between the master controller and the slave controller, which is carried over the internal local area network. The management interface is the interface provided by the slave controller to the master controller for reading firmware information and issuing control commands. It can be implemented using the Redfish management interface or the intelligent platform management interface. Firmware information describes the current status of the firmware running on a target device. Firmware model refers to the model and product series identifier of the device corresponding to the firmware. Version number refers to the version identifier of the currently running firmware. Historical upgrade progress records the execution results of previous firmware upgrade operations, including upgrade start time, upgrade end time, success / failure values, and failure reasons. Device availability information indicates whether the target device is currently accessible. The message bus is the common channel for message transmission between various software modules within the master controller. It can be implemented using a desktop bus (DBus) or other inter-process communication methods. The unified external management interface is the management entry point provided by the master controller to the maintenance team. The overall firmware information refers to the data set representing the firmware status of all target devices within the entire system, formed by the main controller aggregating the firmware information reported by each slave controller. A preset timer refers to a timing unit within the main controller that triggers once at a fixed period. An online slave controller refers to a slave controller that can be accessed by the main controller on the internal local area network.

[0114] In this embodiment, the main controller first establishes a communication connection with each slave controller via the internal local area network, and then calls each slave controller one by one through the management interface to read the firmware information of each target device in its jurisdiction. For example, the firmware information acquisition process begins with the controller's power-on initialization. The slave controller reads the level values ​​of the GPIO signals it is connected to. Different physical locations of the substrate correspond to different level values, which determine its own board identifier, serving as the unique physical location identifier for that slave controller. Next, the slave controller calls pre-configured network parameters according to its board identifier to complete network initialization. Each board identifier is pre-configured with a unique Media Access Control address and a static Internet Protocol address. Then, the master controller performs presence detection on all slave controllers with preset addresses via its internal LAN submodule. Next, the master controller reads the firmware model, firmware version number, historical upgrade progress, and device presence information of each slave controller's substrate through the Redfish management interface. This information is then aggregated and synchronized to its own message bus and presented to the maintenance end via a unified external management interface. Finally, the master controller periodically polls all present slave controllers according to a preset timer, replacing previously saved values ​​with the latest read values, ensuring that the overall firmware information queried by the maintenance end remains up-to-date. For example, the polling period of the preset timer can be 30 seconds, 1 minute, or 5 minutes; it can also be set according to the different operating conditions of the whole machine, such as polling with a shorter period when the whole machine is in the running state and polling with a longer period when the whole machine is in the power-off state; of course, in addition to the above methods, the slave controller can actively report when the firmware information changes, and the master controller can only fill in the information of the unreported nodes when the timer expires, as long as the firmware information of the whole machine queried by the operation and maintenance terminal is consistent with the actual value of each node, the present invention does not make any limitation in this regard.

[0115] As can be seen from the above, this embodiment collects the firmware information of the target devices under the jurisdiction of each slave controller through the internal local area network by the main controller, summarizes and synchronizes it to the message bus and presents it through a unified external management interface, so that the operation and maintenance terminal can obtain the firmware model, version number, historical upgrade progress and on-site information of all devices in the whole machine with one query.

[0116] In the above embodiments, regarding how the main controller handles anomalies occurring on individual nodes during multi-node parallel upgrades, and to avoid the entire upgrade process being halted due to a write error on a single node, this embodiment also defines an exemplary upgrade process monitoring implementation method, which may include the following: The main controller also performs the following operations: During the firmware upgrade process, it uniformly polls and monitors the firmware upgrade status of each slave controller; when a firmware anomaly is detected, such as write failure, network interruption, unexpected power failure, or device unresponsiveness, it identifies the slave controller and device that experienced the anomaly, which are defined as the target slave controller and the target device to be upgraded, respectively, for ease of description; it sends a rollback notification to the slave controller that experienced the anomaly, so that the slave controller that experienced the anomaly only terminates the currently erroneous firmware upgrade task and rolls back the original firmware backed up locally; it keeps the firmware upgrade tasks of other slave controllers that did not experience anomalies running; when an abnormal power failure is detected, it switches the global state to the abnormal power failure state and locks the allocated global resources to the pending recovery state.

[0117] Firmware upgrade status refers to the state variable indicating which stage a slave controller is currently in: waiting, writing, verification, rollback, or termination. Rollback notification is a message sent by the master controller to a node after confirming an anomaly, requesting that the current firmware upgrade task be aborted and the original firmware restored. Global resource locks refer to all resource locks that the master controller has currently allocated to each slave controller.

[0118] In this embodiment, during the firmware upgrade process, the master controller polls the firmware upgrade status of each slave controller according to a preset timer. If any of the following conditions are found in the polled status values: write failure, network interruption, unexpected power failure, or device unresponsiveness, the master controller identifies the target slave controller and the target managed device that experienced the anomaly based on the node identifier and device identifier that reported the status value, and sends a rollback notification to that slave controller individually. Upon receiving the rollback notification, the slave controller only terminates the currently malfunctioning firmware upgrade task; all other tasks already scheduled in the local upgrade queue and all tasks of other nodes remain unaffected. The slave controller then uses the locally backed-up original firmware to perform the rollback. For example, if the firmware of a switch on a certain substrate returns an error response during the writing process, the master controller determines that the slave controller that has encountered the error is the slave controller on that substrate based on the node identifier, and determines that the target device that has encountered the error is the switch based on the device identifier. Therefore, it only sends a rollback notification to the slave controller for the switch, while the firmware of complex programmable logic devices that have already been written on the same substrate and the writing tasks that are in progress on other substrates continue to be executed. As another example, if a slave controller does not return a status value in three consecutive polls, the master controller determines that the node device is unresponsive and sends a rollback notification for the target device that the node is currently writing to. For example, the rollback notification may carry the device identifier of the target device and the sequence number of this upgrade task, so that the recipient can only perform the rollback for that device and that task; it may also carry a list of tasks that are allowed to continue execution, so that the recipient can continue to process other tasks that have not yet started on this node after the rollback; of course, in addition to the above two methods, the rollback notification may also only carry an exception type identifier, allowing the recipient to determine the tasks to be terminated, as long as it can ensure that the node that has an exception only stops the firmware upgrade task that malfunctioned, and the present invention does not impose any limitations on this.

[0119] In this embodiment, if the master controller detects an abnormal power failure during polling, it switches the global state to the abnormal power failure state and sets all resource locks allocated to each slave controller to a pending recovery state. Unlike the previous embodiment where the slave controller detects and reports the abnormal power failure before the master controller completes the switch, this step is performed directly by the master controller based on its detected overall power status. Therefore, even if a slave controller loses response during the power failure, the global state and resource locks can still be updated synchronously. After the switch, the allocated resource locks are retained but no longer allocated as available resources to other slave controllers until the overall power supply is restored and the master controller confirms the write status of each holding node. Only then are the corresponding resource locks restored to availability or released. For example, after the entire system is powered back on, the master controller can first read the write interruptions reported by each slave controller, release the resource locks held by nodes that have completed writing, retain the resource locks of nodes whose writing was interrupted, and wait for the node to complete the rollback before releasing them.

[0120] As can be seen from the above, this embodiment achieves this by having the main controller uniformly poll the firmware upgrade status of each node during the upgrade process and only sending rollback notifications to nodes that experience abnormalities. This ensures that if a node fails to write, experiences a network interruption, suffers an unexpected power outage, or becomes unresponsive, only the task currently malfunctioning on that node is suspended, while the firmware upgrade tasks of the remaining nodes continue to execute. Furthermore, by having the main controller directly switch the global state to the abnormal power-down state and set the allocated global resource locks to the pending recovery state when the entire machine experiences an abnormal power outage, the ownership and writing of each lock can still be traced after power is restored.

[0121] In the above embodiments, there is no limitation on how the main controller determines whether the resource lock allocation process refers to the upgrade scheduling of the entire machine. In order to avoid the problem of conflict between the current upgrade arrangement of the entire machine and the lock's own occupancy status, this embodiment also provides an exemplary implementation method for monitoring the entire machine upgrade process, which may include the following: The main controller also performs the following operations: receiving firmware categories and upgrade trigger conditions reported by each slave controller; updating the whole machine firmware upgrade scheduling information maintained by the main controller based on the firmware categories and upgrade trigger conditions reported by each slave controller; and authorizing or rejecting the resource lock request when receiving a resource lock request sent by a slave controller, based on the current global state, the whole machine firmware upgrade scheduling information, and the resource lock status.

[0122] Among them, the whole machine firmware upgrade scheduling information refers to the information maintained by the main controller, which records the firmware category and upgrade trigger conditions of each slave controller's devices by node, and arranges the order of whole machine upgrades accordingly.

[0123] In this embodiment, the master controller also receives firmware categories and upgrade trigger conditions reported by each slave controller, and updates the overall firmware upgrade scheduling information it maintains with the newly reported values. Compared with the method in the previous embodiment where the master controller determines the upgrade scheduling order based on the firmware categories and upgrade trigger conditions reported by each slave controller, this embodiment further uses this scheduling information as an input item for resource lock determination: when receiving a resource lock request sent by a slave controller, the master controller simultaneously refers to the current global state, the overall firmware upgrade scheduling information, and the resource lock state to jointly determine the lock allocation result. For example, if the firmware upgrade scheduling information for a certain slave controller records that all devices to be upgraded in the current phase are of type 1 firmware and the upgrade trigger condition is the system being powered on, then the slave controller will be allocated a shared bus lock when it requests one in the running state. In the same round, if another slave controller has devices to be upgraded of type 2 firmware and the upgrade trigger condition is the operating system being normally powered off and the boards being powered on, then although the resource lock request sent by the slave controller in the running state does not conflict with the current global state, the master controller will still reject the request according to the firmware upgrade scheduling information because the system condition corresponding to its upgrade trigger condition has not yet been reached. The lock will be allocated again after the system enters the power-off state. Alternatively, if the firmware upgrade scheduling information shows that a certain slave controller has no devices to be upgraded in this round, then the resource lock request sent by the slave controller thereafter will not be allocated.

[0124] As can be seen from the above, this embodiment sets the allocated global resource locks to a pending recovery state, so that the ownership and writing of each lock can still be traced after the power is restored. In addition, the whole machine firmware upgrade scheduling information is considered in the resource lock allocation process, so that the allocation result is consistent with the current upgrade scheduling of the whole machine, and avoids the node occupying the resource lock before its own upgrade trigger condition is reached.

[0125] This invention also provides a corresponding apparatus for the firmware upgrade method, further enhancing the method's practicality. The apparatus can be described from both a functional module perspective and a hardware perspective. The firmware upgrade apparatus provided by this invention is described below. This apparatus is used to implement the firmware upgrade method provided by this invention. In this embodiment, the firmware upgrade apparatus may include or be divided into one or more program modules. These program modules are stored in a storage medium and executed by one or more processors to complete the firmware upgrade method disclosed in the embodiment. The program module referred to in this embodiment is a series of computer program instruction segments capable of performing a specific function, which is more suitable than the program itself for describing the execution process of the firmware upgrade apparatus in the storage medium. The following description will specifically introduce the functions of each program module in this embodiment. The firmware upgrade apparatus described below and the firmware upgrade method described above can be referred to in correspondence.

[0126] From the perspective of functional modules, see Figure 3 , Figure 3 A structural diagram of the firmware upgrade device provided in this embodiment under a specific implementation, applied to a controller, including: The operating condition acquisition module 301 is used to acquire the current overall operating condition when a firmware upgrade task is received from the target device. The upgrade target determination module 302 is used to determine the target firmware category and target trigger conditions of the target device according to the firmware upgrade conditions. The firmware upgrade conditions are generated based on the detection data of the managed device under at least two system operating conditions, and the firmware category and upgrade trigger conditions corresponding to the managed device are recorded. The target trigger conditions are used to determine the target system operating conditions that allow the target device to be updated with firmware, and the write permission status of the target device under the target system operating conditions. The lock type determination module 303 is used to determine the target resource lock type that the target device needs to apply for when the current whole machine operating condition meets the target triggering conditions, based on the target firmware type and the occupation of whole machine resources or shared resources by the target device during the firmware upgrade process. The lock request module 304 is used to send a resource lock request to the main controller and receive the authorization result or rejection result returned by the main controller based on the global state and the resource lock state; the resource lock request is used to request a resource lock of the target resource lock type; Firmware writing module 305 is used to perform a write operation on the target device when the current overall operating conditions still meet the target triggering conditions and resource lock authorization is obtained.

[0127] From the perspective of functional modules, see Figure 4 , Figure 4 This embodiment provides a structural diagram of the firmware upgrade device in one specific implementation, applied to a main controller. The device may include: The request receiving module 401 is used to receive a resource lock request sent by the slave controller. The resource lock request is used to request a resource lock of the target resource lock type. The target resource lock type is determined by the slave controller when the target triggering condition is met under the current overall operating condition, based on the target firmware category of the target device and the occupation of overall or shared resources by the target device during the firmware upgrade process. The target triggering condition is determined by the slave controller based on the firmware upgrade condition. The firmware upgrade condition record is based on the firmware category and upgrade triggering condition determined by the detection data of the target device under at least two overall operating conditions. The target triggering condition includes the target overall operating condition that allows upgrade and the write-allowed status of the target device under the target overall operating condition. The lock allocation module 402 is used to authorize or deny resource lock request requests based on the global state and the resource lock state. The allocation result return module 403 is used to return an authorization result or a rejection result to the slave controller, so that the slave controller can perform a write operation on the target device when the current overall operating condition still meets the target triggering condition and the authorization result is received.

[0128] The firmware upgrade device mentioned above is described from the perspective of functional modules. Furthermore, the present invention also provides an electronic device, which is described from the perspective of hardware. Figure 5 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. The electronic device includes a memory 501 and a processor 502. The memory 501 stores a computer program, and the processor 502 is configured to run the computer program to perform the steps in any of the firmware upgrade method embodiments described above.

[0129] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the firmware upgrade method embodiments described above when running.

[0130] 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.

[0131] Embodiments of the present invention also provide a computer program product, which includes a computer program configured to execute the steps in any of the firmware upgrade method embodiments described above when running.

[0132] Embodiments of the present invention also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program configured to execute the steps in any of the firmware upgrade method embodiments described above when run.

[0133] The present invention also provides a server, see [link to relevant documentation]. Figure 6The system may include a main controller 601 and at least one slave controller 602. The main controller 601 is deployed on the motherboard of the server, and each slave controller 602 is deployed on the baseboard of the server. Each slave controller 602 is used to implement the steps of the firmware upgrade method executed by the slave controller 602 as described in any of the above embodiments when executing a computer program stored in the memory. The main controller 601 is used to implement the steps of the firmware upgrade method executed by the main controller 601 as described in any of the above embodiments when executing a computer program. For example, the maintenance terminal is connected to the main controller 601 via an external network interface. The main controller 601 and each slave controller 602 are connected via an internal local area network. Each slave controller 602 is further connected to multiple managed devices on its baseboard via its I2C and GPIO. The main controller 601 is the only node that interacts with the maintenance terminal, and each slave controller 602 does not directly provide a management interface to the outside world. For example, a master controller 601 is deployed on the server motherboard, and a slave controller 602 is deployed on each board, enabling firmware upgrades for the master controller 601 and slave controller 602, their BIOS, and the firmware of each board's CPLD and switch. For example, the number of boards can be one, four, eight, or other numbers; the internal local area network can be carried by Ethernet; or it can be carried by other inter-board interconnection channels, as long as an independent communication link can be established between the master controller 601 and each slave controller 602. This invention does not impose any limitations on this.

[0134] In this context, "server" refers to a computing device configured with a motherboard and multiple pluggable cards. The motherboard is the circuit board located at the front of the server, housing the central processing unit (CPU), memory, and external management interfaces. "Baseboard" refers to a circuit board that is pluggably mounted on a chassis or backplane, used to house dedicated functional modules for computing, acceleration, or storage. It can be a general-purpose baseboard for mounting graphics processor modules, forming a computing platform that provides a channel for high-speed data exchange between multiple graphics processors. In some embodiments, the baseboard can also provide power management and heat dissipation support for its mounted modules. "Memory 501" refers to a non-volatile storage medium used to store the aforementioned computer program. The computer program refers to the program code that, when executed by the processor, implements the aforementioned firmware upgrade method. "Internal local area network" refers to a dedicated communication network between the main controller 601 and each slave controller 602, not shared with the server's business network.

[0135] For example, the main controller 601 is internally divided into a network module, an image verification module, a baseboard management module, and an upgrade module. These modules work together to acquire firmware information, manage firmware images, and write firmware. The network module is further divided into an external network submodule and an internal LAN submodule. The former communicates with the maintenance team and provides an external Redfish management interface, while the latter communicates with each slave controller 602. It uses a static Internet Protocol address and a preset Media Access Control (MAC) address configuration. The image verification module performs integrity and validity checks on the firmware image and identifies its firmware type using the image's built-in identifier, determining whether it belongs to the main controller 601 or a slave controller 602. The baseboard management module distributes firmware images belonging to the slave controllers 602 via the internal LAN submodule to the slave controllers 602, collects firmware information and upgrade progress from each slave controller 602, and then presents the aggregated information to the maintenance team through the external management interface. The upgrade module is deployed on both the main controller 601 and each slave controller 602. The upgrade module on the main controller 601 performs firmware writing for devices managed by the main controller 601, while the upgrade module on each slave controller 602 performs firmware writing for its local node and reports the writing progress and results to the baseboard management module. After power-on initialization, the slave controllers 602 first complete identification and communication establishment. Subsequently, the main controller 601 collects the firmware information of the devices managed by each slave controller 602 via the internal local area network. The specific implementation methods of the main controller 601 in establishing communication connections, collecting firmware information, summarizing and presenting it, and uniformly polling and monitoring the firmware upgrade status of each slave controller 602 during the firmware upgrade process can be found in the steps described in the above method embodiments, and will not be repeated here.

[0136] For example, the firmware upgrade process for the server can be as follows: The maintenance server uploads all firmware images to be upgraded to the local storage of the main controller 601 via the external network interface. The main controller 601 performs a round of integrity and validity checks. The main controller 601 identifies the management affiliation of each firmware image according to the pre-stored overall hardware topology. Firmware images belonging to the main controller 601 enter the local upgrade queue, while firmware images belonging to the slave controller 602 are encrypted according to a preset binding relationship and sent point-to-point to the corresponding slave controller 602. Each slave controller 602 only receives firmware images directed to its own node. Each slave controller 602 performs local firmware data writing operations in parallel. Multiple firmware files within the same slave controller are written serially in a preset order. During the writing process, the overall operating conditions corresponding to each firmware category are triggered. During this process, the main controller 601 uniformly polls and monitors the firmware upgrade status of each slave controller 602 and sends rollback notifications individually to nodes that experience abnormalities. After all firmware upgrade tasks are completed, each slave controller 602 counts the final version of each firmware, success and failure results, self-test status and abnormal information of its node and reports them to the master controller 601. The master controller 601 then generates an upgrade report and completes log archiving.

[0137] As can be seen from the above, this embodiment deploys the main controller 601 on the motherboard and each slave controller 602 on a separate substrate and connects them via an internal local area network. The main controller 601 is used for verification, distribution, global status maintenance, and resource lock authorization, while each slave controller 602 is used for local node condition detection, local writing, and local rollback. This avoids over-level writing and allows managed devices on multiple substrates to perform firmware upgrades according to the overall operating conditions of their respective nodes. At the same time, the firmware access, distribution, and writing results across the entire system are recorded on the same server, facilitating subsequent fault location.

[0138] Finally, to make the technical solution of this invention clearer to those skilled in the art, this invention uses the BMC (Browser Control Center) deployed on the server motherboard as the main controller and the MMC (Modifier Control Center) deployed on the server's general-purpose baseboard as an example to illustrate the server firmware upgrade process, such as... Figure 7 As shown, the BMC provides a unique external management interface through which it communicates with users or upper-level management systems. It possesses at least mirror verification, log aggregation, firmware version management, and global resource lock management functions. There are N MMCs, and the managed devices within each MMC can be CPLDs, SWITCHs, etc., and each managed device can serve as the target device in the above embodiments. Both the external network and the internal LAN can support Redfish, for example. The server's global state can be implemented through a global state machine, which may include the following: like Figure 8As shown, during the server's power-on initialization process, the BMC and all MMCs connect to the internal LAN. After power-on initialization, each MMC reads its own GPIO to identify the Board ID. Each MMC then calls the preset static IP (Internet Protocol) address and MAC (Media Access Control Address) based on the Board ID to complete the internal network configuration without manual configuration. The BMC performs presence detection on all MMCs with preset IPs through the internal LAN to confirm the online MMCs. After completing power-on initialization, the BMC establishes communication with the online MMCs and calls them through the Redfish interface. The MMC collects all firmware information from this UBB (Universal Base Board), including firmware model, version number, historical upgrade progress, and device presence information. The BMC aggregates the firmware information of all MMCs and synchronizes it to its own DBus (Desktop Bus). The BMC displays the entire firmware information to the user through a unified external Redfish interface. The BMC polls all online MMCs according to a timer to update the firmware information in real time.

[0139] like Figure 9 As shown, maintenance personnel upload the firmware images to be upgraded to the BMC's local storage via an external network. The BMC performs integrity and validity checks on the images. Integrity checks include file checksums, whether the image is corrupted, and whether it is readable. Validity checks include digital signatures, device model matching, version legitimacy, and whether there is any suspected tampering. After both integrity and validity checks pass, the BMC identifies the management affiliation of each firmware based on a pre-stored hardware topology table. If the firmware belongs to the BMC, such as the BIOS (Basic Input / Output System) or a CPLD under the BMC's jurisdiction, it enters the BMC's local upgrade queue and is upgraded serially on the same node. If the firmware belongs to the MMC, it is encrypted and sent to the corresponding target MMC according to a preset binding relationship. MMCs do not receive firmware that does not belong to them to avoid accidental flashing. After receiving the image, the MMC performs a second verification to confirm its integrity and legitimacy. If the verification passes, the same node performs a serial upgrade. The firmware upgrade process includes at least resource lock application and condition-triggered writing; for details, please refer to the above embodiments.

[0140] like Figure 10As shown, the MMC probes the managed devices on this node, reading one or more of the following: PGOOD, ACPI S0 / S5, BIOSPOST (Power-On Self-Test) status, CPLD reset reason register, presence signal, I2C (Inter-Integrated Circuit) response, and VPD / FRU information. Based on the actual hardware status data read, it generates firmware upgrade conditions, which can be stored in tabular form. For the first type of firmware, the running state has a writable backup partition, and the changeover takes effect upon reboot. For the second type of firmware, it identifies whether the device is in a power-on state. If, after a normal OS shutdown, PGOOD remains valid, presence is confirmed, and I2C communication is possible, then this state is determined, and writability is allowed. For the third type of firmware, it identifies whether the device is powered on. If, after the entire device is powered on, I2C is detectable, presence is confirmed, and the link is stable, then this state is determined, and writability is allowed. When card insertion / removal, topology changes, firmware updates, or reboots are detected, the MMC will re-probe and update the firmware upgrade conditions.

[0141] When the overall idle metric value falls below the preset idle threshold, and the upgrade task for this node has ended and there are no ongoing maintenance operations on the entire machine, it is determined to enter the idle and restartable state. The BMC migrates the global state machine from the running state to the idle and restartable state. The BMC continuously maintains the global state machine and resource lock states. The global state machine states include abnormal power failure state, power-on shutdown state, power-on initialization state, running state, and idle and restartable state, with the priority of each state from high to low as follows: abnormal power failure state, power-on shutdown state, power-on initialization state, idle and restartable state, and running state. Resource locks include the entire machine restart lock, power-on shutdown lock, shared power domain lock, and shared bus lock.

[0142] Each MMC node executes local firmware upgrade tasks in parallel, and multiple firmware updates within the same MMC are executed sequentially according to a preset order. Before performing operations that may affect the entire device or shared resources, the MMC requests the corresponding resource lock from the BMC. The BMC authorizes or queues the requests based on the current global state, the target firmware type, the lock status, and the MMC's in-place status. The MMC that obtains the lock executes the operation, while those that do not obtain the lock enter the lock allocation waiting queue, but this does not affect other conflict-free nodes from continuing to upgrade.

[0143] For the first type of firmware upgrade, the backup partition is written in running mode and verified after writing; after the entire machine enters an idle and rebootable state, a machine reboot lock is requested from the BMC; after obtaining lock authorization, the machine is rebooted and switched to the backup partition to run the new version. For the second type of firmware upgrade, the server has completed a normal shutdown and entered the shutdown power-saving mode based on ACPI entering S5, BMC power status being soft shutdown, PGOOD being valid, and power button status being normal. In addition, it is necessary to distinguish between normal shutdown and abnormal power failure. During normal shutdown, there is an OS shutdown process, ACPI sequential conversion, BMC receiving a shutdown command, PSU AC input being normal, and PGOOD remaining valid; during abnormal power failure, PGOOD is invalid, BMC records AC power failure, CPLD reset reason register records power failure reset, and OS has no normal shutdown record. Before the upgrade, the PSU power margin is checked, the power policy is locked, BMC / MMC reboot is prohibited, and AC power-down commands are prohibited from being sent to the PSU; the original firmware is backed up before writing; the firmware is written and verified; only when the verification passes is the upgrade marked as successful; if the upgrade is interrupted due to a power failure, it is automatically rolled back or retried. For the third type of firmware upgrade, confirm that ACPI enters S0, PGOOD is valid, BIOS POST is completed, there is no crash signal, and confirm that the in-situ GPIO is valid, VPD / FRU is readable, and I2C address response is normal. After meeting the above conditions, initiate the upgrade, write and verify.

[0144] After all firmware upgrade tasks are completed, each MMC will compile statistics on the final firmware version, firmware upgrade task execution results, device self-test status, and abnormal information for its node, and report the above information to the BMC.

[0145] like Figure 9 As shown, the BMC (Browser Control Center) monitors the entire firmware upgrade process via unified polling. If any anomalies occur, such as write failure, network interruption, unexpected power outage, or device unresponsiveness, the BMC identifies the faulty device and firmware and notifies the corresponding MMC (Multi-Level Manager). This MMC only terminates the current failed upgrade task, automatically rolls back the pre-backed-up original firmware, ensuring the node remains operational; other nodes without errors continue the upgrade. The BMC generates a firmware upgrade report based on the log data reported by each MMC. This report may include the firmware source, upgrade time, device number, fault location, power outage records, and lock request records. The BMC also summarizes and archives the logs for subsequent maintenance, problem tracing, and version management.

[0146] Finally, the present invention also provides a supernode server, comprising multiple servers, each server serving as a computing node of the supernode server, and the servers being connected via an interconnect bus; each server may include a master controller and at least one slave controller; the master controller is deployed on the motherboard of the corresponding server, and each slave controller is deployed on the substrate of the corresponding server, the master controller and each slave controller communicating via an internal local area network; each slave controller, when executing a computer program stored in a memory, implements the steps of the firmware upgrade method executed by the slave controller as described in any of the above embodiments; the master controller, when executing the computer program, implements the steps of the firmware upgrade method executed by the master controller as described in any of the above embodiments.

[0147] A supernode server refers to a computing system that is physically composed of multiple computing nodes tightly connected through an efficient interconnect protocol, possesses unified memory addressing capabilities across physical nodes, and logically appears as a single computing system to upper-layer software and users. The efficient interconnect protocol may include a memory-coherent interconnect protocol bus, which is a high-speed interconnect protocol capable of achieving cache coherency and supporting memory sharing among multiple devices. This may include, but is not limited to, the Compute ExpressLink (CXL) bus and the Cachecoherent Initerconned for Accelerators (CCX) bus. Any of the components, modules, units, parts, methods, and operations described in this invention can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The systems, computing devices, or apparatuses described herein encompass a wide range of devices, apparatuses, and machines for processing data, including, for example, one or more programmable processors, computers, systems-on-a-chip, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also referred to as a program, software, software application, app, script, or code) may be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and may be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

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

[0149] The firmware upgrade method, server, and supernode server provided by this invention have been described in detail above. The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Several improvements and modifications can be made to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of this invention.

Claims

1. A firmware upgrade method, characterized in that, Applied to controllers, including: When a firmware upgrade task is received from the target device, the current overall operating status of the device is obtained; Based on the firmware upgrade conditions, determine the target firmware category and target trigger conditions for the target device; When the current overall operating condition meets the target triggering condition, the target resource lock type to be requested by the target device is determined according to the target firmware type and the occupation of overall or shared resources by the target device during the firmware upgrade process. Send a resource lock request to the main controller and receive an authorization result or rejection result returned by the main controller based on the global state and the resource lock state; When the current overall operating condition still meets the target triggering condition and resource lock authorization is obtained, a write operation is performed on the target device; The firmware upgrade conditions are determined based on detection data under at least two system operating conditions, and the target triggering conditions represent the system operating conditions and write permission status that must be met for the firmware to be allowed to be updated.

2. The firmware upgrade method according to claim 1, characterized in that, The target firmware of the target device is of type 1 firmware. The target device has a target running partition and a target spare partition. When the current overall operating condition still meets the target triggering condition and an authorization result is received, a write operation is performed on the target device, including: When the current overall operating condition is that the whole machine is powered on and running, the firmware to be upgraded for the target device is written into the target spare partition; After the firmware to be upgraded is written and verified, wait for the global state to enter the idle and rebootable state; When the global state is the idle and restartable state, request a whole machine restart lock from the main controller; After obtaining the system reboot lock, the target device is controlled to reboot in order to switch to the target backup partition to run the firmware to be upgraded.

3. The firmware upgrade method according to claim 2, characterized in that, Before writing the firmware to be upgraded to the target spare partition, the process also includes: Based on the target device's usage of the shared bus during firmware upgrades, the required resource lock type is determined to be a shared bus lock. Request a shared bus lock from the main controller; After acquiring the shared bus lock, the firmware to be upgraded is written to the target spare partition, and the shared bus lock is released after the firmware to be upgraded is written.

4. The firmware upgrade method according to claim 2, characterized in that, After waiting for the global state to enter the idle and restartable state, the process also includes: The quantified value of the idle machine is determined based on at least one of the following: user access status, operation and maintenance task status, system load status, and abnormal alarm status. When the overall idle metric value is lower than the preset idle threshold, and the firmware upgrade task from the controller is completed and there are no ongoing maintenance operations on the entire machine, it is determined that the machine enters an idle and restartable state.

5. The firmware upgrade method according to claim 1, characterized in that, The target firmware of the target device is of type II firmware. When the current overall operating condition still meets the target triggering condition and an authorization result is received, a write operation is performed on the target device, including: When the current overall operating condition is that the operating system is normally shut down and the board is in a power-saving state, a power-saving lock is requested from the main controller; wherein, the normal shutdown of the operating system and the power-saving state of the board means that the operating system has been normally shut down and the power supply domain of the target device remains valid; the power-saving lock is allocated when the global state is the power-saving state. After obtaining the power-off lock, when it is determined that the power supply meets the task requirements, the power status of the whole machine is locked, the controller restart prohibition attribute and AC power-off command sending operation prohibition attribute are set, and the original firmware data of the target device is backed up; A write operation is performed on the target device.

6. The firmware upgrade method according to claim 5, characterized in that, Before the current overall machine operating condition is in a power-off state, it also includes: The system detects the overall power status signal, the power supply domain status signal of the target device, the power button status, the operating system shutdown record, the AC power failure record, and the power failure reset record. If the overall power status indicates that the operating system has been soft-shutdown, the power supply domain of the target device is valid, the power button is in normal condition, there is a record of normal shutdown of the operating system, there is no record of AC power failure, and there is no record of power failure reset, then the current overall operating condition is determined to be the operating system normal shutdown and board power preservation condition. If the conditions for normal shutdown are not met and there is a power failure record, it is determined to be an abnormal power failure. Normal shutdown and board power preservation mode of the operating system are prohibited. The information is reported to the main controller, so that the main controller can switch the global state to the abnormal power failure state and call the locally backed-up original firmware to roll back or retry.

7. The firmware upgrade method according to claim 1, characterized in that, The target firmware of the target device is of type three firmware. When the current overall operating condition still meets the target triggering condition and an authorization result is received, a write operation is performed on the target device, including: Acquire the overall system power-on status data, target device power supply data, and target device accessibility data; Based on the overall system power-on status data, the target device power supply data, and the target device accessibility data, it is determined that the current overall system operating condition is the overall system power-on running condition, and the target device meets the conditions of being in place and link stability, and then a shared bus lock is requested from the main controller; Once the shared bus lock is acquired, a write operation is performed on the target device.

8. The firmware upgrade method according to claim 1, characterized in that, After performing a write operation on the target device, the process also includes: If the firmware writing of the target device fails, the network is interrupted, there is an unexpected power outage, or the device becomes unresponsive, the firmware upgrade task of the target device is terminated only, and the original firmware that has been pre-backed up locally is called to perform a rollback operation on the target device. After the firmware to be upgraded has been written, a verification process is performed. If the verification fails, the firmware upgrade task of the target device will be terminated only, and the original firmware that has been backed up locally will be used to perform a rollback operation on the target device.

9. The firmware upgrade method according to any one of claims 1 to 8, characterized in that, The process of generating the firmware upgrade conditions includes: Under at least two of the following system conditions: system power-on operation, normal system shutdown with board power-on, and system idle and restartable, detect each managed device. When the managed device has a running partition and a backup partition under the power-on and running conditions of the whole machine, and is allowed to switch between the running partition and the backup partition, if the backup partition is allowed to be written to when the running partition is running, then the firmware category of the managed device is the first type of firmware, and the corresponding upgrade trigger condition is set as follows: when the whole machine is running, writing to the backup partition is allowed, and when the whole machine enters the idle and restartable state, restarting and switching to the backup partition is allowed. When the managed device is powered off normally under the operating system and the board is powered on, and the power supply domain is still valid, the presence signal is still displayed, the device identifier is successfully read, and the bus communication is normal, then the firmware category of the managed device is determined to be Category 2 firmware, and the corresponding upgrade trigger conditions are set as follows: the overall power status indicates that the operating system has been powered off normally, the power supply domain is still valid, the presence signal is valid, and the bus communication is normal. When the managed device is powered off normally under the operating system and the board is powered on, and the device identifier is unreadable, the device is not in place, or the bus is unresponsive, and the bus address response is normal and the presence signal is valid under the overall system power-on running condition, then the managed device is determined to be Category 3 firmware, and the corresponding upgrade trigger conditions are set as follows: the overall system is in power-on running state, power-on self-test is completed, the power supply domain is valid, the presence signal is valid, and the bus address response is normal. Firmware upgrade conditions are generated based on the firmware category and corresponding upgrade trigger conditions of each managed device.

10. The firmware upgrade method according to claim 9, characterized in that, Also includes: When the target managed device is detected to have undergone board insertion / removal, topology change, firmware update, or firmware restart, the target managed device will be re-detected under at least two of the following conditions: system power-on operation, normal system shutdown with board power-on, and system idle and restartable operation. Based on the new detection data of the target managed device, the firmware category and upgrade trigger conditions of the target managed device are re-determined; Update the firmware upgrade conditions based on the new firmware category and new upgrade trigger conditions of the target managed device.

11. A firmware upgrade method, characterized in that, Applied to the main controller, including: Receive a resource lock request sent from the controller, the resource lock request being used to request a resource lock of the target resource lock type; The target resource lock type is determined by the slave controller when the target triggering condition is met under the current overall operating conditions, based on the target firmware category of the target device and the occupation of overall or shared resources by the target device during the firmware upgrade process; The target triggering condition represents the overall operating conditions and write-allowed status that the firmware must meet to allow updates. The firmware upgrade conditions are determined based on detection data under at least two overall operating conditions. Based on the global state and the resource lock state, the resource lock request can be authorized or denied. The slave controller returns an authorization result or a rejection result so that when the slave controller still meets the target triggering condition and receives the authorization result, it can perform a write operation on the target device.

12. The firmware upgrade method according to claim 11, characterized in that, The global state includes abnormal power failure state, power-saving shutdown state, power-on initialization state, running state, and idle restartable state. Based on the global state and resource lock state, resource lock requests are authorized or denied, including: When the global state is idle and restartable, and the target resource lock type corresponding to the resource lock request is a whole machine restart lock, then the whole machine restart lock is allocated; When the global state is in the power-off state and the target resource lock type corresponding to the resource lock request is a power-off lock, then the power-off lock is allocated. During the power-on initialization state, the firmware upgrade task is paused, and the corresponding resource lock request is rejected until the power-on initialization is completed and the system enters the running state. When the global state is in the running state, and the target resource lock type corresponding to the resource lock request is a shared bus lock, then the shared bus lock is allocated; When the global state is in an abnormal power-down state, the corresponding resource lock request is rejected, and the slave controller corresponding to the resource lock request is notified to suspend the firmware upgrade task.

13. The firmware upgrade method according to claim 11, characterized in that, Also includes: When the server power-on initialization is detected, the global state is switched to the power-on initialization state; When the power-on initialization is completed and the server enters the overall machine startup and operation mode, the global state is switched to the running state; When the server enters the normal shutdown state of the operating system and the board power-saving mode, the global state is switched to the shutdown power-saving state. When it is determined that the server meets the idle and restartable condition, the global state is switched to the idle and restartable state; When an abnormal power outage is detected, the global state is switched to the abnormal power outage state, and the power-saving shutdown state is prohibited while the global state is in the abnormal power outage state until the abnormal power outage is recovered.

14. The firmware upgrade method according to claim 11, characterized in that, Also includes: Receive firmware image upload requests and perform integrity and validity checks on the firmware image data; After both the integrity check and the validity check pass, the management affiliation of the target device corresponding to the firmware image data is determined according to the pre-stored whole machine hardware topology relationship; If the target device belongs to the management of the main controller, the firmware image data is added to the local upgrade queue of the main controller; If the target device belongs to the management of the slave controller, the firmware image data is encrypted and sent point-to-point to the corresponding target slave controller according to the preset binding relationship, so that the target slave controller can perform secondary verification on the received firmware image data; Each slave controller receives only firmware image data sent by the master controller according to a preset binding relationship.

15. The firmware upgrade method according to any one of claims 11 to 14, characterized in that, Also includes: Record and update the resource lock status; the resource lock status includes lock type and lock status information, the lock type includes whole machine restart lock, power-saving lock, shared power domain lock and shared bus lock, and the lock status information includes occupancy status, holder ID, application time and lease duration; When a target resource lock request is received from the target controller, and the target lock resource corresponding to the lock type requested in the target resource lock request is in an occupied state, the target controller is added to the lock allocation waiting queue. When the target lock resource is released, the target lock resource is allocated to the slave controllers in the lock allocation waiting queue according to the order of the lock allocation waiting queue and based on the current global state. When the holding time of the target lock resource exceeds the lease duration, or when the slave controller holding the target lock resource goes offline, the target lock resource is released, or the target lock resource is set to a pending recovery state.

16. The firmware upgrade method according to any one of claims 11 to 14, characterized in that, Also includes: Receive firmware categories and upgrade trigger conditions reported by each slave controller; Based on the current global state, the firmware type of each slave controller, the resource lock requests and resource lock status of each slave controller, determine the upgrade scheduling order of each slave controller; For slave controllers that do not require the use of whole machine resources or shared resources, they are allowed to perform local firmware upgrade tasks in parallel without conflicting with other slave controllers; For slave controllers that require the use of whole machine resources or shared resources, execute local firmware upgrade tasks according to the resource lock allocation order; In this process, multiple firmware upgrade tasks within the same slave controller are executed serially in a preset order.

17. The firmware upgrade method according to any one of claims 11 to 14, characterized in that, Also includes: Monitor the firmware upgrade status of each slave controller; When a firmware upgrade anomaly is detected, the target of the anomaly is determined to be the controller and the target device to be upgraded; Send a rollback notification to the target slave controller so that the target slave controller only terminates the currently erroneous firmware upgrade task and calls the locally backed-up original firmware to roll back; When an abnormal power failure is detected, the global state is switched to the abnormal power failure state, and the allocated global resources are locked to the state pending recovery.

18. A server, characterized in that, Includes a master controller and at least one slave controller; The main controller is deployed on the motherboard of the server, and each slave controller is deployed on the baseboard of the server. The main controller and each slave controller communicate through an internal local area network. Each slave controller is configured to implement the steps of the firmware upgrade method as described in any one of claims 1 to 10 when executing a computer program stored in the memory; The main controller is used to implement the steps of the firmware upgrade method as described in any one of claims 11 to 17 when executing the computer program.

19. The server according to claim 18, characterized in that, The main controller collects firmware information of the managed devices of each slave controller through the management interface, and then summarizes the collected firmware information and synchronizes it to the message bus of the main controller. The firmware information of the entire device is displayed through the user interface.

20. A supernode server, characterized in that, It includes multiple servers, which are connected via an interconnect bus; Each server includes a master controller and at least one slave controller; the master controller is deployed on the motherboard of the corresponding server, and each slave controller is deployed on the base plate of the corresponding server; the master controller and each slave controller communicate through an internal local area network; each slave controller is used to implement the steps of the firmware upgrade method as described in any one of claims 1 to 10 when executing a computer program stored in a memory; the master controller is used to implement the steps of the firmware upgrade method as described in any one of claims 11 to 17 when executing the computer program.

Images