RTRE deployment method and RTRE

Abstract

The invention relates to an RTRE deployment method and an RTRE, the method is suitable for equipment provided with a Linux system of any release version, and the method comprises the following steps: acquiring a CPU type and / or a mainboard board card type of the equipment by a configuration script, and executing configuration of hardware resources of the RTRE according to the CPU type and / or the mainboard board card type; compiling the source code of the drive module of the RTRE by the compiling script and storing the source code in a temporary directory; and copying the compiled drive module under the temporary directory to a specified installation directory by an installation script. Therefore, the problems of complex RTRE deployment and high maintenance cost caused by different release versions of the Linux operating system in the prior art are solved, and adaptation across multiple non-real-time Linux operating systems is realized by using one set of RTRE, so that running of a real-time operating system (RTOS) is supported on the systems.

Description

Technical Field

[0001] The present application relates to the technical field of embedded systems, and in particular to a deployment method of RTRE and RTRE. Background Art

[0002] With the widespread application of embedded systems in industrial automation, intelligent manufacturing, intelligent transportation and other fields, the demand for real-time operating systems (RTOS) is increasing. At present, these demands can be met through the Intewell-Lin architecture, such as Figure 1 The Intewell-Lin architecture shown in the figure deploys a non-real-time operating environment and a real-time operating environment (RTRE) based on the hardware layer. Linux runs in the non-real-time operating environment and RTOS runs in the RTRE. This architecture combines the real-time operating system RTOS with the non-real-time Linux operating system to provide a mixed operating system environment. This architecture enables the execution of tasks with strict real-time requirements and the running of general non-real-time applications on the same hardware platform.

[0003] At present, the Intewell-Lin architecture has been adapted to multiple distribution versions of non-real-time Linux operating systems, such as Ubuntu, Debian, Buildroot, Yocto and other distribution versions. Figure 2 These operating systems are all based on the Linux kernel, and the hardware drivers are compatible with each other under the same CPU architecture. The differences between the root file system architectures are not particularly large, such as Figure 3 shown.

[0004] At present, when deploying RTRE, different versions of RTRE installation scripts are developed for different Linux distributions, and the Linux distribution will be read during the RTRE deployment process to perform corresponding deployment. For example, based on the Linux distribution, the driver files are released to the folder corresponding to the system distribution name, and the configuration files and instruction sets corresponding to the Linux distribution are constructed. Therefore, the RTRE installation script made for the Ubuntu system can only be executed on the Ubuntu system, not on the Debian system. This RTRE deployment method leads to the following problems:

[0005] (1) The RTRE installation scripts corresponding to different Linux operating system releases need to be maintained separately. As the number of supported releases increases, the maintenance cost increases exponentially.

[0006] (2) Every time a new Linux operating system is released, RTRE needs to be recompiled and tested, which consumes a lot of time and resources;

[0007] (3) Multiple versions of installation scripts can easily confuse users and increase the difficulty of use. In particular, in some demand scenarios, different boards in a system support different Linux distributions. For example, board A in the system runs the Ubuntu system, and board B runs the Debian system. If two sets of RTRE are deployed to correspond to the two distributions of the system, it is not only easy to make mistakes, but also inconvenient to maintain. Summary of the invention

[0008] In view of the above problems in the prior art, the present application provides a RTRE deployment method and RTRE, which solves the problems of complex RTRE deployment and high maintenance cost caused by different Linux operating system release versions in the prior art. The present application uses a set of RTRE to achieve adaptation across multiple non-real-time Linux operating systems, thereby supporting the operation of real-time operating systems (RTOS) on these systems.

[0009] To achieve the above-mentioned object, the first aspect of the present application provides a method for deploying RTRE, which is applicable to a device having any Linux system distribution installed, including:

[0010] The configuration script obtains the CPU type and / or the mainboard card type of the device, and performs the configuration of the hardware resources of the RTRE accordingly;

[0011] The source code of the driver module of RTRE is compiled by the compilation script and stored in a temporary directory;

[0012] The installation script copies the compiled driver module in the temporary directory to the specified installation directory.

[0013] In this way, the RTRE deployment method provided by the present application no longer relies on the Linux system distribution version to specifically develop and maintain many different versions of installation scripts. Instead, through a unified configuration, compilation and installation process, only one set of RTRE needs to be maintained. In the face of Linux systems with various distribution versions, it can effectively cope with the deployment of RTRE, greatly reducing the high maintenance costs caused by the diversity of versions and improving the overall maintenance efficiency.

[0014] As a possible implementation manner of the first aspect, obtaining a CPU type and a mainboard card type of the device includes:

[0015] The device tree file of the Linux system is read to obtain a field for identifying a CPU type and a field for identifying a mainboard card type in the device tree file.

