A method, system, electronic device, and storage medium for BMC optimization of an AI server.

Abstract

This disclosure provides a BMC optimization method, system, electronic device, and storage medium for an AI server, relating to the field of computer technology. The BMC optimization method for an AI server, applied to a BMC optimization system for an AI server, includes: responding to a startup command for the AI ​​server, a first kernel and a second kernel start; after the first kernel completes startup, it takes over the basic monitoring subsystem of the AI ​​server, continuously collecting operating data of the fans and power supply in the AI ​​server and controlling the fans and power supply; after the second kernel completes startup, it takes over the global monitoring subsystem of the AI ​​server, performs global monitoring of the AI ​​server, and optimizes strategies based on the monitoring results; during the parallel operation of the first and second kernels, if the target kernel detects an anomaly in the other kernel, the target kernel takes over the monitoring tasks of the anomaly kernel. This eliminates the startup idle period of traditional single-core AI servers.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a BMC optimization method, system, electronic device and storage medium for an AI server. Background Technology

[0002] As a core component for hardware monitoring and management of AI (Artificial Intelligence) servers, the BMC (Baseboard Management Controller) directly determines the stability, energy efficiency, and ease of maintenance of AI servers in data center scenarios. With the continuous increase in computing power demands from AI technology, AI servers are gradually moving towards high-density hardware integration. A single device often carries multiple GPUs (Graphics Processing Units), multiple cooling fans, and redundant power supply modules. This places higher demands on the BMC's real-time monitoring capabilities, startup response speed, and fault redundancy performance. Existing BMC monitoring solutions are no longer adequate to meet these requirements, presenting significant technical challenges.

[0003] Traditional AI server BMCs (Body Control Centers) often employ a single-kernel architecture with a Linux operating system for hardware management. This architecture suffers from a significant startup window problem. Because Linux system initialization requires multiple steps, including kernel loading, driver adaptation, and service startup, the entire process typically takes 180-240 seconds. During this time, the BMC cannot effectively monitor and control fans, power supplies, and core computing components. This not only causes fans to run at maximum speed by default during initial power-up, resulting in unnecessary energy waste and noise pollution, but also prevents the BMC from responding promptly to sudden hardware issues such as voltage anomalies or sudden temperature increases. This could lead to overheating and damage to expensive hardware components, posing a serious equipment safety risk.

[0004] Meanwhile, the BMC in a single-core architecture needs to simultaneously handle two types of tasks with significantly different characteristics: one is high-frequency real-time tasks, including sensor data acquisition, PID (Proportional-Integral-Derivative) control of cooling fans, and hardware fault interrupt handling, which have extremely high requirements for response timeliness; the other is complex non-real-time tasks, such as web interface rendering, system event log (SEL) analysis, and remote operation and maintenance command parsing, which require a large amount of computing resources. The two types of tasks share the CPU (Central Processing Unit) and memory resources of the single core, which can easily lead to resource contention, resulting in delayed response of real-time tasks, extended sensor data update cycles, and delayed fan control, thus affecting the hardware stability of the AI ​​server; non-real-time tasks will also experience stuttering due to resource contention, such as web interface loading taking more than 10 seconds, which significantly reduces operation and maintenance efficiency.

[0005] Furthermore, existing BMC solutions generally lack effective fault redundancy mechanisms. If a single core or peripheral fails, the BMC will become completely inoperable, making hardware status monitoring and fault alarms impossible. As the core computing power node of a data center, AI servers need to operate 24 / 7. BMC failure will severely disrupt business continuity, and troubleshooting and recovery require manual on-site operations, significantly extending downtime.

[0006] In summary, current AI server BMCs have significant shortcomings in startup response, task processing, fault redundancy, and hardware adaptation. There is an urgent need for an AI server BMC optimization solution to meet the requirements of high-density AI servers for efficient and reliable BMC operation. Summary of the Invention

[0007] This disclosure provides a BMC optimization method, system, electronic device, and storage medium for an AI server, to at least solve the above-mentioned technical problems existing in the prior art.

[0008] According to a first aspect of this disclosure, a BMC optimization method for an AI server is provided, applied to a BMC optimization system for an AI server. The BMC chip of the AI ​​server includes a first core and a second core that are independent of each other. The startup time of the first core is shorter than that of the second core. The method includes: in response to a startup command for the AI ​​server, the first core and the second core start; after the first core finishes startup, it takes over the basic monitoring subsystem of the AI ​​server, continuously collects the operating data of the fans and power supply in the AI ​​server, and controls the fans and power supply; after the second core finishes startup, it takes over the global monitoring subsystem of the AI ​​server, performs global monitoring of the AI ​​server, and optimizes strategies based on the monitoring results; the first core and the second core exchange monitoring information through a data interaction interface; during the parallel operation of the first core and the second core, if a target core detects an anomaly in the other core, the target core takes over the monitoring task of the abnormal core.

[0009] In one possible implementation, the first kernel is connected to a first QSPI controller, and the second kernel is connected to a second QSPI controller; the startup of the first kernel and the second kernel includes: detecting the hardware status of the first kernel, the second kernel, the first QSPI controller, and the second QSPI controller, determining the normal kernel among the first kernel and the second kernel; reading the startup mode in the startup configuration register of the BMC chip, and starting the normal kernel based on the startup mode.

[0010] In one possible implementation, the first QSPI controller is connected to a first flash memory, which stores the RTOS firmware of the first kernel; the second QSPI controller is connected to a second flash memory, which stores the Linux firmware of the second kernel; the step of booting the normal kernel based on the boot mode includes: in response to the boot mode being a parallel boot mode, simultaneously initializing the first QSPI controller and the second QSPI controller, and loading the RTOS firmware in the first flash memory and the Linux firmware in the second flash memory in parallel, so that the first kernel and the second kernel boot in parallel; in response to the boot mode being a priority boot mode, prioritizing the boot of the first kernel, and triggering the boot of the second kernel through an internal interrupt after the first kernel takes over the basic monitoring subsystem; in response to the boot mode being a single boot mode, booting only one of the first kernel and the second kernel.

[0011] In one possible implementation, an upgrade partition is provided in the first flash memory, and the method further includes: the second kernel transferring a new RTOS firmware to the first flash memory of the first kernel; the first kernel erasing the upgrade partition and writing the new RTOS firmware into the upgrade partition; the first kernel reading the new RTOS firmware from the upgrade partition and performing a reset and reboot based on the new RTOS firmware.

[0012] In one possible implementation, the second flash memory includes a primary root partition and a backup root partition, and the method further includes: the second kernel obtaining new Linux firmware and writing the new Linux firmware into the backup root partition; in response to the successful verification of the new Linux firmware, switching the boot partition of the second kernel from the primary root partition to the backup root partition.

[0013] In one possible implementation, the basic monitoring subsystem running on the first kernel includes a hardware driver layer, a core service layer, and an application control layer. The continuous collection of operating data from the fans and power supply in the AI ​​server and the control of the fans and power supply includes: adapting the peripheral interface of the first kernel to the hardware driver layer, reading operating data from the fan speed sensor and power parameter sensor via a communication bus interface, and transmitting control signals to the fan driver and power management module; receiving the operating data output by the hardware driver layer from the core service layer, performing sliding filtering, CRC checksum verification, and format standardization on the operating data, and transmitting the processed operating data to the application control layer, while simultaneously forwarding control commands sent by the application control layer to the hardware driver layer; executing the collection and control tasks according to a preset priority by the application control layer. The collection task obtains and stores the processed operating data from the core service layer in a first cycle; the control task calculates the control quantity using a PID algorithm based on the processed operating data and the strategy optimization parameters issued by the second kernel; and the core service layer and hardware driver layer adjust the fan speed and power supply status based on the control quantity.

[0014] In one possible implementation, the data interaction interface is based on the shared SRAM of the first kernel and the second kernel in the second kernel. The first kernel and the second kernel exchange monitoring information through the data interaction interface, including: the first kernel synchronizing monitoring data to the shared SRAM in a second cycle; when the second kernel needs to access the shared SRAM, it initiates an access request to the first kernel through a designated interrupt channel; after the first kernel completes the current operation, it releases control of the shared SRAM and sends an interrupt notification to the second kernel; after the second kernel completes the access to the shared SRAM, it sends an interrupt notification to the first kernel.

[0015] In one possible implementation, if the target kernel detects an anomaly in another kernel, the target kernel takes over the monitoring task of the anomaly kernel, which includes: when the second kernel detects an anomaly in the target task in the first kernel through the task status area of ​​the data interaction interface, it sets a status flag to identify the target task to be taken over, and sends a task takeover notification through the command buffer of the data interaction interface; the second kernel acquires control of the shared peripheral corresponding to the target task and takes over the target task; when the first kernel detects that the target task fault has been recovered, the second kernel clears the status flag, releases control of the shared peripheral, and the first kernel takes over the target task again.

[0016] In one embodiment, the method further includes: after the first kernel completes its startup, it sends startup completion information to the second kernel; during the startup process of the second kernel, it reads the startup status of the first kernel.

[0017] According to a second aspect of this disclosure, a BMC optimization system for an AI server is provided. The system includes: a BMC chip, which includes a first core and a second core that are independent of each other, wherein the startup time of the first core is shorter than that of the second core; the BMC chip is used to control the startup of the first core and the second core in response to a startup command for the AI ​​server; the first core, after startup, takes over the basic monitoring subsystem of the AI ​​server, continuously collects the operating data of the fans and power supply in the AI ​​server, and controls the fans and power supply; the second core, after startup, takes over the global monitoring subsystem of the AI ​​server, performs global monitoring of the AI ​​server, and optimizes strategies based on the monitoring results; the first core and the second core exchange monitoring information through a data interaction interface; during the parallel operation of the first core and the second core, if a target core detects an anomaly in the other core, the target core takes over the monitoring task of the abnormal core.

[0018] In one embodiment, the first kernel is connected to a first QSPI controller, and the second kernel is connected to a second QSPI controller; the BMC chip is also used to detect the hardware status of the first kernel, the second kernel, the first QSPI controller, and the second QSPI controller, determine the normal kernel among the first kernel and the second kernel; read the boot mode in the boot configuration register of the BMC chip, and boot the normal kernel based on the boot mode.

[0019] In one possible implementation, the first QSPI controller is connected to a first flash memory, which stores the RTOS firmware of the first kernel; the second QSPI controller is connected to a second flash memory, which stores the Linux firmware of the second kernel; the BMC chip is further configured to: in response to the boot mode being a parallel boot mode, simultaneously initialize the first QSPI controller and the second QSPI controller, and load the RTOS firmware in the first flash memory and the Linux firmware in the second flash memory in parallel, so that the first kernel and the second kernel can boot in parallel; in response to the boot mode being a priority boot mode, prioritize booting the first kernel, and after the first kernel takes over the basic monitoring subsystem, trigger the boot of the second kernel through an internal interrupt; in response to the boot mode being a single boot mode, boot only one of the first kernel and the second kernel.

[0020] In one embodiment, the first flash memory is provided with an upgrade partition, and the second kernel is further configured to transfer the new RTOS firmware to the first flash memory of the first kernel; the first kernel is further configured to erase the upgrade partition and write the new RTOS firmware into the upgrade partition; the first kernel is further configured to read the new RTOS firmware from the upgrade partition and perform a reset and restart based on the new RTOS firmware.

[0021] In one embodiment, the second flash memory includes a primary root partition and a backup root partition. The second kernel is further configured to obtain new Linux firmware and write the new Linux firmware to the backup root partition. The second kernel is also configured to switch the boot partition of the second kernel from the primary root partition to the backup root partition in response to the successful verification of the new Linux firmware.

