A method for describing Linux user-mode board-level information

Abstract

This invention discloses a method for describing Linux user-mode board-level information. It innovatively employs a structured syntax and a corresponding parser and device tree detector, supporting user programs in sequentially initializing the board-level resources they need to manage. This method is applicable to all processor-equipped devices. The solution provided by this invention can reduce redundant code, improve the development efficiency of new BSP models, and also meet the needs of multiple user processes in multi-process systems that require reading device board-level information.

Description

Technical Field

[0001] This invention relates to software system technology, specifically to the description and initialization technology of device board-level resources in software systems. Background Technology

[0002] In some application scenarios, while Linux user-space programs may not be concerned with the hardware details of all board-level resources, they do need to be aware of the bus topology or other resources not managed by the Linux kernel in the board-level space. They then need to create data structures to manage these board-level resources in the Linux user-space environment. When multiple Linux user-space processes require board-level information, and the information needed by each process is different, a different BSP library describing the board-level resources must be provided for each process. This approach leads to the following two problems:

[0003] 1. The code is redundant and the development efficiency is low.

[0004] 2. When the bus topology in board-level resources is too complex, Linux user programs have difficulty handling the dependencies within the bus topology. Therefore, the sequential initialization process of the bus topology should also be placed in the BSP library. Initializing the bus topology depends on libraries of other modules. If BSP libraries under different processes are managed in the same BSP package, then other packages using the BSP package will also have these dependencies, which can easily lead to circular dependencies. Summary of the Invention

[0005] To address the problems existing in the management of board-level resources in Linux user space, the present invention aims to provide a method for describing board-level information in Linux user space. This solution is based on the concept of device tree in the Linux kernel, innovatively providing a structured syntax, and then using a parser and detector for corresponding parsing and detection, thereby enabling the initialization of board-level resources in user space, thus effectively solving the problems existing in the prior art.

[0006] To achieve the above objectives, the present invention provides a method for describing Linux user-mode board-level information, which describes static information in board-level resources based on structured configuration files, and defines nodes, node attributes, node trees, and node depths based on the syntax of structured configuration files.

[0007] The node is used to describe a hardware resource, and the method describes one node in each single-layer structure;

[0008] The node attributes are used to describe the attributes of a node. The method describes a node attribute in each single-layer structure using a set of key-value pairs. A node can contain several node attributes.

[0009] The node tree is a collection of nodes, and the topology between nodes is represented by a tree structure. In the multi-layer structure, the outer layer structure represents the parent node.

[0010] The node depth is used to record the distance of a node from the root node in the node tree. In this method, the depth of a child node is the depth of its parent node plus 1.

[0011] Furthermore, the node has a node name, followed by a single-layer structure identifier.

[0012] Furthermore, the method uses a pair of curly braces "{}" to identify a single-level structure when defining nodes.

[0013] Furthermore, when defining a node tree, the method states that a node has one or more pairs of curly braces “{}” within a pair of curly braces “{}”, indicating that the node has one or more child nodes.

[0014] Furthermore, the node attributes include general attributes and private attributes, both of which are described using key-value pairs.

[0015] Furthermore, each node has a node index, which allows the node's location to be searched within the structured configuration file.

[0016] Furthermore, the bus topology in the board-level resources can be described not only through the arrangement of multi-layer structures in the structured configuration file, but also through node attributes.

[0017] Furthermore, all attributes of the node can be copied to another node in the same structured configuration file via a reference statement.

[0018] Furthermore, both the reference statement and the key-value pair statement are used within the single-level structure of the current node, and can be used simultaneously.

[0019] Furthermore, the structured configuration file is parsed by a parser implemented in C code. This parser parses the configuration file according to the requirements of structured syntax, and the parsed node attributes are saved to the device tree in memory.

[0020] Furthermore, the parser supports configuring attribute inheritance rules, which are used in the parsing process to inherit specific attributes of a specific type of node to its descendant nodes of a specific type.

[0021] Furthermore, the sources of the parsed node attributes include: reference statements and key-value pair statements in the structured configuration file, as well as inheritance rules configured in the parser.

[0022] Furthermore, the different sources of the node attributes have different priorities. When attributes are the same, the attribute obtained through inheritance rules has the lowest priority and can be overridden by key-value pair statements and reference statements; while when attributes are obtained through key-value pair statements and reference statements, the later statement has higher priority and can overwrite the attribute described by the earlier statement.

