Firmware configuration data processing method and device, and server

Abstract

The application relates to a firmware configuration data processing method and device and a server, and relates to the technical field of computers. The method comprises the following steps: when a server is powered on, writing firmware configuration data required by a basic input / output system into a volatile shared storage area of a baseboard management controller; when the basic input / output system is in a first starting stage, reading first firmware configuration data in the shared storage area by using a first communication interface to configure data transmission firmware required by a second communication interface; and when being in a second starting stage, switching to a second communication interface with higher communication efficiency to continue reading second firmware configuration data in the shared storage area. According to the application, memory-level reading and writing are used to replace flash memory erasing and writing, and differential access is carried out in stages, so that the storage medium loss is reduced, and the data processing efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a firmware configuration data processing method, apparatus, and server. Background Technology

[0002] In server systems, the configuration parameters of the Basic Input / Output System (BIOS) are typically stored in the non-volatile random access memory (NVRAM) area within the non-volatile flash memory (such as SPI Flash, Serial Peripheral Interface Flash, also simply referred to as Flash) on the motherboard. Because this area uses flash memory chips as the storage medium, its physical characteristics limit the number of erase / write cycles. However, in related technologies, the BIOS needs to frequently read and update configuration parameters during startup and operation. This high-frequency direct read / write operation can easily accelerate the wear and tear of the aforementioned non-volatile flash memory, shortening the chip's lifespan. Furthermore, the writing mechanism of non-volatile flash memory typically involves page erasure and full-page writing. This is inefficient when parameters need to be stored across pages, and the garbage collection mechanism triggered when the storage space is full may cause system crashes due to external interruptions. Summary of the Invention

[0003] This invention provides a firmware configuration data processing method, apparatus, and server to at least solve the problems of high lifespan loss and low access efficiency of firmware configuration data storage media in related technologies. The technical solution of this invention is as follows: According to a first aspect of the present invention, a firmware configuration data processing method is provided, applied to a server including a baseboard management controller and a basic input / output system (PIS). The method includes: when the server is powered on, writing firmware configuration data required by the PIS to a shared storage area of ​​the baseboard management controller; the shared storage area is a volatile storage area; when the PIS is in a first startup phase, controlling the PIS to read first firmware configuration data from the firmware configuration data required in the shared storage area using a first communication interface, so as to configure the data transmission firmware required by a second communication interface based on the first firmware configuration data; when the PIS is in a second startup phase, controlling the PIS to switch to the second communication interface, and using the second communication interface to call the data transmission firmware to continue reading the second firmware configuration data in the shared storage area; the communication efficiency of the second communication interface is higher than that of the first communication interface.

[0004] The second firmware configuration data is the other firmware configuration data besides the first firmware configuration data in the required firmware configuration data.

[0005] In this technical solution, given that the read / write mechanism of volatile memory (such as SRAM) is fundamentally different from that of flash memory, volatile memory can support byte-level random read / write, requires no page erase, has no full-page write constraint, and does not require a garbage collection mechanism. This application, by carrying runtime firmware configuration data in a volatile shared memory area instead of local flash memory, physically isolates the wear and tear on non-volatile media caused by high-frequency read / write operations. Simultaneously, considering the characteristic of the high-speed bus not being ready in the early stages of system startup, a low-dependency first communication interface is set up to ensure the acquisition of basic configuration. After the high-speed bus initialization is completed, it automatically switches to a high-bandwidth second communication interface, achieving a dynamic balance between startup compatibility and data transmission efficiency during the startup process.

[0006] In one technical solution, when the firmware configuration data in the shared storage area is detected to meet the update write conditions, the baseboard management controller is controlled to write the firmware configuration data in the shared storage area into the non-volatile storage medium of the baseboard management controller.

[0007] Among them, the update write condition refers to the state in which the data changes and the preset synchronization strategy is reached. The non-volatile storage medium is used to save a persistent copy of the configuration data in the event of a power failure.

[0008] This technical solution avoids invalid writes to the non-volatile storage medium by triggering write operations only when the data actually changes. While ensuring that the data in the volatile shared storage area has the ability to recover from power failure, it further reduces the number of writes to the non-volatile storage medium, thus balancing high performance during operation, data security, and storage medium lifespan protection.

[0009] In one technical solution, when the server is powered on, the firmware configuration data required by the basic input / output system is written to the shared storage area of ​​the baseboard management controller. This includes: when it is determined that the server power-on signal is a power-down restart signal, controlling the baseboard management controller to write the firmware configuration data in the non-volatile storage medium to the shared storage area; and when it is determined that the server power-on signal is an initial power-on signal, controlling the basic input / output system to read the default firmware configuration data from the motherboard flash memory of the basic input / output system and copying the read default firmware configuration data to the shared storage area.

[0010] Among them, the power-down restart signal characterization system has undergone a complete power-down process and needs to restore the user configuration from the persistent medium; the initial power-on signal characterization system has been deployed for the first time or has performed a configuration clearing operation and needs to load the factory default values.

[0011] This technical solution matches the corresponding data source path with two electrical signal types: normal restart and first power-on. In the normal restart scenario, data can be quickly recovered directly from the non-volatile storage medium on the board management controller side, shortening the boot time. In the initial power-on scenario, the system default settings are loaded from the motherboard flash memory, ensuring that the system can still boot normally even without effective backup data. This ensures the correctness of the data source in the shared storage area under different power-on scenarios and avoids system configuration abnormalities caused by incorrect data sources.

[0012] In one technical solution, the method further includes: in response to the Basic Input / Output System (PIOS) performing a firmware upgrade operation or a factory reset operation, setting a reset flag in a shared memory area; in response to the reset flag, the PIOS reads default firmware configuration data from the PIOS motherboard flash memory and copies the read default firmware configuration data to the shared memory area; and controlling the board management controller to copy the read default firmware configuration data from the shared memory area to a non-volatile storage medium; when it is detected that the read default firmware configuration data in the shared memory area has not been updated and has been completely copied to the non-volatile storage medium, setting a data completion flag in the shared memory area and deleting the reset flag in the shared memory area.

[0013] Among them, the reset flag is the control bit that triggers the configuration restore process, and the data completion flag is the status bit that confirms the consistency of the persistent backup.

[0014] In this technical solution, a reset flag is first set during the configuration restore process to mark the start of the restore operation. After the default configuration data is completely written to the shared storage area and synchronized to the non-volatile storage medium, a data completion flag is set and the reset flag is cleared, forming a complete state transition closed loop. When an unexpected power failure occurs during the restore process, the system can detect the presence of the reset flag or the absence of the data completion flag to identify the incomplete state of the restore operation. This allows the restore process to be re-executed upon the next power-on, ensuring atomic switching between old and new configuration data in firmware change or reset scenarios and preventing configuration data from being in an uncertain state due to power failure.

[0015] In one technical solution, the method further includes: when a reset flag is detected in the shared storage area or no data completion flag is detected in the non-volatile storage medium, determining that the server power-on signal is an initial power-on signal; when no reset flag is detected in the shared storage area and a data completion flag is detected in the non-volatile storage medium, determining that the server power-on signal is a power-down restart signal.

[0016] This technical solution employs a dual verification logic using a reset flag and a data completion flag: when a reset flag exists in the shared storage area or a data completion flag is missing in the non-volatile storage medium, it is determined to be an initial power-on signal; only when the reset flag is absent and the data completion flag exists is it determined to be a power-down restart signal. This dual verification mechanism ensures that an abnormal state of either flag bit will not lead to misjudgment of the power-on scenario. For example, if the reset flag is not cleared due to an anomaly, the system can still correctly identify the initial power-on scenario based on the missing data completion flag and re-execute the configuration restoration process, thereby improving the robustness of the system state machine.

[0017] In one technical solution, the first communication interface includes a mailbox message channel; the second communication interface includes a memory-mapped input / output area mapped by a high-speed bus based on peripheral component interconnection; when the basic input / output system is in the second startup phase, controlling the basic input / output system to switch to the second communication interface includes: controlling the basic input / output system to send a configuration request to the baseboard management controller after completing the high-speed bus initialization operation; the baseboard management controller responding to the configuration request to map the shared memory area as a memory-mapped input / output area on the high-speed bus; and calling the basic input / output system's preset driver to switch the access path for firmware configuration data from the mailbox message channel of the first communication interface to the memory-mapped input / output area.

[0018] Among them, the mailbox message channel is a low-speed communication method based on IO ports, which is suitable for bus resource-constrained environments such as the PEI stage; the memory-mapped input / output area (MMIO) is a high-speed memory access method based on the PCIe bus, which is suitable for DXE and subsequent stages.

[0019] In this technical solution, after the high-speed bus initialization is completed, the baseboard management controller maps the shared memory area to the MMIO area on the PCIe bus and calls the preset driver to switch the access path from the mailbox message channel to the MMIO area. This enables the basic input / output system to directly read and write the configuration data in the shared memory area in the second startup phase in the form of memory access, without the overhead of message encapsulation and parsing. The high bandwidth characteristics of the PCIe bus significantly improve the throughput of a large amount of configuration data.

