Multi-bios boot switching method, device, storage medium and computer program product

Abstract

The application discloses a multi-BIOS starting switching method and device, a storage medium and a computer program product, relates to the technical field of multi-BIOS storage chip starting, and discloses a multi-BIOS starting switching method, which comprises the following steps: acquiring a firmware degradation state vector of a main BIOS storage chip; inputting the firmware degradation state vector into a preset time sequence prediction model by a baseboard management controller, so as to acquire a starting failure probability within a future preset time length; and when the starting failure probability exceeds a preset threshold value, switching the power-on starting target of the baseboard management controller to a backup BIOS storage chip. As a result, the multi-BIOS starting switching method acquires the firmware degradation state vector, predicts the future starting failure probability through the preset time sequence prediction model, and automatically switches to the backup BIOS storage chip when necessary, thereby effectively avoiding the starting failure problem caused by the firmware degradation of the main BIOS storage chip, and improving the stability and reliability of the system.

Description

Technical Field

[0001] This application relates to the field of BIOS boot technology, and in particular to multi-BIOS boot switching methods, devices, storage media and computer program products. Background Technology

[0002] In servers, workstations, and high-availability computing devices, the Basic Input / Output System (BIOS) is a critical firmware component for hardware initialization and operating system loading. Its reliability directly affects the system's boot stability and business continuity. To improve system fault tolerance, the industry commonly adopts a dual-BIOS (or multi-BIOS) redundancy architecture, configuring a primary BIOS storage chip and a backup BIOS storage chip. When the primary BIOS fails, it can switch to the backup BIOS to maintain normal system startup. However, existing multi-BIOS switching mechanisms generally suffer from a "passive response" defect. Typical solutions rely on real-time error detection during the boot process (such as SPI communication failure, checksum errors, or abnormal CPU POST codes) to trigger the switch. This means the system must experience a boot failure before activating the backup BIOS. Such a "post-boot switch" strategy not only leads to service interruptions and prolonged recovery time but may also damage the degraded primary BIOS chip due to repeated attempts, potentially triggering a chain of failures. Summary of the Invention

[0003] The main purpose of this application is to provide a multi-BIOS boot switching method, device, storage medium, and computer program product, which aims to solve the technical problem that server multi-BIOS systems can only passively respond to switching.

[0004] To achieve the above objectives, this application proposes a multi-BIOS boot switching method, which includes:

[0005] Obtain the firmware degradation state vector of the main BIOS storage chip;

[0006] The baseboard management controller inputs the firmware degradation state vector into a preset timing prediction model to obtain the probability of startup failure within a preset time period in the future;

[0007] When the probability of startup failure exceeds a preset threshold, the power-on startup target of the baseboard management controller is switched to the backup BIOS storage chip.

[0008] In one embodiment, the step of obtaining the firmware degradation state vector of the main BIOS storage chip includes:

[0009] The baseboard management controller collects multiple firmware health data;

[0010] The firmware health data is transformed and normalized to generate the firmware degradation state vector by weighted combination of the processed firmware health data.

[0011] In one embodiment, the firmware degradation state vector includes the following components: ECC uncorrectable error rate component, FLASH erase / write count component, firmware hash drift component, average temperature component, temperature standard deviation component, SPI read retry count component, and bit flip distribution pattern component.

[0012] In one embodiment, the baseboard management controller inputs the firmware degradation state vector into a preset timing prediction model to obtain the probability of startup failure within a preset time period, including the following steps:

[0013] The baseboard management controller filters the firmware degradation state vector according to preset filtering conditions;

[0014] If the preset screening conditions are met, the preset time-series prediction model obtains the firmware degradation state vector to generate the startup failure probability within a preset time period in the future.

[0015] In one embodiment, after the step of switching the power-on boot target of the baseboard management controller to the backup BIOS storage chip when the boot failure probability exceeds a preset threshold, the method further includes:

[0016] If the main BIOS storage chip is started for more than a preset time, the baseboard management controller switches to the backup BIOS storage chip;

[0017] The system performs fault analysis on the main BIOS storage chip to generate fault location data and cause analysis reports, which are then uploaded or repaired.

[0018] In one embodiment, the step of performing fault analysis on the main BIOS storage chip includes: the baseboard management controller monitoring the status code sequence during the central processing unit startup process, locating the fault in the main BIOS storage chip according to a preset structure mapping table to generate fault location data, and performing attribution analysis on the main BIOS storage chip according to the work log to generate an attribution analysis report.

