Pre-boot execution environment driver loading method and electronic device

Abstract

The application discloses a pre-start execution environment driving loading method and electronic equipment, relates to the technical field of network communication, and comprises the following steps: after a network card driving file is acquired, a core module is decompiled, screened and optimized in a light weight mode, basic input and output system and unified extensible firmware interface dual-environment adaptation is completed, an option read-only memory image is integrated and generated, and the image is written to the network card; and when starting, the image is directly called to load the adaptive driving. Through the dual-environment adaptation design, the environment difference is eliminated, the driving is integrated into the network card firmware to get rid of the dependence on the operating system, and the problems of insufficient adaptation compatibility, system dependence, starting interruption or failure in the prior art are solved, so that the effects of improving the adaptation, guaranteeing stable starting and reducing the driving development and maintenance cost are achieved.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a driver loading method and electronic device for a pre-boot execution environment. Background Technology

[0002] The expansion of diskless boot and remote system deployment scenarios has led to the widespread application of pre-boot execution environment (PMI) technology, which allows systems to boot without local storage media, in server clusters, public terminals, and other fields. In this technology, PMI driver loading depends on the operating system. Driver files are compiled and stored, then transmitted to the client over the network at startup. The operating system completes driver loading and initialization, and drivers need to be compiled and managed separately for different environments. Ultimately, the driver is used to configure the network card and establish network communication for booting.

[0003] The core issues with this technology are poor compatibility between the driver module and the basic input / output system environment and unified extensible firmware interface environment required by the pre-boot execution environment, and excessive reliance on the operating system for driver loading. Differences in interface specifications and scheduling logic between different environments necessitate the development of independent drivers, increasing development and maintenance costs. Furthermore, the operating system is not loaded during the initial startup of the pre-boot execution environment, preventing driver initialization and causing network card configuration failures and network link breakdowns, leading to startup interruptions or failures, and impacting the stability of diskless booting and remote deployment. Summary of the Invention

[0004] This application provides a driver loading method and electronic device for a pre-boot execution environment, which at least solves the problem in the related art of insufficient compatibility between the driver module and the environment required by the pre-boot execution environment, excessive reliance on the operating system support, and resulting in interruption or failure of the pre-boot execution environment startup.

[0005] This application provides a driver loading method for a pre-boot execution environment, including:

[0006] Obtain the driver file corresponding to the target network card;

[0007] Decompile the driver file to obtain program structure information;

[0008] Extract target modules that match the functions of the pre-boot execution environment from the program structure information, and perform code trimming and compression on the target modules to obtain lightweight driver modules;

[0009] The lightweight driver module is adapted to both the preset basic input / output system environment and the unified scalable firmware interface environment to obtain a dual-environment adaptable driver module.

[0010] The dual-environment adaptation driver module is integrated with the preset firmware control module and the preset reserved expansion module to obtain the option read-only memory image;

[0011] Compile and verify the option read-only memory image, and then flash the verified option read-only memory image to the option read-only memory of the target network card.

[0012] When the trigger instruction to start the pre-boot execution environment process is obtained, the option read-only memory image is invoked and the dual-environment adaptation driver module is loaded from the option read-only memory image.

[0013] This application also provides a driver loading device for a pre-boot execution environment, comprising:

[0014] The acquisition module is used to obtain the driver file corresponding to the target network card;

[0015] The compilation module is used to decompile driver files to obtain program structure information;

[0016] The processing module is used to extract target modules that match the functions of the pre-boot execution environment from the program structure information, and to perform code trimming and compression on the target modules to obtain lightweight driver modules;

[0017] The adapter module is used to adapt the lightweight driver module to the preset basic input / output system environment and the unified extensible firmware interface environment respectively, so as to obtain a dual-environment adapter driver module.

[0018] The image module is used to integrate the dual-environment adaptation driver module with the preset firmware control module and the preset reserved expansion module to obtain the optional read-only memory image;

[0019] The verification module is used to compile and verify the option ROM image, and then write the verified option ROM image to the option ROM of the target network card.

[0020] The loading module is used to call the option read-only memory image and load the dual-environment adaptation driver module from the option read-only memory image when the trigger instruction to start the pre-boot execution environment process is obtained.

[0021] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the driver loading method of any of the above-described pre-boot execution environments when executing the computer program.

[0022] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the driver loading method of any of the above-described pre-boot execution environments.

[0023] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the driver loading method for any of the above-described pre-boot execution environments.

[0024] The driver loading method and electronic device for the pre-boot execution environment provided in this application achieve dual-environment adaptation of the basic input / output system environment and the unified extensible firmware interface environment after the driver module has undergone functional screening and lightweight optimization. Furthermore, the integrated and generated option read-only memory image is solidified into the network card firmware, and the driver loading does not rely on the operating system. Therefore, it can solve the technical problems of insufficient driver compatibility with dual-environment adaptation and the pre-boot execution environment startup interruption or failure caused by the loading process relying on the operating system in related technologies. This achieves the technical effects of improving driver compatibility, ensuring stable startup of the pre-boot execution environment, and reducing driver development and maintenance costs. Attached Figure Description

[0025] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram illustrating an application scenario of the driver loading method for the pre-boot execution environment provided in the embodiments of this application;

[0027] Figure 2 A flowchart illustrating the driver loading method for the pre-boot execution environment provided in this application embodiment;

[0028] Figure 3 A schematic diagram of the structure of the driver loading device for the pre-boot execution environment provided in the embodiments of this application;

[0029] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0031] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0032] To address the technical issues of insufficient compatibility between the driver and pre-boot execution environments and the reliance on the operating system for loading, a process involving lightweight optimization, dual-environment adaptation, and firmware integration was adopted. This involved decompiling and filtering core functional modules from the original network card driver files, then trimming and compressing them to remove redundant code and adapt to the resource constraints of the pre-boot environment. Targeted adaptation modifications were made to the basic input / output system and the unified extensible firmware interface to eliminate interface specification differences between the two environments. The adapted driver module was integrated with the control and expansion modules to generate an option read-only memory image, which was then embedded into the network card. This allows the pre-boot execution environment to directly call the adapted driver in the network card firmware upon startup, without relying on operating system support. Ultimately, through the collaborative design of driver optimization, environment adaptation, and firmware integration, stable startup of the pre-boot execution environment was achieved.

[0033] First, let me explain the terms used in this application:

[0034] Pre-boot execution environment: refers to a technical environment that does not rely on local storage media, but obtains the necessary boot files and completes system boot initialization via the network;

[0035] Option Read-Only Memory: refers to a read-only memory module integrated into hardware devices such as network cards, used to store firmware information such as drivers and boot configurations;

[0036] Basic Input / Output System (BIOS): This refers to the low-level firmware embedded on the computer motherboard, which is responsible for initializing hardware devices and providing basic input / output functions.

[0037] Unified and Extensible Firmware Interface: refers to a firmware interface standard used to replace the Basic Input / Output System and provide more powerful hardware initialization, boot management and system services;

[0038] High-speed interconnection of peripheral components: refers to the existing high-speed serial computer expansion bus standard, which is used to realize high-speed data transmission between hardware devices and the motherboard;

[0039] Dual-environment adaptable driver module: refers to a driver module that has been adapted and modified to run normally in both basic input / output system environment and unified scalable firmware interface environment;

[0040] Lightweight driver modules refer to driver modules that are reduced in size and focused on function after being decompiled, functional modules filtered, code trimmed and compressed to eliminate redundant components.

[0041] Dynamic Host Configuration Protocol (DHCP) is a network protocol used to dynamically assign network configuration information such as IP addresses, subnet masks, and gateways to devices in a network.

[0042] Media access control address: This refers to a unique identifier assigned to a network device, used to identify the device in network communication;

[0043] Firmware control module: refers to the core firmware component used to schedule hardware resources, manage driver operation processes, and coordinate interactions between modules;

[0044] Reserved extension modules: These are modular components that reserve interfaces for future new features, supporting the expansion of driver functions without changing the core architecture;

[0045] Path index information: refers to the structured information stored in the boot image file that records the correspondence between the storage paths of various files and index identifiers;

[0046] Preset transmission protocol: refers to the pre-defined specifications for network data transmission, including data frame format, transmission timing, verification mechanism, etc.

[0047] Target storage location: refers to the storage area specified in the pre-boot execution environment for storing resources required for startup, such as kernel files and initial memory disk files.

[0048] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0049] This section describes the specific application environment architecture or hardware architecture that the driver loading method of the pre-boot execution environment depends on. (References) Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of the driver loading method for the pre-boot execution environment provided in the embodiments of this application, such as... Figure 1 As shown, it includes: terminal 101 and server 102.

