An inter-core interaction method of a heterogeneous multi-core framework

Abstract

The application discloses a kind of inter-core interaction methods of heterogeneous multi-core framework, comprising the following steps: S1, normal start RTOnBoot framework Linux, through BOOTLOADER fast start RTOS;S2, RTOS core and main core are contacted by IPI interrupt;S3, Linux maps RTOS memory to the same virtual address with RTOS;S4, Linux starts to complete;The steps of the S1 are as follows: before entering Linux startup process, first power on main CPU core, then enter BOOTLOADER and initialize, initialize RTOS page table, then load RTOS image to memory, then power on RTOS core;After power on RTOS core, enable MMU for RTOS core, and then jump to RTOS entry point, at this time, RTOS starts to complete.The application makes full use of the characteristics of modern CPU multicore, designs a kind of multi-core heterogeneous framework, and a kind of structure is Linux or Android, another structure is RTOS, and the two structures run on different CPU cores.At the same time, the optimal large-capacity data exchange performance between cores under this framework is realized, and a flexible inter-core message interaction mechanism is also realized.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to an inter-core interaction method for a heterogeneous multi-core framework. Background Technology

[0002] In fields such as industrial automation, robotics, 3D printing, and drone flight control, the real-time requirements of control systems are increasingly stringent, such as the EtherCAT bus master in industrial automation. In many application scenarios, traditional microcontroller solutions are increasingly unable to meet the demands. Instead, it's necessary to address the real-time performance issues of complex time-sharing operating systems like Linux. Several solutions exist, such as the Preempt-RT patch for Linux or Xenomai. In modern multi-core CPU architectures, these solutions can largely isolate the real-time system onto a single core, reducing the impact of the time-sharing system on the real-time system. In principle, this seems perfect. However, in reality, the real-time performance stability of these solutions is poor. This is not obvious when the time-sharing system is idle. But when the time-sharing system is heavily loaded, the scheduling latency increases significantly, with extremely high scheduling latency occurring very frequently. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a method for inter-core interaction in a heterogeneous multi-core framework. This invention fully utilizes the characteristics of modern CPUs with multiple cores and designs a heterogeneous multi-core framework. One heterogeneous architecture is Linux or Android, and the other is an RTOS, with both architectures running on different CPU cores. This framework achieves optimal high-capacity data exchange performance between cores and also implements a flexible inter-core message interaction mechanism.

[0004] The objective of this invention is achieved through the following technical solution:

[0005] A method for inter-core interaction in a heterogeneous multi-core framework includes the following steps:

[0006] S1. Normally start the Linux in the RTOnBoot framework and quickly start the RTOS through BOOTLOADER;

[0007] S2, the RTOS core and the main core communicate via IPI interrupts;

[0008] S3, Linux maps RTOS memory to the same virtual address as the RTOS;

[0009] S4, Linux boot complete.

[0010] In one or more embodiments of the invention, step S1 is specifically as follows:

[0011] Before entering the Linux boot process, the main CPU core is powered on, then the bootloader is initialized, the RTOS page table is initialized, the RTOS image is loaded into memory, and then the RTOS core is powered on.

[0012] In one or more embodiments of the invention, after powering on the RTOS core, the MMU of the RTOS core is enabled, and then the process jumps to the RTOS entry point, at which point the RTOS startup is complete.

[0013] In one or more embodiments of the invention, step S2 is specifically as follows:

[0014] After entering the Linux boot process, the RTOS has already started. Linux and RTOS perform their first handshake through IPI interrupts. At this point, the RTOS console switches to the Linux main console.

[0015] In one or more embodiments of the invention, the memory layout of the RTOS is divided into three parts: one memory is used for the code segment, data segment, BSS segment and heap of the RTOS; another memory is dedicated to the shared variables between the RTOS and Linux and the message interaction mechanism between the RTOS and Linux; and the last memory is used for large-capacity data interaction between the RTOS and Linux.

[0016] In one or more embodiments of the invention, messages are divided into five categories: messages initiated by Linux with a response, messages initiated by Linux without a response, messages initiated by RTOS with a response, messages initiated by RTOS without a response, and broadcast messages.

[0017] The beneficial effects of this invention are:

[0018] This invention proposes a heterogeneous multi-core framework inter-core interaction method that addresses the real-time performance stability issues in existing solutions where general-purpose complex time-sharing operating systems and real-time systems coexist. It achieves optimal large-capacity data exchange performance between cores and implements a flexible inter-core message interaction mechanism. The only connection between the Linux user space and the RTOS is the RTBridge driver, maximizing isolation between the two. The data structure of the message mechanism is completely isolated from the two operating systems, minimizing the impact of operating system memory jitter on real-time performance. Large-capacity data exchange does not require data copying between cores, achieving optimal inter-core performance. The RTOS and Linux kernel spaces see the same virtual memory through the MMU. Attached Figure Description