[0016] In this way, by directly reading the device tree file, the configuration script can obtain the necessary hardware configuration information, namely the CPU type and the motherboard card type. Since the device tree file is parsed and loaded by the kernel when the system starts, it reflects the most realistic hardware status of the current system, ensuring that the acquired hardware information is up-to-date and accurate. In addition, the device tree, as a widely used standard data structure, is used to describe hardware configuration information, ensuring compatibility and consistency between devices of different manufacturers and models. By parsing the fields in the device tree file in a unified way, differences caused by different Linux distributions or hardware platforms can be avoided, improving the consistency and reliability of the deployment process.

[0017] As a possible implementation manner of the first aspect, obtaining a CPU type and a mainboard card type of the device includes:

[0018] The configuration parameters in the kernel of the Linux system are read, and a field for identifying a CPU type and a field for identifying a mainboard card type in the configuration parameters are obtained.

[0019] In this way, the configuration parameters in the Linux system kernel are usually strictly checked and set during the system startup and initialization process, and the accuracy and timeliness are highly guaranteed. Compared with relying on external files (such as device tree files) or other tools to obtain hardware information, directly reading kernel configuration parameters can obtain key hardware information such as CPU type and motherboard type more quickly and directly, reducing the overhead of intermediate links and data conversion, improving the efficiency of information acquisition, helping to speed up the deployment process of RTRE and reduce the risk of deployment failure caused by information acquisition delays or errors.

[0020] As a possible implementation manner of the first aspect, the configuration of the hardware resources for executing RTRE includes at least one of the following:

[0021] According to the board model, the serial port enable command or the serial port disable command executed;

[0022] According to the CPU model, the dynamic frequency scaling mode is turned off or on.

[0023] In this way, by reading the CPU type and mainboard card type of the device, the hardware resource configuration of RTRE can be flexibly adjusted. This dynamic configuration strategy effectively meets the diverse needs of different application scenarios, allowing RTRE to better adapt to various hardware environments.

[0024] As a possible implementation of the first aspect, the compiling script compiles the source code of the driver module of RTRE and stores it in a temporary directory, including:

[0025] Obtain the source code of the RTRE driver module and the source code of the Linux system kernel;

[0026] The source code of the driver module of RTRE and the source code of the kernel of the Linux system are compiled by the compilation script and stored in a temporary directory.

[0027] In this way, compiling the source code of the RTRE driver module and the source code of the Linux system kernel together can ensure the integrity of the underlying code required for compiling the RTRE driver module (that is, part of the code is obtained from the Linux kernel), so that the compiled driver module can correctly adapt to the architecture of the Linux kernel and its operating environment, and work in accordance with the specifications and requirements of the kernel, thereby ensuring the compatibility of the RTRE driver module with the Linux system kernel, and effectively avoiding system failures or performance problems caused by the mismatch between the driver module and the Linux kernel.

[0028] As a possible implementation of the first aspect, copying the compiled driver module in the temporary directory to a specified installation directory includes:

[0029] Creating a universal installation directory, wherein the universal installation directory is a fixed installation directory;

[0030] The compiled driver module in the temporary directory is copied to the general installation directory.

[0031] In this way, using a fixed installation directory as the deployment location of the driver module can ensure that each installation operation follows a unified path specification, reducing the possibility of path configuration errors. At the same time, there is no need to carry out complex installation directory planning for different hardware configurations or system versions. You only need to copy the driver module to a fixed universal installation directory, which improves the convenience and efficiency of installation.

[0032] As a possible implementation of the first aspect, copying the compiled driver module in the temporary directory to a specified installation directory includes:

[0033] Creating an installation directory including the CPU type and / or the mainboard card type field;

[0034] Copy the compiled driver module in the temporary directory to the installation directory.

[0035] In this way, by creating an installation directory containing the CPU type and motherboard card type fields, it is indicated that the deployed driver modules are all customized for the current hardware environment. In this way, the same set of RTRE installation scripts can be used to install RTRE on devices with the same hardware but different Linux distributions. Through this directory, it can be used as a reminder and distinction of the difference in hardware, which can reduce the risk of hardware incompatibility and improve the stability of the system.

[0036] As a possible implementation of the first aspect, copying the compiled driver module in the temporary directory to a specified installation directory includes:

[0037] Get the version name of the Linux system of the release version;

[0038] Creating an installation directory containing a field for the version name;

[0039] Copy the compiled driver module in the temporary directory to the installation directory.

[0040] In this way, by creating an installation directory containing the Linux distribution version name field, it is ensured that each driver module can accurately match a specific Linux distribution, avoiding compatibility issues caused by differences in operating systems. In addition, the method supports the installation method of the designated directory of the driver module of the existing Linux distribution, and the driver is copied to the original specified installation directory, which can be effectively compatible with the existing designated directory driver module deployment method of distributions such as Ubuntu and Debian.

[0041] To achieve the above-mentioned object, the second aspect of the present application provides an RTRE installed on a device of a Linux system, which is installed using the deployment method described in the first aspect above.