[0020] In one technical solution, after switching to the memory-mapped input / output area, the method further includes: controlling the basic input / output system to determine whether the second communication interface is available by reading the service status value of a preset service status register in the memory-mapped input / output area; if the second communication interface is available, keeping the access path unchanged on the second communication interface; if the second communication interface is unavailable, calling the preset driver of the basic input / output system to fall back the access path to the first communication interface.

[0021] Among them, the service status register is a hardware feedback mechanism that reflects the service readiness status of the shared memory on the baseboard management controller side. Its service status value is dynamically updated by the baseboard management controller according to the actual operating status of the memory mapping input and output area mapping.

[0022] In this technical solution, after switching to the memory-mapped I / O area, the availability of the high-speed path is verified by actively reading the value of the service status register. When an anomaly is detected in the memory-mapped I / O area service, it automatically falls back to the mailbox message channel, forming a fault degradation strategy. This fault degradation strategy ensures that even when the high-speed path is unavailable due to hardware failure or driver anomaly, the system can still maintain basic read / write functions of configuration data through the low-speed path, guaranteeing the continuity of firmware configuration data access and preventing system startup failure due to communication link failure.

[0023] In one technical solution, writing firmware configuration data from a non-volatile storage medium into a shared storage area includes: determining a hash check value for a backup file, wherein the firmware configuration data is stored in a backup file on the non-volatile storage medium; comparing the hash check value with a preset benchmark check value; and writing the firmware configuration data from the non-volatile storage medium into the shared storage area when the comparison result indicates that the hash check value matches the preset benchmark check value.

[0024] Among them, the hash check value is a summary information obtained by hashing the contents of the backup file, which is used to characterize the integrity features of the data; the preset benchmark check value is a trusted reference standard generated synchronously when the data is written to the non-volatile storage medium.

[0025] In this technical solution, before loading firmware configuration data from non-volatile storage media to the shared storage area, the hash checksum of the backup file is calculated and compared with a preset baseline checksum. Only when the two match is the data write operation performed. In this way, the validity of the backup file is verified by hash comparison, preventing corrupted or tampered configuration data from being loaded into the shared storage area, thus ensuring the security and reliability of firmware configuration data from the source.

[0026] According to a second aspect of the present invention, a firmware configuration data processing apparatus is provided, applied to a server including a baseboard management controller and a basic input / output system (PIS). The apparatus includes: a data read / write module configured to write firmware configuration data required by the PIS to a shared storage area of ​​the baseboard management controller when the server is powered on; the shared storage area is a volatile storage area; a first interface calling module configured to, when the PIS is in a first startup phase, control the PIS to read first firmware configuration data from the firmware configuration data required in the shared storage area using a first communication interface, so as to configure data transmission firmware required by a second communication interface based on the first firmware configuration data; and a second interface calling module configured to, when the PIS is in a second startup phase, control the PIS to switch to the second communication interface and use the second communication interface to call the data transmission firmware to continue reading the second firmware configuration data in the shared storage area; the communication efficiency of the second communication interface is higher than that of the first communication interface.

[0027] The aforementioned device realizes the physical embodiment of the firmware configuration data processing method through modular design. The modules work together to complete the dynamic migration and dual-mode access of configuration data, ensuring the executability and stability of the method on the actual hardware platform.

[0028] According to a third aspect of the present invention, a computer-readable storage medium is provided, on which instructions are stored, such that when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform a firmware configuration data processing method as described in the first aspect and any possible implementation thereof.

[0029] According to a fourth aspect of the present disclosure, a server is provided, the server including computer instructions that, when executed on the server, cause the server to perform the firmware configuration data processing method of the first aspect and any possible implementation thereof.

[0030] The technical solution provided by the embodiments of the present invention brings at least the following beneficial effects: First, the firmware configuration data required by the basic input / output system is written to the shared storage area of ​​the baseboard management controller, and the working copy of the firmware data is transferred from the non-volatile Flash on the motherboard to the volatile shared memory (such as SRAM / SDRAM) of the BMC, so that the BMC loads the data into the volatile memory in advance before the BIOS starts, thereby changing the data preparation and BIOS startup execution processes from serial to parallel, eliminating the initial delay of waiting to read data from the slow Flash when the BIOS starts, and significantly shortening the server startup time.

[0031] Secondly, given that critical hardware pathways such as high-speed buses (e.g., PCIe buses) are not yet initialized during the first stage of BIOS startup, making high-efficiency standard high-speed interfaces unavailable, a first communication interface with lower communication efficiency is set up to obtain the first firmware configuration data through the shared memory area of ​​the BMC. This ensures that high-speed firmware data can be reliably obtained even when the high-speed hardware environment is not ready.

[0032] Finally, by seamlessly switching the configuration data access path from the low-speed first communication interface to the high-speed second communication interface in the second stage of BIOS startup, and using dedicated data transmission firmware to support burst data transmission and high bandwidth throughput, the efficiency of configuration data transmission is improved and the server startup time is significantly shortened.

[0033] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0035] Figure 1 This is a schematic diagram illustrating a firmware configuration data processing system according to an exemplary embodiment; Figure 2 This is a flowchart illustrating a firmware configuration data processing method according to an exemplary embodiment; Figure 3 This is a block diagram illustrating a firmware configuration data processing apparatus according to an exemplary embodiment; Figure 4 This is a schematic block diagram of a server according to an exemplary embodiment. Detailed Implementation

[0036] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0037] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0038] Before providing a detailed description of the firmware configuration data processing method provided in the embodiments of this application, a brief introduction to the technical terms and implementation architecture involved in the embodiments of this application will be given first.

[0039] First, the technical terms used in this application are explained as follows.

[0040] BMC: Baseboard Management Controller, is an independent management unit integrated on the server system. It is responsible for managing server components and monitoring the operating status of the equipment. The BMC can still work normally even if the server is shut down or the operating system is not started.

[0041] BIOS: Basic Input / Output System, is a set of low-level firmware programs embedded in a ROM chip on the computer motherboard. It is the first software to run after the computer is powered on, responsible for waking up the hardware and handing it over to the operating system.

[0042] SIO Mailbox: Super Input / Output Mailbox. SIO is an extended I / O component integrated into the server BMC chip, and Mailbox is a data communication method integrated into SIO.

[0043] UEFI: Unified Extensible Firmware Interface, is a standard that regulates computer boot processes, hardware initialization, and operating system booting.

[0044] PEI: Pre-EFI Initialization (Extensible Firmware Interface), stored in FV_BB, is responsible for initializing memory, scheduling and executing each PEI module, and finally transferring control to the DXE stage.

[0045] DXE: Driver Execution Environment. The DXE stage is responsible for performing most of the system initialization work, providing the necessary hardware support and services for the booting and operation of the operating system.

[0046] FV_BB: BIOS boot partition (Firmware Volume – Boot Block), the first partition for BIOS boot, stores the SEC phase (Security and Early Initialization Phase) and PEI phase code, and is responsible for the initialization of necessary services for BIOS boot, such as memory.

[0047] FV_MAIN: BIOS main partition (Firmware Volume – Main Block). The main partition is responsible for most of the functionality. The FV_BB code is decompressed and copied into memory for execution.

[0048] NVRAM: Non-volatile random access memory, used to store the settings parameters required by the BIOS, i.e., firmware configuration data.

[0049] JSON: JavaScript Object Notation, a lightweight data interchange format.

[0050] Shared memory: Shared memory is an efficient communication and data sharing mechanism that allows the BMC and BIOS to directly access the same physical memory area, thereby enabling fast data exchange and collaborative work.

[0051] EMMC: This refers to the EMMC (Embedded Multi Media Card) chip mounted under the BMC chip. This EMMC chip can be a type of storage chip that integrates flash memory chips and flash memory controllers together.

[0052] Secondly, the implementation background of this application will be briefly introduced below.

[0053] The BIOS is responsible for detecting and initializing various server components (CPU, memory, PCIe, etc.) and loading necessary peripheral drivers. BIOS firmware is mainly divided into a code area and a data area. The code area can be further subdivided into FV_BB and FV_MAIN regions depending on its purpose, while the data area is the NVRAM area. NVRAM is the area in the BIOS firmware that stores important parameters of various computer components. When external users modify BIOS parameters through the BIOS setup interface or system tools, these changes are saved to NVRAM via the BIOS interface. Upon the next reboot, the BIOS applies the new settings to initialize the devices, enabling user interaction.

[0054] The BIOS is a program embedded in the SPI Flash chip on the computer motherboard, and NVRAM is the area where the BIOS firmware is most frequently written. To avoid damage to the Flash chips, it is possible to check whether there are changes in variables when the BIOS is writing to NVRAM and decide whether to write to the variables, thereby reducing the number of Flash erase / write cycles. However, this solution still cannot avoid the lifespan issues caused by frequent writing.

