Device tree-based user-mode driver cross-platform support method, device, and medium

Abstract

The present application provides a method, apparatus and medium for cross-platform support of user-mode drivers based on a device tree. The method includes: during system startup, loading the device tree file into memory and passing the memory address of the device tree to the user-mode driver module; parsing the device tree file in the user-mode driver module and building a device node list; during the system compilation phase, registering the initialization function and compatibility string of the driver module to the driver module segment to form a driver module list; matching the compatibility string of the device node with the compatibility string in the driver module list; registering the device instance to the device linked list; when an external module in user mode accesses a device, searching for the corresponding device instance in the device linked list, and calling the operation method in the device instance to perform operations on the device. The present application enables the driver to be flexibly adapted to different hardware platforms, reducing development costs and improving system security.

Description

Technical Field

[0001] The present application relates to the field of device driver technology, and in particular to a method, apparatus, and medium for cross-platform support of user-mode drivers based on a device tree. Background Art

[0002] In traditional operating system architectures, device drivers typically run in kernel space, interacting directly with the kernel and hardware devices. Because drivers are tightly bound to specific hardware platforms, the cost of developing and maintaining drivers for different hardware platforms is high. For example, adapting to different architectures like x86, ARM, and RISC-V often requires refactoring or modifying the underlying driver implementation, resulting in long development cycles and difficult maintenance.

[0003] To address the security and stability issues of kernel-space drivers, the microkernel operating system (Microkernel OS) architecture has gradually emerged. Microkernel OSes minimize kernel functionality and move most operational logic and device drivers to user space, improving system security and reliability. Because user-space drivers run in user space, they are isolated from kernel space. Even if a user-space driver crashes, it won't cause a kernel crash, thus enhancing system stability and recoverability.

[0004] However, with the introduction of user-space drivers, new technical problems also arise. User-space drivers need to be compatible with multiple hardware platforms, which brings the challenge of cross-platform support. Different hardware platforms (such as x86, ARM, and RISC-V) have differences in instruction set architecture, I / O control, and interrupt mechanisms. Traditional drivers are difficult to directly reuse on these platforms, and the development cost of cross-platform porting is high and the development cycle is long. In addition, the dynamic loading of user-space drivers and the efficiency of device management also face challenges. Because the relationship between user-space drivers and the kernel relies on message passing and interrupt mechanisms, how to efficiently achieve driver matching and initialization becomes a major problem in the process of dynamically loading the device tree, parsing device nodes, and initializing device drivers. Summary of the Invention

[0005] In view of this, the embodiments of the present application provide a device tree-based user-mode driver cross-platform support method, apparatus and medium to solve the problems in the prior art that drivers cannot be reused across platforms, have high development costs and low system security.

[0006] In a first aspect of an embodiment of the present application, a method for supporting user-mode drivers across platforms based on a device tree is provided, comprising: during system startup, loading a device tree file into memory, and passing the memory address of the device tree to a user-mode driver module; parsing the device tree file in the user-mode driver module, and constructing a device node list, wherein the device node list includes the device path, device status, and compatibility string of the device node; during the system compilation phase, registering the initialization function and compatibility string of the driver module to the driver module segment to form a driver module list; matching the compatibility string of the device node with the compatibility string in the driver module list, and if the match is successful, calling the initialization function of the corresponding driver module to initialize the driver of the device corresponding to the device node; classifying devices according to their functions, defining a device interface data structure and access method for each type of device, and registering the device instance to a device linked list; when an external module in user mode accesses a device, searching for the corresponding device instance in the device linked list, and calling the operation method in the device instance to perform an operation on the device.

[0007] According to a second aspect of an embodiment of the present application, a device tree-based user-mode driver cross-platform support device is provided, comprising: a loading module for loading a device tree file into memory during system startup, and passing the memory address of the device tree to the user-mode driver module; a parsing module for parsing the device tree file in the user-mode driver module and constructing a device node list, wherein the device node list includes the device path, device status, and compatibility string of the device node; a registration module for registering the initialization function and compatibility string of the driver module to the driver module segment during the system compilation phase to form a driver module list; a matching module for matching the compatibility string of the device node with the compatibility string in the driver module list, and if the match is successful, calling the initialization function of the corresponding driver module to initialize the driver of the device corresponding to the device node; a classification module for classifying devices according to their functions, defining a device interface data structure and access method for each type of device, and registering the device instance in the device linked list; a calling module for searching the corresponding device instance in the device linked list when an external module in user mode accesses the device, and calling the operation method in the device instance to perform an operation on the device.

[0008] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the computer program.

[0009] According to a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the steps of the above method are implemented.

[0010] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0011] During the system startup process, the device tree file is loaded into the memory, and the memory address of the device tree is passed to the user-state driver module; the device tree file is parsed in the user-state driver module, and a device node list is constructed, wherein the device node list includes the device path, device status and compatibility string of the device node; during the system compilation phase, the initialization function and compatibility string of the driver module are registered to the driver module segment to form a driver module list; the compatibility string of the device node is matched with the compatibility string in the driver module list, and if the match is successful, the initialization function of the corresponding driver module is called to initialize the driver of the device corresponding to the device node; the devices are classified according to their functions, the device interface data structure and access method are defined for each type of device, and the device instance is registered in the device linked list; when the external module in the user state accesses the device, the corresponding device instance is searched in the device linked list, and the operation method in the device instance is called to perform the operation on the device. This application enables the driver to be flexibly adapted to different hardware platforms, reduces development costs, and improves system security. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0013] Figure 1 This is a schematic diagram of the overall framework structure of the user-mode driver of the microkernel operating system provided in an embodiment of the present application;

[0014] Figure 2 This is a flowchart of a device tree-based user-mode driver cross-platform support method provided in an embodiment of the present application;

[0015] Figure 3 This is a schematic diagram of the structure of a device tree-based user-mode driver cross-platform support device provided in an embodiment of the present application;

[0016] Figure 4 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0017] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0018] The operating system is a core component of a computer system, responsible for managing hardware resources and providing services to applications. In traditional operating system architectures, drivers typically run in kernel space, working alongside the kernel to directly control hardware devices. While this architecture provides efficient hardware access because the driver and kernel share the same operating environment, it also has some significant drawbacks.

[0019] With the rise of microkernel operating systems (microkernel OS), operating system architectures are gradually shifting toward a design model that minimizes kernel functionality and shifts more operational logic to user space. In a microkernel architecture, the core operating system functionality is streamlined to include only the most basic functions, such as process management, memory management, and hardware interrupts, while traditional device drivers run in user space to provide greater security and stability.

[0020] Characteristics of traditional kernel-mode drivers include:

[0021] Running location: Runs in kernel space and interacts directly with hardware.