[0022] In one embodiment, the basic monitoring subsystem running on the first kernel includes a hardware driver layer, a core service layer, and an application control layer. The first kernel is further configured to: adapt the peripheral interface of the first kernel based on the hardware driver layer, read the operating data of the fan speed sensor and the power parameter sensor through the communication bus interface, and transmit the control signal to the fan driver and the power management module; receive the operating data output by the hardware driver layer based on the core service layer, perform sliding filtering, CRC check and format standardization processing on the operating data, and transmit the processed operating data to the application control layer, while forwarding the control instructions sent by the application control layer to the hardware driver layer; execute the acquisition task and the control task according to the preset priority based on the application control layer, wherein the acquisition task obtains and stores the processed operating data from the core service layer in a first cycle, and the control task calculates the control quantity through the PID algorithm based on the processed operating data and the strategy optimization parameters issued by the second kernel, and the core service layer and the hardware driver layer adjust the fan speed and power status based on the control quantity.

[0023] In one possible implementation, the data interaction interface is based on the shared SRAM of the first kernel and the second kernel in the second kernel. The first kernel is further configured to synchronize monitoring data to the shared SRAM in a second cycle. The second kernel is further configured to initiate an access request to the first kernel through a specified interrupt channel when it needs to access the shared SRAM. The first kernel is further configured to release control of the shared SRAM after completing the current operation and send an interrupt notification to the second kernel. The second kernel is further configured to complete the access to the shared SRAM and send an interrupt notification to the first kernel.

[0024] In one embodiment, the second kernel is further configured to: when the second kernel detects an anomaly in the target task in the first kernel through the task status area of ​​the data interaction interface, set a status flag to identify the target task that needs to be taken over, and send a task takeover notification through the command buffer of the data interaction interface; the second kernel acquires control of the shared peripheral corresponding to the target task and takes over the target task; when the first kernel detects that the target task fault has been recovered, the second kernel clears the status flag, releases control of the shared peripheral, and the first kernel takes over the target task again.

[0025] In one embodiment, the first kernel is further configured to send boot completion information to the second kernel after booting; the second kernel is further configured to read the boot status of the first kernel during the boot process.

[0026] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0027] At least one processor; and,

[0028] A memory communicatively connected to the at least one processor; wherein,

[0029] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described in this disclosure.

[0030] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing the computer to perform the methods described in this disclosure.

[0031] This disclosure discloses a BMC optimization method, system, electronic device, and storage medium for an AI server. The first kernel in the BMC starts up quickly and can rapidly take over basic monitoring, eliminating the 180-240 second startup window of traditional single-kernel Linux systems and avoiding the risks of high fan consumption and unresponsive hardware during initial power-on. Secondly, the dual kernels have clear division of labor: the first kernel handles high-frequency real-time tasks, while the second kernel is responsible for complex non-real-time tasks, avoiding resource contention and ensuring the timeliness of real-time task response and the smoothness of non-real-time tasks. In addition, the dual kernels can take over abnormal tasks from each other, compensating for the lack of fault redundancy in a single kernel, reducing the probability of BMC failure, ensuring 24 / 7 operation of the AI ​​server, and improving data center business continuity and operational efficiency.

[0032] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0033] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which:

[0034] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

[0035] Figure 1 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 1 ;

[0036] Figure 2 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 2 ;

[0037] Figure 3 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 3 ;

[0038] Figure 4 A schematic diagram of the structure of a BMC optimization system for an AI server according to an embodiment of the present disclosure is shown;

[0039] Figure 5 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 4 ;

[0040] Figure 6 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 5 ;

[0041] Figure 7 A schematic diagram of the composition structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0042] To make the objectives, features, and advantages of this disclosure more apparent and understandable, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0043] Figure 1 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 1 ,like Figure 1 As shown, a BMC optimization method for an AI server is applied to an AI server BMC optimization system. The BMC chip of the AI ​​server includes a first core and a second core that are independent of each other. The startup time of the first core is shorter than that of the second core. The method includes:

[0044] In step S101, in response to the startup command for the AI ​​server, the first kernel and the second kernel start up. After the first kernel finishes starting up, it takes over the basic monitoring subsystem of the AI ​​server, continuously collects the operating data of the fans and power supply in the AI ​​server, and controls the fans and power supply.

[0045] Figure 4 A schematic diagram of the structure of a BMC optimization system for an AI server according to an embodiment of this disclosure is shown, as follows: Figure 4As shown, a BMC optimization system for an AI server includes a BMC chip, which comprises an independent first core and a second core. The startup time of the first core is shorter than that of the second core. The first core can be a Cortex-M33 core (hereinafter referred to as the M33 core), and the second core can be a Cortex-A55 core (hereinafter referred to as the A55 core). The A55 core supports multi-process / thread collaboration, can integrate data acquisition from a large number of sensors, and adapts to the multi-dimensional and high-density monitoring needs of AI servers. The M33 core has extremely high real-time performance, predictable response latency, adopts priority preemptive scheduling, and task switching latency is typically in the microsecond range, and supports interrupt nesting.

[0046] In this embodiment, upon receiving the startup command, the first kernel and the second kernel start simultaneously. After startup, the first kernel immediately takes over the AI ​​server's basic monitoring subsystem. The main task of the basic monitoring subsystem is to continuously collect operating data from the fan and power supply, such as data from the fan speed sensor and power parameter sensor, and adjust the fan speed and power supply status based on this data to ensure stable system operation.

[0047] In step S102, after the second kernel completes startup, it takes over the global monitoring subsystem of the AI ​​server, performs global monitoring of the AI ​​server, and optimizes the strategy based on the monitoring results; the first kernel and the second kernel exchange monitoring information through a data interaction interface.

[0048] In this embodiment, after startup, the second kernel takes over the global monitoring subsystem of the AI ​​server. The global monitoring subsystem is responsible for comprehensive monitoring of the AI ​​server, including but not limited to hardware status, system performance, and network communication. Based on the collected global monitoring data, the second kernel can perform policy optimization, such as dynamically adjusting cooling strategies or optimizing power management according to system load. The first and second kernels exchange monitoring information through a data interaction interface, ensuring that the two kernels can share monitoring data in real time, thereby achieving collaborative work. For example, the first kernel can send real-time collected fan and power data to the second kernel, and the second kernel can generate optimization strategies based on this data and feed them back to the first kernel for execution.

[0049] In step S103, if the target kernel detects an anomaly in another kernel during the parallel operation of the first kernel and the second kernel, the target kernel will take over the monitoring task of the abnormal kernel.

[0050] In this embodiment, during the parallel operation of the first and second kernels, if one kernel detects an anomaly in the other kernel, such as task execution failure or communication interruption, the target kernel will take over the monitoring task of the abnormal kernel. For example, if the second kernel detects a failure in a monitoring task within the first kernel, the second kernel will take over that task to ensure the continuity of monitoring tasks.

[0051] This disclosure employs a dual-core architecture, effectively addressing the monitoring gap issue present in traditional single-core BMC systems during startup. This ensures that the AI ​​server can be effectively monitored and controlled immediately upon startup, mitigating hardware risks. Simultaneously, the collaborative work of the first and second cores enables comprehensive monitoring and policy optimization of the AI ​​server, improving overall system performance and reliability. Distributing some monitoring tasks to the first core prevents resource contention between monitoring tasks and other functions in the second core, reducing CPU (Central Processing Unit) resource usage and improving overall system responsiveness. Furthermore, a failover mechanism further enhances system stability, ensuring the continuity of monitoring tasks in the event of a kernel failure.

[0052] In another embodiment, the first kernel is connected to a first QSPI controller, and the second kernel is connected to a second QSPI controller; the "startup of the first and second kernels" in step S101 includes:

[0053] Detect the hardware status of the first kernel, the second kernel, the first QSPI controller, and the second QSPI controller to determine the normal kernel among the first kernel and the second kernel;

[0054] Read the boot mode from the boot configuration register of the BMC chip and boot the normal kernel based on the boot mode.

[0055] like Figure 4 As shown, the first kernel is connected to a first Quad Serial Peripheral Interface (QSPI) controller, and the second kernel is connected to a second QSPI controller. The QSPI controllers are used to manage the firmware storage and boot process of their respective kernels. Specifically, the first kernel accesses its firmware storage area through the first QSPI controller, while the second kernel accesses its firmware storage area through the second QSPI controller.

[0056] In this embodiment, during the boot process, the hardware status of the first kernel, the second kernel, the first QSPI controller, and the second QSPI controller is first checked. This check is performed through a hardware self-test mechanism to ensure that all critical components are in normal working order before boot. For example, the system checks key parameters such as the kernel's clock signal, reset signal, and the QSPI controller's communication link to determine which kernels and QSPI controllers are functioning correctly, thereby providing accurate hardware status information for the subsequent boot process.

[0057] In this embodiment, after determining the normal kernel and QSPI controller, the boot mode is read from the boot configuration register of the BMC chip. The boot configuration register stores configuration information during system startup, including the selection of the boot mode. Based on the read boot mode, the normal kernel will be booted accordingly. The boot order of the first and second kernels differs under different boot modes.

[0058] In this embodiment, by configuring independent QSPI controllers for the first and second kernels respectively, hardware isolation and independent operation of the two kernels during the boot process are achieved, effectively avoiding boot conflicts and delays caused by hardware resource sharing in traditional monolithic systems. Simultaneously, through hardware status detection and boot mode configuration, the boot method can be flexibly selected according to the actual hardware status and application scenario, further improving the reliability and adaptability of the boot process.

[0059] In another embodiment, a first QSPI controller is connected to a first flash memory for storing the RTOS firmware of a first kernel, and a second QSPI controller is connected to a second flash memory for storing the Linux firmware of a second kernel; booting a normal kernel based on a boot mode includes:

[0060] In response to the boot mode being parallel boot mode, the first QSPI controller and the second QSPI controller are initialized simultaneously, and the RTOS firmware in the first flash memory and the Linux firmware in the second flash memory are loaded in parallel, so that the first kernel and the second kernel can boot in parallel.

[0061] If the boot mode is the priority boot mode, the first kernel will be booted first. After the first kernel takes over the basic monitoring subsystem, the second kernel will be triggered to boot through an internal interrupt.

[0062] If the boot mode is a single boot mode, then only one of the first kernel and the second kernel will be booted.

[0063] like Figure 4As shown, the first QSPI controller is connected to a first flash memory, which stores the RTOS (Real-Time Operating System) firmware of the first kernel. The second QSPI controller is connected to a second flash memory, which stores the Linux firmware of the second kernel. Both flash memories can be ROM (Read-Only Memory), with the first flash memory having a capacity of 521kb and the second flash memory having a capacity of 128MB. This dual flash memory design separates the firmware storage for the two kernels, ensuring that they do not interfere with each other during startup and operation. The RTOS firmware of the first kernel is responsible for fast startup and real-time monitoring tasks, while the Linux firmware of the second kernel is responsible for global monitoring and complex task processing. The power supply (VCC), reset (RESET), and chip select signals of the first and second memory are completely independent, powered by independent power management modules to prevent a single memory failure (such as a short circuit) from affecting the other kernel. The connection lines between the first and second memory and the QSPI controller use differential impedance matching (50Ω) to shorten the wiring length (less than or equal to 5cm) and reduce signal interference.

[0064] In this embodiment, when the boot mode is set to parallel boot mode, the system initializes the first QSPI controller and the second QSPI controller simultaneously. These two controllers load the corresponding RTOS firmware and Linux firmware from their respective connected flash memory. Specifically, the first QSPI controller loads the RTOS firmware into the first kernel from the first flash memory, and the second QSPI controller loads the Linux firmware into the second kernel from the second flash memory. Through parallel loading, the two kernels begin booting simultaneously. For example, the first kernel (M33) can complete booting and take over basic monitoring tasks within 100ms, while the second kernel (A55) completes booting and takes over global monitoring tasks slightly later.