[0042] As a possible implementation of the second aspect, at least one executable instruction of the RTRE includes multiple version instruction codes, and when the instruction is executed, the multiple version instruction codes can be executed in sequence until a Linux system with a current release version is matched;

[0043] The multiple version instruction codes correspond to Linux systems of different release versions.

[0044] In this way, the RTRE script contains multiple versions of instruction codes, which correspond to different Linux distributions. When RTRE is executed, it will automatically try to execute these instruction codes according to the actual situation of the current system until it finds a version that matches the current distribution. In other words, no matter whether the user is using Ubuntu, CentOS or any other Linux distribution, for instructions with different expressions of the same functional instruction, RTRE can flexibly respond and match the instructions recognized by the Linux distribution, avoiding the problem of incompatibility between the Linux distribution and the RTRE script.

[0045] In addition, the design of RTRE also avoids commands that rely on specific operating system types. Traditional scripts or tools often need to choose to execute different commands based on the type of operating system, which increases the complexity of RTRE. RTRE automatically adapts to different Linux distributions by including multiple versions of instruction codes and choosing which version to execute based on the actual system environment and available tools.

[0046] To achieve the above object, the third aspect of the present application provides a computing device, including:

[0047] processor, and

[0048] A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor executes the deployment method described in any one of the first aspects above.

[0049] To achieve the above-mentioned objectives, the fourth aspect of the present application provides a computer-readable storage medium having program instructions stored thereon, and when the program instructions are executed by a computer, the computer implements the deployment method described in any one of the above-mentioned first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 It is a structural diagram of an Intewell-Lin architecture provided by this application;

[0051] Figure 2 This is a schematic diagram of a Linux operating system startup process provided by this application;

[0052] Figure 3 It is a corresponding relationship diagram between a different Linux operating system and RTRE in the prior art;

[0053] Figure 4 This is a flow chart of the main steps of a RTRE deployment method provided by this application;

[0054] Figure 5It is a correspondence diagram between different Linux operating systems and RTRE provided by this application;

[0055] Figure 6 It is a structural schematic diagram of a computing device provided by the present application.

[0056] It should be understood that the size and shape of each block diagram in the above structural diagram are for reference only and should not constitute an exclusive interpretation of the embodiment of the present invention. The relative position and inclusion relationship between the blocks presented in the structural diagram are only schematic representations of the structural association between the blocks, and do not limit the physical connection method of the embodiment of the present invention. DETAILED DESCRIPTION

[0057] The technical solution provided by the present application is further described below with reference to the accompanying drawings and examples. It should be understood that the system structure and business scenarios provided in the examples of the present application are mainly to illustrate the possible implementation methods of the technical solution of the present application and should not be interpreted as the only limitation on the technical solution of the present application. It is known to those of ordinary skill in the art that with the evolution of the system structure and the emergence of new business scenarios, the technical solution provided by the present application is also applicable to similar technical problems.

[0058] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present application. In case of any inconsistency, the meaning described in this specification or the meaning derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0059] 1) RTRE (Real Time Runtime Environment), which is a software platform designed for real-time applications and can support multiple real-time operating systems (RTOS).

[0060] 2) Device Tree is a data structure used to describe the configuration information of hardware devices. It helps operating systems (such as Linux) to correctly identify and configure hardware devices at startup. The device tree file (DTS file) is the source code file of the device tree, usually with the extension .dts. In Linux systems, the decoded device tree information can usually be found in the / proc / device-tree / directory. In addition, / sys / firmware / devicetree / base / is also a common path for accessing device tree information.

[0061] The present application embodiment provides a method for deploying RTRE, such as Figure 4As shown, it is applicable to devices with any Linux distribution installed, including:

[0062] S401, obtaining the CPU type and / or mainboard card type of the device through a configuration script, and performing configuration of the hardware resources of the RTRE accordingly;

[0063] S402, compile the source code of the driver module of RTRE by a compile script and store it in a temporary directory;

[0064] S403: The installation script copies the compiled driver module in the temporary directory to the specified installation directory.

[0065] In this way, the RTRE deployment method provided by the present application no longer relies on each Linux system distribution version to specifically develop and maintain many different versions of RTRE installation scripts, but through a unified configuration, compilation and installation process, a set of RTRE installation scripts is used to implement the installation of RTRE under Linux systems of multiple distribution versions, which greatly reduces the high maintenance cost caused by the diversity of versions and improves the overall maintenance efficiency.

[0066] It is worth noting that when the Linux operating systems are based on the same Linux kernel, their hardware drivers are compatible with each other under the same CPU architecture. In addition, the root file system architectures of these operating systems also have a high degree of similarity. This application uses these commonalities to achieve the adaptation of multiple non-real-time Linux operating systems through a unified RTRE (real-time runtime environment) installation or running scripts, such as Figure 5 As shown, it supports RTOS (real-time operating system) running on it. It not only simplifies the cross-platform RTRE deployment process, but also effectively reduces the development and maintenance costs of RTRE installation files (ie, installation scripts), reduces the possibility of errors, and improves the overall user experience.