[0022] Tightly bound to hardware: The driver is strongly coupled to a specific hardware platform (e.g., associated with the instruction set and register operations of platforms such as x86 and ARM).

[0023] High risk: Since the driver runs in the same space as the kernel, once the driver crashes, the entire system may also crash.

[0024] Platform compatibility issues: If you want to run the original driver on a new hardware platform, you usually need to re-adapt and modify the driver's underlying implementation, which increases development and maintenance costs.

[0025] Characteristics of traditional microkernel architecture include:

[0026] Kernel minimization: Only basic resource management and communication functions are retained, such as process management, memory management, and interrupt handling. Other traditional driver, file system and other operating logic are moved to user mode.

[0027] User-mode driver: The driver is "moved out" from kernel space and runs in user space, communicating with the kernel through message passing. The kernel no longer directly controls the hardware device.

[0028] Enhanced isolation and security: Even if a user-mode driver crashes, the kernel is not affected, which enhances the stability and security of the operating system.

[0029] Although the architectural design of the microkernel operating system has significant security and stability advantages, moving drivers from kernel space to user space also brings many new technical challenges.

[0030] In addition, the interaction between the user-mode driver and the microkernel in the prior art is mainly achieved through a message queue or message passing mechanism. The driver needs to request hardware operation permissions from the kernel, and the kernel forwards the request to the specific hardware device.

[0031] Some operating systems shield the underlying hardware differences by introducing the Hardware Abstraction Layer (HAL). Drivers only need to interact with the abstraction layer without having to program directly to the hardware platform.

[0032] Some microkernel operating systems have proposed a unified driver framework, such as defining the driver as a set of common interfaces. Users only need to implement the interface methods to achieve support for different platforms.

[0033] However, the existing technical solutions still have the following disadvantages:

[0034] First, different hardware platforms (such as x86, ARM, RISC-V, etc.) use different instruction sets, I / O control interfaces, and interrupt mechanisms, which makes cross-platform driver development difficult.

[0035] Even if a hardware abstraction layer (HAL) is used to shield the underlying differences, the HAL still needs to be adapted and optimized for each new platform.

[0036] Secondly, in traditional kernel-mode drivers, hardware access is direct, but in user-mode drivers, accessing hardware requires first initiating a request to the kernel, which then forwards the request to the hardware device.

[0037] This "user state → kernel state → user state" switching increases the overhead of context switching, resulting in the driver's performance being inferior to that of the kernel state driver.

[0038] In addition, since the communication between user mode and kernel needs to rely on IPC (inter-process communication) mechanism, and IPC usually involves memory copying and context switching, the transmission delay is higher than that of traditional kernel mode drivers.

[0039] If the hardware device needs to frequently interact with the driver (such as high-frequency interrupts or real-time device operations), this communication delay may cause a performance bottleneck.

[0040] Finally, in traditional kernel-mode drivers, the operating system and hardware manufacturers' drivers can work closely together in the kernel, and operating system developers can directly optimize for the hardware platform.

[0041] However, in user-mode drivers, the driver's access is limited and it cannot directly operate certain hardware devices, especially those involving DMA (direct memory access) and interrupt management. These require special kernel-level permissions and are difficult to implement through user-mode drivers.

[0042] Therefore, how to implement an efficient cross-platform user-mode driver support method so that the driver can flexibly adapt, quickly load and dynamically match device nodes on different hardware platforms has become a technical problem that the industry urgently needs to solve.

[0043] In view of the problems existing in the prior art, this application proposes a method for implementing cross-platform support for user-mode drivers in a microkernel operating system. By combining the device tree mechanism with the device management mechanism, the driver's portability, scalability, and efficient management are achieved. To address the problems of traditional user-mode drivers, such as difficulty in cross-platform adaptation, large performance loss, and complex management, this application designs an overall framework for user-mode drivers, a device tree loading and matching mechanism, a unified device management and access interface, and proposes a platform switching mechanism.

[0044] Before describing the technical solution of the present application in detail, the overall framework structure of the user-mode driver of the microkernel operating system involved in the technical solution of the present application in actual scenarios is explained with reference to the accompanying drawings and embodiments. Figure 1 This is a schematic diagram of the overall framework structure of the microkernel operating system user mode driver provided by the embodiment of this application. Figure 1 As shown, the overall framework structure of the microkernel operating system user mode driver can specifically include the following contents:

[0045] First, the user-mode driver of the microkernel operating system provides services to external modules in the form of a device driver library.

[0046] The device driver library is the core component of user-mode drivers. It integrates multiple device categories and specific driver logic, and provides device access and operation methods to external modules through a standardized interface layer.

[0047] By calling the interfaces in the device driver library, external modules can access different categories of devices in the operating system without having to worry about the specific implementation details of the underlying hardware.

[0048] The following layered design is adopted: device interface layer and specific device driver layer

[0049] 1. Device interface layer

[0050] Function of the device interface layer: Provide a unified driver access method for device categories.

[0051] By defining standardized interfaces, external modules can call the functions of different categories of devices in a unified manner without having to directly operate the underlying driver logic of the device.

[0052] Device classification management: The device interface layer classifies and manages devices according to their functional categories (such as GPIO, SPI, FLASH, I2C, etc.), and provides corresponding driver interfaces for each type of device.

[0053] For example, GPIO devices provide operation methods through the "GPIO driver device interface"; SPI devices provide access methods through the "SPImaster driver device interface"; FLASH devices provide access methods through the "FLASH driver device interface"; and I2C devices provide operation methods through the "I2C host driver device interface."

[0054] This classification management method enhances the scalability and modularity of the system, making it easier to integrate new device categories.

[0055] 2. Specific device driver layer

[0056] Functions of the specific device driver layer: Implement specific device driver logic for different hardware manufacturers or different hardware platforms.

[0057] Provide independent device driver implementation for specific hardware under each device category (such as AM64x, ZYNQ MP, etc.).

[0058] Implementation of specific device drivers: Each specific device driver module is responsible for parsing the information of the corresponding device node in the device tree, and controlling the device according to the hardware resources provided in the node (such as register address, interrupt number, etc.).

[0059] For example, in the GPIO category, the GPIO device driver for AM64x and the GPIO device driver for ZYNQ MP provide specific implementations for different hardware platforms.

[0060] In the SPI category, the AM64x SPI driver, AM64x OSPI driver, and ZYNQ QMP QSP I driver support different hardware configurations and protocols respectively.

[0061] Furthermore, this framework separates driver code from hardware platform resources by introducing the Device Tree Mechanism, and provides a standardized way to manage and organize device drivers, including:

[0062] 1. Decoupling of driver and hardware:

[0063] Through the device tree mechanism, the device's hardware resource information (such as storage addresses and interrupt numbers) is abstracted into a standardized description file (i.e., the device tree file, DTB). The driver does not need to directly rely on the specific hardware platform; it only needs to parse the device node information defined in the device tree to complete the device adaptation.

[0064] 2. Dynamic management and loading:

[0065] When the system starts, the microkernel operating system loads the device tree file and parses the device nodes. The device interface layer and the specific device driver layer dynamically complete driver loading and device initialization by calling the hardware resource information defined in the device tree.

[0066] 3. Universality and sharing:

[0067] Different types of devices can share common interface methods, while specific hardware differences are handled by the resource information provided by the device tree and the implementation of the specific device driver layer.

[0068] Furthermore, the flexible configurations supported by the Kconfig tool include the following:

[0069] First, the device driver library supports trimming unnecessary driver modules through the Kconfig configuration tool.

[0070] When compiling the system, users can selectively compile the required driver modules according to specific hardware requirements, thereby reducing system resource usage and improving system performance.

[0071] For example, if a system only uses GPIO and I2C devices, the SPI and FLASH-related driver modules can be cut out through the Kconfig tool.

[0072] Furthermore, the Kconfig tool can automatically configure the required driver modules according to the target hardware platform, thereby achieving on-demand adaptation of the driver library to different hardware platforms.

[0073] For example, for the AM64x hardware platform, the Kconfig tool will configure the GPIO and SPI driver modules; for the ZYNQ MP hardware platform, the GPIO and QSPI driver modules will be selected.

[0074] Furthermore, the device tree file is loaded into the memory when the system starts, and the information of the device node (such as storage address, interrupt number, etc.) is passed to the specific device driver layer.

[0075] The driver module obtains resource information from the device tree file and completes initialization.

[0076] For example, the GPIO driver module obtains the storage address and interrupt number of the GPIO controller from the device tree; the SPI driver module obtains the bus resources from the device tree and completes the initialization of the bus device.

[0077] Figure 1 As shown by the middle arrow, the device tree is closely integrated with the specific device driver layer, ensuring that each device driver can achieve cross-platform adaptation through standardized device description information.

[0078] The microkernel operating system user-mode driver overall framework provided in this application significantly improves the system's security, reliability, and cross-platform adaptability through layered design, device tree mechanism, and flexible configuration tools, meeting the actual needs of multi-device management in complex systems.

[0079] Based on the aforementioned microkernel operating system user mode driver overall framework, the application of the device tree mechanism in the microkernel operating system user driver is as follows:

[0080] 1) Loading and parsing the device tree file: The device tree file (DTB) is independent of the kernel and application firmware and is provided by the bootloader. During the boot process, the microkernel operating system checks and loads the DTB, then loads it into memory. The kernel notifies the user driver module of the memory address through the boot information frame parameters. Alternatively, the DTB is packaged with the kernel and application files in an archive file. During the boot process, the microkernel operating system extracts the DTB file from the archive file and loads it into memory.

[0081] 2) Matching mechanism between the device tree and user-mode drivers: First, a macro is used to register the driver module's initialization function and matching string in a unified compilation section. The system then traverses the device tree to obtain information about all child nodes and searches for the corresponding driver module based on the device node's compatibility string. Once a matching driver module is found, its initialization function is called. If initialization is successful, processing continues with the next device node; otherwise, the driver module is added to the deferred initialization list.

[0082] The contents of the technical solution of this application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0083] Figure 2This is a flow chart of a method for supporting user-mode drivers across platforms based on a device tree according to an embodiment of the present application. Figure 2 As shown, the device tree-based user-mode driver cross-platform support method may specifically include:

[0084] S201, during system startup, loading the device tree file into the memory and passing the memory address of the device tree to the user-mode driver module;

[0085] S202, parsing the device tree file in the user-mode driver module and constructing a device node list, wherein the device node list includes a device path, a device status, and a compatibility string of the device node;

[0086] S203, during the system compilation phase, registering the initialization function and compatibility string of the driver module to the driver module segment to form a driver module list;

[0087] S204, matching the compatibility string of the device node with the compatibility strings in the driver module list. If the match is successful, calling the initialization function of the corresponding driver module to initialize the driver of the device corresponding to the device node;

[0088] S205, classify the devices according to their functions, define the device interface data structure and access method for each type of device, and register the device instance in the device list;

[0089] S206: When the external module in the user state accesses the device, the corresponding device instance is searched in the device linked list, and the operation method in the device instance is called to perform the operation on the device.

[0090] In some embodiments, during system startup, loading a device tree file into memory includes:

[0091] Check the device tree file during system startup, and if the device tree file exists independently, load the device tree file into memory; or,

[0092] The device tree file is packaged with the kernel file and the application file in an archive file, and the device tree file is extracted from the archive file during system startup and loaded into memory.

[0093] Specifically, during the system startup process, the device tree file is loaded and the driver module is registered. In this embodiment, the device tree file (DTB file) is loaded in one of the following two ways according to the different configuration environments of the system:

[0094] 1. Loading when the device tree file exists independently:

[0095] During system startup, the boot loader checks whether the device tree file is stored independently in a storage medium, such as a memory card, EEPROM, or flash memory.

[0096] If the device tree file (DTB file) exists independently, the boot loader will directly load the device tree file into the specified area of ​​the system memory.

[0097] After loading is complete, the system transmits the address of the device tree file in memory through the startup information frame, providing a resource entry for subsequent user-mode driven device tree parsing.

[0098] 2. Loading when packaging device tree files with kernel files and application files:

[0099] When the device tree file is packaged with the kernel file and application files in an archive file, such as a system image file generated by a file compression tool (such as a cpio format archive file), the boot loader first extracts the device tree file from the archive file.

[0100] The extracted device tree file is loaded into the specified area of ​​the memory, and the startup information frame records the memory address of the device tree file and passes the address to the user-mode driver module.

[0101] After loading the device tree file, the system completes kernel initialization to ensure that the resource description information of the device tree file is available in the user-mode driver module.

[0102] Furthermore, during the system compilation phase, the initialization function and compatibility string of the driver module are registered in the driver module segment. The specific process may include:

[0103] Driver module definition and registration:

[0104] The driver module is defined through the PS_DRIVER_MODULE_DEFINE macro, and its initialization function and compatibility string are registered in the kernel segment (_driver_modules segment).

[0105] For example, a macro definition might look like this:

[0106] PS_DRIVER_MODULE_DEFINE(driver_name,init_function,compatible_string);

[0107] driver_name: The name of the driver module, used to identify the module.

[0108] init_function: The initialization function of the driver module, used for device initialization operations.

[0109] compatible_string: The compatibility string of the driver module, used to match the compatibility string of the device tree node.

[0110] Furthermore, during system compilation, all driver modules registered through the PS_DRIVER_MODULE_DEFINE macro will be automatically placed in the _driver_modules segment by the compiler, forming a continuous storage area.

