Multi-core AMP architecture inter-core communication method and system based on high-security embedded real-time operating system

Abstract

The invention provides a multi-core AMP architecture inter-core communication method and system based on a high-security embedded real-time operating system, and the method comprises the steps: respectively operating an authentication version of a Quhua high-security embedded real-time operating system on an AMP heterogeneous multi-core platform, and guaranteeing the real-time performance of a task while providing functional security. And two driving interface mechanisms of IPC Not ify and IPC RPMsg are provided, so that the real-time performance of inter-core communication of the multi-core AMP architecture is improved. The IPC Not ify transmits messages based on the HW mailbox of the HW fifo and interrupts the receiving of core messages, and has low time delay; and a heterogeneous multi-core synchronization function is supported, so that a user does not need to concern the starting sequence of the AMP heterogeneous multi-core system and mainly focuses on development of inter-core communication application programs of the user. The IPC RPMsg provides a two-way communication link based on a channel between the cores, and supports large data volume communication interaction between the cores. A universal shared memory area is configured, and a spinlock technology is adopted to synchronize multi-core operation and prevent multi-core access conflicts. A method for sharing the same physical device by multiple cores is provided, and the problem of insufficient device hardware resources is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of inter-core communication of embedded multi-core processors, and in particular to an inter-core communication method and system of a multi-core AMP architecture based on a high-security embedded real-time operating system. Background Art

[0002] As multi-core designs become more common, almost mainstream, different hardware and software architectures are evolving. From a software perspective, there are two general types: symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP). SMP systems can only be implemented on homogeneous multi-core platforms. For embedded applications, AMP offers greater flexibility and is therefore more common. In a multi-core AMP system, each core may run its own operating system or bare metal program in order to maximize their performance and collaborate on a task. Therefore, two issues need to be addressed: lifecycle management (boot order, etc.) and inter-core communication.

[0003] Patent document CN115098430A (application number: 202210739156.6) discloses a method for inter-core communication priority scheduling based on the AMP architecture, which realizes the simultaneous operation of general-purpose systems and real-time systems on a multi-core platform. The information generated by the general-purpose system enters the RPMsg channel after passing through the message queuing module and is passed to the real-time system, while the information generated by the real-time system is directly passed to the general-purpose system through the RPMsg channel. By adding a message queuing module, messages are prioritized and scheduled, improving the real-time performance of inter-core communication of AMP devices.

[0004] Patent document CN116225741A (application number: 202310231799.4) discloses a heterogeneous multi-core inter-core communication scheduling method. The invention encapsulates messages of different priorities through the RPMsg device driver module, and then implements message scheduling and writes them into shared memory by adding a scheduling module, including a high priority queue, several medium priority queues and a low priority queue.

[0005] In summary, existing inter-core communication focuses on improving the real-time performance of communication, while the equally important lifecycle management issue is ignored. The present invention provides a multi-core AMP architecture inter-core communication method and system based on a high-security embedded real-time operating system. On the basis of improving the security and real-time performance of inter-core communication, the multi-core system startup sequence problem is shielded through IPC Notify, so that the main focus is on the development of user inter-core communication applications. A method for realizing multi-core sharing of the same physical device based on shared memory solves the problem of insufficient multi-core hardware resources, and provides a specific implementation plan using the serial port as an example. Summary of the invention

[0006] In view of the defects in the prior art, the object of the present invention is to provide a multi-core AMP architecture inter-core communication method and system based on a high-security embedded real-time operating system.

[0007] According to the present invention, a multi-core AMP architecture inter-core communication method based on a high-security embedded real-time operating system includes:

[0008] Step S1: running a high-security embedded real-time operating system on the AMP architecture multi-core platform;

[0009] Step S2: Based on IPC Notify, complete two-way handshake communication with all other cores through interruption;

[0010] Step S3: Each core implements inter-core communication based on IPC Notify, supporting small data volume interaction that meets preset conditions;

[0011] Step S4: Each core implements inter-core communication based on IPC RPMsg, supporting large data volume interaction that meets preset conditions.

[0012] Preferably, the step S2 adopts:

[0013] Step S2.1: Initialize the configuration and list all the core names that need to be synchronized with the current core;

[0014] Step S2.2: Synchronize all cores by completing two handshake communications with each core in the list.

[0015] Preferably, the shared memory includes: a shared memory SM1, a general shared memory SM2 and a device shared memory SM3;

[0016] The shared memory SM1 is configured to the MSRAM area, and the IPC RPMsg implements IPCRPMsg inter-core communication based on the shared memory SM1;

[0017] The universal shared memory SM2 is configured in the DDR area, and all AMP heterogeneous multi-cores can access the universal shared memory SM2;

[0018] The device shared memory SM3 is configured to the MSRAM area, multiple cores share the same physical device, the device communication information of each core is recorded in the device shared memory SM3, and the physical device output is realized by enabling the CPU with the information reading function.

[0019] Preferably, the universal shared memory SM2 uses spinlock technology to synchronize multi-core operations and prevent multi-core access conflicts.

[0020] Preferably, the IPC RPMsg implements the message sending and receiving interface through RPMsg based on Mailbox and VRing, Mailbox manages interrupts, and VRing manages data;

[0021] The VRing is a shared memory used for communication between two CPUs, and VRing is unidirectional and visible to both CPUs; there are two VRings between every two CPUs, one dedicated to caching messages sent to the remote CPU, and the other dedicated to caching messages received from the remote CPU.

[0022] According to the present invention, a multi-core AMP architecture inter-core communication system based on a high-security embedded real-time operating system includes:

[0023] Module M1: Runs a highly secure embedded real-time operating system on an AMP architecture multi-core platform;

[0024] Module M2: Based on IPC Notify, it completes two handshake communications with all other cores through interrupts;

[0025] Module M3: Each core implements inter-core communication based on IPC Notify, supporting small data volume interaction that meets preset conditions;

[0026] Module M4: Each core implements inter-core communication based on IPC RPMsg, supporting large data volume interaction that meets preset conditions.

[0027] Preferably, the module M2 adopts:

[0028] Module M2.1: Initialize configuration, list all core names that need to be synchronized with the current core;

[0029] Module M2.2: Synchronize all cores by completing two handshake communications with each core in the list.

[0030] Preferably, the shared memory includes: a shared memory SM1, a general shared memory SM2 and a device shared memory SM3;

[0031] The shared memory SM1 is configured to the MSRAM area, and the IPC RPMsg implements IPCRPMsg inter-core communication based on the shared memory SM1;

[0032] The universal shared memory SM2 is configured in the DDR area, and all AMP heterogeneous multi-cores can access the universal shared memory SM2;

[0033] The device shared memory SM3 is configured to the MSRAM area, multiple cores share the same physical device, the device communication information of each core is recorded in the device shared memory SM3, and the physical device output is realized by enabling the CPU with the information reading function.

[0034] Preferably, the universal shared memory SM2 uses spinlock technology to synchronize multi-core operations and prevent multi-core access conflicts.

[0035] Preferably, the IPC RPMsg implements the message sending and receiving interface through RPMsg based on Mailbox and VRing, Mailbox manages interrupts, and VRing manages data;

[0036] The VRing is a shared memory used for communication between two CPUs, and VRing is unidirectional and visible to both CPUs; there are two VRings between every two CPUs, one dedicated to caching messages sent to the remote CPU, and the other dedicated to caching messages received from the remote CPU.

[0037] Compared with the prior art, the present invention has the following beneficial effects:

[0038] 1. Use IPC Notify for inter-core synchronization, so that users do not need to worry about the startup order of AMP heterogeneous multi-core systems, and focus on the development of user inter-core communication applications;

[0039] 2. The two-way handshake process between IPC Notify cores is designed as an interface, which greatly simplifies the complexity of user applications and reduces the effort users need to spend on inter-core synchronization;

[0040] 3. For messages with small data volumes, IPC Notify interrupts are used for inter-core communication, which is suitable for scenarios with sub-microsecond delays;