[0067] In some embodiments, obtaining the CPU type and the mainboard card type of the device includes:

[0068] The device tree file of the Linux system is read to obtain a field for identifying a CPU type and a field for identifying a mainboard card type in the device tree file.

[0069] Specifically, in terms of obtaining the CPU type and motherboard type of the device, the present invention adopts an innovative method based on the device tree file. In the device tree file, there are many possibilities for the field used to identify the CPU type, such as the common compatible, model, etc., and it also supports users to customize fields according to specific needs; and the field used to identify the motherboard type can also be board-type, compatible or other user-defined fields. Because the configuration script needs to accurately parse these fields to obtain accurate hardware information, the exact names of these fields must be clear.

[0070] For example, model="Phytium Pi Board" indicates that the CPU type is "Phytium Pi Board".

[0071] compatible="phytium,pe2204"; indicates that the motherboard card type is "phytium,pe2204".

[0072] In Linux systems, decoded device tree information can usually be found in the / proc / device-tree / or / sys / firmware / devicetree / base / directories. Based on this, the configuration script can obtain key information about the CPU type and motherboard type by accessing these specific paths, thereby providing a solid data foundation for subsequent RTRE hardware resource configuration and ensuring the accuracy and reliability of the entire deployment process.

[0073] In this way, by directly reading the device tree file, the configuration script can obtain the necessary hardware configuration information, namely the CPU type and the motherboard card type. Since the device tree file is parsed and loaded by the kernel when the system starts, it reflects the most realistic hardware status of the current system, ensuring that the acquired hardware information is up-to-date and accurate. In addition, the device tree, as a widely used standard data structure, is used to describe hardware configuration information, ensuring compatibility and consistency between devices of different manufacturers and models. By parsing the fields in the device tree file in a unified way, differences caused by different Linux distributions or hardware platforms can be avoided, improving the consistency and reliability of the deployment process.

[0074] In some embodiments, obtaining the CPU type and the mainboard card type of the device includes:

[0075] The configuration parameters in the kernel of the Linux system are read, and a field for identifying a CPU type and a field for identifying a mainboard card type in the configuration parameters are obtained.

[0076] Among them, for platforms that do not support device tree, such as Feiteng D2000, corresponding parameters can be added in the Linux kernel in advance.

[0077] For example, the Linux system provides many command line tools, such as uname, lscpu, dmidecode, etc., through which the configuration parameters and hardware information in the kernel can be read and displayed.

[0078] In this way, the configuration parameters in the Linux system kernel are usually strictly checked and set during the Linux system startup and initialization process, and the accuracy and timeliness are highly guaranteed. Compared with relying on external files (such as device tree files) or other tools to obtain hardware information, directly reading kernel configuration parameters can obtain key hardware information such as CPU type and motherboard type more quickly and directly, reducing the overhead of intermediate links and data conversion, improving the efficiency of information acquisition, helping to speed up the deployment process of RTRE and reduce the risk of deployment failure caused by information acquisition delays or errors.

[0079] In some embodiments, the configuration of the hardware resources for executing RTRE includes at least one of the following:

[0080] According to the board model, the serial port enable command or the serial port disable command executed;

[0081] According to the CPU model, the dynamic frequency scaling mode is turned off or on.

[0082] Specifically, the reason for executing the enable serial port command or the disable serial port command according to the board model will be explained as follows.

[0083] In embedded systems or specific hardware platforms, real-time operating systems (RTOS) and non-real-time operating systems (such as Linux) may share the same hardware resources, such as serial ports. Serial ports are important tools for debugging and communication, but in some cases, real-time systems and non-real-time systems may conflict because they try to use the same serial port at the same time. In order to ensure system stability and performance, you need to execute the corresponding serial port configuration commands according to the specific board model.