[0050] Terminal 101 is used to obtain the driver file corresponding to the target network card, decompile the driver file, filter functional modules and perform lightweight optimization, and after completing the dual-environment adaptation modification, integrate it with the preset module to generate an option read-only memory image, and flash the image to the option read-only memory of the target network card. When the pre-boot execution environment startup process is triggered, the image in the network card firmware is called and the adapted driver is loaded to complete the network card hardware configuration and network communication. The server sends a request to the server 102 to obtain startup-related files and completes the system startup based on the received files. The server 102 is used to store the target network card driver file, startup image file and kernel-related files. It receives the file acquisition request sent by terminal 101, performs file retrieval and reading operations, generates corresponding file data and feeds it back to terminal 101, providing data support for the pre-boot execution environment driver loading and system startup of terminal 101.

[0051] Figure 2 A flowchart illustrating the driver loading method for the pre-boot execution environment provided in this application embodiment is shown below. Figure 2 As shown, embodiments of this application provide a driver loading method for a pre-boot execution environment. The method is described in detail below:

[0052] Step S201: Obtain the driver file corresponding to the target network card.

[0053] Specifically, based on the hardware identification information of the target network card, the corresponding driver file is matched from the driver resource library of the local storage medium or the remote server. The acquisition of the driver file conforms to the compatibility matching rules between hardware and driver programs, ensuring that the acquired file is consistent with the hardware parameters and functional specifications of the target network card. This provides the original data foundation for the subsequent optimization, adaptation and integration of the driver module, and clarifies the target object of driver loading.

[0054] Step S202: Decompile the driver file to obtain program structure information.

[0055] Specifically, a pre-defined disassembler is used to reverse engineer the binary code of the driver file. Based on pre-defined syntax parsing rules, the instruction structure of the code is restored, function call relationships, hardware interaction logic, and functional module division are extracted, transforming the binary file, which cannot be directly analyzed, into program information that can be processed in a structured manner. This yields program structure information containing driver functional module divisions, function call relationships, and hardware interaction logic, providing technical support for extracting target modules and eliminating redundant code, thus improving the targeting and efficiency of subsequent driver optimization.

[0056] Step S203: Extract the target module that matches the function of the pre-boot execution environment from the program structure information, and perform code trimming and compression on the target module to obtain a lightweight driver module.

[0057] Specifically, the core functional code segments in the program structure information are filtered through a preset functional matching algorithm. Redundant code, debugging information, and unused program branches that depend on the operating system are removed according to preset code trimming rules. Constant data is losslessly compressed through a preset compression algorithm to achieve lightweight optimization of the driver module. This enables the driver module to adapt to the resource constraints of the pre-boot execution environment, avoids loading failures due to excessive driver size or functional redundancy, and ensures the running efficiency and stability of the driver module.

[0058] Step S204: Adapt the lightweight driver module to the preset basic input / output system environment and the unified scalable firmware interface environment respectively to obtain a dual-environment adapted driver module.

[0059] Specifically, based on the interface specifications of the basic input / output system environment, the interrupt call interface of the lightweight driver module is replaced by a preset interface replacement rule; initialization and execution entry functions are generated based on the preset peripheral component interconnection option read-only memory specification; the lightweight driver module is structurally encapsulated according to the framework encapsulation rules of the unified extensible firmware interface, relevant functions in the preset protocol function library are called to supplement functionality, and dual-environment adaptation is achieved by combining runtime environment matching rules. This eliminates interface differences and compatibility barriers between the lightweight driver module and the two preset runtime environments, enabling the same driver module to work normally in different runtime environments, avoiding driver loading failures or abnormal operation due to environmental differences, and simplifying the driver development and management process.

[0060] Step S205: Integrate the dual-environment adaptation driver module with the preset firmware control module and the preset reserved expansion module to obtain the option read-only memory image.

[0061] Specifically, the system obtains the functional interface definitions of the preset firmware control module and the extended interface definitions of the preset reserved extended modules. Through interface adaptation technology, it achieves interface interfacing between the dual-environment adaptation driver module and the aforementioned two modules. Based on preset modular integration rules, it combines and compiles multiple modules into an image file conforming to the optional ROM storage specification. This enables the driver module to work collaboratively with the control module and extended modules, while adapting to the storage requirements of the optional ROM, ensuring the effective transmission of control commands and the scalability of extended functions during driver loading, and providing a functional carrier for subsequent image flashing and boot loading.

[0062] Step S206: Compile and verify the option ROM image, and flash the verified option ROM image to the option ROM of the target network card.

[0063] Specifically, two corresponding versions of the optional ROM images are compiled using preset cross-compilation tools and a unified extensible firmware interface toolset. Preset verification tools and an interactive environment are used to verify the image's compliance with specifications and protocol support. The capacity parameters of the target network card's optional ROM are read for matching and verification. Based on a preset flashing strategy, an appropriate flashing method is selected, and the verified image is flashed into the target network card's optional ROM. Verification eliminates issues such as syntax errors, unsupported protocols, or capacity mismatches in the image. The flashing operation flashes the image to the network card hardware, making the driver module part of the network card firmware. This avoids driver loading failures due to image issues, achieving deep integration between the driver module and the network card hardware. This allows the pre-boot execution environment to directly call the driver from the network card firmware during startup, eliminating dependence on external storage media and the operating system.

[0064] Step S207: When the trigger instruction to start the pre-boot execution environment process is obtained, the option read-only memory image is invoked and the dual-environment adaptation driver module is loaded from the option read-only memory image.

[0065] Specifically, after the pre-boot execution environment startup process is triggered, the target network card's option read-only memory is activated based on the firmware call mechanism, the image file stored therein is read, the currently running basic input / output system environment or unified extensible firmware interface environment is identified through preset environment matching rules, the corresponding driver unit is called and initialization is completed, so as to realize the adaptation and operation of the driver module with the current running environment.

[0066] By responding to the startup trigger command of the pre-boot execution environment, the core processes of image invocation and driver loading are completed, enabling the dual-environment adaptation driver module to be put into operation in the early stage of startup, providing driver support for subsequent steps such as network card hardware configuration and network communication, and ensuring that the pre-boot execution environment can proceed smoothly.

[0067] It enables rapid driver loading and environment adaptation during the initial startup of the pre-boot execution environment, eliminating dependence on the operating system and avoiding startup interruptions caused by driver loading delays or environment adaptation failures. This ensures stable startup of the pre-boot execution environment and provides reliable driver support for application scenarios such as diskless boot and remote deployment.

[0068] The driver loading method for the pre-boot execution environment provided in this invention obtains and decompiles the target network card compatible driver file, extracts the core module for lightweight optimization, and integrates it with the auxiliary module to generate an image after completing dual-environment adaptation and flashing it to the network card. During startup, the adapted driver in the network card firmware is directly called, which realizes efficient adaptation between the driver module and the dual running environment of the pre-boot execution environment. This eliminates the operating system's dependence on driver loading, reduces driver development and maintenance costs, ensures the stability and reliability of the pre-boot execution environment startup, and improves the execution efficiency in scenarios such as diskless boot and remote deployment.

[0069] This embodiment provides a detailed description of the process of decompiling the driver file to obtain program structure information in the above embodiments. The specific implementation of this process includes the following steps:

[0070] Step a1: Decompile the driver file using a pre-defined disassembler to obtain the initial assembly code.

[0071] Specifically, the driver file is binary executable code. The pre-built disassembler parses the binary code line by line into corresponding assembly instructions according to the instruction set architecture of the target driver file and the instruction reverse engineering rules. This achieves the format conversion from machine language to assembly language, restores the underlying instruction execution logic of the driver file, and transforms the binary data that cannot be directly analyzed into assembly code with readable and parseable characteristics, thus avoiding the inability to proceed with subsequent analysis due to the limitations of the original file format.

[0072] Step a2: Based on the preset syntax parsing rules, perform structured processing on the initial assembly code and extract the corresponding function call relationships and hardware interaction logic.

[0073] Specifically, the pre-defined syntax parsing rules are constructed based on the syntax specifications of assembly language, instruction association logic, and the general design architecture of the driver. By performing syntax verification, instruction classification, and association analysis on the instruction sequences in the initial assembly code, it identifies function entry / exit instructions, parameter passing instructions, and hardware port access instructions to obtain the call hierarchy between functions and the interaction flow between the driver and the hardware. By logically sorting and structurally reconstructing the fragmented initial assembly code, it removes invalid instruction interference, accurately locates the core logical associations (function calls) and core functional associations (hardware interaction) of the driver, transforms fragmented assembly instructions into logically related information units, eliminates the fragmentation and disorder of the code, and improves the efficiency and accuracy of subsequent information integration.

[0074] Step a3: Integrate the initial assembly code, function call relationships, and hardware interaction logic to obtain program structure information that includes the division of driver function modules.

