Hardware resource configuration method based on equipment tree

Abstract

The invention discloses a hardware resource configuration method based on an equipment tree, which comprises the following steps: acquiring a to-be-configured signal request through a preset equipment tree, and performing format analysis on the to-be-configured signal request according to the type of the preset equipment tree to obtain an execution signal, an execution mode and a processing priority, the to-be-configured signal request comprises but is not limited to a hardware resource address, a signal format and a device identifier; calling a driving program corresponding to the execution signal from a preset driving program database according to the equipment identifier; and driving corresponding application equipment to execute operation according to the driving program, the execution mode and the processing priority corresponding to the execution signal. According to the hardware resource configuration method based on the equipment tree, separation of the drive code and the hardware information is achieved, the influence of hardware configuration adjustment on a drive program is reduced, the portability of a system and hardware resources is improved, and migration and adaptation on different hardware platforms are facilitated.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a hardware resource configuration method based on a device tree. Background Art

[0002] In existing computer systems, hardware resource configuration usually requires writing a driver for each hardware device and writing the hardware information directly into the driver code. When the hardware device changes, the driver also needs to be modified accordingly, which makes the driver maintenance and upgrade difficult. In addition, the driver contains a lot of redundant code for hardware details, which increases the complexity and instability of the system. With the development of technology, the types and number of hardware devices are increasing. This traditional hardware configuration method can no longer meet the needs of modern computer systems for flexibility and maintainability. Summary of the invention

[0003] In order to solve the technical problems existing in the background technology, the present invention proposes a hardware resource configuration method based on a device tree.

[0004] The present invention proposes a method for hardware resource configuration based on a device tree, comprising:

[0005] Obtain a signal request to be configured through a preset device tree, and perform format parsing on the signal request to be configured according to the type of the preset device tree to obtain an execution signal, an execution mode, and a processing priority, wherein the signal request to be configured includes but is not limited to a hardware resource address, a signal format, and a device identifier;

[0006] Calling a driver corresponding to the execution signal from a preset driver database according to the device identification;

[0007] The corresponding application device is driven to perform the operation according to the driver, execution mode and processing priority corresponding to the execution signal.

[0008] Preferably, it also includes: when the acquired signal to be configured requests a change, generating an execution constraint of the execution signal; when the execution signal exceeds the limit defined in the preset device tree, truncating the signal or reporting an error.

[0009] Preferably, the construction process of the preset device tree is specifically as follows:

[0010] Build a device tree, which includes a root node, multiple child nodes, and multiple leaf nodes. The root node represents the top layer of the hardware system, the multiple child nodes represent multiple application devices, and the multiple leaf nodes represent multiple specific hardware attributes of the application devices.

[0011] Multiple sub-nodes are layered according to functional modules, and the processing priority of each layer is set to form a pyramid-shaped preset device tree.

[0012] Preferably, the format parsing of the request for configuration signal according to the type of the preset device tree to obtain the execution signal, execution mode, and processing priority specifically includes:

[0013] Performing data conversion or protocol conversion on the signal format of the signal request to be configured, so that the signal request to be configured is converted into an execution signal that can be processed by the preset device tree;

[0014] An execution mode and a processing priority are assigned to the signal request to be configured based on the hardware resource address and the device identifier.

[0015] Preferably, the preset driver database is configured to store a plurality of driver programs corresponding to a plurality of application devices on a one-to-one basis, and a plurality of device identifiers are configured on a one-to-one basis for the plurality of application devices.

[0016] Preferably, before obtaining the signal request to be configured through the preset device tree, the method further includes:

[0017] Acquire multiple application devices to be configured and attribute information corresponding to the multiple application devices, wherein the attribute information includes but is not limited to the type, compatibility, and resource requirements of the device;

[0018] Multiple application devices are layered according to functional modules, a preset device tree file is written, multiple child nodes are configured one by one for the multiple layered application devices, multiple leaf nodes are configured for the attribute information corresponding to the multiple layered application devices, and one child node corresponds to one or more leaf nodes.

[0019] Preferably, the driving of the corresponding application device to perform the operation according to the driver, execution mode and processing priority corresponding to the execution signal is specifically: driving the corresponding application device to perform the operation in the order corresponding to the processing priority from high to low, one application device corresponds to one driver, and one application device corresponds to one execution mode.

