Drive firmware generation method and device, electronic equipment and storage medium

Abstract

This application provides a driver firmware generation method, apparatus, electronic device, and storage medium. The method includes: loading a target base firmware to be compiled and determining a target candidate hardware list, the target candidate hardware list being used to record hardware information of different models; responding to a selection operation applied to the target candidate hardware list and determining a specific driver firmware based on the hardware information determined by the selection operation; and compiling the target driver firmware based on the target base firmware and the specific driver firmware to obtain the target driver firmware. This solution can select specific driver firmware as needed, effectively compress firmware size, avoid wasting chip memory resources, and improve chip operational stability.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a driver firmware generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] In fields such as smart commercial displays, automotive touchscreens, industrial human-machine interaction, and consumer electronics, display screens are the core carriers for human-machine interaction in various smart devices. Touchscreens produced by screen manufacturers all require dedicated drivers. The dedicated drivers of screens from different manufacturers or different models are incompatible. For a screen to achieve stable touch interaction and normal UI operation, it must be matched with a corresponding dedicated display driver chip.

[0003] In order to ensure that the display driver chip can drive screens from different manufacturers or different models, the basic firmware of the display driver chip needs to integrate a full range of dedicated drivers. This results in a large firmware size, occupies a large amount of chip memory, wastes memory resources, and affects the stability of chip operation. Summary of the Invention

[0004] This application provides a driver firmware generation method, apparatus, electronic device, and storage medium, which solves the problem in related technologies that the basic firmware of the display driver chip needs to integrate the full driver, which leads to a large firmware size, occupies a large amount of chip memory, causes resource waste, and affects the stability of chip operation. It realizes the selection of special driver firmware on demand, effectively compresses firmware size, avoids waste of chip memory resources, and also improves chip operation stability.

[0005] In a first aspect, embodiments of this application provide a driver firmware generation method, the method comprising:

[0006] Load the target base firmware to be compiled and determine the target candidate hardware list, which is used to record hardware information of different models; In response to a selection operation applied to the target candidate hardware list, a specific driver firmware is determined based on the hardware information determined by the selection operation. The target driver firmware is obtained by compiling based on the target base firmware and the special driver firmware.

[0007] Optionally, determining the target candidate hardware list includes: Access the candidate hardware library and generate an initial candidate hardware list based on the candidate hardware library; Based on the target basic firmware, the initial candidate hardware list is filtered for compatibility to obtain the target candidate hardware list.

[0008] Optionally, generating an initial list of candidate hardware based on the candidate hardware library includes: Read the metadata files corresponding to each candidate hardware from the candidate hardware library; The metadata file corresponding to each of the candidate hardware components is parsed to obtain the hardware information corresponding to each of the candidate hardware components. An initial list of candidate hardware is generated based on the hardware information corresponding to each of the candidate hardware components.

[0009] Optionally, the step of performing compatibility filtering on the initial candidate hardware list based on the target underlying firmware to obtain the target candidate hardware list includes: The target basic firmware is parsed to obtain firmware feature information; The initial candidate hardware list is filtered based on the firmware feature information to obtain the target candidate hardware list.

[0010] Optionally, determining the specific driver firmware based on the hardware information determined by the selection operation includes: The target firmware identifier is obtained by querying the preset mapping relationship based on the hardware information determined by the selection operation. Read the specific driver firmware corresponding to the target firmware identifier from the preset storage area.

[0011] Optionally, after generating the initial list of candidate hardware based on the candidate hardware library, the method further includes: Monitor hardware change events in the candidate hardware library in real time; Determine the incremental change information of the list based on the hardware change events; The initial list of candidate hardware is updated based on the incremental change information of the list.

[0012] Optionally, after accessing the candidate hardware library, the following steps are also included: Upon receiving a hardware update request from the candidate hardware library, the validity of the hardware update request is verified. If the hardware update request passes verification, hardware update information is extracted from the hardware update request; The candidate hardware library is incrementally updated based on the hardware update information.

