Device driving method and apparatus, electronic device, and readable storage medium

Abstract

The application discloses a device driving method and device, electronic equipment and readable storage medium, and belongs to the technical field of computers. A read command sent by a driving scanning program preset in a target firmware in a first storage device is used to read a driving image file from a second storage device; and the driving image file is loaded based on the driving scanning program to drive a corresponding hardware device. In this way, the second storage device is used as a driving carrier, and the driving image file is actively read and loaded by using the driving scanning program preset in the target firmware, so that the hardware driving and the target firmware are decoupled, and the flexibility of driving deployment and update is improved. Further, in the scene of modifying or updating the driving related content, the main body of the target firmware does not need to be modified or recompiled, and only the modified or updated driving image file needs to be written into the second storage device, so that the driving support for the non-standard hardware device can be completed, and the process of driving deployment and update is simplified.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a device driving method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] UEFI (Unified Extensible Firmware Interface), as a next-generation firmware interface standard, often assumes the responsibility of hardware initialization and operating system booting. Drivers for standard hardware devices are typically integrated directly into the UEFI firmware code.

[0003] In practical applications, there is often a need to expand non-standard hardware devices. For example, computer equipment may require the integration of specific function cards or peripherals implemented using FPGAs (Field-Programmable Gate Arrays). Currently, the common approach is to submit the driver source code of the hardware device to a UEFI firmware developer, who then compiles and integrates it into the firmware image.

[0004] However, the above solution has obvious shortcomings: any driver-related modifications or updates require recompiling the entire UEFI firmware and conducting comprehensive testing, which is a complex process with poor flexibility. Summary of the Invention

[0005] To overcome the problems existing in related technologies, the present invention provides a device driving method, apparatus, electronic device, and readable storage medium.

[0006] In a first aspect, embodiments of this application provide a device driving method, the method comprising: Based on the read command sent by the driver scanning program pre-installed in the target firmware, the driver image file is read from the second storage device; the target firmware is deployed in the first storage device for booting the system. The driver image file is loaded based on the driver scanning program to drive the hardware device corresponding to the driver image file.

[0007] Secondly, embodiments of this application provide a device driving apparatus, the apparatus comprising: The first reading module is used to read the driver image file from the second storage device based on the read command sent by the driver scanning program pre-installed in the target firmware; the target firmware is deployed in the first storage device for booting the system. The first driver module is used to load the driver image file based on the driver scanning program, so as to drive the hardware device corresponding to the driver image file.

[0008] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0010] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0011] In this embodiment, a driver image file is read from a second storage device based on a read command sent by a driver scanning program pre-installed in the target firmware; the target firmware is deployed in a first storage device; and the driver image file is loaded based on the driver scanning program to drive the hardware device corresponding to the driver image file. Thus, by storing the driver image file in a second storage device independent of the target firmware, using this independent second storage device as the driver carrier, and utilizing the driver scanning program pre-installed in the target firmware to actively read and load the driver image file, decoupling the hardware driver from the target firmware is achieved, improving the flexibility of driver deployment and updates. Furthermore, in scenarios where driver-related content needs modification or updating, there is no need to modify or recompile the target firmware body; simply writing the modified or updated driver image file to the second storage device is sufficient to complete driver support for non-standard hardware devices, simplifying the driver deployment and update process. Attached Figure Description

[0012] Figure 1 This is a flowchart of the steps of a device driving method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the system architecture corresponding to a device driving method provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the specific steps of a device driving method provided in an embodiment of the present invention; Figure 4 This is a structural diagram of a device driving device provided in an embodiment of the present invention; Figure 5 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0013] 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0015] The device driving method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0016] Figure 1 This is a flowchart of the steps of a device driving method provided in an embodiment of the present invention, as follows: Figure 1 As shown, the method may include: Step 101: Read the driver image file from the second storage device based on the read command sent by the driver scanning program pre-installed in the target firmware; the target firmware is deployed in the first storage device.

[0017] In this embodiment of the invention, the first storage device can be an SPI Flash chip connected to the processor, and the second storage device can be an SPI Flash chip indirectly connected to the processor via a bridge chip. The first storage device is independent of the second storage device. The first storage device contains target firmware, which integrates a pre-built driver scanning program for automatic driver loading. The target firmware can refer to the platform UEFI firmware deployed in the first storage device, used to boot the operating system after the driver image file is loaded.