[0084] For some boards (such as Rockchip's rk series), since the real-time system has higher requirements, the serial port of the non-real-time system will be disabled to ensure that the real-time system can monopolize the debugging serial port.

[0085] However, for other boards (such as Feiteng e2000), in order to support the debugging requirements of both real-time and non-real-time systems, the serial port will be enabled and the non-real-time system will be allowed to output debugging information to a file.

[0086] Specifically, the reasons for turning off or on the dynamic frequency scaling mode according to the CPU model will be explained as follows.

[0087] Dynamic frequency modulation technology is an important means for modern CPUs and hardware platforms to improve system energy efficiency. It can automatically adjust the frequency of the CPU, memory, and bus according to system load and performance requirements. However, in some real-time system application scenarios, in order to ensure the stability and performance of the system, this function needs to be precisely controlled.

[0088] For CPUs that support dynamic frequency modulation, execute a special command to turn off this function, so that the CPU can run stably at a fixed frequency, effectively avoiding system fluctuations and uncertainties caused by dynamic frequency adjustment, and providing solid protection for the stable operation of real-time systems.

[0089] For CPUs that do not support dynamic frequency adjustment, the shutdown operation will not be performed to prevent unnecessary errors and performance loss caused by incorrect shutdown operations, ensuring that the system is always in the best operating state.

[0090] In this way, by reading the CPU type and mainboard card type of the device, the hardware resource configuration of RTRE can be flexibly adjusted. This dynamic configuration strategy effectively meets the diverse needs of different application scenarios, allowing RTRE to better adapt to various hardware environments.

[0091] In some embodiments, the compiling script compiles the source code of the driver module of RTRE and stores it in a temporary directory, including:

[0092] Obtain the source code of the RTRE driver module and the source code of the Linux system kernel;

[0093] The source code of the driver module of RTRE and the source code of the kernel of the Linux system are compiled by the compilation script and stored in a temporary directory.

[0094] In this way, compiling the source code of the RTRE driver module and the source code of the Linux system kernel together can ensure the integrity of the underlying code required for compiling the RTRE driver module (that is, part of the code is obtained from the Linux kernel), so that the compiled driver module can correctly adapt to the architecture of the Linux kernel and its operating environment, and work in accordance with the specifications and requirements of the kernel, thereby ensuring the compatibility of the RTRE driver module with the Linux system kernel, and effectively avoiding system failures or performance problems caused by the mismatch between the driver module and the Linux kernel.

[0095] In some embodiments, copying the compiled driver module in the temporary directory to the specified installation directory includes:

[0096] Creating a universal installation directory, wherein the universal installation directory is a fixed installation directory;

[0097] The compiled driver module in the temporary directory is copied to the general installation directory.

[0098] Among them, the general installation directory and the fixed installation directory can be understood as: a specific path location that is pre-set, which does not change with the hardware characteristics of the device, such as the CPU type, the motherboard type, and is not affected by the differences in Linux system releases. It is unique and deterministic in the system's file architecture.

[0099] It is worth noting that since the RTRE driver module interacts directly with the Linux kernel and hardware, and does not rely on the implementation of a specific operating system, all operating systems using the same Linux kernel version and CPU architecture can share the same set of drivers, which makes driver deployment easier and more unified. Through this design, no matter what the underlying operating system is, as long as it is based on the same Linux kernel and has a matching hardware architecture, this common installation directory can be used to install and use these universal drivers.

[0100] In this way, using a fixed installation directory as the deployment location of the driver module can ensure that each installation operation follows a unified path specification, reducing the possibility of path configuration errors. At the same time, there is no need to carry out complex installation directory planning for different hardware configurations or system versions. You only need to copy the driver module to a fixed universal installation directory, which improves the convenience and efficiency of installation.

[0101] In some embodiments, copying the compiled driver module in the temporary directory to the specified installation directory includes:

[0102] Creating an installation directory including the CPU type and / or the mainboard card type field;

[0103] Copy the compiled driver module in the temporary directory to the installation directory.

[0104] For example, two servers with different configurations are used as examples for explanation.

[0105] Server A: Equipped with Intel J6412 CPU and master board card of master_board_01.

[0106] Server B: Equipped with Rockchip RK3568 CPU and master_board_02 motherboard.

[0107] The specific operations are as follows.

[0108] For server A:

[0109] Create an installation directory that contains the CPU type (i.e. Intel J6412) and the motherboard type (i.e. master_board_01) fields, such as / drivers / Intel_J6412 / master_board_01 / ; and copy the compiled driver module in the temporary directory to the / drivers / Intel_J6412 / master_board_01 / directory.

[0110] For server B:

[0111] Create an installation directory that contains the CPU type (i.e. Rockchip RK3568) and the mainboard type field (i.e. master_board_02), such as drivers / RK3568 / master_board_02 / ; and copy the compiled driver module in the temporary directory to the / RK3568 / master_board_02 / directory.

[0112] In this way, by creating an installation directory containing the CPU type and motherboard card type fields, it is indicated that the deployed driver modules are all customized for the current hardware environment. In this way, the same set of RTRE installation scripts can be used to install RTRE on devices with the same hardware but different Linux distributions. Through this directory, it can be used as a reminder and distinction of the difference in hardware, which can reduce the risk of hardware incompatibility and improve the stability of the system.

[0113] In some embodiments, copying the compiled driver module in the temporary directory to the specified installation directory includes:

[0114] Get the version name of the Linux system of the release version;

[0115] Creating an installation directory containing a field for the version name;

[0116] Copy the compiled driver module in the temporary directory to the installation directory.

[0117] For example, take two servers running different Linux distributions as an example.

[0118] Server A: Running Ubuntu 20.04LTS.

[0119] Server B: Running CentOS 8.

[0120] The specific operations are as follows.

[0121] For server A:

[0122] Get the version name of the current Linux system "Ubuntu_20.04_LTS" and create an installation directory containing the version name field, for example, / drivers / ubuntu_20.04_lts / ; copy the compiled driver module in the temporary directory to the / drivers / ubuntu_20.04_lts / directory.

[0123] For server B:

[0124] Get the version name of the current Linux system "CentOS_8" and create an installation directory containing the version name field, for example, / drivers / centos_8 / ; copy the compiled driver module in the temporary directory to the / drivers / centos_8 / directory.

[0125] In this way, by creating an installation directory containing the Linux distribution version name field, it is ensured that each driver module can accurately match a specific Linux distribution, avoiding compatibility issues caused by differences in operating systems. In addition, the method supports the installation method of the designated directory of the driver module of the existing Linux distribution, and the driver is copied to the original specified installation directory, which can be effectively compatible with the existing designated directory driver module deployment method of distributions such as Ubuntu and Debian.

[0126] It should be noted that, in some embodiments, if the version name of the Linux system of the distribution version cannot be obtained, that is, the operating system type cannot be successfully identified, then the unidentified system will be classified as "others", which indicates that the operating system is not in the predefined list. At this time, an installation directory containing "others" can be created, such as / drivers / others / .

[0127] In this way, the method supports the installation method of the designated directory of the driver module of the existing Linux distribution, and copies the driver to the original specified installation directory, which can be effectively compatible with the existing designated directory driver module deployment method of distributions such as Ubuntu and Debian.

[0128] In order to more clearly illustrate the above method, the present application provides the following specific embodiments.

[0129] First embodiment: Linux system device, whose CPU type is Intel J6412, mainboard card type is master_board_01, and version name is Ubuntu 20.04LTS.

[0130] Step 1: Obtain the CPU type and / or mainboard type of the device;

[0131] Ways to obtain include:

[0132] Method 1: The configuration script reads the device tree file (Device Tree) of the Linux system and obtains the field used to identify the CPU type (such as compatible or device_type) and the field used to identify the motherboard card type (such as model).

[0133] Method 2: The configuration script can also choose to read the kernel configuration parameters of the Linux system and extract relevant information about the CPU type and motherboard type.

[0134] The CPU type obtained through method 1 or method 2 is Intel J6412, and the mainboard card type is master_board_01.

[0135] The configuration script mentioned above may be the rt_config.sh script.

[0136] Step 2: According to the obtained CPU type and / or mainboard card type, perform configuration of the hardware resources of RTRE;

[0137] Exemplarily, according to the obtained mainboard card type master_board_01, the serial port enable command is executed;

[0138] According to the obtained CPU type Intel J6412, disable the dynamic frequency adjustment mode.

[0139] Step 3: Obtain the source code of the RTRE driver module and the source code of the Linux system kernel;

[0140] Step 4: Compile the script to compile the source code of the RTRE driver module and the source code of the Linux system kernel, and store them in a temporary directory;

[0141] The compilation script may be a build.sh script.

[0142] Exemplarily, the temporary directory is / tmp / rtre_modules.

[0143] Step 5: Create a general installation directory, and use the installation script to copy the compiled driver module in the temporary directory to the general installation directory.

[0144] The installation script may be the intewell_install.sh script.

[0145] By default, the common installation directory is / usr / local / rtre / modules.

[0146] Of course, you can also create an installation directory containing the CPU type (i.e. Intel J6412) and / or motherboard type (i.e. master_board_01) fields according to actual needs, and copy the compiled driver module in the temporary directory to the installation directory; or, create an installation directory containing a version name (i.e. Ubuntu 20.04LTS) field; copy the compiled driver module in the temporary directory to the installation directory.

[0147] The second embodiment: the Feiteng E2000Q chip platform is used as an example for explanation.

[0148] The Feiteng E2000Q chip platform supports a variety of Linux operating systems, including Ubuntu, Debian, Buildroot, Yocto, etc. Different models of Feiteng Pie boards need to be adapted to different operating systems, but the Linux kernel version adapted based on the Feiteng official SDK is the same. In order to compile and install the RTRE driver module on different board models, you can perform the following operations.

[0149] Step 1: To ensure that the CPU type and board model type can be correctly identified, you need to add the model and compatible fields in the device tree file phytium-pi-board-intewell.dts. Model is used to identify the CPU type, and compatible is used to identify the motherboard type.

[0150] For example, model = "Phytium Pi Board" Board";

[0151] compatible="phytium,pe2204".

[0152] Step 2: Modify the RTRE source code modules / build.sh script

[0153] In the modules / build.sh script, conditional statements are added to select the correct compilation path and installation path according to the board model.

[0154] The following is the specific implementation for Phytium E2000Q GSK and Phytium Pi boards:

[0155] (1) For the Phytium E2000Q GSK board, the code is as follows:

[0156] if["$CONFIG_PHYTIUM_E2000Q_GSK"=="y"]; then

[0157] #phytium e2000q gsk board

[0158] echo "-----------building phytium e2000q gsk rt driver-------------"

[0159] INST_DIR=$INSTALL_PATH / aarch64 / others / 5.10.153-phytium-embeded-v2.0

[0160] make install CONFIG_PHYTIUM_E2000Q=ykernel_dir=$(pwd) / .. / .. / .. / kernel_phytium e2000q\

[0161] inst_dir=$INST_DIR\

[0162] module_dir=$TOPDIR

[0163] make clean

[0164] Fi

[0165] The above code can be understood as:

[0166] Judgment condition if["$CONFIG_PHYTIUM_E2000Q_GSK"=="y"];

[0167] Set the installation path INST_DIR; "aarch64" represents the specific architecture type, "others" represents the operating system type, and "5.10.153-phytium-embeded-v2.0" is the version name. This path will be used as a temporary directory.

[0168] Call the make install command and specify the kernel source code path kernel_dir, the installation directory inst_dir, and the module source code path module_dir.

[0169] Run make clean to clean the compilation environment.

[0170] (2) For the Phytium Pi board, the code is as follows:

[0171] if["$CONFIG_PHYTIUM_PI"=="y"]; then

[0172] #phytiumpi

[0173] echo "-----------building phytium pi rt driver-------------"

[0174] INST_DIR=$INSTALL_PATH / aarch64 / others / 5.10.153-phytium-embeded-v2.0

[0175] make install CONFIG_PHYTIUM_E2000Q=ykernel_dir=$(pwd) / .. / .. / .. / kernel_phytiume2000q\

[0176] inst_dir=$INST_DIR\

[0177] module_dir=$TOPDIR

[0178] make clean

[0179] fi

[0180] The above code is similar to the code of Phytium E2000Q GSK board, and the repeated parts are not repeated here.

[0181] Step 3: Get the CPU type and board model type, and configure the hardware resources of RTRE.

[0182] For example, according to the board model, the serial port enable command or the serial port disable command is executed;

[0183] For another example, according to the CPU model, the dynamic frequency modulation mode is turned off or on.

[0184] Step 4: intewellrtev / source / rtcmd / rt_config.sh script, copy the compiled driver module in the temporary directory to the specified installation directory.

[0185] The embodiment of the present application also provides an RTRE installed on a device of a Linux system, which is installed using the deployment method mentioned above.

[0186] In some embodiments, at least one executable instruction of the RTRE includes multiple version instruction codes, and when executing the instruction, the multiple version instruction codes may be executed in sequence until a Linux system with a current release version is matched;

[0187] The multiple version instruction codes correspond to Linux systems of different release versions.

[0188] This is explained below with two examples.

[0189] Example 1: Take configuring a virtual network card as an example.

[0190] In Linux, there are many configuration methods such as ip command, ifconfig command and lower-level network configuration tools. Different Linux distributions have different default integrated network configuration tools. If the RTRE script decides to use specific commands based solely on the operating system type, such as using the ip command on Ubuntu and the ifconfig command on CentOS, the script will become extremely complex and difficult to maintain as Linux distributions increase and update. Therefore, the RTRE script should first detect which network configuration commands are available in the current system. For example, try to configure the virtual network card with the ip command first. If it fails (possibly because the command does not exist or the permissions are insufficient), try the ifconfig command again until a suitable command is matched. This method is based on the actual system environment and available tools, not a specific operating system type.

[0191] Example 2: Take the configuration of NFS server as an example.

[0192] Different Linux distributions provide different configuration tools and file formats. If the RTRE script selects the configuration method and file path according to the operating system type, the script must be updated when there is a new distribution or the configuration method of the existing distribution changes. Therefore, first check whether the / etc / exports file exists and whether the exportfs command can be used to reload the NFS export. This is because these two configuration methods and tools are common in many Linux distributions. If none of these methods are available (possibly because the file does not exist, the command does not exist, or there is no corresponding permission), then other available configuration methods will be tried. For example, this includes checking other configuration file paths and using other commands or tools to configure the NFS server. If all attempted methods fail, an error prompt will be provided to instruct the user to manually configure the NFS server or check the system environment.

[0193] Thus, the RTRE script contains multiple versions of instruction codes, which correspond to different Linux distributions. When RTRE is executed, it will automatically try to execute these instruction codes according to the actual situation of the current system until it finds a version that matches the current distribution. In other words, no matter whether the user is using Ubuntu, CentOS or any other Linux distribution, RTRE can respond flexibly, avoiding the problem of incompatibility between Linux distributions and RTRE scripts.

[0194] In addition, the design of RTRE also avoids commands that rely on specific operating system types. Traditional scripts or tools often need to choose to execute different commands based on the type of operating system, which increases the complexity of RTRE. RTRE automatically adapts to different Linux distributions by including multiple versions of instruction codes and choosing which version to execute based on the actual system environment and available tools.

[0195] Figure 6 600 is a structural diagram of a computing device 600 provided in an embodiment of the present application. The computing device executes the above method, such as Figure 6 As shown, the computing device 600 includes: a processor 610 , a memory 620 , and a communication interface 630 .

[0196] It should be understood that Figure 6 The communication interface 630 in the computing device 600 shown may be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0197] The processor 610 may be connected to a memory 620. The memory 620 may be used to store the program code and data. Therefore, the memory 620 may be a storage unit inside the processor 610, or an external storage unit independent of the processor 610, or a component including a storage unit inside the processor 610 and an external storage unit independent of the processor 610.

