Development method, device and equipment for in-vehicle driving

Abstract

Embodiments of the present application provide a kind of vehicle-mounted drive development method, device and equipment, wherein the method comprises: receiving the drive configuration parameter corresponding to vehicle-mounted hardware;Drive configuration parameter includes: hardware data manual and hardware configuration parameter;First prompt word is sent to the generation agent;First prompt word includes: drive configuration parameter and generation rule;Generation rule is used to control the generation agent to generate the drive result file corresponding to drive configuration parameter;Kernel compilation is carried out to drive result file, to obtain kernel result file;Kernel result file is written to the start partition of target device, after the restart of target device, the start log of target device is collected;From start log, the target log segment related to drive result file is extracted, and the fault diagnosis is carried out to target log segment, to obtain diagnostic result;Diagnostic result is normal to the function verification of target device.This embodiment of the present application can improve the development efficiency and development quality of vehicle-mounted drive.

Description

Technical Field

[0001] The embodiments of the present invention relate to the fields of intelligent vehicle technology and artificial intelligence technology, and in particular to a development method, apparatus and equipment for vehicle drive. Background Technology

[0002] With the development of intelligent vehicle technology, the electronic and electrical architecture of vehicles is evolving from distributed to centralized. The in-vehicle Ethernet system, as the backbone network for high-speed communication within the vehicle, is used to achieve high-bandwidth, low-latency data transmission between key devices such as cameras, radar, and central control screens. The in-vehicle platform needs to adapt to various PHY (Physical Layer Transceiver) chips to meet different speed requirements, and the development and debugging of PHY drivers is a crucial step in the integration of the in-vehicle Ethernet system.

[0003] In existing technologies, the development method for PHY drivers specifically includes: developers first consulting register configuration information from the PHY chip datasheet (usually hundreds of pages); then, based on the aforementioned register configuration information, configuring the Ethernet PHY driver, and manually writing the DTS (Device Tree Source) configuration file and driver initialization code according to the corresponding driver configuration information; and then performing a compilation-burning-debugging loop on the written DTS configuration file and driver initialization code. Specifically, the DTS configuration file is compiled into a device tree binary file, and the driver initialization code is compiled into a driver image.

[0004] In practical applications, Ethernet PHY driver configuration usually involves the manual integration of multi-level heterogeneous information, including DTS configuration, MDIO (Management Data Input / Output) bus bonding, PHY chip register initialization sequence, and pin multiplexing configuration. The configuration differences between different PHY chip models are large, and developers need to repeatedly consult the chip datasheet for manual adaptation, which is time-consuming and prone to errors. Summary of the Invention

[0005] This invention provides a method, apparatus, and device for developing vehicle-mounted drives, which can improve the development efficiency and quality of vehicle-mounted drives.

[0006] In a first aspect, embodiments of the present invention disclose a method for developing vehicle-mounted drives, the method comprising: Receive the driver configuration parameters corresponding to the vehicle hardware; the driver configuration parameters include: hardware datasheet and hardware configuration parameters; A first prompt word is sent to the generating agent; the first prompt word includes: driver configuration parameters and generation rules; the generation rules are used to control the generating agent to generate a driver result file corresponding to the driver configuration parameters; the driver result file includes: driver source code file and device tree configuration file; The driver result file is then compiled into a kernel result file. The kernel result file is burned to the boot partition of the target device, the target device is restarted, and the boot log of the target device is collected after the target device restarts. Extract the target log segment related to the driver result file from the startup log, and perform fault diagnosis on the target log segment to obtain the diagnosis result; Functional verification was performed on the target device whose diagnostic results were normal, and the corresponding verification results were obtained.

[0007] Secondly, embodiments of the present invention disclose a development apparatus for vehicle-mounted drive systems, the apparatus comprising: The parameter acquisition module is used to receive the driver configuration parameters corresponding to the vehicle hardware; the driver configuration parameters include: hardware datasheet and hardware configuration parameters. A code generation module is used to send a first prompt word to the generation agent; the first prompt word includes: driver configuration parameters and generation rules; the generation rules are used to control the generation agent to generate a driver result file corresponding to the driver configuration parameters; the driver result file includes: driver source code file and device tree configuration file; A compilation and build module is used to perform kernel compilation on the driver result file to obtain a kernel result file; The programming module is used to program the kernel result file to the boot partition of the target device, perform a reboot of the target device, and collect the boot logs of the target device after the reboot. The log collection and diagnosis module is used to extract target log segments related to the driver result file from the startup log, and to perform fault diagnosis on the target log segments to obtain diagnosis results; The verification module is used to perform functional verification on target devices whose diagnostic results are normal, and obtain the corresponding verification results.

[0008] Thirdly, embodiments of the present invention disclose an electronic device, including a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the aforementioned method.

[0009] Fourthly, embodiments of the present invention disclose a non-transitory computer-readable storage medium storing instructions that cause a processor to execute the aforementioned method.

[0010] Fifthly, embodiments of the present invention disclose a computer program product, characterized in that the computer program product includes a computer program stored in a computer-readable storage medium, and a processor of an electronic device reads from and executes the computer program from the computer-readable storage medium, causing the electronic device to perform the aforementioned method.

[0011] Compared with the prior art, the embodiments of the present invention have the following advantages: This invention uses driver configuration parameters as input to generate an intelligent agent and uses generation rules to control the intelligent agent to generate driver result files corresponding to the driver configuration parameters. This achieves automated generation from driver configuration parameters to driver result files, eliminating the need for developers to manually write driver code and significantly improving the development efficiency of vehicle drivers.

[0012] Secondly, the embodiments of the present invention divide the development process of vehicle drivers into five processing steps: "code generation → compilation and building → kernel deployment → log analysis → functional verification". Each processing step runs continuously in a predetermined order, building a closed-loop process that can complete driver development independently. The entire process does not require users to manually operate each step, effectively shortening the development time of vehicle drivers.

[0013] The process involves several stages: Code generation generates a driver file adapted to the vehicle hardware based on driver configuration parameters. Compilation and building involves performing kernel compilation on the driver file to obtain a kernel file. Kernel deployment writes the compiled kernel file to the target device's boot partition, reboots the target device, and runs the firmware with the new driver. Log analysis collects boot logs generated after the target device reboots, extracts target log fragments related to the driver file, and performs fault diagnosis on these fragments. Functional verification performs functional verification on target devices with normal diagnostic results and obtains the corresponding verification results.

[0014] Furthermore, in this embodiment of the invention, the kernel result file compiled based on the driver result file is written to the boot partition of the target device, the target device is restarted, and the boot log generated by the target device is obtained after the target device restarts. Based on the driver configuration parameters and the fault knowledge base, fault diagnosis is performed on the target log segments in the boot log related to the driver result file. This embodiment of the invention applies log analysis-based fault diagnosis methods to the development process of automotive drivers, which can automatically identify fault problems in the driver result file through the boot log, thereby improving the quality and efficiency of driver development. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the steps of a vehicle-mounted drive development method according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating the steps of a vehicle-mounted drive development method according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the steps of a vehicle-mounted drive development method according to an embodiment of the present invention. Figure 4 This is a schematic flowchart of the diagnostic method for vehicle drive according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a vehicle-mounted drive development device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a vehicle-mounted drive development system according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device 1100 according to an embodiment of the present invention. Detailed Implementation

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] It should be noted that the various embodiments of the present invention can be combined as long as there is no technical conflict.

[0018] In this field, vehicle drivers are software that enables vehicle hardware to be recognized and controlled by the vehicle system. Their function is to translate instructions from the upper-level system into operations that the vehicle hardware can perform, and to feed back the vehicle's status and data to the upper-level system. For example, they enable the PHY chip to transmit data as required and the camera to output images correctly, thus achieving communication between the vehicle hardware and the vehicle system, which is fundamental to the normal operation of the vehicle hardware.

[0019] The development of vehicle drivers is the process of writing software programs that enable normal interaction between the hardware and the system, based on the vehicle hardware specifications and the requirements of the vehicle system. The resulting driver program can convert upper-level instructions into hardware operations and provide feedback of hardware status and data to the upper-level system.

[0020] Vehicle-mounted hardware refers to physical devices or onboard hardware installed in a vehicle to perform specific functions. Examples of vehicle-mounted hardware include: vehicle-mounted Ethernet PHY chips, millimeter-wave radar, vehicle-mounted cameras, central control display modules, body controllers, powertrain control units, chassis sensors, vehicle-mounted storage chips, audio amplifiers, bus transceivers, etc. It is understood that this embodiment of the invention does not limit the specific vehicle-mounted hardware.

[0021] The vehicle drive development method of this invention can be executed by an electronic device, which can be a development device, such as a desktop computer, laptop computer, workstation, or other device with program development, compilation, and debugging capabilities.

[0022] The development method of vehicle-mounted drive according to the present invention will be described below through specific embodiments.

[0023] Reference Figure 1 The diagram illustrates a step-by-step flowchart of a vehicle-mounted drive development method according to an embodiment of the present invention. The method may specifically include the following steps: Step 101: Receive the driver configuration parameters corresponding to the vehicle hardware; the driver configuration parameters include: hardware datasheet and hardware configuration parameters; Step 102: Send a first prompt word to the generating agent; the first prompt word includes: driver configuration parameters and generation rules; the generation rules are used to control the generating agent to generate the driver result file corresponding to the driver configuration parameters; the driver result file includes: driver source code file and device tree configuration file; Step 103: Compile the driver result file into a kernel file. Step 104: Burn the kernel result file to the boot partition of the target device, execute the restart of the target device, and collect the boot log of the target device after the target device restarts; Step 105: Extract the target log segment related to the driver result file from the startup log, and perform fault diagnosis on the target log segment to obtain the diagnosis result; Step 106: Perform functional verification on the target device whose diagnostic result is normal, and obtain the corresponding verification result.

[0024] First, in this embodiment of the invention, the driver configuration parameters are used as input to the generating agent, and the generating agent is controlled by the generation rules to generate the driver result file corresponding to the driver configuration parameters. This realizes the automated generation from driver configuration parameters to driver result file, eliminating the need for developers to manually write driver code and significantly improving the development efficiency of vehicle drivers.

[0025] Secondly, the embodiments of the present invention divide the development process of vehicle drivers into five processing steps: "code generation → compilation and building → kernel deployment → log analysis → functional verification". Each processing step runs continuously in a predetermined order, building a closed-loop process that can complete driver development independently. The entire process does not require users to manually operate each step, effectively shortening the development time of vehicle drivers.

[0026] The process involves several stages: Code generation generates a driver file adapted to the vehicle hardware based on driver configuration parameters. Compilation and building involves performing kernel compilation on the driver file to obtain a kernel file. Kernel deployment writes the compiled kernel file to the target device's boot partition, reboots the target device, and runs the firmware with the new driver. Log analysis collects boot logs generated after the target device reboots, extracts target log fragments related to the driver file, and performs fault diagnosis on these fragments. Functional verification performs functional verification on target devices with normal diagnostic results and obtains the corresponding verification results.

[0027] Furthermore, in this embodiment of the invention, the kernel result file compiled based on the driver result file is written to the boot partition of the target device, the target device is restarted, and the boot log generated by the target device is obtained after the target device restarts. Based on the driver configuration parameters and the fault knowledge base, fault diagnosis is performed on the target log segments in the boot log related to the driver result file. This embodiment of the invention applies log analysis-based fault diagnosis methods to the development process of automotive drivers, which can automatically identify fault problems in the driver result file through the boot log, thereby improving the quality and efficiency of driver development.

[0028] In step 101, a configuration file input by the user can be received, which contains driver configuration parameters.

[0029] Driver configuration parameters refer to a set of information describing the identity information of the vehicle hardware, the connection relationship between the target platform and the vehicle hardware, its operating mode, and reference specifications. These driver configuration parameters include: hardware datasheets and hardware configuration parameters.

[0030] Hardware datasheets refer to official documentation provided by the hardware manufacturer that includes low-level specifications such as electrical characteristics, register definitions, and timing standards. These datasheets may include data tables and programming guides. Examples of hardware datasheets include the datasheet document for a PHY chip.

[0031] Hardware configuration parameters refer to the descriptive information that configures the identity of the vehicle hardware, the interconnection relationship between the target platform and the vehicle hardware, and the working mode.

[0032] The hardware configuration parameters specifically include: hardware identification parameters, hardware connection parameters, and hardware operating parameters.

