A heterogeneous inter-core communication third-party library adaptation method based on a general kernel

Abstract

The application provides a heterogeneous core communication third-party library adaptation method based on a general kernel, belongs to the technical field of computer operating systems, and aims to solve the problem of OpenAMP third-party library adaptation required by mixed deployment of OpenHarmony and RTOS, and comprises the following steps: libmetal masks the details of different system implementations, provides a unified abstraction, virtio queue is equivalent to the MAC layer in a network protocol, provides an efficient underlying communication mechanism, rpmsg is equivalent to the transport layer in a network protocol, provides a communication mechanism based on endpoint and channel abstraction, and remoteproc provides life cycle management functions including initialization, starting, pausing, ending and the like. The application breaks through the environmental restrictions, realizes cross-system reuse of library files, and can be applied to arm64 architecture heterogeneous core devices of different brands and different models, and the scene coverage of the technology is enhanced.

Description

Technical Field

[0001] This invention relates to a method for adapting third-party libraries for heterogeneous inter-kernel communication based on a general kernel, belonging to the field of computer operating system technology. Background Technology

[0002] While Linux is widely used in embedded systems, it cannot cover all needs, such as high real-time performance, high reliability, and high security. These are often where real-time operating systems (RTOS) come in. Some applications require both Linux's management capabilities and rich ecosystem, as well as the high real-time performance, high reliability, and high security of an ROS. A typical design involves using a high-performance processor running Linux for rich functionality, and a microcontroller / DSP / real-time processor running the ROS for real-time control or signal processing. The two communicate via I / O, network, or off-chip bus. The problems with this approach are: hardware-wise, it requires two systems with low integration; communication is limited by off-chip physical mechanisms (such as speed and latency); and software-wise, Linux and the ROS are disconnected, leaving room for improvement in flexibility and maintainability.

[0003] Benefiting from the rapid development of hardware technology, the hardware capabilities of embedded systems are becoming increasingly powerful. For example, the single-core capability is constantly improving, evolving from single-core to multi-core, heterogeneous multi-core and even many-core. The development and application of virtualization technology and Trusted Execution Environment (TEE) technology, and the future advanced packaging technology will bring higher integration, etc., provide a solid physical foundation for deploying multiple OSs in a single System-on-a-Chip (SoC).

[0004] Meanwhile, driven by the demands of IoT, AI, functional safety, and information security applications, embedded software systems are becoming increasingly complex, posing a growing challenge to having a single OS handle all functions. One solution is to assign different systems to functions they excel at, such as Windows' UI, Linux's network communication and management, and real-time operating systems' high real-time performance and high reliability. Furthermore, these systems should be easy to develop, deploy, and extend, and can be implemented using containers, virtualization, or similar methods.

[0005] In light of the aforementioned hardware and application changes, and considering their inherent characteristics, one direction for the future evolution of embedded systems is a hybrid deployment of Linux and RTOS. This can be glimpsed from the recent development trend of automotive electronics, a typical embedded system. Therefore, in order to achieve hybrid deployment of OpenHarmony with an RTOS in the future, OpenAMP needs to be ported and adapted first.

[0006] OpenAMP provides a lightweight heterogeneous inter-core communication solution for OpenHarmony hybrid deployment scenarios: libmetal shields the details of different system implementations and provides a unified abstraction; virtio queue is equivalent to the MAC layer in network protocols, providing an efficient low-level communication mechanism; rpmsg is equivalent to the transport layer in network protocols, providing a communication mechanism based on endpoint and channel abstractions; and remoteproc provides lifecycle management functions including initialization, startup, pause, and termination. Summary of the Invention

[0007] To address the issue of OpenAMP third-party library adaptation required for hybrid deployment of OpenHarmony and RTOS, this invention proposes a method for adapting third-party libraries for heterogeneous inter-kernel communication based on a general kernel.

