A modular integration method, system, storage medium and device of a device tree file

Abstract

This invention discloses a modular integration method, system, storage medium, and device for device tree files, belonging to the field of embedded system technology. The method includes: adding slot identifiers to the board device tree source file, synchronously updating the path references of the node(“path”) and the node handle reference of &nodeName; merging the board intermediate files with slot identifiers into the baseboard device tree source file; deduplicating child nodes with the same name after merging; resolving relative path references to absolute path strings; and finally cleaning up nodes with marked attributes. This invention realizes the process from board file preprocessing to final file generation, supports multi-board, multi-slot scenarios, automatically handles path references, node handle references, node deduplication, and marked node cleanup, significantly improving the generation efficiency and accuracy of device tree configuration.

Description

Technical Field

[0001] This invention relates to the field of embedded systems technology, and more particularly to a modular integration method, system, and apparatus for device tree files. Specifically, this invention relates to a method for automatically integrating the device tree description files of pluggable boards into the baseboard device tree description file in a modular hardware design scenario. Background Technology

[0002] A device tree is a data structure used to describe hardware resources. It is widely used in embedded Linux systems to pass hardware configuration information to the kernel, replacing traditional hard-coding methods. The source file describing the device tree is called a DTS (Device Tree Source) file, which uses a tree structure to describe the hardware information of board-level devices, such as the number of CPUs, memory addresses, bus interfaces, and peripherals.

[0003] In modern embedded system design, a modular design approach is often adopted to reduce R&D costs and shorten development cycles. This involves a single baseboard (backplane) paired with multiple pluggable functional boards. In this design approach, the baseboard's device tree describes a fixed hardware structure, while the device tree descriptions of each board vary depending on the board type and insertion slot.

[0004] Currently, there are several ways to integrate the board device tree into the baseboard device tree: (1) Manual editing or simple script processing. This is the most traditional method, in which engineers manually copy and paste the board device tree fragments to the corresponding positions in the baseboard device tree, or write simple sed or awk scripts to merge the text. This method has the following technical problems: low efficiency, in the case of multiple boards and multiple slots, manual merging is labor-intensive and prone to errors; path references become invalid, relative path references in the board device tree (such as node(“path”)) need to be converted to absolute paths after integration, manual processing is complicated and prone to omissions; node references (phandle) are prone to breakage, when a slot prefix is ​​added to the node name, when other nodes reference the node using &node_name, the original reference will become invalid, and the existing technology lacks an automatic update mechanism.

[0005] (2) Device Tree Overlay Technology. Device Tree Overlay (DTO) is a standard mechanism widely used in the Linux kernel and U-Boot, which allows device tree fragments (.dtbo) to be overlaid on the base device tree (.dtb) at runtime or compile time. For example, the ovmerge tool in the Raspberry Pi community can merge, flatten, and sort multiple overlay source files; Android's libufdt optimizes the merging efficiency of multiple .dtb files by building a non-flat device tree. This technical approach belongs to the category of "modular integration" as in this invention, but DTO technology mainly merges at the binary level (.dtb / .dtbo) or at compile time through fragment syntax. Developers need to manually write fragment files that conform to the overlay syntax specification (including / plugin / declarations, fragment@ nodes, and target-path, etc.), which increases the additional learning cost and coding workload, and is incompatible with the board DTS file format directly maintained by hardware engineers. Furthermore, the ability to handle references between overlay layers is limited. A single overlay layer typically cannot reference nodes defined in other overlay layers using the &node_name syntax. Overlay layer merging occurs during the compilation or runtime phase, rather than at the source file level. When multiple overlay layers define nodes with the same name, the DTC compiler will exit with an error (duplicate_node_names), lacking an automated node deduplication and conflict resolution mechanism. Overlay layer technology also cannot automatically handle custom relative path expressions used within the board (such as the node("path") syntax generated by some EDA tools), and it cannot synchronously update various references within the board after adding a namespace prefix.

[0006] (3) DTC Path Reference Extension Functionality. The Device Tree Compiler (DTC) itself supports label references (&label) and path references (&{ / full / path}) syntax. Open-source community patches have extended the path reference functionality, allowing direct use of the reference syntax in property definitions, which is then expanded into a complete path string at compile time. This technology addresses some of the "relative path to absolute path" requirements, but its implementation resides at the DTC compiler level and relies on developers explicitly declaring labels or using specific syntax. For non-standard expressions such as node("path") already existing in the board source files, DTC's path reference extension functionality cannot recognize or process them.

[0007] (4) Project management solutions based on intermediate formats such as JSON. Patent CN115544968B discloses a method compatible with multiple project device trees. By constructing a JSON configuration file, the source files of each project's device tree are compiled into binary device tree files, and then integrated into a total binary device tree file. U-Boot selects the corresponding device tree based on the hardware configuration during loading. This solution postpones the integration work to the compilation and loading stage, focusing on the unified packaging of multiple project images and runtime selective loading, rather than deep integration at the source file level. It does not involve source file-level processing such as node deduplication and path parsing.

[0008] (5) Device tree file processing auxiliary tools. There are also some device tree file processing tools in the industry, such as Xilinx Device Tree Generator (DTG) and OpenAMP's Lopper tool, which can automatically generate device trees from hardware description files or manipulate and verify device trees. These tools focus on automatically generating device trees from hardware designs, rather than modularly integrating existing, independently maintained device tree files from multiple boards into the baseboard file.

[0009] (6) Node deletion / cleanup related technologies. The device tree syntax itself supports the / delete-node / and / delete-property / commands to delete nodes and properties, which is a standard feature of the DTC compiler. However, this mechanism requires developers to explicitly declare the deletion target, cannot automatically identify and clean up temporary nodes with specific marked attributes (such as des), and does not support "promotion" operations (promoting the content of a marked node to its parent node and then deleting itself).

[0010] In summary, existing technologies offer solutions for merging device tree files, such as compiling and merging the DTS and Overlay DTS using the DTC compiler, or decoupling resource nodes from the core board and interface board. However, these solutions primarily focus on merging during the compilation phase or dynamic selection at runtime, lacking a comprehensive toolchain for automated, modular integration at the source file level in multi-board, multi-slot scenarios. They fail to systematically address a range of issues arising during source file integration, including namespace isolation, invalid path references, broken handle references, node redundancy, and residual marker nodes. Summary of the Invention

