Server startup fault maintenance method and system, storage medium and computer program product

Abstract

The invention discloses a server startup fault maintenance method and system, a storage medium and a computer program product, and relates to the technical field of servers, the method comprises the following steps: setting a backup system address request flag bit under the condition that a main basic input / output system of a server is interrupted by trigger software; the backup system address request flag bit is transmitted to a main control core, the main control core obtains backup system address information from a pre-stored backup system firmware program according to the backup system address request flag bit, and the backup system firmware program and a substrate management controller firmware program are stored in the same flash memory chip in a partition mode; reading backup system firmware resources pointed by the backup system address information; the backup system firmware resources are mapped to the control chip set, the control chip set reads the backup system firmware resources to conduct hardware initialization, and the server is guided to be started. Server startup failure maintenance which is highly reliable and is not affected by in-band server failures is achieved at low cost.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to server startup failure maintenance methods, systems, storage media, and computer program products. Background Technology

[0002] In server architecture, the BMC (Baseboard Management Controller) and BIOS (Basic Input Output System) work together to provide crucial support for server management and startup. If the BIOS program is corrupted or malfunctions, the server may fail to complete the power-on self-test (POST). Mainstream redundancy design solutions fall into two categories: one involves burning two BIOS firmware images into a Flash chip, with the controller switching to the backup image when the primary image fails to boot; the other uses an additional BIOS chip independent of the motherboard, achieving primary / backup switching via the SPI interface of the platform controller hub. The former cannot overcome the physical failure risk of the Flash device itself, and since both images share the same storage medium, a global failure of the Flash chip will completely disable the redundancy mechanism. The latter requires additional dedicated chips and supporting circuitry, leading to increased material costs, increased motherboard wiring complexity, and a higher risk of switching failures.

[0003] Therefore, how to achieve highly reliable server fault maintenance at low cost and unaffected by in-band server failures has become an urgent problem to be solved in this application.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a server startup failure maintenance method, which aims to solve the technical problem of how to achieve high reliability server failure maintenance at low cost and unaffected by in-band server failures.

[0006] To achieve the above objectives, this application proposes a server startup fault maintenance method, applied to the coprocessing core of a baseboard management controller chip, the method comprising:

[0007] Set the backup system address request flag when the server's primary input / output system is interrupted by a software interrupt.

[0008] The backup system address request flag is passed to the main control core of the baseboard management controller chip, so that the main control core can obtain the backup system address information from the pre-stored backup system firmware program according to the backup system address request flag. The backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner.

[0009] Receive the backup system address information returned by the main control core, and read the backup system firmware resources pointed to by the backup system address information;

[0010] The backup system firmware resources are mapped to the control chipset, so that the control chipset can read the backup system firmware resources to perform hardware initialization and boot the server.

[0011] In one embodiment, the step of setting the backup system address request flag under the condition that the server's primary input / output system is triggered by a software interrupt includes:

[0012] The monitoring status flag of the main basic input / output system in the server is read at preset time intervals, and the startup status of the main basic input / output system is determined based on the monitoring status flag.

[0013] When the startup state of the main basic input / output system is restart state and the number of restarts is less than the preset restart threshold, the restart event that triggers the restart of the main basic input / output system is recorded, and a system startup failure alarm is issued.

[0014] When the startup state of the primary basic input / output system is in restart state and the number of restarts is equal to the preset restart threshold, a software interrupt is triggered in the primary basic input / output system, a system error alarm is issued, and the backup system address request flag is set.

[0015] In one embodiment, the step of receiving the backup system address information returned by the main control core and reading the backup system firmware resources pointed to by the backup system address information includes:

[0016] Receive the backup system address information returned by the main control core in the form of shared memory, and verify the backup system address information with specific identification information;

[0017] If the specific identification information is verified, the backup system firmware resources stored in advance are completely read from the flash memory chip according to the backup system address information, and the double verification field is read from the flash memory chip.

[0018] In one embodiment, the step of mapping the backup system firmware resources to the control chipset includes:

[0019] The dual verification fields are used to perform cyclic redundancy verification and vertical redundancy verification on the backup system firmware resources;

[0020] Under the condition that the cyclic redundancy check and the longitudinal redundancy check pass, the backup system firmware resources are mapped to the control chipset.

[0021] In one embodiment, the step of mapping the backup system firmware resources to the control chipset further includes:

[0022] The backup system address information, the verification results of the cyclic redundancy check, and the verification results of the longitudinal redundancy check are logged.

[0023] Write the restart event of the primary basic input / output system and the call event of the backup system firmware resources to the system log.

[0024] Furthermore, to achieve the above objectives, this application also proposes a server startup fault maintenance method, applied to the main control core of a baseboard management controller chip, the method comprising:

[0025] The system receives a backup system address request flag from the coprocessor core of the baseboard management controller chip. The backup system address request flag is set by the coprocessor core when the server's main basic input / output system is triggered by a software interrupt.

[0026] Based on the backup system address request flag, the backup system address information is obtained from the pre-stored backup system firmware program, wherein the backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner.

[0027] The backup system address information is transmitted to the coprocessor core, so that the coprocessor core can read the backup system firmware resources pointed to by the backup system address information, map the backup system firmware resources to the control chipset, and the control chipset reads the backup system firmware resources to perform hardware initialization and boot the server.

[0028] In one embodiment, the step of obtaining backup system address information from a pre-stored backup system firmware program based on the backup system address request flag includes:

[0029] Poll the backup system address request flag bit to monitor changes in the backup system address request flag bit;

[0030] When the backup system address request flag is changed to a valid state, the end address of the baseboard management controller firmware program, the firmware start address of the backup system firmware program, and the check segment start address of the double check field are read from the flash memory chip.

[0031] The backup system address information is obtained based on the end address, the firmware start address, and the check segment start address.

[0032] Furthermore, to achieve the above objectives, this application also proposes a server startup fault maintenance system, which includes:

[0033] The baseboard management controller chip coprocessor core is used to set a backup system address request flag when the server's main basic input / output system is triggered by a software interrupt, pass the backup system address request flag to the main control core of the baseboard management controller chip, receive the backup system address information returned by the main control core, read the backup system firmware resources pointed to by the backup system address information, and map the backup system firmware resources to the control chipset.

[0034] The main control core of the baseboard management controller chip is used to obtain backup system address information from the pre-stored backup system firmware program according to the backup system address request flag bit;

[0035] Flash memory chip, used to pre-store the backup system firmware and the baseboard management controller firmware in a partitioned manner;

[0036] The control chipset is used to read the backup system firmware resources to perform hardware initialization and boot the server.

[0037] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the server startup fault maintenance method described above.

[0038] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the server startup fault maintenance method described above.

[0039] One or more technical solutions proposed in this application have at least the following technical effects:

[0040] When the server's main input / output system is triggered by a software interrupt, a backup system address request flag is set. This flag is then transmitted to the main control core of the baseboard management controller chip, allowing the main control core to retrieve backup system address information from a pre-stored backup system firmware program. The backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner. The system receives the backup system address information returned by the main control core and reads the backup system firmware resource pointed to by the address. This backup system firmware resource is mapped to the control chipset, allowing the control chipset to read it for hardware initialization and to boot the server. In this application, leveraging the out-of-band management advantages of the BMC, the backup system firmware program (i.e., the backup BIOS firmware program) and the BMC firmware program (baseboard management controller firmware program) are co-located in the same flash memory chip in a partitioned manner. This eliminates the impact of in-band server faults. Furthermore, since the BMC is an out-of-band management chip with extremely high stability, binding the backup BIOS firmware program to the BMC firmware program enhances the stability of the backup BIOS firmware program. Furthermore, the backup BIOS firmware and BMC firmware share a single flash memory chip, eliminating the need for an additional BIOS chip and significantly reducing material costs. Moreover, after detecting a BIOS boot failure and triggering a software interrupt, the BMC's internal coprocessor core first sets the backup system address request flag and transmits it to the main control core. The main control core then returns the backup system address information of the backup BIOS to the coprocessor core. The coprocessor core reads the backup system firmware resources according to this address information and directly maps them to the control chipset, thus bypassing the main CPU and in-band paths to complete hardware initialization and server operating system startup. The entire switching process is completed out-of-band by the BMC, independent of the server's main processor and in-band links, and therefore unaffected by in-band server failures. Utilizing the BMC's dual-core division of labor (the coprocessor core is dedicated to fault handling, while the main control core continues to perform daily management tasks), both normal BMC functionality and rapid, reliable BIOS fault recovery are achieved. In summary, this application utilizes the out-of-band management function of the BMC to store the backup system firmware and the baseboard management controller firmware in the same flash memory chip in a partitioned manner. Combined with the dual-core division of labor of the BMC: the coprocessor core is dedicated to fault handling, while the main control core continues to perform daily management tasks, so as to achieve high reliability and server startup fault maintenance that is unaffected by in-band server failures at low cost. Attached Figure Description

[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 A flowchart illustrating the first embodiment of the server startup fault maintenance method of this application;

[0044] Figure 2 This is a flowchart illustrating the fourth embodiment of the server startup fault maintenance method of this application.

[0045] Figure 3 This is a flowchart illustrating the fifth embodiment of the server startup fault maintenance method of this application.

[0046] Figure 4 This is a schematic diagram showing how the backup system firmware is stored in the flash memory chip.

[0047] Figure 5 A framework diagram of the server startup failure maintenance system designed in this application is provided;

[0048] Figure 6 The flowchart of the backup BIOS boot method provided in this application;

[0049] Figure 7 This is a schematic diagram of the module structure of the server startup fault maintenance device according to an embodiment of this application;

[0050] Figure 8 This is a schematic diagram of the hardware operating environment involved in the server startup failure maintenance method in this application embodiment.

[0051] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0052] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0053] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0054] The main solution of this application embodiment is as follows: When the main basic input / output system of the server is triggered by a software interrupt, the coprocessor core of the baseboard management controller chip sets a backup system address request flag; the backup system address request flag is transmitted to the main control core of the baseboard management controller chip, so that the main control core can obtain backup system address information from a pre-stored backup system firmware program based on the backup system address request flag, wherein the backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner; the main control core receives the backup system address information returned by the main control core and reads the backup system firmware resource pointed to by the backup system address information; the backup system firmware resource is mapped to the control chipset, so that the control chipset can read the backup system firmware resource for hardware initialization and booting the server.

[0055] This application's embodiments take into account that in modern server technology, the BMC and BIOS work together to provide crucial support for server management and startup. As an embedded microcontroller, the BMC has functions such as remote management and hardware monitoring, allowing administrators to access the server via the network and perform operations such as restarting and checking hardware status even before the operating system starts. The BIOS is responsible for hardware initialization during server startup, performing POST (Power-On Self-Test) to create conditions for operating system loading. Combined, the BMC can monitor the BIOS's execution status before system startup and obtain hardware information provided by the BIOS during the startup process, enabling comprehensive management and maintenance of the server. This is especially beneficial in data center and cloud computing environments, significantly improving server manageability and operational reliability. In the server architecture, the BIOS dominates the startup process, responsible for hardware initialization and operating system loading, laying the foundation for stable operation. The BMC assists with control, remote management, and hardware monitoring functions. In this design, if the BIOS experiences an in-band fault and cannot boot the system, the fault can only be recovered by manually re-flashing the BIOS program. During this time, the server cannot function normally, impacting product stability.

[0056] To address the issue of BIOS failure during server startup preventing the operating system from booting normally, mainstream redundancy design solutions propose two approaches: First, burning two BIOS firmware images into a Flash chip, with the controller switching to the backup image if the primary image fails to boot. Second, using an additional BIOS chip independent of the motherboard, with primary / backup switching achieved via the SPI interface of the platform controller hub. The former cannot overcome the physical failure risk of the Flash device itself, and since both images share the same storage medium, a global failure of the Flash chip would completely disable the redundancy mechanism. The latter requires additional dedicated chips and circuitry, increasing material costs, motherboard wiring complexity, and the likelihood of switching failures.

[0057] Therefore, this application provides a solution that is unaffected by in-band server failures, has high stability, does not require manual BIOS programming, and can restore the normal system startup process when the BIOS boot system fails and the system cannot work, ensuring that the server can work normally. This achieves high reliability and server startup failure maintenance that is unaffected by in-band server failures at low cost.

[0058] As can be seen from the above embodiments, this application utilizes the out-of-band management advantages of the BMC to place the backup system firmware program, i.e. the backup BIOS firmware program, and the BMC firmware program (baseboard management controller firmware program) in the same flash memory chip in a partitioned manner, thereby eliminating the impact of server in-band faults. Furthermore, since the BMC is an out-of-band management chip with extremely high stability, binding the backup BIOS firmware program with the BMC can enhance the stability of the backup BIOS firmware program. The backup BIOS firmware and BMC firmware share a single flash memory chip, eliminating the need for an additional BIOS chip and significantly reducing material costs. Furthermore, after detecting a BIOS boot failure and triggering a software interrupt, the BMC's internal coprocessor core first sets the "backup system address request flag" and sends it to the main control core. The main control core then returns the backup system address information of the backup BIOS to the coprocessor core. The coprocessor core reads the backup system firmware resources according to this address information and directly maps the backup firmware resources to the control chipset, thereby bypassing the main CPU and in-band paths to complete hardware initialization and system boot. The entire switching process is completed out-of-band by the BMC, without relying on the server's main processor and in-band links, and is therefore unaffected by in-band faults. At the same time, by utilizing the dual-core division of labor in the BMC (the coprocessor core is dedicated to fault handling, while the main control core continues to perform daily management tasks), normal BMC functions are maintained while achieving fast and reliable BIOS fault recovery. In summary, this application utilizes the out-of-band management function of the BMC to store the backup system firmware and the baseboard management controller firmware in the same flash memory chip in a partitioned manner. Combined with the dual-core division of labor of the BMC: the coprocessor core is dedicated to fault handling, while the main control core continues to perform daily management tasks, so as to achieve high reliability and BIOS system fault maintenance that is unaffected by in-band server failures at low cost.