[0008] The technical solution adopted by the present invention to solve the above problems is as follows: The present invention includes the following steps: Step 1: Obtain the OpenHarmonySDK, libsysfs library files, libmetal source code, and OpenAMP source code in an Ubuntu 20.04 environment; Step 2: Create an ohos folder in the lib / system directory of the libmetal source code, and copy the files in the linux folder of the lib / system directory into the ohos folder; Step 3: Modify the utilities.c file in the ohos folder to make it compatible with the OpenHarmonySDK environment; Step 4: Use configure and OpenHarmonySDK to cross-compile the libsysfs library file, and copy the relevant header files from the libsysfs library file to the specified directory of OpenHarmonySDK; Step 5: Create a build folder in the libmetal source code and cross-compile the libmetal library files using CMake and OpenHarmonySDK; Step 6: Create a build folder in the OpenAMP source code, and use CMake and OpenHarmonySDK to cross-compile the OpenAMP library files based on the compiled libmetal library files to complete the adaptation of the third-party library for communication between heterogeneous cores.

[0009] Furthermore, in step 3, modify the utilities.c file in the ohos folder directory, including: Open the utilities.c file in the ohos folder directory and find the original metal_open function, which is int metal_open(const char *path, int shm); Modify the original `metal_open` function, including: ignoring the `shm` function via `(void)shm`; defining file open flags: `flags` (read / write enabled, `O_RDWR`; `O_CREAT` (create file if it doesn't exist); and `O_CLOEXEC` (close unused file descriptors during execution); defining file permissions (`mode`): `S_IRUSR` (read only for the file owner), `S_IWUSR` (write enabled); defining the file descriptor `fd`; adding parameter validation: returning an invalid parameter error code `-EINVAL` if `path` is a null pointer or the `path` string length is 0; calling the `open` function to open the file corresponding to `path` using `flags` and `mode`; and handling the return result: returning a negative error code `-errno` if the file opening fails (`fd < 0`); and returning the file descriptor `fd` if successful.

[0010] Furthermore, in step 4, the relevant header files from the libsysfs library are copied to the specified directory of OpenHarmonySDK, including: Step 4.1: Execute the command `autoreconf -fiv` to generate the libsysfs configuration file; Step 4.2: Set a series of environment variables to specify the toolchain path and compilation parameters for the OpenHarmony SDK. These environment variables include, but are not limited to, the OHOS_SDK path, the compilers CC and CXX, the linker LD, and the stripping tool STRIP. Step 4.3: Use the configure command to configure the libsysfs build environment, specifying the output directory and target architecture; Step 4.4: Execute the make command to compile the library files, and use the make install command to install the compiled results into the specified directory of OpenHarmonySDK.

[0011] Furthermore, step 5 involves cross-compiling the libmetal library files using CMake and OpenHarmonySDK, including: Step 5.1: Create a build folder in the libmetal source code directory; Step 5.2: Configure the CMake tool, specifying the toolchain files, installation directory, and target architecture, and disable warnings for unused command-line arguments during C / C++ compilation, while also viewing the compilation details -L; Step 5.3: Execute the command `make VERBOSE=1` to compile the library files, display the detailed compilation process, complete the compilation of the libmetal library, and generate libmetal library files adapted for OpenHarmony; Step 5.4: Execute the `make install` command to install the libmetal library files adapted for OpenHarmony into the specified directory of the OpenHarmonySDK.

[0012] Furthermore, in step 6, the OpenAMP library files are cross-compiled using CMake and OpenHarmonySDK based on the libmetal library files, including: Step 6.1: Create a "build" folder in the OpenAMP source code directory. Step 6.2: Configure using CMake tools, specifying the same toolchain files, installation directory, and target architecture as in Step 5.2, and disable warnings for unused command-line arguments during C / C++ compilation. At the same time, view the compilation details -L, and specify the directory of the compiled libmetal files and the path to the compiled libmetal library files. Step 6.3: Execute the command `make VERBOSE=1` to display the detailed compilation process and link the libmetal library to complete the compilation of the OpenAMP library; Step 6.4: Execute the `make install` command to install the compiled OpenAMP library to the specified path of OpenHarmonySDK.

[0013] The beneficial effects of this invention are: 1. This invention overcomes environmental limitations and enables cross-system reuse of library files. By modifying the libmetal source code (such as adjusting the metal_open function to adapt to OpenHarmony file operation logic) and cross-compiling based on the OpenHarmonySDK (specifying the aarch64 architecture toolchain and adapting the musl library), this invention allows library files that originally only supported Linux to be called normally in the OpenHarmony environment. This avoids the cost for developers to redevelop an entire inter-kernel communication library to adapt to OpenHarmony, and achieves cross-system reuse of mature third-party libraries.

[0014] 2. This invention employs targeted adaptation and optimization, including modifications to the metal_open function, specifying the -fPIC file during cross-compilation, generating standardized configuration files via autoreconf, and using CMake to specify toolchain files, thereby reducing runtime errors caused by compatibility issues.

[0015] 3. This invention is compiled and adapted for the arm64-v8a architecture, and the compilation instructions reserve space for adjusting directory parameters, allowing developers to modify the configuration according to the SDK path and installation path of the actual hardware. This enables the adapted library files to be applied to heterogeneous arm64 architecture devices of different brands and models, thus enhancing the scope of application of the technology. Attached Figure Description

[0016] Figure 1 It is the modified utilities.c file.

[0017] Figure 2 This is an example of successfully generating the configure file for the libsysfs library.

[0018] Figure 3 This is a successful compilation example of the libsysfs library.

[0019] Figure 4 This is an example of a successful generation of the makefile for the libmetal library.

[0020] Figure 5 This is a successful compilation example of the libmetal library.

[0021] Figure 6 This is a successful example of generating the Makefile for the OpenAMP library.

[0022] Figure 7 This is a successful example of compiling the OpenAMP library.

[0023] Figure 8 This is a diagram showing the project structure of DevEco Studio that includes three libraries.

[0024] Figure 9 This is a diagram illustrating how CMake imports three libraries.

[0025] Figure 10 This is a flowchart illustrating a method for adapting third-party libraries for heterogeneous inter-kernel communication based on a general kernel. Detailed Implementation

[0026] Combination Figure 1-10 This implementation method is described as follows: Figure 10 As shown in this embodiment, the steps of a third-party library adaptation method for heterogeneous inter-kernel communication based on a general kernel include: S1: Obtain the OpenHarmonySDK and the source code for libsysfs, libmetal, and OpenAMP in an Ubuntu 20.04 environment; OpenHarmonySDK can be obtained through official channels; libmetal source code: https: / / github.com / OpenAMP / libmetal; OpenAMP source code: https: / / github.com / OpenAMP / open-amp; libmetal is a prerequisite for compiling OpenAMP.

[0027] S2: Create an ohos folder in the lib / system directory of the libmetal source code, and copy the files in the linux folder in the same directory into the ohos folder; S3: Modify the utilities.c file in the ohos directory to make it compatible with the OpenHarmonySDK environment; like Figure 1 As shown, the specific modifications to the utilities.c file in S3 include: S31: Locate the function int metal_open(const char *path, int shm); S32: Modify the function to: int metal_open(const char *path, int shm) { (void)shm; const int flags = O_RDWR | O_CREAT | O_CLOEXEC; const int mode = S_IRUSR | S_IWUSR; int fd; if (!path || !strlen(path)) return -EINVAL; fd = open(path, flags, mode); return fd<0 ? -errno : fd; } S4: Use configure and OpenHarmonySDK to cross-compile the libsysfs library file, and copy dlist.h and libsysfs.h from / usr / include / sysfs into native / sysroot / usr / include / sysfs in OpenHarmonySDK; The configure build command for libsysfs in S4 specifically includes: S41: autoreconf -fiv; This invention generates standardized configuration files via autoreconf and specifies the toolchain files (ohos.toolchain.cmake) using CMake, ensuring the repeatability of the compilation process and avoiding library file anomalies caused by differences in the compilation environment. Figure 2 As shown, the command successfully generated the configure file.

[0028] S42: Adjust the parameters of subsequent commands automatically according to the directory situation. export OHOS_SDK= / home / zero6go / desktop / OH_SDK / export AS=${OHOS_SDK} / native / llvm / bin / llvm-as export CC="${OHOS_SDK} / native / llvm / bin / clang --target=aarch64-linux-ohos" export CXX="${OHOS_SDK} / native / llvm / bin / clang++ --target=aarch64-linux-ohos" export LD=${OHOS_SDK} / native / llvm / bin / ld.lld export STRIP=${OHOS_SDK} / native / llvm / bin / llvm-strip export RANLIB=${OHOS_SDK} / native / llvm / bin / llvm-ranlib export OBJDUMP=${OHOS_SDK} / native / llvm / bin / llvm-objdump export OBJCOPY=${OHOS_SDK} / native / llvm / bin / llvm-objcopy export NM=${OHOS_SDK} / native / llvm / bin / llvm-nm export AR=${OHOS_SDK} / native / llvm / bin / llvm-ar export CFLAGS="-fPIC -D__MUSL__=1" export CXXFLAGS="-fPIC -D__MUSL__=1"; S43: . / configure --prefix= / home / zero6go / desktop / sysfsutils / output --host=aarch64-linux ac_cv_func_malloc_0_nonnull=yes; S44: make; S45: make install; like Figure 3 As shown, the libsysfs library has now been compiled. The compiled include and lib files can be found in the output folder.

[0029] In summary, this invention specifies -fPIC (position-independent code) and disables the "unused command-line argument" warning (-Wno-unused-command-line-argument) during cross-compilation, reducing potential errors during the compilation process and ensuring that library files can be loaded in different memory address spaces, thereby improving the stability of operation in multi-process / multi-threaded scenarios.

[0030] S5: Create a build folder in the libmetal source code and cross-compile the libmetal library files using CMake and OpenHarmonySDK; The CMake build instructions for libmetal in S5 specifically include: S51: / home / zero6go / Desktop / OH_SDK / native / build-tools / cmake / bin / cmake -DCMAKE_TOOLCHAIN_FILE= / / home / zero6go / Desktop / OH_SDK / native / build / cmake / ohos.toolchain.cmake -DCMAKE_INSTALL_PREFIX= / home / zero6go / Desktop / libmetal / output -DOHOS_ARCH=arm64-v8a -DCMAKE_C_FLAGS="-Wno-unused-command-line-argument" -DCMAKE_CXX_FLAGS="-Wno-unused-command-line-argument" .. -L; like Figure 4 As shown, CMake has successfully generated the Makefile at this point; S52: make VERBOSE=1; S53: make install; like Figure 5 As shown, the libmetal library has now been compiled. The compiled include and lib files can be found in the output folder.

[0031] S6: Create a build folder in the OpenAMP source code, and use CMake and OpenHarmonySDK to cross-compile the OpenAMP library files based on the libmetal library files; The CMake build instructions for libmetal in S5 specifically include: S51: / home / zero6go / Desktop / OH_SDK / native / build-tools / cmake / bin / cmake -DCMAKE_TOOLCHAIN_FILE= / / home / zero6go / Desktop / OH_SDK / native / build / cmake / ohos.toolchain.cmake -DCMAKE_INSTALL_PREFIX= / home / zero6go / Desktop / libmetal / output -DOHOS_ARCH=arm64-v8a -DCMAKE_C_FLAGS="-Wno-unused-command-line-argument" -DCMAKE_CXX_FLAGS="-Wno-unused-command-line-argument" .. -L; The -DLIBMETAL_INCLUDE_DIR and -DLIBMETAL_LIB points to the libmetal library include folder and .a file compiled in S5, respectively.

[0032] like Figure 6 As shown, CMake has successfully generated the Makefile at this point; S52: make VERBOSE=1; S53: make install; like Figure 7 As shown, the OpenAMP library compilation is now complete, and the compiled include and lib files can be found in the output folder.

[0033] like Figure 8As shown, place the libsysfs, libmetal, and OpenAMP library files generated by cross-compilation into the DevEcoStudio project, and then... Figure 9 As shown, by adding the dependencies of the three libraries to the CMakeLists file, you can develop a hybrid deployment framework.

[0034] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent substitutions, and improvements made to the above embodiments without departing from the scope of the present invention, based on the technical essence of the present invention and within the spirit and principles of the present invention, shall still fall within the protection scope of the present invention.

Claims

1. A method for adapting third-party libraries for heterogeneous inter-kernel communication based on a general-purpose kernel, characterized in that, include: Step 1: Obtain the OpenHarmonySDK, libsysfs library files, libmetal source code, and OpenAMP source code in an Ubuntu 20.04 environment; Step 2: Create an ohos folder in the lib / system directory of the libmetal source code, and copy the files in the linux folder of the lib / system directory into the ohos folder; Step 3: Modify the utilities.c file in the ohos folder to make it compatible with the OpenHarmonySDK environment; In step 3, modify the utilities.c file in the ohos folder directory, including: Open the utilities.c file in the ohos folder directory and find the original metal_open function, which is int metal_open(const char *path, int shm); Modify the original `metal_open` function, including: ignoring the `shm` function via `(void)shm`; defining file open flags: `flags` (read / write enabled, `O_RDWR`; `O_CREAT` (create file if it doesn't exist); and `O_CLOEXEC` (close unused file descriptors during execution); defining file permissions (`mode`): `S_IRUSR` (read only for the file owner), `S_IWUSR` (write enabled); defining the file descriptor `fd`; adding parameter validation: returning an invalid parameter error code `-EINVAL` if `path` is a null pointer or the `path` string length is 0; calling the `open` function to open the file corresponding to `path` using `flags` and `mode`; and handling the return result: returning a negative error code `-errno` if the file opening fails (`fd` < 0); and returning the file descriptor `fd` if successful. Step 4: Use configure and OpenHarmonySDK to cross-compile the libsysfs library file, and copy the relevant header files from the libsysfs library file to the specified directory of OpenHarmonySDK; Step 5: Create a build folder in the libmetal source code and cross-compile the libmetal library files using CMake and OpenHarmonySDK; Step 6: Create a build folder in the OpenAMP source code, and use CMake and OpenHarmonySDK to cross-compile the OpenAMP library files based on the compiled libmetal library files to complete the adaptation of the third-party library for communication between heterogeneous cores.

2. The method for adapting third-party libraries for heterogeneous inter-kernel communication based on a general kernel as described in claim 1, characterized in that, In step 4, the relevant header files from the libsysfs library are copied to the specified directory of OpenHarmonySDK, including: Step 4.1: Execute the command `autoreconf -fiv` to generate the libsysfs configuration file; Step 4.2: Set a series of environment variables to specify the toolchain path and compilation parameters of the OpenHarmony SDK; among them, the series of environment variables include, but are not limited to, the OHOS_SDK path, the compilers CC and CXX, the linker LD, and the stripping tool STRIP; Step 4.3: Use the configure command to configure the libsysfs build environment, specifying the output directory and target architecture; Step 4.4: Execute the make command to compile the library files, and use the make install command to install the compiled results into the specified directory of OpenHarmonySDK.

3. The method for adapting third-party libraries for heterogeneous inter-kernel communication based on a general kernel as described in claim 1, characterized in that, Step 5 uses CMake and OpenHarmonySDK to cross-compile the libmetal library files, including: Step 5.1: Create a build folder in the libmetal source code directory; Step 5.2: Configure the CMake tool, specifying the toolchain files, installation directory, and target architecture, and disable warnings for unused command-line arguments during C / C++ compilation, while also viewing the compilation details -L; Step 5.3: Execute the command `make VERBOSE=1` to compile the library files, display the detailed compilation process, complete the compilation of the libmetal library, and generate libmetal library files adapted for OpenHarmony; Step 5.4: Execute the `make install` command to install the libmetal library files adapted for OpenHarmony into the specified directory.

4. The method for adapting third-party libraries for heterogeneous inter-kernel communication based on a general kernel as described in claim 3, characterized in that, Step 6 uses CMake and OpenHarmonySDK to cross-compile the OpenAMP library files based on the libmetal library files, including: Step 6.1: Create a build folder in the OpenAMP source code directory; Step 6.2: Configure using CMake tools, specifying the same toolchain files, installation directory, and target architecture as in Step 5.2, and disable warnings for unused command-line arguments during C / C++ compilation. At the same time, view the compilation details -L, and specify the directory of the compiled libmetal files and the path to the compiled libmetal library files. Step 6.3: Execute the command `make VERBOSE=1` to display the detailed compilation process and link the libmetal library to complete the compilation of the OpenAMP library; Step 6.4: Execute the `make install` command to install the compiled OpenAMP library to the specified path.

Images