[0041] 4. IPC RPMsg is based on Mailbox interrupts and inter-core shared memory communication, supports large data volume interaction, and is more efficient than inter-core communication using simple shared memory;

[0042] 5. To address the time domain conflict problem of AMP heterogeneous multi-core accessing common shared memory, the spinlock mechanism is used to synchronize multi-core operations on shared memory and prevent conflicts in multi-core access to shared memory;

[0043] 6. Support multiple cores to share the same physical device, saving hardware costs and simplifying hardware design;

[0044] 7. The CPU runs the certified version of ReWorks' high-security embedded real-time operating system. The ReWorks Cert2 real-time operating system complies with the functional safety standards of rail transit (50128SIL4), industrial control (61508SIL3), nuclear power instrumentation and control (60880) and medical equipment (62304), and ensures the real-time performance of tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0046] Figure 1 Schematic diagram of the inter-core communication system of a multi-core AMP architecture based on a high-security embedded real-time operating system.

[0047] Figure 2 Maps are allocated for IPC RPMsg shared memory SM1, general shared memory SM2, and debug serial port shared memory SM3.

[0048] Figure 3 This is the IPC Notify message protocol diagram.

[0049] Figure 4 This is the IPC RPMsg message protocol diagram.

[0050] Figure 5 This is the IPC Notify inter-core synchronization diagram.

[0051] Figure 6 This is the IPC Notify and IPC RPMsg inter-core communication interaction diagram.

[0052] Figure 7 This is the spinlock register state diagram.

[0053] Figure 8 This is the debugging serial port information protocol diagram. DETAILED DESCRIPTION

[0054] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0055] The present invention provides a multi-core AMP architecture inter-core communication method and system based on a high-security embedded real-time operating system, including: running Ruihua high-security embedded real-time operating system certified versions on AMP heterogeneous multi-core platforms respectively, providing functional safety while ensuring the real-time performance of tasks. Two driver interface mechanisms, IPC Notify and IPC RPMsg, are provided to improve the real-time performance of inter-core communication in the multi-core AMP architecture. IPC Notify transmits messages based on the HW mailbox of HW fifo and interrupts the reception of core messages, with low latency; it supports heterogeneous multi-core synchronization functions, so that users do not need to care about the startup sequence of the AMP heterogeneous multi-core system, and can focus on the development of user inter-core communication applications. IPC RPMsg provides a channel-based bidirectional communication link between cores, supporting large-scale data communication and interaction between cores. A general shared memory area is configured, and spinlock technology is used to synchronize multi-core operations and prevent multi-core access conflicts. A method for multi-cores to share the same physical device is provided to solve the problem of insufficient device hardware resources.

[0056] Example 1

[0057] In view of the defects in the prior art, the object of the present invention is to provide a multi-core AMP architecture inter-core communication method and system based on a high-security embedded real-time operating system.

[0058] The multi-core AMP architecture inter-core communication method based on a high-security embedded real-time operating system includes:

[0059] The certified version of ReWorks Cert2 real-time operating system with high security embedded system is run on the AMP architecture multi-core platform, which complies with the functional safety standards of rail transit (50128SIL4), industrial control (61508SIL3), nuclear power instrumentation and control (60880) and medical equipment (62304). ReWorks Cert2 real-time operating system is used for safety-critical applications and supports task priority scheduling and time slice rotation.

[0060] Provides two driver interface mechanisms: IPC Notify and IPC RPMsg;

[0061] IPC Notify: A CPU uses a low-level hardware interrupt mechanism to interrupt or notify another CPU, which can be used for synchronization between heterogeneous cores. It also supports users to send up to 28 bits of messages along with the interrupt; among which, bit

[31] -bit

[28] is the client core ID, and bit

[27] -bit[0] is the user message;

[0062] More specifically, the IPCNotify, each core supports up to 16 client IDs for receiving IPC Notify messages, where ID number 1 is dedicated to inter-core synchronization, i.e., for two-way handshake communication; ID number 0 is dedicated to inter-core IPC RPMsg communication; user IPC Notify applications are not available;

