Driver loading method, apparatus, and computer device based on programmer

Abstract

This application relates to a method, apparatus, and computer device for loading a driver based on a programmer. The method includes: in response to an operation request for a target device, obtaining the address of a driver file corresponding to a chip protocol and a hardware parameter package of the programmer; obtaining a corresponding driver file based on the driver file address; the driver file includes a driver program and unbound hardware-related symbols; invoking a hardware configuration function provided by the programmer firmware based on parameters in the hardware parameter package; binding the unbound hardware-related symbols to the address of the hardware configuration function to obtain a driver instance; and invoking the driver instance to operate the target device. This method can reduce deployment costs.

Description

Technical Field

[0001] This application relates to the field of programmer technology, and in particular to a programmer-based driver loading method, apparatus, and computer device. Background Technology

[0002] General-purpose programmers (also known as firmware programmers or mass production programmers) are key production tools in the semiconductor industry chain, connecting chip design and end products. Their core task is to accurately and efficiently write firmware programs or configuration data into various microcontrollers, memories, and programmable logic devices. Traditional BSP (Board Support Package) firmware typically uses a monolithic integrated structure, where all driver code is statically compiled and linked into a complete image file. When support for a new chip or fixing a driver bug is needed, a full firmware upgrade is required. Even if only 1KB of code is modified, users need to download and burn the entire firmware package (potentially tens of MB), resulting in high deployment costs. Summary of the Invention

[0003] Therefore, it is necessary to provide a programmer-based driver loading method, apparatus, and computer device that can reduce deployment costs in response to the above-mentioned technical problems.

[0004] A programmer-based driver loading method, applied to a programmer, the method comprising: In response to an operation request for the target device, the driver file address corresponding to the chip protocol and the hardware parameter package of the programmer are obtained; The corresponding driver file is obtained based on the driver file address; the driver file includes the driver program and unbound hardware-related symbols; Based on the parameters in the hardware parameter package, call the hardware configuration function provided by the programmer firmware; Bind the unbound hardware-related symbols to the address of the hardware configuration function to obtain a driver instance; The driver instance is invoked to operate the target device.

[0005] A programmer-based driver loading apparatus, used to implement the steps of various programmer-based driver loading method embodiments, includes: The parameter package acquisition module is used to acquire the driver file address corresponding to the chip protocol and the hardware parameter package of the programmer in response to the operation request of the target device; The driver file acquisition module is used to obtain the corresponding driver file according to the driver file address; the driver file includes the driver program and unbound hardware-related symbols; The hardware configuration function call module is used to call the hardware configuration function provided by the programmer firmware according to the parameters in the hardware parameter package; The binding module is used to bind the unbound hardware-related symbols to the address of the hardware configuration function to obtain a driver instance; The driver instance invocation module is used to invoke the driver instance to operate the target device.

[0006] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of various embodiments of a programmer-based driver loading method.

[0007] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of various programmer-based driver loading method embodiments.

[0008] A computer program product includes a computer program that, when executed by a processor, implements the steps of various programmer-based driver loading method embodiments.

[0009] The aforementioned programmer-based driver loading method, apparatus, and computer device, in response to an operation request for the target device, obtain the driver file address corresponding to the chip protocol and the programmer's hardware parameter package, thereby obtaining the driver file and hardware configuration functions. This separates the driver program from hardware initialization, allowing the driver file to be reused across different programmers and supporting individual updates to the driver program or database configuration of a specific target device without requiring a full firmware upgrade. Unbound hardware-related symbols are bound to the addresses of hardware configuration functions to obtain a driver instance. The driver instance is then invoked to operate on the target device. Through the binding relationship between unbound hardware-related symbols and hardware configuration functions, plug-and-play and flexible configuration of the driver are achieved, significantly reducing deployment costs. Attached Figure Description

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

[0011] Figure 1 This is an application environment diagram of a programmer-based driver loading method in one embodiment; Figure 2 This is a flowchart illustrating a programmer-based driver loading method in one embodiment; Figure 3 This is a diagram of the programmer system architecture in one embodiment. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

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

[0014] It should be noted that all directional indicators (such as up, down, left, right, front, back, etc.) in the embodiments of this application are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicator will also change accordingly. The connection can be a direct connection or an indirect connection.