[0019] In one embodiment, after the step of performing fault analysis on the main BIOS storage chip to generate fault location data and attribution analysis report, and then uploading or repairing the fault location data and attribution analysis report, the method further includes:

[0020] Based on the fault location data and the attribution analysis report, the baseboard management controller performs differential repair on the main BIOS memory chip and performs repair verification according to the simulated boot process to generate verification data.

[0021] In addition, to achieve the above objectives, this application also proposes a multi-BIOS boot switching device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-BIOS boot switching method as described above.

[0022] 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 multi-BIOS boot switching method described above.

[0023] 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 multi-BIOS boot switching method described above.

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

[0025] The multi-BIOS boot switching method includes: acquiring the firmware degradation state vector of the main BIOS storage chip; the baseboard management controller inputting the firmware degradation state vector into a preset timing prediction model to obtain the boot failure probability within a preset time period; when the boot failure probability exceeds a preset threshold, the power-on boot target of the baseboard management controller is switched to the backup BIOS storage chip. In this way, the firmware degradation state vector acquired by the multi-BIOS boot switching method predicts the future boot failure probability through the preset timing prediction model, and automatically switches to the backup BIOS when necessary, thereby effectively avoiding boot failure problems caused by main BIOS firmware degradation and improving the stability and reliability of the system. Attached Figure Description

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

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

[0028] Figure 1 This is a flowchart illustrating an embodiment of the multi-BIOS boot switching method of this application.

[0029] Figure 2 This is a flowchart illustrating the specific implementation of step S100 in Embodiment 1 of the multi-BIOS boot switching method of this application;

[0030] Figure 3 A schematic flowchart illustrating the specific implementation of step S200 of the multi-BIOS boot switching method provided in this application;

[0031] Figure 4 This is a simplified flowchart illustrating the multi-BIOS boot switching method provided in Embodiment 2 of this application;

[0032] Figure 5 This is a simplified flowchart illustrating the multi-BIOS boot switching method provided in Embodiment 3 of this application;

[0033] Figure 6 This is a schematic diagram of the specific module structure of the multi-BIOS boot switching method in the embodiments of this application;

[0034] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the multi-BIOS boot switching method in this application embodiment.

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

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

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

[0038] In traditional multi-BIOS redundancy architectures, the fault response mechanism of the baseboard management controller for the main BIOS storage chip has the drawback of passively relying on real-time error detection during the boot process. The system must go through the complete boot process and confirm the failure before a switchover operation can be triggered. Furthermore, this mechanism makes service interruptions inevitable and extends recovery time. Repeated triggering of boot failure events may exacerbate the degradation of the main BIOS storage chip, thereby negatively impacting system boot stability and business continuity. Specifically, key performance indicators such as system availability and hardware reliability remain at risk due to the post-failure switchover strategy.

[0039] For example, in a high-availability server cluster deployed in a data center, the main BIOS storage chip may experience firmware degradation due to long-term operation. SPI communication timing deviations and checksum anomalies may occur intermittently during the startup phase. Furthermore, the baseboard management controller can only determine that the main BIOS is faulty after detecting an error in the POST code. As a result, the system is forced to complete a full startup failure process before switching the power-on target to the backup BIOS storage chip. This process causes service interruptions, and repeated startup attempts put additional stress on the degraded main BIOS storage chip. Specifically, the risk of hardware damage gradually accumulates in multiple startup cycles, thereby affecting the continuous operation capability of the entire server node.

[0040] If the above problems are not addressed, the system will frequently experience unplanned startup failures, with service interruption cycles being repeatedly introduced. Furthermore, the physical state of the main BIOS storage chip may deteriorate rapidly due to continuous stress, leading to a cascading failure risk. Specifically, the decline in hardware reliability will directly undermine the design goals of the multi-BIOS redundancy architecture, fundamentally challenging the effectiveness of the business continuity guarantee mechanism. As a preferred implementation method, the continued existence of this technical defect will hinder the stable deployment of high-availability computing devices in critical business scenarios.

[0041] Based on this, the embodiments of this application provide a method for switching between multiple BIOS boot BIOSes, referring to... Figures 1 to 6 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-BIOS boot switching method of this application. Figure 6 This is a schematic diagram of the specific module structure of the multi-BIOS boot switching method in the embodiments of this application.