[0013] Secondly, embodiments of this application also provide a driver firmware generation apparatus, which includes: Load the module, configured to load the target base firmware to be compiled; The first determining module is configured to determine a target candidate hardware list, wherein the target candidate hardware list is used to record hardware information of different models; The second determining module is configured to respond to a selection operation applied to the target candidate hardware list and determine a specific driver firmware based on the hardware information determined by the selection operation. The compilation module is configured to compile the target driver firmware based on the target base firmware and the special driver firmware.

[0014] Thirdly, embodiments of this application also provide an electronic device, which includes: one or more processors; and a storage device configured to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the driver firmware generation method described in embodiments of this application.

[0015] Fourthly, embodiments of this application also provide a non-volatile storage medium for storing computer-executable instructions, which, when executed by a computer processor, are configured to perform the driver firmware generation method described in embodiments of this application.

[0016] In this embodiment, determining the target candidate hardware list allows compatible hardware to be included in the selection range, providing suitable hardware entries. Determining the specific driver firmware based on the hardware information determined by the selection operation enables precise matching between hardware and drivers, flexibly adapting to user needs. Compiling the target driver firmware based on the target base firmware and the specific driver firmware allows only the user-selected specific driver to be retained, while maintaining firmware integrity. This solution allows for the selection of specific driver firmware as needed, effectively compressing firmware size, avoiding waste of chip memory resources, and improving chip operational stability. Attached Figure Description

[0017] Figure 1 A flowchart illustrating a driver firmware generation method provided in this application embodiment; Figure 2 A flowchart illustrating a specific implementation process for determining a list of target candidate hardware, provided in this application embodiment; Figure 3 A flowchart illustrating a specific implementation process for generating an initial list of candidate hardware based on a candidate hardware library, provided in this application embodiment; Figure 4 A flowchart illustrating a specific implementation process for compatibility filtering of an initial candidate hardware list based on a target underlying firmware, provided in this application embodiment; Figure 5 A flowchart illustrating a specific implementation process for determining a dedicated driver firmware based on hardware information determined by a selection operation, as provided in this application embodiment; Figure 6 This is a schematic diagram illustrating a specific implementation process for generating target driver firmware, provided in an embodiment of this application. Figure 7 A flowchart of a driver firmware generation method, including a process of updating an initial candidate hardware list, is provided for embodiments of this application. Figure 8 A flowchart of a driver firmware generation method including a process for updating a candidate hardware library, provided for embodiments of this application; Figure 9 A structural block diagram of a driver firmware generation device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the scope of the embodiments. Furthermore, it should be noted that, for ease of description, only the parts relevant to the embodiments of this application are shown in the accompanying drawings, not the entire structure.

[0019] 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, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. 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.

[0020] The driver firmware generation method provided in this application embodiment can be executed by a computer device. The computer device refers to any electronic device with data computing, processing and storage capabilities, such as mobile phones, PCs (Personal Computers), tablet computers and other terminal devices, or servers, etc. This application embodiment does not limit the scope of the method.

[0021] Figure 1 A flowchart of a driver firmware generation method provided in this application embodiment is shown below. Figure 1 As shown, the driver firmware generation method specifically includes the following steps: Step S101: Load the target base firmware to be compiled and determine the target candidate hardware list, wherein the target candidate hardware list is used to record hardware information of different models.

[0022] The target base firmware can be the general core program of the driver firmware, without containing any specific hardware-specific adaptation code. It only possesses basic operation capabilities for the display driver chip, general interface scheduling, and basic timing control, providing a universal operating platform for all adapted hardware. The target candidate hardware list can be a collection of hardware information corresponding to the hardware supported by the target base firmware (such as display screens in fields like smart commercial displays, automotive touch screens, industrial human-machine interaction, and consumer electronics), providing an interactive platform for users to select hardware. Hardware information can include the display screen's manufacturer information, model specifications, interface parameters, etc. Optionally, the target base firmware to be compiled can be loaded via the local file system I / O interface, reading the intermediate file corresponding to the target base firmware stored on the local disk, completing the integrity hash verification of the intermediate file, and then loading it into the dedicated memory space of the compilation process for processing.

[0023] In one embodiment, a specific implementation process for determining a list of target candidate hardware is described. Please refer to [reference needed]. Figure 2 This is a flowchart illustrating a specific implementation process for determining a list of target candidate hardware, as provided in an embodiment of this application. Figure 2 As shown, the specific implementation steps for determining the target candidate hardware list are as follows: Step S1011: Access the candidate hardware library and generate an initial candidate hardware list based on the candidate hardware library.