[0015] Furthermore, the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but only on the basis of being achievable by those skilled in the art. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0016] It is understood that the term "connection" in the following embodiments should be understood as "electrical connection," "communication connection," etc., if the connected circuits, modules, units, etc., have electrical signal or data transmission with each other.

[0017] It is understood that the "data acquisition" operation in the embodiments of this application includes, but is not limited to, the following implementation methods: directly reading data pre-stored in the device; data received from external devices; or indirect acquisition methods after data collection, conversion and processing.

[0018] The programmer-based driver loading method provided in this application can be applied to, for example... Figure 1 In the application environment. Figure 1This diagram illustrates an application environment for a programmer-based driver loading method in one embodiment. It includes a host computer 110, a programmer 120, and a target device 130. The host computer 110 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The programmer 120 is used to load the driver into the target device 130. The target device 130 refers to the device on which the driver is to be written, and can specifically include, but is not limited to, various microcontroller units (MCUs), memories (Flash, EEPROM), and programmable logic devices.

[0019] In one embodiment, such as Figure 2 As shown, a programmer-based driver loading method is provided, which can be applied to... Figure 1 The following steps are used as an example of a programmer: steps 202 to 210. Step 202: In response to the operation request for the target device, obtain the driver file address corresponding to the chip protocol and the hardware parameter package of the programmer.

[0020] The driver file address indicates the location of the driver file. The hardware parameter package is a JSON (JavaScript Object Notation) or binary block containing the initialization parameters required by the driver on the programmer.

[0021] Specifically, in response to an operation request for the target device, the programmer can obtain the driver file address corresponding to the chip protocol of the target device and the programmer's hardware parameter package from the configuration database. For example, the programmer queries the configuration database for the record of chip A, which includes the driver file address Driver_ELF_Path and the hardware parameter package Configuration_Parameters.

[0022] Optionally, the chip protocol is optional; in response to an operation request to the target device and a chip protocol selection operation, the driver file address corresponding to the selected chip protocol and the programmer's hardware parameter package are obtained. When more than one chip protocol is required, the driver file address corresponding to each selected chip protocol and the programmer's hardware parameter package are obtained sequentially.

[0023] Step 204: Obtain the corresponding driver file based on the driver file address; the driver file includes the driver program and unbound hardware-related symbols.

[0024] The driver program includes core algorithms such as signal timing generation and command parsing. Unbound hardware-related symbols are placeholders in the driver file that do not link to any specific hardware operation functions to achieve decoupling from the hardware platform. These include hardware-dependent operations such as pin control (GPIO_Set), clock acquisition (CLK_GetFrequency), and delay waiting (Delay_us). These symbols appear as empty address references in the compiled driver file.

[0025] Specifically, the programmer retrieves the corresponding driver file based on its address. In the database, different driver files are used for drivers corresponding to different chip protocols. During compilation, the driver file does not link any specific hardware addresses such as GPIOA base address, clock frequency parameters, etc.

[0026] Step 206: Based on the parameters in the hardware parameter package, call the hardware configuration function provided by the programmer firmware.

[0027] Specifically, the loader in the programmer firmware calls the hardware abstraction layer function provided by the device firmware itself based on the specific parameters in the configuration_parameters hardware parameter package. For example, if the parameter specifies SWDIO=GPIOB3, the loader will call the firmware's built-in HAL_GPIO_Init(GPIOB, PIN3, OUTPUT).

[0028] Hardware configuration functions are a set of functions pre-written in the firmware of the embedded device's main control MCU. These functions can be understood as the firmware code receiving information about the protocol configured in the background and the chip I / O used, and then performing the corresponding hardware protocol and I / O initialization. The difference generally lies in the fact that this initialization process can vary significantly across different hardware platforms. For example: `HAL_GPIO_WritePin(Port, Pin, Level)` is a standard function in the hardware abstraction layer that sets the output of a pin to a high or low level. `HAL_SPI_Transmit(&data, size)`: sends a string of data via the SPI bus. `HAL_Delay_us(microseconds)`: precisely delays the data by a certain number of microseconds. `HAL_GetTick`: retrieves the current system timestamp.

[0029] Step 208: Bind the unbound hardware-related symbols to the address of the hardware configuration function to obtain the driver instance.