[0020] In the present invention, the proposed hardware resource configuration method based on the device tree improves the flexibility and maintainability of the hardware resource configuration and reduces the upgrade and maintenance costs of the driver. Through the use of the device tree, the adjustment and upgrade of the hardware configuration become simple and fast, without the need to make large-scale modifications to the driver, reducing the redundant code in the driver and improving the stability and reliability of the system. Since the hardware information is separated into the device tree, the driver is more concise and focuses on realizing the functions of the device, avoiding errors caused by changes in hardware details, realizing the separation of the driver code and the hardware information, and reducing the impact of the hardware configuration adjustment on the driver. The separation of the driver and the hardware information makes it possible for the change of the hardware configuration to not affect the stability of the driver, improves the portability of the system and hardware resources, and facilitates migration and adaptation on different hardware platforms. The use of the device tree makes the hardware configuration information independent of the platform, which facilitates the reuse of the same driver on different hardware platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A schematic diagram of the work flow structure of a device tree-based hardware resource configuration method proposed by the present invention. DETAILED DESCRIPTION

[0022] Reference Figure 1 The present invention proposes a method for hardware resource configuration based on a device tree, comprising:

[0023] S0. Obtain multiple application devices to be configured and attribute information corresponding to the multiple application devices, the attribute information including but not limited to the type, compatibility, and resource requirements of the devices; stratify the multiple application devices according to functional modules, write a preset device tree file, configure multiple child nodes one by one for the multiple stratified application devices, and configure multiple leaf nodes corresponding to the attribute information corresponding to the multiple stratified application devices, where one child node corresponds to one or more leaf nodes.

[0024] S1. Obtain a signal request to be configured through a preset device tree, and parse the format of the signal request to be configured according to the type of the preset device tree to obtain an execution signal, an execution mode, and a processing priority. The signal request to be configured includes but is not limited to a hardware resource address, a signal format, and a device identifier.

[0025] In this embodiment, the construction process of the preset device tree is specifically as follows: constructing a device tree, the device tree includes a root node, multiple child nodes and multiple leaf nodes, wherein the root node represents the top level of the hardware system, the multiple child nodes represent multiple application devices, and the multiple leaf nodes represent multiple specific hardware attributes of the application devices; the multiple child nodes are layered according to functional modules, and the processing priority of each layer is set to form a pyramid-shaped preset device tree.

[0026] In this embodiment, data conversion or protocol conversion is performed on the signal format of the signal request to be configured so that the signal request to be configured is converted into an execution signal that can be processed by a preset device tree; and an execution mode and a processing priority are assigned to the signal request to be configured based on the hardware resource address and the device identifier.

[0027] It should be noted that, specifically in the Linux system, obtaining signals from multiple device trees is a complex process. Different device trees represent different hardware architectures or device collections, and the sources of signals are diverse. For example, for a system that contains both ARM architecture and PowerPC architecture devices, the device tree describes the information of the devices under these two architectures respectively. When obtaining signals from the hardware represented by the device tree, it may be through interrupts, I / O ports, memory mapping and other methods. For example, for some sensor devices, it may be a simple binary code to represent the measured value, accompanied by device identification information. In the signal acquisition stage, the parameters include the hardware resource address of the device (such as register address, I / O port number), the data format of the signal (such as encoding method), and the device identification (such as the node name or ID in the device tree). These parameters determine how to correctly obtain signals from the device. Signal processing is a key link in the adaptation process. For signals obtained from different device trees, format parsing is required. Taking sensor data as an example, if the sensor represents the temperature value in the form of binary complement, the Linux system needs to convert it into a meaningful decimal value. In addition, signals in different device trees may need to be integrated or converted. For example, in an industrial control device tree containing multiple sensors and actuators, the signals of multiple temperature sensors and pressure sensors may need to be aggregated and averaged to obtain more reliable environmental parameter values. Protocol conversion is also required for interactive signals between different types of device trees (such as control signals from sensor device trees to actuator device trees). In this process, parameters are gradually converted from original signal format-related parameters (such as encoding, data length) to parameters that can be processed by the application layer (such as temperature values, pressure values, etc. after conversion and processing, as well as control instruction format-related parameters for device-to-device interaction). The hierarchical structure of the device tree also plays an important role in signal processing. High-level device trees may define system-level parameters, such as data processing priorities. If a device tree represents a critical device (such as a security monitoring device), its signal processing may be given a higher priority, and the signal processing process needs to determine the processing order and resource allocation based on these hierarchical parameters.