[0075] Specifically, based on the hierarchical association of function calls and the functional orientation of hardware interactions, the scattered information (assembly code, call relationships, and interaction logic) obtained in the previous steps is integrated according to the preset functional association integration rules. This generates program structure information that includes the division of driver functional modules, complete initial assembly code, function call relationships, and hardware interaction logic. This achieves a systematic presentation of the internal logic of the driver and provides accurate and reliable structured data support for the subsequent extraction of target modules for the functional requirements of the pre-boot execution environment.

[0076] This invention uses a pre-set disassembler to reverse engineer the binary code of a driver file into assembly code. It then performs code structuring and core logic extraction according to pre-set syntax parsing rules, and integrates the code based on functional relationships to form a program structure with module divisions. This completely disassembles the internal logical architecture of the driver file, accurately reflecting the driver's functional components and core relationships. This provides a high-quality structured analysis foundation for subsequent target module selection, lightweight optimization, and dual-environment adaptation, improving the targeting and reliability of the driver optimization and adaptation process.

[0077] This embodiment details the process described in the above embodiment of extracting target modules that match the functions of the pre-boot execution environment from the program structure information, and performing code trimming and compression on the target modules to obtain lightweight driver modules. The specific implementation of this process includes the following steps:

[0078] Step b1: Based on the preset pre-boot execution environment function list, select matching function code fragments from the program structure information to obtain the first target module.

[0079] Specifically, the pre-boot execution environment function list is constructed based on the core communication requirements, hardware control requirements, and resource scheduling requirements of the pre-boot phase, and includes functional feature descriptions and code recognition rules. Through a functional feature matching algorithm, each functional module and code segment in the program structure information is compared with the functional items in the list one by one, and code segments with functional overlap that meet the preset threshold are selected to obtain the first target module that highly matches the functional requirements of the pre-boot execution environment.

[0080] Step b2 involves extracting and deleting redundant code segments that depend on the operating system from the first target module to obtain the second target module.

[0081] Specifically, based on the identification rules of operating system dependent code, by analyzing the API (Application Programming Interface) call characteristics, system function relationships, and runtime environment dependency identifiers of the code in the first target module, code segments that depend on the operating system kernel, system services, or system libraries to run are accurately located. According to the rules for removing redundant code, code that cannot run in the pre-boot execution environment is extracted and removed, ensuring that the deletion operation does not affect the integrity of the core functions. This effectively solves the problem of code failure caused by the lack of operating system support in the pre-boot stage, while reducing the proportion of invalid code in the module. This results in the second target module stripped of redundant operating system dependent code, eliminating compatibility barriers for the driver module to run in the pre-boot environment.

[0082] Step b3 involves trimming the code of the second target module, removing debugging information and unused program branches, to obtain the third target module.

[0083] Specifically, based on the identifying characteristics of code debugging information (such as debugging instructions and log output statements) and the analysis rules of program branch call status, non-essential information used for development debugging and troubleshooting in the second target module, as well as program branches that have never been triggered in the pre-boot execution environment's functional flow, are identified. These invalid components are then removed in a targeted manner according to pruning rules, effectively reducing memory usage and instruction execution overhead during driver loading and operation, avoiding storage resource consumption by debugging information and logical redundancy caused by unused program branches, and improving the running efficiency and response speed of the driver module in the pre-boot execution environment.

[0084] Step b4: Compress the constant data of the third target module using a preset compression algorithm to obtain a lightweight driver module.

[0085] Specifically, the preset compression algorithm can encode highly repetitive and structured constant data (such as fixed configuration parameters and character constants) in the third target module through lossless compression. It reduces the amount of data storage by establishing data indexes and replacing duplicate data, while ensuring that the compressed data can be completely restored through the corresponding decoding logic without affecting the normal execution of the code.

[0086] Without altering the core functionality and execution logic of the module, the storage size and data transmission overhead of the module are minimized to generate a lightweight driver module with a streamlined size and low resource consumption. Lossless compression of constant data significantly reduces the module's storage size, optimizes data transmission efficiency and memory usage during loading, and maintains the integrity of core functions and execution reliability.

[0087] This invention precisely filters the core code required for the pre-boot environment by pre-setting a functional list, removes redundant operating system-dependent code and invalid components, and optimizes the module size through lossless compression. This achieves functional focus and lightweight transformation of the driver module, ensuring the integrity of the core functions required for the pre-boot execution environment, significantly reducing the storage footprint and operating overhead of the driver, and improving the efficiency and stability of driver loading and running. This lays an efficient and reliable module foundation for subsequent dual-environment adaptation and image integration.

[0088] This embodiment details the process of adapting the lightweight driver module to both the basic input / output system environment and the unified extensible firmware interface environment in the above embodiments to obtain a dual-environment adapted driver module. The specific implementation of this process includes the following steps:

[0089] Step c1: Replace the interrupt call interface of the lightweight driver module with the standard interrupt interface of the preset basic input / output system according to the preset interface replacement rules.

[0090] Specifically, the preset interface replacement rules are built based on the interrupt call specification of the Basic Input / Output System (BIOS), clearly defining the mapping relationship between the original interrupt interface and the BIOS standard interrupt interface. Through interface parsing and replacement, the code segments related to interrupt calls in the lightweight driver module are located, and interrupt interfaces that do not conform to the BIOS specification are replaced with their standard interfaces. This ensures that interrupt requests and responses conform to the resource scheduling logic of the BIOS environment, eliminating compatibility barriers between the lightweight driver module and the BIOS environment at the interrupt call level. Unified and extensible firmware interface environment adaptation is achieved through subsequent framework encapsulation; these two steps collaboratively complete dual-environment adaptation, ensuring that the driver can run normally in both pre-boot environments.

[0091] Step c2: Generate an initialization entry function and an execution entry function based on the preset peripheral component interconnection option read-only memory specification, and add them to the lightweight driver module to obtain the first driver unit adapted to the basic input / output system.

[0092] Specifically, the Preset Peripheral Component Interconnect Options Read-Only Memory Specification defines the initialization process, entry function format, and parameter passing rules of the driver module in a basic input / output system environment. Based on this specification, an initialization entry function (for driver startup initialization) and an execution entry function (for core function execution) that meet the requirements are constructed through a function generation mechanism, and embedded into the corresponding code location of the lightweight driver module, so that the module conforms to the operating standards of the Preset Peripheral Component Interconnect Options Read-Only Memory.

[0093] Step c3: By using the pre-defined framework encapsulation rules of the unified and scalable firmware interface, the lightweight driver module is structurally encapsulated to obtain the second driver unit of the unified and scalable firmware interface.

[0094] Specifically, the pre-defined unified and extensible firmware interface framework encapsulation rules conform to the module architecture specifications, including module header definitions, functional partitioning, parameter interface standards, etc. Through a structured encapsulation mechanism, the code structure of the lightweight driver module is restructured to meet the format requirements and possess module identifiers and functional layouts recognizable by the pre-defined unified and extensible firmware interface environment. This eliminates the differences between the lightweight driver module and the pre-defined unified and extensible firmware interface environment at the module architecture level, enabling the driver module to adapt to the module loading and running mechanism of the pre-defined unified and extensible firmware interface, and avoiding the inability of the pre-defined unified and extensible firmware interface environment to recognize or load the driver due to architectural incompatibility.

[0095] Step c4: Retrieve the first function corresponding to the network transceiver protocol and the second function corresponding to the file loading protocol from the preset protocol function library, and add them to the second driver unit.

[0096] Specifically, the preset protocol function library integrates network transceiver functions (first function) and file loading functions (second function) that conform to the preset unified and extensible firmware interface protocol specification. Through the function call mechanism, these two types of core function functions are embedded into the corresponding function code segments of the second driver unit, which completes the function implementation logic of the second driver unit in the preset unified and extensible firmware interface environment and avoids the pre-boot process from being unable to proceed due to missing functions.

[0097] Step c5: Determine the matching rules for the current operating environment by reading the preset system table signature or basic input / output system interrupt flag.

[0098] Specifically, the preset system signature is a unique identifier of the preset unified extensible firmware interface environment, and the basic input / output system interrupt flag is a unique identifier of the basic input / output system environment. By reading the system identifier of the target operating environment through the environment identification mechanism, the driver module can automatically identify the current operating environment and determine the driver unit to be called (first driver unit or second driver unit), providing a logical basis for the driver module's automatic cross-environment adaptation.

[0099] Step c6: Integrate the first driving unit, the second driving unit, and the matching rules to obtain the dual-environment adaptation driving module.

[0100] Specifically, the first driving unit, the second driving unit, and the environment matching rules are structurally integrated to build a unified module architecture. The matching rules, as scheduling logic, are embedded in the front end of the module's initialization process to ensure that environment identification and unit matching are performed first when the driver starts, and then the corresponding driving unit is called to run. This achieves the fusion of two driving units adapted to different environments and environment scheduling logic, forming a unified driving module with complete functions that can run across environments. This avoids the calling chaos caused by the dispersion of driving units and simplifies the deployment and management process of the driver.