[0018] For example, the process of generating a driver scanner can be as follows: the developer writes a driver scanner source code that conforms to the UEFI specification, compiles it with a UEFI compiler to generate a binary image in PE / COFF format, and then uses a toolchain to package the binary image into a UEFI executable file (e.g., an .efi format file), which is finally burned into the first storage device as part of the target firmware.

[0019] The second storage device stores a driver image file. The driver image file can be a binary file in a specific format, compiled from a UEFI driver used to drive the hardware device. This specific format binary file can be an executable image conforming to a predetermined driver format. The predetermined driver format can be a driver format conforming to the UEFI specification. The driver image file may contain the driver's executable code, protocol interface table, and digital signature information. The driver image file can be read and loaded for execution by the driver scanning program of the target firmware.

[0020] The processor first reads and executes the target firmware from the first storage device. When the target firmware reaches the Driver Execution Environment (DXE) stage, the pre-installed driver scanner within the target firmware is triggered. The driver scanner sends a read command to the second storage device to read the driver image file stored there. After reading the driver image file from the second storage device, the driver image file can be stored in a designated memory location for the driver scanner to load, such as a temporary buffer area in system memory.

[0021] Step 102: Load the driver image file based on the driver scanning program to drive the hardware device corresponding to the driver image file.

[0022] In this embodiment of the invention, after the driver scanning program obtains the driver image file, it calls the driver loading interface in the Boot Services provided by the target firmware to load the driver image file from system memory to runtime memory space. Subsequently, the driver scanning program calls the target startup interface in Boot Services, which transfers control to the entry address field of the driver image file. The driver program corresponding to the driver image file will complete the initialization and configuration of the corresponding hardware device. For example, after the driver image file is loaded, the driver scanning program can call the DriverBindingProtocol.Supported() function of the driver binding protocol of the target firmware to perform protocol matching between the driver program corresponding to the loaded driver image file and the corresponding hardware device. The device identifiers declared inside the driver (e.g., VendorID, DeviceID) can be matched with the device identifiers of the hardware devices to be driven. When a match is successful, DriverBindingProtocol.Start() is called, and the driver program will be activated and executed. After activation, the driver scanner starts executing the hardware initialization instruction sequence inside the driver from the entry address field of the driver image file, such as 0x1000. It performs operations such as register configuration, resource allocation and function enabling on the hardware device according to the predefined instruction sequence, thereby completing the initialization of the hardware device and putting it into a working state that can be recognized and used by the operating system.

[0023] In summary, in this embodiment of the invention, a driver image file is read from a second storage device based on a read command sent by a driver scanning program pre-installed in the target firmware; the target firmware is deployed in a first storage device; and the driver image file is loaded based on the driver scanning program to drive the hardware device corresponding to the driver image file. Thus, by storing the driver image file in a second storage device independent of the first storage device where the target firmware resides, using this independent second storage device as the driver carrier, and utilizing the driver scanning program pre-installed in the target firmware to actively read and load the driver image file, decoupling the hardware driver from the target firmware is achieved, improving the flexibility of driver deployment and updates. Furthermore, in scenarios where driver-related content needs modification or updating, there is no need to modify or recompile the main target firmware; simply writing the modified or updated driver image file to the second storage device is sufficient to support non-standard hardware devices, simplifying the driver deployment and update process.

[0024] Furthermore, since the second storage device is an SPI Flash chip connected to the bridge chip, and SPI Flash chips are often existing hardware resources in the system, this solution fully utilizes the existing hardware resources of the bridge chip's SPI Flash, eliminating the need for additional ROM chips. This is because existing technologies rely on Option Read-Only Memory (OPM) mechanisms, which require additional programmable read-only memory (ROM) and Peripheral Component Interconnect (PCI) interfaces, thus increasing hardware costs and design complexity. This solution is more stable and reliable, as it is independent of any PCI device and does not rely on the standard Option ROM mechanism, enabling direct management of the general-purpose storage area and reducing design complexity. Moreover, since standard UEFI firmware lacks the ability to scan driver images in the general-purpose area of ​​the bridge chip's SPI Flash, this solution overcomes this limitation by pre-installing a driver scanning program in the target firmware. This allows the driver scanning program to actively read and load driver image files from an independent SPI Flash chip.