[0030] Specifically, the programmer binds unbound hardware-related symbols to the addresses of hardware configuration functions to obtain a driver instance. That is, the driver instance includes hardware-independent driver code, the current programmer's hardware configuration parameters, and the correct address links to the hardware configuration functions. Thus, the driver file is transformed from a general logic block into a driver instance executable for the current programmer, completing the driver loading process.

[0031] Step 210: Invoke the driver instance to operate on the target device.

[0032] Specifically, the programmer can call the driver instance to perform chip programming, reading and writing operations on the target chip.

[0033] In this embodiment, by responding to an operation request for the target device, the driver file address corresponding to the chip protocol and the hardware parameter package of the programmer are obtained, thereby obtaining the driver file and hardware configuration function. That is, the driver program and hardware initialization are separated, which allows the driver file to be reused across different programmers and supports updating the driver program or database configuration of a specific target device without the need for a full firmware upgrade. Unbound hardware-related symbols are bound to the addresses of hardware configuration functions to obtain a driver instance. The driver instance is called to operate on the target device. Through the binding relationship between unbound hardware-related symbols and hardware configuration functions, plug-and-play and flexible configuration of the driver are achieved, thereby greatly reducing deployment costs.

[0034] In one embodiment, the corresponding driver file is obtained based on the driver file address; the driver file includes the driver program and unbound hardware-related symbols, including: Obtain the corresponding driver file based on the driver file address and load the driver file into random access memory; Parse the driver file in random access memory to obtain the driver and unbound hardware-related symbols.

[0035] Random Access Memory (RAM) refers to the volatile memory area within the programmer's main control chip, used to temporarily store the contents of driver files loaded from the outside and to provide an execution environment for the driver program.

[0036] Specifically, after receiving the driver file address, the programmer driver loader (software module) calls the underlying storage or network protocol stack to fully read the driver file into the dynamic code area of ​​RAM. The programmer then parses the driver file using a parser to obtain the driver program and unbound hardware-related symbols.

[0037] Optionally, a digital signature verification step can be added after parsing the driver file header. The parser calculates the file hash value and compares it with the signature pre-stored in the database. Only after successful verification can the parser continue to parse the driver and unbound hardware-related symbols, preventing malicious drivers from being loaded.

[0038] In this embodiment, the corresponding driver file is obtained according to the driver file address, the driver file is loaded into the random access memory, the driver file is parsed in the random access memory to obtain the driver program and unbound hardware-related symbols, and then loaded into the random access memory for further parsing, which facilitates function calling.

[0039] In one embodiment, binding unbound hardware-related symbols to the address of a hardware configuration function to obtain a driver instance includes: Create translation tables or jumper functions; translation tables or jumper functions represent the relationship between the addresses of unbound hardware-related symbols and hardware configuration functions; By querying the translation table or calling the jumper function, unbound hardware-related symbols are bound to the addresses of hardware configuration functions to obtain driver instances.

[0040] Specifically, both the translation table and the jump function are linked at runtime. The translation table is a dynamically created address mapping dictionary in memory. The loader parses the driver file and finds that the driver file requires GPIO_Set. On the current platform, GPIO_Set should correspond to HAL_GPIO_WritePin. The loader creates a table in RAM: {“GPIO_Set”:0x20001000}, representing the mapping relationship between unbound hardware-related symbols and the addresses of hardware configuration functions. The loader does not directly modify the code of GPIO_Set in the driver ELF. Instead, it modifies the code of the driver file, replacing GPIO_Set with LookupInTable(“GPIO_Set”). This LookupInTable function looks up the table, finds 0x20001000, and then jumps to it. The translation table is flexible and secure; it can be dynamically added, deleted, and modified. The code of the driver file itself is not modified to hard-coded addresses, maintaining the purity of "hardware independence," and the binding relationship is maintained by the translation table.

[0041] A jump function is a short procedure linking table entry, a small piece of fixed code dynamically generated at runtime. Initial binding call: When the driver first calls GPIO_Set, it actually calls its PLT (Procedure Linking Table) entry. The first instruction of the PLT entry is `jmp*[GOT_BASE+GPIO_Set_INDEX]`. At this point, the entry points to the subsequent "binder" code in the PLT. The "binder" calls the runtime linker, finds the actual address of GPIO_Set (0x2000_1234), writes it to the corresponding entry, and then jumps to execute.