[0023] Furthermore, each node in the device tree has a unique device tree path, which can be used to search for the corresponding node in the device tree.

[0024] Furthermore, the structured configuration file defines a device tree path mounting node, which is used by the parser to calculate the device tree path of the child nodes of the current node. The order of the paths at each level is the same as the order in which the structured configuration file is traversed from front to back.

[0025] Furthermore, the parsed node attributes include special attributes used by the detector to determine the driver program that the node needs to mount.

[0026] Furthermore, the detector uses a depth-first algorithm to traverse the nodes in the device tree, and during the traversal, it attaches a driver to the node and calls the initialization process within the driver to initialize the node.

[0027] Furthermore, during the process of the detector traversing the nodes, it is possible to specify whether a certain type of node needs to have its driver mounted and whether the initialization process within the driver is called to initialize the node.

[0028] The solution provided by this invention enables user processes to obtain board-level information and complete the initialization of board-level resources in user space; the solution provided by this invention is applicable to all devices with processors.

[0029] The solution provided by this invention offers complete board-level information in the form of a structured configuration file, supporting simultaneous access by multiple user processes. Each process only needs to focus on the parts it needs to focus on, reducing redundant code.

[0030] The solution provided by this invention provides complete board-level information in the form of a structured configuration file, which is then parsed by the code and recorded in memory to form a tree structure of device nodes. Finally, the detector is initialized sequentially according to the bus topology and device node type. Therefore, the application no longer needs to use the bsps package, avoiding the circular dependency problem that may occur due to the use of the bsps package. Attached Figure Description

[0031] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0032] Figure 1This is a flowchart illustrating the process by which the parser generates a device tree in memory based on a structured configuration file in this invention.

[0033] Figure 2 This is a flowchart illustrating the process of initializing nodes in the device tree by the detector in this invention.

[0034] Figure 3 This is a diagram showing the board-level information of the device in this invention example;

[0035] Figure 4 This is an abstract model of the device tree constructed in memory in an example of the present invention. Detailed Implementation

[0036] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to specific illustrations.

[0037] This invention is based on the mechanism of the device tree in the Linux kernel, and provides an innovative structured syntax and parser, device detector, and achieves support for initialization of board-level resources in user space through the organic cooperation between the structured syntax and parser and device detector.

[0038] Specifically, the present invention provides a method for describing board-level information in Linux user space. This method describes static information in board-level resources based on structured configuration files, and further defines nodes, node attributes, node trees, and node depths based on the syntax of structured configuration files.

[0039] The node here is used to describe a hardware resource. In this scheme, one node is described in each single-layer structure.

[0040] The node attributes here are used to describe the properties of a node. In this scheme, a set of key-value pairs in each single-layer structure describes a node attribute, and a node can contain several node attributes.

[0041] The node tree here is specifically a collection of nodes, which represents the topology between nodes in a tree structure. In this scheme, the outer layer represents the parent node in a multi-layer structure.

[0042] The node depth here is used to record the depth of a node from the root node in the node tree. In this scheme, the depth of a child node is the depth of the parent node plus 1.

[0043] The above definitions provide a convenient way to describe board-level resource nodes and the topology between them.

[0044] The implementation of the present invention will be described in detail below.

[0045] For each node defined in this scheme, the node has a node name, followed by a pair of curly braces "{}" as an identifier, starting from "{" and ending with "}", and the content in between is the node's attributes.

[0046] In this scheme, when defining a node tree, a pair of curly braces "{}" within a node contains one or more pairs of curly braces "{}", indicating that the node has one or more child nodes. This notation visually expresses the parent-child relationship between nodes.

[0047] In this scheme, node attributes are divided into general attributes and private attributes, both of which are described using key-value pairs.

[0048] The general attributes here are used to describe key information such as node type, and different node types require different processing. Private attributes, on the other hand, refer to attributes that are private to a specific node type. These can be flexibly added to the configuration file, and retrieved during parsing. This division ensures that some key information is processed using general methods, while private attributes guarantee the flexibility of node attribute processing.

[0049] As an example, the key-value pair statement here is formatted as "KEY=VALUE", where KEY is the attribute name and VALUE is the attribute value. Each key-value pair statement ends with a semicolon ";".