[0101] This invention achieves basic input / output system environment adaptation of the driver module through interface replacement and supplementation of standardized functions. It completes unified and scalable firmware interface environment adaptation by relying on framework encapsulation and protocol function invocation. It establishes matching rules by combining environment identifier recognition and integrates dual driver units to achieve automatic adaptation and universal operation of the driver module in two core pre-boot environments. This effectively solves the problem of insufficient driver environment adaptation and compatibility in related technologies, reduces driver development and maintenance costs, and ensures stable driver support for the pre-boot execution environment under different operating environments.

[0102] This embodiment provides a detailed explanation of the process in the above embodiments of integrating the dual-environment adaptation driver module with the preset firmware control module and the preset reserved expansion module to obtain the optional read-only memory image. The specific implementation of this process includes the following steps:

[0103] Step d1: Obtain the functional interface definition of the preset firmware control module and the extension interface definition of the preset reserved extension module.

[0104] Specifically, the functional interface definition of the preset firmware control module is pre-set based on the control logic requirements of the pre-boot execution environment driver loading, and the transmission format, parameter type and interaction sequence of the control commands are clearly defined; the extension interface definition of the preset reserved extension module conforms to the modular extension specification, and the access method and data interaction standard of the extension function are defined; through the interface definition reading mechanism, the complete definition information of the two types of interfaces is extracted from the module's configuration file or preset storage area to ensure that the information obtained meets the specification requirements of the interaction between modules.

[0105] Step d2 involves adapting and connecting the standardized interactive interface of the dual-environment adaptation driver module with the functional interface definition and extended interface definition.

[0106] Specifically, by performing syntax verification, parameter mapping, and timing alignment on the standardized interaction interface of the dual-environment adaptation driver module and the interface definitions of the two types of preset modules, and through the interface adaptation and modification mechanism, the parameter format and transmission timing of the driver module's interaction interface are adjusted to fully match the interface definitions of the preset modules, ensuring the compatibility of data transmission and command interaction.

[0107] Step d3: According to the preset modular integration rules, the docked dual-environment adaptation driver module, preset firmware control module, and preset reserved extension module are combined and compiled to obtain the option read-only memory image.

[0108] Specifically, the pre-defined modular integration rules conform to the storage architecture specifications and program execution logic of the optional ROM, clarifying the combination order of multiple modules, code segment division, memory address allocation, and image header information definition. Using a compilation tool, the code of the three modules that have completed interface integration is integrated and compiled according to these rules, transforming the scattered module code into an image file that meets the storage and execution requirements of the optional ROM. When generating the optional ROM image through compilation, the actual capacity of the target network card's optional ROM (typically 256KB-512KB) is simultaneously verified. If the integrated capacity exceeds the limit, adjustments are made by trimming redundant functions of reserved expansion modules and optimizing driver compression algorithms to ensure that the image capacity meets hardware limitations.

[0109] This invention, through obtaining the interface definition of the preset module to clarify the interaction standard, completes the interface adaptation and connection between the dual-environment adaptation driver module and the preset module, and compiles and generates an image by combining multiple modules according to the option read-only memory specification, thereby realizing the organic integration of driver function with control and expansion functions, ensuring the standardization and compatibility of the image, providing a complete and reliable carrier for the driver module to be solidified into the network card firmware, while reserving functional expansion space to ensure the integrity and scalability of the pre-boot execution environment driver loading.

[0110] This embodiment details the process of compiling and verifying the option read-only memory image in the above embodiments, and then flashing the verified option read-only memory image to the option read-only memory of the target network card. The specific implementation of this process includes the following steps:

[0111] Step m1: Compile the option read-only memory image corresponding to the basic input / output system version using the preset cross-compilation tool to obtain the system version image.

[0112] Specifically, the pre-built cross-compilation tool is constructed based on the operating architecture of the Basic Input / Output System (BIOS) environment and the storage specifications of the Option READ-only memory (READ-only memory). It has cross-platform code conversion capabilities and can convert the code of the original BIOS version READ-only memory image into executable code that conforms to the instruction set requirements of the BIOS environment. At the same time, it ensures that the structure of the compiled image is compatible with the READ-only memory storage format, eliminating the running format obstacles of the original image in the BIOS environment.

[0113] Step m2: Verify the system version image to obtain the system verification result.

[0114] Specifically, based on the preset verification tools and the operating specifications of the option read-only memory in the basic input / output system environment, verification indicators are constructed, including image syntax integrity, code logic compliance, and functional module integrity. The preset verification tools are used to check the system version image item by item, and the test results are compared with the preset pass standards to generate corresponding system verification results. System version images with syntax errors, logical defects, or missing functions are screened out to prevent unqualified images from entering the subsequent process and causing the driver to fail to run after flashing, thus ensuring the reliability of subsequent image flashing.

[0115] Step m3: Compile the option read-only memory image corresponding to the version of the unified extensible firmware interface to obtain the interface version image.

[0116] Specifically, a pre-defined unified and extensible firmware interface toolset is used to compile the original version of the option read-only memory image according to the module architecture specification and the storage standard of the option read-only memory. This process enables the image code to be adapted and converted to the pre-defined unified and extensible firmware interface instruction set, ensuring that the compiled image meets the loading and running requirements of the pre-defined unified and extensible firmware interface environment.

[0117] Step m4: Verify the protocol support capabilities of the interface version image through a preset interactive environment to obtain the interface version verification result.

[0118] Specifically, the preset interactive environment simulates the real-world operation scenario of the preset unified and extensible firmware interface, and integrates the interaction logic of the core protocols under the preset unified and extensible firmware interface environment. Through this environment, the interaction process between the interface version image and core protocols such as network transmission and reception protocols and file loading protocols is simulated. The image's support completeness and interaction compatibility for various protocols are tested, interface version verification results are generated, and the pre-boot process interruption problem caused by insufficient protocol support is eliminated, ensuring that the image can meet the driver requirements of the pre-boot execution environment.

[0119] Step m5: Read the target network card's option read-only memory capacity parameter.

[0120] Specifically, a data interaction link is established with the target network card through a preset hardware communication protocol, and a capacity parameter reading command is sent. After the target network card responds to the command, it feeds back the storage capacity information of its optional read-only memory. The accuracy of the capacity parameters is extracted and confirmed through a data parsing mechanism to ensure that the obtained parameters are consistent with the actual hardware status. The storage limit of the target network card's optional read-only memory is clarified, providing a hardware constraint basis for subsequent image capacity matching and avoiding flashing failure or hardware damage due to the image size exceeding the storage capacity.

[0121] Step m6: Compare the size of the system version image and the interface version image with the capacity parameters to obtain the capacity matching result.

[0122] Specifically, based on preset capacity matching rules, the actual size of the system version image and the interface version image are compared with the capacity parameters to determine whether the size of the two types of images is within the allowable range of the capacity parameters, generate the corresponding capacity matching results, and filter out unqualified images whose size exceeds the hardware storage capacity to avoid incomplete flashing or hardware failure due to excessive image size.

[0123] Step m7: Based on the system verification results, interface version verification results, capacity matching results, and preset verification conditions, select target images that meet the preset verification conditions.

[0124] Specifically, the preset verification conditions clarify the qualification criteria for system verification results, interface version verification results, and capacity matching results. Through a multi-result comparison mechanism, the three types of results are comprehensively verified, and images that meet all qualification criteria are selected as target images. By integrating the results of each verification step, a comprehensive screening of images is achieved, eliminating images with environmental adaptation defects, capacity incompatibility, and other issues.

[0125] Step m8: Flash the target image to the target network card's option read-only memory.

[0126] Specifically, before flashing, the write protection status of the target network card's optional ROM must be processed: read the write protection parameters; if it is enabled, generate an unlock command to unlock and confirm; if not enabled, proceed directly to the flashing process. Based on the preset flashing protocol and strategy, establish a communication connection between the flashing tool and the target network card's optional ROM, and write the target image segment by segment to the hardware storage area according to the storage address of the optional ROM; after writing, a data verification mechanism is used to confirm the integrity and accuracy of the image data, ensuring that there is no data loss or error during the flashing process.

[0127] This invention uses preset tools to compile and perform multi-dimensional verification of two types of image versions. It combines the network card option read-only memory capacity parameter to select qualified target images and complete the flashing process. This ensures the environmental adaptability, capacity compatibility, and operational reliability of the target images, achieves deep integration between the driver module and the network card hardware, eliminates the dependence of driver loading on external storage and operating system, ensures the stability and efficiency of driver calls when the pre-boot execution environment starts, and reduces the risk of driver loading failure due to image issues.

[0128] In one specific embodiment, the method for writing the target image to the option read-only memory of the target network card includes the following steps:

[0129] Step m81: Obtain the target network card's option read-only memory hardware information and extract the write-protected status parameters.