[0065] In this embodiment, when the boot mode is set to priority boot mode, the first kernel will be booted first. After the first kernel completes booting and takes over the basic monitoring subsystem, it triggers the second kernel to boot via an internal interrupt. This boot method ensures that the system can quickly enter the basic monitoring state in the early stages of booting, avoiding monitoring gaps caused by boot delays. For example, after the first kernel completes booting, it immediately takes over the monitoring tasks of the fan and power supply, ensuring that these critical hardware components are always under control during the boot process. Subsequently, the system triggers the second kernel to boot via an internal interrupt. After booting, the second kernel takes over the global monitoring tasks, further optimizing the overall performance of the system.

[0066] In this embodiment, when the boot mode is set to single boot mode, the system boots only one of the first kernel or the second kernel. This boot method is suitable for specific simplified application scenarios, such as when performing system testing or maintenance, where only one kernel needs to be booted to perform a specific task. For example, when performing fan control strategy testing, only the first kernel (M33) is booted to perform basic monitoring tasks, without needing to boot the second kernel (A55).

[0067] In this embodiment, during the parallel operation of the first kernel and the second kernel, the first kernel and the second kernel will also read the health status register of their respective memory. If memory corruption is detected, an alarm will be triggered.

[0068] In this embodiment, the configuration of the startup mode enables the system to select the most suitable startup method according to different application scenarios and needs, thereby optimizing the efficiency and performance of the startup process.

[0069] In another embodiment, an upgrade partition is provided in the first flash memory, and a BMC optimization method for an AI server further includes:

[0070] The second kernel transfers the new RTOS firmware to the first flash memory of the first kernel;

[0071] The first kernel erases the upgrade partition and writes the new RTOS firmware to the upgrade partition;

[0072] The first kernel reads the new RTOS firmware from the upgrade partition and performs a reset and reboot based on the new RTOS firmware.

[0073] In this embodiment, a dedicated upgrade partition is provided in the first flash memory for storing new versions of the RTOS firmware. When an upgrade of the RTOS firmware of the first kernel is required, the second kernel is responsible for transferring the new version of the RTOS firmware from an external storage device (such as a secure digital card, network storage, etc.) to the upgrade partition of the first flash memory. This process can be accomplished through file transfer protocols or direct memory operations. For example, the second kernel can download the new version of the RTOS firmware from a server via a network and write it to the upgrade partition of the first flash memory.

[0074] In this embodiment, after the second kernel completes the transfer of the new RTOS firmware, the first kernel is responsible for erasing the upgrade partition to ensure that the data in the partition is up-to-date and complete. Subsequently, the first kernel writes the new RTOS firmware to the upgrade partition. This process needs to ensure data integrity and consistency to avoid firmware corruption due to write errors. For example, the first kernel can use mechanisms such as Cyclic Redundancy Check (CRC) to verify the integrity of the new firmware.

[0075] In this embodiment, after writing the new RTOS firmware, the first kernel reads the new firmware from the upgrade partition and performs a reset and reboot based on the new firmware. During the reboot process, the first kernel loads the new firmware and initializes the system to ensure that the new firmware can run normally. For example, before rebooting, the first kernel verifies the version number and checksum of the new firmware, and only performs the reboot operation after confirming that everything is correct. After rebooting, the system will run the new version of the RTOS firmware, thereby achieving seamless firmware upgrades.

[0076] In this disclosure, the existence of an upgrade partition ensures that the firmware update process does not interfere with the currently running firmware, avoiding system instability or boot failure due to upgrade failure. This design not only improves the maintainability and scalability of the system but also ensures high availability and reliability during the upgrade process.

[0077] In another embodiment, the second flash memory includes a primary root partition and a backup root partition. A BMC optimization method for an AI server further includes:

[0078] The second kernel obtains the new Linux firmware and writes the new Linux firmware to the backup root partition;

[0079] In response to the successful verification of the new Linux firmware, the boot partition of the second kernel is switched from the primary root partition to the backup root partition.

[0080] In this embodiment, the second flash memory is designed to contain two main root partitions: a primary root partition and a backup root partition. The primary root partition stores the currently running Linux firmware, while the backup root partition stores new Linux firmware or serves as a backup partition. When an update to the Linux firmware of the second kernel is required, the second kernel first obtains the new Linux firmware. After obtaining the new firmware, the second kernel writes the new firmware to the backup root partition. For example, the second kernel can download a new version of Linux firmware from a server via the network and write it to the backup root partition. During the writing process, the second kernel uses a verification mechanism (such as CRC checksum) to ensure data integrity and consistency.

[0081] In this embodiment, if the verification passes, the second kernel switches the boot partition from the primary root partition to the backup root partition. This switching process can be accomplished by updating the boot configuration register, ensuring that the system loads the new Linux firmware from the backup root partition upon the next boot. For example, the second kernel can instruct the boot system to boot from the backup root partition by writing specific register values. After the switch is complete, the system will run the new Linux firmware, thus completing the firmware update process. It is important to emphasize that when upgrading the firmware of either kernel, the other kernel remains running to ensure that the BMC always has monitoring capabilities.

[0082] In this disclosure, the dual-partition design allows the system to always maintain a usable system partition when updating firmware, thereby avoiding system boot failure due to firmware update failure.

[0083] Figure 2 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 2 ,like Figure 2 As shown, the basic monitoring subsystem running on the first kernel includes a hardware driver layer, a core service layer, and an application control layer. Step S101, "continuously collecting operating data of the fans and power supply in the AI ​​server and controlling the fans and power supply," includes:

[0084] Step S201: Based on the hardware driver layer, adapt the peripheral interface of the first kernel, read the operating data of the fan speed sensor and power parameter sensor through the communication bus interface, and transmit the control signal to the fan driver and power management module.

[0085] In this embodiment, the hardware driver layer is the bottom layer of the basic monitoring subsystem, primarily responsible for adapting the interface between the first core and peripherals. Specifically, the hardware driver layer reads the operating data from the fan speed sensor and power parameter sensor through the communication bus interface. For example, the hardware driver layer can periodically read the data from the fan speed sensor via the I2C (Inter-Integrated Circuit) bus, and read the voltage and current parameters of the power module via the SPI (Serial Peripheral Interface Bus). The hardware driver layer also transmits control signals to the fan driver and power management module to control the fan speed and power status. For example, the hardware driver layer can adjust the PWM (Pulse Width Modulation) signal of the fan driver according to the instructions of the application control layer, thereby changing the fan speed, or adjusting the output voltage of the power management module to ensure a stable power supply.

[0086] In one possible implementation, the hardware interface allocation for the first kernel to monitor the fan and power supply is as shown in Table 1 below:

[0087] Table 1

[0088]

[0089] Among them, FG signal is frequency generator signal, PSU is power supply unit, and SMBus is system management bus.

[0090] In one possible implementation, the FreeRTOS system running the first kernel prioritizes monitoring tasks as shown in Table 2 below:

[0091] Table 2

[0092]

[0093] In another possible implementation, the code scheme design for the hardware driver layer is as follows (taking I2C temperature sensing acquisition as an example):

[0094] #include "stm32l5xx_hal.h" / / Taking STM32L5 (M33 core) as an example, actual adaptation to the target chip is required.

[0095] #include "FreeRTOS.h"

[0096] #include "task.h"

[0097] #include "queue.h"

[0098] / / Global I2C handles and sensor queues

[0099] I2C_HandleTypeDef hi2c1;

[0100] QueueHandle_t Queue_Sensor; / / Queue for storing sensor data

[0101] / / I2C initialization function (100kHz, corresponding to M33 I2C1 peripheral)

[0102] void I2C_Sensor_Init(void) {

[0103] hi2c1.Instance = I2C1;

[0104] hi2c1.Init.Timing = 0x00702991; / / 100kHz timing configuration

[0105] hi2c1.Init.OwnAddress1 = 0;

[0106] hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;

[0107] hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE;

[0108] hi2c1.Init.OwnAddress2 = 0;

[0109] hi2c1.Init.OwnAddress2Masks = I2C_OA2_NOMASK;

[0110] hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE;

[0111] hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE;

[0112] if (HAL_I2C_Init(&hi2c1) != HAL_OK) {

[0113] Error_Handler(); / / Error handling needs to be added in actual projects

[0114] }

[0115] / / Initialize the sensor data queue (store 10 data entries, each containing 8 PSUs + 5 temperature sensors)

[0116] Queue_Sensor = xQueueCreate(10, sizeof(Sensor_Data_t));

[0117] if (Queue_Sensor == NULL) {

[0118] Error_Handler();

[0119] }

[0120] }

[0121] / / Definition of temperature sensing data structure

