BMC (Baseboard Management Controller) coprocessing method and device, electronic equipment and storage medium

Abstract

The invention provides a BMC co-processing method and device, electronic equipment and a storage medium, and is applied to the technical field of computers, the method is applied to a BMC based on a multi-core heterogeneous chip, and the multi-core heterogeneous chip comprises a first processor core and a second processor core; the method comprises the steps that in the process that a first processor core executes a target task, a second processor core monitors the state of the first processor core in real time through a multi-stage detection method; if the second processor core determines that the first processor core is changed from the first state to the second state, the second processor core executes a first firmware refreshing operation and takes over part of target tasks of the first processor core; after the first processor core restores to the first state, the first processor core continues to execute the target task. Therefore, the hung processor cores can be detected in time through the plurality of processor cores in the multi-core heterogeneous architecture, and firmware refreshing is automatically performed on the hung processor cores, so that the processor cores are automatically recovered.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a BMC collaborative processing method, apparatus, electronic device and storage medium. Background Technology

[0002] The Baseboard Management Controller (BMC) is a remote management controller for the server. The BMC enables server control, information monitoring, and other functions, serving as a platform for intuitively presenting server information. Server clients can access the server's BMC to obtain server information via web, ipmitool, SNMP tools, etc.

[0003] Currently, BMCs can adopt a multi-core heterogeneous architecture, which can include a main core (PSP) and a co-core (SSP). This architecture balances high-efficiency processing and real-time performance, making it suitable for hardware monitoring and management scenarios of data center servers. For example, the main core uses a quad-core Cortex-A35 AST2700, running OpenBMC (Linux system), and is responsible for complex management (such as web interaction, firmware upgrades, policy optimization, temperature control, etc.); the co-core uses a Cortex-M4F AST2700, running an RTOS (such as FreeRTOS), and is responsible for assisting the main core in allocating physical resources. However, in extreme scenarios such as BMC abnormal hangs or system crashes, the above architecture has significant drawbacks. Problem 1: Reliance on manual intervention: When the BMC hangs, maintenance personnel need to conduct on-site troubleshooting and manually refresh the firmware; automatic recovery is not possible. If a batch of servers malfunction, it can lead to monitoring interruption and heat dissipation failure, potentially causing hardware damage or service interruption. Problem 2: Low hang detection accuracy: Monitoring based solely on a single heartbeat signal is prone to misjudgment due to signal interference or partial service crashes. Accidentally triggering a firmware update increases the risk of system instability. Issue 3: Lack of monitoring continuity: During the period between main core anomaly and recovery, system-wide sensor monitoring and thermal control are interrupted. The server may crash due to overheating, power supply failures, or other issues. Summary of the Invention

[0004] This disclosure provides a collaborative processing method, apparatus, electronic device, and storage medium for BMC, to at least solve the above-mentioned technical problems existing in the prior art.

[0005] In a first aspect, embodiments of this disclosure provide a collaborative processing method for a BMC (Browser Control Center), the method being applied to a BMC based on a multi-core heterogeneous chip, the multi-core heterogeneous chip comprising: a first processor core and a second processor core; the method comprising:

[0006] During the execution of the target task by the first processor core, the second processor core uses a multi-level detection method to monitor the status of the first processor core in real time. If the second processor core determines that the first processor core changes from the first state to the second state, the second processor core performs a first firmware refresh operation and takes over part of the target tasks of the first processor core; wherein, the first firmware refresh operation is used to restore the first processor core from the second state to the first state, the first state indicating that the first processor core is operating normally, and the second state indicating that the first processor core cannot operate normally. After the first processor core returns to the first state, the first processor core continues to execute the target task; Wherein, the first processor core runs a Linux system and the second processor core runs a real-time operating system; If the first processor core runs a real-time operating system, and the second processor core runs a Linux system.

[0007] Secondly, embodiments of this disclosure provide a collaborative processing device for a BMC (Browser Control Center), the device being applied to a BMC based on a multi-core heterogeneous chip, the multi-core heterogeneous chip comprising: a first processor core and a second processor core; the device comprising: The first processor core is used to execute the target task; The second processor core is used to monitor the state of the first processor core in real time using a multi-level detection method during the execution of the target task by the first processor core; if it is determined that the first processor core changes from the first state to the second state, a first firmware refresh operation is performed, and the first firmware refresh operation is taken over part of the target task of the first processor core; wherein, the first firmware refresh operation is used to restore the first processor core from the second state to the first state, the first state indicating that the first processor core is running normally, and the second state indicating that the first processor core cannot run normally. The first processor core is also configured to continue executing the target task after the first processor core returns to the first state; Wherein, the first processor core runs a Linux system and the second processor core runs a real-time operating system; If the first processor core runs a real-time operating system, and the second processor core runs a Linux system.

[0008] Thirdly, embodiments of this disclosure provide an electronic device for an on-chip network, comprising: At least one processor; and a memory communicatively connected to said at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the BMC's cooperative processing method.

[0009] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the cooperative processing method of the BMC.

[0010] This disclosure provides a collaborative processing method, apparatus, electronic device, and storage medium for a Block Design Controller (BMC). The method is applied to a BMC based on a multi-core heterogeneous chip, the multi-core heterogeneous chip including a first processor core and a second processor core. The method includes: during the execution of a target task by the first processor core, the second processor core monitors the state of the first processor core in real time using a multi-level detection method; if the second processor core determines that the first processor core changes from a first state to a second state, the second processor core performs a first firmware update operation and takes over part of the target task of the first processor core; wherein, the first firmware update operation is used to restore the first processor core from the second state to the first state, the first state indicating that the first processor core is operating normally, and the second state indicating that the first processor core cannot operate normally; after the first processor core is restored to the first state, the first processor core continues to execute the target task; wherein, if the first processor core runs a Linux system, the second processor core runs a real-time operating system; or if the first processor core runs a real-time operating system, the second processor core runs a Linux system. In this way, multiple processor cores in a multi-core heterogeneous architecture can detect dead processor cores in a timely manner and automatically update the firmware of dead processor cores to restore them; the normal operating processor cores take over the tasks of dead processor cores (especially when the main core takes over the co-core), avoiding the problem of missing monitoring continuity, thereby improving the stability of BMC; the multi-level detection method can determine the occurrence of processor core deadness in a timely and accurate manner, solving the problem of misjudgment from a single dimension.