[0025] Optionally, embodiments of the present invention may further include the following steps: Step 201: Initialize the target firmware.

[0026] Step 202: In the driver execution environment stage, the driver scanning program configures the storage controller based on the register set base address, so that the storage controller accesses the second storage device after responding to the read command sent by the driver scanning program.

[0027] In this embodiment of the invention, after the computer device is powered on, the processor resets and loads and executes the early initialization (PEI) phase code from the first storage device to complete the initialization of basic hardware such as the processor core, memory controller, and bridge chip. After the early initialization (PEI) phase is completed, the UEFI firmware enters the driver execution environment (DXE) phase.

[0028] During the Driver Execution Environment (DXE) phase, the driver scheduler (DXE Dispatcher) in the target firmware loads all DXE Drivers sequentially according to their dependencies. At this time, the driver scanner in the target firmware acts as a custom-developed DXE Driver. Its entry function is recognized and called by the driver scheduler, and the driver scanner begins initialization. After completing its own module initialization, it enters the execution flow of the driver scanner.

[0029] The driver scanning program accesses the register set in the bridge chip where the memory controller is deployed, based on the register set base address, and completes parameter writing through the processor's memory-mapped I / O operations. The memory controller can be an SPI Flash controller. The second storage device is connected to the bridge chip with the memory controller deployed via a memory bus, which can be an SPI bus.

[0030] The register set base address can be determined based on the controller register memory mapping table defined in the datasheet of the bridge chip on which the memory controller is deployed. For example, taking the LS7A2000 bridge chip as an example, the register set base address of its memory controller can be 0x1FE0_XX00.

[0031] Specifically, the driver scanning program can configure multiple configuration registers within the memory controller sequentially, starting with the register set base address as the offset. Configuration items may include, but are not limited to: clock divider (used to set the SPI clock frequency), operating mode (used to set the clock polarity and phase to match the communication protocol of the second memory device), command frame format (used to set the read command), chip select enable (used to enable the CS pin of the second memory device), and transmission length (used to set the number of bytes per read / write operation).

[0032] For example, the driver scanning program can read preset default SPI parameters from its own code (e.g., clock divider parameter of 4, operating mode parameter of CPOL=0 or CPHA=0, command frame=0x03, chip select parameter of CS0, and transmission length parameter of 256 bytes), and write them sequentially to the configuration registers of the memory controller via MMIO using 0x1FE0_XX00 as the base address. This completes the operating mode configuration and puts the memory controller into a ready state. After completing the above register configuration, the driver scanning program has completed the operating mode configuration of the memory controller, putting it into a ready state that can respond to external read commands and access the second storage device.

[0033] In this embodiment of the invention, by initializing the target firmware and by having the driver scanning program autonomously configure the storage controller based on the register group base address, a communication path is actively established with the second storage device, thereby laying the communication foundation for the driver scanning program to read the driver scanning file in the second storage device.

[0034] Optionally, embodiments of the present invention may further include the following steps: Step 301: For the hardware device to be driven, generate a driver file corresponding to the hardware device based on the device parameters of the hardware device.

[0035] In this embodiment of the invention, for the hardware device to be driven, a driver file corresponding to the hardware device can be generated based on the device parameters of the hardware device. The hardware device to be driven can be a hardware peripheral connected to the processor via a bridge chip, such as an FPGA device. If the hardware device to be driven does not have platform-wide UEFI driver support, a separate driver program needs to be developed to complete its initialization and function enabling.

[0036] Based on the device parameters of the hardware device, a driver file corresponding to that hardware device is generated. The device parameters can be structured data extracted from the hardware device's specification sheet, describing the hardware characteristics of the device. Device parameters may include, but are not limited to: register base address, register bit field definitions, interrupt number, device ID, vendor ID, bus type, clock frequency, and initialization timing parameters. The driver file can be a file conforming to the UEFI specification.

[0037] For example, the INF file, DEC file, and C source code file can be configured separately to generate the driver file corresponding to the hardware device. Specifically, the driver's metadata, including driver name, version number, list of supported device IDs, and loading priority, can be filled in the driver description file (INF file); the UEFI protocol interface implemented by the driver can be declared in the driver protocol declaration file (DEC file), including the driver binding protocol and the device path protocol; and the hardware register read / write functions can be implemented based on the register base address and bit field definition in the device parameters, and the device detection and matching functions can be implemented based on the device ID.