[0042] Execution of subsequent calls: All subsequent calls to GPIO_Set still go through the PLT entry. However, the entry has now been updated to the real address, so the jmp*[GOT_BASE+GPIO_Set_INDEX] instruction will jump directly to 0x2000_1234. This process of "calling a jump function to trigger or directly jump" is the binding implemented through the jump function.

[0043] In this embodiment, a translation table or jumper function is created to represent the relationship between the addresses of unbound hardware-related symbols and hardware configuration functions. The addresses of hardware-related symbols and hardware configuration functions are then bound to obtain a driver instance. This achieves software and hardware binding, enabling plug-and-play and flexible configuration of the driver, thereby greatly reducing deployment costs.

[0044] In one embodiment, binding unbound hardware-related symbols to the address of a hardware configuration function to obtain a driver instance includes: By dynamically relocating, unbound hardware-related symbols are bound to the addresses of hardware configuration functions to obtain driver instances.

[0045] Specifically, dynamic relocation refers to the process by which the system loader, after the driver file has been loaded into memory (such as RAM) but before its actual execution, directly modifies specific memory contents in the program code segment or data segment according to the actual address space layout of the target runtime environment, thereby updating the absolute addresses or offset addresses contained therein. In other words, this process is specifically used to correct the null addresses of unbound hardware-related symbols to the actual memory addresses of the corresponding specific hardware configuration functions in the programmer firmware.

[0046] In this embodiment, unbound hardware-related symbols are bound to the addresses of hardware configuration functions through dynamic relocation to obtain driver instances. Then, the calls to hardware configuration functions in the driver file become direct jump instructions, which can achieve the highest runtime execution efficiency and improve the real-time performance of burning.

[0047] In one embodiment, the driver file is an ELF file; the ELF file also includes a driver description header, which contains at least one of the following data: driver identifier, supported protocol types, a list of required resources, version number, and entry function name.

[0048] ELF (Executable and Linking Format) files refer to object files that conform to the executable and linkable format specification. They are the standardized carrier of driver files and include: Driver logic code: such as core algorithms for signal timing generation and command parsing.

[0049] Unbound hardware-related symbols: placeholders for hardware-related symbols such as GPIO_Set, CLK_GetFrequency, Delay_us, etc.

[0050] Driver description header: contains metadata such as driver representation, supported protocol types, list of required resources, version number, entry function name, etc.

[0051] The driver identifier is a string or numeric identifier used to uniquely identify the driver file, and is used for fast indexing in database queries, version comparisons, and cache management. Supported protocol types specify the chip communication protocol implemented by the driver file; for example, "SWD", "JTAG", "SPI_FLASH", "UART_BOOTLOADER", etc. The required resource list describes the hardware and software resources the driver depends on at runtime, such as "requires 2 pins", "requires 1 hardware timer", "requires 8KB RAM as a buffer". The version number identifies the driver file version and is used for driver file version management, compatibility assessment, and upgrade control. The entry function name specifies the name of the function that the core engine should execute first when this driver instance is called, such as "Driver_Probe" or "Driver_Init". The parser uses this name to look up the corresponding entry address in the driver file's symbol table.

[0052] In this embodiment, the driver file is an ELF file, which defines a standardized format and self-describing structure for driver files. This is a crucial prerequisite for ensuring the safe, efficient, and automated operation of the dynamic loading system. The driver description header provides a consistent metadata interface for the driver module, enabling the backend database, host computer software, and embedded loader to classify, retrieve, manage versions, and analyze dependencies of drivers based on a unified data structure. This achieves systematic management of the driver ecosystem. In one embodiment, invoking a driver instance to operate on the target device includes: By calling the driver instance through the entry function specified in the driver file, read and write operations on the target device are performed.

[0053] Specifically, the entry function defined in the driver file is used to call the driver instance. Taking the target device as a chip as an example, chip read and write operations refer to various data access operations performed on the target device (chip) through a specific hardware protocol. These include the most basic read (reading data from the chip's storage space) and write (burning data into the chip's storage space), and usually also include a complete set of programmer operations such as erase (clearing the storage space), verification (verifying the correctness of the written data), empty check (checking whether the storage space is empty), reading the chip identifier (such as Device ID), and configuring security bits (such as write protection and read protection).