[0042] In this embodiment, the multi-BIOS boot switching method includes steps S100~S300:

[0043] Step S100: Obtain the firmware degradation state vector of the main BIOS storage chip 2;

[0044] In step S200, the baseboard management controller 1 inputs the firmware degradation state vector into a preset timing prediction model to obtain the startup failure probability within a preset time period in the future.

[0045] Step S300: When the startup failure probability exceeds a preset threshold, the power-on startup target of the baseboard management controller 1 is switched to the backup BIOS storage chip 3.

[0046] In this embodiment, the server motherboard is equipped with two SPI Flash chips (e.g., Winbond W25Q128JV), which serve as the main BIOS storage chip 2 and the backup BIOS storage chip 3, respectively. The baseboard management controller 1 (e.g., ASPEED AST2600) controls a 2:1 BIOS select multiplexer 4 (e.g., TI SN74LVC1G3157) through a dedicated GPIO pin to dynamically determine whether the central processing unit 5 (e.g., CPU) accesses the main BIOS storage chip 2 or the backup BIOS storage chip 3 when it powers on. The baseboard management controller 1 periodically collects executable and configurable firmware content related to the health of the main BIOS storage chip 2 from the main BIOS chip and its surrounding sensors (e.g., temperature sensors), such as RAID, network card PXE, ME / PSP firmware, etc.

[0047] Specifically, the firmware degradation state vector refers to a multi-dimensional data set representing the health status of the main BIOS memory chip 2. It can be obtained by directly accessing the chip's built-in health monitoring registers, for example, by reading the accumulated error counter value on the SPI bus through the baseboard management controller 1. Its main purpose is to quantify the degree of chip degradation to support subsequent predictions. Further, the preset timing prediction model can be understood as a prediction algorithm for processing time series data. The lightweight timing prediction model (e.g., a neural network containing one LSTM layer (32 units) + one fully connected layer (output as a scalar)) pre-deployed in its internal SRAM has the following objective function:

[0048]

[0049] in, This represents the probability of startup failure within the next τ=72 hours, where n=5 is the length of the sliding window. For model functions, parameters It has been embedded in the baseboard management controller firmware. to All are time-series input observations of firmware degradation state vectors.

[0050] when When the threshold η (preset threshold η=0.85) is greater than η, the baseboard management controller 1 sends an instruction to the CPLD via the I²C bus or SMBus to set the multiplexer control signal to "backup BIOS storage chip 3", thereby ensuring that the central processing unit 5 starts from the backup BIOS storage chip 3 to load firmware when the AC is powered on or the baseboard management controller 1 is remotely powered on next time.

[0051] Therefore, this application obtains the firmware degradation state vector and inputs it into a timing prediction model to predict future startup risks, transforming the switching mechanism from relying on real-time error detection during the startup process to a proactive prevention mode, thus avoiding service interruptions and repeated damage to the degraded chip. As a preferred implementation, the firmware degradation state vector can also be obtained by monitoring chip operating parameters through external sensors, such as collecting voltage fluctuation data and converting it into degradation indicators, thereby ensuring the reliability of the prediction data. This embodiment achieves a technological shift in the startup switching mechanism from reactive response to proactive prevention through the synergistic effect of degradation state quantification, timing prediction, and threshold decision-making.

[0052] Furthermore, obtaining the firmware degradation state vector of the main BIOS storage chip 2 further includes:

[0053] Step S101: The baseboard management controller 1 collects multiple firmware health data.

[0054] Step S102: Perform data transformation and normalization on the firmware health data to generate the firmware degradation state vector by weighted combination of the processed firmware health data.

[0055] In this embodiment, the baseboard management controller is specifically set as a BMC chip, which has powerful data processing and communication capabilities and can accurately collect multiple firmware health data. These data cover various key parameters during firmware operation. Collecting multiple firmware health data means monitoring key health indicators in the operation of the BIOS chip from multiple dimensions. This can be achieved by periodically polling the SPI interface register or by real-time monitoring the hardware monitoring unit. The purpose is to avoid the one-sidedness of a single data source and provide basic data support for comprehensively capturing degradation trends. Data transformation and normalization of firmware health data refers to feature extraction and dimension unification of the original data. This can be achieved by using sliding window filtering to eliminate instantaneous noise or Z-score standardization to process heterogeneous data. The purpose is to eliminate the magnitude differences and noise interference of different health data and ensure the objectivity of the subsequent combination process. Weighted combination of the processed firmware health data to generate a firmware degradation state vector means fusion calculation based on the actual impact of each health indicator on degradation. This can be achieved by using a weight allocation algorithm trained on historical fault data or a dynamically adjusted weighted average strategy. The purpose is to generate a comprehensive quantitative indicator that can truly reflect the overall degradation state of the BIOS chip.