[0122] typedef struct {

[0123] uint32_t timestamp; / / Timestamp (ms)

[0124] int16_t psu_temp[8]; / / PSU temperature (unit: 0.1℃)

[0125] int16_t inlet_temp; / / Inlet air temperature (0.1℃)

[0126] int16_t outlet_temp; / / Outlet temperature (0.1℃)

[0127] int16_t vr_temp; / / VR temperature (0.1℃)

[0128] int16_t cpu_temp; / / CPU temperature (0.1℃)

[0129] int16_t gpu_temp; / / GPU temperature (0.1℃)

[0130] uint8_t crc8; / / Data parity bit

[0131] Sensor_Data_t;

[0132] Temperature sensor data acquisition task (executed every 50ms)

[0133] / / Sliding filter function (average of 5 samples)

[0134] int16_t sliding filter(int16_t new_val, int16_t buf, uint8_t idx) {

[0135] static uint8_t count = 0;

[0136] int32_t sum = 0;

[0137] buf[idx] = new_val;

[0138] count = (count>= 5) ? 5 : count + 1;

[0139] for (uint8_t i = 0; i <count; i++) {

[0140] sum += buf[i];

[0141] }

[0142] return (int16_t)(sum / count);

[0143] }

[0144] / / Sensor acquisition task function

[0145] void Sensor_Collect_Task(void pvParameters) {

[0146] Sensor_Data_t sensor_data;

[0147] int16_t psu_buf[8][5] = {0}; / / Filter buffer for 8-channel PSU

[0148] int16_t temp_buf[5][5] = {0}; / / Filter buffer for 5 key temperature sensors

[0149] uint8_t idx = 0;

[0150] for (;;) {

[0151] / / 1. Read the temperature of 8 PSUs (using TI TMP102 as an example, I2C address 0x48-0x4F)

[0152] for (uint8_t i = 0; i<8; i++) {

[0153] uint8_t i2c_data[2];

[0154] / / Send read command

[0155] HAL_I2C_Master_Receive(&hi2c1, (0x48 + i)<<1, i2c_data, 2, 10);

[0156] / / Conversion temperature (TMP102 12-bit precision, unit 0.0625℃, converted to 0.1℃ here)

[0157] int16_t raw_temp = (i2c_data[0]<<4) | (i2c_data[1]>>4);

[0158] if (raw_temp&0x800) raw_temp -= 0x1000; / / Two's complement processing

[0159] int16_t temp = (int16_t)(raw_temp 0.625); / / 0.0625℃ → 0.1℃

[0160] / / Sliding filter

[0161] sensor_data.psu_temp[i] = sliding filter(temp, psu_buf[i], idx % 5);

[0162] }

[0163] / / 2. Read the key temperature sensor (taking NTC as an example, I2C address 0x4A)

[0164] uint8_t ntc_data[2];

[0165] HAL_I2C_Master_Receive(&hi2c1, 0x4A<<1, ntc_data, 2, 10);

[0166] / / Analyze the temperature of the air inlet and outlet (specific protocol needs to be adapted according to the sensor manual).

[0167] sensor_data.inlet_temp = sliding filter((ntc_data[0]<<2) | (ntc_data[1]>>6), temp_buf[0], idx % 5);

[0168] sensor_data.outlet_temp = sliding filter(((ntc_data[1]&0x3F)<<4) | (ntc_data[2]>>4), temp_buf[1], idx % 5);

[0169] / / ... Similarly, analyze VR / CPU / GPU temperatures

[0170] / / 3. Data Validation and Timestamps

[0171] sensor_data.timestamp = xTaskGetTickCount(); / / Get FreeRTOS system time

[0172] sensor_data.crc8 = CRC8_Calculate((uint8_t )&sensor_data, sizeof(Sensor_Data_t)-1); / / Calculate CRC8

[0173] / / 4. Send data to the queue (timeout 10ms, to avoid blocking)

[0174] xQueueSend(Queue_Sensor,&sensor_data, 10);

[0175] / / 5. 50ms periodic delay

[0176] vTaskDelay(pdMS_TO_TICKS(50));

[0177] idx++;

[0178] }

[0179] }

[0180] In another possible implementation, the core algorithm of the fan PID control module is based on anti-integral saturation combined with dynamic parameters. The code implementation of the fan PID control module is as follows:

[0181] / / PID control structure

[0182] typedef struct {

[0183] float kp; / / Scale factor

[0184] float ki; / / Integral coefficient

[0185] float kd; / / Differential coefficients

[0186] float target; / / Target value (revolutional speed: RPM)

[0187] float feedback; / / Feedback value (actual rotational speed: RPM)

[0188] float error; / / Current error

[0189] float last_error; / / Last error

[0190] float integral; / / Integral term

[0191] float integral_max; / / Maximum integral value (to prevent saturation)

[0192] float output_max; / / Output limit (PWM duty cycle: 0-100)

[0193] float output_min; / / Output lower limit (PWM duty cycle: 0-20, to avoid stalling)

[0194] float output; / / Current output (PWM duty cycle)

[0195] } PID_HandleTypeDef;

[0196] / / PID initialization (tuning parameters based on fan characteristics)

[0197] void PID_Init(PID_HandleTypeDef pid, float kp, float ki, float kd) {

[0198] pid->kp = kp;

[0199] pid->ki = ki;

[0200] pid->kd = kd;

[0201] pid->integral_max = 500; / / Maximum integration value

[0202] pid->output_max = 100.0f;

[0203] pid->output_min = 20.0f;

[0204] pid->target = 1500.0f; / / Default target RPM 1500

[0205] pid->integral = 0.0f;

[0206] pid->last_error = 0.0f;

[0207] }

[0208] / / PID calculation (executed every 10ms)

[0209] float PID_Calculate(PID_HandleTypeDef pid) {

[0210] / / 1. Calculation error

[0211] pid->error = pid->target - pid->feedback;

[0212] / / 2. Proportional Term

[0213] float p_out = pid->kp pid->error;

[0214] / / 3. Integral terms (to prevent saturation)

[0215] pid->integral += pid->error;

[0216] if (pid->integral>pid->integral_max) pid->integral = pid->integral_max;

[0217] if (pid->integral<-pid->integral_max) pid->integral = -pid->integral_max;

[0218] float i_out = pid->ki pid->integral;

[0219] / / 4. Differential term (to avoid differential shocks, use the rate of change of error)

[0220] float d_out = pid->kd (pid->error - pid->last_error);

[0221] / / 5. Total Output and Limiting

[0222] pid->output = p_out + i_out + d_out;

[0223] if (pid->output>pid->output_max) pid->output = pid->output_max;

[0224] if (pid->output <pid->output_min) pid->output = pid->output_min;

[0225] / / 6. Save the current error

[0226] pid->last_error = pid->error;

[0227] return pid->output;

[0228] }

[0229] In another possible implementation, the code for the fan control task (10ms cycle, including speed acquisition and PWM output) is as follows:

[0230] / / Global variables: PID handles and states of 20 fans

[0231] PID_HandleTypeDef fan_pid

[20] ;

[0232] Fan_Status_t fan_status

[20] ; / / Fan status: speed, fault flags, etc.

[0233] / / Read fan speed (capture FG signal frequency via timer input)

[0234] uint16_t Fan_Read_Speed(TIM_HandleTypeDef htim, uint8_t channel) {

[0235] / / Configure the timer to input capture mode and calculate the FG signal frequency (rotation speed = frequency × 60 / number of pole pairs).

[0236] uint32_t freq = HAL_TIM_ReadCapturedValue(htim, channel);

[0237] if (freq == 0) return 0; / / 0 RPM is considered a fault.

[0238] return (uint16_t)((1000000 / freq) 60 / 2); / / Assuming the number of magnetic pole pairs is 2

[0239] }

[0240] / / Fan control task function

[0241] void Fan_PID_Control_Task(void pvParameters) {

[0242] Sensor_Data_t sensor_data;

[0243] uint16_t target_speed

[20] ; / / Target speed of 20 fans

[0244] / / 1. Initialize the PID parameters of 20 fans (tune them by position, e.g., kp=2.5 for edge fans and kp=3.0 for center fans)

[0245] for (uint8_t i = 0; i<20; i++) {

[0246] if (i<8) PID_Init(&fan_pid[i], 2.5f, 0.1f, 0.05f); / / Edge fan

[0247] else PID_Init(&fan_pid[i], 3.0f, 0.12f, 0.06f); / / Center fan

[0248] }

[0249] for (;;) {

[0250] / / 2. Read sensor data from the queue (timeout 50ms, use the last data if no data is available)

[0251] if (xQueueReceive(Queue_Sensor,&sensor_data, 50) == pdTRUE) {

[0252] / / 3. Calculate the target speed based on temperature (temperature-speed mapping table, example: GPU temperature dominates the center fan, inlet temperature dominates the edge fans)

[0253] / / Target speed of the center fan = base speed 1000 + (GPU temperature - 40℃) × 50 (speed increases when GPU temperature > 40℃)

[0254] for (uint8_t i = 8; i<20; i++) {

[0255] float gpu_temp = sensor_data.gpu_temp / 10.0f; / / Convert to °C

[0256] target_speed[i] = (gpu_temp>40.0f) ? (1000 + (gpu_temp - 40) 50) :1000;

[0257] if (target_speed[i]>3000) target_speed[i] = 3000; / / Upper limit 3000RPM

[0258] fan_pid[i].target = target_speed[i];

[0259] }

[0260] / / Edge fan target speed = base speed 800 + (inlet temperature - 30℃) × 40 (speed increases when inlet temperature > 30℃)

[0261] for (uint8_t i = 0; i<8; i++) {

[0262] float inlet_temp = sensor_data.inlet_temp / 10.0f;

[0263] target_speed[i] = (inlet_temp>30.0f) ? (800 + (inlet_temp - 30) 40): 800;

[0264] if (target_speed[i]>2500) target_speed[i] = 2500;

[0265] fan_pid[i].target = target_speed[i];

[0266] }

[0267] }

[0268] / / 4. Read the actual speeds of 20 fans, perform PID calculations, and output PWM.

[0269] for (uint8_t i = 0; i<20; i++) {

[0270] / / Read RPM (timers corresponding to fan groups)

[0271] if (i<4) fan_pid[i].feedback = Fan_Read_Speed(&htim2, TIM_CHANNEL_1 +i);

[0272] else if (i<8) fan_pid[i].feedback = Fan_Read_Speed(&htim3, TIM_CHANNEL_1 + (i-4));

[0273] / / ... Similarly, adapt to other timers

[0274] / / Check for fan malfunction (speed = 0 or deviation > 50%).

[0275] fan_status[i].fault = (fan_pid[i].feedback == 0) || (abs(fan_pid[i].target - fan_pid[i].feedback)>fan_pid[i].target 0.5f);

[0276] if (fan_status[i].fault) {

[0277] / / Output maximum PWM and trigger the exception queue in case of a fault.

[0278] HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_1 + (i / 5)); / / Start PWM by group

[0279] __HAL_TIM_SET_COMPARE(&htim1, TIM_CHANNEL_1 + (i / 5), 100); / / 100% duty cycle

[0280] xQueueSend(Queue_Error,&(Fan_Error_t){i, fan_pid[i].feedback}, 0);

[0281] } else {

[0282] / / Normally, the PID controller is executed, and the PWM output is generated.

[0283] float pwm_duty = PID_Calculate(&fan_pid[i]);

[0284] HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_1 + (i / 5));

[0285] __HAL_TIM_SET_COMPARE(&htim1, TIM_CHANNEL_1 + (i / 5), (uint32_t)pwm_duty);

[0286] }

[0287] / / Save current speed

[0288] fan_status[i].speed = fan_pid[i].feedback;

[0289] }

[0290] / / 5. 10ms periodic delay

[0291] vTaskDelay(pdMS_TO_TICKS(10));

[0292] }

[0293] }

[0294] In one possible implementation, the code for the exception handling and data interaction module is as follows:

[0295] a) Emergency fault handling task (interrupt triggered)

[0296] QueueHandle_t Queue_Error; / / Exception queue

[0297] / / Over-temperature interrupt service function (GPIO external interrupt)

[0298] void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {

[0299] BaseType_t xHigherPriorityTaskWoken = pdFALSE;

[0300] Error_Data_t error = {0};

[0301] if (GPIO_Pin == GPU_OVER_TEMP_Pin) {

[0302] error.type = ERROR_GPU_OVER_TEMP;

[0303] error.value = 95; / / Temperature exceeds the threshold of 95℃

[0304] } else if (GPIO_Pin == FAN_FAULT_Pin) {

[0305] error.type = ERROR_FAN_FAULT;

[0306] error.value = GPIO_Pin - FAN_FAULT_Pin; / / Locate the faulty fan number

[0307] }

[0308] / / Send an exception to the queue to wake up high-priority tasks

[0309] xQueueSendFromISR(Queue_Error,&error,&xHigherPriorityTaskWoken);

[0310] portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

[0311] }

[0312] / / Emergency troubleshooting task

[0313] void Fault_Handle_Task(void pvParameters) {

[0314] Error_Data_t error;

[0315] for (;;) {

[0316] / / Wait for exception queue data (permanent block, ensuring fast response)

[0317] if (xQueueReceive(Queue_Error,&error, portMAX_DELAY) == pdTRUE) {

[0318] switch (error.type) {

[0319] case ERROR_GPU_OVER_TEMP:

[0320] / / Execute emergency policy: all fans run at full speed, trigger PSU alarm.

[0321] for (uint8_t i = 0; i<20; i++) {

[0322] HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_1 + (i / 5));

[0323] __HAL_TIM_SET_COMPARE(&htim1, TIM_CHANNEL_1 + (i / 5), 100);

[0324] }

[0325] HAL_GPIO_WritePin(PSU_ALARM_GPIO_Port, PSU_ALARM_Pin, GPIO_PIN_SET);

[0326] break

[0327] case ERROR_FAN_FAULT:

[0328] / / Increase the speed of other fans in the same location as the faulty fan by 20%.

[0329] uint8_t fault_fan = error.value;

[0330] uint8_t group = fault_fan / 5; / / Locate the fan group

[0331] for (uint8_t i = group 5; i<(group+1) 5; i++) {

[0332] if (i != fault_fan) {

[0333] fan_pid[i].target = 1.2f;

[0334] if (fan_pid[i].target>3000) fan_pid[i].target = 3000;

[0335] }

[0336] }

[0337] break

[0338] }

[0339] / / Trigger A55 interrupt and synchronize exception information

[0340] HAL_GPIO_WritePin(A55_INT_GPIO_Port, A55_INT_Pin, GPIO_PIN_SET);

[0341] vTaskDelay(pdMS_TO_TICKS(10));

[0342] HAL_GPIO_WritePin(A55_INT_GPIO_Port, A55_INT_Pin, GPIO_PIN_RESET);

[0343] }

[0344] }