[0198] Optionally, the computing device 600 may further include a bus. The memory 620 and the communication interface 630 may be connected to the processor 610 via the bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 A line without an arrow is used to represent the bus, but this does not mean that there is only one bus or one type of bus.

[0199] It should be understood that in the embodiment of the present application, the processor 610 can adopt a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. Or the processor 610 uses one or more integrated circuits to execute related programs to implement the technical solutions provided in the embodiments of the present application.

[0200] The memory 620 may include a read-only memory and a random access memory, and provides instructions and data to the processor 610. A portion of the processor 610 may also include a nonvolatile random access memory. For example, the processor 610 may also store information on the device type.

[0201] When the computing device 600 is running, the processor 610 executes the computer-executable instructions in the memory 620 to perform any operation step of the above method and any optional embodiment thereof.

[0202] It should be understood that the computing device 600 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 600 are respectively for implementing the corresponding processes of each method of the present embodiment. For the sake of brevity, they will not be repeated here.

[0203] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0204] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0205] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0206] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0207] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0208] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0209] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute the above method, which includes at least one of the solutions described in the above embodiments.

[0210] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.

[0211] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0212] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0213] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0214] In addition, the words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0215] In the above description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps will be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0216] The term "comprising" as used in the description and claims should not be interpreted as being limited to what is listed thereafter; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the features, integers, steps or components mentioned, but does not exclude the presence or addition of one or more other features, integers, steps or components and groups thereof. Therefore, the expression "a device comprising means A and B" should not be limited to a device consisting of components A and B only.

