User mode driven cross-platform support method and device based on equipment tree and medium

Abstract

The invention provides a user mode driven cross-platform support method and device based on an equipment tree and a medium. The method comprises the steps that in the system starting process, a device tree file is loaded to a memory, and a memory address of a device tree is transmitted to a user mode driving module; analyzing the device tree file in the user mode driving module, and constructing a device node list; in a system compiling stage, an initialization function and a compatibility character string of a driving module are registered to a driving module section to form a driving module list; matching the compatibility character string of the equipment node with the compatibility character string in the driving module list; registering the equipment instance into an equipment linked list; and when the external module in the user mode accesses the equipment, searching the corresponding equipment instance in the equipment linked list, and calling an operation method in the equipment instance to operate the equipment. According to the method, the drive program can be flexibly adapted on different hardware platforms, the development cost is reduced, and the system safety is improved.

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 usually run in kernel space and interact directly with the kernel and hardware devices. Since drivers are tightly bound to specific hardware platforms, the cost of developing and maintaining drivers on different hardware platforms is high. For example, the adaptation work for different architecture platforms such as x86, ARM, and RISC-V often requires the reconstruction or modification of the underlying implementation of the driver, resulting in a long development cycle and difficult maintenance.

[0003] In order to solve the security and stability issues of kernel space drivers, the architecture of microkernel operating system (Microkernel OS) has gradually emerged. Microkernel operating system minimizes kernel functions and transfers most of the operation logic and device drivers to user space. This design improves the security and reliability of the system. Since user-mode drivers run in user space, they are isolated from kernel space. Even if the user-mode driver crashes, it will not cause the kernel to crash, thereby enhancing the stability and recoverability of the system.

[0004] However, with the introduction of user-mode drivers, new technical problems also arise. User-mode drivers need to be compatible with multiple hardware platforms, which brings challenges in 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 reuse directly on these platforms, and the development cost and cycle of cross-platform porting are high. In addition, the dynamic loading of user-mode drivers and the efficiency of device management are also challenged. Since the user-mode driver relies on message passing and interrupt mechanisms with the kernel, how to efficiently achieve driver matching and initialization in the process of dynamically loading the device tree, parsing device nodes, and initializing device drivers has become a major problem. 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 a 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 device instances in 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 operations 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, which is used to load a device tree file into a memory during system startup, and pass the memory address of the device tree to a user-mode driver module; a parsing module, which is used 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; a registration module, which is used to register the initialization function and the 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, which is used to match the compatibility string of the device node with the compatibility string in the driver module list, and if the match is successful, call the initialization function of the corresponding driver module to initialize the driver of the device corresponding to the device node; a classification module, which is used to classify devices according to their functions, define a device interface data structure and an access method for each type of device, and register the device instance in a device linked list; a calling module, which is used to search for the corresponding device instance in the device linked list when an external module in the user mode accesses the device, and call 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, including 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 an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program, and 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 stage, 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 device is classified according to function, 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 on 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 drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. 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 paying any creative work.

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

[0014] Figure 2 It 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 It is a structural diagram 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 schematic diagram of the structure 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, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also 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 prevent unnecessary details from obstructing the description of the present application.

[0018] The operating system is the core component of the computer system, responsible for managing hardware resources and providing services to applications. In the traditional operating system architecture, the driver usually runs in the kernel space and directly controls the hardware devices together with the kernel. Since the driver and the kernel share the same operating environment, although this architecture can provide efficient hardware access, it also has some obvious disadvantages.

[0019] With the rise of microkernel OS, the OS architecture has gradually shifted to a design model that "minimizes kernel functions and transfers more operation logic to user space". In the microkernel architecture, the core functions of the OS are reduced to only the most basic functions such as process management, memory management, and hardware interrupts, while traditional device drivers run in user space to provide higher security and stability.