[0063] The first condition for inter-core communication is to ensure that all cores have completed system initialization and entered the operating system, which specifically includes: completing two-way handshake communication with all other cores through interrupts based on IPC Notify, including: the first step is to initialize the configuration and list the names of all cores that need to be synchronized with the current core; the second step is to synchronize all cores by handshaking twice with each core in the list, that is, sending synchronization messages to all cores in the list and waiting for and confirming synchronization messages from all cores in the list. If and only if the current core and all cores in the list have completed sending synchronization messages, receiving and confirming each other's synchronization messages, will they return and enter the user application, thus ensuring that all cores are at the same starting point, that is, executing the user application after the system initialization is completed. The two-way handshake process is designed as an interface, which greatly simplifies the complexity of the user application. Shared memory includes: IPC RPMsg shared memory SM1, general shared memory SM2 and debug serial port shared memory SM3; IPC RPMsg implements IPC RPMsg inter-core communication based on shared memory SM1, spinlock manages general shared memory SM2, debug serial port accesses corresponding shared memory SM3, and IPC Notify implements inter-core synchronization to provide a stable and reliable software environment. Otherwise, if the system is not fully prepared, the state of the peer core will be uncertain and inconsistent every time it communicates with the peer core, and the IPC RPMsg shared memory SM1, general shared memory SM2, and debug serial port shared memory SM3 messages will be maliciously overwritten, the operations on both ends will be out of sync, and the communication will be uncontrollable.

[0064] IPC RPMsg: Based on Mailbox and VRing, the RPMsg module implements the message sending and receiving interface. Mailbox manages interrupts, and VRing manages data.

[0065] More specifically, the IPC RPMsg, VRing is a shared memory used for communication between two CPUs. VRing is unidirectional and visible to both CPUs. There are two VRings between every two CPUs, one dedicated to caching messages sent to the remote CPU, and the other dedicated to caching messages received from the remote CPU;

[0066] For the IPC RPMsg, the user can configure the sending properties according to the actual application needs, that is, whether to allow a new message to be sent when the last message sent has not been read by the other party. The user only needs to configure the number of message buffers during initialization. Equal to 1 means no, and greater than 1 means yes.

[0067] Configure the general shared memory SM2 and use the spinlock technology to synchronize multi-core operations and prevent multi-core access conflicts. Figure 7 As shown, the spinlock supports 256 locks numbered 0-255, provides lock acquisition and unlock interfaces, and only one core can acquire the same lock at the same time. When the state of lock N is unoccupied (idle), reading the lock register returns 0 (indicating idle state) and sets the current lock to occupied (locked), and the lock acquisition is successful; when the state of lock N is occupied (locked), reading the lock register returns 1 (locked state) and does not change the lock state, and the lock acquisition fails.

[0068] Multiple cores share the same physical device. For example, the serial port is used to configure the debug serial port shared memory SM3. The multi-core shared debug serial port function records the debug information into the shared memory SM3. The user can decide which core manages the hardware debug serial port, that is, the core that performs the serial port driver initialization operation (opens the serial port). At this time, the debug information corresponding to the core to which the serial port belongs will not be written into the shared memory SM3, but will be directly output from the serial port. The debug information corresponding to other cores will be written into the shared memory SM3, and will eventually be read from the shared memory SM3 by the core to which the serial port belongs and output to the terminal through the serial port. The output format of the shared memory debug information is "CPU ID + timestamp + application information", which is convenient for distinguishing the debug information of the corresponding core.

[0069] The serial port driver is divided into three operations: open, write and read:

[0070] Open, that is, debug serial port hardware initialization, including setting serial port clock, baud rate, data bit, stop bit, parity bit;

[0071] There are two types of writing: (1) writing to the debug shared memory SM3; (2) writing to the debug serial port and outputting to the terminal;

[0072] Read, read from the debug serial port shared memory SM3, and output to the terminal.

[0073] Application operations are divided into two parts: writing and reading:

[0074] The write operation steps include:

[0075] Initialize the debug information shared memory writing program corresponding to the current CPU;

[0076] Call the debug information output interface.

[0077] The read operation steps include:

[0078] Initialize the reading program corresponding to the entire debug information shared memory SM3 and create a read buffer task;