[0056] Furthermore, the firmware degradation state vector includes the following components: ECC uncorrectable error rate component, FLASH erase / write count component, firmware hash drift component, average temperature component, temperature standard deviation component, SPI read retry count component, and bit flip distribution pattern component.

[0057] In this embodiment, the ECC uncorrectable error rate component refers to the proportion of errors that cannot be corrected during the error correction process. This can be achieved by periodically scanning the memory error log and counting the frequency of uncorrectable error events, aiming to identify deep degradation trends caused by hardware aging. The FLASH erase / write cycle component refers to the cumulative frequency of erase / write operations on the storage medium. This can be achieved by maintaining a non-volatile counter to record the erase / write cycle, aiming to assess the physical wear and tear of the storage chip. The firmware hash drift component refers to the dynamic change in the firmware content hash value. This can be achieved by periodically calculating and comparing the firmware hash digest, aiming to detect progressive data drift or potential damage. The average temperature component refers to the temperature during the operation of the BIOS storage chip. The temperature mean, calculated by collecting data from a temperature sensor and performing a moving average, aims to quantify the impact of long-term thermal stress on chip lifespan. The temperature standard deviation component is an indicator of the dispersion of temperature fluctuations, calculated by statistically analyzing the standard deviation of temperature sampling data, and aims to reflect the risk of thermal stress caused by environmental instability. The SPI read retry count component refers to the number of retries required in serial peripheral interface communication, which can be achieved by monitoring retry events at the communication protocol layer and accumulating the count, aiming to provide early warning of decreased interface reliability or weakened chip responsiveness. The bit flip distribution pattern component refers to the spatial distribution characteristics of bit errors, which can be achieved by analyzing the statistical patterns of error locations, aiming to distinguish different fault mechanisms such as radiated interference or voltage fluctuations.

[0058] Specifically, the solution in this application systematically defines the firmware degradation state vector as a combination of multi-dimensional components covering electrical characteristics, physical wear, environmental impact, and communication reliability. This allows each component to be independently collected and characterize different degradation dimensions of the BIOS memory chip. These components are synchronously integrated into a unified vector and input to a timing prediction model. Based on the correlation between historical degradation data and boot failure events, the model dynamically analyzes the weights and interactions of each component to generate a predicted boot failure probability value within a preset time period. When this predicted value exceeds a preset threshold, the baseboard management controller 1 actively adjusts the power-on boot target to the backup BIOS memory chip 3, avoiding reliance on a passive switching mechanism after boot failure.

[0059] As a specific implementation method, the solution of this application is implemented as follows: The substrate management controller 1 is configured to use an ARM Cortex-M series microcontroller as the processing unit, collects the chip operating temperature through an integrated temperature sensor, and monitors communication retry events using an SPI controller; simultaneously, the substrate management controller calls the built-in error correction module to record uncorrectable ECC errors, periodically generates hash digests through a firmware hash calculation engine, and combines this with the erase / write counter data maintained by the storage management unit to comprehensively generate a firmware degradation state vector. In actual operation, the substrate management controller periodically performs data acquisition and vector construction, inputs the results into a preset timing prediction model for analysis, and ensures that the prediction process covers the degradation characteristics of the entire chip lifecycle.

[0060] Through the above scheme, this application can provide a comprehensive assessment of firmware degradation status from multiple dimensions, effectively improve the accuracy of boot failure probability prediction, thereby ensuring that the system actively switches to the backup BIOS storage chip 3 before the actual boot failure occurs, avoiding the risk of passive response due to insufficient prediction data, and significantly enhancing the reliability of system boot and business continuity.

[0061] In some embodiments described above in this application, the baseboard management controller 1 is proposed to input the firmware degradation state vector into a preset timing prediction model to obtain the startup failure probability within a preset time period in the future. However, in its implementation, the unfiltered firmware degradation state vector may contain noise, outliers or irrelevant state data, causing the timing prediction model to process low-quality input, thereby causing the startup failure probability prediction to be distorted, making the switching decision basis unreliable, which may cause premature switching or delayed switching, affecting the system startup stability.