[0345] }

[0346] b) Data interaction with A55 (shared memory + periodic synchronization)

[0347] / / Shared memory region definition (M33 and A55 agreed address: 0x20000000, size 1KB)

[0348] #define SHARED_MEM_ADDR (uint32_t)0x20000000

[0349] Shared_Data_t shared_data = (Shared_Data_t )SHARED_MEM_ADDR;

[0350] / / Shared data structure

[0351] typedef struct {

[0352] uint8_t sync_flag; / / Synchronization flag (0: not updated, 1: readable)

[0353] Sensor_Data_t last_sensor; / / Latest sensor data

[0354] Fan_Status_t fan_status

[20] ; / / Fan status

[0355] PID_Param_t pid_param

[20] ; / / PID parameters issued by A55

[0356] Shared_Data_t;

[0357] / / Data interaction task

[0358] void Data_Exchange_Task(void pvParameters) {

[0359] Sensor_Data_t sensor_data;

[0360] for (;;) {

[0361] / / 1. Write data to shared memory (clear the flag first, then set it again after writing).

[0362] if (xQueuePeek(Queue_Sensor,&sensor_data, 10) == pdTRUE) {

[0363] shared_data->sync_flag = 0; / / Disable A55 reads

[0364] memcpy(&shared_data->last_sensor,&sensor_data, sizeof(Sensor_Data_t));

[0365] memcpy(shared_data->fan_status, fan_status, sizeof(Fan_Status_t) 20);

[0366] shared_data->sync_flag = 1; / / Allow A55 to read

[0367] }

[0368] / / 2. Read A55 configuration from shared memory (e.g., PID parameter updates)

[0369] if (shared_data->pid_param[0].update_flag == 1) {

[0370] for (uint8_t i = 0; i<20; i++) {

[0371] fan_pid[i].kp = shared_data->pid_param[i].kp;

[0372] fan_pid[i].ki = shared_data->pid_param[i].ki;

[0373] fan_pid[i].kd = shared_data->pid_param[i].kd;

[0374] }

[0375] shared_data->pid_param[0].update_flag = 0; / / Clear the update flag

[0376] }

[0377] / / 3. 100ms periodic delay

[0378] vTaskDelay(pdMS_TO_TICKS(100));

[0379] }

[0380] }

[0381] In another possible implementation, the code design for submodule reliability is as follows:

[0382] System startup initialization (main function)

[0383] int main(void) {

[0384] / / 1. Hardware initialization (clock, GPIO, I2C, PWM, timers)

[0385] HAL_Init();

[0386] SystemClock_Config(); / / Configure the M33 core clock to 800MHz

[0387] MX_GPIO_Init();

[0388] MX_I2C1_Init();

[0389] MX_TIM1_Init(); / / PWM timer

[0390] MX_TIM2_Init(); / / Rotational speed acquisition timer

[0391] / / ... Initialize other peripherals

[0392] / / 2. FreeRTOS Task Creation

[0393] xTaskCreate(Fault_Handle_Task,"Fault_Handle",1024, NULL, tskIDLE_PRIORITY+3, NULL);

[0394] xTaskCreate(Fan_PID_Control_Task,"Fan_PID_Control",2048, NULL,tskIDLE_PRIORITY+2, NULL);

[0395] xTaskCreate(Sensor_Collect_Task, "Sensor_Collect", 1024, NULL,tskIDLE_PRIORITY+1, NULL);

[0396] xTaskCreate(Data_Exchange_Task,"Data_Exchange",1024, NULL, tskIDLE_PRIORITY+0, NULL);

[0397] xTaskCreate(Log_Alarm_Task,"Log_Alarm",512,NULL, tskIDLE_PRIORITY-1,NULL);

[0398] / / 3. Start the task scheduler

[0399] vTaskStartScheduler();

[0400] / / If the scheduler fails to start, it will enter an infinite loop.

[0401] for (;;) {

[0402] Error_Handler();

[0403] }

[0404] }

[0405] In this embodiment, reliability is further ensured by the following methods: all sensor data is checked with CRC8, and shared memory data is timestamped to avoid transmission errors; FreeRTOS's Task Watchdog is enabled to monitor timeouts for core tasks (such as PID control and fault handling), and the task is restarted if a timeout occurs; range limits are set for key configurations such as PID parameters and speed limits (e.g., the proportional parameter kp in PID is ∈ [0.5, 5.0]) to prevent illegal configurations from causing system malfunction; when a single fan fails, other fans in the same group automatically increase their speed by 20%; the most recent 100 abnormal logs (including timestamps, fault types, and data snapshots) are stored in local Flash, and can be read and exported using A55.

[0406] Step S202: Based on the core service layer receiving the running data output by the hardware driver layer, the running data is processed by sliding filtering, CRC check and format standardization, and the processed running data is transmitted to the application control layer. At the same time, the control instructions sent by the application control layer are forwarded to the hardware driver layer.

[0407] In this embodiment, the core service layer is located between the hardware driver layer and the application control layer, and is mainly responsible for preprocessing the operational data output by the hardware driver layer. Specifically, the core service layer performs sliding average filtering on the operational data to smooth fluctuations in sensor data and improve data stability. For example, for fan speed data, the core service layer uses a sliding average filtering algorithm to calculate the average of the most recent sampled data, thereby obtaining a more stable speed value. The core service layer also performs CRC check on the operational data to ensure data integrity and accuracy. In addition, the core service layer performs format standardization processing on the operational data, converting it into a format that the application control layer can recognize and process. The processed operational data is transmitted to the application control layer, and the core service layer also forwards the control commands sent by the application control layer to the hardware driver layer, ensuring that the control commands can be delivered to the corresponding hardware modules in a timely manner.

[0408] Step S203: Based on the application control layer, the acquisition task and control task are executed according to the preset priority. The acquisition task obtains and stores the processed running data from the core service layer in the first cycle. The control task calculates the control quantity through the PID algorithm based on the processed running data and the strategy optimization parameters issued by the second kernel. The core service layer and the hardware driver layer adjust the fan speed and power status based on the control quantity.

[0409] In this embodiment, the application control layer is the top layer of the basic monitoring subsystem, primarily responsible for executing data acquisition and control tasks according to preset priorities. The data acquisition task retrieves processed operational data from the core service layer at predetermined intervals (e.g., 50ms) and stores it in memory or external storage for subsequent data analysis and processing. The control task calculates the control quantity using a PID algorithm based on the processed operational data and strategy optimization parameters issued by the second kernel. For example, the control task can calculate a new PWM duty cycle based on the error between the current fan speed and the target speed, thereby adjusting the fan speed. The core service layer and hardware driver layer adjust the fan speed and power supply status according to the calculated control quantity, ensuring that the AI ​​server's hardware components operate in optimal condition.

[0410] In this disclosure, by adopting a layered architecture design, the basic monitoring subsystem can efficiently collect and process the operating data of the fans and power supply in the AI ​​server, and precisely control them. The hardware driver layer adapts to peripheral interfaces, ensuring the reliability of data acquisition and control signal transmission. The core service layer performs sliding filtering, CRC check, and format standardization on the operating data, improving the stability and accuracy of the data. The application control layer executes acquisition and control tasks according to preset priorities, and calculates control quantities through a PID algorithm, realizing the dynamic adjustment of the fans and power supply.

[0411] In another embodiment, the data interaction interface is obtained based on the shared SRAM of the first and second kernels in the second kernel, and step S102, "the first kernel and the second kernel exchange monitoring information through the data interaction interface", includes:

[0412] The first kernel synchronizes monitoring data to the shared SRAM in the second cycle;

[0413] When the second kernel needs to access the shared SRAM, it sends an access request to the first kernel through a designated interrupt channel; after the first kernel completes the current operation, it releases control of the shared SRAM and sends an interrupt notification to the second kernel; after the second kernel completes its access to the shared SRAM, it sends an interrupt notification to the first kernel.

[0414] In this embodiment, the data interaction interface between the first and second cores is implemented based on shared SRAM (Static Random-Access Memory). This design allows the two cores to efficiently share and exchange monitoring information. The BMC chip's own A55 core contains a 256KB SRAM, which can be used as shared memory. Under normal conditions, the first core has default access to the shared SRAM and updates the data periodically.

[0415] In this embodiment, when the first kernel and the second kernel exchange monitoring information through a data interaction interface, the first kernel synchronizes the collected monitoring data to the shared SRAM at a predetermined period (e.g., 100ms). This period is preset according to the system's real-time requirements and data processing capabilities. For example, the first kernel can package monitoring data such as fan speed and power parameters and write them to the shared SRAM at 100ms intervals. In this way, the second kernel can read the latest monitoring data at any time, thereby realizing global monitoring and strategy optimization of the AI ​​server.

[0416] In this embodiment, when the second kernel needs to access the shared SRAM, it initiates an access request to the first kernel through a designated interrupt channel. For example, the second kernel can send the request to the first kernel via a hardware interrupt signal or a software interrupt mechanism. After completing its current operation, the first kernel releases control of the shared SRAM and notifies the second kernel via an interrupt. After accessing the shared SRAM, the second kernel also notifies the first kernel via an interrupt, informing it that the access is complete. This interrupt-based access mechanism ensures high efficiency and low latency in data interaction between the two kernels, while avoiding resource waste caused by busy-waiting.

[0417] In one embodiment, the shared SRAM can be divided into a control register area, a sensor data area, a task status area, a command buffer, an event log area, a shared configuration area, and a reserved area. The control register area stores key flags required for interaction between the first and second kernels. The sensor data area stores the operating data of the fan and power supply collected by the first kernel. The task status area stores the operating status of each task in the first kernel. The command buffer stores control commands issued by the second kernel, allowing the first kernel to read control commands from the command buffer. The event log area stores target events and fault information. The shared configuration area stores configuration parameters shared by the first and second kernels. The reserved area reserves space for future expansion.

[0418] In one possible implementation, the allocation of the 16 interrupt channels in the data interaction interface is shown in Table 3 below:

[0419] Table 3

[0420]

[0421] In this embodiment, the design code for the control register area structure is as follows:

[0422] / / Shared SRAM control structure (64B)

[0423] typedef struct {

[0424] / / Access Control

[0425] uint32_t sram_lock; / / SRAM access lock (0: unlocked, 1: A55 locked, 2: M33 locked)

[0426] uint32_t data_version; / / Data version number (auto-increments with each update)

[0427] / / Interruption status

[0428] uint16_t int_status; / / Interrupt status register

[0429] uint16_t int_mask; / / Interrupt mask register

[0430] / / System Status

[0431] uint8_t a55_state; / / A55 system state (0: not ready, 1: running, 2: hibernating)

[0432] uint8_t m33_state; / / M33 system state (0: not ready, 1: running, 2: fault)

[0433] uint8_t resource_owner

[16] ; / / Shared resource owner (0:A55, 1:M33), corresponding to 16 types of shared peripherals

[0434] uint8_t failover_flag; / / Failover flag (each bit corresponds to one takeover task)

[0435] / / Validation and Retention

[0436] uint32_t crc32; / / CRC checksum for control area

[0437] uint8_t reserved

[32] ; / / Reserved

[0438] SharedControl_t

[0439] In one possible implementation, the code design for the sensor data area structure is as follows:

[0440] / / Sensor data structure (8KB)

[0441] typedef struct {

[0442] uint32_t timestamp; / / Data collection timestamp (ms)

[0443] / / Fan data (20 fans)

[0444] struct {

[0445] uint16_t speed; / / Actual rotational speed (RPM)

[0446] uint16_t target_speed; / / Target rotational speed (RPM)

[0447] uint8_t pwm; / / PWM duty cycle (0-100)

[0448] uint8_t status; / / Status (0: normal, 1: fault)

[0449] } fan

[20] ;

[0450] / / PSU data (8 PSUs)

[0451] struct {

[0452] int16_t temp; / / Temperature (0.1℃)

[0453] uint16_t voltage; / / Voltage (mV)

[0454] uint16_t current; / / Current (mA)

[0455] uint8_t status; / / Status (0: normal, 1: warning, 2: fault)

[0456] } psu[8];

[0457] / / Key temperature sensor

[0458] int16_t inlet_temp; / / Inlet air temperature (0.1℃)

[0459] int16_t outlet_temp; / / Outlet temperature (0.1℃)

[0460] int16_t vr_temp; / / VR temperature (0.1℃)

[0461] int16_t cpu_temp; / / CPU temperature (0.1℃)

[0462] int16_t gpu_temp[8]; / / GPU temperature (0.1℃), supports 8 GPUs

[0463] / / Data validation

[0464] uint32_t crc32; / / CRC checksum for data area

[0465] SensorData_t

[0466] In one possible implementation, the design code for the task state area structure is as follows:

[0467] / / Task state structure (4KB)

[0468] typedef struct {

[0469] uint32_t timestamp; / / Status update timestamp

[0470] / / M33 Task Status (Maximum 16 tasks)

[0471] struct {

[0472] uint8_t id; / / Task ID

[0473] uint8_t state; / / State (0: Not running, 1: Running, 2: Blocked, 3: Faulty)

[0474] uint8_t cpu_usage; / / CPU utilization (%)

[0475] uint8_t priority; / / Task priority

[0476] uint32_t last_heartbeat; / / Last heartbeat timestamp

[0477] uint32_t error_code; / / Error code (0: no error)

[0478] uint32_t run_count; / / Run counter

[0479] } tasks

[16] ;

[0480] / / Shared peripheral status

[0481] struct {

[0482] uint8_t type; / / Peripheral type (0: GPIO, 1: I2C, 2: SPI, 3: I3C)

[0483] uint8_t id; / / Peripheral ID

[0484] uint8_t status; / / Status (0: Idle, 1: In use, 2: Faulty)

[0485] uint32_t last_operation; / / Last operation timestamp

[0486] } peripherals

[16] ;

[0487] uint32_t crc32; / / CRC checksum for status area

[0488] TaskStatus_t

[0489] In one possible implementation, the code design of the command buffer structure is as follows:

[0490] / / Command structure

[0491] typedef struct {

[0492] uint8_t cmd_id; / / Command ID

[0493] uint8_t src; / / Command source (0:A55, 1:M33)

[0494] uint8_t dst; / / Command target (0:A55, 1:M33)

[0495] uint8_t status; / / Command status (0: not processed, 1: processing, 2: completed, 3: failed)

[0496] uint32_t timestamp; / / Command timestamp

[0497] uint32_t param[8]; / / Command parameters

[0498] uint32_t result; / / Command result

[0499] Command_t;

[0500] / / Command buffer (8KB)

[0501] typedef struct {

[0502] Command_t cmds

[32] ; / / 32-line command buffer

[0503] uint8_t write_idx; / / Write index

[0504] uint8_t read_idx; / / Read index

[0505] uint8_t count; / / Command count

[0506] uint32_t crc32; / / Command area CRC check

[0507] CommandBuffer_t.

[0508] In one possible implementation, the access switching between the first kernel and the second kernel is as follows:

[0509] When A55 needs access, it sends an access request through interrupt channel 4.

[0510] Upon receiving the request, M33 completes the current operation and releases control of the shared SRAM.

[0511] M33 sets the access control lock sram_lock to 1 (A55 locks), and notifies A55 via interrupt channel 3;

[0512] After A55 access is completed, sram_lock is set to 2 (M33 lock), and M33 is notified through interrupt channel 4;

[0513] Forced access: When the A55 detects an M33 fault, it can forcibly acquire control of the shared SRAM through a hardware mechanism.

[0514] In this disclosure, by setting a shared SRAM between the first kernel and the second kernel as a data interaction interface, efficient and low-latency data exchange between the two kernels is achieved, further optimizing the system performance and enhancing the system's stability and reliability.

[0515] Figure 3 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 3 ,like Figure 3 As shown, step S103, "If the target kernel detects another kernel anomaly, the target kernel takes over the monitoring task of the abnormal kernel," includes:

[0516] Step S301: When the second kernel detects an anomaly in the target task in the first kernel through the task status area of ​​the data interaction interface, it sets a status flag bit to identify the target task that needs to be taken over, and sends a task takeover notification through the command buffer of the data interaction interface.

[0517] In this embodiment, when the second kernel detects an anomaly in a target task in the first kernel through the task status area of ​​the data interaction interface, it sets a status flag to identify the task that needs to be taken over. For example, if a monitoring task (such as a fan control task) in the first kernel malfunctions, the second kernel will mark the task as abnormal in the task status area. Subsequently, the second kernel sends a task takeover notification to the first kernel through the command buffer of the data interaction interface. This notification contains specific task identification information, ensuring that the first kernel understands which tasks need to be taken over.

[0518] In step S302, the second kernel acquires control of the shared peripheral corresponding to the target task and takes over the target task.

[0519] In this embodiment, upon receiving a task takeover notification, the second kernel acquires control of the shared peripheral corresponding to the target task. For example, if the target task is a fan control task, the second kernel will acquire control of the fan driver. This process is completed through a hardware resource allocation mechanism, ensuring that the second kernel can seamlessly take over the task. After takeover, the second kernel will be responsible for executing the target task, such as continuing to monitor the fan speed and adjusting control signals as needed.

[0520] In step S303, after the target task failure of the first kernel is detected to have recovered, the second kernel clears the status flag bit, releases control of the shared peripheral, and the first kernel takes over the target task again.

[0521] In this embodiment, if the faulty task of the first kernel resumes operation, the second kernel will detect this change. Specifically, the second kernel will check the task status of the first kernel through the task status area. Once it is confirmed that the task has returned to normal, the second kernel will clear the previously set status flag and release control of the shared peripheral. For example, if the fan control task resumes normal operation, the second kernel will clear the task fault flag and return control of the fan driver to the first kernel. The first kernel will then take over the task again, ensuring that the system monitoring task can continue to run stably.

[0522] For ease of understanding of this embodiment, the following is used: Figure 6 This document uses an example to illustrate the kernel exception handling logic in this disclosure. Figure 6 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 5 ,like Figure 6 As shown, after the system powers on, A55 and M33 complete initialization, and then both systems operate normally, sending heartbeat packets to each other. During this process, M33 checks if A55 is functioning correctly. If the check is successful, the two systems maintain normal operation and continue sending heartbeat packets. If the check is unsuccessful (heartbeat loss for 3 seconds), M33 confirms an A55 malfunction and then enters takeover mode, running basic functions such as critical sensor monitoring, minimum fan control, and basic network communication. Afterward, M33 checks if A55 has recovered. If A55 recovers, M33 exits takeover mode and returns to normal operation and heartbeat packet sending between the two systems. If A55 does not recover, it continues to run basic functions and maintains monitoring.

[0523] Simultaneously, the A55 will also check if M33 is functioning correctly. If the check is successful, both systems will continue to operate normally and exchange heartbeat packets. If the check is unsuccessful (heartbeat lost for 3 seconds), the A55 will confirm that M33 is malfunctioning. Then, the A55 will activate takeover mode, taking over all functions including all sensors, restoring fan PID control, and taking over all peripherals. Afterward, the A55 will check if M33 has recovered. If M33 has recovered, the A55 will exit takeover mode and return to normal operation of both systems, exchanging heartbeat packets. If M33 has not recovered, it will continue to run all functions and maintain monitoring.

[0524] In one possible implementation, the kernel exception handling code is designed as follows:

[0525] / / Dual system state definition

[0526] typedef enum {

[0527] SYS_STATE_NORMAL = 0, / / Normal operation

[0528] SYS_STATE_WARNING = 1, / / Warning status

[0529] SYS_STATE_ERROR = 2, / / Error status

[0530] SYS_STATE_FAULT = 3 / / Fault status

[0531] SysState_t;

[0532] / / Shared exception control structure

[0533] typedef struct {

[0534] / / System Status

[0535] SysState_t a55_state; / / A55 system state

[0536] SysState_t m33_state; / / M33 system state

[0537] uint32_t a55_heartbeat; / / A55 heartbeat timestamp (ms)

[0538] uint32_t m33_heartbeat; / / M33 heartbeat timestamp (ms)

[0539] / / Fault marker

[0540] uint16_t a55_fault_bits; / / A55 fault bitmap

[0541] uint16_t m33_fault_bits; / / M33 fault bitmap

[0542] / / Takeover Control

[0543] uint8_t takeover_flag; / / Takeover flag (0 = no takeover, 1 = A55 takeover, 2 = M33 takeover)

[0544] uint8_t takeover_mask; / / Takeover function mask

[0545] uint32_t crc; / / Checksum

[0546] } FaultControl_t;

[0547] / / Function mask definition

[0548] #define FUNC_SENSOR_MON(1<<0) / / Sensor monitoring

[0549] #define FUNC_FAN_CONTROL (1<<1) / / Fan control

[0550] #define FUNC_NET_COMM(1<<2) / / Network communication

[0551] #define FUNC_REMOTE_RESET (1<<3) / / Remote restart

[0552] 2.2.4.2.2 Implementation of Anomaly Handling on the M33 Side

[0553] / / M33 monitoring A55 status task

[0554] void M33_Monitor_A55_Task(void pvParameters) {

[0555] FaultControl_t fault_ctrl = (FaultControl_t )SHARED_FAULT_ADDR;

[0556] uint32_t check_count = 0;

[0557] const uint32_t HEARTBEAT_TIMEOUT = 3000; / / Heartbeat timeout threshold (3s)

[0558] for (;;) {

[0559] / / 1. Update your own heart rate

[0560] fault_ctrl->m33_heartbeat = xTaskGetTickCount();

[0561] fault_ctrl->m33_state = SYS_STATE_NORMAL;

[0562] / / 2. Check A55 status

[0563] uint32_t current_tick = xTaskGetTickCount();

[0564] if (current_tick - fault_ctrl->a55_heartbeat>HEARTBEAT_TIMEOUT ||

[0565] fault_ctrl->a55_state == SYS_STATE_FAULT) {

[0566] / / A55 error: 3 consecutive confirmations

[0567] check_count++;

[0568] if (check_count>= 3) {

[0569] / / Mark A55 fault

[0570] fault_ctrl->a55_fault_bits = 0xFFFF;

[0571] fault_ctrl->takeover_flag = 2; / / M33 takes over

[0572] fault_ctrl->takeover_mask = FUNC_SENSOR_MON | FUNC_FAN_CONTROL |

[0573] FUNC_NET_COMM | FUNC_REMOTE_RESET;

[0574] / / Enable M33 backup function

[0575] M33_Start_Backup_Functions(fault_ctrl->takeover_mask);

[0576] / / Try restarting the A55

[0577] M33_Reset_A55();

[0578] check_count = 0;

[0579] }

[0580] } else {

[0581] / / A55 has returned to normal and is currently under takeover.

[0582] if (fault_ctrl->takeover_flag == 2) {

[0583] / / Release of takeover rights

[0584] fault_ctrl->takeover_flag = 0;

[0585] M33_Stop_Backup_Functions();

[0586] }

[0587] check_count = 0;

[0588] }

[0589] / / Calculate CRC

[0590] fault_ctrl->crc = crc32_calculate((uint8_t )fault_ctrl, sizeof(FaultControl_t)-4);

[0591] vTaskDelay(pdMS_TO_TICKS(500)); / / Check once every 500ms

[0592] }

[0593] }

[0594] / / M33 Start Backup Function

[0595] void M33_Start_Backup_Functions(uint8_t func_mask) {

[0596] / / Take over sensor monitoring

[0597] if (func_mask&FUNC_SENSOR_MON) {

[0598] xTaskCreate(M33_Sensor_Monitor_Task, "SensorMon", 1024, NULL, 2,NULL);

[0599] }

[0600] / / Take over fan control

[0601] if (func_mask&FUNC_FAN_CONTROL) {

[0602] xTaskCreate(M33_Fan_Control_Task, "FanCtrl", 1024, NULL, 3, NULL);

[0603] }

[0604] / / Start basic network communication

[0605] if (func_mask&FUNC_NET_COMM) {

[0606] M33_Init_Basic_Network();

[0607] }

[0608] / / Enable remote restart function

[0609] if (func_mask&FUNC_REMOTE_RESET) {

[0610] xTaskCreate(M33_Remote_Reset_Task, "RemoteRst", 512, NULL, 1, NULL);

[0611] }

[0612] / / Turn on the warning light

[0613] HAL_GPIO_WritePin(ALARM_LED_GPIO_Port, ALARM_LED_Pin, GPIO_PIN_SET);

[0614] }

[0615] / / A55 monitoring M33 status thread

[0616] void A55_Monitor_M33_Thread(void arg) {

[0617] FaultControl_t fault_ctrl = (FaultControl_t )SHARED_FAULT_ADDR;

[0618] uint32_t check_count = 0;

[0619] const uint32_t HEARTBEAT_TIMEOUT = 3000; / / Heartbeat timeout threshold (3s)

[0620] int takeover_in_progress = 0;

[0621] while (1) {

[0622] / / 1. Update your own heart rate

[0623] fault_ctrl->a55_heartbeat = get_system_ms();

[0624] fault_ctrl->a55_state = SYS_STATE_NORMAL;

[0625] / / 2. Check M33 status

[0626] uint32_t current_tick = get_system_ms();

[0627] if (current_tick - fault_ctrl->m33_heartbeat>HEARTBEAT_TIMEOUT ||

[0628] fault_ctrl->m33_state == SYS_STATE_FAULT) {

[0629] / / M33 error: Confirmed 3 times consecutively

[0630] check_count++;

[0631] if (check_count>= 3&&!takeover_in_progress) {

[0632] / / Mark M33 fault

[0633] fault_ctrl->m33_fault_bits = 0xFFFF;

[0634] fault_ctrl->takeover_flag = 1; / / A55 takes over

[0635] fault_ctrl->takeover_mask = FUNC_SENSOR_MON | FUNC_FAN_CONTROL;

[0636] / / Take over M33 functions

[0637] A55_Takeover_M33_Functions(fault_ctrl->takeover_mask);

[0638] takeover_in_progress = 1;

[0639] check_count = 0;

[0640] }

[0641] } else {

[0642] M33 has returned to normal and is currently under takeover control.

[0643] if (takeover_in_progress) {

[0644] / / Release of takeover rights

[0645] fault_ctrl->takeover_flag = 0;

[0646] A55_Release_M33_Functions();

[0647] takeover_in_progress = 0;

[0648] }

[0649] check_count = 0;

[0650] }

[0651] / / Calculate CRC

[0652] fault_ctrl->crc = crc32_calculate((uint8_t )fault_ctrl, sizeof(FaultControl_t)-4);

[0653] usleep(500000); / / Check every 500ms

[0654] }

[0655] return NULL;

[0656] }

[0657] / / A55 takes over M33 functions

[0658] int A55_Takeover_M33_Functions(uint8_t func_mask) {

[0659] / / Seize shared peripherals

[0660] a55_claim_shared_peripherals();

[0661] / / Take over sensor monitoring

[0662] if (func_mask&FUNC_SENSOR_MON) {

[0663] pid_t pid = fork();

[0664] if (pid == 0) {

[0665] execl(" / usr / bin / a55_sensor_mon", "a55_sensor_mon", NULL);

[0666] exit(0);

[0667] }

[0668] }

[0669] / / Take over fan control

[0670] if (func_mask&FUNC_FAN_CONTROL) {

[0671] pid_t pid = fork();

[0672] if (pid == 0) {

[0673] execl(" / usr / bin / a55_fan_ctrl", "a55_fan_ctrl", NULL);

[0674] exit(0);

[0675] }

[0676] }

[0677] / / Record takeover logs

[0678] syslog(LOG_ERR, "A55 takeover M33 functions, mask: 0x%x", func_mask);

[0679] return 0;

[0680] }

[0681] This disclosure provides a highly reliable and efficient task takeover mechanism by setting status flags and a task takeover notification mechanism. This mechanism allows a kernel to quickly take over and execute the relevant tasks when it detects an anomaly in another kernel task, ensuring the continuity of monitoring tasks. Simultaneously, when the failed task recovers, the system can smoothly return control to the original task execution kernel, ensuring the overall stability of the system. This design not only improves the reliability and stability of the system but also ensures seamless switching of monitoring tasks in the event of kernel failure, further enhancing the maintainability and scalability of the system.

[0682] In another embodiment, a BMC optimization method for an AI server further includes:

[0683] After the first kernel completes booting, it sends boot completion information to the second kernel;

[0684] During the boot process of the second kernel, the boot status of the first kernel is read.

[0685] In this embodiment, after the first kernel completes boot and takes over the basic monitoring subsystem, it sends a boot completion message to the second kernel via a data interaction interface (such as shared SRAM). This message can be a simple status flag or a structure containing more details, such as boot time and hardware status. The purpose of sending this message is to notify the second kernel that the first kernel is ready and has taken over the basic monitoring tasks.

[0686] In this embodiment, during the startup process of the second kernel, it periodically checks the startup status in the shared SRAM to determine the tasks that the first kernel has started. The second kernel can actively avoid preempting resources of the basic monitoring subsystem during its own startup phase. For example, it does not initialize the I2C sensor interface and PWM timer peripheral that have been taken over by M33, thus avoiding speed erratic caused by the two kernels sending control signals to the fan at the same time, or data conflict caused by reading the sensor at the same time.

[0687] To facilitate understanding of the BMC optimization method for an AI server in this disclosure, the following is based on... Figure 5 An explanation of a BMC optimization method for an AI server:

[0688] Figure 5 This illustration shows a flowchart of a BMC optimization method for an AI server according to an embodiment of the present disclosure. Figure 4 ,like Figure 5 As shown, when AC (Alternating Current) is powered on, hardware initialization is performed first. Subsequently, the system will trigger the M33 kernel startup, dual-kernel parallel initialization, and A55 kernel startup processes respectively.

[0689] After the M33 kernel boots up, it takes over the basic monitoring subsystem. Upon completion, it enters real-time monitoring mode, performing tasks such as high-frequency sensor data acquisition, real-time fan and power supply control, and rapid response to anomaly alarms. After the A55 kernel boots up, it completes system initialization and performs tasks such as comprehensive complex monitoring, strategy optimization (e.g., selecting appropriate cooling algorithms), and user interaction (visual interactive interface Web / command line interface CLI). At this point, the dual-core collaborative phase begins. The M33 and A55 exchange data through a data interface. The M33 ensures the real-time performance of data acquisition and control, while the A55 handles complex logic and implements resource isolation to avoid conflicts. During operation, if the A55 detects a fatal error, it will directly trigger the protection mechanism; if the M33 fails, the A55 will take over core control and restart, thus ensuring system reliability.

[0690] like Figure 4 As shown, a BMC optimization system for an AI server includes:

[0691] The BMC chip includes an independent first core and a second core, with the boot time of the first core being shorter than that of the second core; the first core can be an M33 core and the second core can be an A55 core.

[0692] The BMC chip is used to control the startup of the first and second kernels in response to startup commands for the AI ​​server.

[0693] After startup, the first kernel takes over the basic monitoring subsystem of the AI ​​server, continuously collects the operating data of the fans and power supply in the AI ​​server, and controls the fans and power supply.

[0694] The second kernel is used to take over the global monitoring subsystem of the AI ​​server after startup, to perform global monitoring of the AI ​​server and optimize strategies based on the monitoring results; the first kernel and the second kernel exchange monitoring information through a data interaction interface; the data interaction interface is built on the basis of the internal bus so that the first kernel and the second kernel can share memory and send interrupt signals to each other.

[0695] If the target kernel detects an anomaly in another kernel while the first and second kernels are running in parallel, the target kernel will take over the monitoring task of the abnormal kernel.

[0696] In one possible implementation, the first core is connected to a first QSPI controller, and the second core is connected to a second QSPI controller;

[0697] The BMC chip is also used to detect the hardware status of the first core, the second core, the first QSPI controller, and the second QSPI controller, to determine the normal core among the first core and the second core; and to read the boot mode in the boot configuration register of the BMC chip and boot the normal core based on the boot mode.

[0698] In one embodiment, a first QSPI controller is connected to a first flash memory, which stores the RTOS firmware of a first kernel. The capacity of the first flash memory can be 521kb. A second QSPI controller is connected to a second flash memory, which stores the Linux firmware of a second kernel. The capacity of the second flash memory can be 128MB. The BMC chip is also used for:

[0699] In response to the boot mode being parallel boot mode, the first QSPI controller and the second QSPI controller are initialized simultaneously, and the RTOS firmware in the first flash memory and the Linux firmware in the second flash memory are loaded in parallel, so that the first kernel and the second kernel can boot in parallel.

[0700] If the boot mode is the priority boot mode, the first kernel will be booted first. After the first kernel takes over the basic monitoring subsystem, the second kernel will be triggered to boot through an internal interrupt.

[0701] If the boot mode is a single boot mode, then only one of the first kernel and the second kernel will be booted.

[0702] In one possible implementation, an upgrade partition is provided in the first flash memory.

[0703] The second kernel is also used to transfer the new RTOS firmware to the first flash memory of the first kernel;

[0704] The first kernel is also used to erase the upgrade partition and write the new RTOS firmware to the upgrade partition;

[0705] The first kernel is also used to read the new RTOS firmware from the upgrade partition and perform a reset and reboot based on the new RTOS firmware.

[0706] In one possible implementation, the second flash memory includes a primary root partition and a backup root partition.

[0707] The second kernel is also used to obtain the new Linux firmware and write the new Linux firmware to the backup root partition;

[0708] The second kernel is also used to switch the boot partition of the second kernel from the primary root partition to the backup root partition in response to successful verification for the new Linux firmware.

[0709] In one possible implementation, the basic monitoring subsystem running on the first kernel includes a hardware driver layer, a core service layer, and an application control layer. The first kernel is also used for:

[0710] Based on the hardware driver layer, the peripheral interface of the first kernel is adapted, and the operating data of the fan speed sensor and power parameter sensor are read through the communication bus interface, and the control signal is transmitted to the fan driver and power management module.

[0711] Based on the core service layer receiving the running data output by the hardware driver layer, the running data is processed by sliding filtering, CRC check and format standardization, and the processed running data is transmitted to the application control layer. At the same time, the control commands sent by the application control layer are forwarded to the hardware driver layer.

[0712] Based on the application control layer, data acquisition and control tasks are executed according to preset priorities. The data acquisition task obtains and stores the processed running data from the core service layer in the first cycle. The control task calculates the control quantity through the PID algorithm based on the processed running data and the strategy optimization parameters issued by the second kernel. The core service layer and the hardware driver layer adjust the fan speed and power status based on the control quantity.

[0713] In one possible implementation, the data interaction interface is obtained based on the shared SRAM of the first and second kernels in the second kernel.

[0714] The first kernel is also used to synchronize monitoring data to the shared SRAM in a second cycle;

[0715] The second kernel is also used to send an access request to the first kernel via a specified interrupt channel when it needs to access shared SRAM.

[0716] The first kernel is also used to release control of the shared SRAM after completing the current operation and send an interrupt notification to the second kernel;

[0717] The second kernel is also used to complete accesses to the shared SRAM and send interrupt notifications to the first kernel.

[0718] In one possible implementation, the second kernel is further configured to:

[0719] When the second kernel detects an anomaly in the target task in the first kernel through the task status area of ​​the data interaction interface, it sets a status flag to identify the target task that needs to be taken over, and sends a task takeover notification through the command buffer of the data interaction interface.

[0720] The second kernel acquires control of the shared peripherals corresponding to the target task and takes over the target task.

[0721] Once the first kernel detects that the target task has recovered from the failure, the second kernel clears the status flags, releases control of the shared peripherals, and the first kernel takes over the target task again.

[0722] In one embodiment, the first kernel is further configured to send boot completion information to the second kernel after booting; the second kernel is further configured to read the boot status of the first kernel during the boot process.

[0723] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0724] Figure 7 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0725] like Figure 7 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0726] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0727] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as a BMC optimization method for an AI server. For example, in some embodiments, a BMC optimization method for an AI server can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the BMC optimization method for an AI server described above can be performed. Alternatively, in other embodiments, computing unit 801 may be configured by any other suitable means (e.g., by means of firmware) to perform a BMC optimization method for an AI server.

[0728] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0729] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0730] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0731] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0732] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0733] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0734] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0735] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise explicitly specified.