[0111] The system identifies the range of the driver module segment by defining the start pointer (__start__driver_modules) and end pointer (__stop__driver_modules) of the segment so that all registered driver modules can be located when the system starts.

[0112] Furthermore, during the system startup phase, the microkernel operating system completes loading of the device tree file and extracts resource description information from the device tree, including the following steps:

[0113] 1. Load the device tree file:

[0114] When the system starts, the bootloader locates the storage location of the device tree file (DTB file) in the memory through the address passed by the startup information frame.

[0115] The kernel reads the memory location and loads the device tree file, parsing the root node information and child node information in the device tree file.

[0116] 2. Get the device tree binary data:

[0117] The system parses the device tree file, extracts binary data, and obtains key information of the device node, such as the storage address of the hardware resource (such as the register base address); the device hardware resource configuration such as the interrupt number (IRQ); and the compatibility string (compatible) of the device node.

[0118] 3. Pass device tree data to the user-mode driver module:

[0119] After the device tree is parsed, the system passes the memory address of the device node list to the user-mode driver module, enabling it to access the device node information and further complete the driver initialization and operation of the device.

[0120] Through the methods of the above embodiment, device tree file loading and driver module registration are completed during the system startup phase. These two loading methods support independent storage and archiving of device tree files, adapting to different system configuration requirements. During the compilation phase, the PS_DRIVER_MODULE_DEFINE macro is used to register key driver module information in a specified kernel segment, simplifying the driver module management process. Compatibility strings are used to dynamically associate the device tree file with the driver module, supporting cross-platform hardware adaptation and significantly reducing development and maintenance costs.

[0121] In some embodiments, the device tree file is parsed in the user-mode driver module, and a device node list is constructed, including:

[0122] In the user-mode driver module, the memory address of the device tree transmitted by the kernel through the boot information frame is received to access the device tree file stored in the memory;

[0123] According to the memory address of the device tree, locate the root node of the device tree, and recursively parse the child nodes in the device tree starting from the root node to extract the key information of each device node;

[0124] Organize key information of the device node into a device node data structure, and add the device node data structure to the device node list.

[0125] Specifically, during system startup, the kernel loads the device tree file (DTB file) into a specified area of ​​memory and passes the memory address of the device tree to the user-mode driver module through a startup information frame.

[0126] After the user-mode driver module starts, it first reads the memory address of the device tree from the startup information frame to access the device tree file stored in memory. This memory address serves as the entry point for device tree parsing, ensuring that the user-mode driver module can obtain the complete device tree file structure.

[0127] The user-mode driver module locates the starting position of the device tree file based on the received device tree memory address. The device tree file consists of a series of nested nodes. The root node is the starting point of the device tree and contains global hardware resource description information and references to child nodes.

[0128] Furthermore, by parsing the root node, the user-mode driver module obtains the global structural information of the device tree file, such as the version number of the device tree, the main device category under the root node, the reference path of the child nodes, etc. The location of the root node provides the basis for the subsequent recursive parsing of all child nodes in the device tree.

[0129] Furthermore, starting from the root node of the device tree, the user-mode driver module recursively scans each child node in the device tree. During the recursive parsing process, the module traverses the hierarchical structure of the device tree level by level, accessing each child node one by one and extracting key information.

[0130] Furthermore, for each device node, the following key information is extracted:

[0131] Device path: identifies the unique logical location of the device node in the device tree, which is used for subsequent matching and operation of the driver module.

[0132] Offset: records the memory offset of the device node relative to the starting position of the device tree, which facilitates quick positioning of the device node.

[0133] Parent node information: Saves the parent-child relationship of device nodes and is used to build a hierarchical structure of the device tree.

[0134] Compatibility string: Extract the compatibility string (compatible) of the device node for matching the driver module.

[0135] Hardware resource description: includes register base address, interrupt number and other information related to device hardware operation.

[0136] Furthermore, the user-mode driver module initializes a hardware device node list for storing all device node information parsed from the device tree file.

[0137] After parsing each device node, the user-mode driver module organizes the node information into a standardized data structure and stores it in the device node list.

[0138] The data structure of each device node includes device path, offset, parent node information, compatibility string, and hardware resource description information.

[0139] At the same time, the management logic of the device node list supports fast query according to the device path or node index, which facilitates the calling and matching operations of subsequent driver modules.

[0140] Furthermore, during the recursive parsing process, the user-mode driver module saves the memory offset and parent node information for each device node.

[0141] In some examples, offset: By recording the offset of the device node relative to the starting position of the device tree file, the position of the node can be quickly located in the subsequent parsing or matching process;

[0142] Parent node information: By recording the parent-child relationship of device nodes, it ensures that the structural hierarchy of the device tree can be traced back when needed, or a complete device hierarchy model can be built.

[0143] Furthermore, the user-mode driver module adds each parsed device node to the device node list:

[0144] The device node list stores all parsed device nodes in order, providing a complete set of device nodes for subsequent driver module matching;

[0145] By indexing the device node list, you can quickly locate hardware resources or compatibility string information related to a specific device.

[0146] Through the method of this embodiment described above, the user-mode driver module can efficiently parse the device tree file and build a device node list. Recursively scan the root node and all child nodes to ensure that each device node in the device tree file is fully parsed. By saving the offset and parent node information of the device node, a complete device tree hierarchy is constructed, providing a clear logical hierarchy for subsequent device management. By organizing the device node data structure and adding it to the device node list, unified storage and efficient query of device node information are achieved. The compatibility string information in the device node list corresponds to the compatibility string in the driver module list, providing support for dynamic matching and initialization of the driver module.

[0147] In some embodiments, the initialization function and compatibility string of the driver module are registered to the driver module segment to form a driver module list, including:

[0148] Define initialization functions and compatibility strings for various driver modules;

[0149] Use compilation macros to register the initialization function and compatibility string of the driver module to the driver module segment, and store the function pointer and compatibility string of each driver module in the driver module data structure;

[0150] During compilation, the preset start pointer and end pointer are used to identify the start position and end position of the driver module segment to form a driver module list.

[0151] Specifically, during the development process, an initialization function and compatibility string are defined for each driver module. Each driver module is provided with an initialization function, which is called after the device node successfully matches the driver module to complete the driver loading and device initialization operations.

[0152] For example, for the GPIO driver module, its initialization function is responsible for allocating resources for the GPIO device and configuring related hardware registers.

[0153] Furthermore, the compatibility string of each driver module corresponds one-to-one with the compatibility string of the device node in the device tree, and is used to match the device node with the driver module.

[0154] For example, an I2C driver module might have a compatibility string of "i2c_host_v1" to match the node describing the I2C device in the device tree.