[0059] Based on this, this application provides a server startup failure maintenance method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the server startup fault maintenance method of this application.

[0060] In this embodiment, the server startup fault maintenance method is applied to the coprocessor core of the baseboard management controller chip, and the server startup fault maintenance method includes steps S10 to S40:

[0061] Step S10: Under the condition that the server's main basic input / output system is triggered by a software interrupt, set the backup system address request flag.

[0062] The BMC chip refers to the Aspeed AST2600 chip, which integrates an ARM Cortex-A7 main control core (A7 core) and an ARM Cortex-M3 coprocessor (M3 core), responsible for complex management and real-time monitoring tasks, respectively. The main control core, the A7 core, is responsible for running the BMC main firmware and handling tasks such as remote management and firmware updates. The coprocessor core, the M3 core, focuses on real-time monitoring, hardware acceleration, and low-power tasks.

[0063] The server's primary basic input / output system (PBX) refers to the main BIOS used during server startup to perform hardware initialization, self-test, and boot the operating system. This is distinct from the backup BIOS. Software interrupts are interrupt mechanisms actively triggered by the M3 core upon detecting a startup anomaly in the main BIOS system, used to notify the system to enter the exception handling process. The backup system address request flag is a system status identifier set by the M3 core, used to request the address information of the backup PBX firmware from the A7 core. This flag is typically written to a shared memory area as a global variable for the A7 core to periodically poll and read.

[0064] Additionally, it should be noted that the purpose of setting the backup system address request flag is to establish a communication mechanism between the M3 core and the A7 core, ensuring a reliable switch to backup firmware when the main BIOS fails to boot. This mechanism avoids the problems of relying on external chips or manual intervention in traditional solutions, improving self-healing capabilities. In one possible implementation, the backup system address request flag can be a Boolean variable, with a value of 1 indicating that a request has been initiated and a value of 0 indicating that no request has been made. In another implementation, the backup system address request flag can also adopt a bitmap structure, compressing multiple status information into an integer variable to improve memory utilization.

[0065] For example, in one specific implementation, when the M3 core detects the watchdog timer timeout three times in a row (i.e., does not receive the watchdog signal), it determines that the main BIOS boot has failed. At this time, the M3 core writes the flag value 0x01 to the shared memory address, triggering the A7 core to recognize the request in the next polling cycle and prepare to return the backup system address information.

[0066] Step S20: The backup system address request flag is transmitted to the main control core of the baseboard management controller chip, so that the main control core can obtain the backup system address information from the pre-stored backup system firmware program according to the backup system address request flag. The backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner.

[0067] Backup system address information refers to metadata such as the starting address and length of the backup system firmware program in the flash memory chip. Partitioned storage means dividing the flash memory chip into multiple logical regions, where the first region stores the BMC firmware program, the second region is the end / start flag segment, the third region stores the backup basic input / output system firmware, and the fourth region is the checksum segment.

[0068] Additionally, it should be noted that this transmission process is implemented through a shared memory mechanism. After the M3 core writes the backup system address request flag to the shared memory, the A7 core checks the status of this flag periodically (e.g., every 50ms). Once a valid flag is detected, the A7 core reads the backup system address information from the flash memory chip. In one possible implementation, the address information is stored in the form of a structure, including the starting address, length, and checksum; in another implementation, it can also be stored using JSON serialization for easier expansion.

[0069] Step S30: Receive the backup system address information returned by the main control core, and read the backup system firmware resources pointed to by the backup system address information;

[0070] Receiving refers to the process by which the M3 core obtains the backup system address information from the A7 core through a shared memory mechanism. Backup system firmware resources refer to the binary data of the backup basic input / output system program firmware, which includes hardware initialization code, interrupt vector tables, and bootloaders. Reading refers to the M3 core retrieving this binary data from the backup system firmware program storage area of ​​the flash memory chip via SPI (Serial Peripheral Interface) and loading it into the memory buffer.

[0071] Additionally, it should be noted that the core of receiving the backup system address information returned by the main control core and reading the backup system firmware resources pointed to by the backup system address information is to ensure the integrity and correctness of the backup system firmware resources. After reading the data, the M3 core immediately performs double verification: first, it calculates the CRC32 value of the data (32-bit Cyclic Redundancy Check) and compares it with the pre-stored check value; second, it verifies byte-level consistency through the LRC (Longitudinal Redundancy Check) algorithm. If either verification fails, an error handling process is triggered (such as logging and retrying). In one possible implementation, data reading uses DMA to improve efficiency; in another implementation, a cache prefetch mechanism can also be used to reduce SPI access latency.

[0072] Step S40: Map the backup system firmware resources to the control chipset so that the control chipset can read the backup system firmware resources for hardware initialization and boot the server.

[0073] Mapping refers to the hardware remapping function of the USB OTG controller, which virtualizes the backup basic input / output system firmware resources into a USB storage device, enabling the control chipset to access the firmware via the USB interface. The control chipset refers to the core logic chipset on the server motherboard, responsible for coordinating communication between the CPU, memory, and peripherals, and executing the basic input / output system firmware to complete hardware initialization. Hardware initialization includes configuring and testing key components such as CPU registers, memory controllers, and PCIe devices.

[0074] Additionally, it should be noted that mapping the backup system firmware resources to the control chipset allows the chipset to read these resources for hardware initialization and server restart. This bypasses the faulty primary input / output system and directly completes the server startup process via the backup firmware. USB mapping technology enables the control chipset to recognize the backup firmware without additional hardware support, significantly reducing design complexity. In one possible implementation, the mapping process is achieved by configuring the descriptor table of the USB OTG controller, registering the memory buffer as a Mass Storage device; in another implementation, virtual bus technology can be used to simulate SPI interface behavior.