[0020] The 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 (such as 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 underlying implementation of the driver, which will increase development and maintenance costs.

[0025] The 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 logics 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 the 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, transferring 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 a message passing mechanism. The driver needs to request the kernel for hardware operation permissions, and the kernel forwards the request to a specific hardware device.

[0031] Some operating systems shield the underlying hardware differences by introducing the Hardware Abstraction Layer (HAL). The driver only needs to interact with the abstract 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 it to the hardware device.

[0037] This "user state → kernel state → user state" switching increases the context switching overhead, 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 interact with the driver frequently (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 vendors' 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, which 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, and realizes the portability, scalability and efficient management of the driver through the combination of the device tree mechanism and the device management mechanism. In order to solve the problems of difficult cross-platform adaptation, large performance loss and complex management of traditional user-mode drivers, this application designs the overall framework of user-mode drivers, the loading and matching mechanism of the device tree, the 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 in conjunction with the accompanying drawings and embodiments. Figure 1 Schematic diagram of the overall framework structure of the microkernel operating system user mode driver provided in the embodiment of the present application. Figure 1 As shown, the overall framework structure of the microkernel operating system user mode driver may 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 the user-mode driver. 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 types of equipment.

[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 method 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 QSPI driver support different hardware configurations and protocols respectively.

[0061] Furthermore, this framework separates the driver code from the 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 hardware resource information of the device (such as storage address, interrupt number, etc.) is abstracted into a standardized description file (i.e., device tree file, DTB). The driver does not need to directly rely on the specific hardware platform, but only needs to parse the device node information defined in the device tree to complete the adaptation of the device.

[0064] 2. Dynamic management and loading:

[0065] When the system starts, the microkernel operating system loads the device tree file and parses the device node. The device interface layer and the specific device driver layer dynamically complete the 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 configuration supported by the Kconfig tool specifically includes 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 to ensure 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 of device tree files: The device tree file (DTB) is independent of the kernel and application firmware and is provided by the boot loader. The microkernel operating system checks and loads the DTB during the boot process and then loads it into memory. The kernel notifies the user driver module of the memory address through the boot information frame parameters. Another way is that the DTB is packaged in an archive file together with the kernel file and the application file. The microkernel operating system extracts the DTB file from the archive file during the boot process and loads it into memory.

[0081] 2) Matching mechanism between device tree and user-mode driver: First, use macros to register the initialization function and matching string of the driver module into a unified compilation segment. Then, the system traverses the device tree to obtain the information of all child nodes, and searches for the corresponding driver module according to the compatibility string of the device node. After finding the matching driver module, call its initialization function. If the initialization is successful, continue to process the next device node; otherwise, add the driver module to the delayed initialization list.

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

[0083] Figure 21 is a flow chart of a method for supporting user-mode drivers across platforms based on a device tree provided in 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 the system startup process, loading the device tree file into the memory, and passing the memory address of the device tree to the user state 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, in the system compilation stage, 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 string in the driver module list, and if the match succeeds, 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 the system startup process and loaded into the 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 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 independently stored 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 transfers 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 of device tree files when packaging with kernel files and application files:

[0099] When the device tree file is packaged with the kernel file and the application file 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 will first extract the device tree file in 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 will complete the kernel initialization work 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 to form 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 the 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, for example, including: 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 method of the above embodiment, the loading of the device tree file and the registration of the driver module are completed during the system startup phase. Through two loading methods, the independent storage and archive packaging of the device tree file are supported to adapt to different system configuration requirements. In the compilation phase, the key information of the driver module is registered to the specified kernel segment through the PS_DRIVER_MODULE_DEFINE macro, which simplifies the management process of the driver module. The device tree file and the driver module are dynamically associated through a compatibility string, which supports cross-platform hardware adaptation and significantly reduces 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, 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;

[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] The key information of the device node is organized into a device node data structure, and the device node data structure is added to the device node list.

[0125] Specifically, during the system startup process, the kernel loads the device tree file (DTB file) into a specified area of ​​the 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 is started, it first reads the memory address of the device tree from the startup information frame to access the device tree file stored in the memory. This memory address serves as the entry point for device tree parsing to ensure 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 according to 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 node, 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, accesses the child nodes one by one, and extracts 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 the matching and operation of subsequent driver modules.

[0132] Offset: records the memory offset of the device node relative to the starting position of the device tree, which facilitates the rapid 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 information of the node 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 start 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 necessary, 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 the present embodiment described above, the user-mode driver module can efficiently complete the parsing of 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 to provide 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 of 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] Register the initialization function and compatibility string of the driver module to the driver module segment using the compilation macro, and store the function pointer and compatibility string of each driver module in the driver module data structure;

[0150] During compilation, the start and end positions of the driver module segments are identified using the preset start pointer and end pointer to form a driver module list.

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

[0152] For example, for a GPIO driver module, its initialization function is responsible for allocating resources for GPIO devices 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", matching the node describing the I2C device in the device tree.

[0155] Furthermore, during the compilation phase, the initialization function and compatibility string of the driver module 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), a pointer to the initialization function, and a 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 the compiler generates the system image, it will allocate a dedicated memory segment for all driver modules according to 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, a complete list of driver modules is constructed through 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 section, 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 order, providing support for device node matching and driver initialization in the device tree.