[0062] Step S200, the baseboard management controller 1 inputs the firmware degradation state vector into a preset timing prediction model to obtain the startup failure probability within a preset time period, further includes the following steps:

[0063] Step S201: The baseboard management controller 1 filters the firmware degradation state vector according to preset filtering conditions;

[0064] Step S202: If the preset screening conditions are met, the preset time-series prediction model obtains the firmware degradation state vector to generate the startup failure probability within a preset time period in the future.

[0065] In this embodiment, to avoid invalid model calls under low-risk conditions, the substrate management controller 1 sets screening conditions to evaluate whether to call a preset time-series prediction model. For example, the model is called for prediction only when one or more of the following preset screening conditions are met, for example... >0.1 (ECC error active) >0.8 (Write / erase cycle nearing the end of life) If the preset filtering conditions are not met (e.g., >0.05, hash has drifted), the boot failure probability is directly determined to be 0, thus skipping the preset timing prediction model and saving CPU resources. If the preset filtering conditions are met, the preset timing prediction model is called, and the filtered firmware degradation state vector is input into the model. The model analyzes and processes the input vector based on its internal algorithm and training data, thereby generating the boot failure probability within a preset time period. This provides a key reference for subsequent operations such as multi-BIOS boot switching. V1, V2, and V3 are specific components in the firmware degradation state vector. V1 represents the proportion or frequency of errors in the main BIOS memory chip that cannot be corrected by the ECC (Error Correcting Code) mechanism. V2 represents the component reflecting the main BIOS... The components of the Flash chip's cumulative write / erase cycles relative to its maximum lifespan are: V3 represents the component that measures the difference in hash values ​​between the current firmware content and the original / baseline firmware. These components usually need to be normalized (e.g., scaled to the [0,1] range) before being input into the preset timing prediction model, so that health indicators of different dimensions can participate in weighted fusion and model inference in a unified manner. The preset screening conditions (e.g., V1>0.1) are risk trigger thresholds set based on the normalized values.

[0066] In servers, workstations, and high-availability computing devices, the Basic Input / Output System (BIOS) is a critical firmware component for hardware initialization and operating system loading. Its reliability directly affects the system's boot stability and business continuity. To improve system fault tolerance, the industry commonly adopts a dual-BIOS (or multi-BIOS) redundancy architecture, configuring a primary BIOS storage chip 2 and a backup BIOS storage chip 3. When the primary BIOS fails, it can switch to the backup BIOS to maintain normal system startup. However, existing multi-BIOS switching mechanisms generally suffer from a "passive response" defect. Typical solutions rely on real-time error detection during the boot process (such as SPI communication failure, checksum errors, or abnormal CPU 5 POST codes) to trigger the switch. This means the system must experience a boot failure before activating the backup BIOS. Such a "post-boot switch" strategy not only leads to service interruptions and prolonged recovery time but may also damage the degraded primary BIOS chip due to repeated attempts, potentially triggering a chain of failures. In some of the embodiments described above in this application, a startup target is set in advance based on the prediction of startup failure probability to avoid startup failure. However, in its implementation, when the main BIOS storage chip 2 is unexpectedly started and exceeds the preset time, the system lacks a real-time switching mechanism and fault diagnosis capability, which leads to prolonged service interruption time and may aggravate hardware degradation.

[0067] In this regard, this application further proposes that, in one embodiment, after step S300, the step of switching the power-on boot target of the baseboard management controller 1 to the backup BIOS storage chip 3 when the boot failure probability exceeds a preset threshold, the application further includes:

[0068] Step S400: If the main BIOS storage chip 2 has been running for longer than a preset time, the baseboard management controller 1 switches to the backup BIOS storage chip 3.

[0069] Step S500: Perform fault analysis on the main BIOS storage chip 2 to generate fault location data and cause analysis report, and upload or repair the fault location data and cause analysis report.