[0155] Furthermore, during the compilation phase, the driver module's initialization function and compatibility string are registered to the specified memory segment (_driver_modules segment) by using the compilation macro PS_DRIVER_MODULE_DEFIN E.

[0156] For example, each driver module is declared through the macro PS_DRIVER_MODULE_DEFINE, and the registration information includes: the driver module name (used to identify the module), the pointer to the initialization function, and the compatibility string.

[0157] The compilation macro stores the information of each driver module as a standardized data structure and places the data structure in the _driver_modules segment, so that the information of all driver modules can be managed centrally.

[0158] Furthermore, the registration information is stored in a predefined format, and the data structure includes but is not limited to the following:

[0159] The name of the driver module, used to identify the driver module;

[0160] The address of the initialization function, which is used to call the module to complete device initialization;

[0161] Compatibility string used to match device nodes in the device tree.

[0162] Furthermore, when generating the system image, the compiler allocates a dedicated memory segment for all driver modules based on the macro definition information, called the _driver_modules segment. The _driver_modules segment is a continuous storage area used to store all registered driver module information.

[0163] Furthermore, when generating the _driver_modules segment, the compiler automatically generates a start pointer __start__driver_modules and an end pointer __stop__driver_modules of the segment, which are used to identify the start position and the end position of the _driver_modules segment.

[0164] The start pointer and end pointer define the memory range of all driver module data, ensuring that all registered driver modules can be quickly located and traversed when the system starts.

[0165] Furthermore, during the system startup phase, the system constructs a complete list of driver modules using the start and end pointers. For example, the system reads the __start__driver_modules and __stop__driver_modules pointers to locate the memory range of the _driver_modules segment.

[0166] Extract the driver module information one by one from the _driver_modules segment, and load the data structure of each driver module into the driver module list.

[0167] The driver module list stores the initialization functions and compatibility strings of all driver modules in sequence, providing support for device node matching and driver initialization in the device tree.

[0168] Through the method of this embodiment described above, the information of all driver modules is centrally managed through the _driver_modules segment, which facilitates rapid loading and traversal during system startup. By matching the compatibility string with the device node in the device tree, it is ensured that the driver module can be correctly associated with the target device. The compilation macro PS_DR IVER_MODULE_DEFINE is used to automatically complete the driver module registration and memory allocation, eliminating the need to manually maintain the driver module registration information. Developers can easily expand new driver modules by adding new macro definitions without modifying the existing system logic.

[0169] In some embodiments, matching the compatibility string of the device node with the compatibility strings in the driver module list includes:

[0170] Traverse each device node in the device node list to determine whether the device node is in a disabled state. If it is in a disabled state, skip the current device node.

[0171] Check whether the device node contains a compatibility string. If not, skip the current device node. If it contains a compatibility string, get the compatibility string of the device node.

[0172] Match the compatibility string of the device node with the compatibility string of the driver module. If the match is successful, call the initialization function of the driver module to initialize the driver of the device corresponding to the device node;

[0173] If the match fails, add the driver module and device node to the delayed initialization list.

[0174] Specifically, after the device tree is parsed, the user-mode driver module will traverse each device node in sequence according to the device node list, and allocate memory for each device node to store the path information of the node in the device tree.

[0175] By calling the device tree parsing function (such as fdt_get_path), the complete path of the device node is obtained to facilitate subsequent management and matching operations.

[0176] During the traversal process, the status information of the device node is checked first.

[0177] If the status of a device node is marked as "disabled", the device node is skipped and no matching operation is performed.

[0178] For device nodes that are not disabled, further check whether they contain the "compatible" attribute. For example, if the device node does not define the "compatible" attribute, skip the node; if the device node contains the "compatible" attribute, extract the compatibility string of the node.

[0179] The compatibility string is an important attribute of a device node that identifies the hardware type. For example, an I2C device node may have a compatibility string of "i2c_host_v1".

[0180] Furthermore, during the compilation phase, the system has registered the initialization function and compatibility string of the driver module to the _driver_modules segment, and loaded all driver module information through the starting pointer __start__driver_modules and the ending pointer __stop__driver_modules to form a driver module list.

[0181] Each module in the driver module list contains its initialization function pointer and compatibility string.

[0182] Furthermore, for each device node, each driver module in the driver module list is traversed in turn to check whether its compatibility string matches the compatibility string of the device node.

[0183] If the match is successful, the initialization function of the matching driver module is called to initialize the hardware device corresponding to the device node.

[0184] Furthermore, after the match is successful, the initialization function of the driver module is called, which is responsible for completing the initialization operation of the hardware device corresponding to the device node, for example, including the following operations:

[0185] Allocate hardware resources, such as I / O registers and memory;

[0186] Configure the device's interrupt number and other hardware parameters;

[0187] Set the operating status of the device to enable it to work normally.

[0188] Furthermore, if the initialization function is executed successfully, a successful initialization status is returned and the device node is marked as initialized. If the initialization function fails, an initialization error message is recorded and a failure status is returned.

[0189] Furthermore, for device nodes and driver modules that failed to initialize successfully, perform the following operations:

[0190] 1. Add a delayed initialization list:

[0191] Call the delayed initialization function defer_driver_init to add the device node and the corresponding driver module to the delayed initialization list.

[0192] The delayed initialization list is used to store device nodes and driver modules that cannot be initialized immediately, providing a basis for subsequent retry attempts.

[0193] 2. Delayed retry:

[0194] During the delayed initialization phase of the system, the system will traverse the delayed initialization list and try to match and initialize the device nodes and driver modules in the list again until the device node is successfully initialized or the preset retry limit is reached.

[0195] According to the technical solution of the present embodiment described above, by checking the status of the device node, invalid matching operations on disabled nodes and nodes without compatibility strings are avoided, thereby improving the operating efficiency of the system. By dynamically matching the compatibility string of the device node with the compatibility string of the driver module, it is ensured that the device node can be correctly initialized, and automatic loading and configuration of the device driver is achieved. For device nodes that fail to initialize successfully, the delayed initialization mechanism allows the system to retry the initialization operation in subsequent stages, thereby improving the stability of the system and the success rate of device adaptation. The separate management of the driver module list and the device node list, as well as the dynamic matching of the compatibility string, enable the system to easily adapt to different types of devices and hardware platforms, significantly reducing development and maintenance costs.

[0196] In some embodiments, after adding the driver module and the device node to the delayed initialization list, the method further includes:

[0197] Traverse each device node in the delayed initialization list, re-call the initialization function of the driver module that matches each device node, and perform initialization operations on the device corresponding to the device node;

[0198] If the initialization is successful, remove the device node's resources from the delayed initialization list and release the resources associated with the device node;