[0168] Through the method of the present embodiment described above, the information of all driver modules is centrally managed through the _driver_modules segment, which is convenient for fast loading and traversal when the system starts. 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 driver module registration and memory allocation are automatically completed using the compilation macro PS_DR IVER_MODULE_DEFINE, without the need to manually maintain the registration information of the driver module. 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 string 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 turn according to the device node list, and allocate memory to 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 the 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, the system has registered the initialization function and compatibility string of the driver module to the _driver_modules segment during the compilation phase, 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 having completed initialization. If the initialization function fails to execute, initialization error information 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 failed to initialize immediately, providing a basis for subsequent retries.

[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 realized. 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 matching each device node, and perform initialization operations on the device corresponding to the device node;

[0198] 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;

[0199] 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.

[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 be initialized 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 initialization function of the driver module to initialize the hardware device corresponding to the device node. The initialization function of the driver module will try to allocate necessary resources (such as register addresses, I / O channels, and interrupt numbers) and complete the hardware configuration of the device.

[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 delayed initialization list; temporary resources related to the device node are released, such as the memory allocated for the device node path; and the device node is marked as initialized so that it can be called and used by external modules.

[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 is 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 still cannot be successfully initialized after multiple attempts, the system can decide whether to permanently remove it from the delayed initialization list based on a preset upper limit on the number of retries or other rules to avoid occupying resources.

[0213] Furthermore, during the delayed initialization process, when the initialization operation of a device node succeeds, 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 present embodiment described above, the system can efficiently manage the device nodes and driver modules that have not been successfully initialized, ensuring that these nodes will not be missed. Through the delayed initialization processing function, the system can repeatedly attempt to initialize the device nodes that have not been successfully initialized, 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 time to avoid occupying system memory and other key 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 according to actual needs, thereby 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 thereof. 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. 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 a consistent calling method 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 the same behavior and calling method on different devices.

[0216] This application forms a hierarchical structure by classifying devices according to their functions, and provides a set of universal device access interfaces for a class of devices, thereby achieving efficient management of device drivers. The specific technical solutions include the following:

[0217] 1. Provides a framework for driver device interface registration and search, and implements interface registration, deregistration and search functions by defining data structures and operation functions. The specific technical contents are as follows:

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

[0219] Unregister 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 the devices according to their functions. Each category represents a type of device, and each category can contain multiple device instances. Through the device interface type, you can easily manage and operate devices with different functions, improving the flexibility and maintainability of the system. 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 communications 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 management data input and output 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 type of device interface defines the same data structure, and the specific device driver fills the corresponding data structure and implements specific methods. Each type of device provides the same methods and data structures to the outside.

[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 into 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, the corresponding driver modules are dynamically loaded and called on different platforms according to 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 the currently running platform 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 the driver modules. The specific operations include: the Kconfig tool will parse the platform information in the configuration file and automatically filter out the driver modules required by the current platform; for unused driver modules, the Kconfig tool will remove them during compilation, thereby 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 according to the target platform. The device tree files of different hardware platforms (such as ARM device tree, 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] According to the compatibility string in the device tree, the system dynamically matches and loads the corresponding driver module. For example, when the device node in the device tree contains the compatibility string "arm_i2c_v1", the system will load the I2C driver module of the ARM platform; for the RISC-V platform, the system will dynamically load the riscv_spi_v2 driver module to adapt to the SPI device.

[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] Through the combination of configuration files and environment variables, the system can flexibly support cross-platform switching. When switching to a new hardware platform, users only need to modify the configuration files or set new environment variables, without modifying the source code of the driver module or redesigning the device tree file. During system startup or operation, the system will automatically load the new device tree and driver module according to the new configuration.

[0260] Configuration files and Kconfig tools support the rapid access of new hardware platforms. Developers only need to add the information of the new platform (including the device tree file of the target platform and the list of required driver modules) in the configuration file; the system can automatically load and call the device tree and driver modules during the compilation and operation stages.

[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, so that the user driver can 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, which is easy to manage and maintain.

[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. Since the driver module can be compatible with different hardware platforms, the portability of the driver is significantly improved. Since the user-mode driver reduces the complexity of the kernel mode and reduces the risk of kernel crashes, the security of the system is enhanced. Since the driver can be updated and expanded without affecting the system core, the flexibility is improved. Since the unified interface and device management mechanism simplify the development of the driver, the development and maintenance costs are reduced.

[0267] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0268] Figure 3 Schematic diagram of the structure of the device tree-based user-mode driver cross-platform support device 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 state driver module;

[0270] A parsing module 302 is used 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 to form a driver module list during the system compilation stage;

[0272] The matching module 304 is used to match the compatibility string of the device node with the compatibility string 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 into a 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 with the kernel file and the application file in an archive file, 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 segments, and stores the function pointers and compatibility strings of each driver module in the driver module data structure; during compilation, uses preset start pointers and end pointers to identify the start and end positions of the driver module segments 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 the compatibility string, the current device node is skipped; if it contains the 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 the present application.

[0282] Figure 4 Schematic diagram of an electronic device 4 provided in an 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 on the processor 401. When the processor 401 executes the computer program 403, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 401 executes the computer program 403, the functions of the modules / units in the above-mentioned 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 The electronic device 4 is merely an example and does not limit the electronic device 4 , and may include more or less components than those 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] The memory 402 may be an internal storage unit of the electronic device 4, for example, a hard disk or memory of the electronic device 4. The memory 402 may also be an external storage device of the electronic device 4, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 4. The memory 402 may also include both an internal storage unit and an external storage device of the electronic device 4. The memory 402 is used to store computer programs and other programs and data required by the electronic device.

[0286] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be assigned to 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 unit 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 (e.g., 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. Computer-readable storage media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, 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, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope 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 a 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 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; Classify devices according to their functions, define device interface data structures and access methods for each type of device, and register device instances 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: During the system startup process, the device tree file is checked, and when the device tree file exists independently, the device tree file is loaded 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 parsing of the device tree file in the user-mode driver module and constructing a device node list includes: 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; According to the memory address of the device tree, the root node of the device tree is located, and the child nodes in the device tree are recursively parsed 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, characterized in that: The initialization function and compatibility string of the driver module are registered to 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 the end pointer to form the driver module list.

5. The method according to claim 1, characterized in that 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 in a disabled state, 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, and 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 is subsequently performed on the device node in the delayed initialization list.

7. The method according to claim 1, characterized in that The method further comprises: In the compilation stage, 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 operation 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 a device tree, characterized in that: include: The loading module 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; A parsing module, used for 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 a 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, used to match the compatibility string of the device node with the compatibility string in the driver module list, and if the 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, characterized in that: 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