[0736] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A BMC optimization method of an AI server, the method comprising: The application relates to a BMC optimization system applied to an AI server, wherein a BMC chip of the AI server comprises a first kernel and a second kernel which are independent of each other, the starting time of the first kernel is less than that of the second kernel, and the method comprises the following steps: In response to a starting instruction for the AI server, the first kernel and the second kernel are started, after the first kernel is started, the first kernel takes over a basic monitoring subsystem of the AI server, continuously collects running data of fans and power supplies in the AI server, and controls the fans and the power supplies; After the second kernel is started, the second kernel takes over a global monitoring subsystem of the AI server, globally monitors the AI server, and optimizes a strategy based on a monitoring result; the first kernel and the second kernel exchange monitoring information through a data interaction interface; During parallel operation of the first kernel and the second kernel, if a target kernel detects that another kernel is abnormal, the target kernel takes over a monitoring task of the abnormal kernel; The first kernel is connected with a first QSPI controller, and the second kernel is connected with a second QSPI controller; starting of the first kernel and the second kernel comprises the following steps: A hardware state of the first kernel, the second kernel, the first QSPI controller and the second QSPI controller is detected, and a normal kernel in the first kernel and the second kernel is determined; A starting mode in a starting configuration register of the BMC chip is read, and the normal kernel is started based on the starting mode.