[0075] This embodiment provides a server startup failure maintenance method. By leveraging the out-of-band management advantages of the BMC, the backup system firmware program, i.e. the backup BIOS firmware program, and the BMC firmware program (baseboard management controller firmware program) are placed together on the same flash memory chip in a partitioned manner, eliminating the impact of server in-band failures. Furthermore, since the BMC is an out-of-band management chip with extremely high stability, binding the backup BIOS firmware program to the BMC can enhance the stability of the backup BIOS firmware program. The backup BIOS firmware and BMC firmware share a single flash memory chip, eliminating the need for an additional BIOS chip and significantly reducing material costs. Furthermore, after detecting a main BIOS boot failure and triggering a software interrupt, the BMC's internal coprocessor core first sets the "backup system address request flag" and sends it to the main control core. The main control core then returns the backup system address information of the backup BIOS to the coprocessor core. The coprocessor core reads the backup system firmware resources according to this address information and directly maps the backup firmware resources to the control chipset, thereby bypassing the main CPU and in-band paths to complete hardware initialization and system boot. The entire switching process is completed out-of-band by the BMC, without relying on the server's main processor and in-band links, and is therefore unaffected by in-band faults. At the same time, by utilizing the BMC's dual-core division of labor (the coprocessor core is dedicated to fault handling, while the main control core continues to perform daily management tasks), both the normal function of the BMC and fast and reliable BIOS fault recovery are achieved. In summary, this application utilizes the out-of-band management function of the BMC to store the backup system firmware and the baseboard management controller firmware in the same flash memory chip in a partitioned manner. Combined with the dual-core division of labor of the BMC: the coprocessor core is dedicated to fault handling, while the main control core continues to perform daily management tasks, so as to achieve high reliability and server startup fault maintenance that is unaffected by in-band server failures at low cost.

[0076] In one feasible implementation, step S10 may include steps S11 to S23:

[0077] Step S11: Read the monitoring status flag of the main basic input / output system in the server at preset time intervals, and determine the startup status of the main basic input / output system based on the monitoring status flag.

[0078] The preset time interval refers to the periodic detection period set by the coprocessor (i.e., the M3 core) of the baseboard management controller. This period operates with millisecond precision and is used to continuously monitor the real-time status of the server startup process. A typical value is 100 milliseconds. The monitoring status flag bit of the main basic input / output system refers to a hardware register bit maintained by the control chipset under the watchdog timer mechanism. This bit is used to reflect whether the main basic input / output system has completed the watchdog feeding operation within the specified time. If it has not been completed, the flag bit is set to 1, indicating a startup abnormality. "Startup status" is a comprehensive judgment result, including states such as "normal startup", "startup failed", and "rebooting", which are used in subsequent decision-making processes.

[0079] A periodic polling mechanism enables real-time monitoring of the main basic input / output system startup process, promptly detecting startup anomalies and triggering subsequent processing mechanisms. Polling is performed using the M3 core, independent of the server operating system or its in-band communication path, and is entirely handled independently by the baseboard management controller's coprocessor, ensuring high reliability. In one possible implementation, the monitoring status flag can be read via a specific register address on the LPC bus; in another implementation, it can also be directly accessed by the M3 core via shared memory mapping.

[0080] For example, in one specific implementation, the M3 core reads the watchdog status register every 100 milliseconds via the LPC bus. If bit 0 of the register is 1, the server is determined to have failed to start and needs to be restarted. Otherwise, it is determined to be starting normally.

[0081] Step S12: When the startup state of the main basic input / output system is the restart state and the number of restarts is less than the preset restart threshold, record the restart event that triggers the restart of the main basic input / output system and issue a system startup failure alarm.

[0082] It should be noted that, in this embodiment, the restart state refers to the state in which the primary basic input / output system is forcibly restarted by the control chipset due to startup failure. This state is determined by the M3 core by monitoring the status flag bit to be 1 multiple times consecutively. The restart count is a counter maintained by the M3 core, used to record the number of consecutive failures of the primary basic input / output system during startup. The preset restart threshold is a system configuration parameter, typically set to 3 times, used to determine whether to enter the backup switchover process.

[0083] A restart event refers to a complete startup failure and restart process, and its event information includes the failure timestamp, failure reason code, restart count, etc. A system startup failure alarm refers to an SNMPTrap or Redfish event sent to a remote management terminal via the IPMI protocol, used to notify maintenance personnel that the system is in an unstable state.

[0084] Additionally, it should be noted that this application proposes a three-tiered fault handling principle: initial fault restart → fault recording below the preset restart threshold → fault switching at the preset restart threshold. When the main basic input / output system is in a restart state and the number of restarts is less than the preset restart threshold, the restart event triggering the restart of the main basic input / output system is recorded, and a system startup failure alarm is issued. This early recording of abnormal behavior and issuance of alarms facilitates intervention by maintenance personnel to investigate problems and prevents the problem from escalating. The alarm information is written to the system event log, supporting subsequent auditing and fault tracing.

[0085] For example, in one specific implementation, when the M3 core detects that the main basic input / output system has failed twice in a row (i.e., the number of restarts = 2, which is less than the preset threshold 3), it will record a SEL event with the content "BIOS boot failed, number of restarts = 2, timestamp = 2025-07-24 10:15:32", and send an alarm to the remote management terminal through the IPMI channel.

[0086] Step S13: When the startup state of the main basic input / output system is restart state and the number of restarts is equal to the preset restart threshold, the software interrupt of the main basic input / output system is triggered, a system error alarm is issued, and the backup system address request flag is set.

[0087] Software interrupts are implemented via an interrupt flag in shared memory. A system error alarm indicates that the primary base I / O system cannot be recovered via reboot and that backup firmware must be enabled. The backup system address request is used to request the storage address information of the backup base I / O system firmware from the A7 core. This flag is passed via shared memory to ensure reliable communication between the two cores.

[0088] By employing a software interrupt mechanism, the problems of relying on external hardware or manual intervention in traditional solutions are avoided, enabling a fully automated fault recovery process. In one possible implementation, the software interrupt can be triggered by setting the value of shared memory address 0xFFFF0200 to 0xFF; in another implementation, asynchronous notification can also be achieved through a message queue mechanism.

[0089] For example, in one specific implementation, when the M3 core detects that the number of reboots is 3 (which is equal to the preset threshold), it immediately writes 0xFF to the shared memory address 0xFFFF0200 to trigger a software interrupt. At the same time, it records a high-priority SEL event "Main BIOS boot failed, enable backup firmware" and sends the event JSON to the remote management system through the Redfish interface. Subsequently, the M3 core sets the backup system address request flag to 0x01 and waits for the A7 core to respond.

[0090] Based on the first embodiment of this application, a second embodiment of this application is proposed. In the second embodiment of this application, content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter.

[0091] In this embodiment, step S30, which involves receiving the backup system address information returned by the main control core and reading the backup system firmware resources pointed to by the backup system address information, may include steps S31 to S32:

[0092] Step S31: Receive the backup system address information returned by the main control core in the form of shared memory, and verify the backup system address information with specific identification information;

[0093] Specific identification information verification refers to a data consistency check mechanism used to confirm that the obtained backup system address information does indeed point to a legitimate backup firmware area, rather than a misread or corrupted data segment.

[0094] The core purpose of verifying specific identification information is to prevent firmware loading failures or system crashes due to incorrect address information. The verification mechanism relies on specific identifiers pre-written in the flash memory chip. Only verified address information will be used for subsequent read operations; otherwise, an error log will be logged and the switching process will be aborted. In one possible implementation, the specific identification information can be a fixed-length magic number; in another implementation, structured header information can be used, including a version number, a length field, and a checksum.

[0095] Step S32: If the specific identification information is verified, the backup system firmware resources are fully read from the flash memory chip according to the backup system address information, and the double verification field is read from the flash memory chip.