[0054] In this embodiment, by calling the driver instance through the entry function agreed upon in the driver file, the target device read and write operations are performed on the target device. The calling instance can use a standardized interface to be called in a unified way, so that the system can use a set of the same scheduling logic to manage and operate hundreds or thousands of different chip drivers, which greatly simplifies the system architecture and improves scalability and maintainability.

[0055] In one embodiment, the current programmer's firmware architecture suffers from the following insurmountable pain points: 1. Full updates are inefficient and risky: Traditional BSP (Board Support Package) firmware typically adopts a monolithic integrated structure, where all driver code is statically compiled and linked into a complete image file.

[0056] When new chips need to be supported or a driver bug needs to be fixed, a full firmware upgrade is required. Even if only 1KB of code is modified, users need to download and burn the entire firmware package (which may be tens of MB), which is time-consuming and wastes bandwidth.

[0057] If a power outage or communication interruption occurs during a full upgrade, the device is very likely to become unusable, resulting in high recovery costs.

[0058] 2. The driver is tightly coupled with the hardware, making cross-platform porting difficult: Traditional protocol driver code typically manipulates hardware registers (such as GPIO and clock) directly, and is deeply bound to a specific host MCU model.

[0059] When the programmer hardware platform is changed, the original driver code cannot be directly reused. Engineers need to rewrite or make extensive modifications to the hardware initialization part, which results in a long development cycle and high maintenance costs.

[0060] 3. Inflexible configuration management: Driver parameters (such as pin mapping, clock frequency, and timing parameters) are usually hard-coded in the code or managed through local configuration files.

[0061] When it is necessary to adapt the same chip to different hardware platforms, it is impossible to achieve "write once, run anywhere" and there is a lack of a unified dynamic configuration mechanism.

[0062] This embodiment aims to overcome the above-mentioned shortcomings and provide a decoupled, modular, and dynamically configurable driver architecture to achieve: 1. Cross-platform driver: Separate driver logic from hardware initialization, enabling the core driver file (ELF) to be reused across different hardware platforms.

[0063] 2. Lightweight updates: Supports updating the driver or database configuration of a single chip without requiring a full firmware upgrade.

[0064] 3. Dynamic configuration: Driver parameters and hardware mapping relationships are centrally managed through a background database, enabling "plug and play" and flexible configuration of drivers.

[0065] Steps in detail: Step 1: Standardized fabrication of driver modules (development phase) 1. Write independent drivers for each chip protocol.

[0066] 2. During compilation, no specific hardware addresses (such as GPIOA base address) or clock frequency parameters are linked. These drivers are output in the standard ELF file format, containing: Driver program (logic code): such as core algorithms for signal timing generation and command parsing.

[0067] Unbound hardware-related symbols: placeholders for hardware-related functions such as GPIO_Set, CLK_GetFrequency, and Delay_us.

[0068] Driver description header: contains metadata such as driver ID, supported protocols, list of required resources, and version number.

[0069] Step 2: Configuring the backend database (configuration phase) 1. Establish a relational or key-value database, where each record corresponds to a target chip.

[0070] 2. The configuration database can be a relational or key-value database, with each record corresponding to a target chip. Each record must include at least: Chip_ID: A unique identifier for the target device, such as a chip.

[0071] Driver_ELF_Path: The address of the driver file, corresponding to the storage path of the ELF driver file on the server or local machine.

[0072] Configuration_Parameters: A hardware parameter package, in JSON or binary format, containing the initialization parameters required by the driver on the hardware platform. For example: "platform": "SSSSS750", specifies the target hardware platform. "pin_swdio": {"port": 3, "af": 0}, indicates the data line of the SWD interface. "pin_swclk": {"port": 14, "af": 0}, indicates the clock line of the SWD interface. "clock_speed_hz": 16000000, representing the SWD clock frequency. "delay_loop_count": 4, indicating the delay loop count. "voltage_level": 3.3, indicating the interface voltage level. Step 3: Dynamic loading and binding of the target device at runtime (runtime phase) 1. User selects target chip: The operating software (host computer) informs the device's main control MCU that "chip A" needs to be operated.