[0033] Among them, the hardware identification parameter is used to distinguish the identity information of the vehicle hardware, including hardware model, compatible model, manufacturer ID (identifier), and device ID (identifier).

[0034] Examples of hardware identification parameters include: PHY chip model RTL8211F, manufacturer ID 0x001cc915.

[0035] Hardware connection parameters can refer to the physical interconnection configuration information between the target platform and the target hardware, including bus number, physical address, interrupt GPIO (General Purpose Input Output), reset GPIO, SPI (Serial Peripheral Interface) chip select, etc.

[0036] Examples of hardware connection parameters include: the PHY chip is mounted on the MDIO bus with a physical address of 0x01, and the reset GPIO is GPIO12, etc.

[0037] Hardware operating parameters refer to configuration items that control the operating status and performance of on-board hardware, including operating speed, operating mode, clock frequency, initialization register configuration sequence, and optional function enable flags.

[0038] Examples of hardware operating parameters include: PHY operating bandwidth mode of 1000BASE-T (gigabit baseband Ethernet based on twisted pair), and initialization register sequence of 0x00=0x1200, 0x04=0x0001.

[0039] Referring to Table 1, an example of driver configuration parameters is shown when the vehicle hardware is a PHY chip. The specific driver configuration parameters include: ethernet_port, phy_chip_model, phy_datasheet, phy_init_regs, phy_speed_mode, phy_reset_gpio, and phy_address.

[0040] Table 1 field name Data types illustrate ethernet_port enumerate Ethernet hardware port identifier (ethernet0 or ethernet1) phy_chip_model String PHY chip models (such as TJA1103, RTL8211F, AR8035, YT8531, etc.) phy_datasheet document PHY chip datasheet (PDF format) phy_init_regs Register List PHY Initialization Register Configuration Sequence (List of Register Address-Value Pairs) phy_speed_mode enumerate PHY bandwidth mode (auto-negotiation / 100Mbps / 1Gbps) phy_reset_gpio Integer PHY hardware reset signal corresponding GPIO pin number phy_address Integer The PHY chip uses PHYAD (PHY Physical Address, value range 0-31) on the MDIO (Management Data Input / Output) bus. This invention can convert received driver configuration parameters into a configuration data structure. The configuration data structure can adopt a key-value pair format. This configuration data structure can standardize the format of various driver configuration parameters, facilitating subsequent unified parsing and reading. Keys allow for quick location and modification of corresponding parameter values, significantly simplifying parameter maintenance. This configuration data structure is adaptable to program calling logic, highly extensible, and only requires adding new key-value pairs when adding new hardware configuration parameters, without needing to reconstruct the overall structure.

[0041] This invention can also perform parameter validity verification on the driver configuration data structure. The parameter validity verification is used to check whether the value of the key-value pair in the configuration data structure is within a preset range. For example, parameter validity verification includes: ethernet_port value range verification, phy_address value range (0-31) verification, phy_reset_gpio validity verification, and phy_speed_mode enumeration value verification, etc.

[0042] If the parameter validity check passes, the driver configuration data structure can be sent to step 102. If the driver configuration data structure fails, a corresponding prompt message can be output. The above prompt message can remind the user to modify the configuration file.

[0043] In this embodiment of the invention, the Agent is an intelligent agent system with an LLM (Large Language Model) as its core controller. Essentially, it's an agent system that controls the large language model to solve user problems. It relies on the large language model as its core decision-making and processing unit, utilizing the logical reasoning capabilities of the large language model to solve user problems. In practical applications, the agent can specifically be an autonomous software or hardware entity. The agent in this embodiment may include: a generating agent and a diagnostic agent, etc.

[0044] In step 102, the generating agent uses a large language model as the core control unit, receives the first prompt word carrying the driving configuration parameters and generation rules, and, based on the reasoning ability of the large language model and the constraints of the generation rules, parses the driving configuration parameter information and automatically outputs the driving source code file and device tree configuration file that match the vehicle hardware.

[0045] The generation rules are the specifications that guide the generation of intelligent agents to parse driver configuration parameters and generate driver result files. They include parameter parsing rules, code generation logic, compilation adaptation requirements, kernel version compatibility standards, register mapping writing specifications, pin configuration syntax, comment format, file naming specifications, functional code modularization, exception handling code writing requirements, device node description paradigm, bus communication configuration format, resource usage definition rules, etc., which are used to limit the generation method, form and content of driver result files. The driver source code file is a program source code text generated based on the driver configuration parameters. It carries the program logic for vehicle hardware initialization, register reading and writing, interrupt response, I2C (Inter-Integrated Circuit) / Ethernet bus interaction, and hardware function start and stop control. It can be compiled by cross-compilation tools and run in the system kernel to realize data interaction and function control between the operating system and vehicle hardware. The device tree configuration file is a configuration text used to statically describe the physical resource information of the vehicle hardware to the operating system kernel. It records hardware topology and resource information such as hardware bus mounting, pin assignment, power supply parameters, interrupt numbers, hardware addresses, and clock resources. When the kernel starts, it parses the device tree configuration file to complete hardware resource allocation and device matching and binding, adapting to different hardware without modifying the kernel source code.

[0046] The embodiments of the present invention can provide the following implementation of the first prompt word: Implementation method A1 In implementation method A1, the first prompt word further includes: a target device tree template and a target driver code template that match the target platform and driver framework; then the generation rule is specifically used to control the generation agent to fill in the target device tree template and the target driver code template according to the driver configuration parameters to obtain a driver result file.

[0047] Implementation method A2 In implementation method A2, the first prompt word further includes information on hardware features and a code knowledge base; then the generation rule is also used to control the generation agent to obtain target driver code that matches the hardware features from the code knowledge base, and generate a driver result file corresponding to the driver configuration parameters based on the target driver code.

[0048] Implementation method A1 (Artificial Intelligence) employs a layered code generation architecture that combines templates and AI. This generation architecture consists of two layers: a template layer and an AI layer.

[0049] The template layer pre-acquires target device tree templates and target driver code templates that match the target platform and driver framework. The target driver code template defines the framework structure, interface specifications, registration process, and device node description paradigm of the driver code, ensuring that the generated driver result file conforms to the driver framework specifications and kernel compilation requirements of the target platform.

[0050] The AI ​​layer, centered on a large language model, receives driver configuration parameters and is responsible for adapting to the specific automotive hardware. For example, the AI ​​layer's generative agent parses the hardware datasheet to extract inherent characteristics of the automotive hardware, such as manufacturer identification, register definitions, and timing requirements. Combined with board-level connection and operating mode information from the hardware configuration parameters, it maps and fills in placeholders in the target driver code template to generate customized code adapted to the specific automotive hardware.

[0051] This layered architecture ensures code standardization and platform compatibility through the template layer, while the AI ​​layer enables adaptability to automotive hardware. Working together, these two layers avoid formatting deviations and interface non-standardization issues that can occur when generating code from scratch, and overcome the limitations of fixed templates in flexibly adapting to different chip models, thus achieving automated generation from hardware specifications to compilable driver code.

[0052] The target platform refers to the set of underlying hardware and basic software on which the driver (corresponding to the driver source code file) depends for its operation. It includes at least the processor, on-chip peripheral controller, operating system kernel (or its variants), system services, and supporting cross-compilation toolchain. It is the basic environment for driver compilation, linking, initialization, and execution.