[0130] Specifically, a data interaction link is established with the target network card through a preset hardware communication protocol, and a hardware information reading command is sent. After the target network card responds to the command, it feeds back hardware configuration information including the option read-only memory (Option ROM). According to the identification rules of write protection status parameters, the write protection status parameters are parsed and extracted from the feedback information to ensure that the parameters are consistent with the actual hardware protection status.

[0131] Step m82: Based on the write protection status parameters and preset unlocking rules, generate an unlocking command, send it to the control register of the target network card, and obtain write protection unlocking confirmation information.

[0132] Specifically, the preset unlocking rules are formulated based on the write protection control logic of the target network card's optional read-only memory, specifying the unlocking instruction format and transmission timing corresponding to different write protection states. Based on the extracted write protection state parameters, the corresponding unlocking instruction template is matched to generate an unlocking instruction that meets the requirements of the control register. This instruction is sent to the target network card's control register via the hardware bus. The unlocking status information fed back from the register is received and parsed to obtain the confirmation result. By removing the write protection restriction of the optional read-only memory, the hardware permission barrier for the flashing operation is eliminated, ensuring that subsequent image data can be written to the storage area normally. At the same time, the validity of the unlocking operation is verified by receiving the confirmation information.

[0133] Step m83: Split the target image according to the preset data block splitting rules to obtain a data block set.

[0134] Specifically, the preset data block splitting rules are formulated in conjunction with the storage unit size of the optional read-only memory, data transmission bandwidth, and error correction capabilities, clearly defining the partition size and splitting order of the data blocks. The target image is structurally segmented using a data splitting algorithm, ensuring that each split data block conforms to the hardware specifications for transmission and storage, while preserving the original logical order of the image data. By optimizing the transmission efficiency and storage reliability of the image data, single transmission failures or data loss due to excessively large image files are avoided, facilitating subsequent fine-grained management of block-by-block transmission and verification, and reducing the probability of errors in large-scale data transmission.

[0135] Step m84: Obtain the preset starting storage address of the target network card's option read-only memory, and allocate the target storage address corresponding to each data block based on the sorting order of the data block set to obtain the address allocation table.

[0136] Specifically, the preset starting storage address is the reserved mirror storage starting area in the optional ROM. According to the storage address mapping rules of the optional ROM, combined with the sorting order of the data block set and the size of each data block, a continuous and non-overlapping target storage address is assigned to each data block. This clarifies the specific storage location of each data block in the optional ROM, avoids data block storage address conflicts, ensures that the mirror data is stored in an orderly manner according to the original logical order, and provides accurate address guidance for subsequent block-by-block transmission.

[0137] Step m85: Based on the address allocation table and the preset data transmission protocol, the data block set is transmitted block by block to the target network card's optional read-only memory, and a data transmission completion signal is obtained.

[0138] Specifically, the preset data transmission protocol conforms to the communication specifications of the hardware bus, clearly defining the frame format, verification method, and timing requirements for data transmission. Based on the address information in the address allocation table, the corresponding data blocks are encapsulated according to the protocol requirements and sent block by block to the target address of the optional ROM. Verification is performed after each block transmission is completed, and a transmission completion signal is received from the optional ROM after all transmissions are finished. This achieves accurate and orderly data block transmission, ensuring that each data block is accurately written to its corresponding memory address. Block-by-block transmission and verification guarantee the integrity of data transmission, preventing data mistransmission and omission.

[0139] Step m86: Generate a firmware verification command based on the data transmission completion signal and send it to the target network card, and receive the image verification result returned by the target network card.

[0140] Specifically, the data transmission completion signal triggers the firmware verification process. A verification command is generated based on a preset verification algorithm and sent to the target network card. The network card then compares the verification value (e.g., hash value comparison) of the image stored in its option read-only memory with the original target image. The comparison result is fed back to the control terminal as the image verification result. By verifying the integrity and accuracy of the transmitted image, potential data corruption or loss during transmission is investigated, preventing subsequent driver loading errors due to transmission mistakes.

[0141] Step m87: Generate firmware update confirmation command based on image verification result to complete flashing of target image.

[0142] Specifically, the preset verification result judgment rules clearly define the standards for qualified verification results. If the image verification result meets the qualified standards, an update confirmation command conforming to the network card firmware specification is generated and sent to the target network card to confirm that the flashing is completed. If the verification fails, an exception handling process (such as retransmission) is triggered.

[0143] This invention, through detection and unlocking of write protection, image splitting and storage address allocation, precise block-by-block transmission, and verification confirmation, completes the flashing process. This achieves refined and highly reliable flashing of the target image to the network card's optional read-only memory, ensuring the integrity of image transmission and the accuracy of storage, and guaranteeing the validity of the image after flashing. It provides a stable guarantee for the deep integration of the driver module and network card hardware, while forming a complete flashing closed loop, improving the controllability and reliability of the flashing process.

[0144] This embodiment details the process described in the above embodiment of calling the option read-only memory image and loading the dual-environment adaptation driver module from the option read-only memory image when the trigger instruction to start the pre-boot execution environment process is obtained. The specific implementation of this process includes the following steps:

[0145] Step n1: Receive the trigger command to start the pre-boot execution environment process, triggering the client to call the target network card's option read-only memory image.

[0146] Specifically, the client detects the trigger signal through a firmware-level instruction recognition mechanism. Based on the preset hardware calling logic, it locates the target network card's option ROM and initiates an image call request, establishing a connection between the image and the client's execution logic. By calling the image in the network card's option ROM, it eliminates the dependence on external storage media or operating system, ensuring that the driver loading process starts from the firmware level.

[0147] Step n2: Load the preset firmware control module from the optional read-only memory image and complete the initialization, and obtain the resource scheduling interface of the firmware control module.

[0148] Specifically, the optional read-only memory image contains the code segment and initialization configuration information of a preset firmware control module. The client locates this module through the image resolution mechanism, executes the initialization process according to the module initialization specification, completes the activation of control logic and parameter configuration, and extracts the module's resource scheduling interface information to establish an interactive channel for subsequent resource calls. By activating the core scheduling function of the firmware control module and obtaining the resource scheduling interface, scheduling support is provided for the subsequent loading of dual-environment adaptation driver modules, allocation of hardware resources, and management of network communication.

[0149] Step n3: Load the dual-environment adaptation driver module through the resource scheduling interface and match it with the currently running basic input / output system environment or unified extensible firmware interface environment.

[0150] Specifically, the resource scheduling interface provides a loading channel for driver modules. The client uses this interface to read the code and environment matching rules of the dual-environment adaptable driver module. Based on the interrupt flags of the basic input / output system environment or the system table signature of the unified extensible firmware interface environment, it identifies the current operating environment, matches the corresponding driver unit, and activates it. This achieves accurate loading and environment-oriented matching of the dual-environment adaptable driver module, eliminating compatibility barriers between the driver module and the current operating environment. It ensures that the driver module can perform its core functions in the corresponding environment and avoids driver malfunctions caused by environment incompatibility.

[0151] Step n4: Based on the dual-environment adaptation driver module, read the preset high-speed configuration information of the target network card's peripheral component interconnection and allocate the corresponding high-speed resources for peripheral component interconnection.

[0152] Specifically, before allocation, the current operating environment is identified through system table signatures or basic input / output system interrupt flags. For different environments, configuration information is read through hardware access interfaces adapted to the corresponding specifications, and peripheral component interconnect high-speed resources are allocated according to the resource scheduling rules of the corresponding environment to ensure accurate and compatible allocation. The dual-environment adaptation driver module integrates the access protocol for the peripheral component interconnect high-speed (PCIe) configuration space. According to this protocol, it reads the preset configuration information (such as device identifier, resource requirements, etc.) in the target network card's PCIe configuration space, and combines it with preset PCIe resource allocation rules to allocate dedicated memory address space, interrupt request numbers, and other hardware resources to the network card to avoid resource conflicts. By clearly defining the target network card's PCIe configuration parameters and resource requirements, and providing the necessary hardware resource support for network card operation through precise resource allocation, the resource contention problem is resolved, ensuring that the network card can stably occupy the required hardware resources.

[0153] Step n5: Detect the rate negotiation and link status of the target network card, and generate link configuration parameters.

[0154] Specifically, the dual-environment adaptation driver module actively performs a rate negotiation process with the connected network devices according to the network link protocol to determine the adapted transmission rate. Simultaneously, through a link status detection mechanism, it monitors link connection integrity, signal quality, and other indicators, integrating the negotiated rate parameters with the detected link status information to generate standardized link configuration parameters. This ensures transmission rate compatibility between the network interface card (NIC) and network devices, identifies link connection anomalies, and provides link-level parameter support for subsequent network interface activation and network communication, preventing communication failures due to rate mismatch or link anomalies.

[0155] Step n6: Based on the high-speed resources and link configuration parameters of peripheral component interconnection, set the media access control address of the target network card and enable the network interface to complete the network card hardware configuration.