[0011] 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

[0012] Figure 1 A flowchart illustrating a collaborative processing method for BMC provided in this embodiment of the disclosure; Figure 2 A flowchart illustrating a method for recovering the main core using a co-core, as provided in an embodiment of this disclosure; Figure 3 A schematic diagram of the structure of a BMC collaborative processing device provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

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

[0014] Figure 1 This is a flowchart illustrating a collaborative processing method for BMC provided in an embodiment of this disclosure, as shown below. Figure 1 As shown, the method is applied to a multi-core heterogeneous chip, which includes a first processor core and a second processor core; the method includes: Step 101: During the execution of the target task by the first processor core, the second processor core uses a multi-level detection method to monitor the status of the first processor core in real time; Step 102: If the second processor core determines that the first processor core changes from the first state to the second state, the second processor core performs the first firmware refresh operation and takes over part of the target tasks of the first processor core. The first firmware refresh operation is used to restore the first processor core from the second state to the first state, where the first state indicates that the first processor core is running normally, and the second state indicates that the first processor core cannot run normally. Step 103: After the first processor core returns to the first state, the first processor core continues to execute the target task; Wherein, if the first processor core runs a Linux system, the second processor core runs a real-time operating system; or if the first processor core runs a real-time operating system, the second processor core runs a Linux system.

[0015] Here, if the first processor core runs a Linux system and the second processor core runs a real-time operating system, it means that the first processor core is the main core (PSP) of the BMC and the second processor core is the co-core (SSP) of the BMC.

[0016] If the first processor core runs a real-time operating system and the second processor core runs a Linux system, it indicates that the first processor core is a co-core of BMC and the second processor core is the main core of BMC.

[0017] When a BMC employs a multi-core heterogeneous chip architecture, the main core can be composed of a high-performance processor (such as the Cortex-A series), running OpenBMC (such as a Linux system). It can be used to perform primary tasks, including: interacting with users, providing a web interface and API to manage various server functions; performing tasks such as firmware upgrades, configuration management, and policy optimization; handling system status monitoring and logging to facilitate troubleshooting and maintenance; and real-time response monitoring (e.g., handling sensor data acquisition, fan control, and interrupt handling).

[0018] A co-core can be composed of a low-power real-time processor (such as the Cortex-M series) running a real-time operating system (RTOS), such as FreeRTOS. It can be used to perform secondary tasks, such as assisting the main core in allocating physical resources, or performing other tasks assigned by the main core.

[0019] Here, the first state is the normal operating state, and the second state is the inability to operate normally, i.e., the hanged state, such as the system being unresponsive or the entire system stopping operation and unable to perform any operations.

[0020] When the first processor core executes the target task, it means that the first processor core is in a normal state. During this process, the second processor core continuously observes the operation of the first processor core in order to detect in a timely manner that the state of the first processor core changes from the normal operation state to the suspended state. When the second processor core detects that the state of the first processor core has changed (i.e., suspended), it immediately and automatically completes the firmware refresh operation and system restart without manual intervention. By reloading or refreshing the firmware, the first processor core is restored to the normal state. After the first processor core is successfully restored to the normal state, it continues to execute the previous management tasks.

[0021] It should be noted that when the first processor core performs status monitoring on the second processor core, the second processor core simultaneously performs status monitoring on the first processor core. That is, the two processor cores can detect whether the other is working properly, so that if the other hangs, a firmware update can be performed to restore the other to normal operation.

[0022] Thus, the collaborative processing method provided in this disclosure, through real-time monitoring and rapid recovery mechanisms, ensures timely recovery when problems occur, thereby improving the RAS (Reliability, Availability, and Serviceability), overall stability, and efficiency of the entire BMC system.

[0023] In some embodiments, the second processor core uses a multi-level detection method to monitor the state of the first processor core in real time, including: The first state detection is performed based on a software-level detection method to obtain the first detection result; If the first detection result is an abnormal state, then the second state detection is performed according to the process-level detection method to obtain the second detection result; If the second detection result is an abnormal state, then a second firmware refresh operation is performed; the second firmware refresh operation is used to restore the first processor core from the second state to the first state; If the second firmware flashing operation fails, a third state detection is performed according to the hardware-level detection method to obtain a third detection result. If the third detection result is an abnormal state, the state of the first processor core is determined to be the second state.

[0024] To avoid misjudgments caused by signal interference or partial service crashes due to a single monitoring method (such as monitoring only through a single heartbeat signal), a multi-level linkage monitoring method is provided to accurately determine whether the first processor core is stuck.

[0025] Here, the multi-level monitoring method includes: software-level detection method, hardware-level detection method, and hardware-level detection method.

[0026] The multi-level detection method can use a two-out-of-three judgment logic. If the first two detection methods both consider the state to be abnormal, a firmware refresh (i.e., the second firmware refresh operation) can be performed through command interaction. If the second firmware refresh operation fails, the third state detection is performed. If the third detection result is that the state is abnormal, the state of the first processor core is determined to be the second state.

[0027] Here, considering that some state anomalies in a software system may be accidental or transient, such as a brief period of high load or resource contention, a single detection result may show an anomaly, but this does not necessarily indicate a persistent fault state. Therefore, the first state detection can be performed N times, where N is greater than or equal to 1, for example, 3 times. Accordingly, the first state detection is performed based on a software-level detection method to obtain the first detection result, including: If the first state detection is performed N times based on the software-level detection method, and all the first state detection results obtained in N times are abnormal, then the second state detection is further performed based on the process-level detection method.

[0028] In this way, by performing multiple first-state checks, the accuracy of the processor core status can be greatly improved, reducing the possibility of false alarms and false negatives.