[0055] To address the aforementioned issues, this application utilizes the BMC shared memory method to store and access NVRAM in the BIOS. During each boot, NVRAM data is written to the BMC shared memory, replacing the BIOS Flash write process and reducing the number of BIOS Flash erase / write operations. Furthermore, the operation of writing NVRAM variables is changed from erasing and writing to the BIOS NVRAM area to writing to the BMC shared memory, which significantly improves write efficiency and further optimizes boot time.

[0056] Next, a brief introduction to the implementation architecture involved in this application will be given.

[0057] Figure 1 This is a schematic diagram of a firmware configuration data processing system provided in this disclosure. Figure 1 As shown, the firmware configuration data processing system includes a server, which mainly comprises a baseboard management controller 10, a basic input / output system 20, a motherboard flash memory 21, a first communication interface 30, a second communication interface 40, and a central processing unit 50. The following is in conjunction with... Figure 1 The structural relationships, setup methods, and functions of the above-mentioned components are described below.

[0058] The central processing unit 50 (CPU) is the core computing and scheduling unit of the server, responsible for executing the instruction stream of the operating system and various applications. The CPU 50 establishes communication connections with the baseboard management controller 10 and the motherboard flash memory 21.

[0059] In some implementations, the central processing unit 50 is connected to the board management controller 10 via two physical links: an enhanced serial peripheral interface (eSPI) bus and a peripheral component interconnect (PCIe) high-speed bus. The former is used to initiate low-speed management communication in the early stages, while the latter is used to initiate high-bandwidth data transmission in the later stages and during operation. Simultaneously, the central processing unit 50 accesses the motherboard flash memory 21 via the serial peripheral interface (SPI) bus through a multiplexer 60 (MUX) to load and execute the firmware code of the basic input / output system 20.

[0060] The specific model and architecture of the aforementioned central processing unit 50 do not constitute a limitation on this application; it can be an x86 architecture, an ARM architecture, or any other processor suitable for server scenarios.

[0061] The baseboard management controller 10 establishes a bidirectional communication connection with the central processing unit 50 via the eSPI bus and PCIe bus. It is also connected to the multiplexer 60 via a connection, thereby sharing the SPI access path to the motherboard flash memory 21 with the central processing unit 50. The shared memory of the baseboard management controller 10 includes a shared storage area 11, and an external or internal non-volatile storage medium 12 is connected. The two work together to undertake the runtime carrying and persistent backup functions of firmware configuration data.

[0062] The specific chip model of the aforementioned baseboard management controller 10 is not limited; it can be an ASPEED series, Nuvoton series, or other embedded processors with equivalent management functions.

[0063] Shared memory area 11 is a volatile memory region partitioned within the baseboard management controller 10. Its physical implementation can be part of static random access memory (SRAM) or dynamic random access memory (DRAM). As a shared physical memory region accessible to both the basic input / output system 20 and the baseboard management controller 10, shared memory area 11 enables efficient data exchange and collaborative operation between the two.

[0064] The non-volatile storage medium 12 is disposed on one side of the baseboard management controller 10 and establishes a data communication connection with the baseboard management controller 10 for persistently storing backup files of firmware configuration data.

[0065] In some embodiments, the non-volatile storage medium 12 can be an embedded multimedia card (EMMC) chip. The non-volatile storage medium 12 can retain data without loss after the server is powered off. When the server is powered on again, the baseboard management controller 10 reads the backup file from the non-volatile storage medium 12 and loads it into the shared storage area 11 to realize the power-off recovery of firmware configuration data.

[0066] It should be understood that the non-volatile storage medium 12 is not limited to an eMMC chip, but may also be a SPINOR Flash, a UFS storage device or other storage unit with power-off retention capability in other embodiments.

[0067] The startup process of the Basic Input / Output System 20 follows the UEFI specification, sequentially going through the Security Authentication (SEC) phase, the Pre-EFI Initialization (PEI) phase, and the Driver Execution Environment (DXE) phase. During different startup phases, the Basic Input / Output System 20 interacts with the Baseboard Management Controller 10 via the first communication interface 30 and the second communication interface 40 to obtain firmware configuration data from the shared memory area 11.

[0068] The motherboard flash memory 21 is an SPI NOR Flash chip that is soldered or plugged into the server motherboard and is used to store the complete firmware image of the basic input / output system 20.

[0069] The motherboard flash memory 21 can be logically divided into multiple functional partitions, including a boot partition (FV_BB, storing SEC and PEI stage code), a main partition (FV_MAIN, storing DXE stage code and drivers), other functional areas, and an NVRAM area. The NVRAM area is used to store the default firmware configuration parameters of the basic input / output system 20, serving as a trusted data source during the system's first power-on or factory reset.

[0070] In this embodiment, the NVRAM region in the motherboard flash memory 21 no longer undertakes the task of frequent read and write operations during operation, and is only accessed during initial power-on or configuration reset scenarios, thereby significantly reducing the erase and write frequency of this flash memory region.

[0071] The multiplexer 60 (MUX) is located on the SPI bus between the central processing unit 50, the baseboard management controller 10 and the motherboard flash memory 21. It is used to time-share the SPI bus access rights between the central processing unit 50 and the baseboard management controller 10, so that the two can share the read channel of the motherboard flash memory 21 without bus conflict.

[0072] The first communication interface 30 is a low-speed communication channel used between the basic input / output system 20 and the baseboard management controller 10 during the early startup phase.

[0073] In some embodiments, the first communication interface 30 is specifically implemented as a SIO Mailbox, which is based on the Super Input / Output (SIO) component integrated in the baseboard management controller 10. The physical layer relies on the eSPI bus or the Low Pin Count (LPC) bus for transmission. The Basic Input / Output System 20 can send and receive commands and data with the baseboard management controller 10 by configuring the IO address space. This interface has low dependence on the core hardware resources of the system and can be used in the early stages of startup before the PCIe bus has been initialized. The transmission rate of the first communication interface 30 is typically on the order of KB / s, suitable for critical configuration data with small transmission volumes but high availability requirements.

[0074] The second communication interface 40 is a high-speed communication channel used between the basic input / output system 20 and the baseboard management controller 10 during the later stages of startup, and its communication efficiency is higher than that of the first communication interface 30.

[0075] In some embodiments, the second communication interface 40 is specifically implemented as a memory-mapped input / output (MMIO) region based on the PCIe bus. The baseboard management controller 10 utilizes the base address register (BAR) mechanism of the PCIe device to map the physical address of the shared memory area 11 to the PCIe address space of the server, enabling the central processing unit 50 to directly read and write data in the shared memory area 11 through standard Load / Store memory access instructions without going through IO port operations or message encapsulation / decapsulation processes.

[0076] The second communication interface 40 can be configured to support burst transmission and zero-copy access, with an effective bandwidth of up to GB / s, suitable for non-critical initialization parameters and runtime variable data with large transmission volumes.

[0077] It should be understood that although this embodiment uses PCIe MMIO as an example of the second communication interface, USB, NVMe over Fabric or other high-speed interfaces with direct memory access capabilities may also be used in other embodiments.

[0078] Based on the above-described implementation architecture, the firmware configuration data processing method in the following embodiments of this application is executed collaboratively by the baseboard management controller 10 and the basic input / output system 20. The shared storage area 11 carries the runtime configuration data, the non-volatile storage medium 12 enables power failure backup and recovery, and the phased switching between the first communication interface 30 and the second communication interface 40 balances startup compatibility and data transmission efficiency.

[0079] The firmware configuration data processing method provided in this application embodiment can be applied to the aforementioned... Figure 1The illustrated implementation architecture includes a firmware configuration data processing system or server. For ease of understanding, the firmware configuration data processing method provided in this application will be described in detail below with reference to the accompanying drawings.

[0080] Figure 2 This is a flowchart illustrating a firmware configuration data processing method according to an exemplary embodiment, such as... Figure 2 As shown, the firmware configuration data processing method includes the following steps.

[0081] In step S100, when the server is powered on, the firmware configuration data required by the basic input / output system is written to the shared storage area of ​​the baseboard management controller, which is a volatile storage area.

[0082] After the server is powered on and reset, the baseboard management controller initializes before the basic input / output system and loads the firmware configuration data into the shared memory area.

[0083] In some implementations, the shared memory area is logically divided into two parts: a header information area (Header-NVRAM) and an NVRAM data area. The header information area is used to store metadata and control information such as signature identifier, service status register, reset flag, data completion identifier, and exclusive flag. The NVRAM data area is used to store firmware configuration data (i.e., NVRAM variables) required for the basic input / output system to run. Each variable is organized in key-value pairs and a variable index table is maintained.

[0084] In this implementation, the shared memory area is configured as a volatile memory region to utilize the charge retention characteristics of memory cells for data access, rather than relying on the electron tunneling effect of floating-gate transistors. Therefore, by using the volatile memory region as the carrier for runtime data storage, cell wear will not occur during high-frequency firmware configuration parameter reads and writes, thus fundamentally eliminating the risk of hardware failure caused by the aging of non-volatile flash memory chips. Simultaneously, the write operation of the volatile memory does not require page erasure and full-page write processes, supporting direct overwrite, significantly improving data update efficiency.