[0156] Specifically, based on the PCIe resource allocation results and link configuration parameters, and conforming to the network card hardware configuration specifications, the media access control (MAC) address is written to the network card register through the dual-environment adaptation driver module. This activates the network interface function of the network card, completes the final configuration of the hardware parameters, and enables the network card to meet the hardware requirements for network communication. This completes the core configuration of the network card hardware, clarifies the network card's identity (MAC address), enables the network interface, and integrates the previous resource allocation and link parameter configuration results to achieve full activation of the network card's hardware functions.

[0157] Step n7: Send a Dynamic Host Configuration Protocol (DHCP) broadcast request through the firmware control module to obtain network configuration information.

[0158] Specifically, the firmware control module integrates the interaction logic of the Dynamic Host Configuration Protocol (DHCP). According to this protocol, it sends broadcast requests to the DHCP server in the network. Upon responding to the request, the server sends back network configuration data containing information such as IP address, subnet mask, gateway address, and DNS server address. The firmware control module parses this data to obtain the network configuration information. By acquiring the core network parameters required for client-side network communication, it solves the problem of the client lacking network configuration during the pre-boot phase, establishing the communication foundation between the client and other devices in the network (such as the default server).

[0159] Step n8: Send a read request to the preset server based on the network configuration information to obtain the boot image file.

[0160] Specifically, based on the acquired network configuration information, a communication link is established between the client and the preset server via the TCP / IP protocol. The client generates a read request according to the preset file request format and sends it to the corresponding port of the server. After parsing the request, the server retrieves the target boot image file and sends the file data back to the client via the communication link. The client receives and caches the file data. By obtaining the core boot image file required for system startup from the pre-boot execution environment, the network configuration is connected to the subsequent system startup preparation process, ensuring that the startup process can obtain the necessary core file support.

[0161] Step n9: Parse the boot image file to obtain the kernel path and memory disk path, and download the corresponding kernel file and initial memory disk file.

[0162] Specifically, based on preset boot image parsing rules, the structure of the boot image file is parsed to locate the path index information of the kernel file and the initial memory disk file, extracting the corresponding kernel path and memory disk path. Based on these two paths, a file download request is sent to a preset server via network communication, and the kernel file and initial memory disk file returned by the server are received and stored. This process clarifies the specific locations of the core files required for booting and completes the download, supplementing the critical files for system booting and providing file support for the pre-boot execution environment to subsequently boot the system kernel and initialize the memory disk.

[0163] This invention, through receiving a trigger command, invokes the network card option read-only memory image, loads the initialization firmware control module and dual-environment adaptation driver module, and matches the operating environment. It sequentially completes network card PCIe resource allocation, link detection, and hardware configuration, and then obtains network configuration via DHCP and boot-related files from the server. This achieves firmware-level autonomous advancement of the entire pre-boot execution environment driver loading process, eliminating dependence on the operating system and solving the problems of poor environment adaptation and unstable startup in related technologies. It ensures the stability and efficiency of the pre-boot execution environment startup, providing reliable technical support for diskless boot and remote deployment scenarios.

[0164] In one specific embodiment, the method for allocating corresponding high-speed peripheral component interconnection resources based on the dual-environment adaptation driver module reading the preset high-speed configuration information of the target network card peripheral component interconnection includes the following steps:

[0165] Step n41: Read the manufacturer identifier and device identifier in the high-speed configuration space of the peripheral component interconnection of the target network card through the hardware access interface of the dual environment adaptation driver module.

[0166] Specifically, the dual-environment adaptation driver module integrates a hardware access interface compliant with the PCIe (Peripheral Component Interconnect) specification. This interface conforms to the PCIe configuration space access protocol and can accurately locate the register addresses of the storage vendor ID and device ID in the PCIe configuration space. It extracts the identification information through a data reading mechanism, ensuring the accuracy and completeness of the information read. By obtaining the unique hardware identifier of the target network card, the hardware model and specifications of the network card are clearly identified, providing a core basis for subsequent resource allocation based on hardware characteristics and avoiding resource allocation mismatches caused by unclear hardware information.

[0167] Step n42: Based on the preset high-speed resource allocation rules for peripheral component interconnection, allocate memory address space and interrupt request number to the target network card corresponding to the vendor identifier and device identifier.

[0168] Specifically, the preset PCIe resource allocation rules are constructed based on the idle status of the system hardware resource pool, the resource scheduling specifications of the PCIe bus, and the resource requirement thresholds for different network card models. By combining the read manufacturer and device identifiers with the corresponding resource requirement parameters, dedicated memory address spaces and interrupt request numbers are selected and allocated from the system's idle resource pool, ensuring that the allocated resources do not conflict with other hardware devices. This yields memory address spaces and interrupt request numbers adapted to the target network card's hardware characteristics, and the resource allocation results conform to the system scheduling specifications and network card requirements, eliminating potential resource conflict risks.

[0169] Step n43: Write the allocated memory address space and interrupt request number into the configuration register of the target network card to complete the allocation of high-speed resources for peripheral component interconnection.

[0170] Specifically, the target network interface card's (NIC) configuration register is a core component storing hardware resource parameters. A register write protocol compliant with the PCIe specification, through the write interface of the dual-environment adaptation driver module, precisely writes the allocated memory address space and interrupt request number to the corresponding register address, enabling the NIC hardware to recognize and load these resource parameters. This solidifies the resource allocation results, allowing the target NIC hardware to perceive and activate the allocated resources, completing the resource allocation loop and ensuring that the previously allocated resources truly support NIC operation, preventing resource parameters from being lost or ineffective.

[0171] This invention, through a dual-environment adaptation driver module, reads the network card's PCIe core hardware identifier, allocates dedicated hardware resources according to preset rules, and writes them into the network card's configuration register. This achieves accurate and compliant allocation of PCIe resources, ensuring that resources are adapted to the network card's hardware characteristics without conflict. It also guarantees the resource stability of the network card's subsequent functions and provides reliable hardware resource guarantees for the normal operation of the network card in the pre-boot execution environment.

[0172] In one specific embodiment, the specific implementation of parsing the boot image file to obtain the kernel path and memory disk path, and downloading the corresponding kernel file and initial memory disk file includes the following steps:

[0173] Step n91: Perform structured parsing of the startup image file using preset image parsing rules to extract path index information from the image file.

[0174] Specifically, the preset image parsing rules are constructed based on the standardized structure specifications of the boot image file, including logic such as image header recognition, data partitioning, and index table location. Through a structured parsing algorithm, the byte stream of the boot image file is segmented and parsed to locate the index areas of storage path information, extracting the file path mapping relationships contained therein, ensuring that the parsing process conforms to the image's storage logic. By extracting core index information related to file paths from the complex image data, it provides fundamental data support for accurately locating the kernel file and the initial memory disk file, avoiding target file location failures due to the opaque image structure.

[0175] Step n92: Based on the path index information, filter out the index identifiers corresponding to the kernel file and the index identifiers corresponding to the initial memory disk file.

[0176] Specifically, the index identifiers of kernel files and initial memory disk files possess specific feature codes. Based on preset identifier matching rules, the extracted path index information is compared to identify those that match the feature codes of the two types of target files, establishing a correspondence between identifiers and target files. By accurately locating the positions of the two types of core target files in the index information, interference from irrelevant file indexes is eliminated, narrowing the scope of subsequent path extraction, improving the targeting and efficiency of path acquisition, and avoiding path extraction errors caused by complex index information.

[0177] Step n93: Extract the kernel path and memory disk path from the path index information based on the index identifier.

[0178] Specifically, the path index information contains a mapping between index identifiers and actual file paths. Based on preset path extraction rules, the corresponding path record is queried backwards using the index identifier. The format of the path record is parsed, and valid path strings are extracted to obtain standardized kernel paths and memory / disk paths. The abstract index identifier is then transformed into a concrete, accessible file path, clarifying the storage location of the target file on the preset server. This provides the core address for subsequent download requests to the server, connecting the index filtering and file download processes.

[0179] Step n94: Verify the validity of the kernel path and memory disk path using preset path verification rules to obtain the path verification result.

[0180] Specifically, the preset path verification rules include logic such as path format compliance checks and path reachability pre-verification. Format verification determines whether the path conforms to the preset server's file access format requirements. Reachability pre-verification simulates the path access process to verify the path's existence and accessibility, ultimately generating a path verification result. This process identifies invalid paths (such as incorrect formats or non-existent paths) to prevent download requests from failing or retrieving incorrect files, ensuring the validity of download requests and reducing resource consumption from invalid operations.

[0181] Step n95: If the path verification result is valid, send a file download request for the corresponding path to the preset server based on the network configuration information and the preset transmission protocol.