[0029] In some embodiments, the first state detection based on the software-level detection method includes: The second processor core calls the second heartbeat process every second time interval to read the heartbeat packet in the shared SRAM, and performs time verification and data integrity verification based on the read heartbeat packet to obtain the first verification result; the heartbeat packet is the heartbeat packet generated by the first processor core calling the first heartbeat process every first time interval, and the heartbeat packet is written to the shared SRAM by the first processor core when running in the first state.

[0030] Here, when the second processor core reads the heartbeat packet from the shared SRAM, it can simultaneously write its own status information. Correspondingly, when the first processor core writes the heartbeat packet to the shared SRAM, it can simultaneously read the status information of the second processor core. In this way, the status detection between the first processor core and the second processor core is realized, that is, the main core and the co-core can detect each other's status.

[0031] In one example, the first and second durations of the heartbeat interaction can be designed based on actual needs.

[0032] For example, the first processor core is the main core, which can call the first heartbeat process (such as psp_send_heartbeat()) every 100ms (i.e., an example of the first duration) to generate a heartbeat packet and write it to the shared SRAM; the second processor core is the co-core, which can call the second heartbeat process (such as ssp_check_heartbeat()) every 50ms (i.e., an example of the second duration) to read the shared SRAM and verify it.

[0033] Here is a code example: bool ssp_check_heartbeat(void) { PspHeartbeat_t hb; memcpy(&hb, (void )0x000000, sizeof(hb)); / / Read from shared SRAM / / Verify timestamp (difference from SSP local time ≤ 500ms) if (abs(hb.timestamp - ssp_get_timestamp())>500) return false; / / Verify SHA256 uint8_t calc_sha

[32] ; sha256_calc((uint8_t )&hb.timestamp, 6, calc_sha); / / Hardware Crypto acceleration if (memcmp(calc_sha, hb.sha256, 32) != 0) return false; return true; } Using this code example, during the first state check, the basic system activity of the first processor core can be confirmed by the validity of the timestamp and the SHA256 check. If it fails three times in a row (a total of 300ms), it will proceed to the next level of check, namely the second state check.