2. The method of claim 1, wherein, The first QSPI controller is connected with a first flash memory, the first flash memory is used for storing RTOS firmware of the first kernel, the second QSPI controller is connected with a second flash memory, and the second flash memory is used for storing Linux firmware of the second kernel; The starting of the normal kernel based on the starting mode comprises the following steps: In response to the starting mode being a parallel starting mode, the first QSPI controller and the second QSPI controller are simultaneously initialized, and the RTOS firmware in the first flash memory and the Linux firmware in the second flash memory are loaded in parallel, so that the first kernel and the second kernel are started in parallel; In response to the starting mode being a priority starting mode, the first kernel is started preferentially, and after the first kernel takes over the basic monitoring subsystem, the second kernel is started through an internal interrupt; In response to the starting mode being a single starting mode, only one of the first kernel and the second kernel is started.

3. The method of claim 2, wherein, The first flash memory is provided with an upgrade partition, and the method further comprises the following steps: The second kernel transmits new RTOS firmware to the first flash memory of the first kernel; The first kernel erases the upgrade partition and writes the new RTOS firmware into the upgrade partition; The first kernel reads the new RTOS firmware from the upgrade partition, and resets and restarts based on the new RTOS firmware.

4. The method of claim 2, wherein, The second flash memory comprises a main root partition and a backup root partition, and the method further comprises the following steps: The second kernel obtains new Linux firmware, and writes the new Linux firmware into the backup root partition; In response to a verification pass for the new Linux firmware, switching the boot partition of the second kernel from the primary root partition to the secondary root partition.