[0217] References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places in this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. In addition, in one or more embodiments, the particular features, structures, or characteristics can be combined in any appropriate manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0218] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.

Claims

1. A method for deploying RTRE, applicable to a device installed with any Linux system distribution, characterized in that: include: The configuration script obtains the CPU type and / or the mainboard card type of the device, and performs the configuration of the hardware resources of the RTRE accordingly; The source code of the driver module of RTRE is compiled by the compilation script and stored in a temporary directory; The installation script copies the compiled driver module in the temporary directory to the specified installation directory.

2. The deployment method according to claim 1, characterized in that: The obtaining of the CPU type and the mainboard card type of the device includes: The device tree file of the Linux system is read to obtain a field for identifying a CPU type and a field for identifying a mainboard card type in the device tree file.

3. The deployment method according to claim 1, characterized in that: The obtaining of the CPU type and the mainboard card type of the device includes: The configuration parameters in the kernel of the Linux system are read, and a field for identifying a CPU type and a field for identifying a mainboard card type in the configuration parameters are obtained.

4. The deployment method according to any one of claims 1 to 3, characterized in that: The configuration of the hardware resources for executing RTRE includes at least one of the following: According to the board model, the serial port enable command or the serial port disable command executed; According to the CPU model, the dynamic frequency scaling mode is turned off or on.