[0070] In this embodiment, "the main BIOS storage chip 2 booting for more than a preset time" means that the system monitors the boot process of the main BIOS storage chip 2 in real time. When the boot time exceeds a preset threshold, a switching mechanism is triggered. This can be implemented using an independent timing module or a status monitoring circuit, such as the crystal oscillator unit of the central processing unit 5, with the aim of timely identifying boot anomalies and avoiding unnecessary waiting. "The baseboard management controller 1 switching to the backup BIOS storage chip 3" means that the baseboard management controller 1 dynamically switches the boot source through hardware signal control. This can be implemented using an SPI bus selection switch or a dedicated switching chip, with the aim of ensuring that the system can quickly restore its boot capability. "Fault analysis generating fault location data and attribution analysis report" means diagnosing the operating status of the main BIOS storage chip 2 to determine the root cause of the fault. This can be implemented using a rule-based diagnostic engine or statistical analysis algorithm, with the aim of accurately identifying the fault type and preventing further damage. "Uploading or repairing the fault location data and attribution analysis report" means transmitting the diagnostic results to a remote management platform or initiating a local repair process. This can be implemented using a network communication interface or local storage medium, with the aim of achieving closed-loop management of fault handling.

[0071] Specifically, the proposed solution supplements the predictive switching mechanism by real-time monitoring of the main BIOS boot time. After the baseboard management controller 1 sets the backup BIOS as the next boot target, if the system unexpectedly boots from the main BIOS and the boot time exceeds a preset threshold, such as 30 seconds, the baseboard management controller immediately interrupts the current boot process and switches to the backup BIOS storage chip 3, thereby avoiding additional service interruption time. During this process, the baseboard management controller synchronously collects status data during the boot process and generates fault location data and attribution analysis reports through the fault analysis module. This analysis is based on the correlation between the boot status code sequence and the system operation log to achieve rapid identification of the root cause of the fault. This mechanism, together with the predictive switching, provides dual protection: the predictive mechanism prevents foreseeable boot failures, while the timeout switching mechanism handles prediction errors or unexpected situations, ensuring that the system can maintain high availability under various abnormal scenarios, while preventing hardware damage caused by repeated attempts to degrade the main BIOS chip.

[0072] As a specific implementation method, the solution of this application is implemented as follows: The baseboard management controller 1 adopts a dedicated management chip with integrated timing function, which continuously monitors the boot process of the main BIOS storage chip 2; when the boot time exceeds a preset threshold, the baseboard management controller 1 switches the boot source to the backup BIOS storage chip 3 by controlling the SPI bus selection switch; at the same time, the baseboard management controller 1 starts the fault analysis module, which parses the POST status code sequence of the central processing unit 5 and generates fault location data and attribution analysis report in combination with the system working log, and uploads the report to a remote server for centralized processing through the management network interface.

[0073] In some of the embodiments described above in this application, fault analysis of the main BIOS storage chip 2 is proposed to generate fault location data and attribution analysis reports. However, in its implementation, there is a lack of a systematic fault location mechanism and in-depth attribution analysis method, which results in the fault analysis only remaining at the surface phenomenon and failing to accurately identify the fault source and root cause, thereby affecting the pertinence of subsequent repairs and the reliability of the system.

[0074] Furthermore, the step of performing fault analysis on the main BIOS storage chip 2 includes: the baseboard management controller 1 monitors the status code sequence during the startup process of the central processing unit 5, locates the fault in the main BIOS storage chip 2 according to the preset structure mapping table to generate fault location data, and performs attribution analysis on the main BIOS storage chip 2 according to the work log to generate an attribution analysis report.

[0075] In this embodiment, the status code sequence refers to the code sequence output by the central processing unit 5 during the startup process to indicate the current startup stage and status. It can be implemented using POST codes or custom status codes. Its purpose is to capture dynamic behavioral details during the startup process in real time, avoiding reliance solely on static detection after startup failure. The preset structure mapping table can be understood as a lookup table that predefined the correspondence between status codes and fault points. It can be implemented using hash tables or database tables. Its purpose is to map the monitored status code sequence to specific hardware or firmware modules, ensuring the objectivity and repeatability of fault location. The work log refers to the detailed event and operation records recorded during system operation. It can be implemented using text log files or database logs. Its purpose is to provide contextual information about the occurrence of faults and support attribution analysis to trace the root cause.

[0076] Specifically, the solution in this application continuously monitors the status code sequence during the startup process of the central processing unit 5 through the baseboard management controller 1 to obtain real-time behavioral data of the startup phase. Subsequently, these status code sequences are parsed into specific fault location points using a preset structure mapping table to generate fault location data. At the same time, combined with historical event records in the work log, attribution analysis is performed to generate an attribution analysis report. This mechanism ensures that fault diagnosis is not only based on the phenomena after startup failure, but also achieves in-depth diagnosis from phenomena to root causes through continuous monitoring and structured analysis.