[0024] The candidate hardware library can be a structured database that centrally stores and manages the associated information of all supported display screens. The initial candidate hardware list can list the hardware information corresponding to all hardware models already entered in the candidate hardware library. Specifically, a communication connection is established with the candidate hardware library through database interfaces, API interfaces, or file system mounting. Optionally, before reading data from the candidate hardware library, pre-verification operations such as identity authentication and permission verification can be performed to ensure the security of data reading. In one embodiment, accessing the candidate hardware library can be achieved by establishing a TCP connection with a locally deployed candidate hardware library, completing account and password authentication and permission verification, and obtaining read-only query permissions for the candidate hardware library. In another embodiment, accessing the candidate hardware library can be achieved by connecting to the open API of a cloud-based hardware management platform, completing identity authentication and signature verification through API keys, and obtaining legitimate interface call permissions.

[0025] Optionally, a specific implementation process for generating an initial list of candidate hardware based on a candidate hardware library is described; please refer to [reference needed]. Figure 3 This is a flowchart illustrating a specific implementation process for generating an initial list of candidate hardware based on a candidate hardware library, as provided in this application embodiment. Figure 3 As shown, the specific implementation steps for determining the target candidate hardware list are as follows: Step S10111: Read the metadata files corresponding to each candidate hardware from the candidate hardware library.

[0026] The metadata file can be a structured file that is independently configured for each candidate hardware and describes all attribute information of that candidate hardware. This metadata file can be written in standardized formats such as JSON / XML / YAML. In one embodiment, reading the metadata file corresponding to each candidate hardware can be done by obtaining a list of storage paths for all metadata files in the candidate hardware library, creating a multi-threaded parallel reading task, simultaneously reading multiple metadata files in batches, performing hash verification, and then storing them in a memory buffer. In another embodiment, reading the metadata file corresponding to each candidate hardware can be done by first reading the version information of the locally cached metadata file, comparing it with the version of the metadata file in the hardware library, reading only the newly added or modified metadata files whose versions have changed, and reusing the locally cached unchanged files.

[0027] Step S10112: Parse the metadata file corresponding to each candidate hardware to obtain the hardware information corresponding to each candidate hardware.

[0028] The process involves parsing the metadata file for each candidate hardware component. This can be done by calling the appropriate parser based on the file's format extension, deserializing the file content, extracting core fields according to predefined field specifications, performing data type conversion and validating required fields, and then generating hardware information for each candidate hardware component. This hardware information may include the display screen's manufacturer information, model specifications, interface parameters, etc.

[0029] Step S10113: Generate an initial list of candidate hardware based on the hardware information corresponding to each candidate hardware.

[0030] After parsing the hardware information corresponding to each candidate hardware, the hardware information can be integrated according to a preset list structure and sorting rules to obtain a standardized initial candidate hardware list. In one embodiment, the initial candidate hardware list can be generated by classifying the hardware information corresponding to all candidate hardware according to a preset hierarchical structure (e.g., "hardware manufacturer-product series-hardware model"), sorting by the first letter of the manufacturer name, removing duplicate hardware model entries, and generating a tree-structured initial candidate hardware list. In another embodiment, the initial candidate hardware list can be generated by configuring at least one tag for each candidate hardware's hardware information according to a preset information dimension (e.g., hardware manufacturer, product model), and classifying and organizing all hardware information according to the tags to generate an initial candidate hardware list that supports multi-dimensional filtering. Therefore, reading and parsing the metadata file corresponding to each candidate hardware to obtain the corresponding hardware information can convert it into structured hardware information, providing data for generating the initial candidate hardware list; generating the initial candidate hardware list based on the hardware information corresponding to each candidate hardware can achieve centralized and standardized integration of all hardware information.

[0031] Step S1012: Perform compatibility filtering on the initial candidate hardware list based on the target basic firmware to obtain the target candidate hardware list.

[0032] The compatibility filtering can be based on the compatibility of the target underlying firmware, verifying each hardware item in the initial candidate hardware list, eliminating hardware models incompatible with the target underlying firmware, and retaining only hardware models that can be normally supported by the target underlying firmware. The target candidate hardware list can include hardware information that is compatible with the target underlying firmware.