[0034] Here, the heartbeat packet exchange format between the first processor core and the second processor core can be set based on actual needs, and it can include timestamps, status information, etc. The heartbeat packet can be stored in the heartbeat exchange area of ​​shared SRAM (e.g., 0x000000-0x007FFF). In one example, a possible data exchange format is provided as follows: typedef struct { uint32_t timestamp; / / Timestamp (ms, since system startup) uint16_t proc_status; / / Process status code (bit0: dbus, bit1: ipmid, 1 = normal) uint8_t sha256

[32] ; / / SHA256 checksum of the first 6 bytes (to prevent tampering) PSP Heartbeat_t; Where uint32_t timestamp is an unsigned 32-bit integer representing a timestamp; `uint16_t proc_status` is an unsigned 16-bit integer representing the process status code. This status code uses bit fields to indicate different process states. Bit 0 indicates the dbus status, bit 1 indicates the ipmid status, and 1 indicates normal operation. For example, if both bit 0 and bit 1 are 1, it means that both the dbus and ipmid processes are in a normal state.

[0035] uint8_t sha256

[32] is an unsigned 8-bit integer array with a length of 32; it represents the storage of the first 6 bytes of the SHA256 checksum, used to prevent data tampering. SHA256 is a cryptographic hash function that ensures that data is not modified during transmission.

[0036] Specifically, here is an example: timestamp=162000000 (represents the time elapsed since system startup, in milliseconds), proc_status=0x03 (represents 00000011, i.e., bit0 and bit1 are both 1, indicating that both dbus and ipmid processes are in normal status), sha256=xxx (represents filling in a specific SHA256 hash value).

[0037] In some embodiments, performing the second state detection according to the process-level detection method includes: The second processor core accesses the target register address of the first processor core via the Advanced High Performance Bus (AHB) to read the status information and determines the second verification result based on the status information; the status information is written to the target register by the key process of the first processor core when it is running in the first state.

[0038] Here, AHB is a bus protocol used to connect multiple processors, peripherals, and memory. A second processor core can access the registers of the first processor core through AHB.

[0039] Here, the second processor core can access the first processor core's OpenBMC virtual file system ( / proc) mapped register addresses (e.g., 0x40000000-0x4000000F) via AHB. During runtime, certain critical processes on the first processor core (such as dbus) can write their process status to specific register addresses, and the second processor core can obtain this status information by accessing the mapped addresses (i.e., the mapped register addresses). Thus, process-level status detection can determine the status of the first processor core, thereby deciding whether to take action (e.g., restart a crashed process or issue an alert).

[0040] In one example, a code example is provided: bool check_psp_processes(void) { / / Read the dbus process status register (0x40000000) uint8_t dbus_status = read_reg(0x40000000); / / Read the ipmid process status register (0x40000001) uint8_t ipmid_status = read_reg(0x40000001); / / 0x01 = Running, 0xFF = Crashed, 0x00 = Not running return (dbus_status == 0x01)&&(ipmid_status == 0x01); } In this example, check_psp_processes is a function used to access two critical processes (dbus and ipmid) of the first processor core. By detecting the status of the two critical processes, the status of the first processor core is determined.

[0041] The status values ​​are defined as follows: 0x01 indicates that the process is running; 0xFF indicates that the process has crashed; and 0x00 indicates that the process is not running.

[0042] By determining whether the states of the two critical processes are both 0x01 (i.e., both are running), if so, they are considered to be in the first state (normal state); otherwise, they are considered to be in an abnormal state.

[0043] In some embodiments, performing the third state detection according to the hardware-level detection method includes: The second processor core monitors the voltage of the first GPIO pin and determines the third verification result based on the monitored voltage value. The first GPIO pin is controlled by the first processor core when it is running in the first state to output the voltage value.

[0044] Here, the first GPIO pin can be a specific pin of a first processor core. For example, suppose the first GPIO pin is GPIO10. This pin outputs 3.3V when the first processor core is running normally (for example, it can be controlled by a driver in Linux, such as the driver / dev / watchdog), and is automatically pulled low when a crash occurs. Correspondingly, the second processor core monitors the voltage of the GPIO10 pin and can determine whether the status is correct.

[0045] One example demonstrates how a second processor core monitors via GPIO interrupts: void gpio_irq_handler(void) { if (gpio_read(GPIO10) == 0) { / / Pull the level low hardware_fault_flag = 1; } } In this example, when the level of the GPIO10 pin changes (from high to low), an interrupt handler is triggered. By checking the state of GPIO10, if its level is found to be pulled low, it indicates a potential hardware fault. In this case, hardware_fault_flag is set to 1 so that other parts of the code can detect this fault state and take appropriate measures.

[0046] In some embodiments, the second firmware flashing operation can be a command-based firmware flashing method. The second firmware flashing operation includes: The second processor core writes a refresh request to the shared SRAM and triggers an interrupt on the first processor core; If the first processor core responds to the refresh request, it writes an authorization command to the shared SRAM, and the second processor core performs the first firmware refresh operation based on the authorization command. If the first processor core does not respond to the refresh request, a third state detection is performed according to the hardware-level detection method.

[0047] Here, the shared SRAM can have multiple partitions, such as: heartbeat packet partition, command packet partition, and check data partition; the command packet partition can be used to transmit refresh requests, as well as authorization commands to respond to refresh requests.

[0048] In one example, when the second processor core initiates a refresh request to the first processor core, it can fill SysCmd_t (cmd_code=0x01) and write it to the shared SRAM (specifically, to the command packet partition), simultaneously triggering an interrupt on the first processor core (triggered via the AHB interrupt line). If only critical processes on the first processor core are malfunctioning at this time, it can still respond to the refresh request and can write an authorization command (e.g., cmd_code=0x02, param = time window). The second processor core can then read the firmware based on the authorization command and perform the refresh. If the first processor core cannot respond, the second firmware refresh fails, and a third state check can be used to determine whether the first processor core is completely hanged.

[0049] In another example, a format example of a command packet (such as a refresh request or authorization command) is provided. The command packet can be bidirectional (i.e., both the first and second processor cores can send and read it), and the command packet is stored in a command buffer (assumed to be 0x010000-0x017FFF) in shared SRAM.

[0050] The following example uses the first processor core as the main core and the second processor core as the co-core. Its format can be as follows: typedef struct { uint8_t cmd_code; / / Command code (0x01 = co-core request refresh, 0x02 = main core authorization) uint8_t target; / / Target (0x00 = main core, 0x01 = co-core, 0x02 = CPLD) uint32_t param; / / Parameter (e.g., image version number) uint8_t crc8; / / CRC8 checksum (first 7 bytes) SysCmd_t.

[0051] In some embodiments, the second processor core performs a first firmware flashing operation, including: The second processor core performs a two-factor authentication operation; after the two-factor authentication is passed, the firmware stored in the embedded memory (EMMC, Embedded Multi Media Card) is checked for firmware integrity. If the check is passed, the first processor core is refreshed based on the firmware. The two-factor validation operation includes: The second processor core reads the pre-programmed first key from the One-Time Programmable (OTP), encrypts it through the encryption algorithm engine (RSA Engine), and compares it with the second key in the security register of the first processor core. If the first key and the second key match successfully, the first verification is confirmed to be successful. The second processor core detects the duration between the start time of the first processor core entering the second state and the end time of the firmware refresh operation, and determines whether the duration exceeds a duration threshold. If the duration does not exceed the duration threshold, the second verification is determined to be successful.

[0052] Here, considering the insufficient security of firmware updates in related technologies—namely, the lack of hardware-level isolation and authentication mechanisms, the risk of image tampering and permission abuse, and the absence of data protection measures—and the potential for image corruption or even malicious attacks during the firmware update process, a two-factor authentication operation is proposed. Firmware updates can only proceed if both the first and second authentications pass, thus addressing the aforementioned security deficiencies.

[0053] Here, the EMMC can be partitioned using a partitioning strategy, and it has a firmware storage area, an emergency image area, and a log area. The firmware storage area stores the firmware of the first processor core and the firmware of the second processor core.

[0054] The encryption algorithm engine can be: RSA Engine, which uses an asymmetric encryption algorithm; or ECC Engine, which uses another asymmetric encryption algorithm.

[0055] The second processor core can independently access the EMMC through its own SPI interface and compare the first key, which is pre-programmed in the OTP (One-Time Programmable Memory), with the second key in the first processor core's security register.

[0056] Here, the firmware flashing process can specifically include: During the firmware update process, a block check (e.g., 64KB) method is used to verify the data transmission or integrity of each data block in the firmware; the verification method can be cyclic redundancy check (e.g., CRC32 check). Record operation logs and save them to the OTP non-erasable area.

[0057] The operation log can include key operations and status information throughout the refresh process, such as the write status of each data block and verification results. Writing the operation log to the OTP (Optical Point Adapter) allows for traceability and prevents mirror tampering and unauthorized operations, as the OTP storage cannot be modified after programming.

[0058] In one example, the first processor core is the primary core, and the second processor core is the secondary core, such as... Figure 2 As shown, if the co-core detection determines that the main core is hanging, then firmware flashing is selected. For example, if the main core image is selected, the backup image can be used first for firmware flashing. If the backup image flashing fails, the emergency image can be selected for firmware flashing. Before flashing the image, two-factor authentication is required (i.e., the first verification passes and the second verification passes). If authentication fails, a log is recorded and an alarm is triggered; if authentication succeeds, the SPI (Serial Peripheral Interface) control is switched. The switching of control can be achieved through pin control. For example, by setting the GPIO20 pin to a high level, the PSP's flash memory is locked to prevent accidental modification during the flashing process.

[0059] When reading the image from the EMMC, the firmware can be read in blocks (e.g., 64KB / block, verified using CRC32). The read firmware is written to the main core's Flash and verified to ensure the data is correct. If the verification fails, the current block is rolled back and rewritten. If the verification succeeds, it is determined whether all data blocks have been written. If so, the boot configuration register of the main core is modified (prioritizing the main partition). Finally, SPI control is released (e.g., by setting GPIO20 low). The refresh log is recorded in the OTP for subsequent auditing and troubleshooting.

[0060] In some embodiments, if the first processor core runs a Linux system and the second processor core runs a real-time operating system, taking over the target task of the first processor core includes: The second processor core activates the peripheral permissions of the APB to take over the monitoring functions executed by the first processor core; The method further includes: The first processor core is started using a fast start mode. After the first processor core recovers from the second state to the first state, a ready command is sent to the second processor core. The second processor core responds to the ready command by releasing APB peripheral permissions, and the first processor core resumes control of its target task.

[0061] Here, the first processor core runs a Linux system, and the second processor core runs a real-time operating system, indicating that the first processor core is the main core and the second processor core is a co-core. The second processor core (i.e., the co-core) can quickly (within 10ms) activate the peripheral permissions of the APB after the first processor core (i.e., the main core) hangs, to take over the basic monitoring functions (i.e., some target tasks) executed by the first processor core. For example, it can periodically collect sensor data (CPU / GPU temperature, fan speed) according to a first cycle (e.g., 50ms), and periodically execute fan PID control according to a second cycle (e.g., 10ms).

[0062] When the main core recovers, unnecessary services can be skipped through fast startup mode (only core modules are loaded), which can generally achieve readiness within 10 seconds. The status list is sent to the co-core through shared SRAM, and control is seamlessly transferred after the co-core verifies the status.

[0063] Here, to explain the above takeover and retakeover process in detail, an example is provided. Assume that the first processor core is the main core and the second processor core is the co-core. If the co-core detects that the main core is hanging, the co-core will perform a firmware update on the main core.

[0064] After the co-core completes the firmware update of the main core, it triggers a cold reset of the main core via a fixed general-purpose input / output pin (such as GPIO30), effectively rebooting the main core. During main core startup, it checks for a recovery flag at a specific address in the shared SRAM, indicating the state the main core has recovered to. The main core enters fast boot mode (loading only the core module, not all functional modules); once startup is complete, it sends a ready command to the co-core (e.g., writing the ready command to a specific address in the shared SRAM, such as cmd_code-0x04); the co-core verifies the main core's state (using the aforementioned software-level and process-level detection methods); if the main core's state is detected as normal, the co-core disables APB peripheral permissions (e.g., by writing 0x0000 to the permission register), and releases permissions for the SPI controller, then enters monitoring mode to continue monitoring the main core's state; the main core rewrites and takes over its full functionality, executing its own target tasks.

[0065] In some embodiments, if the first firmware flashing operation fails multiple times, the method further includes: The second processor core automatically switches to the EMMC emergency image area and performs a firmware refresh operation again by reading the backup firmware in the EMMC emergency image area.

[0066] Here, an emergency strategy is provided that if multiple failures occur during the firmware flashing process, it can automatically switch to a safe backup firmware area (EMMC emergency image area) to flash using the backup firmware.

[0067] Here, another emergency strategy is also provided, which is implemented by a hardware button. When the user presses the hardware button, the system can be forced into emergency boot mode, directly enabling the co-core to switch to the emergency image area, so that basic functions can still be restored in the event of a serious system failure.

[0068] In one example, if the main core still fails to boot after three consecutive refreshes, the co-core automatically switches to the EMMC emergency image area, refreshes the main core's firmware, and sends an alarm to notify relevant personnel. Example code is as follows: if (refresh_fail_cnt>= 3) { LOG_ERROR("PSP refresh failed 3 times, use emergency image"); / / Read emergency image emmc_read(EMERGENCY, EMERGENCY_SIZE, emergency_buf); refresh_ PSP_firmware(emergency_buf, EMERGENCY_SIZE); / / Trigger an alarm (send an SNMP trap via the network port) snmp_trap_send(TRAP_PSP_EMERGENCY); } In some embodiments, if both the first processor core and the second processor core are in the second state, the method further includes: In response to a recovery request from the onboard hardware recovery button, the second processor core loads an emergency program from the OTP and executes the emergency program.

[0069] Here, the emergency procedure (or emergency start procedure) is a recovery mechanism used to enable basic functional recovery or troubleshooting when the main operating system or main application fails to start or run normally.

[0070] To address the simultaneous failure of both core and dual-system systems, an onboard hardware recovery button (independent of the BMC) is provided. When this button is pressed, it triggers the co-core to load an emergency program from a specified OTP address (e.g., 0x60000000). Example code is as follows: / / Hardware button interrupt handling void recovery_btn_irq_handler(void) { / / Read emergency startup program from OTP uint8_t bootloader

[1024] ; otp_read(0x60000000, 1024, bootloader); ((void( )())bootloader)(); / / Perform emergency boot } Specifically, 1024 bytes of data are read from the specified OTP address (here, 0x60000000) and stored in the bootloader buffer; the bootloader buffer is then cast to a function pointer type and immediately invoked. This process runs the read emergency program as an executable function.

[0071] In some embodiments, if the second processor core runs a real-time operating system, the method further includes: The second processor core detects the status of at least one of the following devices in the BMC: motherboard CPLD (Complex Programmable Logic Device), backplane CPLD, and BIOS (Basic Input / Output System). If the device fails, the second processor core automatically updates the firmware of the failed device.

[0072] Here, considering that the existing solutions only address the BMC's own firmware and do not cover the monitoring and recovery of the entire system's firmware such as CPLD and BIOS, they cannot handle server failures caused by abnormalities in the entire system's firmware. Therefore, a method for detecting and troubleshooting the status of the motherboard CPLD, backplane CPLD, BIOS, etc., is proposed.

[0073] Specifically, the firmware partition of the EMMC can also store firmware for the motherboard CPLD, backplane CPLD, BIOS, etc., to support version verification and batch flashing of the entire machine's firmware. The firmware status of the entire machine can be monitored by the second processor core (i.e., the co-core). If a fault is detected in a certain part, backup firmware is written through the I2C interface to achieve full-scenario recovery of the entire machine's firmware failure.

[0074] In some embodiments, the second processor core runs a real-time operating system, and the method further includes at least one of the following: After the second processor core takes over the target task of the first processor core, the second processor core reduces its operating frequency from a first frequency to a second frequency; the first frequency is higher than the second frequency. After the first processor core takes over its target task again, the second processor core increases its operating frequency from the second frequency to the first frequency.

[0075] The method described here can be applied to fields such as data centers and edge computing, and is adaptable to edge scenarios such as 5G base stations, smart transportation, and industrial IoT. Considering that if the main core is suspended, the co-core may be overloaded if it handles multiple tasks, a method is proposed to automatically switch to power-saving mode when the co-core takes over, in order to balance performance and energy consumption. For example, the main frequency is reduced from 400MHz to 200MHz, and unnecessary peripherals are turned off, which can reduce the overall power consumption of the BMC by 40%. After the main core recovers, the frequency of the co-core can be increased back from 200MHz to 400MHz.

[0076] In some embodiments, the method further includes: The first processor core and / or the second processor core detect the status of the operating system (OS) of the first processor core and / or the status of the operating system of the second processor core through the IPMI protocol or a custom interface; If any of the operating systems becomes abnormal, the abnormal operating system will be restarted by the processor core in normal condition via out-of-band management. If the operating system hangs, the normal processor core will use the operating system image backed up in the EMMC to refresh the image of the abnormal operating system.

[0077] Here, system status can include: whether it responds to ping, and whether critical services are running.

[0078] The BMC (including the main core and co-cores) can monitor the OS status (such as whether it responds to ping and whether critical services are running) through the IPMI protocol or a custom interface. If an OS hangs, the BMC (composed of the remaining normal processor cores) can first attempt to restart the OS through out-of-band management. If the restart fails, the BMC (composed of the remaining normal processor cores) can further check the integrity of the OS image. If the hang is caused by OS image corruption, the BMC (composed of the remaining normal processor cores) will automatically refresh the OS image, which can be stored in the EMMC in advance.

[0079] In this way, by combining the IPMI protocol, monitoring mechanisms, fault recovery strategies, and version compatibility checks, the high availability and stability of the server system can be ensured.

[0080] In some embodiments, the multi-core heterogeneous chip belongs to a first device, and if the second processor core runs a real-time operating system, the method further includes: The second processor core of the first device receives status information from the second processor core of the second device. Based on the status information, when it is determined that the first processor core of the second device is hanged and the second processor core is faulty, the firmware backed up in the EMMC of the first device is called and the image is written to the Flash of the second device remotely through a collaborative network, board-level connection or direct connection, and the second device is triggered to recover. The second device is a BMC that has a communication connection with the first device.

[0081] Here, the method can be applied to server clusters, and it breaks through the limitation of independent recovery of a single server, realizing cross-node collaboration of BMCs of multiple servers in the cluster. When the BMC of one server fails, the monitoring and recovery can be taken over by the BMCs of other servers in the cluster.

[0082] For servers within the cluster, a BMC collaborative network can be established via network ports, allowing BMCs to share their respective status (normal / abnormal) and firmware (i.e., image files). For example, when the main core of BMC1 hangs and its co-core fails, the co-core of BMC2 detects the abnormality through the collaborative network, board-level connection, or direct connection, and then remotely writes firmware (i.e., writes image files) to the Flash of BMC1, triggering recovery.

[0083] Each BMC can select and configure its own supported backup BMC nodes. It can choose one or more backup BMC nodes. Of course, multiple BMC nodes can also adopt a distributed mode, with multiple BMC nodes taking turns to be on standby.

[0084] Figure 3 This is a schematic diagram of the structure of a BMC collaborative processing device provided in an embodiment of this disclosure; as shown below. Figure 3 As shown, the device is applied to a BMC based on a multi-core heterogeneous chip, the multi-core heterogeneous chip including: a first processor core and a second processor core; the device includes: The first processor core is used to execute the target task; The second processor core is used to monitor the state of the first processor core in real time using a multi-level detection method during the execution of the target task by the first processor core; if it is determined that the first processor core changes from the first state to the second state, a first firmware refresh operation is performed, and the first firmware refresh operation is taken over part of the target task of the first processor core; wherein, the first firmware refresh operation is used to restore the first processor core from the second state to the first state, the first state indicating that the first processor core is running normally, and the second state indicating that the first processor core cannot run normally. The first processor core is also configured to continue executing the target task after the first processor core returns to the first state; Wherein, the first processor core runs a Linux system and the second processor core runs a real-time operating system; If the first processor core runs a real-time operating system, and the second processor core runs a Linux system.

[0085] In some embodiments, the second processor core is used to perform a first state detection based on a software-level detection method to obtain a first detection result; If the first detection result is an abnormal state, then the second state detection is performed according to the process-level detection method to obtain the second detection result; If the second detection result is an abnormal state, then a second firmware refresh operation is performed; the second firmware refresh operation is used to restore the first processor core from the second state to the first state; If the second firmware flashing operation fails, a third state detection is performed according to the hardware-level detection method to obtain a third detection result. If the third detection result is an abnormal state, the state of the first processor core is determined to be the second state.

[0086] In some embodiments, the second processor core is configured to call the second heartbeat process every second time interval to read the heartbeat packet in the shared SRAM, and perform time verification and data integrity verification based on the read heartbeat packet to obtain a first verification result; the heartbeat packet is a heartbeat packet generated by the first processor core calling the first heartbeat process every first time interval, and the heartbeat packet is written to the shared SRAM by the first processor core when running in the first state. The second processor core is used to access the target register address of the first processor core via AHB to read status information and determine a second verification result based on the status information; the status information is written to the target register by a key process of the first processor core when it is running in the first state.

[0087] In some embodiments, the second processor core is used to monitor the voltage of the first GPIO pin and determine a third verification result based on the monitored voltage value. The first GPIO pin is controlled by the first processor core to output a voltage value when the first processor core is running in the first state.

[0088] In some embodiments, the second processor core is configured to write a refresh request to the shared SRAM and trigger an interrupt from the first processor core; If the refresh request is responded to, the first processor core is used to write an authorization command to the shared SRAM, and the second processor core is also used to perform a first firmware refresh operation based on the authorization command; If the refresh request is not responded to, the first processor core is used to perform a third state detection according to a hardware-level detection method.

[0089] In some embodiments, the second processor core is used to perform a two-factor authentication operation; after the two-factor authentication is passed, the firmware stored in the EMMC is checked for firmware integrity; if the check is passed, the first processor core is refreshed based on the firmware. The two-factor validation operation includes: The second processor core reads the pre-programmed first key from the one-time programmable device (OTP), encrypts it through the encryption algorithm engine, and compares it with the second key in the security register of the first processor core. If the first key and the second key match successfully, the first verification is confirmed to be successful. The second processor core detects the duration between the start time of the first processor core entering the second state and the end time of the firmware refresh operation, and determines whether the duration exceeds a duration threshold. If the duration does not exceed the duration threshold, the second verification is determined to be successful.

[0090] In some embodiments, if the first processor core runs a Linux system and the second processor core runs a real-time operating system, the second processor core is used to activate the peripheral permissions of the APB to take over the monitoring functions executed by the first processor core. The first processor core is also configured to start in a fast startup mode and send a ready command to the second processor core after the first processor core recovers from the second state to the first state. The second processor core is also configured to release APB peripheral permissions in response to the ready command, and the first processor core is also configured to take over its own target task again.

[0091] In some embodiments, if the first firmware refresh operation fails multiple times, the second processor core is further configured to automatically switch to the EMMC emergency image area and perform the firmware refresh operation again by reading the backup firmware in the EMMC emergency image area.

[0092] In some embodiments, if both the first processor core and the second processor core are in the second state, the second processor core is further configured to load an emergency program from the OTP and execute the emergency program in response to a recovery request from the onboard hardware recovery button.

[0093] In some embodiments, if the second processor core runs a real-time operating system, the second processor core is also used to execute at least one of the following: After the second processor core takes over the target task of the first processor core, the operating frequency is reduced from the first frequency to the second frequency; the first frequency is higher than the second frequency. After the first processor core takes over its target task again, the operating frequency is increased from the second frequency to the first frequency.

[0094] In some embodiments, the first processor core and / or the second processor core are further configured to detect the state of the operating system of the first processor core and / or the state of the operating system of the second processor core via the IPMI protocol or a custom interface; If any of the operating systems becomes abnormal, the abnormal operating system will be restarted by the processor core in normal condition via out-of-band management. If the operating system hangs, the normal processor core will use the operating system image backed up in the EMMC to refresh the image of the abnormal operating system.

[0095] In some embodiments, the multi-core heterogeneous chip belongs to the first device. If the second processor core runs a real-time operating system, the second processor core of the first device receives status information from the second processor core of the second device. Based on the status information, when it is determined that the first processor core of the second device is hanged and the second processor core is faulty, the backup firmware in the EMMC of the first device is called and the firmware is written to the Flash of the second device remotely through a collaborative network, board-level connection or direct connection, and the second device is triggered to recover. The second device is a BMC that has a communication connection with the first device.

[0096] It is understood that the BMC collaborative processing device provided in the above embodiments, when implementing the corresponding BMC collaborative processing method, can allocate the above processing to different program modules as needed to complete all or part of the processing described above. Furthermore, the device and the corresponding method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0097] This disclosure provides a computer-readable storage medium storing executable instructions, wherein the executable instructions are executed by a processor, which triggers the processor to execute the BMC cooperative processing method provided in this disclosure.

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

[0099] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure; as shown below. Figure 4 As shown, the electronic device 40 includes: a processor 401 and a memory 402 communicatively connected to the processor 401; the memory 402 stores instructions that can be executed by the processor 401; the instructions are executed by the processor 401 to enable the processor 401 to execute the BMC cooperative processing method.

[0100] Of course, the electronic devices and corresponding method embodiments provided in the above embodiments belong to the same concept. The processor 401 can also execute the BMC cooperative processing method of any of the above embodiments. For details of its implementation process, please refer to the method embodiments, which will not be repeated here.

[0101] In practical applications, the electronic device 40 may further include at least one network interface 403. The various components of the electronic device 40 are coupled together via a bus system 404. It is understood that the bus system 404 is used to implement communication between these components. In addition to a data bus, the bus system 404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 4 All buses are labeled as bus system 404. The number of processors 401 can be at least one, and the number of memories 402 can be at least one. Network interface 403 is used for wired or wireless communication between electronic device 40 and other devices.

[0102] The memory 402 in this embodiment is used to store various types of data to support the operation of the electronic device 40.

[0103] The methods disclosed in the above embodiments of this disclosure can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 401 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 402. Processor 401 reads the information in memory 402 and combines its hardware to complete the steps of the aforementioned method.

[0104] In some embodiments, the electronic device 40 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned methods.

[0105] 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 disclosed in this disclosure can be achieved, and this is not limited herein.

[0106] In the above description, the term "some embodiments" refers to a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0107] Unless otherwise defined, all technical and scientific terms used in this disclosure have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used in this disclosure is for the purpose of describing embodiments of this disclosure only and is not intended to be limiting of this disclosure.