[0053] Examples of target platforms include the Horizon Robotics J6B chip. The Horizon Robotics J6B chip comprises an ARM (Advanced RISC Machine) Cortex A78AE (Automotive Enhanced) processor core, an Ethernet MAC (Media Access Control) controller, a Linux (Open Source Unix-like Operating System) 5.10 kernel, and an aarch64 (64-bit ARM Architecture) Linux GNU (GNU's Not Unix) cross-compilation toolchain, collectively forming a target platform.

[0054] The target device refers to the complete hardware that integrates the target platform and various vehicle hardware (such as sensors, PHY chips, and CAN transceivers). It has independent storage media, boot partitions, power supply and interface circuits, and is the physical carrier on which the driver firmware (including device tree and driver module) is finally burned, deployed and powered on.

[0055] Examples of target devices include: automotive-grade intelligent cockpit domain controllers or intelligent driving domain controllers equipped with the aforementioned Horizon J6B target platform, with onboard Ethernet PHY chips, CAN transceivers, eMMC boot disks, and power management modules.

[0056] A driver framework refers to a standardized software development model defined by the operating system kernel for a specific type of hardware. It defines the interface functions, core data structures, device registration and deregistration processes, and standard interaction methods with kernel subsystems (such as the network stack and I / O subsystem) for driver implementation. It is used to standardize the driver design for functional modules in the target device on the target platform.

[0057] Examples of driver frameworks include the Linux Ethernet PHY subsystem framework, which defines the phy_driver structure, probe() / config_init() callback interfaces, MII management bus operations, and the connection process between phy_connect() and the MAC layer. PHY chip drivers are developed following this framework.

[0058] During driver development, the target platform determines which kernel APIs (Application Programming Interfaces) and SoC (System-on-Chip) peripheral controllers the driver code interfaces with; the driver framework determines the model, structure, and interface specifications that the driver code should follow; and the target device is the actual carrier of the in-vehicle hardware controlled by the driver code, and the physical entity through which the driver is ultimately deployed and runs. A complete driver program is a program adapted to a specific target platform, conforming to a specific driver framework, and designed to control specific hardware modules on the target device.

[0059] The target device tree template and target driver code template can be derived from a template library. This template library contains multiple pre-set templates, each corresponding to a specific combination of target platform and driver framework.

[0060] The target platform refers to the set of underlying hardware and basic software on which the driver depends for operation, such as the QNX operating system.

[0061] A driver framework refers to a standardized driver development model defined by an operating system for a specific type of hardware, such as a device tree plus MDIO bus framework.

[0062] In this embodiment of the invention, a target device tree template and a target driver code template matching the target platform and driver framework can be obtained from a template library based on the user-specified target platform and driver framework. The target driver code template contains placeholders to be filled, which are used to subsequently replace the configuration information of the specific hardware.

[0063] Referring to Table 2, examples of the driver code template and device tree template for a PHY chip according to an embodiment of the present invention are shown.

[0064] The driver code template is formatted as .c or .h. The .c file is the C source file, containing the implementation code of the driver functions; the .h file is the C header file, containing driver-related macro definitions, data structure declarations, and function interface declarations. The device tree template is formatted as .dts or .dtsi. The .dts file is the device tree source file, used to describe the device topology and resource configuration of a single hardware platform; the .dtsi file is the device tree include file, used to describe the definitions of common peripherals or reusable device nodes shared by the SoC, and is referenced by multiple .dts files.

[0065] Table 2 Template type File format Template content Device Tree Template .dts / .dtsi Ethernet controller node definition, MDIO child node definition, PHY node attribute declaration (including placeholders) Driver code template .c / .h The PHY driver framework code includes driver registration, PHY initialization function framework, and register read / write function framework (including placeholders). The generation rule is specifically used to control the generation agent to extract chip parameters from the hardware datasheet and, based on the chip parameters and the hardware configuration parameters, fill in the target device tree template and the target driver code template.

[0066] For example, if the hardware datasheet is a PHY chip datasheet, the generated agent can extract the following chip parameters: the PHY chip's OUI (Organizationally Unique Identifier) ​​and model identifier, supported rate / duplex mode combinations, key register definitions related to initialization in the register map table, clock configuration requirements, and reset timing requirements.

[0067] Chip parameters can reflect the inherent characteristics of automotive hardware, such as OUI, register definitions, timing requirements, etc., and are static specification information defined by hardware manufacturers.

[0068] Driver configuration parameters: These reflect how users use the vehicle hardware, such as which bus it is connected to, which physical address it uses, which reset GPIO it selects, and which bandwidth mode it is configured with. These are engineering configuration information determined by the user.

[0069] Chip parameters are used to fill in fields related to the inherent characteristics of the automotive hardware, such as OUI and phy_id in the driver matching table, the specific values ​​of the initialization register sequence, and the delay parameters of the reset timing.

[0070] Driver configuration parameters are used to populate fields related to board-level connections and usage, such as physical address, reset GPIO number, and rate attribute corresponding to bandwidth mode.

[0071] The generated intelligent agent fills in the placeholders in the target driver code template based on the extracted chip parameters and hardware configuration parameters to generate customized driver code.

[0072] Filling in placeholders in the target driver code template can include mapping a specific piece of information from the driver configuration parameters to a specific attribute in the template. For example, mapping the value of phy_speed_mode (e.g., 1000) to the value of the max-speed attribute in the device tree template.

[0073] Filling placeholders in the target driver code template can include actions such as writing specific numerical values ​​or strings into the placeholder positions in the template. For example, writing the GPIO number "GPIO12" into the reset-gpios attribute.

[0074] Example of filling in a device tree template: Map the ethernet_port to the corresponding Ethernet controller node (ethernet@0 or ethernet@1); Populate the reg attribute of the PHY node in the MDIO child node with phy_address; Fill the reset-gpios attribute of the PHY node with phy_reset_gpio; Map phy_speed_mode to the max-speed attribute value (100 or 1000) of the PHY node. Configure the clocks and clock-names properties according to the clock requirements extracted from the datasheet; Example of filling in the driver code template: Populate the OUI and model identifier corresponding to phy_chip_model into the phy_driver.phy_id and phy_driver.phy_id_mask fields of the driver matching table; Convert the phy_init_regs list into a sequential register in the PHY initialization function and write the code. The delay parameters in the hardware reset function are generated based on the reset timing requirements extracted from the datasheet. Initialization code for configuring the auto-negotiation enable register or forced rate register according to phy_speed_mode In one example, the generated driver output file includes the following parts: The device tree configuration file (.dts) describes the hardware connectivity of the PHY chip on the target platform; The driver source code files (.c / .h) contain the driver registration structure, probe functions, initialization functions, register read / write functions, etc.

[0075] The target driver code template contains a generic driver registration structure framework, where the chip model and method name are represented by placeholders XXXXXX: static device_method_t XXXXXX_methods[] = { / * device interface * / DEVMETHOD(device_probe,XXXXXX_probe), DEVMETHOD(device_attach,XXXXXX_attach), DEVMETHOD(device_detach,mii_phy_detach), DEVMETHOD(device_shutdown,bus_generic_shutdown), DEVMETHOD_END }; static driver_t XXXXXX_driver = { "XXXXXX", XXXXXX_methods, sizeof(struct mii_softc) }; The generated agent, based on the hardware identifier parameter (chip model YT8531) in the hardware configuration parameters, replaces the placeholder XXXXXX with the specific chip model yt8531 to obtain a customized code snippet: static device_method_t yt8531_methods[] = { / * device interface * / DEVMETHOD(device_probe,yt8531_probe), DEVMETHOD(device_attach,yt8531_attach), DEVMETHOD(device_detach,mii_phy_detach), DEVMETHOD(device_shutdown,bus_generic_shutdown), DEVMETHOD_END }; static driver_t yt8531_driver = { "yt8531", yt8531_methods, sizeof(struct mii_softc) }; This customized code snippet indicates that during subsequent system startup, the kernel will use the `yt8531_probe` function to check if a PHY chip with an OUI and phy_id matching the YT8531 chip exists on the MDIO bus. If a match is found, the `yt8531_attach` function will be called to initialize and register the PHY chip. Afterward, the upper-layer network protocol stack can communicate with the PHY chip through the standard MII (Media Independent Interface) interface to implement driver control functions such as rate configuration, link status monitoring, and data transmission for the YT8531 chip.

[0076] In this embodiment, the generating agent obtains the context information required for the template filling task through the first prompt word, including driver configuration parameters, target device tree template, target driver code template, and generation rules. The generation rules contain constraints on the filling logic. Based on a large language model with sufficient domain knowledge, the template filling task can be completed using only the first prompt word, without the need for fine-tuning training.

[0077] Of course, the embodiments of the present invention can also perform fine-tuning training of the generated agent in advance. The fine-tuning training process of the generated agent includes: obtaining a first training sample, the first training sample including: sample-driven configuration parameters, sample target device tree template, sample target driving code template, sample generation rules and corresponding sample-driven result files, the sample-driven result files serving as labels; taking the sample-driven configuration parameters, the sample target device tree template, the sample target driving code template and the sample generation rules as inputs to obtain a prediction-driven result file; calculating the loss value between the prediction-driven result file and the labels; adjusting the model parameters of the generated agent through a backpropagation algorithm to make the loss value converge; stopping training when the loss value is lower than a preset threshold or reaches a preset number of training rounds, and obtaining the fine-tuned generated agent.

[0078] Implementation method A2 employs a code generation method based on retrieval enhancement. First, a vectorized code knowledge base for the vehicle hardware is constructed. This knowledge base contains verified driver code, device tree configurations, and debugging records for multiple vehicle hardware components. Upon receiving a first prompt, the generating agent retrieves existing driver implementations matching the hardware characteristics in the code knowledge base, rather than filling in predefined templates, based on the hardware features in the prompt.

[0079] Hardware characteristics refer to the attributes of automotive hardware that can be used to distinguish the underlying design and functional performance, including module type, interface standard, register address mapping characteristics, supported operating modes, and abstract values ​​of key electrical parameters.

[0080] For example, the hardware characteristics of a PHY chip are: Module type = Ethernet PHY, Interface standard = MII / GMII / RGMII, Supported rate set = {10M, 100M, 1000M}, Register page base address = 0x00 / 0x0A, OUI = 0x001cc915, Auto-negotiation support = TRUE.

[0081] During the generation process, the generating agent uses the retrieved target driver code as a basis and combines it with driver configuration parameters to generate the driver result file. In this approach, the generating agent can reference the driver implementation logic of the same or similar in-vehicle hardware represented by the target driver code, thus exhibiting stronger adaptability to new in-vehicle hardware.

[0082] Specifically, the generating agent replaces and adjusts the hardware-related parts of the target driver code, such as chip model, register configuration, pin allocation, and bus address, based on the hardware identification parameters, hardware connection parameters, and hardware operating parameters in the driver configuration parameters. It also modifies the node attributes in the device tree configuration file accordingly, ultimately generating a driver result file adapted to the vehicle hardware.

[0083] With a sufficient accumulation of code knowledge base, the quality of generated code and the first-time compilation success rate can be further improved, and it is more adaptable to new automotive hardware.

[0084] Of course, the embodiments of the present invention can also be implemented using fine-tuning training. The fine-tuning training process of the generated agent includes: obtaining a second training sample, the second training sample including: sample hardware features, sample code knowledge base information, sample driver configuration parameters, and corresponding sample driver result files; the generated agent retrieves sample target driver code that matches the sample hardware features from the code knowledge base based on the sample hardware features; the generated agent takes the sample target driver code and the sample driver configuration parameters as input to obtain a prediction driver result file; calculates the loss value between the prediction driver result file and the sample driver result file; adjusts the model parameters of the generated agent through the backpropagation algorithm to make the loss value converge; when the loss value is lower than a preset threshold or reaches a preset number of training rounds, training is stopped, and the fine-tuned generated agent is obtained.

[0085] This embodiment of the invention can also perform syntax checks on the generated driver result file. The above syntax checks are used to verify the device tree syntax (DTC, Device Tree Compiler) and C code syntax (compiler preprocessing checks). If a syntax error is found, the error information is fed back to the generation agent so that the generation agent can correct the driver result file according to the error information.

[0086] This invention can support N_retry number of correction iterations (N_retry ranges from 2 to 5, with a default of 3).

[0087] This invention, by adding a syntax check step before compilation, can detect syntax errors in device tree files and driver source code files at an early stage, avoiding sending obviously erroneous code into the time-consuming cross-compilation process. After the error information is fed back to the generation agent, the generation agent can perform targeted corrections to the driver result file based on the error type and location, supporting multiple correction iterations until the syntax check passes or the preset maximum number of iterations is reached. This syntax check step reduces the number of invalid compilations and shortens the overall development cycle.

[0088] In step 103, the driver result file is kernel compiled, the device tree configuration file and the driver source code file are integrated into the kernel source code tree of the target platform and cross-compiled to generate a kernel result file that can be started and run on the target device. The kernel result file includes a kernel image file and a device tree binary file.

[0089] The process of compiling the driver result file into a kernel includes: Step B1: Copy the device tree configuration file to the corresponding device tree directory in the kernel source code tree; Step B2: Copy the driver source code file to the corresponding subdirectory of the kernel driver directory; Step B3: Add the compilation rules for the driver source code file in the driver result file to the kernel compilation rule file, and add the configuration options for the driver source code file in the driver result file to the kernel configuration option file; Step B4: Call the cross-compilation toolchain corresponding to the target platform to perform kernel compilation and obtain the corresponding compilation results; the compilation results include: the kernel result file if the compilation is successful, or the compilation error log if the compilation fails.

[0090] Step B1 copies the generated device tree configuration file to the corresponding device tree directory in the target platform kernel source code tree stored on the compilation device. The compilation device and the development device (the device used to generate the driver result file) can be the same or different.

[0091] The target platform kernel source tree refers to the complete kernel source code directory structure of the operating system running on the target platform, including kernel modules, configuration files, compilation rules, etc., which need to be pre-deployed on the compilation device.

[0092] After executing step B1, the device tree configuration file is stored in the specified device tree directory of the target platform kernel source code tree within the compiled device.

[0093] Step B2 copies the driver source code file to the corresponding subdirectory of the kernel driver directory within the kernel source code tree of the target platform on the compilation device.

[0094] Step B3 locates the subdirectory containing the driver source code file within the target platform kernel source code tree already deployed on the compilation terminal device. This subdirectory contains a kernel compilation rule file and a kernel configuration option file. A new compilation instruction adapted to the driver source code file is added to the kernel compilation rule file to initiate the compilation process for that driver source code file. A new independent configuration entry is added to the kernel configuration option file to set the optional switch parameters corresponding to the driver source code file.

[0095] After executing step B2, the kernel compilation rule file and kernel configuration option file in the target platform kernel source tree have been updated, and the driver source code file has been included in the compilation scope; the device tree configuration file is located in a position that meets the requirements of the kernel source tree and can directly participate in the compilation.

[0096] Step B4 executes the pre-configured cross-compilation instructions on the compilation terminal device, based on the target platform kernel source code tree already deployed within the device. These instructions are compilation scripts containing the storage paths of various components in the cross-compilation toolchain, including the compiler, linker, and assembler, as well as the target architecture identifier and compilation parameters. The script's root directory is set to the root directory of the target platform kernel source code tree. After running the cross-compilation instructions, the script automatically loads and schedules the cross-compilation toolchain to perform a complete compilation of the kernel source code tree.

[0097] The cross-compilation toolchain is installed and runs on the compilation device, and can compile and generate files adapted to the target platform's runtime environment. The generated files include kernel image files and DTB (Device Tree Blob) files.

[0098] This invention can collect compilation status information during the compilation process. This compilation status information includes status prompts and progress reports when compilation is normal, and error prompts and reasons for errors when compilation fails. If error prompts or reasons for errors are present in the compilation status information, compilation is determined to have failed, and a compilation error log is generated based on the error prompts and reasons for errors. If the compilation status information only contains normal status prompts and progress reports, without error prompts or reasons for errors, compilation is determined to have succeeded, and the generated kernel image file and DTB file are read and exported.

[0099] In one implementation, if the compilation result includes a compilation error log in case of compilation errors, the method may further include: A second prompt word is sent to the error analysis agent; the second prompt word includes: compilation error log and analysis rules; the analysis rules are used to control the error analysis agent to generate a first modification suggestion based on the error type of the compilation error log; the first modification suggestion is used to modify the error type of the driver result file; A third prompt word is sent to the generating agent; the third prompt word includes: the driving result file and a first modification suggestion; the generating agent modifies the driving result file according to the first modification suggestion to obtain the modified driving result file; The modified driver result file is then compiled into a kernel.

[0100] If the compilation result includes compilation error logs, the error analysis agent first generates a first modification suggestion based on the compilation error logs and analysis rules, then the generation agent modifies the driver result file according to the first modification suggestion, and finally recompiles the modified driver result file.

[0101] The analysis rules are specifically used to control the error analysis agent to identify the errors contained in the compilation error log after receiving it, and to determine the corresponding modified file and modification location in the driver result file based on the file name and line number range contained in the compilation error log; on this basis, to generate corresponding modification content for the above errors, and to organize the modified file, modification location and modification content into a first modification suggestion.

[0102] After generating the intelligent agent to receive the driver result file and the first modification suggestion, the agent performs modification operations at the corresponding position in the driver result file according to the modification file, modification location and modification content specified in the first modification suggestion, replacing or supplementing the corresponding code snippets to obtain the modified driver result file.

[0103] Step 104 writes the compiled kernel result file to the boot partition of the target device, enabling the target device to load and run the kernel result file after reboot, thereby actually executing the developed vehicle driver on the target hardware; after reboot, the boot log output by the target device is collected via serial port. The boot log contains running status information during the driver loading and initialization process, which facilitates subsequent steps to extract target log fragments related to the driver result file from the boot log for fault diagnosis.

[0104] In the specific implementation, the kernel image file and the DTB file are packaged into a boot.img (boot image) file, and the following processing is performed on the target device based on the boot image file: Step C1: Run the ADB (Android Debug Bridge) device connection detection command on the flashing device. This command verifies the connection status with the target device. If the target device fails to connect normally, a connection error message is generated, and the flashing process is aborted. The flashing device can be the same as or different from the development device.

[0105] Step C2: Run the ADB command to reboot to Fastboot mode on the burning device to switch the target device to Fastboot mode.

[0106] Step C3: Run the Fastboot partition burning command on the burning end device to process the boot image file into blocks and burn it into the boot partition of the target device; after burning is completed, execute the Fastboot restart command on the burning end device to make the target device boot according to the boot partition that has just been burned, and generate a burning operation log on the burning end. The log content includes four items: file name, file size, burning time, and restart timestamp.

[0107] An example of a Fastboot partition flashing command is: `fastbootflash -S32Mboot_aboot.img`. This command is used to flash the `boot.img` file in chunks (32MB each) to the `boot_a` partition of the target device. The `-S32M` parameter specifies the chunk size for sparse flashing as 32MB, suitable for transferring large image files; `boot_a` is the primary boot partition identifier under the A / B partition architecture of the target device.

[0108] Step C4: Automatically set up a UART (Universal Asynchronous Receiver / Transmitter) serial communication link on the programming device (e.g., baud rate configured to 921600bps). This serial communication link is used to receive the startup log of the target device.

[0109] It should be noted that the above method of partitioning and flashing using the Fastboot protocol is only an optional embodiment. In fact, this partitioning and flashing method can also be replaced by a network flashing method based on TFTP (Trivial File Transfer Protocol): the kernel result file is transferred using the TFTP protocol during the bootloader stage of the target device via an Ethernet connection.

[0110] The TFTP-based network flashing method can achieve a transfer speed that is 2-3 times faster than the Fastboot protocol for partition flashing on gigabit networks, and it supports remote flashing (without requiring a physical USB connection); however, the target device's bootloader must already support TFTP functionality.

[0111] The output of step 104 includes: the status of the successful or failed burning result; and the startup log data stream transmitted after the target device restarts.

[0112] Step 105 involves filtering log lines related to the driver result file from the startup log to form a target log segment. This target log segment reflects the loading and initialization status of the vehicle driver on the target device. By performing fault diagnosis on the target log segment, it is possible to identify whether there are any abnormalities in the vehicle driver during operation, and to provide a basis for subsequent functional verification.

[0113] In the specific implementation, target log segments related to the driver result file are extracted from the startup log. The corresponding extraction rules are implemented through keyword matching and log level filtering. The keyword set corresponding to the keyword matching is set according to the technical implementation requirements, and in practical applications, it is usually determined by the hardware identification parameters and hardware functional module types in the driver configuration parameters. For example, the above keyword set includes at least: hardware model name, module type identifier, and log identification keywords frequently used by this type of vehicle hardware in driver initialization and working status output.

[0114] The embodiments of the present invention can provide the following implementation method for fault diagnosis of the target log segment: Implementation method D1 In implementation method D1, the process of fault diagnosis of the target log segment includes: A fourth prompt word is sent to the diagnostic agent; the fourth prompt word includes: driver configuration parameters, target log segment, fault knowledge base information and diagnostic rules; the diagnostic rules are used to control the diagnostic agent to perform fault diagnosis on the target log segment according to the driver configuration parameters and the fault knowledge base, and obtain a diagnostic result.

[0115] After receiving the fourth prompt word, the diagnostic agent reads the driver configuration parameters, target log fragments, fault knowledge base information, and diagnostic rules contained within it. The fault knowledge base information includes the access address or index information, used by the diagnostic agent to locate and retrieve content from the fault knowledge base; the fault knowledge base stores known error mode-cause-solution triples; and the diagnostic rules are the control constraints carried by the fourth prompt word, used to constrain the diagnostic agent's diagnostic behavior.

[0116] In a specific implementation, the hardware datasheet includes: error descriptions and debugging guidelines; the fault knowledge base stores the mapping relationship between error patterns, fault causes, and solutions; The diagnostic rules are used to control the diagnostic agent to perform the following operations: The log features in the target log fragment are matched with error patterns in the fault knowledge base to obtain successfully matched candidate fault causes and candidate solutions; Based on the error descriptions and debugging guidelines in the hardware datasheet, the candidate fault causes and candidate solutions are screened to obtain the screened target fault causes and target solutions; Based on the target fault cause and target solution, a diagnostic result is generated; the diagnostic result includes: diagnostic status; if no abnormality is diagnosed in the diagnostic status, the diagnostic result also includes: error type, error cause, and second modification suggestion.

[0117] The candidate fault cause is compared with the error description in the hardware datasheet. If the candidate fault cause matches the description in the hardware datasheet and is consistent with the actual configuration, the candidate fault cause is determined as the target fault cause; if the candidate fault cause does not match the description in the hardware datasheet, the candidate fault cause is excluded.

[0118] Similarly, each candidate solution is compared with the debugging guidelines in the hardware datasheet. Candidate solutions that fit the current target fault cause and conform to the manual's debugging specifications are retained; these retained candidate solutions are the target solutions. All other candidate solutions that do not conform to the debugging specifications or cannot match the fault scenario are eliminated.

[0119] In this embodiment, the diagnostic agent obtains the contextual information required for the fault diagnosis task through the fourth prompt word, including driver configuration parameters, target log fragments, fault knowledge base information, and diagnostic rules. The diagnostic rules contain logical constraints for matching, filtering, and diagnosis. Based on a large language model with sufficient domain knowledge, the fault diagnosis task can be completed through the fourth prompt word, eliminating the need for fine-tuning training of the diagnostic agent.

[0120] Of course, the embodiments of the present invention can also perform fine-tuning training of the diagnostic agent in advance. The fine-tuning training process of the diagnostic agent includes: obtaining a third training sample, the third training sample including: sample-driven configuration parameters, sample target log fragments, information of the sample fault knowledge base, sample diagnostic rules, and corresponding sample diagnostic results, the sample diagnostic results being used as labels; taking the sample-driven configuration parameters, the sample target log fragments, the information of the sample fault knowledge base, and the sample diagnostic rules as inputs to obtain predicted diagnostic results; calculating the loss value between the predicted diagnostic results and the labels; adjusting the model parameters of the diagnostic agent through a backpropagation algorithm to make the loss value converge; stopping training when the loss value is lower than a preset threshold or reaches a preset number of training rounds, and obtaining the fine-tuned diagnostic agent.

[0121] Referring to Table 3, an example of the diagnostic results of an embodiment of the present invention is shown. The diagnostic results specifically include: a diagnostic status field, a root cause analysis field, a second modification suggestion field, and an error list field.

[0122] Optionally, the diagnostic agent determines the content of the root cause analysis field based on the target cause; determines the content of the second modification suggestion field based on the target solution; determines the content of the diagnostic status field based on whether candidate error types are identified and whether the target cause is determined; and determines the content of the error list field based on the candidate error types and log line numbers. For example, the candidate error types and corresponding log line numbers are filled into the error list field, the target fault cause is filled into the root cause analysis field, and the target solution is filled into the second modification suggestion field, and the diagnostic status is set according to whether the fault exists.

[0123] Table 3 Diagnostic results fields Data types Basis for determination illustrate Diagnostic status enumerate Error situation If no error pattern is matched, it is considered normal; if an error pattern is matched and the cause is identified, it is considered abnormal; if an error pattern is matched but the cause cannot be identified, it is considered a warning. Error List Error List Candidate error types and log line numbers Each error entry includes the error type, error description, and corresponding log line number. Root cause analysis String Target Reasons The identified target causes are used as root cause analysis. Second suggestion for error correction Second revision suggestion Target Solution Based on the target solution, and combined with the file paths and code locations in the driver result file, a second modification suggestion is generated, which includes the modified files, modification locations, and modification content. In one example, the second suggested modification to the diagnostic agent's output is as follows: Modify the file: imx8mp-evk-phy.dts Modify the `reg` attribute of the `PHY` node `ðphy0`. Modification: Change reg =
; to reg =; After the developers review and confirm the second modification suggestion, they input the second modification suggestion and the corresponding driver result file into the generation agent, so that the generation agent can modify the driver result file according to the second modification suggestion. For example, based on the second modification suggestion, the generation agent automatically locates the corresponding modification position in the device tree configuration file, replaces reg =
with reg =, and saves the modified device tree configuration file. Then, steps 103 (compiling) and 104 (burning) are automatically retried to enter the next round of debugging iterations.

[0124] Implementation Method D2 In implementation D2, the process of fault diagnosis of the target log segment includes: matching the log features in the target log segment with the error patterns in the fault knowledge base to obtain successfully matched candidate fault causes and candidate solutions, and determining the diagnosis result based on the candidate fault causes and candidate solutions.

[0125] The fault knowledge base pre-stores multiple known error patterns, each associated with corresponding log features (keywords or regular expressions), fault causes, and solutions. Log features are extracted from the target log segment, and these features are compared one by one with the log features associated with the error patterns in the fault knowledge base. If a log feature in the target log segment matches a certain error pattern, a successful match is determined, and the fault cause corresponding to that error pattern is designated as a candidate fault cause, and the corresponding solution as a candidate solution. Based on the candidate fault causes and candidate solutions, a diagnostic result (including diagnostic status, error list, root cause analysis, and modification suggestions) is generated. This implementation method D2 diagnoses known error patterns quickly (matching in approximately milliseconds).

[0126] Implementation method D3 In implementation method D3, the process of diagnosing the target log segment includes: classifying the target log segment using a fault classification model to obtain the fault type corresponding to the target log segment, and determining the diagnosis result based on the fault cause and investigation direction corresponding to the fault type.

[0127] The fault classification model can be a trained machine learning text classification model that can classify the input target log fragment into a predefined fault type.

[0128] The target log segment is input into the fault classification model, which outputs the fault type to which the target log segment belongs. Based on the fault type, a predefined fault type-fault cause-troubleshooting direction mapping table is queried to obtain the fault cause and troubleshooting direction corresponding to that fault type. The fault cause is filled into the root cause analysis field of the diagnostic result, and the troubleshooting direction is organized into the modification suggestion field. An error list field is generated by combining the fault type and log line number, and the diagnostic status field is determined accordingly, thus obtaining the diagnostic result. This implementation method D3 can cover log content not matched by the fault knowledge base.

[0129] Step 106 verifies the functionality of the target device whose diagnostic result is normal. By executing test items corresponding to the vehicle hardware type on the target device, the actual operating data is obtained and compared with the preset judgment standard to confirm whether the vehicle driver's control function of the vehicle hardware is normal and whether the performance indicators meet the standards, providing a basis for the completion of driver development or entering the next iteration.

[0130] The process of functional verification for target devices whose diagnostic results are normal specifically includes: Step E1: Determine at least one test item corresponding to the vehicle hardware, and the verification judgment criteria for each test item; Step E2: Execute each test item on the target device to obtain the execution data for each test item; Step E3: Determine the project verification result for each test project based on the execution data of each test project and the corresponding verification judgment criteria for each test project. Step E4: Generate verification results based on the verification results of all test items.

[0131] In the process of functional verification of a target device with a diagnostic result of normal, this embodiment of the invention first determines at least one test item corresponding to the vehicle hardware and the verification judgment standard corresponding to each test item; then, each test item is executed sequentially on the target device, and the execution data of each test item is collected; next, the execution data of each test item is compared with the verification judgment standard corresponding to the test item to determine the project verification result of each test item; finally, the project verification results of all test items are combined to generate the final verification result.

[0132] The process of generating verification results based on the verification results of all test items specifically includes: If all test projects show successful verification results, the verification result is: Driver development completion confirmation information; or In the case where the verification result of only one test item is successful, the verification result includes: verification failure data.

[0133] When the in-vehicle hardware includes a PHY chip, the test items corresponding to the PHY chip include: network connectivity test item and network bandwidth test item. The verification criteria for the network connectivity test items include: the packet loss rate of the test does not exceed the preset packet loss rate threshold, and the average round-trip time does not exceed the preset time delay threshold. The verification criteria for the network bandwidth test items include: the tested TCP bandwidth and UDP bandwidth are not lower than the preset lower limit threshold corresponding to the PHY bandwidth mode.

[0134] In one alternative embodiment, the method may further include: sending a fifth prompt word to the generating agent; the fifth prompt word includes: a driver result file and verification failure data, so that the generating agent modifies the driver result file according to the verification failure data to obtain a modified driver result file.

[0135] For test items that fail verification, extract their verification failure data (including the name of the failed test item, measured data, and a description of the deviation from the judgment criteria). Send the verification failure data and the driver result file together to the generation agent. Based on the verification failure data, the generation agent locates the code segment or device tree node associated with the failed test item in the driver result file. According to the expected judgment criteria and measured deviation recorded in the verification failure data, the agent modifies the attribute values ​​of the code segment or device tree node (such as adjusting the initialization register sequence, modifying the rate attribute or GPIO configuration in the device tree, etc.) and outputs the modified driver result file.

[0136] In one example, the functional verification process for the PHY chip specifically includes: Step F1: Perform network connectivity verification; Using ADB, execute the ping command on the target device to send ICMP (Internet Control Message Protocol) probe packets to the preset target address. Send N_ping probe packets consecutively, where N_ping ranges from 10 to 100, with a default value of 20. Record the packet loss rate and average round-trip time (RTT). The connectivity verification criteria are: packet loss rate not exceeding the threshold T_loss (T_loss defaults to 0%); average RTT not exceeding the threshold T_rtt (T_rtt defaults to 10ms).

[0137] Step F2: Perform bandwidth performance verification; The iperf network performance testing tool is executed on the target device using ADB. It performs bandwidth tests for TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) respectively. The test duration is T_iperf, which ranges from 10 to 60 seconds and has a default value of 30 seconds.