[0079] Point to the debug output serial port corresponding to the current CPU;

[0080] Call the debug information output interface.

[0081] The present invention also provides a multi-core AMP architecture inter-core communication system based on a high-security embedded real-time operating system. The multi-core AMP architecture inter-core communication system based on a high-security embedded real-time operating system can be implemented by executing the process steps of the multi-core AMP architecture inter-core communication method based on the high-security embedded real-time operating system, that is, those skilled in the art can understand the multi-core AMP architecture inter-core communication method based on the high-security embedded real-time operating system as a preferred implementation of the multi-core AMP architecture inter-core communication system based on the high-security embedded real-time operating system.

[0082] Example 2

[0083] Embodiment 2 is a preferred embodiment of Embodiment 1

[0084] The overall framework of the present invention is as follows Figure 1 As shown, the specific implementation method is described by taking TI's AM64x processor as an example. The multi-core AMP architecture is adopted: the ReWorks Cert2.0 for ARM64 real-time operating system is deployed on the Arm Cortex-A53, and the ReWorks Cert2.0 for ARM32 real-time operating system is deployed on the Arm Cortex-R5F00 and Arm Cortex-R5F10, and different user applications are run on each core. AM64x has 2MB MSRAM and 2GB DDR available for configuring the user IPC RPMsg shared memory SM1. Based on the fast access speed of MSRAM, the IPC RPMsg shared memory SM1 is configured to the MSRAM interval, as shown in FIG. Figure 2 As shown, each VRing is 8KB in size; the general shared memory SM2 is 256MB in total and is located in the DDR area; the debug shared memory SM3 is 6KB in total, 2KB for each core and is located in the MSRAM area.

[0085] The IPC Notify message contains two parts: the client core ID and the data. Figure 3 , bit

[31] -bit

[28] is the client core ID, and bit

[27] -bit[0] is the user message.

[0086] The IPC RPMsg message structure consists of two parts: the message header and the data. Figure 4 As shown. It includes 32-bit source (sender) endpoint number, 32-bit destination (receiver) endpoint number, 32-bit source core ID number (reserved), 16-bit effective user data length, and 16-bit identifier (reserved). Each VRing begins with a message header, and this space is not available to users.

[0087] The inter-core synchronization process is as follows Figure 5 After each core enters the system, it initializes the configuration of the core name list that needs to be synchronized between cores, and then calls IpcNotify_SyncAll to send synchronization messages to all other cores through interrupts, and then waits for synchronization messages from all other cores. After completion, it enters the inter-core communication stage.

[0088] Take the inter-core communication between Arm Cortex-A53 and Arm Cortex-R5F00 as an example. Figure 6 :

[0089] IPC Notify inter-core communication, the user calls the Notify_Send interface on the Arm Cortex-A53 side to send inter-core messages to the Arm Cortex-R5F00 side. The IPC Notify module checks whether the Mailbox hardware fifo corresponding to the Arm Cortex-R5F00 core is empty. If it is not empty, it will keep polling and waiting. If it is empty, it will press Figure 3 The IPC Notify message protocol shown combines the user message and the core ID of the Arm Cortex-R5F00 into a complete 32-bit message. It is then written into the Mailbox hardware fifo corresponding to the Arm Cortex-R5F00 core, triggering the Mailbox interrupt of the Arm Cortex-R5F00, and notifying the Arm Cortex-R5F00 with client ID 1 that there is a new message to be processed. The Arm Cortex-R5F00 side receives the message by registering the client, and parses the user valid data segment according to the Notify message protocol and returns it to the user buffer.