[0050] Therefore, the bus topology in board-level resources can be described not only through the multi-layered arrangement of a structured configuration file, but also through node attributes. The former provides a more intuitive and human-readable description, while the latter increases flexibility and scalability.

[0051] In this scheme, each defined node has a node index, which allows the node's location to be searched within the structured configuration file.

[0052] As an example, the node index here is a multi-level index, with each level being the node name of each node. The order of the indexes is the same as the order in which the structured configuration file is traversed from front to back. Each level of index is separated by a colon ":".

[0053] Furthermore, all key-value pairs within a node can be copied to another node in the same structured configuration file via a reference statement. Since multiple nodes of the same type share most of their attributes, allowing the copying of node attributes reduces redundancy in the configuration file.

[0054] As an example, the format of the citation statement here is "&NODE_INDEX", where NODE_INDEX is the node index of the referenced node, and each citation statement ends with a semicolon ";".

[0055] Furthermore, both the quoting statements and key-value pair statements here are used within the single-level structure of the current node.

[0056] For the structured configuration files defined above, this solution uses a corresponding parser for parsing. This parser is implemented in C code and parses the configuration file according to the requirements of structured syntax, saving the parsed node attributes to the device tree in memory.

[0057] Furthermore, the parser supports configuring attribute inheritance rules, which are used in the parsing process to inherit specific attributes of a specific type of node to its descendant nodes of a specific type.

[0058] The sources of the parsed node attributes here include: reference statements and key-value pairs in the structured configuration file, as well as inheritance rules configured in the parser.

[0059] Furthermore, in this scheme, node attributes have different priorities based on their different sources. This stipulation ensures that when node attributes have different sources, one of them is selected according to its priority.

[0060] Specifically, when attributes are the same, the attribute obtained through inheritance rules has the lowest priority and can be overridden by key-value pair statements and reference statements; while when obtaining attributes through key-value pair statements and reference statements, the later statement has higher priority and can overwrite the attribute described by the earlier statement.

[0061] Furthermore, each node in the device tree here has a unique device tree path, which can be used to search for the corresponding node in the device tree. This setting facilitates the addressing of device nodes.

[0062] As an example, the device tree path here is multi-level. Except for the root node, which is identified by " / ", the names of the paths at each level of the other nodes are the node names, and the paths at each level are separated by " / ".

[0063] In this application, a device tree path mounting node is also defined in the structured configuration file. This node is used by the parser to calculate the device tree paths of the child nodes of the current node. The order of the paths at each level is then the same as the order in which the structured configuration file is traversed from front to back. This configuration ensures that each node has a corresponding relative path under the device tree mounting node, facilitating addressing.

[0064] In this application, the node attributes parsed by the parser include special attributes for the detector to determine the driver that the node needs to be mounted.

[0065] It should be noted that the driver here refers not only to the driver of the physical device, but also to the initialization process of the logical data structure.

[0066] Based on the parser's completion of the parsing of the structured configuration file, this application further uses a depth-first algorithm through a device tree detector to traverse the nodes in the device tree, and during the traversal, mounts the driver to the node and calls the initialization process within the driver to initialize the node.

[0067] As a preferred solution, this scheme allows specifying whether certain types of nodes need to have their drivers mounted and their initialization processes called during the node traversal process. This setting facilitates addressing intermediate nodes that only require a path for traversing the node hierarchy; these intermediate nodes may already have their drivers mounted and initialized, or they may not require drivers at all.

[0068] See Figure 1 The diagram illustrates an example flow of the parser parsing a structured configuration file in the present invention.

[0069] Combination Figure 1 As shown, the processing flow of this solution for parsing structured configuration files using a parser is as follows:

[0070] ① Open the structured configuration file in read-only mode, and move the read pointer to the root node of the tree that needs to be parsed in the structured configuration file. The root node becomes the current node, with a node depth of 1, and its parent node's device tree path defaults to " / ".

[0071] ② Create an empty inheritance record table.

[0072] ③ The device tree path of the current node is formed by adding the device tree path of the parent node to the node name of the current node, and then cached in the node information.

[0073] ④ Cache the attributes that can be inherited by the current node in the inheritance record table to the node information.