[0138] The bandwidth verification pass criteria are determined based on the bandwidth mode configured in the PHY: in 100Mbps mode, the TCP bandwidth is no less than 90Mbps and the UDP bandwidth is no less than 85Mbps; in gigabit mode, the TCP bandwidth is no less than 900Mbps and the UDP bandwidth is no less than 850Mbps.

[0139] The example above uses the iperf network performance testing tool for bandwidth performance verification. This iperf tool can also be replaced by the netperfiperf network performance testing tool. Furthermore, more verification items can be added to the bandwidth test, such as PHY register status readback verification and MII (Media Independent Interface) status monitoring.

[0140] Step F3: Combine the verification results of connectivity verification and bandwidth verification projects, and output the final verification report. The verification report includes: verification timestamp, raw data for each test project, pass or fail determination for each test project, and overall verification conclusion, which includes all pass, some pass, or all fail.

[0141] Step F4: If the verification result is all passed, output confirmation that the driver development is complete. If the verification result is partially passed or all failed, feed back detailed data of the failed verification items to the large language model for analysis, generate further debugging suggestions, and the developers confirm the debugging suggestions before starting a new iteration. That is, send a sixth prompt word to the generating agent. The sixth prompt word includes: debugging suggestions and driver result file, so that the generating agent can modify the driver result file according to the debugging suggestions to obtain the modified driver result file.