[0019] Figure 1 This is the RTOnBoot startup flowchart;

[0020] Figure 2This example uses a Linux-initiated message with a response to illustrate the message passing flowchart. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0022] Example 1: In this example, as Figure 1 As shown, a method for inter-core interaction in a heterogeneous multi-core framework includes the following steps:

[0023] S1. Normally start the Linux in the RTOnBoot framework and quickly start the RTOS through BOOTLOADER;

[0024] S2, the RTOS core and the main core communicate via IPI interrupts;

[0025] S3, Linux maps RTOS memory to the same virtual address as the RTOS;

[0026] S4, Linux boot complete.

[0027] The RTOnBoot framework is a software framework that enables heterogeneous multi-core coexistence of Linux and RTOS (Real-Time Operating System). One heterogeneous architecture is Linux or Android, while the other is an RTOS, with both architectures running on different CPU cores. The RTOnBoot framework offers significantly better real-time performance and stability than Xenomai and other similar frameworks, achieving optimal performance for large-capacity data exchange between cores, while also implementing a flexible inter-core message exchange mechanism.

[0028] In the RTOnBoot framework, Linux boots normally. The bootloader contains an image of the RTOS that powers on from the CPU core and loads it, allowing the RTOS to boot quickly. A block of memory is reserved in the bootloader for the RTOS; this memory is also reserved in Linux to prevent Linux from overwriting it. This memory for the RTOS is mapped from the CPU core to a specific virtual address in the Linux kernel space via the MMU. The mapped page tables are static and are not swapped out, thus having no impact on the RTOS's real-time performance. This memory for the mapped page tables must be reserved in both the bootloader and Linux to prevent overwriting. At some point during the Linux boot process, this reserved memory for the RTOS is mapped from the CPU core to a specific virtual address in the Linux kernel space via the MMU. This specific virtual address needs to be the same as the specific virtual address mapped from the RTOS CPU core; this requires modification of the Linux virtual memory management code.

[0029] In one or more embodiments of the invention, step S1 is specifically as follows:

[0030] Before entering the Linux boot process, the main CPU core is powered on, then the bootloader is initialized, the RTOS page table is initialized, the RTOS image is loaded into memory, and then the RTOS core is powered on.

[0031] In one or more embodiments of the invention, after powering on the RTOS core, the MMU of the RTOS core is enabled, and then the process jumps to the RTOS entry point, at which point the RTOS startup is complete.

[0032] In one or more embodiments of the invention, step S2 is specifically as follows:

[0033] After entering the Linux boot process, the RTOS has already started. Linux and RTOS perform their first handshake through IPI interrupts. At this point, the RTOS console switches to the Linux main console.

[0034] The two cores communicate via IPI interrupts. At some point during the Linux boot process, after the RTOS has already started, Linux and the RTOS perform their first handshake via IPI interrupts. At this point, the RTOS console redirects to the Linux main console. After Linux boots, the only communication between the Linux user space and the RTOS is through a bridge driver, RTBridge, in the Linux kernel space. This design facilitates strict isolation between real-time and non-real-time processes and also benefits security. RTBridge and the RTOS communicate via IPI interrupts.

[0035] In one or more embodiments of the invention, the memory layout of the RTOS is divided into three parts: one memory is used for the code segment, data segment, BSS segment and heap of the RTOS; another memory is dedicated to the shared variables between the RTOS and Linux and the message interaction mechanism between the RTOS and Linux; and the last memory is used for large-capacity data interaction between the RTOS and Linux.

[0036] Data structures used for message interaction, such as message descriptions, message bodies, and linked lists, are allocated from the second memory block. The allocator is a dedicated allocator. Allocation can be performed entirely on the RTOS, or separately on Linux and the RTOS, since both sides see the same virtual address. If they are not on the same core, the cache needs to be flushed. This design minimizes the impact of operating system memory thrashing on real-time performance.

[0037] In one or more embodiments of the invention, messages are divided into five categories: messages initiated by Linux with a response, messages initiated by Linux without a response, messages initiated by RTOS with a response, messages initiated by RTOS without a response, and broadcast messages.

[0038] User processes have corresponding IOCTL calls available to determine whether they can receive broadcast messages. Message creation is handled by the user process informing the RTBridge driver via the IOCTL. The RTBridge sends an IPI interrupt to the RTOS core, which then prepares and assigns the corresponding data structures. The bridge between message sending and receiving is the RTBridge driver and the IPI interrupt. If they are not on the same core, the cache needs to be flushed.

[0039] Example 2, as follows Figure 2 As shown, this embodiment uses a message with a response initiated by Linux as an example to illustrate the message transmission process.

[0040] After the Linux userspace application prepares the parameters, it passes them to the RTBridge driver via IOCTL. The RTBridge has a sending thread. The RTBridge's IOCTL processing function copies the message body memory from user space to a dynamically allocated address in the second memory block, adds the pointer and message parameters to the linked list, and then wakes up the sending thread.