[0033] In one embodiment, a specific implementation process for compatibility filtering of an initial list of candidate hardware based on the target underlying firmware is described. Please refer to [reference needed]. Figure 4 This is a flowchart illustrating a specific implementation process for compatibility filtering of an initial candidate hardware list based on the target underlying firmware, as provided in an embodiment of this application. Figure 4 As shown, the specific implementation steps for compatibility filtering of the initial candidate hardware list based on the target base firmware are as follows: Step S10121: Parse the target basic firmware to obtain firmware feature information.

[0034] Firmware feature information can be structured attribute information characterizing the core capabilities, compatibility constraints, and operating environment of the target base firmware. Specifically, this structured attribute information may include firmware version number, supported driver framework version, hardware interface type, etc., and is the core basis for determining whether the hardware is compatible with the target base firmware. Optionally, the firmware feature information can be obtained by parsing the target base firmware by extracting configuration files or intermediate files, parsing these files, extracting the core feature fields related to hardware compatibility, and organizing them into standardized firmware feature information.

[0035] Step S10122: Filter the initial candidate hardware list according to firmware feature information to obtain the target candidate hardware list.

[0036] Using the firmware feature information as a filtering benchmark, multi-dimensional compatibility verification rules can be established. Optionally, filtering the initial candidate hardware list based on the firmware feature information can involve comparing the corresponding parameters of each hardware item in the initial candidate hardware list with the firmware feature information one by one, eliminating hardware items that do not meet the verification rules in any dimension, and retaining only hardware items that meet the verification rules in all dimensions. Optionally, the verification rules can be driver framework version matching, interface type matching, model specification matching, timing parameter range matching, resolution support range matching, etc., which are not limited in this application. As can be seen from the above, parsing the target base firmware to obtain firmware feature information can convert the firmware's compatibility into quantifiable and directly comparable feature parameters, providing a reliable basis for compatibility filtering; filtering the initial candidate hardware list based on the firmware feature information can accurately select all hardware compatible with the target base firmware, ensuring the stability of subsequent firmware operation.

[0037] Step S102: Respond to the selection operation applied to the target candidate hardware list, and determine the specific driver firmware based on the hardware information determined by the selection operation.

[0038] The selection operation can be a human-computer interaction or configuration input action whereby the user selects the target hardware to be adapted for compilation from a list of target candidate hardware via an interactive interface, configuration file, etc. In one embodiment, by real-time monitoring of checkmark and click events in the target candidate hardware list on the interactive interface, the subsequent compilation process can continue after capturing the trigger signal of user confirmation. In another embodiment, by real-time monitoring of file change events in the compilation configuration directory, when it is detected that the user has written to a configuration file containing hardware selection configurations, the hardware selection parameters in the configuration file are automatically read and parsed to complete the selection operation response and trigger the subsequent compilation process. The dedicated driver firmware can be a pre-set driver firmware for a single manufacturer or model of display screen, such as touch driver firmware, backlight driver firmware, power management driver firmware, etc. Optionally, the method for determining the dedicated driver firmware based on the hardware information determined by the selection operation can be to use the extracted hardware information as an index, and locate and extract the dedicated driver firmware that uniquely matches the hardware information through mapping matching, database query, file retrieval, etc.

[0039] In one embodiment, a specific implementation process for determining the dedicated driver firmware based on hardware information determined by a selection operation is described. Please refer to [reference needed]. Figure 5 This is a flowchart illustrating a specific implementation process for determining dedicated driver firmware based on hardware information determined by a selection operation, as provided in an embodiment of this application. Figure 5 As shown, the specific implementation steps for determining the dedicated driver firmware based on the hardware information determined by the selection operation are as follows: Step S1021: Based on the hardware information determined by the selection operation, query the preset mapping relationship to obtain the target firmware identifier.