[0142] The embodiments of the present invention can perform iterative closed-loop management of the “code generation → compilation and construction → kernel deployment → log analysis → functional verification” process from steps 102 to 106, record the configuration changes, compilation results, burning status, log diagnosis and verification results of each iteration, and form a complete driver development traceability record.

[0143] Each iteration creates an iteration record containing the following fields: iteration number, trigger reason (initial generation, compilation error repair, log exception repair or verification failure repair), configuration change difference, compilation result, flashing result, log diagnosis result and verification result.

[0144] If the number of iterations exceeds the preset upper limit N_max (N_max ranges from 5 to 20, with a default of 10) and the verification still fails, a comprehensive diagnostic report containing all iteration records will be automatically generated and submitted to the developers for manual intervention.

[0145] Once the verification is successful, the final driver source code file, device tree configuration file, and verification report are packaged and archived to generate a reusable driver development deliverable package.

[0146] The verification report includes: Verification timestamp: The date and time this verification was performed; Raw data from each test: such as packet loss rate and average RTT in ping test, and measured TCP / UDP bandwidth in iperf test, etc. The pass / fail criteria for each test: whether the connectivity verification and bandwidth verification pass; Overall verification conclusion: taken from {all passed, some passed, all failed}.

[0147] It is understood that the vehicle driver development method of this invention, in addition to being applied to PHY chips, can also be applied to the following vehicle hardware scenarios: Scenario for driver development of vehicle-mounted CAN (Controller Area Network) / LIN (Local Interconnect Network) bus: This scenario adopts the "template + AI fill" code generation mechanism of this embodiment of the invention. The template is replaced with a CAN (Controller Area Network) / LIN (Local Interconnect Network) driver framework template, the AI ​​parsing object is replaced with the hardware datasheet of the CAN transceiver or LIN transceiver, and the verification steps are replaced with CAN message transmission and reception test or LIN frame communication test.

[0148] Development scenarios for automotive sensor drivers: The technical solution of this invention can be applied to the development of automotive sensor drivers such as camera ISP (Image Signal Processor) drivers, LiDAR interface drivers, and millimeter-wave radar drivers. The hardware datasheets analyzed by AI are replaced with sensor chip datasheets, and the verification steps are replaced with verification of the correctness of sensor data acquisition.

[0149] Cross-platform embedded driver porting scenario: The target platform of this invention is extended to build a multi-target platform template library that includes QNX (QNX Neutrino Real-time Operating System), Linux (Linux Operating System), and Android (Android Operating System). When the same PHY chip driver is ported from one target platform to another, AI combines the verified driver code of the original platform with the target platform template to generate porting code, reducing the workload of cross-platform porting.

[0150] Reference Figure 2 The diagram illustrates a step-by-step flowchart of a vehicle-mounted drive development method according to an embodiment of the present invention. The method specifically includes the following steps: Step 201: Receive the PHY configuration parameters and PHY chip datasheet input by the user, verify the validity of the PHY configuration parameters, and generate the driver configuration data structure corresponding to the PHY configuration parameters.

[0151] The users here can be developers.

[0152] Step 202: Extract chip parameters from the PHY chip datasheet using a large language model; select a target device tree template and a target driver code template that match the target platform and driver framework from the template library; use a generative agent to fill in the chip parameters and placeholders in the target device tree template and target driver code template to generate a driver result file; perform static syntax checking on the driver result file, and if there are syntax errors, the generative agent will correct the driver result file of the current round to obtain the driver result file of the next round.

[0153] The maximum number of correction iterations is N_retry. The driver result file includes: the driver source code file and the device tree configuration file; Step 203: Integrate the generated driver result file into the target platform kernel source code tree, update the kernel compilation rule file and kernel configuration option file, and call the cross-compilation toolchain corresponding to the target platform to execute kernel compilation; if the compilation is successful, output the kernel result file; if the compilation fails, submit the compilation error log to the large language model for analysis and generate the first modification suggestion. After the user confirms the first modification suggestion, the generating agent automatically modifies the driver result file of the current round according to the first modification suggestion to obtain the driver result file of the next round, and recompiles the driver result file of the next round, performing a maximum of N_build compilation iterations.

[0154] The kernel result files include: kernel image files and device tree binary files.

[0155] Step 204: Burn the successfully compiled kernel file to the boot partition of the target device, execute the target device reboot, and after reboot, use the UART serial port connection to collect the boot log of the target device.

[0156] Step 205: Extract the target log fragment related to the PHY driver from the startup log and submit it to the diagnostic agent; the diagnostic agent performs fault diagnosis by combining the PHY chip datasheet, fault knowledge base and hardware configuration parameters, and outputs the diagnostic results; if the diagnostic results are abnormal, the diagnostic agent outputs root cause analysis and second modification suggestions. After the user confirms the second modification suggestions, the generation agent automatically modifies the driver result file of the current round according to the second modification suggestions to obtain the driver result file of the next round, and re-triggers step 203; if the diagnostic results are normal, proceed to the next step.

[0157] Step 206: Perform functional verification on the target device whose diagnostic result is normal, including ping connectivity test and iperf bandwidth performance test. Compare the measured data with the preset judgment criteria and output a verification report. If the verification conclusion is that all tests are passed, output a driver development completion confirmation message. If the verification conclusion is that some tests are passed or all tests are failed, feed the verification failure data back to the large language model for analysis and generate debugging suggestions. After the user confirms the debugging suggestions, the generated intelligent agent automatically modifies the driver result file of the current round according to the debugging suggestions to obtain the driver result file of the next round and re-trigger step 203.

[0158] Step 207: Perform iterative closed-loop management of the entire process from Step 202 to Step 206, recording configuration changes, compilation results, flashing status, log diagnostics, and verification results for each iteration; when the number of iterations in any of Steps 202, 203, 205, and 206 exceeds their respective preset upper limit N_max, generate a comprehensive diagnostic report and submit it for manual intervention; after verification, package and archive the final driver code, device tree configuration, and verification report to generate a reusable driver development result package.

[0159] The preset upper limit N_max can be determined by those skilled in the art based on actual application requirements.

[0160] Reference Figure 3 The diagram illustrates a flowchart of a method for generating vehicle-mounted driving code according to an embodiment of the present invention. The method specifically includes the following steps: Step 301: Receive the driver configuration data structure and the PHY chip datasheet input by the developer; the driver configuration data structure is generated based on the verified PHY configuration parameters and includes hardware identification parameters, hardware connection parameters and hardware operating parameters. Step 302: Use the generated intelligent agent to analyze the PHY chip datasheet and extract the chip parameters; The chip parameters include at least: the manufacturer identifier (OUI) and model identifier of the PHY chip, the supported rate / duplex mode combinations, the definitions of key registers related to initialization in the register mapping table, clock configuration requirements, and reset timing requirements.

[0161] Step 303: Select the target device tree template and target driver code template that match the target platform and driver framework from the pre-built driver code template library; The target device tree template can be in .dts / .dtsi format, containing Ethernet controller node definitions, MDIO child node definitions, and PHY node attribute declarations with placeholders. The target driver code template can be in .c / .h format, containing PHY driver framework code with placeholders.

[0162] Step 304: Using the generated intelligent agent, according to the chip parameters and the driver configuration data structure, fill the placeholders in the target device tree template and the target driver code template to obtain the device tree configuration file and the driver source code file; Taking the driver configuration parameters shown in Table 1 as an example, the driver configuration parameter ethernet_port can be mapped to the corresponding Ethernet controller node; the driver configuration parameter phy_address can be filled into the reg attribute of the MDIO child node PHY node; the driver configuration parameter phy_reset_gpio can be filled into the reset-gpios attribute of the PHY node; the driver configuration parameter phy_speed_mode can be mapped to the max-speed attribute value of the PHY node; the clocks and clock-names attributes can be configured according to the clock configuration requirements; the OUI and model identifier corresponding to phy_chip_model can be filled into the fields of phy_driver.phy_id and phy_id_mask in the driver matching table; the phy_init_regs list can be converted into the sequential register write code in the PHY initialization function; the delay parameters in the hardware reset function can be generated according to the reset timing requirements; and the initialization code of the auto-negotiation enable or forced rate register can be configured according to phy_speed_mode.

[0163] Step 305: Perform syntax checking on the generated device tree configuration file and perform cross-compilation toolchain preprocessing and syntax checking on the generated driver source code file; if the syntax check passes, output the driver result file, which includes the device tree configuration file and the driver source code file; if the syntax check fails, feed back the error information to the generating agent for correction, and perform a maximum of N_retry correction iterations.

[0164] Steps 301 to 305 above describe the driver code generation process: First, the generating agent receives the driver configuration data structure and the PHY chip datasheet, and extracts the chip parameters from the PHY chip datasheet; then, it selects the target device tree template and the target driver code template that match the target platform and driver framework from the template library; next, the generating agent maps and fills the placeholders in the template according to the extracted chip parameters and driver configuration data structure, generating the device tree configuration file and the driver source code file; finally, it performs syntax checks on the generated device tree configuration file and the driver source code file respectively. If the check passes, the driver result file is output; if the check fails, it is fed back to the generating agent for correction, and a maximum of N_retry correction iterations are performed.