[0199] If initialization fails, the device node and the corresponding driver module are retained in the delayed initialization list so that a delayed retry operation can be performed on the device nodes in the delayed initialization list later.

[0200] Specifically, during the delayed initialization phase of the system, the user-mode driver module calls a delayed initialization processing function (eg, handle_defered_modules) to process the device nodes and driver modules in the delayed initialization list.

[0201] The delayed initialization list contains all device nodes and corresponding driver modules that failed to initialize successfully in the first match. The user-mode driver module traverses the entries in the delayed initialization list one by one and retries the initialization operation for each device node.

[0202] Further, in some examples, for each device node in the lazy initialization list, the following steps are performed:

[0203] 1. Find the matching driver module:

[0204] Get the device node and its corresponding driver module information from the delayed initialization list. Ensure that the compatibility string of the driver module is consistent with the compatibility string of the device node to provide a basis for subsequent initialization operations.

[0205] 2. Re-call the initialization function of the driver module:

[0206] Call the driver module's initialization function to initialize the hardware device corresponding to the device node. The driver module's initialization function attempts to allocate necessary resources (such as register addresses, I / O channels, and interrupt numbers) and complete the device's hardware configuration.

[0207] Furthermore, according to the result returned by the initialization function of the driver module, subsequent processing is performed on the device node and the driver module.

[0208] If the initialization function returns a success status, indicating that the device corresponding to the device node has been successfully initialized, the device node and driver module are removed from the deferred initialization list; temporary resources related to the device node, such as the memory allocated for the device node path, are released; and the device node is marked as initialized, making it available for external modules to call and use.

[0209] If the initialization function returns a failure status, the device node and the corresponding driver module will continue to be retained in the delayed initialization list so that the initialization operation can be attempted again later; the reason for the initialization failure will be recorded to facilitate subsequent diagnosis and troubleshooting.

[0210] Furthermore, for the device nodes and driver modules retained in the delayed initialization list, the user-mode driver module will try to initialize them again in the next delayed initialization phase.

[0211] The system can re-call the delayed initialization processing function to traverse and process the device nodes in the list according to the set time interval or trigger condition.

[0212] Furthermore, if a device node fails to initialize successfully after multiple attempts, the system can decide whether to permanently remove it from the delayed initialization list based on a preset retry limit or other rules to avoid occupying resources.

[0213] Furthermore, during the delayed initialization process, when the initialization operation of a device node is successful, the system will release its related temporary resources, such as: memory space allocated for the device node path; intermediate state record data allocated for the delayed initialization operation; timely release of resources can avoid memory leaks or resource waste during system operation.

[0214] Through the technical solution of the above-mentioned embodiment, the system can efficiently manage device nodes and driver modules that have not been successfully initialized, ensuring that these nodes are not missed. By delaying the initialization processing function, the system can attempt to initialize the device nodes that have not been successfully initialized multiple times, thereby improving the success rate of the adaptation of the driver module and the device node. After the device node is successfully initialized, the resources related to it are released in a timely manner to avoid occupying system memory and other critical resources. For device nodes that fail to initialize, the delayed retry mechanism allows the system to decide whether to continue trying or terminate the operation based on actual needs, avoiding system crashes or anomalies during the adaptation process.

[0215] In some embodiments, the present application also provides a user-driven device management mechanism and a unified driver device access interface. Devices are classified according to their functions, each category represents a type of device, and each type of device provides a unified interface to the outside world. For example, devices can be divided into categories such as GPIO, SPI, UART, I2C, etc. Each type of device implements the same interface to ensure that different types of devices have consistent calling methods when in use. The specific driver of each type of device implements the relevant operating methods, and the specific device driver is responsible for implementing these methods to ensure that they have the same behavior and calling methods on different devices.

[0216] This application classifies devices by function to form a hierarchical structure and provides a set of universal device access interfaces for each type of device, thereby achieving efficient management of device drivers. Specific technical solutions include the following:

[0217] 1. Provides a framework for driver device interface registration and search. By defining data structures and operation functions, it implements the interface registration, deregistration and search functions. The specific technical content is as follows:

[0218] Register interface: Add the interface instance to the interface type list.

[0219] Deregister interface: Find and delete the interface instance node.

[0220] Find interface: Find the interface type node, traverse the interface instance list, and call the processing function for matching.

[0221] 2. Classify devices by function. Each category represents a type of device, and each category can contain multiple device instances. Device interface types allow for easy management and operation of devices with different functions, improving system flexibility and maintainability. Device interface categories include but are not limited to the following:

[0222] GPIO interface: used to manage general input and output pins.

[0223] Clock management interface: used to manage the clock signal of the device.

[0224] Reset management interface: used to manage the reset operation of the device.

[0225] I2C host interface: used to manage host communication on the I2C bus.

[0226] Real-time clock interface: used to manage the real-time clock.

[0227] Hardware monitoring interface: used to monitor hardware status, such as temperature, voltage, etc.

[0228] MDIO interface: used to manage the input and output of management data of Ethernet PHY devices.

[0229] Ethernet interface: used to manage Ethernet communications.

[0230] Timer interface: used to manage timers.

[0231] SDHC interface: used to manage the SD card controller.

[0232] SPI interface: used to manage serial peripheral interface.

[0233] Flash memory interface: used to manage flash memory devices.

[0234] 3. Each device interface defines the same data structure. Specific device drivers populate the corresponding data structure and implement specific methods. Each device provides the same methods and data structures.

[0235] For example, taking the I2C bus device as an example, the I2C bus device interface data structure is as follows:

[0236]

[0237] The I2C bus device provides an access interface to the outside world and obtains the I2C host bus structure through the FDT offset: i2c_host_bus_t*i2chostbus_get_byfdtoffset(ps_io_ops_t*io_ops,int fdt_offset);

[0238] Get the I2C host bus structure by bus name: i2c_host_bus_t*i2chostbus_get_bybusname(ps_io_ops_t*io_ops,char*busname).

[0239] Transfer messages between the I2C host and target device: int i2c_xfer(i2c_host_bus_t*pBus,i2c_msg_t*msgs,int num).

[0240] 4) The specific user-mode device driver implements a unified method for this type of device, fills in the data structure, and registers the device instance in the device list.

[0241] Zynq driver I2C bus device registration

[0242]

[0243] In some embodiments, the method further comprises:

[0244] During the compilation phase, the target platform is selected based on the configuration file or environment variables, and the compatibility of the device tree and driver module is configured to adapt to the hardware environment of the target platform;

[0245] During the runtime phase, the corresponding driver modules are dynamically loaded and called on different platforms based on the hardware resource information and device path described in the device tree to adapt to cross-platform switching.

[0246] Specifically, during the compilation phase, the system uses configuration files or environment variables to complete the selection and configuration of the device tree and driver module according to the hardware environment of the target platform.