[0040] The preset mapping relationship can be a one-to-one correspondence between pre-established and stored hardware information and dedicated driver firmware identifiers. Specifically, it can adopt a key-value pair structured storage method, using hardware information as the key and the unique identifier of the corresponding dedicated driver firmware as the value. Optionally, the method for querying the preset mapping relationship based on the hardware information determined by the selection operation can be to extract key fields from the hardware information, combine the field values ​​corresponding to the key fields to obtain the key, and then search the preset mapping relationship based on the key to extract the target firmware identifier.

[0041] Step S1022: Read the special driver firmware corresponding to the target firmware identifier from the preset storage area.

[0042] The preset storage area can be a centralized storage area for all specialized driver firmwares, specifically a local disk partition, cloud object storage, or external database. Using the target firmware identifier as an index, the corresponding specialized driver firmware can be located within the preset storage area. In one embodiment, using the target firmware identifier as the filename, the relevant file of the corresponding specialized driver firmware is located in the locally preset driver firmware storage directory, and the file content of that file is read into a memory buffer. In another embodiment, using the target firmware identifier as the object key, an object read request is initiated. After server-side authentication and file verification, the relevant file of the corresponding specialized driver firmware is downloaded to a local temporary directory. As can be seen from the above, querying the preset mapping relationship based on the hardware information determined by the selection operation can achieve precise adaptation from hardware information to specialized driver firmware, improving the efficiency and accuracy of driver matching; reading the specialized driver firmware corresponding to the target firmware identifier from the preset storage area allows for quick and accurate extraction of the specialized driver firmware.

[0043] Step S103: Compile the target driver firmware based on the target base firmware and the special driver firmware to obtain the target driver firmware.

[0044] The target driver firmware is compiled based on the target base firmware and the specialized driver firmware. Specifically, the target base firmware serves as the core operating platform, while the specialized driver firmware acts as a functional extension module, and the two are integrated to obtain the target driver firmware. It should be noted that, compared to related technologies where the base firmware needs to integrate all specialized drivers, the target base firmware in this application does not contain any driver information specific to any particular hardware model. Instead, it provides optional hardware information for additional specialized driver firmware matching, and then merges and compiles the target base firmware and the specialized driver firmware to obtain the target driver firmware. This target driver firmware retains the general operating capabilities of the base firmware while integrating the specific adaptation capabilities of the target hardware, eliminating the need to integrate redundant drivers and reducing memory resource consumption.

[0045] As described above, determining the target hardware candidate list allows for the inclusion of compatible hardware within the selection range, providing suitable hardware entries. Developing specific driver firmware based on the hardware information determined during the selection operation enables precise matching between hardware and drivers, flexibly adapting to user needs. Compiling the target driver firmware based on the target base firmware and the specific driver firmware allows for the retention of only the user-selected specific driver while maintaining firmware integrity. This approach enables the selection of specific driver firmware as needed, effectively compressing firmware size, avoiding waste of chip memory resources, and improving chip operational stability.

[0046] Figure 6 This is a schematic diagram illustrating a specific implementation process for generating target driver firmware, as provided in an embodiment of this application. Figure 6As shown, the target candidate hardware list 601 provides multiple hardware information (identified by serial numbers 1, 2, 3, etc. in the figure). In response to the selection operation applied to the target candidate hardware list, the required hardware information 6011 is determined from the multiple hardware information (the selected hardware information 6011 is circled by a dashed box in the figure). Then, based on the hardware information 6011 determined by the selection operation, the special driver firmware 602 can be determined. The special driver firmware 602 and the target base firmware 603 are merged and compiled to obtain the target driver firmware 604.

[0047] Figure 7 A flowchart of a driver firmware generation method, including a process of updating an initial candidate hardware list, is provided for embodiments of this application. Figure 7 As shown, the driver firmware generation method specifically includes the following steps: Step S701: Load the target base firmware to be compiled.

[0048] Step S702: Access the candidate hardware library and generate an initial candidate hardware list based on the candidate hardware library.

[0049] Step S703: Monitor hardware change events of the candidate hardware library in real time.

[0050] Hardware change events can be various operation events in the candidate hardware library that trigger changes in hardware information, including adding, modifying, and deleting hardware metadata files. Optionally, real-time monitoring can be achieved through event notification mechanisms, polling mechanisms, message subscription mechanisms, etc. In one embodiment, a hardware change topic in the candidate hardware library is subscribed to via a message queue protocol. When a hardware change operation occurs in the hardware library, a change event message is automatically published to this topic, and messages are received in real time to complete event capture. In another embodiment, incremental polling requests are initiated to the candidate hardware library at preset millisecond intervals to retrieve hardware change event logs that occurred after the last polling time, and the change operations in the logs are parsed to complete event capture.