[0165] Reference Figure 4 The diagram illustrates a flowchart of a diagnostic method for vehicle-mounted drives according to an embodiment of the present invention. The method specifically includes the following steps: Step 401: Receive UART startup log data stream; the UART startup log data stream is the startup log collected after the target device restarts.

[0166] Step 402: From the UART startup log data stream, perform matching and extraction based on a preset keyword set to obtain target log segments related to the PHY driver; the keyword set includes keywords related to Ethernet PHY driver initialization and link status such as ethernet, phy, mdio, link, and speed.

[0167] Step 403: Input the target log fragment, PHY chip datasheet, information from the fault knowledge base, driver configuration data structure, and driver result file into the diagnostic agent. The diagnostic agent then performs fault diagnosis to obtain the corresponding diagnostic results.

[0168] Step 404: Obtain the diagnostic results output by the diagnostic agent; if the diagnostic results are normal, continue to perform functional verification; if the diagnostic results are abnormal, output the diagnostic results, which include: a list of error entries (including error type, error description and log line number), root cause analysis (such as register configuration error, improper timing parameters, abnormal GPIO configuration, etc.) and a second modification suggestion (including the file to be modified, the location to be modified and the content to be modified).

[0169] Step 405: The diagnostic results are presented to the developers. After the developers review and confirm the second modification suggestion, they use the generated intelligent agent to automatically modify the driving result file of the current round according to the second modification suggestion.

[0170] Step 406: After automatically modifying the driver result file of the current round, re-trigger the automated compilation and building of the driver result file, automated firmware burning, and log diagnosis of the next round, and enter the next round of debugging iteration.

[0171] Figure 4 The method shown illustrates the detailed process of log diagnosis and the iterative closed loop when diagnosing anomalies. First, PHY driver-related segments are extracted from the UART startup log through keyword matching. These segments are then submitted to a diagnostic agent for semantic analysis, incorporating the datasheet, fault knowledge base, and configuration parameters. If the diagnosis is normal, functional verification is performed; if an anomaly is detected, an error list, root cause analysis, and a second modification suggestion are output. After review and confirmation by the development team, the generated agent automatically applies the modifications, re-triggering the compilation-burning-log analysis iterative loop.

[0172] In summary, the vehicle drive development method of this invention has the following advantages: First, this invention reduces the development cycle of automotive drivers such as PHY drivers from days to hours. This is because it employs an automatic code generation mechanism combining hardware datasheet parsing and template filling. Developers only need to input hardware configuration parameters and the PHY chip datasheet to automatically generate compilable device tree configuration files and driver code files, eliminating the need for manually consulting datasheets (typically 0.5-1 day) and manually writing adaptation code (typically 0.5-1 day). Actual testing shows that using this invention reduces the average driver development time for a single PHY chip from 2 working days to 2-4 hours, improving efficiency by approximately 75%-85%.

[0173] Secondly, the embodiments of the present invention significantly reduce the error rate of driver configuration. Because the present invention adopts a layered architecture of "template providing framework + generating intelligent agents to fill parameters," the template layer constrains the code structure to conform to the QNX kernel driver framework specification (eliminating framework errors), and the generated intelligent agents extract accurate chip parameters by parsing the chip datasheet (eliminating manual errors in copying register values). Combined with the automatic error correction mechanism of static syntax checking, the first-time compilation pass rate is increased from approximately 40%-60% in manual development to approximately 80%-90%.

[0174] Furthermore, the embodiments of this invention lower the professional experience threshold for PHY driver development. Because the embodiments of this invention introduce an AI-assisted automatic diagnostic function for UART boot logs, the diagnostic agent can automatically analyze abnormal information in the UART boot logs and provide modification suggestions by combining the PHY chip datasheet and fault knowledge base. This allows junior developers to complete PHY driver debugging work that previously required senior driver engineers.

[0175] Furthermore, this embodiment of the invention achieves objective quantitative evaluation of driver verification. Because this embodiment establishes a quantitative verification standard system based on packet loss rate, RTT, and bandwidth, and automatically compares data obtained through ping and iperf tests, it eliminates subjective judgment biases in manual verification, ensuring the comparability and consistency of verification results from different developers and different PHY chip models.

[0176] Furthermore, this embodiment of the invention achieves a fully automated closed-loop process of compilation, flashing, diagnosis, and verification. Because this embodiment of the invention connects the five stages of code generation, compilation, flashing, log analysis, and verification into an automated pipeline through an iterative closed-loop management module, AI-assisted repair is automatically triggered and subsequent stages are re-executed when any stage fails. Developers do not need to manually switch between multiple toolchains, reducing the average time per round of debugging iterations from approximately 30-60 minutes of manual operation to approximately 5-10 minutes.

[0177] The development method of vehicle-mounted drive according to an embodiment of the present invention will be described below through specific application scenario examples.

[0178] Example 1: NXP TJA1103 100Mbps 100BASE-T1 Automotive Ethernet PHY Driver Development The system configuration is as follows: The target platform is the Horizon J6B in-vehicle computing platform, the operating system is QNX 8.0, the PHY chip is the NXP TJA1103 100BASE-T1 in-vehicle Ethernet PHY, the Ethernet port is ethernet0, the MAC controller is the Synopsys DWC EQoS GMAC (base address 0x25012000), the large language model corresponding to the generated intelligent agent is ClaudeOpus 4.6 (integrated and called via Cursor IDE), the host of the development device is Windows 10 + Cursor IDE (Integrated Development Environment), the connection method is ADB / Fastboot (firmware burning) plus UART serial port (log collection, baud rate 921600bps), and the cross-compilation toolchain is the QNX SDP 8.0 toolchain. Cursor IDE is an integrated development environment tool for AI-assisted programming.

[0179] The input hardware configuration parameters are as follows: ethernet_port is ethernet0, phy_chip_model is TJA1103, phy_datasheet is NXP TJA1103 Automotive Ethernet PHY Datasheet, phy_init_regs is Clause 45 vendor MMD30 register sequence, phy_speed_mode is 100Mbps (100BASE-T1), phy_reset_gpio is GPIO_479 (hardware reset is not currently enabled, it is implemented through software reset), and phy_address is 1.

[0180] The development process for vehicle-mounted drivers is as follows: Step S1: Parameter acquisition; It receives 7 parameters, verifies phy_address=1 (range 0-31, valid), identifies TJA1103 as Clause 45PHY (requires access using MMD extended register), and generates driver configuration data structure.