[0028] In this embodiment, the device tree can be layered based on the function, type, physical connection and other factors of the hardware. In an embedded system, it can be layered according to functional modules, such as a sensor module layer, a control module layer, a communication module layer, etc.

[0029] In this embodiment, after the code is layered by using the device tree, the hardware description part and the driver part are independent of each other and complement each other. The probability of driver line bugs caused by changing the hardware part code can be well avoided, and the portability of the same chip code is greatly increased. When the hardware configuration is the same, the code can be directly ported, and only the driver and application layer program need to be changed.

[0030] S2. Calling a driver corresponding to the execution signal from a preset driver database according to the device identification.

[0031] In this embodiment, a plurality of drivers corresponding to a plurality of application devices are configured and stored in a preset driver database, and a plurality of device identifiers are configured to correspond to a plurality of application devices one by one.

[0032] S3. Drive the corresponding application device to execute the operation according to the driver, execution mode and processing priority corresponding to the execution signal.

[0033] Specifically, the corresponding application devices are driven to perform operations in order from high to low according to the processing priority, one application device corresponds to one driver program, and one application device corresponds to one execution mode.

[0034] In this embodiment, it also includes: when the acquired signal to be configured requests a change, generating an execution constraint of the execution signal; when the execution signal exceeds the limit defined in the preset device tree, truncating the signal or reporting an error.

[0035] In this embodiment, the execution signal stage is to send the processed signal to the corresponding device to perform the operation. The execution method is different for devices in different device trees. Taking the actuator device as an example, such as the motor controller device, according to the control parameters (such as the speed setting value) obtained from the signal processing stage, the control signal is sent to the register of the motor controller through the device driver interface defined in the device tree to adjust the motor speed.

[0036] In this process, the parameters change again, from processed application layer parameters to device-specific control parameters. At the same time, other related parameters in the device tree will constrain the execution signal. If the execution signal exceeds the limits defined in the device tree, the system needs to handle it accordingly (such as truncating the signal or reporting an error).

[0037] In this embodiment, the root node of the device tree may contain system-level parameters, such as system clock frequency, power management mode, etc., which will affect the operation of the devices in the entire system. The parameters of the lower-level nodes are related to specific devices. For example, the parameters of the sensor nodes include measurement range, accuracy, sampling frequency, etc., and the parameters of the actuator nodes include operating range, response time, etc. The hierarchical structure of the device tree makes the parameters inherited and covered. For example, all sensors in a device tree branch may inherit the common parameters defined by the upper nodes (such as data transmission protocols), and can define specific parameters in their own nodes (such as their own measurement range). This correspondence between parameters and the device tree hierarchy provides a basis for signal acquisition, processing and execution, ensuring that the system can correctly adapt to devices in different device trees.

[0038] It should be noted that the device tree is a data structure that describes the hardware devices in the system. It uses a tree structure to describe board-level devices such as the number of CPUs, IIC, LED, SPI, and memory base address. When the device is initialized during the boot phase of the operating system, the hardware information in the data structure is detected and passed to the operating system. When using the device tree, it is necessary to understand the hardware configuration of the platform and the system operating parameters, and then write this information into the device tree source code DTS file. The main function of the DTS file is to describe the board-level hardware information according to the information recorded in the corresponding data structure. In the device tree, a device is described by a node containing a compatible attribute, and a parent node containing a group of device nodes represents the bus. The device tree source code is compiled into a binary file DTB suitable for machine processing. When the system starts, the startup parameters can copy the device tree stored in the flash to the memory and pass the starting address of the DTB to the kernel of the operating system. In this way, when using the single board in this hardware state, you only need to load the previously compiled DTB file to complete the corresponding hardware configuration. The device tree is mainly composed of two elements, Node and Property. In the device tree, the number and type of CPUs, memory base address and size, buses and bridges, peripheral connections, interrupt controllers and interrupt usage, GPIO controllers and GPIO usage can be described. Each hardware device can be described by a node, for example:

[0039] Led{

[0040] Compatible="A","B","C";

[0041] };

[0042] It means that there may be 3 drivers in the kernel that support this LED. When the kernel starts, it will find the corresponding driver for this LED in the order of A, B, and C. There is also a compatible attribute under the root node to select which "machine desc". After the kernel starts, it will find the corresponding machine desc structure according to the compatible attribute of the root node and execute the initialization function in it.