[0090] IPC RPMsg inter-core communication, initialize and configure the number of IPC RPMsg message buffers to be equal to 1. The user calls the RPMsg_Send interface on the ArmCortex-A53 side to send inter-core messages to the Arm Cortex-R5F00 side. The IPC RPMsg module then checks whether the VRing used to send the message is empty. If it is not empty, the sending fails. If it is empty, the user buffer data is filled according to the message protocol, that is, the message header is completed. Then the complete message is written to the VRing shared memory buffer, and the Arm Cortex-R5F00 with client ID 0 is notified through the IPC Notify module that there is a new message to be processed, that is, the Mailbox interrupt of the ArmCortex-R5F00 is triggered. The Arm Cortex-R5F00 side calls the RPMsg_Recv interface to receive the message sent from the ArmCortex-A53, parses the user valid data segment according to the RPMsg message protocol, and copies the data from the VRing shared memory buffer to the user buffer in the user RPMsg_Recv interface. The IPC Notify module notifies the Arm Cortex-A53 with client ID 0 to release the VRing that sent the message. At this point, the inter-core communication process from the Arm Cortex-A53 to the Arm Cortex-R5F00 is completed.

[0091] For the common shared memory SM2 area accessible to all AMP heterogeneous multi-cores, spinlock technology is used to prevent the uncertainty caused by multi-cores operating the same address at the same time during program execution. For example, when Arm Cortex-A53, Arm Cortex-R5F00 and Arm Cortex-R5F10 all need to access the same shared memory area P1, a common lock L1 is configured for the area. Arm Cortex-A53 obtains the lock L1 status before operating P1. If it returns 0, P1 can be read and written; if it returns 1, it means that the lock is occupied and Arm Cortex-A53 cannot access P1. The lock status is polled until it returns 0. Similarly, Arm Cortex-R5F00 and Arm Cortex-R5F10 also obtain the lock L1 status before operating P1. If it returns 1, the lock status is polled until it returns 0 before P1 can be read and written. In this way, the synchronization of reading and writing common shared memory SM2 between AMP heterogeneous multi-cores is guaranteed, and conflicts in accessing common shared memory by multi-cores are prevented.

[0092] like Figure 8It is the protocol for shared memory debugging serial port information, including a 32-bit flag indicating that the shared memory buffer corresponding to the current core is valid, a 32-bit read information length information, a 32-bit write information length information, a 32-bit reserved information, and a data buffer (including CPU ID, timestamp, and application information). Therefore, the actual message buffer size available for each core is 2KB-16B. If Arm Cortex-R5F00 is selected to manage the debug serial port, Arm Cortex-R5F00 opens the debug serial port driver. When the user wants to output the debugging information of Arm Cortex-A53, the debugging information shared memory writing program corresponding to Arm Cortex-A53 must be initialized first, including the Arm Cortex-A53 shared memory writing buffer (i.e. 0x701D1000-0X701D1800), the validity of the shared memory buffer, and the CPU ID corresponding to the current core, which are used to fill in the message protocol. Then the DebugP_log interface is called to fill in the application information to be printed. Here, the debugging information is actually written to the debugging shared memory area corresponding to Arm Cortex-A53, including obtaining the current timestamp. The same is true for Arm Cortex-R5F10. When the user wants to output the debugging information of Arm Cortex-R5F00, first initialize the reading program corresponding to the entire debug shared memory SM3, including the number of cores to be read and the starting address of the debug shared memory corresponding to each core. At the same time, create a read buffer SM3 task. Then specify the debug output serial port corresponding to the current core as the shared debug serial port, which is achieved by setting the global identifier shmLog_reader to 1. Finally, call the DebugP_log interface to output the debug information corresponding to the current core, and read the debug information from the debug shared memory and output it to the console. Arm Cortex-A53 and Arm Cortex-R5F10 do not specify the shared debug serial port, so the corresponding global identifier shmLog_reader is 0. When each core calls the DebugP_log interface, it will use the global identifier shmLog_reader to decide whether to write data to the corresponding debug information shared memory or output data directly from the debug serial port.

[0093] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0094] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A multi-core AMP architecture inter-core communication method based on a high-security embedded real-time operating system, characterized in that: include: Step S1: running a high-security embedded real-time operating system on the AMP architecture multi-core platform; Step S2: Based on IPC Notify, complete two-way handshake communication with all other cores through interruption; Step S3: Each core implements inter-core communication based on IPC Notify, supporting small data volume interaction that meets preset conditions; Step S4: Each core implements inter-core communication based on IPC RPMsg, supporting large data volume interaction that meets preset conditions.