[0074] ⑤ Process key-value pairs within the current node to retrieve attribute names and values. In this process, common attributes will be parsed, and the parsed data will be cached in the node information; while the node's private attributes will be directly cached in the node information.

[0075] ⑥ Determine if the current node is a device tree path mount node. If the current node is a device tree path mount node, proceed to step ⑨; otherwise, continue to step ⑦.

[0076] ⑦ According to the inheritance rules configured in the parser, add the attributes of the current node that can be inherited by descendant nodes and the node depth of the current node to the inheritance record table.

[0077] ⑧ Save all cached node information from the preceding process to the device tree in memory. Then, proceed to step ⑩.

[0078] ⑨ Modify the device tree path of the current node.

[0079] ⑩ The read pointer continues to move forward, stopping when it reaches a child node or when the current node has been scanned.

[0080] Determine the reason why the scan stopped. If a child node was detected, continue the steps. If the current node has been scanned, proceed to step [step name].

[0081] Calculate the node depth of the child node (the node depth of the current node plus 1), and pass the node depth of the child node and the device tree path of the current node as input parameters into the node processing flow. Then, the child node becomes the current node. After that, jump to step ③.

[0082] The parent node of the current node becomes the current node, and expired entries are removed from the inheritance record table. The deletion principle is that if the node depth of an entry is greater than the node depth of the current node, the entry must be deleted.

[0083] Determine if the tree has been completely scanned. If it has, end the parsing; otherwise, proceed to step 10.

[0084] See Figure 2 The diagram shown is a flowchart illustrating how the detector in this application uses a depth-first traversal algorithm to traverse the nodes in the device tree and initialize nodes of a specified type.

[0085] As shown in the figure, the present invention employs a detector to traverse the nodes in the device tree using a depth-first search algorithm, and initializes nodes of a specified type as follows:

[0086] ① Create an initialization set (the set is of node type (compatible)) and pass the set to the detector.

[0087] ② Locate the root node in the device tree and set it as the current node.

[0088] ③ Determine if the node type of the current node is in the initialization set. If it is, continue to step ④; otherwise, jump to step ⑥.

[0089] ④ Determine if the current node has a matching driver. If a matching driver is found, continue to step ⑤; otherwise, jump to step ⑥.

[0090] ⑤ Attach the driver to the node and initialize the node using the initialization process in the driver.

[0091] ⑥ Determine if the current node has child nodes. If it does, proceed to step ⑩; otherwise, continue to step ⑦.

[0092] ⑦ Determine if the current node has sibling nodes. If it does, proceed to step ⑩; otherwise, continue to step ⑧.

[0093] ⑧ Determine if the current node is the root node. If the current node is the root node, end the traversal; otherwise, continue to step ⑨.

[0094] ⑨ The parent node of the current node becomes the current node, and then jump to step ⑦.

[0095] ⑩ The child node or sibling node of the current node becomes the current node, and then jump to step ③.

[0096] The following will describe the Linux user-mode board-level information description scheme provided by this invention. Figure 3 Taking the board-level information described in the figure as an example, the board-level resources are described using the structured configuration file in this invention. The parsing process of the parser for the structured configuration file and the initialization process of the detector for the board-level resources in this invention are illustrated by example.

[0097] First of all Figure 3 In this example, the device information is briefly described as follows:

[0098] 1. The I2C controller is simulated via GPIO and is driven by a driver in kernel mode, providing " / dev / i2c0" for user programs to perform I2C read and write operations.

[0099] 2. GPIO device A has 12 pins and is accessed via I2C at address 0x20. Its driver is implemented in user space. GPIO device A needs to be initialized after the I2C controller has been initialized. During initialization, pins 0 and 1 are configured to output low.

[0100] 3. GPIO device B is of the same type as GPIO device A, with I2C address 0x21. GPIO device B needs to be initialized after the I2C controller has been initialized. During initialization, PIN0 and PIN1 are configured as inputs.

[0101] 4. Power supply device: The user program needs to monitor its presence and operating status. These two status signals are acquired through PIN0 and PIN1 of GPIO device B, respectively. The power supply device is initialized after GPIO device B is initialized.

[0102] 5. A network port is an abstract unit containing multiple physical devices used to provide services to upper-layer protocols. The network port needs to be aware of the `phy-unit` and `phy-port` attributes of the switch and PHY. The network port should be initialized only after the switch and PHY have been initialized.