[0085] Step S200: When the basic input / output system is in the first startup phase, control the basic input / output system to read the first firmware configuration data in the firmware configuration data required in the shared storage area using the first communication interface, so as to configure the data transmission firmware required by the second communication interface based on the first firmware configuration data.

[0086] The first startup phase corresponds to the Pre-EFI Initialization (PEI) phase in the Unified Extensible Firmware Interface (UEFI) specification. During this phase, high-speed peripherals such as the server's PCIe bus have not yet completed initialization and training, and therefore cannot directly use high-bandwidth communication channels. Consequently, the Basic Input / Output System interacts with the baseboard management controller through the first communication interface.

[0087] The basic input / output system sends a variable read request through the first communication interface. The baseboard management controller responds to the request and retrieves the corresponding first firmware configuration data from the shared storage area and returns it.

[0088] The first firmware configuration data refers to the critical configuration parameters used to initialize the core system hardware, such as memory timing parameters, processor microcode version, PCIe port enable status, and link width configuration. These data are prerequisites for the subsequent normal operation of the high-speed bus. Therefore, the first firmware configuration data contains the key parameters necessary to establish a high-speed path.

[0089] In some implementations, the first firmware configuration data is a subset logically segmented from the full firmware configuration data, and the segmentation principle is based on the minimum dataset of configuration parameters of the firmware required to configure the second communication interface for data transmission.

[0090] The aforementioned data transmission firmware refers to the firmware module in the basic input / output system used for high-speed data transmission through the second communication interface. The specific form of the data transmission firmware depends on the specific implementation of the second communication interface.

[0091] For example, when the second communication interface is the MMIO area based on the PCIe bus, the data transmission firmware can be a PCIe bus initialization driver, a PCIe bus-based DMA (Direct Memory Access) transfer driver, or a data transfer firmware based on MMIO address mapping, etc.; when the second communication interface is other high-speed interfaces, the data transmission firmware corresponds to the corresponding firmware module that provides data path establishment and data transfer capabilities for that interface.

[0092] Therefore, the purpose of reading the first firmware configuration data in this implementation step is to complete the configuration and loading of the aforementioned data transmission firmware, thereby creating conditions for the subsequent establishment of the second communication interface. By using the low-dependency first communication interface to obtain the key parameters necessary for the high-speed path during the first startup phase, the system can quickly complete the initialization of the high-speed bus driver under limited hardware resources, ensuring a smooth switch to the high-bandwidth path in subsequent phases.

[0093] In step S300, when the basic input / output system is in the second startup phase, the basic input / output system is controlled to switch to the second communication interface, and the data transmission firmware is called using the second communication interface to continue reading the second firmware configuration data in the shared storage area. The communication efficiency of the second communication interface is higher than that of the first communication interface.

[0094] The second firmware configuration data consists of other firmware configuration data besides the first firmware configuration data. For example, the second firmware configuration data may include non-critical initialization parameters such as operating system boot options, network boot configuration, fan policy tables, and asset tag information, or runtime variables that need to be frequently updated during system operation.

[0095] The second startup phase corresponds to the Driver Execution Environment (DXE) phase in the UEFI specification. During this phase, the PCIe bus has completed its training and is ready for use.

[0096] To handle the need to read a large amount of remaining configuration data, the system switched the communication path from the first communication interface to the second communication interface.

[0097] The first firmware configuration data and the second firmware configuration data are divided according to the timing dependencies of each configuration parameter on hardware initialization during the startup process of the basic input / output system.

[0098] Specifically, the criterion for determining whether a piece of firmware configuration data belongs to the first firmware configuration data or the second firmware configuration data is: whether the configuration parameter is a necessary prerequisite for the second communication interface to complete initialization. If a configuration parameter is a necessary input for operations such as PCIe bus training, link enumeration, or MMIO address space allocation, then the parameter belongs to the first firmware configuration data and must be obtained through the first communication interface during the first startup phase; conversely, if the reading and use of a configuration parameter does not presuppose the readiness of the second communication interface, or if its use occurs after the second communication interface has become available, then the parameter is classified as the second firmware configuration data.

[0099] For example, memory timing parameters (such as DDR frequency, tCL / tRCD / tRP timing values, etc.) directly determine whether the system memory can be initialized normally, and memory availability is a prerequisite for the PCIe controller to complete link training. Therefore, memory timing parameters belong to the first firmware configuration data. Similarly, the enable status and link width configuration of PCIe ports (such as x4 / x8 / x16) directly determine which PCIe ports participate in enumeration and in what topology training mode. These parameters also belong to the first firmware configuration data. In contrast, parameters such as operating system boot order, network boot (PXE) configuration, fan speed policy table, and asset tag strings, although also configuration data that needs to be loaded during the basic input / output system startup process, are read and used only after the PCIe bus is ready. They do not constitute a prerequisite for the initialization of the second communication interface, and therefore are all classified as second firmware configuration data.

[0100] In some implementations, the second communication interface is specifically implemented as a Memory Mapped I / O (MMIO) region mapped via the Peripheral Component Interconnect Bus (PCIe). After completing PCIe initialization, the Basic Input / Output System (BIOS) sends a configuration request to the Baseboard Management Controller (BMC). The BMC responds to this request by mapping the physical address of the shared memory area into the PCIe address space. The BIOS driver redirects the access pointer to this MMIO region, translating read operations on firmware configuration data into direct memory access instructions.

[0101] Compared to the message polling or interrupt-triggered mode of the first communication interface, the second communication interface can support burst transmission and zero-copy access, and its effective bandwidth can be increased from the KB / s level to the GB / s level, resulting in an order-of-magnitude increase in communication efficiency.

[0102] This phased, differentiated interface access strategy ensures compatibility in the early stages of startup while fully unleashing hardware performance in the later stages, significantly shortening the overall startup time.

[0103] It should be noted that although this embodiment uses PCIe's MMIO as an example of the second communication interface, in other embodiments, USB, NVMe over Fabric, or other high-speed interfaces with direct memory access capabilities can also be used, as long as their communication efficiency meets the requirements of the first communication interface and can achieve the same data transmission function. In some embodiments, during the execution of steps S200 and S300, the basic input / output system or the baseboard management controller locates and accesses specific variable data based on the variable index table, without needing to perform a full scan of the entire shared memory area.

[0104] The variable index table functions similarly to the directory structure of a file system. By mapping identifiers to offset addresses, it reduces the time complexity of variable lookup operations from linear traversal to index lookup operations, significantly improving the retrieval efficiency of a large number of variables.

[0105] The above embodiments construct a technical architecture that decouples runtime read / write operations from persistent storage. On one hand, volatile shared storage is used to carry hot data, isolating it from wear and tear on non-volatile media. On the other hand, dynamic switching of the two-stage interface achieves optimal matching of configuration data access efficiency throughout the entire startup process. This implementation not only extends the lifespan of the server motherboard's storage devices but also ensures that configuration data can be acquired with the highest efficiency under current hardware conditions at different startup stages, improving the overall startup performance and reliability of the system.

[0106] Based on the above embodiments, in order to ensure the security and recoverability of configuration data under power failure or abnormal scenarios, the following step S400 is specifically implemented to back up the data in the non-volatile area during or after the execution of the above steps S200 and S300.

[0107] S400, when it detects that the firmware configuration data in the shared storage area meets the update write conditions, controls the baseboard management controller to write the firmware configuration data in the shared storage area into the non-volatile storage medium of the baseboard management controller.

[0108] The above update write conditions do not mean that a write operation is triggered immediately every time data changes, but rather a comprehensive judgment based on a set of preset strategy parameters.

[0109] In some implementation examples, update write conditions may specifically include one or more of the following: the dirty flag is set, the timed synchronization period is reached, or the amount of data change reaches a preset threshold.

[0110] The following provides a further explanation of the specific logic for determining the update write conditions.

[0111] In one implementation scenario, an incremental change threshold can be used as a trigger condition. That is, when the number of configuration variables that have changed in the shared storage area since the last successful backup exceeds a preset number threshold (e.g., 10), or the total amount of changed data exceeds a preset size threshold (e.g., 4KB), it is determined that the update write condition is met.

[0112] This approach can combine multiple small, scattered write requests into a single large-scale batch write, significantly reducing the number of I / O operations on the non-volatile storage medium 12.

[0113] In another implementation scenario, a time window can be used as the trigger condition, that is, a minimum write interval (such as 30 seconds or 60 seconds) is set. Even if the configuration data changes multiple times during this period, the system will only perform a write operation once at the end of the time window.

[0114] In another implementation scenario, the system load status can be used to make a judgment, and the write operation will only be performed when the CPU utilization rate is lower than a preset threshold or the bus is idle, so as to avoid the backup operation from occupying system resources and affecting the normal business performance of the server.

[0115] In some implementations, the non-volatile storage medium may specifically be an eMMC chip, SPI NOR Flash, UFS storage device, or other storage units with power-loss retention capabilities. Furthermore, the firmware configuration data written to the non-volatile storage medium can be stored in a backup file on the non-volatile storage medium.