2. The multi-core AMP architecture inter-core communication method based on a high-security embedded real-time operating system according to claim 1 is characterized in that: The step S2 adopts: Step S2.1: Initialize the configuration and list all the core names that need to be synchronized with the current core; Step S2.2: Synchronize all cores by completing two handshake communications with each core in the list.

3. The multi-core AMP architecture inter-core communication method based on a high-security embedded real-time operating system according to claim 1 is characterized in that: Shared memory includes: shared memory SM1, general shared memory SM2 and device shared memory SM3; The shared memory SM1 is configured to the MSRAM area, and the IPC RPMsg implements IPC RPMsg inter-core communication based on the shared memory SM1; The universal shared memory SM2 is configured in the DDR area, and all AMP heterogeneous multi-cores can access the universal shared memory SM2; The device shared memory SM3 is configured to the MSRAM area, multiple cores share the same physical device, the device communication information of each core is recorded in the device shared memory SM3, and the physical device output is realized by enabling the CPU with the information reading function.

4. The multi-core AMP architecture inter-core communication method based on a high-security embedded real-time operating system according to claim 1, characterized in that: The general shared memory SM2 uses spinlock technology to synchronize multi-core operations and prevent multi-core access conflicts.

5. The multi-core AMP architecture inter-core communication method based on a high-security embedded real-time operating system according to claim 1, characterized in that: The IPC RPMsg implements the message receiving and sending interface based on Mailbox and VRing through RPMsg, Mailbox manages interrupts, and VRing manages data; The VRing is a shared memory used for communication between two CPUs, and VRing is unidirectional and visible to both CPUs; there are two VRings between every two CPUs, one dedicated to caching messages sent to the remote CPU, and the other dedicated to caching messages received from the remote CPU.

6. A multi-core AMP architecture inter-core communication system based on a high-security embedded real-time operating system, characterized in that: include: Module M1: Runs a highly secure embedded real-time operating system on an AMP architecture multi-core platform; Module M2: Based on IPC Notify, it completes two handshake communications with all other cores through interrupts; Module M3: Each core implements inter-core communication based on IPC Notify, supporting small data volume interaction that meets preset conditions; Module M4: Each core implements inter-core communication based on IPC RPMsg, supporting large data volume interaction that meets preset conditions.

7. The multi-core AMP architecture inter-core communication system based on a high-security embedded real-time operating system according to claim 6 is characterized in that: The module M2 adopts: Module M2.1: Initialize configuration, list all core names that need to be synchronized with the current core; Module M2.2: Synchronize all cores by completing two handshake communications with each core in the list.

8. The multi-core AMP architecture inter-core communication system based on a high-security embedded real-time operating system according to claim 6, characterized in that: Shared memory includes: shared memory SM1, general shared memory SM2 and device shared memory SM3; The shared memory SM1 is configured to the MSRAM area, and the IPC RPMsg implements IPC RPMsg inter-core communication based on the shared memory SM1; The universal shared memory SM2 is configured in the DDR area, and all AMP heterogeneous multi-cores can access the universal shared memory SM2; The device shared memory SM3 is configured to the MSRAM area, multiple cores share the same physical device, the device communication information of each core is recorded in the device shared memory SM3, and the physical device output is realized by enabling the CPU with the information reading function.

9. The multi-core AMP architecture inter-core communication system based on a high-security embedded real-time operating system according to claim 6, characterized in that: The general shared memory SM2 uses spinlock technology to synchronize multi-core operations and prevent multi-core access conflicts.

10. The multi-core AMP architecture inter-core communication system based on a high-security embedded real-time operating system according to claim 6, characterized in that: The IPC RPMsg implements the message receiving and sending interface based on Mailbox and VRing through RPMsg, Mailbox manages interrupts, and VRing manages data; The VRing is a shared memory used for communication between two CPUs, and VRing is unidirectional and visible to both CPUs; there are two VRings between every two CPUs, one dedicated to caching messages sent to the remote CPU, and the other dedicated to caching messages received from the remote CPU.

Images