[0073] 2. Query and Download: The device's main control MCU (or assisting host computer) queries the background database for the record of "Chip A".

[0074] Download the corresponding ELF file based on the Driver_ELF_Path in the record, and obtain the Configuration_Parameters package. This can be cached in local non-volatile storage.

[0075] 3. ELF file loading and parsing: The driver loader in the device firmware loads the downloaded ELF file into the dynamic code area of ​​RAM.

[0076] The ELF parser reads the ELF file, determines the addresses of driver-related transmit and receive functions, and finds any unresolved hardware-related symbols (such as GPIO_Set).

[0077] 4. Hardware association initialization: The loader calls the hardware abstraction layer function provided by the device firmware itself based on the specific parameters in Configuration_Parameters. For example, if the parameter specifies SWDIO=GPIOB3, the loader will call the firmware's built-in HAL_GPIO_Init(GPIOB, PIN3, OUTPUT).

[0078] A crucial step is to create a translation table / jump function that binds the GPIO_Set symbol called in the driver ELF to the specific address of the firmware's built-in HAL_GPIO_WritePin function. This is typically achieved through dynamic relocation or runtime linking techniques.

[0079] 5. Driver ready: Once the binding is complete, the driver ELF transforms from a "general logic block" into a "driver instance that is executable for the current hardware platform".

[0080] The core engine calls the driver by calling the entry function (such as Driver_Probe()) agreed upon in the ELF driver file to perform chip programming, read and write operations.

[0081] like Figure 3 The diagram shown illustrates a programmer system architecture in one embodiment. It includes a cloud / back-end management system located on a host computer, a general-purpose programmer, and a target chip. The cloud / back-end management system includes a driver and configuration database and an independent ELF driver file library, and may also include a version update service and a digital signature center.

[0082] The general-purpose programmer includes a user interface (UI) for selecting chip models or launching tasks. The core dynamic loading engine includes matching and retrieval, downloading and caching, security verification, an ELF parser (for relocation and symbol binding), and a memory allocator. Matching and retrieval queries the cloud system for the corresponding driver and configuration based on the user-selected chip model. Downloading and caching retrieves the necessary individual ELF driver files and their configuration parameters. Security verification verifies the integrity and legitimacy of the downloaded files (e.g., using digital signatures). The ELF parser parses the ELF file format and performs critical relocation and symbol binding operations. The memory allocator dynamically allocates memory space for the upcoming driver instance.

[0083] The general-purpose programmer includes a hardware abstraction adaptation layer, which comprises a standard abstract interface table, local hardware initialization hooks, and local low-level register drivers. The standard abstract interface table defines a unified set of hardware operation interfaces. The local hardware initialization hooks provide hardware platform-specific initialization entry points. The local low-level register drivers are used to implement the specific hardware operations of the aforementioned abstract interfaces.

[0084] Then, configuration parameters are injected through the cloud-based backend management system, and the core dynamic loading engine relocates and loads the code. Hardware-related symbols are bound to the specific addresses of hardware configuration functions (such as HAL functions) to obtain the driver instance. The runtime environment has already loaded the driver instance (dynamic ELF code segment) and the runtime configuration context, such as pin mappings and timing parameters, which come from the database JSON (JavaScript Object Notation). The general-purpose programmer executes protocol operations to interact with the target chip via physical signals.

[0085] The system's workflow is as follows: First, the cloud / backend management system sends the target chip's configuration parameters (such as pin mappings and timing parameters, typically stored in a database in JSON format) to the general-purpose programmer. Simultaneously, the core dynamic loading engine downloads, performs security verification, and parses the independent ELF driver file. Second, during loading, the ELF parser performs relocation and dynamically binds hardware-related symbols in the driver code to the corresponding function addresses in the hardware abstraction adaptation layer, thereby generating a driver instance that can run on the current hardware platform. Subsequently, this driver instance (i.e., the dynamically loaded ELF code segment) executes in the runtime environment created within the general-purpose programmer. The configuration context it depends on (such as pin mappings and timing parameters) is provided by the aforementioned configuration parameters. Finally, this driver instance controls the general-purpose programmer to execute specific protocol operations, interacting with the target chip through physical signals to complete programming, reading, and writing tasks.