[0182] Specifically, the valid path verification result triggers the download process. Based on the previously obtained network configuration information (such as IP address, gateway, etc.), a network connection is established between the client and the preset server. The download request is encapsulated according to the specifications of the preset transmission protocol (such as Transmission Control Protocol / Internet Protocol, TCP / IP), including core information such as the target path and file identifier, and sent to the corresponding service port of the server. A download communication link is established between the client and the server, clarifying the target file and access path of the download request, triggering the server's file retrieval and transmission process. A successful and accurate file download request is initiated to the preset server, establishing a stable download communication link. The server can accurately retrieve the target file according to the request information, laying the communication foundation for subsequent file data reception.

[0183] Step n96: Receive kernel file data and initial memory disk file data returned by the preset server, and write them to the preset cache area respectively.

[0184] Specifically, based on a preset transmission protocol, the receiving mechanism receives file data transmitted in segments from the server, and ensures the integrity of each segment through data verification. A preset cache area has temporary storage and data concatenation functions, writing the received segmented data sequentially into the cache and concatenating them to form complete file data. Complete reception and storage of data from both types of target files in the preset cache area, with complete and lossless data concatenation, provides qualified verification objects for subsequent integrity checks, ensuring the initial reliability of the file data.

[0185] Step n97: Perform integrity verification on the kernel file data and initial memory disk file data in the cache area using a preset file verification algorithm to obtain the file verification result.

[0186] Specifically, a preset file verification algorithm (such as a hash algorithm) calculates the complete file data within the cache area to generate a data verification value. This verification value is then compared with a preset standard verification value for the target file stored on the server side to determine whether the file data is complete and undamaged, generating a file verification result. This verifies the completeness and validity of the received file data, investigates potential packet loss or corruption during data transmission, and prevents subsequent system startup anomalies caused by incomplete file data.

[0187] Step n98: If the file verification result is successful, the file data in the cache area is saved to the target storage location, completing the download of the kernel file and the initial memory disk file.

[0188] Specifically, after file verification, according to preset storage specifications, the complete file data within the cache area is written to the target storage location specified by the pre-boot execution environment, completing the migration of data from temporary cache to permanent storage; simultaneously, the storage status flag is updated to confirm that the file download is complete. The kernel file and the initial memory disk file are successfully persisted to the target storage location, the file data is complete and valid, the pre-boot execution environment has the core file resources required to boot the system, and the file download process is successfully completed, laying the file foundation for system startup.

[0189] This invention, through pre-defined rules, parses the boot image file to extract the path index, filters the identifiers, and obtains the valid path. Based on network configuration and transmission protocol, it initiates a download request, receives the data through caching, verifies its integrity, and then solidifies the file data. This achieves accurate and reliable download of kernel files and initial memory disk files, ensuring the integrity and validity of the downloaded files. It provides core file support for the pre-boot execution environment to boot the system, and improves the stability and reliability of the pre-boot process.

[0190] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0191] Figure 3 This is a schematic diagram of the driver loading device for the pre-boot execution environment provided in an embodiment of this application. Figure 3 As shown, embodiments of this application also provide a driver loading device 30 for a pre-boot execution environment, comprising:

[0192] Module 301 is used to obtain the driver file corresponding to the target network card;

[0193] Compiler module 302 is used to decompile driver files to obtain program structure information;

[0194] Processing module 303 is used to extract target modules that match the functions of the pre-boot execution environment from the program structure information, and to perform code trimming and compression on the target modules to obtain lightweight driver modules;

[0195] The adapter module 304 is used to adapt the lightweight driver module to the preset basic input / output system environment and the unified extensible firmware interface environment respectively, so as to obtain a dual-environment adapter driver module.

[0196] The image module 305 is used to integrate the dual-environment adaptation driver module with the preset firmware control module and the preset reserved expansion module to obtain the optional read-only memory image;

[0197] The verification module 306 is used to compile and verify the option read-only memory image, and to write the verified option read-only memory image to the option read-only memory of the target network card.

[0198] Loading module 307 is used to call the option read-only memory image and load the dual-environment adaptation driver module from the option read-only memory image when a trigger instruction to start the pre-boot execution environment process is obtained.

[0199] In some alternative implementations, compilation module 302 is specifically used for:

[0200] The driver file is decompiled using a pre-defined disassembler to obtain the initial assembly code. The initial assembly code is then structured based on pre-defined syntax parsing rules, and the corresponding function call relationships and hardware interaction logic are extracted. The initial assembly code, function call relationships, and hardware interaction logic are then integrated to obtain program structure information that includes the division of driver functional modules.

[0201] In some alternative implementations, the processing module 303 is specifically used for:

[0202] Based on the pre-boot execution environment function list, matching functional code segments are selected from the program structure information to obtain the first target module; redundant code segments that depend on the operating system in the first target module are extracted and deleted to obtain the second target module; the code of the second target module is trimmed to remove debugging information and unused program branches to obtain the third target module; the constant data of the third target module is compressed using a pre-set compression algorithm to obtain the lightweight driver module.

[0203] In some alternative implementations, the adapter module 304 is specifically used for:

[0204] The interrupt call interface of the lightweight driver module is replaced with the standard interrupt interface of the preset basic input / output system by using preset interface replacement rules. An initialization entry function and an execution entry function are generated based on the preset peripheral component interconnection option read-only memory specification and added to the lightweight driver module to obtain a first driver unit adapted to the basic input / output system. The lightweight driver module is structurally encapsulated using preset unified and extensible firmware interface framework encapsulation rules to obtain a second driver unit with a unified and extensible firmware interface. The first function corresponding to the network transceiver protocol and the second function corresponding to the file loading protocol are retrieved from the preset protocol function library and added to the second driver unit. The matching rules for the current operating environment are determined by reading the preset system table signature or the basic input / output system interrupt flag. The first driver unit, the second driver unit, and the matching rules are integrated to obtain a dual-environment adapted driver module.

[0205] In some alternative implementations, the mirror module 305 is specifically used for:

[0206] Obtain the functional interface definition of the preset firmware control module and the extended interface definition of the preset reserved extension module; adapt and connect the standardized interaction interface of the dual-environment adaptation driver module with the functional interface definition and the extended interface definition; according to the preset modular integration rules, combine and compile the connected dual-environment adaptation driver module, preset firmware control module, and preset reserved extension module to obtain the optional read-only memory image.

[0207] In some alternative implementations, the verification module 306 is specifically used for:

[0208] The system version image is obtained by compiling the optional ROM image corresponding to the basic input / output system version using a preset cross-compilation tool; the system version image is verified to obtain the system verification result; the interface version image is obtained by compiling the optional ROM image corresponding to the unified extensible firmware interface version; the protocol support capability of the interface version image is verified through a preset interactive environment to obtain the interface version verification result; the capacity parameter of the optional ROM of the target network card is read; the size of the system version image and the interface version image are compared with the capacity parameter to obtain the capacity matching result; based on the system verification result, the interface version verification result, the capacity matching result, and the preset verification conditions, the target image that meets the preset verification conditions is selected; the target image is then flashed into the optional ROM of the target network card.

[0209] In some alternative implementations, the verification module 306 is further configured to:

[0210] The process involves: acquiring the target network interface card's (NIC) optional read-only memory (ROM) hardware information and extracting write protection status parameters; generating an unlock command based on the write protection status parameters and preset unlock rules, sending it to the target NIC's control register, and obtaining write protection unlock confirmation information; splitting the target image according to preset data block splitting rules to obtain a data block set; acquiring the preset starting storage address of the target NIC's optional ROM and allocating target storage addresses for each data block based on the sorting order of the data block set, resulting in an address allocation table; transmitting the data block set block by block to the target NIC's optional ROM according to the address allocation table and preset data transmission protocol, obtaining a data transmission completion signal; generating a firmware verification command based on the data transmission completion signal and sending it to the target NIC, and receiving the image verification result returned by the target NIC; generating a firmware update confirmation command based on the image verification result, and completing the flashing of the target image.

[0211] In some alternative implementations, loading module 307 is specifically used for:

[0212] The system receives a trigger command to initiate the pre-boot execution environment process, triggering the client to call the target network interface card's (NIC) optional ROM image; loads the preset firmware control module from the NIC and completes its initialization, obtaining the resource scheduling interface of the firmware control module; loads the dual-environment adaptation driver module through the resource scheduling interface, matching it with the currently running basic input / output system environment or unified extensible firmware interface environment; reads the preset peripheral component interconnect high-speed configuration information of the target NIC based on the dual-environment adaptation driver module, allocating the corresponding peripheral component interconnect high-speed resources; detects the target NIC's rate negotiation and link status, generating link configuration parameters; sets the target NIC's media access control address and enables the network interface based on the peripheral component interconnect high-speed resources and link configuration parameters, completing the NIC hardware configuration; sends a Dynamic Host Configuration Protocol (DHCP) broadcast request through the firmware control module to obtain network configuration information; sends a read request to the preset server based on the network configuration information to obtain the boot image file; parses the boot image file to obtain the kernel path and memory disk path, and downloads the corresponding kernel file and initial memory disk file.