[0103] 6. switch, a switching chip, belongs to the network port.

[0104] 7.phy is the phy chip, belonging to the network port. Its phy-unit and phy-port attributes are the same as those of the switch.

[0105] Based on this, according to the bus topology dependencies in this example, Figure 3 The board-level resources in the document are described as follows:

[0106]

[0107]

[0108] In the above description, `compatible` is a general attribute used to identify the node type. Nodes where `compatible` is "mount" are device tree path mounting nodes, used by the resolver to calculate the device tree paths of the current node's child nodes.

[0109] The present-probe-gpio and present-probe-gpio-pin attributes in node-power describe how the power supply presence signal is obtained from pin 0 of GPIO device B.

[0110] Furthermore, the present-probe-gpio-ok attribute describes that the power supply is present when the PIN input is high; similarly, status-probe-gpio, status-probe-gpio-pin, and status-probe-gpio-ok are used to describe how the power supply's operating status is determined.

[0111] Furthermore, the user program calls the API (dts_node_inherit_rule_add) provided by the parser to add inheritance rules, and the parser allocates memory to save the added inheritance rules.

[0112] This example requires adding four inheritance rules, namely:

[0113] The "phy-unit" attribute of a net-interface type node can be inherited by a switch type node;

[0114] The "phy-port" attribute of a net-interface type node can be inherited by a switch type node;

[0115] The "phy-unit" attribute of a net-interface type node can be inherited by phy type nodes;

[0116] The "phy-port" attribute of a net-interface type node can be inherited by phy type nodes.

[0117] Based on the foregoing description and settings, in this example, the user program can parse the structured configuration file in this example by calling the API (dts_node_tree_parse) provided by the parser.

[0118] The following is combined with Figure 1 Let me explain the parsing process of the structured configuration file in this example:

[0119] 1. The parser executes step ①, finds the board tree, specifies the depth of the board root node as 1, and the parent node path as " / ".

[0120] 2. The parser executes step ②, in which a storage space (heap or stack) is allocated to manage the addition / deletion of inheritance record table.

[0121] 3. The parser executes step ③ to determine the device tree path of the current node "board" as " / board".

[0122] 4. The parser executes step ④. At this point, the inheritance record table is empty, and board does not inherit any properties.

[0123] 5. The parser executes step ⑤, starting to parse the board's general property `compatible` and private property `mount`. Since board is a device tree path mount node "mount", it jumps to step ⑨. In step ⑨, the device tree path of board is changed from " / board" to the value of the `mount` property " / ".

[0124] 6. The parser executes step 10, reading the pointer to the first child node of board, node-i2c-controller.

[0125] 7. Parser Execution Steps The scan stopped because a child node was encountered, so the following steps were executed. The process involves calculating the node depth of the node-i2c-controller to be 2 (the node depth of the board plus 1), and then passing the node depth of the node-i2c-controller and the device tree path " / " of the board as input parameters to the node-i2c-controller.

[0126] 8. After the parser executes steps ③④⑤⑥⑦⑧ in sequence, the generic property compatible and the private property adapter of node-i2c-controller will be saved to the device tree, and its device tree path is " / node-i2c-controller".

[0127] 9. The parser executes step 10 sequentially. Then, it begins processing the first child node of node-i2c-controller, node-gpio@A.

[0128] 10. After the parser executes steps ③④⑤⑥⑦⑧ in sequence, the general and private attributes of node-gpio@A will be saved to the device tree, and its device tree path is " / node-i2c-controller / node-gpio@A".

[0129] 11. The parser executes step 10 sequentially. The scan stopped after node-gpio@A was completed, so the process skips to the next step. step In the middle, it falls back to the parent node node-i2c-controller of node-gpio@A for processing. Since the current inheritance record table is empty, there are no inheritance table entries to delete.

[0130] 12. Parser Execution Steps Since the current tree has not been completely scanned, we jump to step 10 and scan the second child node of node-i2c-controller, node-gpio@B.

[0131] 13. Parser sequential execution steps Start processing the second child node of node-i2c-controller, node-gpio@B.

[0132] 14. After the parser executes steps ③ and ④, it determines that the device tree path of node-gpio@B is “ / node-i2c-controller / node-gpio@B”, and that there are no inheritable attributes.