[0043] The DTB file mainly contains struct fdt_header: the header of DTB, which mainly describes some basic information of the device tree, such as the size of the device tree and the offset address of the structure block; memory reservation block: the memory reservation information block defines the reserved memory information in the device tree; structure block: the device tree structure block is a linear structure, which is the main body of the device tree and saves the device information on the target board in the form of node. The Linux kernel will parse the DTB file when it starts, and then generate the corresponding device tree node file in the / proc / device-tree directory. The DTB file is a binary file that can be recognized by the kernel and uboot. The tool that compiles dts into dtb files is dtc. The scripts / dtc directory in the Linux source code directory contains the source code of the DTC tool. In addition to providing the DTC tool in the scripts / dtc directory of Linux, you can also install the DTC tool yourself. In Linux, execute: sudo apt-get installdevice-tree-compiler to install the DTC tool. It also provides a fdtdump tool that can decompile DTB files. The modified device tree is compiled by directly executing the make DTBS command in the device tree source code directory, and the .dtb file is obtained in the arch / arm / boot / dts directory. The command for compiling the device tree is different for each manufacturer's SDK. The information of the loaded module is the hardware information in the device tree that we finally parse, and we can apply for and initialize related resources based on this information. First of all, the device tree describes hardware resources in a tree structure. For example, the local bus is the trunk of the tree, which is called the root node in the device tree, and the spi, iic, and uart buses mounted on the local bus are the branches of the tree, which are sub-nodes of the root node in the device tree. These sub-nodes can be divided according to the specific situation, so that a complete device tree suitable for this link can be formed.

[0044] A device tree file references another device tree file, which can achieve code portability and reusability. If the main control chip used by multiple hardware platforms is the same, the device tree file can be directly used for hardware configuration.

[0045] In the device tree, a device is represented by a node with a compatible attribute, and a bus is represented by a parent node containing a group of device nodes. In most cases, the device tree is the only way for the firmware to communicate data with the kernel, so it is also used to pass real-time or configuration data to the kernel, such as kernel parameters, the address of the initrd image, etc. Most of this data is contained in the / chosen node of the device tree: the bootargs attribute contains the kernel parameters, and the initrd-* attributes define the first address and size of the initrd file. The chosen node may also contain any number of attributes that describe platform-specific configuration.

[0046] In the early initialization stage, before the page table is established, the code related to the architecture initialization will use different auxiliary callback functions to call of_scan_flat_dt to decode the device data multiple times.

[0047] of_scan_flat_dt traverses the device tree and uses helper functions to extract the required information.

[0048] The early_init_dt_scan_chosen auxiliary function is used to parse the chosen node including kernel parameters: the early_init_dt_scan_root auxiliary function is used to initialize the address space model of the device tree; the early_init_dt_scan_memory auxiliary function is used to determine the size and address of available memory.

[0049] On the ARM platform, the setup_machine_fdt function is responsible for early device tree traversal after selecting the correct machine_desc structure. After board identification and early configuration data parsing, the kernel is further initialized. During this period, the unflatten_device_tree function is called to convert the device tree data into a more efficient real-time form. At the same time, the machine's special startup hook functions will also be called, such as the init_early function, init_irq function, init_machine function, etc. in machine_desc.

[0050] Using the device tree does not change the behavior and functionality of these functions. If the device tree is provided, then either init_early or init_irq can call any device tree lookup function to obtain additional platform information. However, the init_machine function requires more attention. In the arch / armmach-exynos / mach-exynos4-dt.c file, the init machine function has the following statement:

[0051] of_platform_populate(NULL,of_default_bus_match_table,NULL,NULL);

[0052] The function of_platform_populate is to traverse the nodes in the device tree, convert the matching nodes into platform devices, and then register them in the kernel.