[0038] Step 302: Compile the driver file to generate the driver image file and store it in the second storage device.

[0039] In this embodiment of the invention, after the driver file is generated, it can be compiled using compilation tools. The compilation tools may include a compiler, an assembler, and a linker. The compilation tools can perform preprocessing, compilation, assembly, and linking operations on the driver file according to the UEFI specification. Specifically, the compiler can translate the C language source code file into target machine code, the assembler can convert the assembly instruction file into an object file, and the linker can merge the target machine code and the object file, and parse the protocol interface references declared in the driver file, ultimately generating a binary file conforming to a predetermined driver format, resulting in an executable driver image file. The predetermined driver format can be the .efi format corresponding to the UEFI specification.

[0040] In this embodiment of the invention, by generating an executable driver image file with a predetermined driver format, the driver image file can be uniformly scheduled by the subsequent driven scanning program through a standard interface without the need for customized loading logic, thus avoiding the impact of non-standard drivers on firmware stability.

[0041] Optionally, embodiments of the present invention may further include the following steps: Step 401: Determine free storage space in the second storage device.

[0042] In this embodiment of the invention, free storage space is provided in the second storage device. The free storage space can be a contiguous or non-contiguous address range in the second storage device that is not covered by critical system data or other occupied data and is available for free allocation.

[0043] For example, for a bridge chip of model LS7A2000, the initial portion of the address range of the second storage device already stores critical system data. Specifically, the first 0x20 bytes at offset 0x0000 of the second storage device are used to store critical system information such as the MAC address of the bridge chip's network interface card. This 0x20-byte area has its write-protected bit (WP) enabled by a write-enable instruction, thus preventing this area from being overwritten or modified. Therefore, the starting address of the free storage space can be determined as offset 0x1000, that is, the remaining address range after skipping the first 0x1000 bytes of occupied area.

[0044] Step 402: Set a designated storage area in the free storage space and store the driver image file in the designated storage area for the driver scanning program to read.

[0045] In this embodiment of the invention, a designated storage area is partitioned within the free storage space. This designated storage area can be all or part of the free storage space; the partitioning can be tailored to specific needs, and this embodiment does not impose any limitations. After partitioning the designated storage area, the driver image file is stored there. Specifically, a burning tool or burning software can be used to write the compiled driver image file into the designated storage area of ​​the second storage device.

[0046] For example, if the starting address of the specified storage area is set to an offset of 0x1000, the programming tool can use the starting address of the specified storage area, i.e., setting the offset to 0x1000, as the write base address, and write the binary data of the driver image file page by page through the SPI bus according to the page programming rules of SPI Flash. During the writing process, the programming tool can first perform an erase operation on the target pages in the specified storage area, and then program and write the corresponding data segments of the driver image file through write enable instructions, until the complete driver image file is written to the specified storage area.

[0047] In this embodiment of the invention, by determining free storage space and dividing it into designated storage areas in the second storage device, the driver image file is independently stored in the designated storage area, thus achieving complete decoupling between the driver file and the target firmware of the motherboard. In this way, utilizing the redundant area of ​​the second storage device as an independent driver storage area eliminates the need to modify the main target firmware, improving firmware maintenance efficiency. Furthermore, the driver image file is stored directly in binary form on the second storage device. Driver iteration can be completed simply by updating the image file in the designated storage area using a flashing tool, without needing to re-flash the entire firmware, improving hardware deployment efficiency and flexibility.

[0048] Optionally, step 101 may include the following steps: Step 501: Based on the driver scanning program, send a read command to the storage controller.

[0049] In this embodiment of the invention, the driver scanning program uses the register set base address as the access entry point and writes a read command to the command register of the storage controller through the processor's memory-mapped I / O operations. The read command may include a read address and a specified data size. The read address can be used to indicate the starting position of a specified storage area in the second storage device, and the specified data size can be used to define the length of bytes to be read. Its value can be predetermined based on the actual size of the driver image file or the size of the specified storage area; for example, the specified data size can be the size of the specified storage area.

[0050] Step 502: Using the storage controller, based on the read address indicated by the read command and the specified data size, read the target data in the second storage device via the storage bus; the read address is used to indicate the starting address of the specified storage space, and the target data is continuous data starting from the starting address indicated by the read address and having a size equal to the specified data size.