[0096] The dual check field refers to two sets of check values ​​used to verify firmware integrity: CRC32 check value (32-bit cyclic redundancy check) and LRC check value (longitudinal redundancy check). Together, they form a redundancy check system to ensure that the data is not corrupted or tampered with during the reading process.

[0097] The core objective of fully reading the backup system firmware resources and retrieving the dual verification field from the flash memory chip is to securely load the backup firmware into memory while ensuring data integrity, preparing for subsequent mapping and booting. The reading process is initiated by the M3 coprocessor and can use DMA to continuously read a specified length of data from the flash memory chip, performing dual verification immediately after reading. If either verification fails, an error log is recorded and the switchover process is aborted to prevent booting the system with corrupted firmware.

[0098] In this embodiment, a two-level integrity assurance mechanism of specific identification information verification and dual verification is used to achieve reliable loading of the backup basic input / output system firmware, which together supports the server's highly reliable self-healing boot in the event of a main BIOS failure.

[0099] Based on the first and / or second embodiments of this application, a third embodiment of this application is proposed. In this third embodiment, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0100] In this embodiment, step S40, which maps the backup system firmware resources to the control chipset, may include steps S41 to S42:

[0101] Step S41: Use the dual verification field to perform cyclic redundancy check and vertical redundancy check on the backup system firmware resources;

[0102] The dual check field refers to a structured check data segment pre-written into the flash memory chip and located at the end of the backup system firmware program. Its content consists of two parts: the first part is the cyclic redundancy check value (CRC32 value), which is used to detect whether bit-level errors have occurred in the backup system firmware resources during storage or transmission; the second part is the longitudinal redundancy check value (LRC value), which is used to perform XOR accumulation check on each column of bytes, thereby providing integrity guarantee.

[0103] Cyclic Redundancy Check (CRC) is a hash algorithm based on polynomial division that can detect single-bit errors, double-bit errors, odd-bit errors, and all error patterns with a burst length of 32 bits or less. Vertical Redundancy Check (CR) is a simple vertical XOR check method that generates a single-byte check value by performing an XOR operation on the bytes corresponding to each column in the backup system firmware resources. This value is used to supplement specific error patterns that CRC32 cannot cover.

[0104] Additionally, it should be noted that this verification operation is performed independently by the M3 core. Its purpose is to ensure that the backup system firmware resources to be mapped and used for system boot remain intact and consistent at all times. The M3 core will only continue the subsequent mapping and boot process if both the CRC32 value and the LRC value match the expected values ​​in the double-checked field. If either check fails, the M3 core will immediately abort the switchover process and record a "check failure" event in the system event log and IPMI alarm log to prevent secondary failures caused by loading corrupted firmware. In one possible implementation, the LRC calculation can employ a byte-by-byte XOR followed by inversion to enhance the detection capability for all-zero errors.

[0105] Step S42: Under the condition that the cyclic redundancy check and the longitudinal redundancy check pass, the backup system firmware resources are mapped to the control chipset.

[0106] Cyclic Redundancy Check (CRC) passing means that the calculated CRC32 value is exactly the same as the pre-stored CRC32 value in the double check field, indicating that no bit-level errors have occurred in the backup system firmware resources. Longitudinal Redundancy Check (LRC) passing means that the calculated LRC value is exactly the same as the pre-stored LRC value in the double check field, indicating that no byte-level errors have occurred in the backup system firmware resources. Mapping to the control chipset refers to using the hardware remapping function of the USB OTG controller to present the backup system firmware resources to the control chipset as a USB mass storage device, enabling the control chipset to read the firmware content and complete the server boot as if accessing local SPI flash memory.

[0107] Additionally, it should be noted that mapping the backup system firmware resources to the control chipset requires both verifications to pass, ensuring that the mapped backup system firmware resources are reliable and complete. The mapping process is triggered by the M3 core and implemented by configuring the descriptor table of the USB OTG controller. The entire process requires no manual intervention or additional hardware switching.

[0108] In this embodiment, the rigid constraint of "mapping is only performed after all double checks pass" completely eliminates "starting with defects" caused by data corruption, bit flipping, or misreading, achieving zero-misjudgment loading. Since the verification and mapping are all completed by the BMC's internal M3 core, no manual programming or additional hardware switching is required, reducing costs and improving processing efficiency.

[0109] Based on the above embodiments of this application, a fourth embodiment of this application is proposed. In this fourth embodiment, content that is the same as or similar to that in the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0110] Based on this, please refer to Figure 2 , Figure 2 This is a schematic flowchart of the fourth embodiment proposed in this application, as shown below. Figure 2 As shown, after step S40 of mapping the backup system firmware resources to the control chipset, the method further includes:

[0111] Step S50: Log the backup system address information, the verification result of the cyclic redundancy check, and the verification result of the longitudinal redundancy check;

[0112] The result of Cyclic Redundancy Check (CRC) refers to the Boolean state (pass / fail) generated by comparing the calculated 32-bit CRC32 value with the pre-stored CRC32 value in the flash memory chip. The result of Longitudinal Redundancy Check (LRC) refers to the Boolean state (pass / fail) generated by comparing the calculated 8-bit LRC value with the pre-stored LRC value in the flash memory chip. Log recording refers to writing the above three types of information into the non-volatile event storage area of ​​the baseboard management controller in a standardized format, including the System Event Log (SEL) and the Intelligent Platform Management Interface Log (IPMI Event Log), for real-time querying and offline auditing by the remote management platform.

[0113] Additionally, it's important to note that the purpose of this log entry is to establish a complete traceability chain: key data at each step, from "discovering a primary basic input / output system failure" to "successfully loading backup firmware," is permanently stored, providing quantitative evidence for subsequent root cause analysis. In one possible implementation, log entries use a TLV (Type-Length-Value) format, where the Type field identifies the event category, the Length field describes the data length, and the Value field stores the raw hexadecimal data. In another implementation, a JSON format can be used for easier parsing by the Redfish interface.

[0114] Step S60: Write the restart event of the main basic input / output system and the call event of the backup system firmware resources into the system log.

[0115] The primary base input / output (PIO) system reboot event refers to the hardware reset triggered by the control chipset after detecting a PIO system boot failure. Its event log includes the reboot reason code, cumulative reboot count, and timestamp. The backup system firmware resource call event refers to the action taken by the M3 core after confirming successful dual verification, whereby it presents the backup PIO system firmware to the control chipset via USB OTG mapping and begins the boot process. Its event log includes the call time, firmware version number, and mapping result status. System logs are a broad concept, including both the SEL and IPMI logs of the baseboard management controller and the extended system event log (ESL) that can be queried via Redfish or a web interface, supporting long-term retention and centralized analysis.

[0116] Additionally, it should be noted that the purpose of writing restart and call events is to create a closed-loop record of "fault-response-recovery," enabling operations and maintenance personnel to view complete information such as "when restarted, why restarted, whether the backup firmware has been switched, and whether the switch was successful" in a single interface, without needing to compare logs across systems. In one possible implementation, events are pushed to a centralized log server in real time via Syslog over TLS.