[0133] 15. The parser executes step ⑤. In this process, when processing the first reference statement, the read pointer is first moved to the first key-value pair statement in node-gpio@A. Then, all key-value pair statements in node-gpio@A are parsed sequentially, and the parsed information is cached in node-gpio@B. Afterwards, the cached attributes of node-gpio@B are as follows:

[0134] Property name and property value (string format)

[0135] compatible gpio

[0136] pin-num 12

[0137] addr 0x20

[0138] out 0-0,1-0

[0139] Furthermore, after parsing the key-value pair statements in node-gpio@A, the read pointer is moved to the second key-value pair statement in node-gpio@B, and all key-value pair statements in node-gpio@B are parsed sequentially. Since the parser specifies that later key-value pair statements have higher priority, the `addr` attribute will be modified, and the `out` attribute will be deleted. The final cached attributes of node-gpio@B are as follows:

[0140] Property name and property value (string format)

[0141] compatible gpio

[0142] pin-num 12

[0143] addr 0x21

[0144] in 0,1

[0145] 16. After the parser executes steps ⑥, ⑦, and ⑧ in sequence, the general and private attributes of node-gpio@B will be saved to the device tree, and its device tree path is " / node-i2c-controller / node-gpio@B".

[0146] 17. The parser executes sequentially. (10) ⑩ After ⑩, the second child node of board, node-power, was scanned.

[0147] 18. The parser executes sequentially. Start processing the second child node of the board node, node-power.

[0148] 19. After the parser executes steps ③④⑤⑥⑦⑧ in sequence, the general and private attributes of node-power will be saved to the device tree, and its device tree path is " / node-power".

[0149] 20. The parser executes step 10 sequentially. ⑩ Then, begin processing the third child node of the board, node-net-interface.

[0150] 21. The parser executes step ③, determining the device tree path of node-net-interface as " / node-net-interface".

[0151] 22. After the parser executes steps ④, ⑤, and ⑥ in sequence, the attributes of the node-net-interface node cache are as follows:

[0152] Property name and property value (string format)

[0153] compatible net-interface

[0154] phy-unit 0

[0155] phy-port 1

[0156] 23. The parser executes step ⑦. In this step, the phy-unit and phy-port properties in node-net-interface match the pre-configured inheritance rules, so the following four entries will be added to the inheritance record table:

[0157] Node depth is inherited from node type. Node type attribute name and attribute value (string format) are also inherited.

[0158] 2net-interface switch phy-unit 0

[0159] 2net-interface switch phy-port 1

[0160] 2net-interface phy phy-unit 0

[0161] 2net-interface phy phy-port 1

[0162] 24. Parser sequential steps ⑧ and ⑩ Afterwards, the node information of node-net-interface is saved to the device tree, with the device tree path being " / node-net-interface", and the node depth of the first child node of node-net-interface, node-switch, is determined to be 3.

[0163] 25. After the parser executes step ③, it determines the device tree path of node-switch to be " / node-net-interface / node-switch".

[0164] 26. The parser executes step ④. In this step, the inheritance record table is queried to determine whether node-switch can inherit the phy-unit and phy-port attributes of node-net-interface.

[0165] 27. After the parser executes steps ⑤ and ⑥ sequentially, the attributes of the node-switch cache are as follows:

[0166] Property name and property value (string format)

[0167] compatible switch

[0168] phy-unit 0

[0169] phy-port 1

[0170] 28. The parser executes steps ⑦, ⑧, and ⑩ sequentially. ⑩ Afterwards, the node information of node-switch is saved to the device tree, with the device tree path being " / node-net-interface / node-switch", and the node depth of node-phy, the second child node of node-net-interface, is determined to be 3.

[0171] 29. After the parser executes steps ③④⑤⑥⑦⑧ in sequence, node-phy inherits the phy-unit and phy-port attributes of node-net-interface and saves the node information to the device tree, with the device tree path being " / node-net-interface / node-phy".

[0172] 30. The parser executes step 10 sequentially. Then, the read pointer stops at the end of node-net-interface, and the current node depth is 2.

[0173] 31. Parser sequential execution steps ⑩ The read / write pointer is currently at the end of the root node of the board, with a current node depth of 1. At this point, all entries in the inheritance record table with a node depth greater than 1 will be deleted. Specifically, the following four entries will be deleted, and the inheritance record table will eventually become empty.