[0051] In this embodiment of the invention, after the driver scanning program completes the writing to the command register, the storage controller immediately responds, parses the read command into an SPI bus protocol signal sequence, and initiates chip select enable and address transfer operations to the second storage device through the storage bus.

[0052] After receiving a valid chip select signal and a read address, the second storage device, starting from the read address, transmits the binary data within the specified storage area byte by byte back to the storage controller via the SPI bus data output signal, according to the length defined by the specified data size. Furthermore, the storage controller can temporarily store the read target data in its internal receive buffer. The driver scanning program can then read the storage controller's data registers to store the target data from the receive buffer into a pre-allocated temporary buffer in system memory. The capacity of this temporary buffer is greater than or equal to the specified data size to ensure data integrity.

[0053] Step 503: Determine the driver image file that conforms to the predetermined driver format from the target data.

[0054] In this embodiment of the invention, the driver scanning program performs format recognition processing on the target data. Specifically, the driver scanning program can start from the beginning position of the target data in the temporary buffer and search byte by byte for a lookup identifier corresponding to the predetermined driver format. The lookup identifier corresponding to the predetermined driver format can be a file header marker corresponding to the predetermined driver format; for example, the lookup identifier can be "MZ".

[0055] When the driver scanning program detects a lookup identifier corresponding to a given driver format in the target data, it can identify the target data as a valid driver image file that conforms to the given driver format, and further parse the file header corresponding to the lookup identifier to extract information such as the entry address, code segment size, and protocol interface table of the driver program in the driver image file.

[0056] If no lookup identifier corresponding to the specified driver format is detected, the driver scanning program can determine that there is no valid driver image file in the specified storage area, return an error status, and terminate the current driver loading process.

[0057] For example, the specified data size can be set to the size of a specified storage area. A read command can then read all the data from the specified storage area based on the read address, and use it as the target data. Assuming the read command instruction word is 0x03, the specified data size indicated by the read command is 0x8000 bytes, and the read address is 0x1000, after receiving the read command, the storage controller sends the 0x03 command code + address field to the second storage device through the storage bus. The second storage device then sends back 0x8000 bytes byte by byte from address 0x1000 to the storage controller's receive buffer. The driver scanning program then reads the data from the receive buffer and stores it in the system memory temporary buffer.

[0058] In this embodiment of the invention, the driver scanning program can actively read target data directly from the second storage device via the storage bus using read commands, without relying on the default block device driver of the target firmware, thus improving the flexibility of driver deployment to a certain extent. Simultaneously, the read address and specified data size are parameterized internally by the driver scanning program, rather than hard-coded into the firmware body. This allows the same driver scanning program to adapt to the partitioning plans of storage devices on different platforms, and can point to different storage areas by modifying configuration parameters without recompilation, enhancing its adaptability to diverse hardware layouts and deployment flexibility.

[0059] Optionally, after step 101, the embodiments of the present invention may further include the following steps: Step 601: Perform a validity check on the driver image file and obtain the check result.

[0060] In this embodiment of the invention, after reading the driver image file from the second storage device and writing it to a temporary buffer, the driver scanning program can perform a validity check on the driver image file and obtain the check result. The driver scanning program can perform a validity check on the driver image file, which may include integrity verification (e.g., hash value verification) and signature verification. For example, integrity verification (e.g., hash value verification) can be performed first, followed by signature verification.

[0061] Specifically, the driver scanner can first perform integrity verification on the driver image file. Integrity verification refers to calculating a checksum for the binary data of the driver image file according to a predefined algorithm (such as CRC32 or SHA-256) and comparing it with the checksum field contained in the driver image file. If they match, the checksum verification passes, and digital signature verification can continue; if they do not match, it is determined that the driver image file has been tampered with or corrupted during transmission or storage, the verification result is verification failure, the driver scanner terminates the loading process of the current driver image file, and no longer calls subsequent interfaces.

[0062] After successful verification, the driver scanning program then performs digital signature verification on the driver image file. Digital signature verification involves using the public key in the target firmware to decrypt and compare the digital signature carried in the driver image file to confirm that the driver image file was issued by the authorized party and has not been tampered with. If the signature verification passes, the verification result indicates successful verification, and the driver image file will be loaded into system memory; if the signature verification fails, the verification result indicates failure, the driver image file has been tampered with, and the program will skip this driver image file and continue searching for the next driver image file in the target data.