[0051] Step S704: Determine the incremental change information of the list based on hardware change events.

[0052] The incremental change information in the list can be obtained based on the parsing of hardware change events, and it requires the modification of hardware information in the initial candidate hardware list. Specific modification operations can include adding, modifying, or deleting.

[0053] Step S705: Update the initial list of candidate hardware based on the incremental change information of the list.

[0054] Once the incremental change information of the list is obtained, the corresponding addition, modification, and deletion operations can be performed on the initial candidate hardware list according to the incremental operation instructions in the incremental change information to complete the list update.

[0055] Step S706: Perform compatibility filtering on the initial candidate hardware list based on the target basic firmware to obtain the target candidate hardware list.

[0056] Step S707: Respond to the selection operation applied to the target candidate hardware list, and determine the specific driver firmware based on the hardware information determined by the selection operation.

[0057] Step S708: Compile the target driver firmware based on the target base firmware and the special driver firmware to obtain the target driver firmware.

[0058] As described above, real-time monitoring of hardware change events in the candidate hardware library can effectively capture data changes in the candidate hardware library, providing a data foundation for subsequent incremental updates to the list. Determining incremental change information in the list based on hardware change events can transform abstract hardware change events into specific and executable incremental operation instructions for the list, clarifying the content and type of changes to be made to the list. Updating the initial candidate hardware list based on the incremental change information can achieve real-time synchronization between the initial candidate hardware list and the hardware library data, ensuring the timeliness of hardware information.

[0059] Figure 8 A flowchart of a driver firmware generation method including a process for updating candidate hardware libraries is provided for embodiments of this application, as shown below. Figure 8 As shown, the driver firmware generation method specifically includes the following steps: Step S801: Load the target base firmware to be compiled.

[0060] Step S802: Access the candidate hardware library. Upon receiving a hardware update request from the candidate hardware library, verify the validity of the hardware update request.

[0061] The hardware update request can be a structured request message used to request the addition, modification, or deletion of hardware information in the selected hardware library. Optionally, the validity of the hardware update request can be verified, which can be identity and permission verification (e.g., verifying the requester's account identity and hardware library update operation permissions) or digital signature verification (e.g., verifying the digital signature of the request message using the requester's public key). This application does not impose any limitations on this.

[0062] Step S803: If the hardware update request passes the verification, extract the hardware update information from the hardware update request.

[0063] If the hardware update request passes verification, it is considered legitimate and can proceed to the subsequent information extraction process. Specifically, extracting hardware update information from the hardware update request involves performing structured parsing on the request and extracting all core data related to the update operation according to preset field specifications to obtain the hardware update information. The hardware update information may include relevant content regarding the update operation performed on the selected hardware library, specifically including update operation types such as add, modify, and delete, and their corresponding operation details.

[0064] Step S804: Incrementally update the selected hardware library based on hardware update information.

[0065] Incremental updates can be performed on files that have changed in the selected hardware library only, according to the operation type and update content in the hardware update information, such as adding, modifying, or deleting.

[0066] Step S805: Generate an initial list of candidate hardware based on the candidate hardware library.

[0067] Step S806: Perform compatibility filtering on the initial candidate hardware list based on the target basic firmware to obtain the target candidate hardware list, wherein the target candidate hardware list is used to record hardware information of different models.

[0068] Step S807: Respond to the selection operation applied to the target candidate hardware list, and determine the specific driver firmware based on the hardware information determined by the selection operation.

[0069] Step S808: Compile the target driver firmware based on the target base firmware and the special driver firmware to obtain the target driver firmware.

[0070] As can be seen from the above, validating the hardware update request ensures the security and reliability of the hardware library data; extracting hardware update information from the hardware update request allows for the extraction of the core data required for hardware library updates; and incremental updates to the selected hardware library based on the hardware update information only require updating the changed content without altering the original normal data, thus ensuring the consistency and stability of the hardware library data and improving update efficiency.