[0011] To address the problems existing in the prior art, the present invention aims to provide a modular integration method, system, and apparatus for device tree files, which can automatically integrate the device tree descriptions of multiple boards into the baseboard device tree according to the slot, and complete post-processing steps such as node deduplication, path parsing, and marker node cleanup to generate a device tree configuration file that can be used directly.

[0012] To achieve the above objectives, the present invention specifically provides the following technical solution: Solution 1: A modular integration method for device tree files, comprising the following steps: Step S1: Obtain at least one board device tree source file, add slot identifiers to each board device tree source file, and synchronously update the path reference and node handle reference in the attribute row during the process of adding slot identifiers to obtain the board intermediate file with slot identifiers; wherein, the path reference is a relative path expression of the form node(“path”), and the node handle reference is a phandle reference expression of the form &node_name; Step S2: Obtain the substrate device tree source file, and merge the intermediate file of the board with slot identifier into the substrate device tree source file to obtain the merged substrate intermediate file. Step S3: Perform node deduplication processing on the merged substrate intermediate file. Within each node, merge child nodes with the same name into one node to obtain the deduplicated substrate intermediate file. Step S4: Perform path parsing processing on the deduplicated substrate intermediate file, converting relative path references in the form of node(“path”) in the attribute into absolute path strings to obtain the path-parsed substrate intermediate file. Step S5: Perform marker node cleanup on the intermediate file of the substrate after path parsing, delete or promote marker nodes containing the DES attribute, and obtain the final target device tree file.

[0013] In this method, step S1 involves adding slot identifiers to the board device tree source file, specifically including: Step S1-1: Read each line of the board device tree source file and determine whether the current line is the starting line of the top-level node; Step S1-2: If the current row is the starting row of the top-level node, extract the node name and add the prefix "slotX-" before the node name, where X is the slot number; Steps S1-3: If the current line is an attribute line and contains a path reference in the form of node(“path”), then extract the first part of the node name in the path string, add the prefix before the first part of the node name, and reorganize the new line; Steps S1-4: If the current line is an attribute line and contains a node handle reference (phandle reference) in the form of &node_name, then add the prefix before the node_name and reorganize the new line; Steps S1-5: Output the processed lines to generate the intermediate file of the board with slot identifier.

[0014] In this method, step S2 specifically includes: Step S2-1: Parse the substrate device tree source file, construct the substrate node tree, and record the node name, start and end lines, indentation and parent node information of each node; Step S2-2: Parse the intermediate file of the board with slot identifier and extract the node name and content range of its top-level node; Step S2-3: For each of the board top-level nodes, find the target node with the same name that is located in the preset board node subtree in the baseboard node tree; Step S2-4: If the target node is found, calculate the base indentation inside the target node and the minimum indentation of the rows inside the board node. After adjusting the indentation, add the rows inside the board node to the additional row list of the target node. Step S2-5: Output the substrate device tree source file and insert the contents of its additional line list at the end of each node to obtain the merged substrate intermediate file.

[0015] In this method, step S3 specifically includes: Step S3-1: Parse the merged intermediate baseboard file and construct a node tree, where each node contains an attribute list and a list of child nodes; Step S3-2: Perform a post-order traversal of the node tree, first recursively process the child nodes, and then merge the direct child nodes of the current node. Step S3-3: When merging the direct child nodes of the current node, if a child node with the same name is found, all attributes and child nodes of the latter child node are transferred to the former child node, and the latter child node is deleted. Step S3-4: Output the processed node tree to obtain the deduplicated intermediate file of the substrate.

[0016] In this method, step S4 specifically includes: Step S4-1: Scan the deduplicated intermediate files of the substrate for the first time and construct a mapping table from node names to complete paths; Step S4-2: Scan the file a second time, searching for the node(“path”) pattern in each line; Step S4-3: If the pattern is found, extract the path string, separate the first part of the node name, and search for the complete path corresponding to the node name in the mapping table; Step S4-4: Obtain the parent path of the complete path and concatenate it with the remaining part of the path string to obtain a new absolute path string; Step S4-5: Replace the node(“path”) expression in the original line with the new absolute path string enclosed in double quotes, output the processed line, and obtain the intermediate baseboard file after path parsing.

[0017] In this method, step S5 specifically includes: Step S5-1: Parse the intermediate file of the substrate after path parsing and construct a node tree, where each node contains a pointer to its parent node; Step S5-2: Perform a post-order traversal of the node tree, processing the child nodes first, and then processing the current node. Step S5-3: If the current node contains the `des` attribute and does not contain other attributes or child nodes, then delete the node. Step S5-4: If the current node has a des attribute and contains other attributes and / or child nodes, then promote all attributes except the des attribute and all child nodes to their parent node, and then delete the node itself. Step S5-5: If the current node is the root node and has the des attribute, then only remove the des attribute; Steps S5-6: Output the processed node tree to obtain the final target device tree file.

[0018] Option 2: A modular integration system for device tree files, the system being used to implement the method, comprising: The prefix addition module is used to add slot identifiers to the board device tree source file and synchronously update the path references and node handle references in the attribute line; The merging module is used to merge the intermediate board file with slot identifier obtained by the prefix addition module into the baseboard device tree source file; The node deduplication module is used to merge child nodes with the same name within the files processed by the merging module. The path resolution module is used to convert relative path references to absolute path strings for the files obtained by the node deduplication module. The marker node cleanup module is used to delete or promote marker nodes with the 'des' attribute in the files processed by the path parsing module.

[0019] In this system solution, each module adopts dynamic memory allocation technology, which can handle device tree files with any number of rows; the modules pass input and output file names through command line parameters, which can be used in series to complete the whole process or used independently.

[0020] Solution 3: A modular integration device for device tree files, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0021] Option 4: A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0022] Compared with the prior art, the present invention has the following beneficial effects: (1) High degree of automation: Through multiple independent modular tools, a fully automated process from board file preprocessing to final file generation is realized, without the need for manual intervention, which greatly improves work efficiency.