[0181] Step S2: Code generation; The intelligent agent is generated by parsing the TJA1103 datasheet, extracting OUI=0x006037 and Model ID=0x001BB013, identifying the Clause 45 register architecture (Vendor MMD30), and populating the device tree configuration file (phy-mode="rgmii", reg= <1> MDIO child nodes snps, dwmac-mdio, generate PHY driver code file (tja1103phy.c, including RGMII mode configuration 0xAFC6=0x7, VEND1_DEVICE_CONTROL soft reset, CONFIG_GLOBAL_EN / CONFIG_ALL_EN enable sequence), set TX clock frequency to 25MHz, and pass syntax check on the first generation.

[0182] Step S3: Compile and build; Integrate tja1103phy.c into the dwceqos driver source code tree, update common.mk to add compilation targets, execute QNX 8.0 cross-compilation, the first compilation is successful, and boot.img is generated.

[0183] Step S4: Firmware flashing; Switch to Fastboot mode via ADB, execute fastboot flash boot_a boot.img, the device restarts, collects UART logs, and the flashing is successful.

[0184] Step S5: Log Diagnosis; The diagnostic agent analysis log detected "NXP TJA1103 100 PHY: attached" and "Link is Up- 100Mbps / Full". The RGMII-ID capability bit check passed, and the diagnostic status is normal.

[0185] Step S6: Functional verification.

[0186] Ping 20 packet loss rate was 0%, average RTT was 0.8ms; iperf TCP was 94.5Mbps, UDP was 91.2Mbps, all passed.

[0187] Development results: The driver development was completed in one iteration, with a total time of approximately 2 hours (including parameter input, AI processing Clause45 register architecture analysis, compilation, programming and verification).

[0188] Example 2: NXP TJA1103 ethernet1 port driver development (including debugging and iteration) The system configuration is as follows: The target platform is the Horizon J6B in-vehicle computing platform, the operating system is QNX 8.0, the PHY chip is the NXP TJA1103 100BASE-T1 in-vehicle Ethernet PHY, the Ethernet port is ethernet1 (MAC base address 0x25014000), the MAC controller is the Synopsys DWC EQoS GMAC, the large language model corresponding to the generated intelligent agent is Claude Opus 4.6 (integrated and called via Cursor IDE), the host of the development device is Windows 10 + CursorIDE, the connection method is ADB / Fastboot (firmware burning) plus UART serial port (log collection, baud rate 921600bps), and the cross-compilation toolchain is the QNX SDP 8.0 corresponding toolchain. Cursor IDE is an integrated development environment tool for AI-assisted programming.

[0189] The input hardware configuration parameters are as follows: ethernet_port is ethernet1, phy_chip_model is TJA1103, phy_datasheet is NXP TJA1103 Automotive Ethernet PHY Datasheet, phy_init_regs is Clause 45 vendor MMD30 register sequence, phy_speed_mode is 100Mbps (100BASE-T1), phy_reset_gpio is GPIO_488 (hardware reset is not currently enabled, it is implemented through software reset), and phy_address is 2.

[0190] The development process for vehicle-mounted drivers is as follows: Round 1 iteration: Step S2: Code generation; Generate the intelligent agent's device tree configuration file and driver code file, reuse the tja1103phy.c driver framework, and the generation is complete.

[0191] Step S3: Compile and build; execute QNX 8.0 cross-compilation, compilation successful.

[0192] Step S4: Firmware flashing; Switch to Fastboot mode via ADB, execute fastboot flash boot_aboot.img, the device restarts, collects UART logs, and the flashing is successful.

[0193] Step S5, Log Diagnosis; The diagnostic agent analyzed the logs and detected the error "TJA1103: VEND1_ABILITIESRGMII-ID not supported", and the diagnostic status was abnormal; the root cause analysis showed that the TX clock setting index in the dwceqos_set_tx_clk function was hardcoded to 0, and the ethernet1 port should use index 1; the first modification suggestion is to change the dwceqos_set_tx_clk call parameter in tja1103_attach from (0, 25000000) to dynamically obtain the index based on the current Ethernet port alias.

[0194] Second iteration: Steps S2 to S4: The developers confirm the first modification suggestion, generate an agent to modify the TX clock index logic according to the first modification suggestion, recompile, and successfully burn the code.

[0195] Step S5, Log Diagnosis; The diagnostic agent analyzed the logs and detected "NXP TJA1103 100 PHY:attached" and "Link is Up - 100Mbps / Full", indicating a normal diagnostic status.

[0196] Step S6, Functional Verification: Ping 20 packet loss rate is 0%, RTT is 0.9ms; iperf TCP is 93.8Mbps, UDP is 90.6Mbps, all passed.

[0197] Development Results: The driver development was completed after two rounds of iterations, taking approximately 2.5 hours in total. The generated agent successfully discovered the hard-coded issue with the TX clock index and provided correct repair suggestions.

[0198] Example 3: NXP TJA1103 Driver Development (including fixing compilation errors in Clause 45 register configuration) The system configuration is as follows: The target platform is the Horizon J6B in-vehicle computing platform, the operating system is QNX 8.0, the PHY chip is the NXP TJA1103 100BASE-T1 in-vehicle Ethernet PHY, the Ethernet port is ethernet0, the MAC controller is the Synopsys DWC EQoS GMAC (base address 0x25012000), the large language model corresponding to the generated intelligent agent is ClaudeOpus 4.6 (integrated and called via Cursor IDE), the host of the development device is Windows 10 + Cursor IDE, the connection method is ADB / Fastboot (firmware burning) plus UART serial port (log collection, baud rate 921600bps), and the cross-compilation toolchain is the QNX SDP 8.0 toolchain. Cursor IDE is an integrated development environment tool for AI-assisted programming.

[0199] The input hardware configuration parameters are as follows: ethernet_port is ethernet0, phy_chip_model is TJA1103, phy_datasheet is NXP TJA1103 Automotive Ethernet PHY Datasheet, phy_init_regs is Clause 45 vendor MMD30 register sequence, phy_speed_mode is 100Mbps (100BASE-T1), phy_reset_gpio is GPIO_479 (hardware reset is not currently enabled, it is implemented through software reset), and phy_address is 1.

[0200] The development process for vehicle-mounted drivers is as follows: Round 1 iteration: Step S2: Code generation; The intelligent agent driver code file has been generated, including Clause 45 Vendor MMD30 register operations (PHY_READEXT / PHY_WRITEEXT macro calls). Generation is complete, and the syntax check has passed.

[0201] Step S3: Compile and build; When performing QNX 8.0 cross-compilation, compilation failed with the error "undefined reference to 'MIIBUS_READEXTREG'". Error analysis revealed that the extended register read / write interface in Clause 45 of the QNX platform uses the PHY_READEXT / PHY_WRITEEXT macros (defined in the QNXNTO conditional compilation branch in miivar.h) instead of directly calling the MIIBUS function. The suggested modification is to replace the MIIBUS call with the macros PHY_READEXT(phydev, MDIO_MMD_VEND1, reg_addr) and PHY_WRITEEXT(phydev, MDIO_MMD_VEND1, reg_addr, val).

[0202] Step S3 (Repair): The developers confirm the modification suggestions, generate the agent, modify the driver code file according to the modification suggestions, recompile, and the compilation is successful.

[0203] Step S4: Firmware flashing; Switch to Fastboot mode via ADB, execute fastboot flash boot_aboot.img, the device restarts, collects UART logs, and the flashing is successful.

[0204] Step S5: Log Diagnosis; The diagnostic agent analyzes the logs and detects "NXP TJA1103 100 PHY:attached" and successful RGMII mode configuration, indicating a normal diagnostic status.

[0205] Step S6, Functional Verification: Ping 20 packet loss rate is 0%, RTT is 0.7ms; iperf TCP is 94.8Mbps, UDP is 91.8Mbps, all passed.

[0206] Development Results: Driver development was completed after one iteration (including one compilation and fix), taking approximately 2 hours in total. The generated agent successfully identified the unique Clause 45 register access interface differences specific to the QNX platform.

[0207] The technical solution of this invention has been tested and verified on the actual Horizon J6B vehicle-mounted computing platform.

[0208] The verification environment is as follows: The hardware platform is the Horizon J6B development board (equipped with 2 Ethernet interfaces, and the MAC controller is Synopsys DWC EQoS GMAC), the operating system is QNX 8.0, the test PHY chip is NXP TJA1103 (100BASE-T1 automotive Ethernet PHY), and the two ports ethernet0 (MDIO address 1) and ethernet1 (MDIO address 2) are tested respectively. The driver framework is device tree (hobot-j6b-soc.dtsi) plus MDIO (snps, dwmac-mdio) plus Clause 45 MMD extended registers. The AI ​​model is Claude Opus 4.6 (integrated and called through Cursor IDE). The benchmark is historical data of the same PHY driver manually developed by senior driver engineers.

[0209] The verification results are compared as follows: Regarding the average development cycle, manual development takes 2 working days (approximately 16 hours), while the embodiment of this invention takes 2 to 4 hours, representing an improvement of 75% to 87.5%; Regarding the first-time compilation pass rate, manual development has a pass rate of approximately 50%, while the embodiment of this invention has a pass rate of approximately 85%, an improvement of approximately 35 percentage points; Regarding the average number of debugging iterations, manual development requires 5 to 8 rounds, while the embodiment of this invention requires 1 to 3 rounds, a reduction of 60% to 80%; Regarding the average time per iteration, manual development takes 30 to 60 minutes, while the embodiment of this invention takes 5 to 10 minutes, a reduction of 75% to 85%; Regarding the final verification pass rate, manual development achieves 100%, and the embodiment of this invention also achieves 100% (all 3 examples passed), remaining the same; Regarding whether junior engineers can complete the task independently, manual development is not possible (requiring guidance from senior engineers), while the embodiment of this invention is possible (AI provides diagnostic guidance), significantly lowering the barrier to entry.

[0210] The above results demonstrate that the embodiments of the present invention improve the usability of driver development, shorten the development cycle by more than 75%, increase the first-time compilation pass rate by approximately 35 percentage points, reduce the number of debugging iterations by more than 60%, and enable junior developers to independently complete PHY driver development work that previously required senior engineers, with the help of AI diagnostics. Especially in automotive Ethernet PHY scenarios such as the TJA1103 which uses a Clause 45 MMD extended register architecture, AI can correctly parse the Vendor MMD30 register mapping and RGMII mode configuration, and identify the register access interfaces (PHY_READEXT / PHY_WRITEEXT macros) unique to the QNX platform, significantly reducing the development difficulty of such complex PHY drivers.

[0211] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the present invention.

[0212] Based on the description of the above method embodiments, the present invention also provides corresponding vehicle-mounted drive development device embodiments to implement the content described in the above method embodiments.

[0213] Reference Figure 5 The diagram illustrates the structure of a vehicle-mounted drive development device according to an embodiment of the present invention. The device specifically includes the following modules: The parameter acquisition module 501 is used to receive the drive configuration parameters corresponding to the vehicle hardware; the drive configuration parameters include: hardware datasheet and hardware configuration parameters. The code generation module 502 is used to send a first prompt word to the generation agent; the first prompt word includes: driver configuration parameters and generation rules; the generation rules are used to control the generation agent to generate a driver result file corresponding to the driver configuration parameters; the driver result file includes: driver source code file and device tree configuration file; The compilation and build module 503 is used to perform kernel compilation on the driver result file to obtain the kernel result file; The programming module 504 is used to program the kernel result file to the boot partition of the target device, perform a reboot of the target device, and collect the boot log of the target device after the target device reboots. The log collection and diagnosis module 505 is used to extract target log segments related to the driver result file from the startup log, and to perform fault diagnosis on the target log segments to obtain diagnosis results; The verification module 506 is used to perform functional verification on the target device whose diagnostic result is normal, and obtain the corresponding verification result.

[0214] Optionally, the first prompt further includes: a target device tree template and a target driver code template matching the target platform and driver framework; then the generation rule is specifically used to control the generation agent to fill in the target device tree template and the target driver code template according to the driver configuration parameters to obtain a driver result file; or The first prompt word also includes information on hardware features and code knowledge base; then the generation rule is also used to control the generation agent to obtain target driver code that matches the hardware features from the code knowledge base, and generate a driver result file corresponding to the driver configuration parameters based on the target driver code.

[0215] Optionally, the compilation build module includes: The first copy module is used to copy the device tree configuration file to the corresponding device tree directory of the kernel source code tree; The second copying module is used to copy the driver source code file to the corresponding subdirectory of the kernel driver directory; The configuration update module is used to add the compilation rules of the driver source code file in the driver result file to the kernel compilation rule file, and to add the configuration options of the driver source code file in the driver result file to the kernel configuration option file. The kernel compilation module is used to call the cross-compilation toolchain corresponding to the target platform, perform kernel compilation, and obtain the corresponding compilation results. The compilation results include: the kernel result file when the compilation is successful, or the compilation error log when the compilation fails.

[0216] Optionally, if the compilation result includes a compilation error log in case of compilation errors, then the apparatus further includes: A log analysis module is used to send a second prompt word to an error analysis agent; the second prompt word includes: a compilation error log and analysis rules; the analysis rules are used to control the error analysis agent to generate a first modification suggestion based on the error type of the compilation error log; the first modification suggestion is used to modify the error type of the driver result file; The first modification module is used to send a third prompt word to the generating agent; the third prompt word includes: a driving result file and a first modification suggestion; the generating agent modifies the driving result file according to the first modification suggestion to obtain a modified driving result file; The iterative compilation module is used to perform kernel compilation on the modified driver result file.

[0217] Optionally, the fault diagnosis of the target log segment includes: Send a fourth prompt word to the diagnostic agent; the fourth prompt word includes: driver configuration parameters, target log segment, fault knowledge base information, and diagnostic rules; the diagnostic rules are used to control the diagnostic agent to perform fault diagnosis on the target log segment based on the driver configuration parameters and the fault knowledge base, and obtain a diagnostic result; or The log features in the target log segment are matched with error patterns in the fault knowledge base to obtain successfully matched candidate fault causes and candidate solutions. Based on the candidate fault causes and candidate solutions, the diagnostic result is determined; or The target log segment is classified using a fault classification model to obtain the fault type corresponding to the target log segment, and the diagnosis result is determined based on the fault cause and troubleshooting direction corresponding to the fault type.

[0218] Optionally, the hardware datasheet includes: error descriptions and debugging guidelines; the fault knowledge base stores the mapping relationship between error patterns, fault causes, and solutions; The diagnostic rules are used to control the diagnostic agent to perform the following operations: The log features in the target log fragment are matched with error patterns in the fault knowledge base to obtain successfully matched candidate fault causes and candidate solutions; Based on the error descriptions and debugging guidelines in the hardware datasheet, the candidate fault causes and candidate solutions are screened to obtain the screened target fault causes and target solutions; Based on the target fault cause and target solution, a diagnostic result is generated; the diagnostic result includes: diagnostic status; if no abnormality is diagnosed in the diagnostic status, the diagnostic result also includes: error type, error cause, and second modification suggestion.

[0219] Optionally, the functional verification of the target device whose diagnostic result is normal includes: Identify at least one test item for the vehicle-mounted hardware, and the verification criteria for each test item; Execute each test item on the target device to obtain the execution data for each test item; Based on the execution data of each test project and the corresponding verification criteria for each test project, determine the project verification result for each test project. Based on the project verification results of all test items, generate verification results.

[0220] Optionally, generating verification results based on the verification results of all test items includes: If all test projects achieve successful verification results, the verification result will be: a driver development completion confirmation message; or If the verification result of only one test item is successful, the verification result includes: verification failure data.

[0221] Optionally, the vehicle-mounted hardware includes a PHY chip; the test items corresponding to the PHY chip include network connectivity test items and network bandwidth test items. The verification criteria for the network connectivity test items include: the packet loss rate of the test does not exceed the preset packet loss rate threshold, and the average round-trip time does not exceed the preset time delay threshold. The verification criteria for the network bandwidth test items include: the tested TCP bandwidth and UDP bandwidth are not lower than the preset lower limit threshold corresponding to the PHY bandwidth mode.

[0222] Optionally, the device further includes: The second modification module is used to send a fifth prompt word to the generating agent; the fifth prompt word includes: the driving result file and the verification failure data, so that the generating agent can modify the driving result file according to the verification failure data to obtain the modified driving result file.

[0223] Reference Figure 6 The diagram illustrates a structural schematic of an in-vehicle drive development system according to an embodiment of the present invention, which is located between the developer interaction layer and the target embedded device layer.

[0224] The developer interaction layer is implemented through Cursor IDE, which is used to input hardware configuration parameters and PHY datasheets, and output verification reports, diagnostic suggestions and deliverable packages.

[0225] The system includes the following modules: The acquisition and verification module 601 has a built-in parameter verification rule engine, which is used to receive and verify the driver configuration parameters input by the developers and generate driver configuration data structures.

[0226] The code generation module 602 is connected to the generation agent and has a built-in driver code template library and datasheet parsing engine. The driver code template library contains device tree templates and driver code templates, and the datasheet parsing engine is used to call the generation agent to extract chip parameters. This module fills the template placeholders according to the driver configuration parameters and key chip parameters to generate the driver result file.

[0227] The compilation build module 603 has a built-in cross-compilation toolchain, which is used to integrate the driver result files into the target platform kernel source code tree and perform cross-compilation to generate kernel result files.

[0228] The programming module 604 connects to the target device via the ADB / Fastboot protocol and is used to program the kernel result file to the boot partition of the target device.

[0229] The log acquisition and diagnosis module 605 connects to the target device via a UART serial port and has a built-in PHY fault knowledge base. It is used to collect the startup logs of the target device and perform fault diagnosis on the target log segments.

[0230] The verification module 606 connects to the target device via ADB and has a built-in quantitative verification standard library 606a. The quantitative verification standard library 606a includes packet loss rate threshold, RTT threshold and bandwidth threshold, which are used to verify the driver function of the target device whose diagnostic results are normal.

[0231] The iterative closed-loop management module 607 has a built-in iterative record database, which is used to collect process data from each module and record configuration changes, compilation results, burning status, log diagnosis and verification results for each iteration. This module manages the feedback loop from the automated verification module 606 through the log collection and diagnosis module 605, the compilation and building module 603 to the code generation module 602.

[0232] The target embedded device layer includes the Horizon J6B automotive computing platform, which runs a QNX kernel, integrates an Ethernet MAC controller, and a PHY chip connected via the MDIO bus.

[0233] This invention discloses an electronic device, including a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the aforementioned method.

[0234] This invention discloses a non-transitory computer-readable storage medium storing instructions that cause a processor to execute the aforementioned method.

[0235] Non-transitory memory: This refers to components or devices in computer hardware used for non-temporary storage of data and instructions. It emphasizes the "non-transitory" nature of the storage, meaning the data will not be lost due to momentary factors such as the disappearance of electrical signals. Examples include ROM (Read-Only Memory) and the storage chips in solid-state drives (SSDs), which can store data long-term.

[0236] Non-transitory computer-readable recording media: Physical carriers that can permanently store computer data and are readable. Data storage is stable and not temporary. Examples include hard drives, USB flash drives, and optical discs. They can store various types of data such as programs, documents, and videos. Even if the device is powered off or restarted, the data is still retained and can be accessed by the computer later.

[0237] Non-transitory computer-readable storage media: These are part of the computer storage system and are media that can permanently store computer-readable data. They include hard drives, solid-state drives, and flash memory. Unlike transient storage, they can permanently or long-term retain data. Computers can read the stored instructions and data through corresponding interfaces and protocols for use in program execution, data processing, and other scenarios. For example, they store operating systems, application code, and user files, providing stable data support for the computer system.

[0238] The device used for developing vehicle-mounted drives can be an electronic device. Figure 7 A schematic diagram of an electronic device 1100 according to an embodiment of the present invention is shown. The electronic device 1100 specifically includes: one or more processors 1102, a control module (chipset) 1104 coupled to at least one of the processors 1102, a memory 1106 coupled to the control module 1104, a non-volatile memory / storage device 1108 coupled to the control module 1104, one or more input / output devices 1110 coupled to the control module 1104, and a network interface 1112 coupled to the control module 1104.

[0239] Processor 1102 may include one or more single-core or multi-core processors, and processor 1102 may include any combination of general-purpose processors or special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, electronic device 1100 can serve as a terminal device, server (cluster), or other device as described in the embodiments of the present invention.

[0240] In some embodiments, electronic device 1100 may include one or more computer-readable media (e.g., memory 1106 or non-volatile memory / storage device 1108) having instructions 1114 and one or more processors 1102 that are combined with the one or more computer-readable media and configured to execute instructions 1114 to implement modules and thereby perform the actions described in this disclosure.

[0241] In one embodiment, the control module 1104 may include any suitable interface controller to provide any suitable interface to at least one of the processors 1102 and / or any suitable device or component communicating with the control module 1104.

[0242] The control module 1104 may include a memory controller module to provide an interface to the memory 1106. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0243] Memory 1106 may be used, for example, to load and store data and / or instructions 1114 for electronic device 1100. In one embodiment, memory 1106 may include any suitable volatile memory, such as suitable DRAM (Dynamic Random Access Memory). In some embodiments, memory 1106 may include double data rate type quad synchronous dynamic random access memory.