[0108] It should be understood that in the various embodiments of this disclosure, the sequence number of each implementation process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure.

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

[0110] 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 collaborative processing method for BMC, characterized in that, The method is applied to a BMC based on a multi-core heterogeneous chip, wherein the multi-core heterogeneous chip includes: a first processor core and a second processor core; the method includes: During the execution of the target task by the first processor core, the second processor core uses a multi-level detection method to monitor the status of the first processor core in real time. If the second processor core determines that the first processor core changes from the first state to the second state, the second processor core performs a first firmware refresh operation and takes over part of the target tasks of the first processor core; wherein, the first firmware refresh operation is used to restore the first processor core from the second state to the first state, the first state indicating that the first processor core is operating normally, and the second state indicating that the first processor core cannot operate normally. After the first processor core returns to the first state, the first processor core continues to execute the target task; Wherein, if the first processor core runs a Linux system, the second processor core runs a real-time operating system; or if the first processor core runs a real-time operating system, the second processor core runs a Linux system.

2. The method according to claim 1, characterized in that, The second processor core uses a multi-level detection method to monitor the status of the first processor core in real time, including: The first state detection is performed based on a software-level detection method to obtain the first detection result; If the first detection result is an abnormal state, then the second state detection is performed according to the process-level detection method to obtain the second detection result; If the second detection result is an abnormal state, then a second firmware refresh operation is performed; the second firmware refresh operation is used to restore the first processor core from the second state to the first state; If the second firmware flashing operation fails, a third state detection is performed according to the hardware-level detection method to obtain a third detection result. If the third detection result is an abnormal state, the state of the first processor core is determined to be the second state.