5. The method of claim 1, wherein, The base monitoring subsystem in which the first kernel runs includes a hardware driver layer, a core service layer, and an application control layer, and the continuous collection of operation data of fans and power supplies in the AI server and the control of the fans and power supplies include: The peripheral interface of the first kernel is adapted based on the hardware driver layer, operation data of a fan speed sensor and a power supply parameter sensor are read through a communication bus interface, and control signals are transmitted to a fan driver and a power management module; Based on the core service layer, the operation data output by the hardware driver layer is received, the operation data is subjected to sliding filtering, CRC checking, and format standardization processing, and the processed operation data is transmitted to the application control layer, and control instructions sent by the application control layer are forwarded to the hardware driver layer; Based on the application control layer, collection tasks and control tasks are executed according to a preset priority, the collection tasks acquire the processed operation data from the core service layer at a first period and store the processed operation data, the control tasks calculate a control amount through a PID algorithm based on the processed operation data and policy optimization parameters issued by the second kernel, and the core service layer and the hardware driver layer adjust fan speed regulation and power supply states based on the control amount.

6. The method of claim 1, wherein, The data interaction interface is obtained based on a shared SRAM of the first kernel and the second kernel in the second kernel, the first kernel and the second kernel exchange monitoring information through the data interaction interface, and the data interaction interface includes: The first kernel synchronizes monitoring data in the shared SRAM at a second period; When the second kernel needs to access the shared SRAM, an access request is initiated to the first kernel through a specified interrupt channel, the first kernel releases the control right of the shared SRAM after completing a current operation, and sends an interrupt notification to the second kernel, and the second kernel sends an interrupt notification to the first kernel after completing the access to the shared SRAM.

7. The method of claim 1, wherein, When the target task in the first kernel is detected to be abnormal by the second kernel through a task state area of the data interaction interface, a state flag bit is set to identify the target task that needs to be taken over, and a task takeover notification is sent through a command buffer area of the data interaction interface; The second kernel acquires the control right of a shared peripheral corresponding to the target task, and takes over the target task; When the target task of the first kernel is detected to be recovered, the second kernel clears the state flag bit, releases the control right of the shared peripheral, and re-takes over the target task by the first kernel. The method further includes:

8. The method of claim 1, wherein, After the first kernel completes the startup, startup completion information is sent to the second kernel; During the startup process of the second kernel, the startup state of the first kernel is read. The system includes: 9.A BMC optimization system of an AI server, characterized in that, ​ A BMC chip, wherein a first core and a second core are independent of each other, and a starting time of the first core is less than a starting time of the second core; The BMC chip is configured to control the first core and the second core to start in response to a starting instruction for the AI server; The first core is configured to take over a basic monitoring subsystem of the AI server after starting, continuously collect running data of a fan and a power supply in the AI server, and control the fan and the power supply; The second core is configured to take over a global monitoring subsystem of the AI server after starting, globally monitor the AI server, and optimize a strategy based on a monitoring result; and the first core and the second core exchange monitoring information through a data interaction interface; In a parallel running process of the first core and the second core, if a target core detects that another core is abnormal, the target core takes over a monitoring task of the abnormal core; The first core is connected with a first QSPI controller, and the second core is connected with a second QSPI controller; The BMC chip is further configured to detect hardware states of the first core, the second core, the first QSPI controller, and the second QSPI controller, determine a normal core in the first core and the second core, read a starting mode in a starting configuration register of the BMC chip, and start the normal core based on the starting mode.

10. The system of claim 9, wherein, The first QSPI controller is connected with a first flash memory, the first flash memory is configured to store an RTOS firmware of the first core, the second QSPI controller is connected with a second flash memory, the second flash memory is configured to store a Linux firmware of the second core, and the BMC chip is further configured to: In response to the starting mode being a parallel starting mode, the first QSPI controller and the second QSPI controller are simultaneously initialized, and the RTOS firmware in the first flash memory and the Linux firmware in the second flash memory are loaded in parallel, so that the first core and the second core are started in parallel; In response to the starting mode being a priority starting mode, the first core is started preferentially, and after the first core takes over the basic monitoring subsystem, the second core is started through an internal interrupt; In response to the starting mode being a single starting mode, only one of the first core and the second core is started.

11. The system of claim 10, wherein, An upgrade partition is arranged in the first flash memory, The second core is further configured to transmit a new RTOS firmware to the first flash memory of the first core; The first core is further configured to erase the upgrade partition and write the new RTOS firmware into the upgrade partition; The first core is further configured to read the new RTOS firmware from the upgrade partition, and reset and restart based on the new RTOS firmware.

12. The system of claim 10, wherein, The second flash memory includes a main root partition and a backup root partition, The second core is further configured to obtain a new Linux firmware, and write the new Linux firmware into the backup root partition; The second core is further configured to switch a starting partition of the second core from the main root partition to the backup root partition in response to verification of the new Linux firmware being passed.

13. The system of claim 9, wherein, The first kernel runs a basic monitoring subsystem including a hardware driver layer, a core service layer and an application control layer, and is further configured to: adapt a peripheral interface of the first kernel based on the hardware driver layer, read running data of a fan speed sensor and a power parameter sensor through a communication bus interface, and transmit a control signal to a fan driver and a power management module; receive the running data output by the hardware driver layer based on the core service layer, perform sliding filtering, CRC checking and format standardization processing on the running data, and transmit the processed running data to the application control layer, and forward a control instruction sent by the application control layer to the hardware driver layer; perform a collection task and a control task according to a preset priority based on the application control layer, the collection task acquires the processed running data from the core service layer at a first period and stores the processed running data, the control task calculates a control amount through a PID algorithm based on the processed running data and a policy optimization parameter issued by the second kernel, and the core service layer and the hardware driver layer adjust fan speed regulation and power state based on the control amount.

14. The system of claim 9, wherein, The data interaction interface is obtained based on a shared SRAM of the first kernel and the second kernel in the second kernel, The first kernel is further configured to synchronize monitoring data in the shared SRAM at a second period; The second kernel is further configured to initiate an access request to the first kernel through a specified interrupt channel when the second kernel needs to access the shared SRAM; The first kernel is further configured to release the control right of the shared SRAM after completing a current operation, and send an interrupt notification to the second kernel; The second kernel is further configured to complete access to the shared SRAM, and send an interrupt notification to the first kernel.

15. The system of claim 9, wherein, The second kernel is further configured to: set a state marker bit to identify the target task to be taken over when the second kernel detects an abnormal target task in the first kernel through a task state area of the data interaction interface, and send a task takeover notification through a command buffer of the data interaction interface; acquire the control right of a shared peripheral corresponding to the target task, and take over the target task; when detecting that the target task of the first kernel recovers, the second kernel clears the state marker bit, releases the control right of the shared peripheral, and re-takes over the target task by the first kernel.

16. The system of claim 9, wherein the first kernel is further configured to send start completion information to the second kernel after completing starting; the second kernel is further configured to read a starting state of the first kernel during a starting process.

17. An electronic device, comprising: comprise: at least one processor; and a memory in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

18. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method of any one of claims 1-8. The computer instructions are used to enable the computer to perform the method of any one of claims 1-8.

Images