[0086] In this embodiment, by isolating the database configuration and the corresponding operation code from the hardware, when adapting a chip to different programmers, only the hardware configuration function to be called needs to be changed, without having to redevelop each chip.

[0087] When changing the target device for programming, there is no need to rewrite the relevant code of the chip protocol. You only need to focus on the application layer, such as how to implement the read, write and erase functions, without caring about how the underlying data is sent and received.

[0088] When a driver bug needs to be fixed, only the ELF file and configuration parameters in the background need to be updated; the business layer code for firmware and chip operations does not need to be modified.

[0089] If a power outage or communication interruption occurs during the upgrade process, since the update objects in this embodiment are independent driver files and database configurations stored externally (in the background or local cache), the update process does not involve erasing or rewriting the programmer device's own firmware. Therefore, even if any abnormal interruption occurs during driver or configuration updates, it will not affect the normal operation of the programmer's main control firmware at all.

[0090] In summary, due to the wide variety of chips and complex communication protocols, when adding programming functions to a new chip, if the communication protocol differs from that of previous chips, there is no need to register new driver functions in the host, compile new ELF driver files, or obtain specific protocol driver functions from the ELF files to implement chip read, write, erase, lock, and unlock functions. The results show that dynamic parsing, relocation, and secure execution of ELF files have been successfully implemented on resource-constrained MCUs. Furthermore, since it is not necessary to include all communication protocols in the firmware, the demand for Flash and RAM (Random Access Memory) is significantly reduced, lowering hardware BOM (Bill of Materials) costs. This solves the industry pain points of high firmware coupling, difficult updates, and poor scalability in traditional embedded programmers, and has extremely high application value.

[0091] In one embodiment, a programmer-based driver loading method includes: Step (a1): In response to the operation request for the target device, obtain the driver file address corresponding to the chip protocol and the hardware parameter package of the programmer.

[0092] Step (a2): Obtain the corresponding driver file according to the driver file address and load the driver file into random access memory; the driver file is an ELF file; the ELF file also includes a driver description header, which contains at least one of the following data: driver identifier, supported protocol types, required resource list, version number, and entry function name.

[0093] Step (a3) ​​involves parsing the driver file in random access memory to obtain the driver program and unbound hardware-related symbols.

[0094] Step (a4): Based on the parameters in the hardware parameter package, call the hardware configuration function provided by the programmer firmware.

[0095] Step (a5) involves binding unbound hardware-related symbols to the addresses of hardware configuration functions by querying the conversion table, calling jump functions, or using dynamic relocation, thereby obtaining a driver instance.

[0096] Step (a6) involves calling the driver instance by invoking the entry function specified in the driver file to perform target device read / write operations on the target device.

[0097] In this embodiment, by responding to an operation request for the target device, the driver file address corresponding to the chip protocol and the hardware parameter package of the programmer are obtained, thereby obtaining the driver file and hardware configuration function. That is, the driver program and hardware initialization are separated, which allows the driver file to be reused across different programmers and supports updating the driver program or database configuration of a specific target device without the need for a full firmware upgrade. Unbound hardware-related symbols are bound to the addresses of hardware configuration functions to obtain a driver instance. The driver instance is called to operate on the target device. Through the binding relationship between unbound hardware-related symbols and hardware configuration functions, plug-and-play and flexible configuration of the driver are achieved, thereby greatly reducing deployment costs.

[0098] It should be understood that, although the above Figure 2 and Figure 3 In the flowchart, the steps are shown sequentially according to the arrows, and the steps (a1) through (a6) are shown sequentially according to their numbers. However, these steps are not necessarily executed in the order indicated by the arrows or numbers. Unless explicitly stated herein, there is no strict order requirement for the execution of these steps; they can be executed in other orders. Figure 2 and Figure 3 At least some of the steps in the process may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0099] In one embodiment, a programmer-based driver loading device is provided. This device can be a software module, a hardware module, or a combination of both, integrated into a computer device. Specifically, the device includes: The parameter packet acquisition module is used to obtain the driver file address corresponding to the chip protocol and the hardware parameter packet of the programmer in response to the operation request of the target device; The driver file acquisition module is used to obtain the corresponding driver file based on the driver file address; the driver file includes the driver program and unbound hardware-related symbols; The hardware configuration function call module is used to call the hardware configuration functions provided by the programmer firmware based on the parameters in the hardware parameter package. The binding module is used to bind unbound hardware-related symbols to the addresses of hardware configuration functions to obtain driver instances; The driver instance invocation module is used to invoke driver instances to operate on the target device.