[0071] Figure 9 This is a structural block diagram of a driver firmware generation device provided in an embodiment of this application. The device is configured to execute the driver firmware generation method provided in the above embodiment, and has corresponding functional modules and beneficial effects for executing the method. Figure 9 As shown, the device specifically includes: Load module 901, configured to load the target base firmware to be compiled; The first determining module 902 is configured to determine a target candidate hardware list, which is used to record hardware information of different models; The second determining module 903 is configured to respond to a selection operation applied to the target candidate hardware list and determine the specific driver firmware based on the hardware information determined by the selection operation. Compilation module 904 is configured to compile the target driver firmware based on the target base firmware and the special driver firmware.

[0072] As described above, determining the target hardware candidate list allows for the inclusion of compatible hardware within the selection range, providing suitable hardware entries. Developing specific driver firmware based on the hardware information determined during the selection operation enables precise matching between hardware and drivers, flexibly adapting to user needs. Compiling the target driver firmware based on the target base firmware and the specific driver firmware allows for the retention of only the user-selected specific driver while maintaining firmware integrity. This approach enables the selection of specific driver firmware as needed, effectively compressing firmware size, avoiding waste of chip memory resources, and improving chip operational stability.

[0073] In one possible embodiment, the first determining module 902 is specifically configured as follows: Access the candidate hardware library and generate an initial candidate hardware list based on the candidate hardware library; Based on the target firmware, the initial list of candidate hardware is filtered for compatibility to obtain the target list of candidate hardware.

[0074] In one possible embodiment, the first determining module 902 is further configured as follows: Read the metadata files corresponding to each hardware candidate from the hardware candidate library; The metadata file corresponding to each candidate hardware is parsed to obtain the hardware information corresponding to each candidate hardware. An initial list of candidate hardware is generated based on the hardware information corresponding to each candidate hardware.

[0075] In one possible embodiment, the first determining module 902 is further configured as follows: The target basic firmware is parsed to obtain firmware feature information; The initial list of candidate hardware is filtered based on firmware feature information to obtain the target list of candidate hardware.

[0076] In one possible embodiment, the second determining module 903 is specifically configured as follows: The target firmware identifier is obtained by querying the preset mapping relationship based on the hardware information determined by the selection operation. Read the specific driver firmware corresponding to the target firmware identifier from the preset storage area.

[0077] In one possible embodiment, a first update module is also included, configured as follows: Monitor hardware change events in the candidate hardware library in real time; Determine incremental changes to the list based on hardware change events; The initial list of candidate hardware is updated based on the incremental changes in the list.

[0078] In one possible embodiment, a second update module is also included, configured as follows: Upon receiving a hardware update request from a candidate hardware library, the validity of the hardware update request is verified. If the hardware update request passes verification, the hardware update information is extracted from the hardware update request. Incremental updates are performed on the selected hardware library based on hardware update information.

[0079] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 10 As shown, the device includes a processor 1001, a memory 1002, an input device 1003, and an output device 1004; the number of processors 1001 in the device can be one or more. Figure 10 Taking a processor 1001 as an example; the processor 1001, memory 1002, input device 1003, and output device 1004 in the device can be connected via a bus or other means. Figure 10 Taking a bus connection as an example, the memory 1002, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the driver firmware generation method in this embodiment. The processor 1001 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory 1002, thereby implementing the aforementioned driver firmware generation method. The input device 1003 can be configured to receive input digital or character information and generate key signal inputs related to user settings and function control of the device. The output device 1004 may include a display screen or other display device.

[0080] The electronic device provided above can be used to execute the driver firmware generation method provided in any of the above embodiments, and has corresponding functions and beneficial effects.

[0081] This application also provides a non-volatile storage medium for storing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are configured to perform a driver firmware generation method described in the above embodiments, comprising: loading a target base firmware to be compiled and determining a target candidate hardware list, the target candidate hardware list being used to record hardware information of different models; responding to a selection operation acting on the target candidate hardware list and determining a specific driver firmware based on the hardware information determined by the selection operation; and compiling the target driver firmware based on the target base firmware and the specific driver firmware to obtain the target driver firmware.