[0174] Node depth is inherited from node type. Node type attribute name and attribute value (string format) are also inherited.

[0175] 2net-interface switch phy-unit 0

[0176] 2net-interface switch phy-port 1

[0177] 2net-interface phy phy-unit 0

[0178] 2net-interface phy phy-port 1

[0179] 32. Parser sequential execution steps ⑩ At this point, the read pointer stops outside the root node of the board tree, the board tree scan is complete, and the parsing process ends.

[0180] At this point, the structured configuration file scanning is complete, and the final structure is built in memory as follows: Figure 4 The device tree shown.

[0181] Next, the user program calls the API (dt_driver_add) provided by the detector to add the driver for the node with compatible values ​​of i2c-linux, gpio, power, net-interface, switch, and phy to the detector.

[0182] Next, the user program calls the API (dt_bus_probe) provided by the detector to begin traversing the device tree and initializing nodes of a specific type (compatible) in the device tree. Based on the initialization order requirements of each device and the traversal algorithm used by the detector, it is determined that the initialization of all nodes in the device tree can be completed in at least two traversals (i.e., two calls to dt_bus_probe). The first traversal processes nodes of type i2c-linux, gpio, switch, and phy, and the second traversal processes nodes of type power and net-interface.

[0183] The following is combined with Figure 2 and Figure 4 Here is a detailed explanation of the device tree traversal and node initialization process in this example:

[0184] 1. Execute step ①, pass the i2c-linux, gpio, switch, and phy initialization sets to the detector, and start the first traversal.

[0185] 2. The detector executes step ② and locates the root node " / " where all attributes are empty.

[0186] 3. The detector executes step ③ to determine that the root node is not in the initialization set.

[0187] 4. The detector executes step ⑥ to determine if the root node has child nodes. Then it executes step ⑩ to begin processing the first child node, node-i2c-controller.

[0188] 5. The detector executes step ③ to determine if node-i2c-controller is in the initialization set.

[0189] 6. The detector executes step ④ to determine if a matching driver exists for the node-i2c-controller.

[0190] 7. The detector executes step ⑤ to mount the matching driver to the node-i2c-controller and initialize the node-i2c-controller.

[0191] 8. After the detector executes steps ⑥⑩③④⑤ in sequence, the first child node of node-i2c-controller, node-gpio@A, has been initialized.

[0192] 9. The detector executes step ⑥ to determine that node-gpio@A has no child nodes. Then it executes step ⑦ to determine that node-gpio@A has a sibling node node-gpio@B.

[0193] 10. After the detector executes steps ⑩③④⑤ in sequence, node-gpio@B has been initialized.

[0194] 11. The detector sequentially executes steps ⑥ and ⑦ to determine that node-gpio@B has neither child nodes nor sibling nodes. Then it executes step ⑧ to determine that the current node node-gpio@B is not the root node.

[0195] 12. The detector executes step 9, and the parent node of node-gpio@B, node-i2c-controller, becomes the current node.

[0196] 13. The detector sequentially executes steps ⑦ and ⑩, and begins processing the sibling node node-power of the node-i2c-controller node.

[0197] 14. The detector executes step ③ and determines that node-power is not in the initialization set.

[0198] 15. The detector sequentially executes steps ⑥, ⑦, and ⑩ to begin processing the sibling node node-net-interface of node-power.

[0199] 16. The detector executes step ③ and determines that node-net-interface is not in the initialization set.

[0200] 17. The detector sequentially executes steps ⑥ and ⑩, and begins processing the first child node of node-net-interface, node-switch.

[0201] 18. After the detector executes steps ③, ④, and ⑤ in sequence, the node-switch has been initialized.

[0202] 19. The detector sequentially executes steps ⑥, ⑦, and ⑩ to begin processing the sibling node node-phy of node-switch.

[0203] 20. The detector executes steps ③④⑤ in sequence, and node-phy has been initialized.

[0204] 21. The detector sequentially executes steps ⑥, ⑦, and ⑧, and determines that the current node node-phy is not the root node.

[0205] 22. The detector executes step 9, and the parent node of node-phy, node-net-interface, becomes the current node.