5. The deployment method according to claim 1, characterized in that: The compilation script compiles the source code of the driver module of RTRE and stores it in a temporary directory, including: Obtain the source code of the RTRE driver module and the source code of the Linux system kernel; The source code of the driver module of RTRE and the source code of the kernel of the Linux system are compiled by the compilation script and stored in a temporary directory.

6. The deployment method according to claim 1 or 5, characterized in that: The step of copying the compiled driver module in the temporary directory to the specified installation directory includes: Creating a universal installation directory, wherein the universal installation directory is a fixed installation directory; The compiled driver module in the temporary directory is copied to the general installation directory.

7. The deployment method according to claim 1 or 5, characterized in that: The step of copying the compiled driver module in the temporary directory to the specified installation directory includes: Creating an installation directory including the CPU type and / or the mainboard card type field; Copy the compiled driver module in the temporary directory to the installation directory.

8. The deployment method according to claim 1 or 5, characterized in that: The step of copying the compiled driver module in the temporary directory to the specified installation directory includes: Get the version name of the Linux system of the release version; Creating an installation directory containing a field for the version name; Copy the compiled driver module in the temporary directory to the installation directory.

9. An RTRE installed on a device of a Linux system, characterized in that: Use any deployment method described in claims 1-8 for installation.

10. The RTRE according to claim 9, characterized in that At least one executable instruction of the RTRE includes multiple version instruction codes, and when the instruction is executed, the multiple version instruction codes can be executed in sequence until the Linux system with the current release version is matched; The multiple version instruction codes correspond to Linux systems of different release versions.

Images