[0117] In this embodiment, by writing the backup system address information, CRC32 verification results, LRC verification results, and main BIOS restart events and backup BIOS call events into the system log, a complete time chain and evidence chain from the occurrence of the fault, the verification pass, to the successful switchover is formed. This allows maintenance personnel to remotely and accurately locate "when it failed, how many times it failed, when it switched over, and whether the switchover was successful" without disassembling the machine. This reduces the traditional fault diagnosis process, which requires tens of minutes or even hours of on-site troubleshooting, to a second-level log retrieval, thereby improving the efficiency of server startup fault handling.

[0118] This application provides a server startup failure maintenance method, referring to... Figure 3 , Figure 3 This is a flowchart illustrating the fifth embodiment of the server startup fault maintenance method of this application.

[0119] In this embodiment, the server startup fault maintenance method is applied to the main control core of the baseboard management controller chip, and the server startup fault maintenance method includes steps A10 to A30:

[0120] Step A10: Receive the backup system address request flag bit transmitted by the coprocessor core of the baseboard management controller chip. The backup system address request flag bit is set by the coprocessor core when the server's main basic input / output system is triggered by a software interrupt.

[0121] The coprocessor core of the baseboard management controller chip refers to the ARM Cortex-M3 processor integrated within the AST2600 chip, which is dedicated to real-time task processing and low-latency interrupt response. The backup system address request flag is a status variable sent by the M3 core to the ARM Cortex-A7 main control core via a shared memory mechanism. It indicates that the server's main basic input / output system has repeatedly failed to boot and triggered a software interrupt, requesting the address information of the backup firmware. The server's main basic input / output system refers to the main BIOS firmware, which is responsible for completing power-on self-test and operating system boot. The software interrupt is an asynchronous notification signal actively generated by the ARM Cortex-M3 processor after detecting that the number of boot failures has reached a preset threshold. It is used to wake up the ARM Cortex-A7 main control core to enter the backup switching process.

[0122] Additionally, it should be noted that this receiving action is performed by the ARM Cortex-A7 main control core, i.e., the A7 core, through periodic polling of shared memory. The purpose is to establish a high-speed, reliable communication channel between the two cores, ensuring that main BIOS faults can be detected even from out-of-band management paths, thus avoiding information silos caused by in-band path failures. In one possible implementation, the backup system address request flag is stored as a 32-bit unsigned integer variable; in another implementation, a message queue or Mailbox register can be used to implement interrupt-driven notifications to reduce polling overhead.

[0123] Step A20: Obtain backup system address information from the pre-stored backup system firmware program according to the backup system address request flag bit, wherein the backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner.

[0124] The backup system firmware refers to a second basic input / output system firmware with the same function as the main BIOS but used for redundancy recovery. It is pre-programmed in binary form into the third partition of the flash memory chip. Partitioning refers to logically dividing the flash memory chip into four consecutive areas: the first area stores the baseboard management controller firmware, the second area is the identification segment, the third area stores the backup system firmware, and the fourth area stores the double check field.

[0125] Additionally, it should be noted that after confirming the flag is valid, the A7 core reads the flash memory chip via the SPI bus using DMA mode, parses the backup system address information, and performs a validity check. In one possible implementation, the backup system address information is stored in the form of a C language structure; in another possible implementation, TLV (Type-Length-Value) encoding can also be used to improve scalability.

[0126] Step A30: The backup system address information is transmitted to the coprocessor core, so that the coprocessor core can read the backup system firmware resource pointed to by the backup system address information, map the backup system firmware resource to the control chipset, and the control chipset reads the backup system firmware resource to perform hardware initialization and boot the server.

[0127] It should be noted that, in this embodiment, "transmission" refers to the A7 core securely writing back the verified backup system address information to the M3 core via shared memory, completing the second-phase handshake between the two cores. "Mapping to the control chipset" refers to the M3 core utilizing the hardware remapping function of the USB OTG controller to virtualize the backup system firmware resources in memory as a USB mass storage device, enabling the control chipset to access the firmware via the USB bus instead of the SPI bus. "Control chipset" refers to the platform controller hub on the server motherboard, which is responsible for selecting the boot device and executing the firmware to complete hardware initialization after power-on. "Booting the server" refers to the control chipset loading the operating system loader into memory and executing it after completing memory, CPU, and peripheral initialization, ultimately bringing the server to a usable state.

[0128] Additionally, it should be noted that this operation achieves a three-level coordination of "out-of-band verification, out-of-band mapping, and in-band boot": After confirming that the address information is correct, the M3 core first reads the backup firmware from the flash memory chip into memory via DMA, and then performs CRC32+LRC dual verification. After the verification is successful, the USB OTG descriptor is immediately configured, and the memory buffer is registered as a boot device. The entire process requires no manual intervention and is completely isolated from the main BIOS fault path.

[0129] In this embodiment, leveraging the out-of-band management advantages of the BMC, the backup system firmware, i.e. the backup BIOS firmware, and the BMC firmware (baseboard management controller firmware) are co-located in the same Flash memory chip in a partitioned manner, eliminating the impact of server in-band faults. Furthermore, since the BMC is an out-of-band management chip with extremely high stability, binding the backup BIOS firmware with the BMC firmware can enhance the stability of the backup BIOS firmware. Furthermore, the backup BIOS firmware and BMC firmware share a single flash memory chip, eliminating the need for an additional BIOS chip and significantly reducing material costs. Moreover, after detecting a BIOS boot failure and triggering a software interrupt, the BMC's internal coprocessor core first sets the backup system address request flag and transmits it to the main control core. The main control core then returns the backup system address information of the backup BIOS to the coprocessor core. The coprocessor core reads the backup system firmware resources according to this address information and directly maps them to the control chipset, thus bypassing the main CPU and in-band paths to complete hardware initialization and server operating system startup. The entire switching process is completed out-of-band by the BMC, independent of the server's main processor and in-band links, and therefore unaffected by in-band server failures. Utilizing the BMC's dual-core division of labor (the coprocessor core is dedicated to fault handling, while the main control core continues to perform daily management tasks), both normal BMC functionality and rapid, reliable BIOS fault recovery are achieved. In summary, this application utilizes the out-of-band management function of the BMC to store the backup system firmware and the baseboard management controller firmware in the same flash memory chip in a partitioned manner. Combined with the dual-core division of labor of the BMC: the coprocessor core is dedicated to fault handling, while the main control core continues to perform daily management tasks, so as to achieve high reliability and server startup fault maintenance that is unaffected by in-band server failures at low cost.

[0130] In one feasible implementation, step A20 may include steps A21 to A23:

[0131] Step A21: Poll the backup system address request flag bit and monitor the changes in the backup system address request flag bit;