[0063] Accordingly, step 102 may include: Step 602: If the verification result indicates successful verification, load the driver image file based on the driver scanning program to drive the hardware device corresponding to the driver image file.

[0064] In this embodiment of the invention, if the verification result indicates successful verification, the driver scanning program will load the driver image file to drive the hardware device corresponding to the driver image file.

[0065] If the verification result indicates that the verification fails, the driver scanning program can skip the driver image file and continue searching for the next valid driver image file in the target data before performing a validity check.

[0066] For example, if there are multiple driver image files corresponding to multiple hardware devices, these driver image files can be stored sequentially in a designated storage area of ​​the second storage device using a data structure that is contiguous from beginning to end. If the verification result of a driver image file indicates that the verification fails, that driver image file can be skipped, and the search can begin byte-by-byte from the next byte after the current end position of that driver image file to find the next driver image file that conforms to the predetermined driver format.

[0067] In this embodiment of the invention, by performing a legality verification on the driver image file, namely a dual verification mechanism of verification and digital signature verification, it is possible to ensure that the file source is trustworthy and the data is complete before the driver image file is loaded, thereby ensuring the security and reliability of the hardware device initialization process and improving the security level of the driver loading stage.

[0068] Optionally, step 102 may include the following steps: Step 701: Load the driver image file into system memory.

[0069] In this embodiment of the invention, after the driver scanning program locates the driver image file in the target data according to the predetermined driver format, and stores the driver image file in a temporary buffer, the driver scanning program can call the target loading interface to load the driver image file in the temporary buffer into system memory. Specifically, after completing the identification of the driver image file, the driver scanning program can use the confirmed valid driver image file in the temporary buffer as an input parameter and call the target loading interface to load it into system memory. The target loading interface can be UEFI BootService LoadImage, which is a boot service interface defined by the UEFI specification. Its function is to load driver image files conforming to the predetermined driver format into system memory and complete relocation and permission verification.

[0070] Step 702: The driver scanning program executes the driver entry function in the driver image file in the system memory to drive and initialize the hardware device.

[0071] In this embodiment of the invention, after the target loading interface returns a successful loading status, the driver scanning program can call the target boot interface to locate the driver image file already loaded in system memory based on the image handle of the driver image file. It then reads the entry address field (i.e., the driver entry function) from the PE / COFF header and jumps the processor execution flow to this driver entry function, triggering the execution of the driver image file in system memory. The target boot interface can be UEFIBoot Service StartImage, which is a boot service interface defined by the UEFI specification. Its function is to call the entry address field (i.e., the driver entry function) of the driver image file already loaded into system memory to start the execution flow of the driver program.

[0072] For example, after the driver entry function begins execution, it can first complete the runtime initialization of the driver itself corresponding to the driver image file, including establishing the protocol interface required by the driver and allocating the runtime memory pool. The driver entry function is the function at the entry address pointed to by the ImageBase field in the PE / COFF header of the driver image file, which is the location of the first executable instruction of the driver.

[0073] After driver initialization is complete, the driver entry function can write to the registers and configure the functions of the corresponding hardware device according to its internal hard-coded or configured hardware device parameters, thereby completing the power-on initialization of the hardware device. After initialization, the driver can return a success status code to the driver scanner.

[0074] In one possible implementation, after receiving a success status, the driver scanning program can return to the next offset address of the already searched position in the temporary buffer and continue searching for the next driver image file in the target data based on the lookup identifier corresponding to the predetermined driver format, until the target data search is completed or an error status is returned, terminating the process. Different driver image files can correspond to different hardware devices. It can be understood that, depending on the different device driver designs, different driver image files can correspond to the device functions of different hardware devices. Accordingly, in this scenario, loading the driver image file based on the driver scanning program can drive the device functions of the corresponding hardware device.

[0075] In this embodiment of the invention, the driver image file is actively read from the second storage device by the driver scanning program, and the driver image file is actively loaded and executed. That is, the target loading interface LoadImage and the target startup interface StartImage are actively called. It does not rely on the default driver loading mechanism of the target firmware. Custom drivers can be loaded from non-first storage devices, that is, any storage location, as needed, which improves the flexibility and controllability of hardware adaptation. At the same time, it is suitable for dynamic driver loading scenarios of non-standard devices such as FPGA.