[0116] When performing a write operation, the baseboard management controller reads the current firmware configuration data from the shared memory area and converts it into a format suitable for persistent storage, such as a structured format, to store the firmware configuration data written to non-volatile storage media.

[0117] For example, the firmware configuration data is serialized into a text file using JavaScript Object Notation (JSON) format and then written to a backup file on a non-volatile storage medium, so that each piece of firmware configuration data is recorded in key-value pairs and includes information such as version number, timestamp, and attribute identifier.

[0118] Compared to binary image formats, structured format data can be directly read and edited to perform configuration repairs or version comparisons without relying on specific binary parsing tools. At the same time, structured format can support incremental updates and difference comparisons, allowing the baseboard management controller to write only the changed fields when performing backups, further reducing the write / erase pressure on the non-volatile storage media in the baseboard management controller.

[0119] The aforementioned asynchronous backup mechanism achieves an effective balance between data security and storage media lifespan. On one hand, the shared storage area, acting as a runtime cache, handles all real-time read and write pressure, ensuring that BIOS configuration access efficiency is unaffected by the low-speed characteristics of non-volatile storage media. On the other hand, the condition-triggered asynchronous write strategy reduces flash memory erase and write operations, which could have been as high as tens of times per second, to a few times per minute or even less, significantly extending the lifespan of non-volatile storage media.

[0120] Based on the embodiments, the following steps are performed to further explain the process of writing firmware configuration data to the shared storage area of ​​the baseboard management controller in the above implementation step S100, specifically including the following two scenarios of adaptation processing.

[0121] The first method involves controlling the baseboard management controller to write the firmware configuration data from the non-volatile storage medium to the shared storage area when the server's power-on signal is determined to be a power-down restart signal.

[0122] Based on the data backup process in the above embodiments, the power-off restart signal typically corresponds to a hot start or warm start scenario where the server's AC power supply is not disconnected, or the baseboard management controller remains running. In this scenario, the baseboard management controller, as an independent management unit, starts earlier than the basic input / output system. After completing its own initialization, the baseboard management controller actively reads the previously successfully backed-up firmware configuration data file (such as a JSON-formatted NVRAM variable backup) from non-volatile storage media (such as an eMMC chip), parses and converts it into a binary data stream, and loads it into the shared storage area. This processing method utilizes the baseboard management controller's first-mover advantage, completing the preheating of runtime configuration data before the basic input / output system begins performing POST self-tests.

[0123] Compared to directly reading the motherboard flash memory via the Basic Input / Output System (PIS), this embodiment replaces the slow SPI bus reading with memory-level data transfer, significantly shortening the waiting time in the early stages of startup. Furthermore, since the data in the non-volatile storage medium is a verified and valid backup, direct access to the motherboard flash memory NVRAM area, which may be unstable due to abnormal power loss, is avoided, improving the reliability of system recovery.

[0124] The second method involves controlling the Basic Input / Output System (BIOS) to read the default firmware configuration data from the BIOS motherboard flash memory when the server power-on signal is determined to be the initial power-on signal. The read default firmware configuration data is then copied to the shared storage area.

[0125] The initial power-on signal typically corresponds to the server's first power-on after leaving the factory, a cold start after the AC power is completely disconnected, or the first boot after a firmware upgrade / factory reset. In these scenarios, valid backup data may not exist in the non-volatile storage medium, or the existing backup data may be incompatible with the current firmware version (e.g., the variable structure changes after a firmware upgrade). To prevent the spread of dirty data that could cause the system to fail to boot or malfunction, this embodiment designs a safety fallback path independent of the baseboard management controller's backup mechanism. In this case, the basic input / output system does not rely on the preset data in the shared storage area, but directly accesses the default configuration area (Default Store) embedded in the motherboard flash memory, reads the verified factory default parameters, and actively writes them to the shared storage area to complete the initialization of the operating environment. Based on this, it ensures that even in extreme cases where the baseboard management controller's backup mechanism fails or data is corrupted, the server can still boot based on reliable default values, greatly enhancing the system's environmental adaptability and robustness.

[0126] Through the data source adaptation mechanism described above for dual power-on scenarios, this embodiment builds a robust data security defense while ensuring startup efficiency. In normal power-down restart scenarios, the system fully utilizes backup data in non-volatile storage media for rapid recovery, maximizing the cache value of the shared storage area. In initial power-on or abnormal scenarios, the system automatically switches to the default loading path of the motherboard flash memory, cutting off potential sources of erroneous data. This dynamic adaptation strategy resolves the technical contradiction between startup speed and data security in traditional single-data source solutions, ensuring that the server can stably and efficiently complete the startup process under various complex operating conditions.

[0127] Based on the above embodiments, a data closed-loop processing mechanism for firmware upgrade or factory reset scenarios is provided by performing the following steps.

[0128] First, in response to a firmware upgrade or factory reset operation performed by the basic input / output system, a reset flag is set in the shared storage area.

[0129] The reset flag is the trigger signal for the system to enter the configuration rebuild process. Its physical location is typically in a specific status register or flag field within the header information area of ​​the shared memory region. The reset flag can be set when the firmware upgrade tool completes code flashing and triggers a Software System Management Interrupt (SMI), or by the baseboard management controller 10 actively writing it upon detecting an external forced recovery command. This flag explicitly indicates that the current configuration environment is in an untrusted or uninitialized state, blocking the normal data loading path and preventing conflicts between old configuration parameters and new firmware code.

[0130] Secondly, in response to the reset flag, the basal input / output system reads the default firmware configuration data from the basal input / output system's motherboard flash memory and copies the read default firmware configuration data to the shared storage area.

[0131] At this stage, the Basic Input / Output System (BIOS) no longer attempts to restore historical user configurations from shared memory or non-volatile storage media. Instead, it directly accesses the default configuration store embedded in the motherboard's flash memory. This is because the original configuration data structure may have changed during firmware upgrades or factory resets, or users may want to completely erase personalized settings. By forcibly reverting to verified factory defaults, the risk of boot anomalies caused by incompatible variable structures, out-of-bounds parameters, or logical conflicts can be eliminated at the source. After the copy operation is complete, the shared memory is filled with a clean configuration base that is fully compatible with the current firmware version.

[0132] Third, the control board management controller copies the default firmware configuration data from the shared storage area to a non-volatile storage medium.

[0133] This step persists the clean configuration in memory, overwriting any old or corrupted backup files that may exist on the non-volatile storage media. The baseboard management controller, acting as an independent background management unit, handles the data transfer, allowing the basic input / output system to continue the boot process without waiting for slow flash write operations, thus minimizing the impact of the reset process on the user's perceived boot speed. During the copying process, the baseboard management controller can use a full-overwrite method to ensure strict consistency between the data on the non-volatile storage media and the shared storage area.

[0134] Fourth, when it is detected that the default firmware configuration data read in the shared storage area is not updated and is completely copied to non-volatile storage media, a data completion flag is set in the shared storage area, and a reset flag is deleted from the shared storage area.

[0135] The absence of updates is a crucial stability criterion. While performing replication, the baseboard management controller continuously monitors the data version number or dirty flag of the shared memory area. If, during the replication window, the shared memory area is detected to have been modified again by another process (such as a driver currently initializing), it indicates that the system has not yet reached a steady state. Data written to the non-volatile storage medium at this time may be in an intermediate state or incomplete. Therefore, the system will pause or restart the replication count until it confirms that the shared memory area remains static and data transmission verification passes within a preset time threshold, at which point synchronization is considered successful. Only after this stringent condition is met will the system atomically execute the operations of setting the completion flag and clearing the reset flag. This dual-state confirmation mechanism constructs a reliable state machine closed loop, effectively avoiding inconsistencies between the state flags and actual data caused by asynchronous write contention or unexpected interruptions. This ensures that the server can accurately identify that the configuration has returned to normal upon the next power-on, thus smoothly entering the normal power-off restart recovery process.

[0136] It should be understood that although this embodiment describes a specific state transition sequence based on a reset flag and a completion flag, in other embodiments, a state counter, timestamp comparison, or other equivalent state tracking mechanism may be used to implement the same closed-loop control logic. As long as it can achieve the core functions of triggering reset, loading default, secure synchronization, and confirming completion, it should be covered within the protection scope of this application.

[0137] Through the aforementioned closed-loop state machine design, this embodiment provides deterministic configuration data assurance for high-risk operations such as firmware upgrades and factory resets, significantly improving the reliability and security of server operation and maintenance.

[0138] Based on the above embodiments, this embodiment further provides a power-on signal joint determination mechanism based on dual flags through the following steps to accurately distinguish the server startup scenario.

[0139] The first method determines the server power-on signal as the initial power-on signal when a reset flag is detected in the shared storage area or no data completion flag is detected in the non-volatile storage medium.

[0140] The second approach is to determine that the server power-on signal is a power-down restart signal when no reset flag is detected in the shared storage area and a data completion flag is detected in the non-volatile storage medium.