[0132] In this embodiment, "polling" refers to the A7 core actively reading the backup system address request flag in shared memory at fixed time intervals to detect whether the M3 core has issued a backup system address request. The backup system address request flag is a variable located in the shared memory area. When its value changes, for example, from 0 to 1, it indicates that the primary basic input / output system has failed to start consecutively and has reached a preset threshold, triggering the backup switchover process. "Monitoring the changes" means that the A7 core compares the values ​​read before and after the changes to determine whether the flag is set, thereby deciding whether to proceed to the subsequent address acquisition stage.

[0133] Additionally, it should be noted that this polling mechanism ensures that the A7 core can respond to the M3 core's requests within milliseconds, while not consuming interrupt resources and maintaining system stability. In one possible implementation, the polling period can be configured to 50ms; in another possible implementation, event-driven wake-up can be achieved by configuring the Mailbox interrupt register to reduce CPU utilization.

[0134] For example, in one specific implementation, the ARM Cortex-A7 main control core reads the shared memory address 0xFFFF0200 every 50ms. When it finds that the address has changed from 0x00000000 to 0x00000001, it immediately determines that the backup system address request flag is valid and needs to read the backup system address from the flash memory chip.

[0135] Step A22: When the backup system address request flag is changed to a valid state, read the end address of the baseboard management controller firmware program, the firmware start address of the backup system firmware program, and the check segment start address of the double check field from the flash memory chip.

[0136] Step A23: Obtain backup system address information based on the end address, the firmware start address, and the check segment start address.

[0137] The backup system address information includes the end address of the baseboard management controller firmware program, the firmware start address of the backup system firmware program, and the start address of the checksum section of the double checksum field. For example... Figure 4 As shown, Figure 4 This diagram illustrates the storage of backup system firmware within a flash memory chip. (Reference) Figure 4 The backup BIOS firmware and BMC firmware are stored together in a flash memory. The first segment of the flash memory stores the BMC firmware. The second segment is a specific end / start data segment added to the end of the BMC firmware. When burning the BMC firmware, this segment serves as an end marker. When enabling the BIOS, this segment serves as a start marker. The third segment stores the backup BIOS firmware. The fourth segment is a verification segment for the backup BIOS firmware.

[0138] The A7 core uses the SPI bus to read the starting address of the second data segment in the flash memory in DMA mode, which is the end address after the BMC firmware program; the starting address of the third backup BIOS firmware program; and the starting address of the fourth verification segment. These three addresses are read to form structured address information, ensuring the accuracy of subsequent firmware loading and verification.

[0139] For example, to help understand the implementation process of the server startup failure maintenance method in the above embodiments of this application, please refer to...Figure 5 , Figure 5 A framework diagram of the server startup failure maintenance system designed in this application is provided. Figure 5 As shown, the server startup fault maintenance system includes a server side and a BMC module side. The server side includes a central processing unit, a control chipset, and a main BIOS firmware. The BMC module uses the Aspeeed AST2600 BMC chip as the main control chip, i.e., the baseboard management controller chip. The BMC chip contains a coprocessor core M3 and a main control core A7. The BMC module also contains a firmware flash chip, i.e., a flash memory chip. The flash chip stores the BMC firmware program and the backup BIOS firmware program in a partitioned manner.

[0140] The flash chip and the BMC module's main control chip are connected via SPI (Serial Peripheral Interface). The M3 core in the BMC chip communicates with the A7 core through interrupt mechanisms and shared memory. The server communicates with the BMC module through the hardware connection lines between the control chipset and the AST2600 chip, including but not limited to LPC and USB 2.0.

[0141] In this technical respect, refer to Figure 6 , Figure 6 The flowchart of the backup BIOS boot method provided in this application is as follows: Figure 6 As shown, firstly, during the normal startup process of the server operating system, the self-test controller chipset periodically calls the watchdog timer function to prevent the watchdog timer from timing out when performing hardware initialization and booting the server operating system using the main BIOS firmware. For example, the watchdog timer function is called every 5 seconds, writing 0xAA to the watchdog timer's control register. If the watchdog receives a feed within the specified time (system normal), the watchdog flag is set to 0; if no feed is received (system abnormal), the watchdog flag is set to 1.

[0142] Furthermore, the M3 core is designed with a task that periodically reads the hardware register storing the watchdog flag. For example, it reads the status of the flag every 100 milliseconds. If the watchdog flag is found to be set (value 1), it indicates that the server startup has failed. The M3 core then determines the number of system restarts. If the number of restarts exceeds a predetermined number (e.g., 3), the M3 core immediately triggers a software interrupt.

[0143] Furthermore, upon triggering a software interrupt, the M3 core sets a specific flag to request the address information of the backup BIOS firmware from the A7 core. This flag is passed to the A7 core via shared memory. For example, a global variable is set to 1, and the A7 core periodically checks the value of this variable. When it finds that the value is 1, the A7 core retrieves the address information from the pre-stored backup BIOS firmware information and returns this address information to the M3 core via shared memory.

[0144] Furthermore, the M3 core receives the backup BIOS firmware address information written by the A7 core via shared memory. The M3 core immediately initiates a data acquisition process to fully read the address information and acquire it into memory. Then, the M3 core uses the hardware remapping function of the USBOTG controller to map the acquired backup BIOS firmware to the controller chipset, enabling the controller chipset to successfully access the backup BIOS firmware.

[0145] Finally, the controller chipset reads the relevant code and data from the backup BIOS firmware and begins hardware initialization, configuring and debugging various hardware devices in the system to ensure they are in a normal and usable state. After successful hardware initialization, the controller chipset further utilizes the bootloader in the backup BIOS firmware to boot the system, thus successfully replacing the faulty main BIOS firmware chip and ensuring stable system operation and normal startup.

[0146] Additionally, the BMC records reboot events and reboot operations to the SEL Event log, and records alarms in the IPMI log such as "Main BIOS boot error" to notify maintenance personnel or users.

[0147] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the server startup failure maintenance method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0148] This application also provides a server startup failure maintenance device; please refer to... Figure 7 The server startup fault maintenance device includes:

[0149] The coprocessing core module 10 is used to set a backup system address request flag when the server's main basic input / output system is triggered by a software interruption, pass the backup system address request flag to the main control core of the baseboard management controller chip, receive the backup system address information returned by the main control core, read the backup system firmware resources pointed to by the backup system address information, and map the backup system firmware resources to the control chipset.

[0150] The main control core module 20 is used to obtain backup system address information from the pre-stored backup system firmware program according to the backup system address request flag bit;

[0151] Backup storage module 30 is used to pre-store the backup system firmware and the baseboard management controller firmware in a partitioned manner;

[0152] The control chipset module 40 is used to read the backup system firmware resources to perform hardware initialization and boot the server.