[0077] As a preferred embodiment, the solution of this application is specifically implemented as follows: The baseboard management controller 1 monitors the status code sequence output by the central processing unit 5 during the startup process. For example, when the status code is 0x55, it indicates the memory initialization stage, and when it is 0xAA, it indicates the graphics card detection stage. A preset structure mapping table maps the status code 0x55 to the memory controller module and the 0xAA to the graphics card interface module. The working log records the temperature change and voltage fluctuation data during startup, which is used to analyze the cause of the fault, such as memory errors caused by high temperature.

[0078] In some of the embodiments described above in this application, a fault analysis of the main BIOS storage chip 2 is proposed to generate fault location data and attribution analysis report for repair. However, in its implementation, the repair operation lacks a targeted processing mechanism based on the specific fault cause and no verification step is set, which may result in the repair only performing a general rewrite rather than a precise correction, which may easily lead to boot failure or repeated system failures after repair, and cannot ensure the reliability and one-time success rate of the repair.

[0079] In response, this application further proposes step S500, which, after the step of performing fault analysis on the main BIOS storage chip 2 to generate fault location data and cause analysis report, and uploading or repairing the fault location data and cause analysis report, also includes:

[0080] In step S600, based on the fault location data and the attribution analysis report, the baseboard management controller 1 performs differential repair on the main BIOS storage chip 2 and performs repair verification according to the simulated boot process to generate verification data.

[0081] In practical applications, differential repair operations refer to customized processing of degraded areas based on fault location data and attribution analysis reports. This can be achieved by rewriting only the affected storage blocks instead of a full disk refresh, aiming to avoid resource waste and potential risks caused by blind repairs. The simulated boot process can be understood as a verification mechanism that reproduces the CPU 5 initialization and firmware loading process before actual power-on. This can be implemented using a software simulation environment, aiming to expose repair defects in an isolated environment in advance and prevent service interruptions caused by verification failures. Specifically, verification data refers to the data set recording status code sequences and key indicators during the repair verification process. This can be implemented using structured log files, aiming to provide traceable evidence for subsequent maintenance and quantify the repair effect.

[0082] In this embodiment, by immediately performing differential repair operations based on fault location data and attribution analysis reports after fault analysis, the repair process closely aligns with the actual root cause of the fault. Subsequently, the repaired main BIOS storage chip 2 is verified according to the simulated boot process. This verification is completed before the system actually runs, avoiding the risk of service interruption in a real boot environment. Finally, verification data is generated as the output of the repair closed loop, ensuring that the repair effect can be objectively evaluated. Because the differential repair operation only precisely corrects the degraded areas, combined with the pre-verification mechanism of the simulated boot process, a complete technical chain from fault analysis to repair verification is formed, effectively solving the problems of lack of specificity in the repair process and missing verification links.

[0083] As a preferred embodiment, the solution of this application is implemented as follows: The baseboard management controller 1 identifies the bit flip distribution pattern of a specific block in the main BIOS memory chip 2 based on the fault location data, and performs a rewrite operation only on that block; subsequently, it simulates the initialization timing of the central processing unit 5 in a software simulation environment, loads the repaired firmware and monitors the status code sequence. If the status code sequence conforms to the preset normal startup mode, it generates verification data containing key indicator records; the verification data can be uploaded to a remote management platform for subsequent analysis.

[0084] Through the above scheme, this application ensures that the repair operation can accurately correct the specific cause of the fault, avoids the risk of startup failure after repair caused by general rewriting, and significantly improves the one-time success rate and reliability of repair through the pre-verification mechanism of simulating the startup process, effectively ensuring the continuity of system startup.

[0085] Through the above-mentioned scheme, this application achieves more precise fault location and more in-depth attribution analysis, which can accurately identify the fault source and root cause, thereby providing reliable data support for subsequent repair operations and effectively improving the system's fault tolerance and startup reliability.

[0086] This application provides a multi-BIOS boot switching 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 multi-BIOS boot switching method in the above embodiment 1.

[0087] The following is for reference. Figure 7 This document illustrates a structural diagram of a multi-BIOS boot switching device suitable for implementing embodiments of this application. The multi-BIOS boot switching 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 5 The multi-BIOS boot switching 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.