3. The method according to claim 2, characterized in that, The first state detection based on the software-level detection method includes: The second processor core calls the second heartbeat process every second time interval to read the heartbeat packet in the shared static random access memory (SRAM), and performs time verification and data integrity verification based on the read heartbeat packet to obtain the first verification result; the heartbeat packet is the heartbeat packet generated by the first processor core calling the first heartbeat process every first time interval, and the heartbeat packet is written to the shared SRAM by the first processor core when running in the first state. The second state detection according to the process-level detection method includes: The second processor core accesses the target register address of the first processor core via the Advanced High-Performance Bus (AHB) to read status information and determines the second verification result based on the status information; the status information is written to the target register by the key process of the first processor core when it is running in the first state.

4. The method according to claim 2, characterized in that, The third-state detection based on the hardware-level detection method includes: The second processor core monitors the voltage of the first GPIO pin and determines the third verification result based on the monitored voltage value. The first GPIO pin is controlled by the first processor core when it is running in the first state to output the voltage value.

5. The method according to claim 2, characterized in that, The second firmware flashing operation includes: The second processor core writes a refresh request to the shared SRAM and triggers an interrupt on the first processor core; If the first processor core responds to the refresh request, it writes an authorization command to the shared SRAM, and the second processor core performs the first firmware refresh operation based on the authorization command. If the first processor core does not respond to the refresh request, a third state detection is performed according to the hardware-level detection method.