[0023] (2) Supports multi-board and multi-slot scenarios: By adding slot prefixes and repeatable merging steps, it can flexibly handle complex scenarios where any number of boards are inserted into any slot. In contrast, DTO technology requires writing a separate overlay file for each board when dealing with multi-board scenarios, and it cannot automatically handle naming conflicts between boards.

[0024] (3) Maintain format correctness: All processing steps retain the original indentation and spaces to ensure that the output file conforms to the device tree syntax specification and can be directly used for compilation.

[0025] (4) Intelligent path reference processing: Through two scans and node path mapping, the relative path references inside the board are automatically converted into correct absolute paths, avoiding the tediousness and errors of manual modification. The custom expression of node(“path”) processed by this invention is a scenario that neither DTO technology nor DTC path reference extension function can cover.

[0026] (5) Support automatic updates of node references (phandle): Step S1 updates the &node_name reference synchronously when adding the prefix, ensuring the integrity and correctness of the reference relationship after modular integration, which is not available in the existing technology.

[0027] (6) Node deduplication optimization: Automatically merge child nodes with the same name to eliminate redundant nodes caused by multiple merges, making the final configuration concise and clear. This reflects a proactive problem-solving approach compared to the passive handling of errors and exits by the DTC compiler when dealing with nodes with the same name.

[0028] (7) Marked Node Cleanup: Automatically deletes or promotes DES attribute nodes used only for identification, so that the final file does not contain debugging or marking information, making it more suitable for production environments. In particular, the "promotion" operation is not disclosed in the prior art and is a creative extension of the device tree cleanup function.

[0029] (8) Modular design: The five tools have a single responsibility and can be flexibly combined through the command line. They can be used in series to complete the whole process or used individually to perform specific tasks, and have good scalability.

[0030] (9) Compatible with existing board file formats: This invention directly processes conventional device tree source files, without requiring developers to rewrite the board description to DTO format or any other specific format, which greatly reduces the migration cost of existing projects and can be quickly integrated into existing embedded development processes. Attached Figure Description

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

[0032] Figure 1 This is a flowchart of the modular integration method for device tree files according to an embodiment of the present invention; Figure 2 This is a flowchart of the prefix addition module processing in an embodiment of the present invention; Figure 3 This is a flowchart of the merging module processing according to an embodiment of the present invention; Figure 4 This is a flowchart of the node deduplication module processing according to an embodiment of the present invention; Figure 5 This is a flowchart of the path resolution module processing according to an embodiment of the present invention; Figure 6 This is a flowchart of the marker node cleanup module in an embodiment of the present invention. Detailed Implementation

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

[0034] The modular integration method for device tree files provided by this invention constitutes an automated pipeline from preprocessing of the board device tree source file to the generation of the final target device tree file through five ordered steps (steps S1 to S5). The logical relationships and data flow between each step are as follows: Figure 1 As shown.

[0035] Step S1 is the preprocessing stage of the board file.

[0036] This step receives at least one board device tree source file as input, adds slot identifiers (slot prefixes) to each board file, and synchronously updates two types of node references within the board file during the prefix addition process: path references in the form of node(“path”) and node handle references (phandle references) in the form of &node_name. After processing, an intermediate board file with slot identifiers is generated.

[0037] This step adds a slot prefix to the node while automatically scanning and updating the node(“path”) path reference and &node_name handle reference inside the board. On the one hand, it establishes clear namespace isolation for boards in different slots, avoiding node name conflicts when integrating multiple boards; on the other hand, by synchronously updating the references, it ensures the integrity of the internal reference relationship of the board after the namespace changes, preventing reference breakage.

[0038] Step S2 is the merging process stage.

[0039] This step receives the substrate device tree source file and one or more intermediate board files with slot identifiers generated in step S1. By parsing the substrate node tree structure, intelligently matching target nodes, and adjusting the indentation format, the contents of the intermediate board files are merged into the corresponding positions in the substrate file. After processing, the merged intermediate substrate file is generated.

[0040] This step generates a complete device tree source file containing the substrate and all board hardware descriptions by deeply integrating multiple files at the source file level, while preserving the indentation format and readability of the original files.

[0041] Step S3 is the node deduplication stage.

[0042] This step receives the merged intermediate substrate file generated in step S2, constructs a node tree and performs a post-order traversal, detecting and merging child nodes with the same name in the direct child node list of each node. After this step is completed, a deduplicated intermediate substrate file is generated.

[0043] This step employs a post-order traversal and attribute merging algorithm to actively detect and merge child nodes with the same name. This eliminates redundancy of child nodes with the same name that may occur due to the merging of multiple boards, ensuring that the final device tree file structure is concise and the node names are unique, thus avoiding duplicate node errors during subsequent compilation.

[0044] Step S4 is the path resolution processing stage.

[0045] This step receives the deduplicated intermediate substrate file generated in step S3 and employs a two-pass scanning strategy: the first pass constructs a mapping table from node names to complete paths, and the second pass searches for and replaces node(“path”) patterns, converting them into standard absolute path strings. After processing, the path-parsed intermediate substrate file is generated.

[0046] This step ensures that all path references effectively point to the target node in the final device tree by converting the custom relative path references used inside the board (commonly found in DTS files generated by specific EDA tools) into the correct absolute paths after integration.

[0047] Step S5 is the marker node cleanup phase.

[0048] This step receives the intermediate substrate file after path parsing generated in step S4. By parsing the node tree and performing a post-order traversal, it identifies marked nodes containing the `des` attribute and performs operations such as deletion, promotion, or attribute removal based on the node content. After processing, the final target device tree file is generated.

[0049] This step automatically removes temporary marker nodes introduced during the development and debugging phases for identification purposes, resulting in a cleaner and more professional device tree file that is suitable for direct compilation and deployment in production environments.

[0050] There are close data dependencies between the five steps described above: the output file of the previous step serves as the input file for the next step, forming a complete processing chain. This pipeline design allows developers to pause the process at any intermediate stage, review intermediate results, or intervene manually, greatly facilitating debugging and maintenance.

[0051] The following is combined Figures 2 to 6 Each step (i.e., sub-step) is explained in detail with specific implementation schemes.