[0153] The server startup failure maintenance device provided in this application, employing the server startup failure maintenance method in the above embodiments, can solve the technical problem of server startup failure maintenance. Compared with the prior art, the beneficial effects of the server startup failure maintenance device provided in this application are the same as those of the server startup failure maintenance method provided in the above embodiments, and other technical features in the server startup failure maintenance device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0154] This application provides a server startup failure maintenance device, which includes: 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, and the instructions are executed by the at least one processor to enable the at least one processor to perform the server startup failure maintenance method in the above embodiment 1.

[0155] The following is for reference. Figure 8 The diagram illustrates a structural schematic suitable for implementing a server startup failure maintenance device according to embodiments of this application. The server startup failure maintenance device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The server startup fault maintenance device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0156] like Figure 8As shown, the server startup fault maintenance device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the server startup fault maintenance device. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. Input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to input / output interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the server to initiate fault maintenance equipment to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows server initiation fault maintenance equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0157] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0158] The server startup failure maintenance device provided in this application, employing the server startup failure maintenance method in the above embodiments, can solve the technical problem of server startup failure maintenance. Compared with the prior art, the beneficial effects of the server startup failure maintenance device provided in this application are the same as those of the server startup failure maintenance method provided in the above embodiments, and other technical features of the server startup failure maintenance device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0159] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0160] The above description is merely a specific embodiment of this application, but the scope of protection of this application 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 application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0161] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the server startup failure maintenance method in the above embodiments.

[0162] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having 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 fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0163] The aforementioned computer-readable storage medium may be included in the server startup fault maintenance device; or it may exist independently and not be assembled into the server startup fault maintenance device.

[0164] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the server's fault maintenance device, the server initiates the fault maintenance device by: setting a backup system address request flag; transmitting the backup system address request flag to the main control core of the baseboard management controller chip, so that the main control core can obtain backup system address information from a pre-stored backup system firmware program based on the backup system address request flag, wherein the backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner; receiving the backup system address information returned by the main control core and reading the backup system firmware resource pointed to by the backup system address information; mapping the backup system firmware resource to the control chipset, so that the control chipset can read the backup system firmware resource for hardware initialization and booting the server.

[0165] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0166] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0167] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0168] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described server startup failure maintenance method, thereby solving the technical problem of server startup failure maintenance. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the server startup failure maintenance method provided in the above embodiments, and will not be repeated here.

[0169] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the server startup fault maintenance method described above.

[0170] The computer program product provided in this application can solve the technical problem of server startup failure maintenance. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the server startup failure maintenance method provided in the above embodiments, and will not be repeated here.

[0171] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for maintaining server startup failures, characterized in that, The coprocessor core applied to the baseboard management controller chip, the server startup fault maintenance method includes: Set the backup system address request flag when the server's primary input / output system is interrupted by a software interrupt. The backup system address request flag is passed to the main control core of the baseboard management controller chip, so that the main control core can obtain the backup system address information from the pre-stored backup system firmware program according to the backup system address request flag. The backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner. Receive the backup system address information returned by the main control core, and read the backup system firmware resources pointed to by the backup system address information; The backup system firmware resources are mapped to the control chipset, so that the control chipset can read the backup system firmware resources to perform hardware initialization and boot the server.

2. The server startup failure maintenance method as described in claim 1, characterized in that, The step of setting the backup system address request flag under the condition that the server's primary basic input / output system is triggered by a software interrupt includes: The monitoring status flag of the main basic input / output system in the server is read at preset time intervals, and the startup status of the main basic input / output system is determined based on the monitoring status flag. When the startup state of the main basic input / output system is restart state and the number of restarts is less than the preset restart threshold, the restart event that triggers the restart of the main basic input / output system is recorded, and a system startup failure alarm is issued. When the startup state of the primary basic input / output system is in restart state and the number of restarts is equal to the preset restart threshold, a software interrupt is triggered in the primary basic input / output system, a system error alarm is issued, and the backup system address request flag is set.

3. The server startup failure maintenance method as described in claim 1, characterized in that, The steps of receiving the backup system address information returned by the main control core and reading the backup system firmware resources pointed to by the backup system address information include: Receive the backup system address information returned by the main control core in the form of shared memory, and verify the backup system address information with specific identification information; If the specific identification information is verified, the backup system firmware resources stored in advance are completely read from the flash memory chip according to the backup system address information, and the double verification field is read from the flash memory chip.

4. The server startup failure maintenance method as described in claim 3, characterized in that, The step of mapping the backup system firmware resources to the control chipset includes: The dual verification fields are used to perform cyclic redundancy verification and vertical redundancy verification on the backup system firmware resources; Under the condition that the cyclic redundancy check and the longitudinal redundancy check pass, the backup system firmware resources are mapped to the control chipset.

5. The server startup failure maintenance method as described in claim 4, characterized in that, Following the step of mapping the backup system firmware resources to the control chipset, the method further includes: The backup system address information, the verification results of the cyclic redundancy check, and the verification results of the longitudinal redundancy check are logged. Write the restart event of the primary basic input / output system and the call event of the backup system firmware resources to the system log.

6. A method for maintaining server startup failures, characterized in that, The main control core applied to the baseboard management controller chip, the server startup fault maintenance method includes: The system receives a backup system address request flag from the coprocessor core of the baseboard management controller chip. The backup system address request flag is set by the coprocessor core when the server's main basic input / output system is triggered by a software interrupt. Based on the backup system address request flag, the backup system address information is obtained from the pre-stored backup system firmware program, wherein the backup system firmware program and the baseboard management controller firmware program are stored in the same flash memory chip in a partitioned manner. The backup system address information is transmitted to the coprocessor core, so that the coprocessor core can read the backup system firmware resources pointed to by the backup system address information, map the backup system firmware resources to the control chipset, and the control chipset reads the backup system firmware resources to perform hardware initialization and boot the server.

7. The method as described in claim 6, characterized in that, The step of obtaining backup system address information from the pre-stored backup system firmware program based on the backup system address request flag includes: Poll the backup system address request flag bit to monitor changes in the backup system address request flag bit; When the backup system address request flag is changed to a valid state, the end address of the baseboard management controller firmware program, the firmware start address of the backup system firmware program, and the check segment start address of the double check field are read from the flash memory chip. The backup system address information is obtained based on the end address, the firmware start address, and the check segment start address.

8. A server startup failure maintenance system, characterized in that, The server startup fault maintenance system includes: The baseboard management controller chip coprocessor core is used to set a backup system address request flag when the server's main basic input / output system is triggered by a software interrupt, pass the backup system address request flag to the main control core of the baseboard management controller chip, receive the backup system address information returned by the main control core, read the backup system firmware resources pointed to by the backup system address information, and map the backup system firmware resources to the control chipset. The main control core of the baseboard management controller chip is used to obtain the backup system address information from the pre-stored backup system firmware program according to the backup system address request flag bit; Flash memory chip, used to pre-store the backup system firmware and the baseboard management controller firmware in a partitioned manner; The control chipset is used to read the backup system firmware resources to perform hardware initialization and boot the server.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the server startup fault maintenance method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the server startup fault maintenance method as described in any one of claims 1 to 7.

Images