[0247] First, the system specifies the type of platform currently running through configuration files or environment variables, such as x86, ARM, RISC-V and other architecture platforms.

[0248] The configuration file can adopt a standard format (such as JSON, Kconfig configuration file), which clearly defines the driver modules and device tree files corresponding to different platforms.

[0249] For example, for the ARM platform, the configuration file points to specific I2C and GPIO driver modules; for the RISC-V platform, the configuration file selects the corresponding SPI and UART driver modules. Use the Kconfig tool to tailor the driver modules:

[0250] Furthermore, during the compilation phase, the system uses the Kconfig tool to tailor driver modules. Specifically, the Kconfig tool parses the platform information in the configuration file and automatically selects the driver modules required for the current platform. Unused driver modules are removed during compilation, reducing system resource usage.

[0251] For example, when compiling for the x86 platform, the Kconfig tool selects the x86_gpio and x86_i2c driver modules and excludes driver modules for other hardware platforms.

[0252] Furthermore, during the configuration process, the system selects an appropriate device tree file based on the target platform. The device tree files of different hardware platforms (such as ARM device tree and RISC-V device tree) describe the hardware resource information of a specific platform.

[0253] The system dynamically selects and compiles the corresponding device tree file (DTB file) based on the configuration file to ensure that the hardware resources in the device tree are consistent with the target platform.

[0254] Furthermore, during the system operation phase, the system dynamically loads and calls the driver module corresponding to the target platform according to the hardware resource information and device path described in the device tree file.

[0255] For example, when the system starts, the device tree file is loaded and parsed to extract the hardware resource information of the current target platform, including but not limited to: the register address, interrupt number and I / O port of the hardware device; device path (such as I2C bus path, GPIO controller path), etc.

[0256] Through the information in the device tree, the system can identify all valid device nodes on the current hardware platform, providing a basis for loading the driver module.

[0257] Based on the compatibility strings in the device tree, the system dynamically matches and loads the corresponding driver module. For example, if the device node in the device tree contains the compatibility string "arm_i2c_v1", the system will load the I2C driver module for the ARM platform; for the RISC-V platform, the system will dynamically load the riscv_spi_v2 driver module to adapt to SPI devices.

[0258] Furthermore, after the driver module is loaded, the system calls its initialization function to configure the device and allocate resources, for example, including: mapping and configuring I / O registers, registering and enabling interrupt numbers, setting the operating status of hardware devices, etc.

[0259] By combining configuration files and environment variables, the system flexibly supports cross-platform switching. When switching to a new hardware platform, users only need to modify the configuration files or set new environment variables, without having to modify the driver module source code or redesign the device tree file. During system startup or operation, the system automatically loads the new device tree and driver module based on the new configuration.

[0260] Configuration files and the Kconfig tool support the rapid integration of new hardware platforms. Developers simply add the new platform's information (including the target platform's device tree file and a list of required driver modules) to the configuration file; the system automatically loads and calls the device tree and driver modules during compilation and runtime.

[0261] According to the technical solution provided in the embodiments of the present application, the technical solution of the present application has at least the following advantages:

[0262] Through the device tree mechanism and device management mechanism, the driver code and hardware platform resources are separated, allowing user drivers to run on different hardware platforms.

[0263] User-mode drivers are isolated from the kernel, reducing the risk of system crashes.

[0264] Through the unified driver device access interface, different types of devices can share common interfaces and functions, facilitating management and maintenance.

[0265] Through standardized interfaces and management mechanisms, the development and maintenance costs of drivers are reduced. Through the device tree mechanism and device management mechanism, the driver code and hardware platform resources are separated, allowing user drivers to run on different hardware platforms.

[0266] This application has clear practical application value and is applicable to various embedded systems and microkernel operating systems. Because the driver module is compatible with different hardware platforms, it significantly improves the portability of the driver. Because the user-mode driver reduces kernel-mode complexity and reduces the risk of kernel crashes, it enhances system security. Because the driver can be updated and expanded without affecting the core system, it increases flexibility. Because the unified interface and device management mechanism simplify driver development, it reduces development and maintenance costs.

[0267] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0268] Figure 3 This is a schematic diagram of the structure of the user-mode driver cross-platform support device based on the device tree provided in the embodiment of the present application. Figure 3 As shown, the device tree-based user-mode driver cross-platform support device includes:

[0269] The loading module 301 is used to load the device tree file into the memory during the system startup process and pass the memory address of the device tree to the user mode driver module;

[0270] A parsing module 302 is configured to parse the device tree file in the user-mode driver module and construct a device node list, wherein the device node list includes a device path, a device status, and a compatibility string of the device node;

[0271] The registration module 303 is used to register the initialization function and compatibility string of the driver module to the driver module segment during the system compilation phase to form a driver module list;

[0272] The matching module 304 is used to match the compatibility string of the device node with the compatibility strings in the driver module list. If the match is successful, the initialization function of the corresponding driver module is called to initialize the driver of the device corresponding to the device node.

[0273] Classification module 305, used to classify devices according to their functions, define device interface data structure and access method for each type of device, and register device instances in the device list;

[0274] The calling module 306 is used to search for the corresponding device instance in the device linked list when the external module in the user state accesses the device, and call the operation method in the device instance to perform the operation on the device.

[0275] In some embodiments, Figure 3The loading module 301 checks the device tree file during the system startup process, and when the device tree file exists independently, loads the device tree file into the memory; or, packages the device tree file, the kernel file, and the application file in an archive file, and extracts the device tree file from the archive file during the system startup process, and loads the device tree file into the memory.

[0276] In some embodiments, Figure 3 The parsing module 302 receives the memory address of the device tree transmitted by the kernel through the startup information frame in the user-mode driver module to access the device tree file stored in the memory; locates the root node of the device tree according to the memory address of the device tree, and recursively parses the child nodes in the device tree starting from the root node to extract the key information of each device node; organizes the key information of the device node into a device node data structure, and adds the device node data structure to the device node list.

[0277] In some embodiments, Figure 3 The registration module 303 defines initialization functions and compatibility strings for various driver modules; uses compilation macros to register the initialization functions and compatibility strings of the driver modules to the driver module segment, and stores the function pointer and compatibility string of each driver module in the driver module data structure; during compilation, uses preset start pointers and end pointers to identify the start position and end position of the driver module segment to form a driver module list.

[0278] In some embodiments, Figure 3 The matching module 304 traverses each device node in the device node list to determine whether the device node is in a disabled state. If it is in a disabled state, the current device node is skipped; it checks whether the device node contains a compatibility string. If it does not contain a compatibility string, the current device node is skipped. If it contains a compatibility string, the compatibility string of the device node is obtained, and the compatibility string of the device node is matched with the compatibility string of the driver module. If the match is successful, the initialization function of the driver module is called to initialize the driver of the device corresponding to the device node; if the match fails, the driver module and the device node are added to the delayed initialization list.