[0141] In some implementation examples, the joint decision logic is typically executed within a window period immediately after the server completes its power-on reset and before the Basic Input / Output System (PIS) begins loading configuration data. The executing entity can be the baseboard management controller or the PIS, which queries the first communication interface early in the PEI phase.

[0142] In this implementation, an asymmetric logic verification model is constructed: The initial power-on signal is determined using OR logic, meaning that if either a reset flag exists in the shared memory area or a data completion flag is missing in the non-volatile storage medium, the system is considered untrusted and the initialization process of loading default values ​​from the motherboard flash memory must be forcibly executed. However, the power-off restart signal is determined using strict AND logic, requiring both conditions to be met simultaneously: no reset flag exists in the shared memory area and a valid data completion flag exists in the non-volatile storage medium. Only then is the system allowed to recover user configuration data from the non-volatile storage medium.

[0143] In this asymmetric joint determination method, on the one hand, the shared storage area, as a volatile storage area, loses its data after a power outage. The presence of a reset flag clearly indicates that there is an incomplete configuration rebuild task or firmware upgrade operation. In this case, regardless of the backup status in the non-volatile storage medium, the reset request must be responded to first to prevent the old configuration from overwriting the new environment. On the other hand, the data completion flag in the non-volatile storage medium is the final proof of the backup data integrity. If this flag is missing, it means that the previous backup process may have been interrupted due to an unexpected power outage or write error. In this case, even if there is no reset flag in the shared storage area, the data in the non-volatile storage medium cannot be trusted, and a fallback to the safe default configuration path is necessary. Only when both independent storage domains return normal signals is the system certain that the current operating environment is stable and consistent, thus enabling the fast recovery path.

[0144] Compared to methods that rely solely on a single flag bit for determination, the joint determination mechanism in this embodiment effectively avoids the risk of misjudgment caused by single-point failures. For example, if the determination is based solely on the state of the shared storage area, in the event of an abnormal power outage leading to data loss in the shared storage area, the system may mistakenly identify a power outage restart scenario that should restore user configuration as an initial power-on, resulting in the unexplained loss of user-customized settings. Conversely, if the determination is based solely on the state of the non-volatile storage medium, in the extreme case where an interruption occurs during backup writing, resulting in data corruption but the completion flag has not yet been cleared, the system may mistakenly load the corrupted configuration data, leading to startup failure.

[0145] Therefore, by cross-validating the dynamic state of the volatile domain with the persistent state of the non-volatile domain, a double-layered defense is constructed to ensure the determinism and robustness of the state machine transitions.

[0146] It should be noted that although this embodiment uses a Boolean flag as an example for determination, in other embodiments, the reset flag and data completion identifier can also be implemented using version numbers, timestamps, or monotonically increasing sequence numbers. For example, an explicit completion identifier can be replaced by comparing whether the configuration version number in the shared storage area is consistent with the backup version number in the non-volatile storage medium, or the existence of incomplete reset operations can be determined by detecting changes in the reset counter.

[0147] Furthermore, the execution location of the judgment logic can be flexibly adjusted according to the system architecture. It can be that the baseboard management controller completes the judgment in the background and directly notifies the basic input / output system of the result, or the basic input / output system can actively read the two flag bits and make its own decision. As long as the joint state recognition function based on dual-source information can be realized, it should be covered within the protection scope of this application.

[0148] Based on the above embodiments, as one implementation method, the specific form of the first communication interface and the second communication interface and the switching implementation process are further explained.

[0149] The first communication interface includes a mailbox message channel; the second communication interface includes a memory-mapped input / output area based on a high-speed bus mapping of peripheral component interconnection.

[0150] In this embodiment, the Mailbox Message Channel (SIO Mailbox) specifically refers to an out-of-band communication mechanism implemented based on a Low Pin Count (LPC) bus or an Enhanced Serial Peripheral Interface (eSPI) bus. It sends and receives commands and data through specific IO port addresses, and has the characteristics of low dependence on the core hardware resources of the system, making it suitable for low-speed interaction scenarios in the early stages of startup.

[0151] However, the high-speed bus-mapped memory input / output area (PCIe MMIO) based on peripheral component interconnection refers to using the base address register (BAR) of the PCIe bus to map the shared memory area inside the baseboard management controller into a physical memory space that the CPU can directly address, supporting high-bandwidth memory read and write instruction access. This combination of heterogeneous interfaces fundamentally solves the contradiction between hardware resource readiness timing and data access efficiency requirements during server startup.

[0152] The following steps, S300, further explain the specific triggering and control process for interface switching. When the basic input / output system is in the second startup phase, controlling the basic input / output system to switch to the second communication interface specifically includes the following steps.

[0153] First, after completing the high-speed bus initialization operation, the basic input / output system sends a configuration request to the baseboard management controller.

[0154] The aforementioned high-speed bus initialization operation refers to the PCIe link training and enumeration process. Only when the PCIe link is stable and bus resources are allocated can the physical basis for establishing an MMIO path be established. After confirming the PCIe subsystem is ready, the Basic Input / Output System (BIOS) sends a specific configuration request message to the baseboard management controller via the established mailbox message channel or PCIe configuration space. This request message can carry parameters such as the desired shared memory area size and alignment requirements, serving as a handshake signal to negotiate the establishment of a high-speed data channel.

[0155] It should be understood that although this embodiment uses the completion of PCIe link training as the trigger condition for sending the configuration request, in other embodiments, the triggering time can also be set to the completion of DXE core service loading or the completion of a specific platform initialization protocol, as long as it is ensured that the high-speed bus is in a state where it can stably transmit data at this time.

[0156] Secondly, in response to a configuration request, the baseboard management controller maps the shared memory area to a memory-mapped input / output area on a high-speed bus.

[0157] Specifically, after parsing the mapping parameters in the configuration request, the baseboard management controller dynamically adjusts the value of its PCIe device-side BAR register, projecting the internal SRAM physical address window used to carry firmware configuration data into the server's PCIe address space.

[0158] The mapping process described above is completed autonomously by the baseboard management controller, without the CPU directly participating in the configuration of the underlying address decoding, thereby reducing the software complexity on the host side. Furthermore, after successful mapping, the shared memory area becomes a normal physical memory area for the CPU, which can access it through standard Load / Store instructions without having to go through cumbersome I / O port operations or message encapsulation / decapsulation processes.

[0159] It is worth noting that the size and location of the MMIO region can be dynamically negotiated or fixed values ​​agreed upon in advance in the firmware of both parties; this application does not impose any restrictions on this.

[0160] Third, the default driver of the basic input / output system is invoked to switch the access path for firmware configuration data from the mailbox message channel of the first communication interface to the memory-mapped input / output area.

[0161] This implementation step is to complete the actual switching of access paths at the software level after the hardware-level mapping is completed.

[0162] The aforementioned pre-defined driver typically refers to the core driver module (such as the Variable Runtime Driver or NVRAM Service Module) responsible for managing NVRAM variables in a basic input / output system. Internally, this driver maintains an abstract Hardware Access Interface (HAL). During system startup, the underlying implementation of this HAL is bound to the read / write functions of the mailbox message channel. Upon receiving a notification of successful MMIO mapping, the driver atomically updates its internal function pointers or status flags, redirecting subsequent read / write requests to memory access functions in the MMIO region. This switching mechanism is completely transparent to upper-layer services. Whether it's the Setup UI, the Boot Manager, or the operating system runtime services, the standard UEFI interfaces such as GetVariable and SetVariable they call remain unchanged, without requiring awareness of changes to the underlying communication link.

[0163] Through this dual switching mechanism of hardware mapping and driver redirection, this embodiment achieves a seamless transition from low-speed I / O channels to high-speed memory channels. This ensures compatibility in the early stages of startup while fully unleashing the high throughput of the PCIe bus in the later stages, reducing the loading time of large amounts of firmware configuration data from seconds to milliseconds and significantly improving the overall startup performance of the server.

[0164] Based on the above embodiments, as one implementation method, after switching to the memory-mapped input / output area in step S300, the following steps can also be performed to implement the availability-related scheme of the second communication interface.

[0165] First, the basic input / output system is controlled to determine whether the second communication interface is available by reading the service status value of the preset service status register in the memory-mapped input / output area.

[0166] In a real-world server operating environment, the physical layer training, address space mapping, and PCIe endpoint device status within the baseboard management controller of the PCIe link may become abnormal due to electromagnetic interference, firmware timing deviations, or transient hardware failures. If the basic input / output system directly performs large-scale data reads and writes to the memory-mapped input / output area after switching, and if the area is not actually correctly mapped or the baseboard management controller cannot respond, the CPU may trigger a machine check exception or enter an infinite wait state, causing the system to hang.

[0167] Based on this, a lightweight handshake verification mechanism is introduced in some embodiments. The preset service status register is a read-only or read-write status field specifically allocated by the baseboard management controller in the header area of ​​the shared memory region, with its physical address located at a fixed offset in the memory-mapped input / output region. This register stores characteristic values ​​representing the service health status, such as a specific magic number, protocol version number, or ready flag. In its first operation after switching the access path to the second communication interface, the basic input / output system does not directly read the service configuration data, but instead prioritizes reading this preset service status register. The true availability of the second communication interface is comprehensively determined by judging whether the read service status value matches the predefined expected value, or whether the read operation completes and returns within a preset time threshold. This implementation concretizes the abstract concept of interface availability into a verifiable register status, providing a secure prerequisite for subsequent data transmission.