[0082] Storage medium – any type of memory device or storage device. The term “storage medium” is intended to include: mounting media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media, or optical storage; registers or other similar types of memory elements, etc. Storage medium may also include other types of memory or combinations thereof. Furthermore, storage medium may reside in a first computer system in which the program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term “storage medium” may include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0083] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the driver firmware generation method described above, but can also perform related operations in the driver firmware generation method provided in any embodiment of this application.

[0084] It is worth noting that in the embodiments of the above-mentioned driver firmware generation device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not configured to limit the protection scope of the embodiments of this application.

[0085] It should be noted that the numbering of each step in this solution is only used to describe the overall design framework of this solution and does not indicate a necessary sequential relationship between the steps. As long as the overall implementation process conforms to the overall design framework of this solution, it falls within the protection scope of this solution. The order of the text in the description is not an exclusive limitation on the specific implementation process of this solution. Those skilled in the art should understand that the embodiments of this application can be provided as methods, systems, or computer program products. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0086] It should also be noted that 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 process, method, article, or apparatus. Unless otherwise specified, 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.

[0087] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A driver firmware generation method, characterized in that, The method includes: Load the target base firmware to be compiled and determine the target candidate hardware list, which is used to record hardware information of different models; In response to a selection operation applied to the target candidate hardware list, a specific driver firmware is determined based on the hardware information determined by the selection operation. The target driver firmware is obtained by compiling based on the target base firmware and the special driver firmware.

2. The driver firmware generation method according to claim 1, characterized in that, The list of target candidate hardware includes: Access the candidate hardware library and generate an initial candidate hardware list based on the candidate hardware library; Based on the target basic firmware, the initial candidate hardware list is filtered for compatibility to obtain the target candidate hardware list.

3. The driver firmware generation method according to claim 2, characterized in that, The process of generating an initial list of candidate hardware based on the candidate hardware library includes: Read the metadata files corresponding to each candidate hardware from the candidate hardware library; The metadata file corresponding to each of the candidate hardware components is parsed to obtain the hardware information corresponding to each of the candidate hardware components. An initial list of candidate hardware is generated based on the hardware information corresponding to each of the candidate hardware components.

4. The driver firmware generation method according to claim 2, characterized in that, The process of performing compatibility filtering on the initial candidate hardware list based on the target basic firmware to obtain the target candidate hardware list includes: The target basic firmware is parsed to obtain firmware feature information; The initial candidate hardware list is filtered based on the firmware feature information to obtain the target candidate hardware list.

5. The driver firmware generation method according to claim 1, characterized in that, The step of determining the specific driver firmware based on the hardware information determined by the selection operation includes: The target firmware identifier is obtained by querying the preset mapping relationship based on the hardware information determined by the selection operation. Read the specific driver firmware corresponding to the target firmware identifier from the preset storage area.

6. The driver firmware generation method according to claim 2, characterized in that, After generating the initial list of candidate hardware based on the candidate hardware library, the method further includes: Monitor hardware change events in the candidate hardware library in real time; Determine the incremental change information of the list based on the hardware change events; The initial list of candidate hardware is updated based on the incremental change information of the list.

7. The driver firmware generation method according to claim 2, characterized in that, Following the access to the candidate hardware library, the following is also included: Upon receiving a hardware update request from the candidate hardware library, the validity of the hardware update request is verified. If the hardware update request passes verification, hardware update information is extracted from the hardware update request; The candidate hardware library is incrementally updated based on the hardware update information.

8. A driver firmware generation device, characterized in that, include: Load the module, configured to load the target base firmware to be compiled; The first determining module is configured to determine a target candidate hardware list, wherein the target candidate hardware list is used to record hardware information of different models; The second determining module is configured to respond to a selection operation applied to the target candidate hardware list and determine a specific driver firmware based on the hardware information determined by the selection operation. The compilation module is configured to compile the target driver firmware based on the target base firmware and the special driver firmware.

9. An electronic device, characterized in that, The electronic device includes: one or more processors; and a storage device configured to store one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the driver firmware generation method according to any one of claims 1-7.

10. A non-volatile storage medium storing computer-executable instructions, which, when executed by a computer processor, are configured to perform the driver firmware generation method according to any one of claims 1-7.

Images