[0279] In some embodiments, Figure 3After adding the driver module and the device node to the delayed initialization list, the matching module 304 traverses each device node in the delayed initialization list, re-calls the initialization function of the driver module that matches each device node, and performs initialization operations on the device corresponding to the device node; if the initialization is successful, the resources of the device node are removed from the delayed initialization list, and the resources related to the device node are released; if the initialization fails, the device node and the corresponding driver module are retained in the delayed initialization list so that a delayed retry operation can be performed on the device node in the delayed initialization list later.

[0280] In some embodiments, Figure 3 During the compilation phase, the configuration module 307 selects the target platform based on the configuration file or environment variables, and configures the compatibility of the device tree and the driver module to adapt to the hardware environment of the target platform; during the operation phase, according to the hardware resource information and device path described in the device tree, the corresponding driver module is dynamically loaded and called on different platforms to adapt to cross-platform switching.

[0281] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0282] Figure 4 Schematic diagram of the electronic device 4 provided in the embodiment of the present application. Figure 4 As shown, the electronic device 4 of this embodiment includes: a processor 401, a memory 402, and a computer program 403 stored in the memory 402 and executable by the processor 401. When the processor 401 executes the computer program 403, the steps of the above-described method embodiments are implemented. Alternatively, when the processor 401 executes the computer program 403, the functions of the modules / units in the above-described device embodiments are implemented.

[0283] The electronic device 4 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 4 may include but is not limited to a processor 401 and a memory 402. Those skilled in the art will appreciate that Figure 4 This is merely an example of the electronic device 4 and does not limit the electronic device 4 . The electronic device 4 may include more or fewer components than shown in the figure, or different components.

[0284] The processor 401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0285] Memory 402 can be an internal storage unit of electronic device 4, such as a hard disk or memory of electronic device 4. Memory 402 can also be an external storage device of electronic device 4, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on electronic device 4. Memory 402 can also include both an internal storage unit of electronic device 4 and an external storage device. Memory 402 is used to store computer programs and other programs and data required by the electronic device.

[0286] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0287] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium (such as a computer-readable storage medium). Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form, etc. Computer-readable storage media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0288] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A user-mode driver cross-platform support method based on device tree, characterized in that: include: During system startup, the device tree file is loaded into memory, and the memory address of the device tree is passed to the user-mode driver module; Parsing the device tree file in the user-mode driver module and constructing a device node list, wherein the device node list includes a device path, a device status, and a compatibility string of the device node; During the system compilation phase, the initialization function and compatibility string of the driver module are registered to the driver module segment to form a driver module list; Matching the compatibility string of the device node with the compatibility strings in the driver module list, and if the match is successful, calling the initialization function of the corresponding driver module to initialize the driver of the device corresponding to the device node; Classify devices according to their functions, define the device interface data structure and access method for each type of device, and register the device instance in the device list; When an external module in user mode accesses a device, it searches for a corresponding device instance in the device linked list, and calls an operation method in the device instance to perform an operation on the device.

2. The method according to claim 1, characterized in that During the system startup process, the device tree file is loaded into the memory, including: Checking the device tree file during system startup, and when the device tree file exists independently, loading the device tree file into the memory; or, The device tree file, the kernel file and the application file are packaged in an archive file, and the device tree file is extracted from the archive file during system startup, and the device tree file is loaded into a memory.

3. The method according to claim 1, characterized in that The device tree file is parsed in the user-mode driver module, and a device node list is constructed, including: In the user-mode driver module, a memory address of the device tree transmitted by the kernel through a startup information frame is received to access the device tree file stored in the memory; Locating the root node of the device tree according to the memory address of the device tree, and recursively parsing the child nodes in the device tree starting from the root node to extract key information of each device node; The key information of the device node is organized into a device node data structure, and the device node data structure is added to a device node list.

4. The method according to claim 1, wherein The initialization function and compatibility string of the driver module are registered in the driver module segment to form a driver module list, including: Define initialization functions and compatibility strings for various driver modules; Registering the initialization function and compatibility string of the driver module to the driver module segment by using a compilation macro, and storing the function pointer and compatibility string of each driver module in a driver module data structure; During compilation, the start position and the end position of the driver module segment are identified by using the preset start pointer and end pointer to form the driver module list.

5. The method according to claim 1, wherein The matching of the compatibility string of the device node with the compatibility string in the driver module list includes: Traversing each device node in the device node list to determine whether the device node is in a disabled state, and if so, skipping the current device node; Check whether the device node contains a compatibility string. If not, skip the current device node. If it contains a compatibility string, get the compatibility string of the device node. Matching the compatibility string of the device node with the compatibility string of the driver module; if the match is successful, calling the initialization function of the driver module to initialize the driver of the device corresponding to the device node; If the matching fails, the driver module and the device node are added to the delayed initialization list.

6. The method according to claim 5, characterized in that After adding the driver module and the device node to the delayed initialization list, the method further includes: Traversing each device node in the delayed initialization list, re-calling the initialization function of the driver module matching each device node, and performing an initialization operation on the device corresponding to the device node; If the initialization is successful, the resources of the device node are removed from the delayed initialization list, and the resources associated with the device node are released; If the initialization fails, the device node and the corresponding driver module are retained in the delayed initialization list so that a delayed retry operation can be performed on the device node in the delayed initialization list later.

7. The method according to claim 1, characterized in that The method further comprises: During the compilation phase, a target platform is selected based on a configuration file or an environment variable, and the compatibility of the device tree and the driver module is configured to adapt to the hardware environment of the target platform; During the running phase, the corresponding driver modules are dynamically loaded and called on different platforms according to the hardware resource information and device paths described in the device tree to adapt to cross-platform switching.

8. A user-mode driver cross-platform support device based on device tree, characterized in that: include: The loading module is used to load the device tree file into the memory during system startup and pass the memory address of the device tree to the user-mode driver module; a parsing module, configured to parse the device tree file in the user-mode driver module and construct a device node list, wherein the device node list includes a device path, a device status, and a compatibility string of the device node; The registration module is used to register the initialization function and compatibility string of the driver module to the driver module segment during the system compilation phase to form a driver module list; a matching module, configured to match the compatibility string of the device node with the compatibility strings in the driver module list, and if a match is successful, call the initialization function of the corresponding driver module to initialize the driver of the device corresponding to the device node; The classification module is used to classify devices according to their functions, define the device interface data structure and access method for each type of device, and register the device instance in the device list; The calling module is used to search for the corresponding device instance in the device linked list when the external module in the user state accesses the device, and call the operation method in the device instance to perform the operation on the device.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images