[0076] For example, Figure 2 A schematic diagram of the system architecture corresponding to a device driver method is shown, such as... Figure 2 As shown, the computer device includes a processor and a bridge chip, which are connected via an HT bus. The processor is connected to a first storage device (SPI Flash 1), which stores the system target firmware, i.e., the main UEFI firmware. The bridge chip, which has a storage controller deployed, is connected to a second storage device (SPI Flash 2) via a storage bus, i.e., the SPI bus, and to hardware devices via a Low Pin Count Bus (LPC). In the second storage device (SPI Flash 2), the first 0x20 bytes (offset 0x0000-0x001F) are used to store critical information such as the MAC address of the built-in network card in the bridge chip. The remaining contiguous space starting at offset 0x1000 can then be designated as a storage area to store the driver image file corresponding to the built-in network card, for loading by the driver scanning program in SPI Flash 1.

[0077] For example, Figure 3 A flowchart illustrating the specific steps of a device driving method is shown, such as... Figure 3As shown, upon system power-up, the UEFI firmware (target firmware) begins initialization, entering the DXE stage. In the DXE stage, the driver scanning program in the UEFI firmware is executed, and the SPI Flash controller is configured through this program. The driver scanning program then reads target data from the second storage device. Based on the lookup identifier corresponding to the predetermined driver format, the driver scanning program matches a valid driver image file in the target data using the lookup identifier, and verifies the validity of the driver image file through integrity verification (e.g., hash value verification) and signature verification. If the verification result indicates successful verification, the driver scanning program calls UEFIBoot Service LoadImage to load the driver image file into system memory; then it calls UEFI Boot Service StartImage to execute the driver entry function of the driver image file, thereby driving and initializing the corresponding hardware device, such as an FPGA, thus enabling driver support for non-standard hardware devices. If the verification result indicates failure, the driver image file is skipped, and the program continues to match the next driver image file in the target data using the lookup identifier, and then performs validity verification.

[0078] In one possible implementation, for driver image files whose verification results indicate verification failure, corresponding error message information can be output after verification is completed. For example, the identifier of the driver image file, the reason for failure (such as signature verification failure, integrity verification failure, etc.) and the failure timestamp can be recorded to facilitate subsequent investigation and auditing.

[0079] It should be noted that the device driver method provided in this application embodiment can be executed by a device driver device, or a control module in the device driver device for executing the loading device driver method. This application embodiment uses the execution of the loading device driver method by a device driver device as an example to illustrate the device driver device provided in this application embodiment.

[0080] Figure 4 This is a structural diagram of a device driving apparatus provided in an embodiment of this application, with reference to... Figure 4 The device may include: The first reading module 801 is used to read the driver image file from the second storage device based on the read command sent by the driver scanning program pre-installed in the target firmware; the target firmware is deployed in the first storage device for booting the system. The first driver module 802 is used to load the driver image file based on the driver scanning program in order to drive the hardware device corresponding to the driver image file.

[0081] This invention provides a device driver apparatus that reads a driver image file from a second storage device based on a read command sent by a driver scanning program pre-installed in the target firmware; the target firmware is deployed in a first storage device; and the driver image file is loaded based on the driver scanning program to drive the hardware device corresponding to the driver image file. By storing the driver image file in a second storage device independent of the first storage device where the target firmware resides, using this independent second storage device as the driver carrier, and utilizing the driver scanning program pre-installed in the target firmware to actively read and load the driver image file, decoupling the hardware driver from the target firmware is achieved, improving the flexibility of driver deployment and updates. Furthermore, in scenarios where driver-related content needs modification or updating, there is no need to modify or recompile the target firmware; simply writing the modified or updated driver image file to the second storage device is sufficient to support non-standard hardware devices, simplifying the driver deployment and update process.

[0082] Optionally, the device further includes: The first processing module is used to initialize the target firmware; The first configuration module is used during the driver execution environment phase to configure the storage controller based on the register group base address, so that the storage controller accesses the second storage device after responding to the read command sent by the driver scanning program.

[0083] Optionally, the device further includes: The first generation module is used to generate a driver file corresponding to the hardware device based on the device parameters of the hardware device to be driven. The second generation module is used to compile the driver file, generate the driver image file, and store it in the second storage device.