6. The method according to claim 1, characterized in that, The second processor core performs the first firmware update operation, including: The second processor core performs a two-factor authentication operation; after the two-factor authentication is passed, the firmware stored in the embedded memory EMMC is checked for firmware integrity; if the check is passed, the first processor core is refreshed based on the firmware. The two-factor validation operation includes: The second processor core reads the pre-programmed first key from the one-time programmable device (OTP), encrypts it through the encryption algorithm engine, and compares it with the second key in the security register of the first processor core. If the first key and the second key match successfully, the first verification is confirmed to be successful. The second processor core detects the duration between the start time of the first processor core entering the second state and the end time of the firmware refresh operation, and determines whether the duration exceeds a duration threshold. If the duration does not exceed the duration threshold, the second verification is determined to be successful.

7. The method according to claim 1, characterized in that, If the first processor core runs a Linux system and the second processor core runs a real-time operating system, the second processor core takes over the target tasks of the first processor core, including: The second processor core activates the peripheral permissions of the APB to take over the monitoring functions executed by the first processor core; The method further includes: The first processor core is started using a fast start mode. After the first processor core recovers from the second state to the first state, a ready command is sent to the second processor core. The second processor core responds to the ready command by releasing APB peripheral permissions, and the first processor core resumes control of its target task.