[0244] In one embodiment, the control module 1104 may include one or more input / output controllers to provide an interface to the non-volatile memory / storage device 1108 and (one or more) input / output devices 1110.

[0245] For example, non-volatile memory / storage device 1108 may be used to store data and / or instructions 1114. Non-volatile memory / storage device 1108 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable (one or more) non-volatile storage devices (e.g., one or more hard disk drives, one or more optical disk drives, and / or one or more digital universal optical disk drives).

[0246] The non-volatile memory / storage device 1108 may include storage resources that are physically part of a device on which the electronic device 1100 is mounted, or that can be accessed by the device without being part of the device. For example, the non-volatile memory / storage device 1108 may be accessed via a network via one or more input / output devices 1110.

[0247] One or more input / output devices 1110 may provide an interface for electronic device 1100 to communicate with any other suitable device. Input / output devices 1110 may include communication components, audio components, sensor components, etc. Network interface 1112 may provide an interface for electronic device 1100 to communicate via one or more networks. Electronic device 1100 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, such as accessing wireless networks based on communication standards, such as WiFi (Wireless Fidelity), 2G (2-Generation wireless telephone technology), 3G (3-Generation wireless telephone technology), 4G (4-Generation wireless telephone technology), 5G (5-Generation wireless telephone technology), etc., or combinations thereof.

[0248] In one embodiment, at least one of the processors 1102 may be logically packaged with one or more controllers (e.g., memory controller modules) of the control module 1104. In one embodiment, at least one of the processors 1102 may be logically packaged with one or more controllers of the control module 1104 to form a system-in-package. In one embodiment, at least one of the processors 1102 may be integrated with the logic of one or more controllers of the control module 1104 on the same die. In one embodiment, at least one of the processors 1102 may be integrated with the logic of one or more controllers of the control module 1104 on the same die to form a system-on-a-chip.

[0249] In various embodiments, electronic device 1100 may be, but is not limited to, a server, desktop computing device, or mobile computing device (e.g., laptop computing device, handheld computing device, touchscreen device, netbook, etc.). In various embodiments, electronic device 1100 may have more or fewer components and / or different architectures. For example, in some embodiments, electronic device 1100 includes one or more cameras, a keyboard, a liquid crystal display screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit (ASIC), and a speaker.

[0250] This invention provides a machine-readable medium storing instructions that, when executed by one or more processors, cause an electronic device to perform one or more of the methods described in the above embodiments.

[0251] Optionally, the machine-readable medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0252] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0253] It will be readily apparent to those skilled in the art that any combination of the above embodiments is feasible, and therefore any combination of the above embodiments constitutes an implementation of the present invention. However, due to space limitations, each embodiment will not be described in detail here. Although preferred embodiments of the present invention have been described, those skilled in the art, once they understand the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the present invention.

[0254] The above provides a detailed description of the development method, apparatus, device, and medium for vehicle-mounted drive provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A development method for vehicle-mounted drive systems, characterized in that, The method includes: Receive the driver configuration parameters corresponding to the vehicle hardware; the driver configuration parameters include: hardware datasheet and hardware configuration parameters; A first prompt word is sent to the generating agent; the first prompt word includes: driver configuration parameters and generation rules; the generation rules are used to control the generating agent to generate a driver result file corresponding to the driver configuration parameters; the driver result file includes: driver source code file and device tree configuration file; The driver result file is then compiled into a kernel result file. The kernel result file is burned to the boot partition of the target device, the target device is restarted, and the boot log of the target device is collected after the target device restarts. Extract the target log segment related to the driver result file from the startup log, and perform fault diagnosis on the target log segment to obtain the diagnosis result; Functional verification was performed on the target device whose diagnostic results were normal, and the corresponding verification results were obtained.

2. The method according to claim 1, characterized in that, The first prompt also includes: a target device tree template and a target driver code template that match the target platform and driver framework; then the generation rule is specifically used to control the generation agent to fill in the target device tree template and the target driver code template according to the driver configuration parameters to obtain a driver result file; or The first prompt word also includes information on hardware features and code knowledge base; then the generation rule is also used to control the generation agent to obtain target driver code that matches the hardware features from the code knowledge base, and generate a driver result file corresponding to the driver configuration parameters based on the target driver code.

3. The method according to claim 1, characterized in that, The kernel compilation of the driver result file includes: Copy the device tree configuration file to the corresponding device tree directory in the kernel source code tree; Copy the driver source code file to the corresponding subdirectory of the kernel driver directory; Add the compilation rules for the driver source code file in the driver result file to the kernel compilation rule file, and add the configuration options for the driver source code file in the driver result file to the kernel configuration option file; The cross-compilation toolchain corresponding to the target platform is invoked to perform kernel compilation and obtain the corresponding compilation results. The compilation results include: the kernel result file if the compilation is successful, or the compilation error log if the compilation fails.

4. The method according to claim 3, characterized in that, If the compilation result includes a compilation error log in case of compilation errors, then the method further includes: A second prompt word is sent to the error analysis agent; the second prompt word includes: compilation error log and analysis rules; the analysis rules are used to control the error analysis agent to generate a first modification suggestion based on the error type of the compilation error log; the first modification suggestion is used to modify the error type of the driver result file; A third prompt word is sent to the generating agent; the third prompt word includes: the driving result file and a first modification suggestion; the generating agent modifies the driving result file according to the first modification suggestion to obtain the modified driving result file; The modified driver result file is then compiled into a kernel.

5. The method according to claim 1, characterized in that, The fault diagnosis of the target log segment includes: Send a fourth prompt word to the diagnostic agent; the fourth prompt word includes: driver configuration parameters, target log segment, fault knowledge base information, and diagnostic rules; the diagnostic rules are used to control the diagnostic agent to perform fault diagnosis on the target log segment based on the driver configuration parameters and the fault knowledge base, and obtain a diagnostic result; or The log features in the target log segment are matched with error patterns in the fault knowledge base to obtain successfully matched candidate fault causes and candidate solutions. Based on the candidate fault causes and candidate solutions, the diagnostic result is determined; or The target log segment is classified using a fault classification model to obtain the fault type corresponding to the target log segment, and the diagnosis result is determined based on the fault cause and troubleshooting direction corresponding to the fault type.

6. The method according to claim 5, characterized in that, The hardware datasheet includes: error descriptions and debugging guidelines; the fault knowledge base stores the mapping relationship between error patterns, fault causes, and solutions. The diagnostic rules are used to control the diagnostic agent to perform the following operations: The log features in the target log fragment are matched with error patterns in the fault knowledge base to obtain successfully matched candidate fault causes and candidate solutions; Based on the error descriptions and debugging guidelines in the hardware datasheet, the candidate fault causes and candidate solutions are screened to obtain the screened target fault causes and target solutions; Based on the target fault cause and target solution, a diagnostic result is generated; the diagnostic result includes: diagnostic status; if no abnormality is diagnosed in the diagnostic status, the diagnostic result also includes: error type, error cause, and second modification suggestion.

7. The method according to claim 1, characterized in that, The functional verification of the target device whose diagnostic result is normal includes: Identify at least one test item for the vehicle-mounted hardware, and the verification criteria for each test item; Execute each test item on the target device to obtain the execution data for each test item; Based on the execution data of each test project and the corresponding verification criteria for each test project, determine the project verification result for each test project. Based on the project verification results of all test items, generate verification results.

8. The method according to claim 7, characterized in that, The step of generating verification results based on the verification results of all test items includes: If all test projects show successful verification results, the verification result is a confirmation message indicating that driver development is complete; or If the verification result for only one test item is successful, the verification result includes verification failure data.

9. The method according to claim 8, characterized in that, The vehicle-mounted hardware includes a PHY chip; the test items corresponding to the PHY chip include network connectivity test items and network bandwidth test items. The verification criteria for the network connectivity test items include: the packet loss rate of the test does not exceed the preset packet loss rate threshold, and the average round-trip time does not exceed the preset time delay threshold. The verification criteria for the network bandwidth test items include: the tested TCP bandwidth and UDP bandwidth are not lower than the preset lower limit threshold corresponding to the PHY bandwidth mode.

10. The method according to claim 8, characterized in that, The method further includes: A fifth prompt word is sent to the generating agent; the fifth prompt word includes: the driving result file and the verification failure data, so that the generating agent can modify the driving result file according to the verification failure data to obtain the modified driving result file.

11. A vehicle-mounted drive development device, characterized in that, The device includes: The parameter acquisition module is used to receive the driver configuration parameters corresponding to the vehicle hardware; the driver configuration parameters include: hardware datasheet and hardware configuration parameters. A code generation module is used to send a first prompt word to the generation agent; the first prompt word includes: driver configuration parameters and generation rules; the generation rules are used to control the generation agent to generate a driver result file corresponding to the driver configuration parameters; the driver result file includes: driver source code file and device tree configuration file; A compilation and build module is used to perform kernel compilation on the driver result file to obtain a kernel result file; The programming module is used to program the kernel result file to the boot partition of the target device, perform a reboot of the target device, and collect the boot logs of the target device after the reboot. The log collection and diagnosis module is used to extract target log segments related to the driver result file from the startup log, and to perform fault diagnosis on the target log segments to obtain diagnosis results; The verification module is used to perform functional verification on target devices whose diagnostic results are normal, and obtain the corresponding verification results.

12. An electronic device comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 10.

Images