[0213] In some alternative implementations, loading module 307 is further configured to:

[0214] The hardware access interface of the dual-environment adaptation driver module reads the vendor identifier and device identifier in the high-speed configuration space of the peripheral component interconnection of the target network card; based on the preset high-speed resource allocation rules of peripheral component interconnection, it allocates memory address space and interrupt request number to the target network card corresponding to the vendor identifier and device identifier; and writes the allocated memory address space and interrupt request number into the configuration register of the target network card to complete the allocation of high-speed resources of peripheral component interconnection.

[0215] For a description of the features in the embodiment corresponding to the driver loading device of the pre-boot execution environment, please refer to the relevant description of the embodiment corresponding to the driver loading method of the pre-boot execution environment, which will not be repeated here.

[0216] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 40 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the electronic device 40 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus.

[0217] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to execute the above-described driver loading method embodiment for the pre-boot execution environment.

[0218] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0219] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0220] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0221] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0222] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described pre-boot execution environment driver loading method embodiments at runtime.

[0223] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0224] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described pre-boot execution environment driver loading method embodiments.

[0225] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described pre-boot execution environment driver loading method embodiments.

[0226] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0227] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software 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.

[0228] The foregoing has provided a detailed description of the driver loading method and electronic device for a pre-boot execution environment provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A driver loading method for a pre-boot execution environment, characterized in that, include: Obtain the driver file corresponding to the target network card; The driver file is decompiled to obtain program structure information; Extract the target module that matches the function of the pre-boot execution environment from the program structure information, and perform code trimming and compression on the target module to obtain a lightweight driver module; The lightweight driver module is adapted to a preset basic input / output system environment and a unified scalable firmware interface environment to obtain a dual-environment adaptation driver module. The dual-environment adaptation driver module is integrated with the preset firmware control module and the preset reserved expansion module to obtain the option read-only memory image; The option read-only memory image is compiled and verified, and the verified option read-only memory image is flashed to the option read-only memory of the target network card; When a trigger instruction to start the pre-boot execution environment process is received, the option read-only memory image is invoked and the dual-environment adaptation driver module is loaded from the option read-only memory image.

2. The driver loading method for the pre-boot execution environment according to claim 1, characterized in that, The driver file is decompiled to obtain program structure information, including: The driver file is decompiled using a pre-defined disassembler to obtain the initial assembly code; The initial assembly code is structured based on preset syntax parsing rules, and the corresponding function call relationships and hardware interaction logic are extracted. The initial assembly code, function call relationships, and hardware interaction logic are integrated to obtain program structure information that includes the division of driver function modules.

3. The driver loading method for the pre-boot execution environment according to claim 1, characterized in that, The target module matching the functions of the pre-boot execution environment is extracted from the program structure information, and the target module is then processed by code trimming and compression to obtain a lightweight driver module, including: Based on the preset pre-boot execution environment function list, matching functional code fragments are selected from the program structure information to obtain the first target module; The redundant code segments that depend on the operating system in the first target module are extracted and deleted to obtain the second target module; The code of the second target module is trimmed to remove debugging information and unused program branches, resulting in the third target module. The constant data of the third target module is compressed using a preset compression algorithm to obtain a lightweight driving module.

4. The driver loading method for the pre-boot execution environment according to claim 1, characterized in that, The lightweight driver module is adapted to both the basic input / output system environment and the unified extensible firmware interface environment to obtain a dual-environment adapted driver module, including: The interrupt call interface of the lightweight driver module is replaced with the standard interrupt interface of the preset basic input / output system by using preset interface replacement rules. An initialization entry function and an execution entry function are generated based on the preset peripheral component interconnection option read-only memory specification and added to the lightweight driver module to obtain a first driver unit adapted to the basic input / output system; By using a pre-defined framework encapsulation rule for a unified and scalable firmware interface, the lightweight driver module is structurally encapsulated to obtain a second driver unit with a unified and scalable firmware interface. The first function corresponding to the network transceiver protocol and the second function corresponding to the file loading protocol are retrieved from the preset protocol function library and added to the second driver unit; The matching rules for the current operating environment are determined by reading the preset system table signature or the basic input / output system interrupt flag. The first driving unit, the second driving unit, and the matching rules are integrated to obtain a dual-environment adaptation driving module.

5. The driver loading method for the pre-boot execution environment according to claim 1, characterized in that, The dual-environment adaptation driver module is integrated with the preset firmware control module and the preset reserved expansion module to obtain an optional read-only memory image, including: Obtain the functional interface definition of the preset firmware control module and the extension interface definition of the preset reserved extension module; The standardized interaction interface of the dual-environment adaptation driver module is adapted and connected with the functional interface definition and the extended interface definition; According to the preset modular integration rules, the dual-environment adaptation driver module, the preset firmware control module, and the preset reserved extension module are combined and compiled to obtain the optional read-only memory image.

6. The driver loading method for the pre-boot execution environment according to claim 1, characterized in that, The process includes compiling and verifying the Option ROM image, and then flashing the verified Option ROM image to the Option ROM of the target network card. The system version image is obtained by compiling the option read-only memory image of the corresponding version of the basic input / output system using a preset cross-compilation tool; The system version image is verified to obtain the system verification result; Compile the option read-only memory image corresponding to the version of the unified extensible firmware interface to obtain the interface version image; The protocol support capabilities of the interface version image are verified by using a preset interactive environment to obtain the interface version verification result. Read the capacity parameter of the option read-only memory of the target network card; The sizes of the system version image and the interface version image are compared with the capacity parameter to obtain the capacity matching result; Based on the system verification results, interface version verification results, capacity matching results, and preset verification conditions, target images that meet the preset verification conditions are selected. The target image is flashed into the target network card's optional read-only memory.

7. The driver loading method for the pre-boot execution environment according to claim 6, characterized in that, The option to write the target image to the target network card's read-only memory includes: Obtain the target network card's option read-only memory hardware information and extract the write-protected status parameters; Based on the write protection status parameters and preset unlocking rules, an unlocking command is generated and sent to the control register of the target network card to obtain write protection unlocking confirmation information; The target image is split according to a preset data block splitting rule to obtain a data block set; The target network card's option read-only memory preset starting storage address is obtained, and the target storage address corresponding to each data block is allocated based on the sorting order of the data block set to obtain the address allocation table; According to the address allocation table and the preset data transmission protocol, the data block set is transmitted block by block to the target network card's optional read-only memory, and a data transmission completion signal is obtained; Based on the data transmission completion signal, a firmware verification command is generated and sent to the target network card, and the image verification result returned by the target network card is received. Based on the image verification result, a firmware update confirmation command is generated to complete the flashing of the target image.

8. The driver loading method for the pre-boot execution environment according to claim 1, characterized in that, When a trigger instruction to start the pre-boot execution environment process is received, the option read-only memory image is invoked and the dual-environment adaptation driver module is loaded from the option read-only memory image, including: Receive the trigger command to start the pre-boot execution environment process, triggering the client to call the target network card's option read-only memory image; Load the preset firmware control module from the selected read-only memory image and complete its initialization, then obtain the resource scheduling interface of the firmware control module. The dual-environment adaptation driver module is loaded through the resource scheduling interface and matched with the currently running basic input / output system environment or unified extensible firmware interface environment. Based on the dual-environment adaptation driver module, the preset high-speed configuration information of peripheral component interconnection of the target network card is read, and the corresponding high-speed resources of peripheral component interconnection are allocated. The rate negotiation and link status of the target network interface card are detected, and link configuration parameters are generated; Based on the high-speed interconnection resources of the peripheral components and the link configuration parameters, the media access control address of the target network card is set and the network interface is enabled to complete the network card hardware configuration; The firmware control module sends a Dynamic Host Configuration Protocol (DHCP) broadcast request to obtain network configuration information. Based on the network configuration information, a read request is sent to a preset server to obtain the boot image file; The boot image file is parsed to obtain the kernel path and memory disk path, and the corresponding kernel file and initial memory disk file are downloaded.

9. The driver loading method for the pre-boot execution environment according to claim 8, characterized in that, Based on the dual-environment adaptation driver module, the preset high-speed configuration information of the target network card's peripheral component interconnection is read, and corresponding high-speed peripheral component interconnection resources are allocated, including: The hardware access interface of the dual-environment adaptation driver module reads the manufacturer identifier and device identifier in the high-speed configuration space of the peripheral component interconnection of the target network card. Based on the preset high-speed resource allocation rules for peripheral component interconnection, memory address space and interrupt request number are allocated to the target network card corresponding to the manufacturer identifier and the device identifier; The allocated memory address space and interrupt request number are written into the configuration register of the target network card to complete the allocation of high-speed resources for peripheral component interconnection.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the driver loading method for the pre-boot execution environment as described in any one of claims 1 to 9 when executing the computer program.

Images