[0053] Specifically, edit the .dts file according to the soc and the mounted peripherals. The file directory of arm is in linux / arch / arm / boot / dts / ... After editing, a dtb file will be generated when compiling the kernel. Burn the dtb file to the boot medium, such as the fixed address of the EMMC storage chip. For operating systems such as servers, it is under the / boot directory. When the boot tool starts the kernel, it will load this file into the memory and tell the kernel the memory address, so that the kernel can read the dtb file. When the kernel starts, it will parse the dtb file through the unflatten_device_tree() device tree parsing core function. Its subfunction unflatten_dt_node() will parse each description into a device_node structure, and finally all device_nodes will be stored in the global variable of_allnodes. The kernel converts the soc controller device in device_node of_allnodes into a platform device platform_device and mounts it on the platform bus. After the kernel starts executing, it will migrate the device nodes in of_allnodes to platform devices through the of_platform_populate() platform device migration function for the initialization of the platform driver. The driver uses platform_device to read the initialization parameters in it to complete the initialization, and cannot directly use device_node. Of course, peripheral drivers outside the platform driver can obtain initialization parameters through device_node. The kernel loads the device tree when it starts. The device tree describes the structure and characteristics of the hardware device, including each device node and its attributes. The kernel starts parsing according to the root node in the device tree. The root node is the top-level node in the device tree, usually represented by / . The kernel reads the compatible attribute of the root node, which contains the type and compatibility information of the device. The kernel traverses the list of loaded drivers and tries to match the compatible attribute of the root node. If a matching driver is found, the kernel initializes the device by calling the initialization function in the driver. The initialization function of the driver reads the device-related attributes in the device tree to initialize and configure the device.

[0054] In this embodiment, from the hardware-related original parameters in the signal acquisition stage to the format conversion, data integration and conversion according to the device tree information in the signal processing stage, and considering the parameters related to the hierarchical structure, the application layer processable parameters are obtained. The parameters are constantly changed and adjusted throughout the process to achieve effective adaptation of the Linux system to multiple device trees and ensure the stable operation of the system under different hardware device environments.

[0055] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A method for hardware resource configuration based on a device tree, characterized in that: include: Obtain a signal request to be configured through a preset device tree, and perform format parsing on the signal request to be configured according to the type of the preset device tree to obtain an execution signal, an execution mode, and a processing priority, wherein the signal request to be configured includes but is not limited to a hardware resource address, a signal format, and a device identifier; Calling a driver corresponding to the execution signal from a preset driver database according to the device identification; The corresponding application device is driven to perform the operation according to the driver, execution mode and processing priority corresponding to the execution signal.

2. The method for configuring hardware resources based on a device tree according to claim 1, characterized in that: Also includes: When the acquired signal to be configured requests a change, an execution constraint for executing the signal is generated; when the execution signal exceeds the limit defined in the preset device tree, the signal is truncated or an error is reported.

3. The method for configuring hardware resources based on a device tree according to claim 1, characterized in that: The construction process of the preset device tree is specifically as follows: Build a device tree, which includes a root node, multiple child nodes, and multiple leaf nodes. The root node represents the top layer of the hardware system, the multiple child nodes represent multiple application devices, and the multiple leaf nodes represent multiple specific hardware attributes of the application devices. Multiple sub-nodes are layered according to functional modules, and the processing priority of each layer is set to form a pyramid-shaped preset device tree.

4. The method for configuring hardware resources based on a device tree according to claim 3, characterized in that: The format of the configuration signal request is parsed according to the type of the preset device tree to obtain the execution signal, execution mode, and processing priority, specifically including: Performing data conversion or protocol conversion on the signal format of the signal request to be configured, so that the signal request to be configured is converted into an execution signal that can be processed by the preset device tree; An execution mode and a processing priority are assigned to the signal request to be configured based on the hardware resource address and the device identifier.

5. The method for configuring hardware resources based on a device tree according to claim 1, characterized in that: The preset driver database is configured to store a plurality of driver programs corresponding to a plurality of application devices one by one, and a plurality of device identifiers are configured to correspond to a plurality of application devices one by one.

6. The method for configuring hardware resources based on a device tree according to claim 3, characterized in that: Before obtaining the signal request to be configured through the preset device tree, it also includes: Acquire multiple application devices to be configured and attribute information corresponding to the multiple application devices, wherein the attribute information includes but is not limited to the type, compatibility, and resource requirements of the device; Multiple application devices are layered according to functional modules, a preset device tree file is written, multiple child nodes are configured one by one for the multiple layered application devices, multiple leaf nodes are configured for the attribute information corresponding to the multiple layered application devices, and one child node corresponds to one or more leaf nodes.

7. The method for configuring hardware resources based on a device tree according to claim 1, characterized in that: The method of driving the corresponding application device to perform the operation according to the driver, execution mode and processing priority corresponding to the execution signal is specifically: driving the corresponding application device to perform the operation in the order corresponding to the processing priority from high to low, one application device corresponds to one driver, and one application device corresponds to one execution mode.

Images