[0168] In some embodiments, an NVRAM variable index table is set in the area occupied by the Header of the shared memory area (which may be referred to as the Header area). The variable index table records the identifier of each NVRAM variable, its offset address in the shared memory area 40, its data length, and attribute information.

[0169] Secondly, if it is determined that the second communication interface is available, the access path remains unchanged on the second communication interface.

[0170] When the basic input / output system successfully reads the correct service status value without a timeout, it indicates that the PCIe endpoint of the baseboard management controller is functioning normally and the shared memory mapping is effective. At this point, the system maintains the current high-speed access path and continues to execute subsequent firmware configuration data loading tasks. This ensures that, under normal circumstances, the system can fully utilize the high bandwidth performance advantages provided by the second communication interface.

[0171] Third, if it is determined that the second communication interface is unavailable, the default driver of the basic input / output system is invoked to fall back the access path to the first communication interface.

[0172] In this implementation process, the conditions for determining unavailability include, but are not limited to, the following: read operation timeout (indicating that the PCIe link is down or the device is unresponsive), the read value is all 0s or all Fs (indicating that the address space is not decoded or is floating), or the read status value does not match the expected version (indicating that the baseboard management controller 10 firmware is abnormal or not ready). Once any of the above abnormal conditions are detected, the default driver of the basic input / output system will immediately trigger the fault degradation logic.

[0173] In some implementations, the driver internally maintains a dual-channel access function pointer table. Upon confirming the failure of the second communication interface, the driver atomically switches the active pointer from the memory-mapped I / O access function back to the mailbox message channel access function. Simultaneously, the system can log an error in memory, marking an interface rollback event during startup for subsequent maintenance analysis. After the rollback operation is complete, the Basic Input / Output System (PIS) transparently resumes using the first communication interface (i.e., SIO Mailbox) to read the remaining firmware configuration data. Although the first communication interface has a lower transmission rate, its LPC or eSPI bus-based communication mechanism boasts high maturity and stability, and does not rely on complex PCIe enumeration and mapping processes, thus serving as a reliable fallback channel.

[0174] Through the closed-loop control mechanism of detection, confirmation, and rollback described above, this embodiment builds the necessary defense depth for the interface switching process, effectively preventing system startup failure caused by single point of failure of high-speed interface, ensuring that the server can complete the minimum function boot under various abnormal conditions, and significantly improving the robustness of the product and user experience.

[0175] It should be understood that although this embodiment uses reading a specific register as the preferred method for availability detection, in other embodiments, methods such as writing test data to the memory-mapped input / output area and reading back for verification, or sending a Ping-Pong message with a timeout can also be used to verify interface connectivity. As long as the functions of fault detection and safe rollback can be achieved, they should be covered within the protection scope of this application.

[0176] Based on the above embodiments, as one implementation method, the process of writing firmware configuration data from a non-volatile storage medium to a shared storage area further includes the following integrity verification steps.

[0177] First, determine the hash checksum of the backup file.

[0178] The firmware configuration data is stored in a backup file on a non-volatile storage medium.

[0179] Secondly, the hash verification value is compared with the preset baseline verification value.

[0180] Third, when the comparison results indicate that the hash verification value matches the preset benchmark verification value, the firmware configuration data in the non-volatile storage medium is written to the shared storage area.

[0181] In this embodiment, the data integrity verification action is performed before the data enters the shared storage area, thereby building a security defense at the level of physical isolation.

[0182] In scenarios where the server loses power and restarts or recovers, after the baseboard management controller reads the backup file of the firmware configuration data (such as an NVRAM variable file in JSON format) from a non-volatile storage medium (such as an eMMC chip), it does not directly parse and move it to the shared storage area. Instead, it first performs a hash operation on all or part of the key contents of the backup file in the memory buffer.

[0183] The hash algorithm mentioned above can be any digest algorithm that can characterize the uniqueness of data, such as SHA-256, MD5, or CRC32.

[0184] The hash verification value calculated above represents the current actual state of the backup file.

[0185] Furthermore, the system uses a preset benchmark check value as a trusted reference. By comparing the actual calculated hash check value with the preset benchmark check value, the system can accurately determine whether the backup file has undergone bit flipping, file system corruption, or unauthorized tampering during static storage.

[0186] The storage location of the preset benchmark verification value can be implemented in several ways: for example, it can be stored in the header metadata area of ​​the backup file and calculated and appended by the writer when the file is generated; or, it can be stored independently in a protected partition of a non-volatile storage medium; or, it can be stored in a read-only memory or security chip inside the baseboard management controller.

[0187] In this embodiment, when the comparison result indicates that the two are completely consistent, the baseboard management controller determines that the backup file is trustworthy, and then performs subsequent parsing and writing operations to load the firmware configuration data into the shared storage area for use by the basic input / output system. Conversely, if the comparison result is inconsistent, the backup file is determined to be corrupted or untrustworthy, and the system will immediately terminate the writing operation to the shared storage area and automatically trigger a fault tolerance mechanism, such as reverting to the process of loading default firmware configuration data from the motherboard flash memory described in the above embodiment.

[0188] This pre-blocking implementation method, which verifies before writing, effectively cuts off the propagation path of corrupted data to the runtime environment. Furthermore, since the shared memory area is a volatile storage region and serves as the configuration data source during the startup process of the Basic Input / Output System (BIOS), if incorrect configuration parameters are written and read by the BIOS, it can lead to serious faults such as memory training failure, PCIe enumeration anomalies, or even processor microcode loading errors. Such faults are often difficult to locate using conventional methods.

[0189] Therefore, by implementing strict integrity checks at the final checkpoint before data is injected into the shared storage area, it is ensured that every bit of configuration data entering runtime memory is verified and clean, thereby significantly improving the determinism and reliability of the server startup process.

[0190] It should be understood that although this embodiment uses hash verification as the implementation method for integrity verification, digital signature verification, cyclic redundancy check (CRC) or other equivalent data digest techniques may also be used in other embodiments. As long as the function of identifying and intercepting corrupted data before writing to the shared storage area can be achieved, they should all be covered within the protection scope of this application.

[0191] To achieve the above functions, the firmware configuration data processing device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art will readily recognize that, based on the algorithmic steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0192] This disclosure also provides an embodiment such as Figure 3 The firmware configuration data processing device shown is applied to a server that includes a baseboard management controller and a basic input / output system. The device includes the following modules.

[0193] The data read / write module 31 is configured to write the firmware configuration data required by the basic input / output system to the shared storage area of ​​the baseboard management controller when the server is powered on; the shared storage area is a volatile storage area.

[0194] The first interface calling module 32 is configured to control the basic input / output system when the basic input / output system is in the first startup phase, and use the first communication interface to read the first firmware configuration data in the firmware configuration data required in the shared storage area, so as to configure the data transmission firmware required by the second communication interface based on the first firmware configuration data.

[0195] The second interface calling module 33 is configured to control the basic input / output system to switch to the second communication interface when the basic input / output system is in the second startup phase, and use the second communication interface to call the data transmission firmware to continue reading the second firmware configuration data in the shared storage area; the communication efficiency of the second communication interface is higher than that of the first communication interface.

[0196] In one embodiment, the data backup module 34 is configured to control the baseboard management controller to write the firmware configuration data in the shared storage area into the non-volatile storage medium of the baseboard management controller when the firmware configuration data in the shared storage area is detected to meet the update write conditions.

[0197] In one implementation, the data read / write module 31 is specifically configured to: when it is determined that the server power-on signal is a power-down restart signal, control the baseboard management controller to write the firmware configuration data in the non-volatile storage medium into the shared storage area; when it is determined that the server power-on signal is an initial power-on signal, control the basic input / output system to read the default firmware configuration data from the motherboard flash memory of the basic input / output system, and copy the read default firmware configuration data to the shared storage area.

[0198] In one embodiment, the data backup module 34 is further configured to: set a reset flag in the shared storage area in response to the Basic Input / Output System (PIOS) performing a firmware upgrade operation or a factory reset operation; the PIOS, in response to the reset flag, read default firmware configuration data from the PIOS motherboard flash memory and copy the read default firmware configuration data to the shared storage area; and control the board management controller to copy the read default firmware configuration data in the shared storage area to a non-volatile storage medium; when it is detected that the read default firmware configuration data in the shared storage area has not been updated and has been completely copied to the non-volatile storage medium, set a data completion flag in the shared storage area and delete the reset flag in the shared storage area.

[0199] In one implementation, the data read / write module 31 is further configured to: determine the server power-on signal as an initial power-on signal when a reset flag is detected in the shared storage area or a data completion flag is not detected in the non-volatile storage medium; and determine the server power-on signal as a power-down restart signal when a reset flag is not detected in the shared storage area and a data completion flag is detected in the non-volatile storage medium.