[0041] The sending thread acquires an inter-core lock, retrieves the pointer and message parameters from the linked list, puts them into a fixed shared area in the second memory block, and refreshes the corresponding cache;

[0042] Then an IPI interrupt is sent to the RTOS core. When the RTOS receives the IPI interrupt, it processes the received message and prepares the response parameters through the registered callback function, and copies the response body to the dynamically allocated address in the second memory block.

[0043] Then, an IPI interrupt is sent to the RTBridge core; upon receiving the interrupt, RTBridge notifies the Linux user-space application via fasync; the memory for the response parameters and response body pointer has been mapped to the Linux user space via MMAP; after the Linux user-space application processes the response, it notifies RTBridge to unlock the inter-core lock via IOCTL; the number of buffer copies is minimized throughout the process. RTBridge starts a timer before fasync, and if the Linux user-space application terminates unexpectedly, the inter-core lock is unlocked after the timer expires.

[0044] Large-capacity data exchange between Linux user space and RTOS involves transferring the third memory block of Linux MMAP to Linux user space. The data preparer needs to populate this memory block, and once the data is ready, it sends a BULK BUFFER AVALIBALE message to the data receiver. If they are not on the same core, the cache needs to be flushed. The entire process does not require data copying between cores; only cache flushing is needed. This approach achieves optimal inter-core performance.

[0045] Those skilled in the art will understand that various aspects of this specification can be described and illustrated in several patentable ways, including any new and useful combinations of processes, machines, products, or substances, or any new and useful improvements thereof. Accordingly, various aspects of this specification can be implemented entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. All of the above hardware or software may be referred to as a “data block,” “module,” “engine,” “unit,” “component,” or “system.” Furthermore, various aspects of this specification may be represented as a computer product located on one or more computer-readable media, including computer-readable program code.

[0046] The computer program code required for the operation of each part of this manual can be written in any one or more programming languages, including object-oriented programming languages ​​such as C++, Rust, and Python, and conventional procedural programming languages ​​such as C and assembly language. This program code can run entirely on the user's computer, or as a standalone software package on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any network, such as a local area network (LAN) or a wide area network (WAN), or connected to an external computer (e.g., via the Internet), or in a cloud computing environment, or used as a service such as Software as a Service (SaaS).

[0047] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0048] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0049] This specification uses numbers to describe the quantity of components and attributes in the embodiments. It should be understood that such numbers used in the description of embodiments are sometimes modified by the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in the embodiments of this specification, the numerical parameters used in the specification and claims are approximate values, which may be changed according to the characteristics required by individual embodiments. In the embodiments of this specification, numerical parameters should take into account specified significant digits and employ general methods of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in the embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as accurately as feasible.

[0050] For each patent, patent application, patent application publication, and other material, such as articles, books, specifications, publications, and documents, referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0051] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present invention, and these should also be considered within the scope of protection of the present invention. These will not affect the effectiveness of the implementation of the present invention or the practicality of the patent.

Claims

1. A method for inter-core interaction within a heterogeneous multi-core framework, characterized in that, Includes the following steps: S1. Normally start the Linux in the RTOnBoot framework and quickly start the RTOS through BOOTLOADER; S2, the RTOS core and the main core communicate via IPI interrupts; S3, Linux maps RTOS memory to the same virtual address as the RTOS; S4, Linux boot complete.

2. The inter-core interaction method of a heterogeneous multi-core framework according to claim 1, characterized in that, The specific steps of S1 are as follows: Before entering the Linux boot process, the main CPU core is powered on, then the bootloader is initialized, the RTOS page table is initialized, the RTOS image is loaded into memory, and then the RTOS core is powered on.

3. The inter-core interaction method of a heterogeneous multi-core framework according to claim 2, characterized in that: After powering on the RTOS core, the MMU is enabled, and then the process jumps to the RTOS entry point, at which point the RTOS boot process is complete.

4. The inter-core interaction method of a heterogeneous multi-core framework according to claim 1, characterized in that, The specific steps of S2 are as follows: After entering the Linux boot process, the RTOS has already started. Linux and RTOS perform their first handshake through IPI interrupts. At this point, the RTOS console switches to the Linux main console.

5. The inter-core interaction method of a heterogeneous multi-core framework according to claim 1, characterized in that: The memory layout of the RTOS is divided into three parts: one memory is used for the RTOS code segment, data segment, BSS segment and heap; another memory is dedicated to the shared variables between the RTOS and Linux and the message interaction mechanism between the RTOS and Linux; and the last memory is used for large-capacity data interaction between the RTOS and Linux.

6. The inter-core interaction method of a heterogeneous multi-core framework according to claim 5, characterized in that: Messages are divided into five categories: messages initiated by Linux with a response, messages initiated by Linux without a response, messages initiated by RTOS with a response, messages initiated by RTOS without a response, and broadcast messages.

Images