[0052] Step S1 of this method is used to add slot identifiers to the board device tree source file and synchronously update the references. For example... Figure 2 As shown, this step specifically includes sub-steps S1-1 to S1-5: Step S1-1: Read each line of the board device tree source file and determine whether the current line is the starting line of the top-level node. Specifically, this step reads the input file line by line, skipping whitespace characters (spaces and tabs) at the beginning of each line. If the first character of the line after skipping whitespace is not whitespace and the end of the line contains "{", then the line is determined to be the starting line of the top-level node; otherwise, it is determined to be a non-top-level node starting line.

[0053] Step S1-2: If the current line is the starting line of the top-level node, extract the node name and add the prefix "slotX-" before the node name, where X is the slot number. The slot number X can be specified by the user via command-line parameters (e.g., "--slot=2"). For example, for the line i2c-interface {, extract the node name i2c-interface, add the prefix, and rewrite it as slot2-i2c-interface {.

[0054] Step S1-3: If the current line is an attribute line and contains a path reference in the form of node(“path”), then extract the first part of the node name from the path string, add the prefix to the first part of the node name, and reorganize the line. Specifically, this step uses a regular expression to match the node(“…”) pattern to extract the complete path string within the double quotes; then, the first part of the node name (i.e., the first node name in the path) is separated using “ / ” as the delimiter; after adding the prefix slotX- to this node name, it is reconstructed with the remaining part of the path, and finally reorganized into a new attribute line. For example, in the attribute line i2c-mux =node(“i2c-interface / device@0 / i2c-mux@0”);, the first part i2c-interface is extracted, the prefix is ​​added to become slot2-i2c-interface, and it is reorganized into i2c-mux = node(“slot2-i2c-interface / device@0 / i2c-mux@0”);.

[0055] Step S1-4: If the current line is an attribute line and contains a node handle reference (phandle reference) in the form of &node_name, then add the prefix before the node_name and reorganize the line. Specifically, this step identifies the node name immediately following the & symbol and inserts the prefix slotX- before that node name. For example, in the attribute line handle = <&i2c-interface>;, identify i2c-interface, add the prefix, and reorganize it into handle = <&slot2-i2c-interface>;.

[0056] Steps S1-5: Output the processed lines to generate the intermediate file of the board with slot identifiers. For lines that do not meet any of the above conditions (such as ordinary attribute lines, blank lines, and comment lines), output them as is.

[0057] Through the above sub-steps, step S1 completes the namespace isolation of the board nodes at the source file level and simultaneously maintains the validity of all references within the board, laying a correct foundation for the subsequent merging steps.

[0058] Step S2 of this method is used to merge the intermediate files of the board with slot identifiers into the baseboard device tree source file. For example... Figure 3 As shown, this step specifically includes sub-steps S2-1 to S2-5.

[0059] Step S2-1: Parse the substrate device tree source file, construct the substrate node tree, and record the node name, start and end lines, indentation, and parent node information of each node. Specifically, this step uses a stack data structure to parse the substrate file line by line. When a node start line (ending with "{") is encountered, the node name is extracted, its start line number is recorded, and the node is pushed onto the stack; when a node end line (a single "}") is encountered, the top node of the stack is popped, and its end line number is recorded. During this process, the indentation level of each node (determined by counting the number of leading whitespace characters) and its parent node pointer are recorded, ultimately constructing a complete node tree.

[0060] Step S2-2: Parse the intermediate file of the board with slot identifiers and extract the node name and content range of its top-level node. This step reads the intermediate file of the board line by line, identifies the starting line of the top-level node without indentation, extracts the node name, and records all the content lines of the node from the starting line to the corresponding ending line (excluding the starting and ending lines of the top-level node itself, only the internal lines are retained).

[0061] Step S2-3: For each of the board's top-level nodes, search for a target node with the same name located within a preset "board" node subtree in the baseboard node tree. Specifically, this step starts from the root node of the baseboard node tree and searches downwards for a node located under a node subtree named "board" (or other preset name) whose node name is the same as the top-level node name of the board. If found, mark the node as the target node; if not found, throw an error or skip merging the top-level node of the board as needed.

[0062] Step S2-4: If the target node is found, calculate the baseline indentation within the target node and the minimum indentation of the lines within the board node. After adjusting the indentation, add the lines within the board node to the additional line list of the target node. Specifically, this step first calculates the indentation of the existing lines within the target node, taking the minimum or most common indentation value as the baseline indentation; then, it calculates the minimum indentation value of the lines within the board node; calculates the difference between the two, and adjusts the indentation of each line within the board node (adding or removing spaces at the beginning of the line) to align it with the baseline indentation of the target node. The adjusted content lines are appended to the "additional line list" of the target node, ready to be inserted during output.

[0063] Step S2-5: Output the substrate device tree source file and insert the contents of the additional line list at the end of each node to obtain the merged substrate intermediate file. This step iterates through each line of the output substrate file. Before processing the end line ("}") of a node, it checks if the node has an additional line list; if so, it outputs the contents of the additional line list line by line before outputting the end line of the node. This ensures that the merged content is correctly placed inside the target node without damaging the structural integrity of the original node.

[0064] In this method, step S3 is used to perform node deduplication on the merged intermediate substrate file. For example... Figure 4 As shown, this step specifically includes sub-steps S3-1 to S3-4.

[0065] Step S3-1: Parse the merged intermediate baseboard file and construct a node tree. Each node contains an attribute list and a child node list. This step uses a stack parsing method similar to step S2-1, but the node tree data structure constructed here is richer: in addition to recording the name and parent node, each node also maintains an attribute list (attribute text stored line by line) and a child node list (child node pointers stored in the order of appearance).

[0066] Step S3-2: Perform a post-order traversal of the node tree, first recursively processing child nodes, and then merging the direct child nodes of the current node. Post-order traversal ensures that the merging work within all child nodes of a node has been completed before processing the merging problem of a certain node's child nodes, avoiding redundant processing.

[0067] Step S3-3: When merging the direct child nodes of the current node, if a child node with the same name is found, all attributes and child nodes of the latter child node are transferred to the former child node, and the latter child node is deleted. Specifically, this step uses a nested loop to traverse the child node list of the current node. For each child node A in the outer loop, the inner loop checks if there is a child node B with the same name as node A. If so, all attributes in B's attribute list are appended to A's attribute list, and all child nodes in B's child node list are appended to A's child node list in turn. After the transfer is complete, B is removed from the child node list of the current node.

[0068] Step S3-4: Output the processed node tree to obtain the deduplicated intermediate file of the substrate. This step re-serializes the processed node tree into text format according to the device tree syntax specification and outputs it to a file.

[0069] In this method, step S4 is used to perform path parsing processing on the deduplicated intermediate substrate file, converting relative path references into absolute path strings. For example... Figure 5As shown, this step specifically includes sub-steps S4-1 to S4-5.

[0070] Step S4-1: The first pass scans the deduplicated intermediate files of the substrate to construct a mapping table from node names to complete paths. This step reads the file line by line, using a stack to track the complete path of the current node. When entering a node, the node name is appended to the end of the current path (separated by " / "); when leaving a node, the node name is removed from the end of the current path. Whenever a complete node is parsed (i.e., after reading the beginning line of the node), the node name is used as the key and the current complete path as the value, and stored in the mapping table. Since step S1 adds a unique slotX- prefix to the top-level nodes of the board, each node name is unique globally, and the mapping table will not cause ambiguity.

[0071] Step S4-2: Scan the file a second time, searching for the node(“path”) pattern in each line. This step restarts reading from the beginning of the file, using regular expressions to match strings in the node(“…”) format for each line.

[0072] Step S4-3: If the pattern is found, extract the path string, separate the first part of the node name, and search for the complete path corresponding to the node name in the mapping table. Specifically, this step extracts the path string within the double quotes, separates the first part of the node name using " / " as the delimiter, and then uses the node name as the key to query the mapping table constructed in step S4-1 to obtain the complete path of the node in the entire device tree.

[0073] Step S4-4: Obtain the parent path of the complete path and concatenate it with the remaining part of the path string to obtain a new absolute path string. For example, if the complete path returned by the mapping table is / i2c@0 / dev-mux@0 / i2c-mux@1 / device@0 / i2c-mux@0, take its parent path part (i.e., remove the last-level node name) / i2c@0 / dev-mux@0 / i2c-mux@1 / device@0, and concatenate it with the remaining part of the original path string (e.g., the remaining part of device@0 / i2c-mux@0 after removing the first part; in practice, this may need to be processed according to specific logic) to form the final absolute path. The specific concatenation rules can be flexibly adjusted according to the semantics of the node(“path”) expression; the core is to convert the relative reference into an absolute path based on the root node.

[0074] Step S4-5: Replace the node(“path”) expression in the original line with the new absolute path string enclosed in double quotes, and output the processed line to obtain the intermediate baseboard file after path parsing. For lines that do not contain the node(“path”) pattern, output them as is.

[0075] In this method, step S5 is used to clean up the marked nodes in the intermediate substrate file after path parsing. For example... Figure 6 As shown, this step specifically includes sub-steps S5-1 to S5-6.

[0076] Step S5-1: Parse the intermediate baseboard file after path parsing and construct a node tree, where each node contains a pointer to its parent node. The node tree construction here is similar to the previous steps, but it is particularly important to maintain a parent node pointer for each node in order to facilitate subsequent "promotion" operations.

[0077] Step S5-2: Perform a post-order traversal of the node tree, processing child nodes first and then the current node. Post-order traversal ensures that all child nodes of a marked node have been cleared before the marked node is processed, avoiding the problem of repeated processing caused by nested marked nodes.

[0078] Step S5-3: If the current node contains the attribute "des" and does not contain any other attributes or child nodes, then delete the node. Specifically, this step checks whether an attribute named "des" exists in the attribute list of the current node; if it exists, and the attribute list length is exactly 1, the child node list is empty, and the current node is not the root node, then remove the node from the child node list of its parent node.

[0079] Step S5-4: If the current node contains the `des` attribute and other attributes and / or child nodes, then promote all attributes except the `des` attribute and all child nodes to its parent node, and then delete the node itself. Specifically, if the current node contains the `des` attribute, but also has other attributes or multiple child nodes, this step first appends all attributes except the `des` attribute to the parent node's attribute list, then appends all child nodes of the current node sequentially to the parent node's child node list (inserting at the current node's original position in the parent node's child node list), and finally removes the current node from the parent node's child node list. This "promotion" operation preserves the valid hardware description content within the marker node, only deleting the node shell that serves as an identifier.

[0080] Step S5-5: If the current node is the root node and has a `des` attribute, then only remove the `des` attribute. The root node cannot be deleted, so only the `des` attribute needs to be removed from its attribute list.

[0081] Steps S5-6: Output the processed node tree to obtain the final target device tree file. This step serializes the cleaned node tree into text format and outputs the final file.

[0082] Based on the above solution, this invention also provides a modular integration system for device tree files to implement the above method flow scheme. The system includes five functional modules, corresponding to the five steps in the method scheme: prefix addition module, merging module, node deduplication module, path parsing module, and marker node cleanup module.

[0083] At the implementation level, each module employs dynamic memory allocation technology, enabling it to handle device tree source files with any number of rows, regardless of file size. Modules communicate via command-line parameters, passing input and output filenames. This allows for both chaining the five modules together to complete a full integration process and individually calling a single module to perform a specific task, offering excellent flexibility and scalability. For example, developers can use the prefix addition module to add slot identifiers to board files and output intermediate files for manual review, or they can directly run the entire process to generate the final target device tree file with a single click.

[0084] The prefix addition module in this system processes the board device tree source file by scanning line by line and matching regular expressions.

[0085] In its implementation, this module maintains a slot number parameter (passed by command-line arguments, such as "--slot=2") and performs the following checks on each line: For lines starting with the top-level node (i.e., lines without leading whitespace and ending with "{"), the node name is extracted and the prefix "slotX-" is inserted; for attribute lines containing the custom extended syntax node("path"), the first part of the node name in the path expression is extracted through string parsing, the prefix is ​​added, and then the lines are reassembled; for lines containing phandle references with &node_name, the prefix is ​​also added before the node name and then the lines are reassembled.

[0086] This module automatically updates all references to that node within the board file while modifying the node name to establish namespace isolation, thereby avoiding reference breakage issues.

[0087] The merging module in this system achieves intelligent merging of board files into baseboard files at the source file level.

[0088] In its implementation, this module parses the substrate device tree source file, constructs a complete node tree using a stack data structure, and records the name of each node, its start and end line numbers in the file, indentation level, and parent node information. Then, it parses the intermediate board file with slot identifiers, extracting the names and content ranges of all its top-level nodes. For each board's top-level node, it searches for a target node with the same name within a preset board subtree in the substrate node tree. If found, the module adjusts the indentation of the board's content lines to match the substrate format by calculating the base indentation within the target node and the minimum indentation of the lines within the board node, and appends the adjusted content lines to the target node's additional line list. Finally, the module iterates through each line of the output substrate file, inserting the corresponding additional line content before encountering a node end marker ("}").

[0089] The module merging process is performed entirely at the source file level, without relying on compiler or runtime support; intelligent indentation adjustment preserves the readability of the original file format; the generated intermediate files are still in the standard device tree source file format, which can be directly used for subsequent steps or submitted for compilation.

[0090] The node deduplication module in this system is used to solve the problem of redundant child nodes with the same name caused by merging multiple boards.

[0091] In its implementation, this module first parses the merged intermediate baseboard file and constructs a complete node tree data structure in memory, where each node contains an attribute list and a child node list. Then, it performs a post-order traversal of the node tree: first, it recursively removes duplicates from all child nodes, then processes the direct child node list of the current node. For the direct child nodes of the current node, a nested loop is used for comparison; if two child nodes have the same name, all attributes and child nodes of the latter child node are transferred to the former child node, and the latter child node is removed from the child node list. After the traversal is complete, the module re-serializes the processed node tree into text format for output.

[0092] This module employs an "active deduplication" strategy, which contrasts sharply with the passive approach of the DTC compiler, which exits when encountering a node with the same name. Through post-order traversal and attribute merging algorithms, it ensures the integrity and correctness of the deduplication operation.

[0093] The path parsing module in this system is used to convert the custom relative path reference node(“path”) inside the board into a standard absolute path string after integration.

[0094] In its implementation, this module employs a two-pass scanning strategy. During the first pass, the module parses the deduplicated intermediate baseboard file, using a stack structure to track the complete path of the current node, and establishing a mapping table from "node name" to "complete path" for each node. During the second pass, the module searches line by line for the `node("path")` pattern. When a pattern is matched, the module extracts the path string and separates the first part, the node name; it then retrieves the complete path corresponding to that node name by querying the mapping table established in the first pass; it takes the parent path portion of this complete path and concatenates it with the remaining part of the original path string to form the final absolute path string; finally, it replaces the `node("path")` expression in the original line with the absolute path string enclosed in double quotes. The key technical features of this module are: its ability to handle non-standard custom path expressions, its ability to establish an automated conversion channel from source files generated by specific EDA tools to standard device trees; and its two-pass scanning design, which ensures the accuracy and efficiency of path parsing.

[0095] The marker node cleanup module in this system is used to clean up temporary marker nodes (identified by the des attribute) introduced for identification purposes during the integration process.

[0096] In its implementation, this module first parses the intermediate baseboard file after path parsing and constructs a node tree with parent node pointers. Then, it performs a post-order traversal of the node tree, checking each node for the presence of the `des` attribute. Depending on the node's content, it handles three cases: if a node contains only the `des` attribute and no other attributes or child nodes, it is directly deleted; if a node contains the `des` attribute and also contains other attributes or child nodes, all attributes except the `des` attribute and all child nodes are "promoted" to their parent node, and then the node itself is deleted; if the root node contains the `des` attribute, only the `des` attribute is removed without deleting the root node.

[0097] This module introduces a "lifting" operation, which can intelligently retain the valid content within the tag node while only deleting the tag shell. This is a feature that the / delete-node / command in the existing technology does not have, making the final generated file more concise and suitable for production environment deployment.

[0098] The five modules work together, with the output files of each module serving as the input files for the next module. Data flows between modules in a standard device tree source file format. Developers can interrupt the process at any stage, review intermediate results, or insert manual interventions, which greatly facilitates debugging and maintenance.

[0099] The specific implementation of the present invention will be further described in detail below through two specific embodiments.

[0100] Example 1 (Single Board Scenario): This embodiment provides a modular integration method for device tree files, applied to a scenario where a card of type cardtype1 is inserted into slot 2 of a baseboard. The entire integration process is as follows: (1) Step S1, perform prefix addition processing.

[0101] Retrieve the board device tree source file cardtype1.txt, specifying slot number 2. Add module prefix as follows. Figure 2 The process shown is used to process this file.

[0102] This module reads the input file line by line, skipping leading whitespace characters. For lines that start with a top-level node without leading whitespace and containing "{", such as i2c-interface {, the node name i2c-interface is extracted, and the prefix slot2- is added before it, rewriting it as slot2-i2c-interface {.

[0103] For an attribute line containing node(“path”), such as i2c-mux = node(“i2c-interface / device@0 / i2c-mux@0”);, the module extracts the first part of the path string, i2c-interface, adds a prefix, and reassembles it into i2c-mux = node(“slot2-i2c-interface / device@0 / i2c-mux@0”);.

[0104] For attribute lines containing a reference to &node_name, such as handle = <&i2c-interface>, the module adds a prefix before i2c-interface and reassembles it into handle = <&slot2-i2c-interface>.

[0105] Other normal lines, blank lines, and comment lines are output as is.

[0106] After this step, the intermediate card file S1-slot2-cardtype1.txt with slot identifiers is generated.

[0107] (2) Step S2, perform the merge process.

[0108] Obtain the baseboard device tree source file board.txt and the intermediate board file S1-slot2-cardtype1.txt generated in the previous step. Merge the module according to... Figure 3 The process shown is followed.

[0109] First, the module parses board.txt and uses a stack structure to build a board node tree, recording in detail the name of each node, the start and end line numbers in the file, the indentation level, and the parent node information.

[0110] Next, the module parses S1-slot2-cardtype1.txt and extracts the names and content ranges of all its top-level nodes.

[0111] Then, for each extracted top-level node of the board (e.g., slot2-i2c-interface), the module searches for a node with the same name in the board node tree located under a specific board node subtree. Once a target node is found, the module calculates the baseline indentation that the content inside the target node should have, and adjusts the indentation of each line inside the board node accordingly to maintain consistency. After adjustment, these content lines are appended to the target node's "additional line list".

[0112] Finally, the module iterates through each line of the output board file, inserting the contents of the node's "additional line list" before processing the closing marker ("}") of that node. This generates the merged intermediate board file S2-board-slot2.txt.

[0113] This step uses a source file-level merging method, which merges directly within the source files, generating a complete, independently compileable device tree source file that is easy for developers to review and debug.

[0114] (3) Step S3: Perform node deduplication.

[0115] Obtain the merged intermediate file S2-board-slot2.txt, and proceed with the node deduplication module as follows: Figure 4 The process shown is followed.

[0116] The module first parses the input file and builds a complete node tree data structure in memory, where each node contains a list of attributes and a list of child nodes.

[0117] The module then performs a post-order traversal of the node tree. When processing each node, it first recursively removes duplicates from all its child nodes, and then processes the list of direct child nodes of the current node. For the direct child nodes of the current node, a nested loop is used for comparison. If two child nodes with the same name are found (e.g., two ethernet-port nodes), all attributes and child nodes of the latter node are transferred to the first node, and the latter node is removed from the list of child nodes.

[0118] After traversal is complete, the module reserializes the node tree in memory into text format and outputs the deduplicated intermediate file S3-board-slot2.txt.

[0119] It is important to emphasize that the "active deduplication" strategy used in this step can automatically merge nodes with the same name, avoiding compilation interruption and improving the degree of automation.

[0120] (4) Step S4: Perform path resolution processing.

[0121] Obtain the deduplicated intermediate file S3-board-slot2.txt of the substrate, and the path parsing module will proceed as follows: Figure 5 The process shown is followed.

[0122] This step employs a two-pass scanning strategy. During the first pass, the module parses the file and uses a stack to trace the complete path of the current node, creating a mapping table from "node name" to "complete path" for each node.

[0123] During the second scan, the module searches for the `node("path")` pattern line by line. For example, when it scans the line `i2c-mux = node("slot2-i2c-interface / device@0 / i2c-mux@0");`, the module extracts the path string and separates the first part, the node name `slot2-i2c-interface`. By querying the mapping table established in the first scan, it obtains the complete path of that node (e.g., ` / i2c@0 / dev-mux@0 / i2c-mux@1 / device@0 / i2c-mux@0`, assuming an absolute path on the baseboard). Next, it takes the parent path portion of this complete path (i.e., removing the last-level node name) and concatenates it with the remaining part of the original path, `device@0 / i2c-mux@0`, to form the final absolute path string.

[0124] Finally, replace the node(...) expression in the original line with an absolute path string enclosed in double quotes, i.e., i2c-mux = " / i2c@0 / dev-mux@0 / i2c-mux@1 / device@0 / i2c-mux@0";. Output all processed lines to obtain the intermediate board file S4-board-slot2.txt after path parsing.

[0125] (5) Step S5: Perform the marker node cleanup process.

[0126] Obtain the intermediate file S4-board-slot2.txt of the substrate after path parsing, and then proceed with the node cleanup module. Figure 6 The process shown is followed.

[0127] The module first parses the file and builds a node tree, and records a pointer to its parent node for each node.

[0128] Next, a post-order traversal is performed on the node tree, prioritizing child nodes. For each current node encountered, it is checked whether it contains an attribute named `des`. If the current node contains the `des` attribute, and does not contain any other attributes or child nodes (i.e., it is an empty tag node), and the current node is not the root node, then the node is directly removed from the list of child nodes of its parent node. If the current node contains the `des` attribute, but also contains other attributes or child nodes, then all attributes of that node except for the `des` attribute and all child nodes are moved to its parent node, and the current node itself is removed from its parent node. This process is called "promotion". If the current node is the root node and contains the `des` attribute, then simply remove the `des` attribute from the root node's attribute list.

[0129] Finally, the processed node tree is output as a text file, which is the final target device tree file S5-device-tree.txt.

[0130] This step achieves refined management of marked nodes through conditional judgment and content transfer, making the final generated file cleaner and more professional.

[0131] Example 2 (Complex combination scenario with multiple boards and slots): This embodiment demonstrates the integration process of inserting two different types of cards (cardtype A and cardtype B) into the first slot 2 and the second slot 5 of the substrate, respectively.

[0132] (1) Step S1: Perform prefix addition processing on the card type A.txt and card type B.txt files respectively, and set the slot number parameters to 2 and 5 respectively. During the processing, update the node(“path”) and &node_name references in each file synchronously to generate intermediate files S1-slot2-cardtype A.txt and S1-slot5-cardtype B.txt.

[0133] (2) Step S2: Obtain the board file board.txt. First, merge S1-slot2-cardtypeA.txt into the board file to obtain a temporary intermediate file. Then, use this temporary intermediate file as the new board and merge S1-slot5-cardtypeB.txt into it. After these two consecutive merging operations, the contents of the two boards are accurately inserted into the corresponding board subtree nodes in the board file, generating the merged board intermediate file S2-board-slot2-slot5.txt.

[0134] (3) Step S3: Perform node deduplication on S2-board-slot2-slot5.txt. For example, if both cardtypeA and cardtypeB contain a child node named ethernet-port, this step will merge the attributes and child node contents of these two nodes into the same ethernet-port node, thereby avoiding redundancy and compilation errors.

[0135] (4) Step S4: Perform path parsing processing on the deduplicated files. This step converts the relative path references node(“path”) used by each of the two boards into their absolute paths in the final integrated device tree, ensuring that all references point to the correct nodes.

[0136] (5) Step S5: Finally, perform the marker node cleanup process, delete all nodes with the des attribute that are temporarily existing for identification purposes during the integration process, and generate the final target device tree file S5-device-tree.txt that can be directly used for compilation.

[0137] As can be seen from the two embodiments above, the modular integration scheme for device tree files provided by this invention can effectively handle various hardware modular combination scenarios, ranging from simple to complex. Through a standardized and automated process, it generates the target device tree file completely and accurately, significantly improving the efficiency and reliability of embedded system development. Compared with existing technologies such as device tree overlay technology, DTC path reference extension function, and JSON-based project management schemes, this invention has significant technical advancements and practical value in terms of source file-level integration, automation level, reference integrity maintenance, node deduplication, and tag cleanup.

[0138] In view of the above-mentioned modular integration scheme for device tree files, this embodiment of the invention also provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the steps of the above-mentioned modular integration method for device tree files.

[0139] This invention also provides a processor for running a program, wherein the program executes the steps of the modular integration method for the device tree file described above.

[0140] This invention also provides a terminal device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. The program code is loaded and executed by the processor to implement the steps of the modular integration method of the device tree file described above.

[0141] The present invention also provides a computer program product, which, when executed on a data processing device, is adapted to perform the steps of the modular integration method for the device tree file described above.

[0142] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0143] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0144] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0145] 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 modular integration method for device tree files, characterized in that, Includes the following steps: Step S1: Obtain at least one board device tree source file, add slot identifiers to each board device tree source file, and synchronously update the path reference and node handle reference in the attribute row during the process of adding slot identifiers to obtain the board intermediate file with slot identifiers; wherein, the path reference is a relative path expression in the form of node("path"), and the node handle reference is a phandle reference expression in the form of &node_name; Step S2: Obtain the substrate device tree source file, and merge the intermediate file of the board with slot identifier into the substrate device tree source file to obtain the merged substrate intermediate file. Step S3: Perform node deduplication processing on the merged substrate intermediate file. Within each node, merge child nodes with the same name into one node to obtain the deduplicated substrate intermediate file. Step S4: Perform path parsing processing on the deduplicated substrate intermediate file, converting relative path references in the attribute such as node("path") into absolute path strings to obtain the path-parsed substrate intermediate file. Step S5: Perform marker node cleanup on the intermediate file of the substrate after path parsing, delete or promote marker nodes containing the DES attribute, and obtain the final target device tree file.

2. The method according to claim 1, characterized in that, Step S1 involves adding slot identifiers to the board device tree source file, specifically including: Step S1-1: Read each line of the board device tree source file and determine whether the current line is the starting line of the top-level node; Step S1-2: If the current row is the starting row of the top-level node, extract the node name and add the prefix "slotX-" before the node name, where X is the slot number; Steps S1-3: If the current line is an attribute line and contains a path reference in the form of node("path"), then extract the first part of the node name in the path string, add the prefix to the first part of the node name, and reorganize the new line; Steps S1-4: If the current line is an attribute line and contains a node handle reference in the form of &node_name, then add the prefix before the node_name and reorganize the new line; Steps S1-5: Output the processed lines to generate the intermediate file of the board with slot identifier.

3. The method according to claim 1, characterized in that, Step S2 specifically includes: Step S2-1: Parse the substrate device tree source file, construct the substrate node tree, and record the node name, start and end lines, indentation and parent node information of each node; Step S2-2: Parse the intermediate file of the board with slot identifier and extract the node name and content range of its top-level node; Step S2-3: For each board top-level node, find the target node with the same name that is located in the preset board node subtree in the substrate node tree; Step S2-4: If the target node is found, calculate the base indentation inside the target node and the minimum indentation of the lines inside the board node. After adjusting the indentation, add the lines inside the board node to the additional line list of the target node. Step S2-5: Output the substrate device tree source file and insert the contents of its additional line list at the end of each node to obtain the merged substrate intermediate file.

4. The method according to claim 1, characterized in that, Step S3 specifically includes: Step S3-1: Parse the merged intermediate baseboard file and construct a node tree, where each node contains an attribute list and a list of child nodes; Step S3-2: Perform a post-order traversal of the node tree, first recursively process the child nodes, and then merge the direct child nodes of the current node. Step S3-3: When merging the direct child nodes of the current node, if a child node with the same name is found, all attributes and child nodes of the latter child node are transferred to the former child node, and the latter child node is deleted. Step S3-4: Output the processed node tree to obtain the deduplicated intermediate file of the substrate.

5. The method according to claim 1, characterized in that, Step S4 specifically includes: Step S4-1: Scan the deduplicated intermediate files of the substrate for the first time and construct a mapping table from node names to complete paths; Step S4-2: Scan the file a second time, searching for the node("path") pattern in each line; Step S4-3: If the pattern is found, extract the path string, separate the first part of the node name, and search for the complete path corresponding to the node name in the mapping table; Step S4-4: Obtain the parent path of the complete path and concatenate it with the remaining part of the path string to obtain a new absolute path string; Step S4-5: Replace the node("path") expression in the original line with the new absolute path string enclosed in double quotes, output the processed line, and obtain the intermediate baseboard file after path parsing.

6. The method according to claim 1, characterized in that, Step S5 specifically includes: Step S5-1: Parse the intermediate file of the substrate after path parsing and construct a node tree, where each node contains a pointer to its parent node; Step S5-2: Perform a post-order traversal of the node tree, processing the child nodes first, and then processing the current node. Step S5-3: If the current node contains the `des` attribute and does not contain other attributes or child nodes, then delete the node. Step S5-4: If the current node has a des attribute and contains other attributes and / or child nodes, then promote all attributes except the des attribute and all child nodes to their parent node, and then delete the node itself. Step S5-5: If the current node is the root node and has the des attribute, then only remove the des attribute; Steps S5-6: Output the processed node tree to obtain the final target device tree file.

7. A modular integration system for device tree files, characterized in that, The system is used to implement the method according to any one of claims 1 to 6, comprising: The prefix addition module is used to add slot identifiers to the board device tree source file and synchronously update the path references and node handle references in the attribute line; The merging module is used to merge the intermediate board file with slot identifier obtained by the prefix addition module into the baseboard device tree source file; The node deduplication module is used to merge child nodes with the same name within the files processed by the merging module. The path resolution module is used to convert relative path references to absolute path strings for the files obtained by the node deduplication module. The marker node cleanup module is used to delete or promote marker nodes with the 'des' attribute in the files processed by the path parsing module.

8. The system according to claim 7, characterized in that, Each module in the system employs dynamic memory allocation technology, enabling it to handle device tree files with any number of rows. Modules exchange input and output filenames via command-line parameters, allowing them to either chain together to complete a full process or be used independently.

9. A modular integration apparatus for device tree files, 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 program, it implements the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

Images