[0100] In one embodiment, the driver file acquisition module is configured to: acquire the corresponding driver file according to the driver file address, and load the driver file into the random access memory; Parse the driver file in random access memory to obtain the driver and unbound hardware-related symbols.

[0101] In one embodiment, the binding module is used to: create a translation table or a jumper function; the translation table or jumper function represents the relationship between the addresses of unbound hardware-related symbols and hardware configuration functions; By querying the translation table or calling the jumper function, unbound hardware-related symbols are bound to the addresses of hardware configuration functions to obtain driver instances.

[0102] In one embodiment, the binding module is used to: bind unbound hardware-related symbols to the addresses of hardware configuration functions through dynamic relocation to obtain a driver instance.

[0103] In one embodiment, the driver file is an ELF file; the ELF file also includes a driver description header, which contains at least one of the following data: driver identifier, supported protocol types, a list of required resources, version number, and entry function name.

[0104] In one embodiment, the driver instance invocation module is used to: invoke the driver instance by calling the entry function agreed upon in the driver file to perform target device read and write operations on the target device.

[0105] For specific limitations regarding the programmer-based driver loading device, please refer to the limitations of the programmer-based driver loading method above, which will not be repeated here. Each module in the aforementioned programmer-based driver loading device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0106] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method embodiments.

[0107] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method embodiments.

[0108] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the above-described method embodiments.

[0109] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0110] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A driver loading method based on a programmer, characterized in that, Applied to a programmer, the method includes: In response to an operation request for the target device, the driver file address corresponding to the chip protocol and the hardware parameter package of the programmer are obtained; The corresponding driver file is obtained based on the driver file address; the driver file includes the driver program and unbound hardware-related symbols; Based on the parameters in the hardware parameter package, call the hardware configuration function provided by the programmer firmware; Bind the unbound hardware-related symbols to the address of the hardware configuration function to obtain a driver instance; The driver instance is invoked to operate the target device.

2. The method according to claim 1, characterized in that, The step involves obtaining the corresponding driver file based on the driver file address; the driver file includes the driver program and unbound hardware-related symbols, including: Obtain the corresponding driver file according to the driver file address, and load the driver file into the random access memory; The driver file is parsed in the random access memory to obtain the driver program and unbound hardware-related symbols.

3. The method according to claim 1, characterized in that, The step of binding the unbound hardware-related symbols to the address of the hardware configuration function to obtain a driver instance includes: Create a translation table or a jump function; the translation table or the jump function represents the relationship between the addresses of the unbound hardware-related symbols and the hardware configuration functions; By querying the conversion table or calling the jumper function, the unbound hardware-related symbols are bound to the address of the hardware configuration function to obtain the driver instance.

4. The method according to claim 1, characterized in that, The step of binding the unbound hardware-related symbols to the address of the hardware configuration function to obtain a driver instance includes: The driver instance is obtained by dynamically relocating the unbound hardware-related symbols to the address of the hardware configuration function.

5. The method according to claim 1, characterized in that, The driver file is an ELF file; the ELF file also includes a driver description header, which contains at least one of the following data: driver identifier, supported protocol types, required resource list, version number, and entry function name.

6. The method according to claim 1, characterized in that, The invocation of the driver instance to operate the target device includes: The driver instance is invoked by calling the entry function agreed upon in the driver file to perform target device read and write operations on the target device.

7. A driver loading device based on a programmer, characterized in that, The steps for implementing the method of any one of claims 1 to 6 include: The parameter package acquisition module is used to acquire the driver file address corresponding to the chip protocol and the hardware parameter package of the programmer in response to the operation request of the target device; The driver file acquisition module is used to obtain the corresponding driver file according to the driver file address; the driver file includes the driver program and unbound hardware-related symbols; The hardware configuration function call module is used to call the hardware configuration function provided by the programmer firmware according to the parameters in the hardware parameter package; The binding module is used to bind the unbound hardware-related symbols to the address of the hardware configuration function to obtain a driver instance; The driver instance invocation module is used to invoke the driver instance to operate the target device.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images