[0084] Optionally, the device further includes: The first determining module is used to determine free storage space in the second storage device; The first storage module is used to set a designated storage area in the free storage space and store the driver image file in the designated storage area for the driver scanning program to read.

[0085] Optionally, the first reading module 801 includes: The first sending module is used to send a read command to the storage controller based on the driver scanning program; The first read submodule is used to read target data from the second storage device via the storage controller, based on the read address indicated by the read command and the specified data size, through the storage bus; the read address is used to indicate the starting address of the specified storage space, and the target data is continuous data starting from the starting address indicated by the read address and having a size equal to the specified data size; The second determining module is used to determine the driver image file that conforms to the predetermined driver format from the target data.

[0086] Optionally, the device further includes: The first verification module is used to verify the legality of the driver image file and obtain the verification result; The first driving module 802 includes: The first driver submodule is used to load the driver image file based on the driver scanning program, in order to drive the hardware device corresponding to the driver image file, if the verification result indicates that the verification is successful.

[0087] Optionally, the first driving module 802 includes: The first loading module is used to load the driver image file into system memory; The second driver submodule is used by the driver scanning program to execute the driver entry function in the driver image file in the system memory to drive and initialize the hardware device.

[0088] The device driving device in the embodiments of this application can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. The embodiments of this application do not impose specific limitations.

[0089] The device driver in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0090] Optional, such as Figure 5 As shown, this application embodiment also provides an electronic device, including a processor 910, a memory 909, and a program or instructions stored in the memory 909 and executable on the processor 910. When the program or instructions are executed by the processor 910, they implement the various processes of the above-described device driving method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0091] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0092] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described device driver method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0093] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0094] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described device driver method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0095] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0096] This application provides a computer program product that is stored in a storage medium and executed by at least one processor to implement the various processes of the device driver method embodiments described above, and achieves the same technical effects. To avoid repetition, further details are omitted here.

[0097] It should be noted that, in this document, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0098] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of 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. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0099] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A device driving method, characterized in that, The method includes: Based on the read command sent by the driver scanning program pre-installed in the target firmware, the driver image file is read from the second storage device; the target firmware is deployed in the first storage device for booting the system. The driver image file is loaded based on the driver scanning program to drive the hardware device corresponding to the driver image file.

2. The method according to claim 1, characterized in that, The method further includes: Initialize the target firmware; During the driver execution environment phase, the driver scanner configures the storage controller based on the register set base address, so that the storage controller accesses the second storage device after responding to the read command sent by the driver scanner.

3. The method according to claim 1, characterized in that, The method further includes: For the hardware device to be driven, a driver file corresponding to the hardware device is generated based on the device parameters of the hardware device; The driver file is compiled to generate the driver image file and stored in the second storage device.

4. The method according to claim 1, characterized in that, The method further includes: Determine free storage space in the second storage device; A designated storage area is set in the free storage space, and the driver image file is stored in the designated storage area for the driver scanning program to read.

5. The method according to claim 2, characterized in that, The process of reading the driver image file from the second storage device based on the read command sent by the driver scanning program pre-installed in the target firmware includes: Based on the driver scanning program, a read command is sent to the storage controller; The storage controller reads target data from the second storage device via the storage bus based on the read address indicated by the read command and the specified data size. The read address indicates the starting address of the specified storage space, and the target data is continuous data with a size equal to the specified data size, starting from the starting address indicated by the read address. The driver image file conforming to the established driver format is determined from the target data.

6. The method according to claim 1, characterized in that, The method further includes: performing a validity check on the driver image file to obtain a verification result; The process of loading the driver image file based on the driver scanning program includes: If the verification result indicates successful verification, the driver image file is loaded based on the driver scanning program to drive the hardware device corresponding to the driver image file.

7. The method according to any one of claims 1-6, characterized in that, The process of loading the driver image file based on the driver scanning program includes: Load the driver image file into system memory; The driver scanning program executes the driver entry function in the driver image file in the system memory to drive and initialize the hardware device.

8. A device drive mechanism, characterized in that, The device includes: The first reading module is used to read the driver image file from the second storage device based on the read command sent by the driver scanning program pre-installed in the target firmware; the target firmware is deployed in the first storage device for booting the system. The first driver module is used to load the driver image file based on the driver scanning program, so as to drive the hardware device corresponding to the driver image file.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the device driving method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the device driving method as described in any one of claims 1-7.

Images