8. The method according to claim 1, characterized in that, If the first firmware flashing operation fails multiple times, the method further includes: The second processor core automatically switches to the EMMC emergency image area and performs a firmware refresh operation again by reading the backup firmware in the EMMC emergency image area.

9. The method according to claim 1 or 8, characterized in that, If both the first processor core and the second processor core are in the second state, the method further includes: In response to a recovery request from the onboard hardware recovery button, the second processor core loads an emergency program from the OTP and executes the emergency program.

10. The method according to claim 1, characterized in that, If the second processor core is running a real-time operating system, the method further includes at least one of the following: After the second processor core takes over the target task of the first processor core, the second processor core reduces its operating frequency from a first frequency to a second frequency; the first frequency is higher than the second frequency. After the first processor core takes over its target task again, the second processor core increases its operating frequency from the second frequency to the first frequency.

11. The method according to claim 1, characterized in that, The method further includes: The first processor core and / or the second processor core detect the operating system status of the first processor core and / or the operating system status of the second processor core through the IPMI protocol or a custom interface; If any of the operating systems becomes abnormal, the abnormal operating system will be restarted by the processor core in normal condition via out-of-band management. If the operating system hangs, the normal processor core will use the operating system image backed up in the EMMC to refresh the image of the abnormal operating system.

12. The method according to claim 1, characterized in that, The multi-core heterogeneous chip belongs to the first device. If the second processor core runs a real-time operating system, the method further includes: The second processor core of the first device receives status information from the second processor core of the second device. Based on the status information, when it is determined that the first processor core of the second device is hanged and the second processor core is faulty, the backup firmware in the EMMC of the first device is invoked and the firmware is written to the Flash of the second device remotely through a collaborative network, board-level connection or direct connection, and the second device is triggered to recover. The second device is a BMC that has a communication connection with the first device.

13. A collaborative processing device for BMC, characterized in that, The device is applied to a BMC based on a multi-core heterogeneous chip, wherein the multi-core heterogeneous chip includes: a first processor core and a second processor core; the device includes: The first processor core is used to execute the target task; The second processor core is used to monitor the state of the first processor core in real time using a multi-level detection method during the execution of the target task by the first processor core; if it is determined that the first processor core changes from the first state to the second state, a first firmware refresh operation is performed, and the first firmware refresh operation is taken over part of the target task of the first processor core; wherein, the first firmware refresh operation is used to restore the first processor core from the second state to the first state, the first state indicating that the first processor core is running normally, and the second state indicating that the first processor core cannot run normally. The first processor core is also configured to continue executing the target task after the first processor core returns to the first state; Wherein, the first processor core runs a Linux system and the second processor core runs a real-time operating system; If the first processor core runs a real-time operating system, and the second processor core runs a Linux system.

14. An electronic device, characterized in that, include: At least one processor; And, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 12.

15. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 12.

Images