[0200] In one embodiment, the first communication interface includes a mailbox message channel; the second communication interface includes a memory-mapped input / output area mapped by a high-speed bus based on peripheral component interconnection; the second interface calling module 33 is specifically configured to: control the basic input / output system to send a configuration request to the baseboard management controller after completing the high-speed bus initialization operation; the baseboard management controller responds to the configuration request by mapping the shared memory area to a memory-mapped input / output area on the high-speed bus; and calls the preset driver of the basic input / output system to switch the access path for firmware configuration data from the mailbox message channel of the first communication interface to the memory-mapped input / output area.

[0201] In one implementation, after switching to the memory-mapped input / output region, the second interface calling module 33 is further configured to: control the basic input / output system to determine whether the second communication interface is available by reading the service status value of the preset service status register in the memory-mapped input / output region; if the second communication interface is available, keep the access path unchanged on the second communication interface; if the second communication interface is unavailable, call the preset driver of the basic input / output system to fall back the access path to the first communication interface.

[0202] In one embodiment, the data backup module 34 is further configured to: determine the hash check value of the backup file, wherein the firmware configuration data is stored in the backup file in the non-volatile storage medium; compare the hash check value with a preset benchmark check value; and when the comparison result indicates that the hash check value is consistent with the preset benchmark check value, write the firmware configuration data in the non-volatile storage medium into the shared storage area.

[0203] Regarding the apparatus in the above embodiments, the specific manner in which each unit module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0204] Figure 4 This is a schematic diagram of a server provided in this application. Figure 4 The server 50 may include at least one first processor 501 and a memory 503 for storing processor-executable instructions. The first processor 501 is configured to execute instructions in the memory 503 to implement the firmware configuration data processing method described in the following embodiments.

[0205] In addition, server 50 may also include communication bus 502, at least one communication interface 504, input device 506 and output device 505.

[0206] The first processor 501 may be a processor (central processing unit, CPU), a microprocessor unit, an ASIC, or one or more integrated circuits for controlling the execution of programs according to the present application.

[0207] The communication bus 502 may include a path for transmitting information between the aforementioned components.

[0208] Communication interface 504 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0209] Input device 506 is used to receive input signals and output device 505 is used to output signals.

[0210] Memory 503 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed discs, laser discs, optical discs, digital universal discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory may exist independently and be connected to the processing unit via a bus. Memory may also be integrated with the processing unit.

[0211] The memory 503 stores instructions for executing the scheme of this application, and the execution is controlled by the first processor 501. The first processor 501 executes the instructions stored in the memory 503 to realize the functions of the method of this application.

[0212] In a specific implementation, as one example, the first processor 501 may include one or more CPUs, for example... Figure 4 CPU0 and CPU1 in the CPU.

[0213] In a specific implementation, as one example, server 50 may include multiple processors, for example... Figure 4 The first processor 501 and the second processor 507 are described. Each of these processors can be a single-core processor or a multi-core processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0214] The server is as follows Figure 4 The diagram includes a first processor 501 and a memory 503 for storing executable instructions of the first processor 501. The first processor 501 is configured to execute the executable instructions to implement the firmware configuration data processing method as described in any of the possible embodiments above. Since the same technical effects can be achieved, further details are omitted here to avoid repetition.

[0215] This application also provides a computer-readable storage medium, which, when the instructions in the computer-readable storage medium are executed by the processor of a firmware configuration data processing device or electronic device, enables the firmware configuration data processing device or electronic device to perform the firmware configuration data processing method as described in any of the possible embodiments above. And it can achieve the same technical effect; to avoid repetition, it will not be described again here.

[0216] This application also provides a computer program product, including a computer program or instructions, which are executed by a processor using a firmware configuration data processing method as described in any of the possible implementations above. This achieves the same technical effects, and to avoid repetition, will not be repeated here.

[0217] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0218] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A firmware configuration data processing method, characterized in that, The method, applied to a server comprising a baseboard management controller and a basic input / output system, includes: When the server is powered on, it writes the firmware configuration data required by the basic input / output system to the shared memory area of ​​the baseboard management controller; the shared memory area is a volatile storage area. When the basic input / output system is in the first startup phase, the basic input / output system is controlled to read the first firmware configuration data in the firmware configuration data required in the shared storage area using the first communication interface, so as to configure the data transmission firmware required by the second communication interface based on the first firmware configuration data. When the basic input / output system is in the second startup phase, the basic input / output system is controlled to switch to the second communication interface, and the data transmission firmware is called through the second communication interface to continue reading the second firmware configuration data in the shared storage area; the communication efficiency of the second communication interface is higher than that of the first communication interface.

2. The method according to claim 1, characterized in that, The method further includes: If the firmware configuration data in the shared storage area is detected to meet the update write conditions, the baseboard management controller is controlled to write the firmware configuration data in the shared storage area into the non-volatile storage medium of the baseboard management controller.

3. The method according to claim 2, characterized in that, When the server is powered on, it writes the firmware configuration data required by the basic input / output system to the shared storage area of ​​the baseboard management controller, including: When it is determined that the power-on signal of the server is a power-down restart signal, the baseboard management controller is controlled to write the firmware configuration data in the non-volatile storage medium into the shared storage area; When the server power-on signal is determined to be the initial power-on signal, the system controls the basic input / output system to read the default firmware configuration data from the motherboard flash memory of the basic input / output system and copy the read default firmware configuration data to the shared storage area.

4. The method according to claim 3, characterized in that, The method includes: In response to the basic input / output system performing a firmware upgrade or factory reset operation, a reset flag is set in the shared storage area; In response to the reset flag, the basic input / output system reads default firmware configuration data from the motherboard flash memory of the basic input / output system and copies the read default firmware configuration data to the shared storage area; And, control the baseboard management controller to copy the read default firmware configuration data in the shared storage area to the non-volatile storage medium; When it is detected that the read default firmware configuration data in the shared storage area has not been updated and has been completely copied to the non-volatile storage medium, a data completion flag is set in the shared storage area, and the reset flag in the shared storage area is deleted.

5. The method according to claim 4, characterized in that, The method further includes: When the reset flag is detected in the shared storage area or the data completion flag is not detected in the non-volatile storage medium, the server power-on signal is determined to be the initial power-on signal; When the reset flag is not detected in the shared storage area and the data completion flag is detected in the non-volatile storage medium, the power-on signal of the server is determined to be the power-off restart signal.

6. The method according to any one of claims 1 to 5, characterized in that, The first communication interface includes a mailbox message channel; the second communication interface includes a memory-mapped input / output area based on a high-speed bus mapping of peripheral component interconnection. When the basic input / output system is in the second startup phase, controlling the basic input / output system to switch to the second communication interface includes: After completing the high-speed bus initialization operation, the basic input / output system sends a configuration request to the baseboard management controller. In response to the configuration request, the baseboard management controller maps the shared memory area to a memory-mapped input / output area on the high-speed bus; The preset driver of the basic input / output system is invoked to switch the access path for firmware configuration data from the mailbox message channel of the first communication interface to the memory-mapped input / output area.

7. The method according to claim 6, characterized in that, After switching to the memory-mapped input / output region, the method further includes: The basic input / output system is controlled to determine whether the second communication interface is available by reading the service status value of the preset service status register in the memory-mapped input / output area. If it is determined that the second communication interface is available, then the access path remains unchanged on the second communication interface; If it is determined that the second communication interface is unavailable, the preset driver of the basic input / output system is invoked to fall back the access path to the first communication interface.

8. The method according to any one of claims 1 to 5, characterized in that, The step of writing the firmware configuration data from the non-volatile storage medium into the shared storage area includes: Determine the hash check value of the backup file, wherein the firmware configuration data is stored in the backup file on the non-volatile storage medium; The hash verification value is compared with the preset baseline verification value; When the comparison results indicate that the hash verification value matches the preset benchmark verification value, the firmware configuration data in the non-volatile storage medium is written to the shared storage area.

9. A firmware configuration data processing apparatus for performing the firmware configuration data processing method as described in any one of claims 1-8, characterized in that, A device for use in a server comprising a baseboard management controller and a basic input / output system, the device comprising: The data read / write module is configured to write the firmware configuration data required by the basic input / output system to the shared memory area of ​​the baseboard management controller when the server is powered on; the shared memory area is a volatile storage area. The first interface calling module is configured to control the basic input / output system to read the first firmware configuration data in the firmware configuration data required in the shared storage area when the basic input / output system is in the first startup phase, and to configure the data transmission firmware required by the second communication interface based on the first firmware configuration data. The second interface calling module is configured to control the basic input / output system to switch to the second communication interface when the basic input / output system is in the second startup phase, and use the second communication interface to call the data transmission firmware to continue reading the second firmware configuration data in the shared storage area; the communication efficiency of the second communication interface is higher than that of the first communication interface.

10. A server, characterized in that, It includes the following components: a baseboard management controller and a basic input / output system, configured to control the server, including each of the components, to perform the firmware configuration data processing method as described in any one of claims 1-8.

Images