[0206] 23. After the detector executes steps ⑦ and ⑧, it determines that the current node node-net-interface is not the root node.

[0207] 24. The detector executes step 9, where the root node of the node-net-interface becomes the current node.

[0208] 25. The detector executes steps ⑦ and ⑧, determines that the current node is the root node, and ends the first traversal.

[0209] 26. Execute step ①, pass the power and net-interface initialization sets to the detector, and start the second traversal. The traversal process is the same as the first traversal. node-power and node-net-interface are initialized in the second traversal.

[0210] Finally, all board-level resources on the device were initialized and can now provide services normally.

[0211] The above example provides complete board-level information in the form of a structured configuration file. The parser then constructs a device tree in memory based on the structured configuration file and pre-configured attribute inheritance rules. Finally, the detector performs driver mounting and sequential initialization of the nodes in the device tree according to the user program's requirements. This not only reduces redundant code but also improves the development efficiency of new device BSPs.

[0212] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for describing Linux user-mode board-level information, characterized in that, The static information in board-level resources is described based on structured configuration files, and nodes, node attributes, node trees and node depths are defined based on the syntax of structured configuration files. The node is used to describe a hardware resource, and the method describes one node in each single-layer structure; The node attributes are used to describe the attributes of a node. The method describes a node attribute in each single-layer structure using a set of key-value pairs. A node can contain several node attributes. The node tree is a collection of nodes, and the topology between nodes is represented by a tree structure. In the multi-layer structure, the outer layer structure represents the parent node. The node depth is used to record the depth of a node from the root node in the node tree. In this method, the depth of a child node is the depth of the parent node plus 1. The structured configuration file is parsed by a parser, and the parsed node attributes are saved to the device tree in memory; The parser parses the configuration file according to structured syntax to obtain the node attributes of board-level resource nodes. The sources of the parsed node attributes are: reference statements and key-value pairs in the structured configuration file, as well as the inheritance rules configured in the parser. Different sources of node attributes have different priorities. When attributes are the same, the attribute obtained through inheritance rules has the lowest priority and can be overridden by key-value pairs and reference statements. When obtaining attributes through key-value pairs and reference statements, the later statement has higher priority and can overwrite the attribute described by the earlier statement.

2. The method for describing Linux user-mode board-level information according to claim 1, characterized in that, The node has a node name, followed by a single-layer structure identifier.

3. The method for describing Linux user-mode board-level information according to claim 1, characterized in that, The node attributes include general attributes and private attributes, both of which are described using key-value pairs.

4. The method for describing Linux user-mode board-level information according to claim 1, characterized in that, Each node has a node index, which allows you to search for the node's location within the structured configuration file.

5. The method for describing Linux user-mode board-level information according to claim 1, characterized in that, The bus topology in board-level resources can be described not only through the multi-layered arrangement of the structured configuration file, but also through node attributes.

6. The method for describing Linux user-mode board-level information according to claim 1, characterized in that, All attributes of the node can be copied to another node in the same structured configuration file via a reference statement.

7. The method for describing Linux user-mode board-level information according to claim 6, characterized in that, Both the reference statement and the key-value pair statement are used within the single-level structure of the current node, and can be used simultaneously.

8. The method for describing Linux user-mode board-level information according to claim 1, characterized in that, Each node in the device tree has a unique device tree path, and the corresponding node can be found in the device tree by using the device tree path.

9. The method for describing Linux user-mode board-level information according to claim 1, characterized in that, The structured configuration file defines a device tree path mounting node, which is used by the parser to calculate the device tree path of the child nodes of the current node. The order of the paths at each level is the same as the order of unilateral traversal in the structured configuration file from front to back.

10. The method for describing Linux user-mode board-level information according to claim 1, characterized in that, The parsed node attributes include special attributes used by the detector to determine the driver program that the node needs to be mounted.

11. The method for describing Linux user-mode board-level information according to claim 10, characterized in that, The detector uses a depth-first algorithm to traverse the nodes in the device tree, and during the traversal, it attaches a driver to the node and calls the initialization process within the driver to initialize the node.

12. The method for describing Linux user-mode board-level information according to claim 11, characterized in that, During the process of the detector traversing the nodes, it is possible to specify whether a certain type of node needs to have its driver mounted during this traversal and call the initialization process within the driver to initialize the node.

Images