[0088] like Figure 7As shown, the multi-BIOS boot switching device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the multi-BIOS boot switching device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, 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. Communication device 1009 allows the multi-BIOS boot switcher to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows multi-BIOS boot switchers 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.

[0089] 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 ROM 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.

[0090] The multi-BIOS boot switching device provided in this application, employing the multi-BIOS boot switching method described in the above embodiments, can solve the technical problems of the multi-BIOS boot switching method. Compared with the prior art, the beneficial effects of the multi-BIOS boot switching device provided in this application are the same as those of the multi-BIOS boot switching method provided in the above embodiments, and other technical features in this multi-BIOS boot switching device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0093] 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 multi-BIOS boot switching method described in the above embodiments.

[0094] 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, 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 fiber, 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, 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.

[0095] The aforementioned computer-readable storage medium may be included in a multi-BIOS boot switching device; or it may exist independently and not be assembled into a multi-BIOS boot switching device.

[0096] The aforementioned computer-readable storage medium carries one or more programs.

[0097] 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++, and conventional procedural programming languages ​​such as the "C" language 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).

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

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

[0100] 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 multi-BIOS boot switching method, thereby solving the technical problem of multi-BIOS boot switching. 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 multi-BIOS boot switching method provided in the above embodiments, and will not be repeated here.

[0101] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-BIOS boot switching method described above.

[0102] The computer program product provided in this application can solve the technical problem of multi-BIOS boot switching. 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 multi-BIOS boot switching method provided in the above embodiments, and will not be repeated here.

[0103] 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 switching between multiple BIOS boot BIOSes, characterized in that, The multi-BIOS boot switching method includes: Obtain the firmware degradation state vector of the main BIOS storage chip; The baseboard management controller inputs the firmware degradation state vector into a preset timing prediction model to obtain the probability of startup failure within a preset time period in the future; When the probability of startup failure exceeds a preset threshold, the power-on startup target of the baseboard management controller is switched to the backup BIOS storage chip; The step of obtaining the firmware degradation state vector of the main BIOS storage chip includes: The baseboard management controller collects multiple firmware health data; The firmware health data is transformed and normalized to generate the firmware degradation state vector by weighted combination of the processed firmware health data. The firmware degradation state vector includes the following components: ECC uncorrectable error rate component, FLASH erase / write count component, firmware hash drift component, average temperature component, temperature standard deviation component, SPI read retry count component, and bit flip distribution pattern component.

2. The multi-BIOS boot switching method as described in claim 1, characterized in that, The baseboard management controller inputs the firmware degradation state vector into a preset timing prediction model to obtain the startup failure probability within a preset time period, including the following steps: The baseboard management controller filters the firmware degradation state vector according to preset filtering conditions; If the preset screening conditions are met, the preset time-series prediction model obtains the firmware degradation state vector to generate the startup failure probability within a preset time period in the future.

3. The multi-BIOS boot switching method as described in claim 1, characterized in that, The step of switching the power-on boot target of the baseboard management controller to the backup BIOS storage chip when the boot failure probability exceeds a preset threshold further includes: If the main BIOS storage chip is started for more than a preset time, the baseboard management controller switches to the backup BIOS storage chip; The system performs fault analysis on the main BIOS storage chip to generate fault location data and cause analysis reports, which are then uploaded or repaired.

4. The multi-BIOS boot switching method as described in claim 3, characterized in that, The steps for fault analysis of the main BIOS storage chip include: the baseboard management controller monitors the status code sequence during the startup process of the central processing unit, locates the fault in the main BIOS storage chip according to a preset structure mapping table to generate fault location data, and performs attribution analysis on the main BIOS storage chip according to the work log to generate an attribution analysis report.

5. The multi-BIOS boot switching method as described in claim 3, characterized in that, The step of performing fault analysis on the main BIOS storage chip to generate fault location data and cause analysis report, and then uploading or repairing the fault location data and cause analysis report, further includes: Based on the fault location data and the attribution analysis report, the baseboard management controller performs differential repair on the main BIOS memory chip and performs repair verification according to the simulated boot process to generate verification data.

6. A multi-BIOS boot switching device, characterized in that, The multi-BIOS boot switching device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-BIOS boot switching method as described in any one of claims 1 to 5.

7. 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 multi-BIOS boot switching method as described in any one of claims 1 to 5.

8. 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 multi-BIOS boot switching method as described in any one of claims 1 to 5.

Images