Preload block device implementation method and device suitable for multi-core heterogeneous hardware system

Abstract

The present invention discloses a method and apparatus for implementing preloading block devices for multi-core heterogeneous hardware systems, relating to the field of storage technology. The method comprises preloading block device data to a pre-applied memory address via the SBL; generating a real block device based on the block device driver registration of the main system and pointing it to the storage device, and associating the generated real block device with the virtual block device server of the main system; driving the memory block device module of the secondary system to generate a memory block device, and associating the generated memory block device with the corresponding virtual block device to implement preloading of the block device. The present invention can preload key data during the system startup phase, significantly shortening the startup time, ensuring startup performance while meeting data integrity requirements and improving storage performance.

Description

Technical Field

[0001] The present application relates to the field of storage technology, and in particular to a method and apparatus for implementing a preloaded block device suitable for a multi-core heterogeneous hardware system. Background Art

[0002] In a multi-core heterogeneous system-on-chip (SoC), if there is only one storage device, generally only the primary system can directly access the storage device. When a secondary system needs to access a block device for rapid business startup, the following methods are commonly used: 1. System virtualization: Virtualization is used to virtualize the entire chip and the storage at the same time; 2. Device virtualization: The primary system shares the storage device with the secondary system, which then accesses the storage device through the primary system via inter-core communication; 3. Memory block device: The primary system preloads the block device into memory, and the secondary system accesses it as a memory block device.

[0003] In actual applications, when the secondary system needs to start quickly and support persistent storage, the current approach has the following shortcomings:

[0004] (1) For system virtualization, the entire chip is virtualized through virtualization technology, and the storage is also virtualized. This method requires modifying the entire software system architecture, which is costly;

[0005] (2) For device virtualization, the main system shares the storage device with the secondary system through sharing, and the secondary system then accesses the storage device through the main system through inter-core communication. This method requires waiting for the main system to start up before accessing the storage device through the main system. Although it can meet the needs of persistent storage, it does not meet the needs of fast startup.

[0006] (3) For memory block devices, the main system preloads the block device into the memory, and the secondary system accesses it as a memory block device. Although this method can meet the requirements of fast startup, it cannot save data when the system is powered off, and persistent storage cannot be achieved. Summary of the Invention

[0007] The present application provides a method and apparatus for implementing a preloaded block device suitable for a multi-core heterogeneous hardware system, which can preload critical data during the system startup phase, significantly shorten the startup time, and ensure startup performance while meeting data integrity requirements and improving storage performance.

[0008] In a first aspect, an embodiment of the present application provides a method for implementing a preloading block device applicable to a multi-core heterogeneous hardware system. The method for implementing a preloading block device applicable to a multi-core heterogeneous hardware system includes:

[0009] Preload block device data to pre-requested memory addresses through SBL;

[0010] A real block device is generated based on the block device driver registration of the main system and points to the storage device, and the virtual block device server of the main system is associated with the generated real block device;

[0011] The memory block device module of the secondary system is driven to generate a memory block device, and the generated memory block device is associated with the corresponding virtual block device to realize preloading of the block device.

[0012] In conjunction with the first aspect, in one embodiment,

[0013] The architecture corresponding to the virtual block device includes the main system, secondary system, memory device, and storage device;

[0014] In the architecture corresponding to the virtual block device, the control path is completed by inter-core communication, and the data path is completed by shared memory.

[0015] In conjunction with the first aspect, in one embodiment,

[0016] The inter-core communication is a control link communication method between the main system and the secondary system;

[0017] The shared memory is a memory area accessible only to the primary system and the secondary system.

[0018] In conjunction with the first aspect, in one embodiment, generating a memory block device specifically includes:

[0019] The memory block device module of the secondary system obtains the memory address preloaded with the block device data, registers the memory block device, and binds it to the memory address preloaded with the block device data;

[0020] The memory block device module of the secondary system binds the memory block device to the virtual block device;

[0021] The virtual block device client of the secondary system binds the virtual block device to the real block device.

[0022] In combination with the first aspect, in one embodiment, the method further includes:

[0023] When quickly starting a service to read data streams, the SBL preloads block device data to the pre-requested memory address;

[0024] The memory block device module of the secondary system generates a memory block device;

[0025] The user space of the secondary system reads the generated memory block device, and the memory block device module of the secondary system starts the write-back service.

[0026] In combination with the first aspect, in one embodiment, the method further includes:

[0027] When the business writes data stream in the fast startup mode, the secondary system writes the target data to the memory block device;

[0028] The write-back service of the memory block device module of the secondary system waits for the primary system to start up and then writes the target data back to the virtual block device;

[0029] The virtual block device client of the secondary system sends target data to the virtual block device server of the primary system;

[0030] The virtual block device server of the main system writes the target data to the real block device.

[0031] In combination with the first aspect, in one implementation, the target data is data generated when there is an action of writing a block device.

[0032] In a second aspect, an embodiment of the present application provides a preloading block device implementation apparatus applicable to a multi-core heterogeneous hardware system, the preloading block device implementation apparatus applicable to a multi-core heterogeneous hardware system comprising:

[0033] Loading module, which is used to preload block device data to pre-requested memory addresses through SBL;

[0034] A generation module is used to generate a real block device based on the block device driver registration of the main system and point it to the storage device, and the virtual block device server of the main system is associated with the generated real block device;

[0035] The execution module is used to drive the memory block device module of the secondary system to generate a memory block device, and associate the generated memory block device with the corresponding virtual block device to realize preloading of the block device.

[0036] In conjunction with the second aspect, in one embodiment,

[0037] The architecture corresponding to the virtual block device includes the main system, secondary system, memory device, and storage device;

[0038] In the architecture corresponding to the virtual block device, the control path is completed by inter-core communication, and the data path is completed by shared memory.

[0039] In conjunction with the second aspect, in one embodiment,

[0040] The inter-core communication is a control link communication method between the main system and the secondary system;

[0041] The shared memory is a memory area accessible only to the primary system and the secondary system.

[0042] The beneficial effects of the technical solutions provided in the embodiments of the present application include:

[0043] By optimizing the startup process and storage device management mechanism, the system can achieve fast startup and persistent storage capabilities. By designing an efficient block device preloading mechanism, key data can be loaded in advance during the system startup phase, significantly shortening the startup time. It also provides a reliable persistent storage management strategy to ensure startup performance while meeting data integrity requirements and improving storage performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is a flowchart of a method for implementing a preloaded block device in a multi-core heterogeneous hardware system according to the present application;

[0045] Figure 2 Schematic diagram of software architecture;

[0046] Figure 3 This is a schematic diagram of the hardware path;

[0047] Figure 4 Generates schematics for memory block devices;

[0048] Figure 5 It is a data flow diagram;

[0049] Figure 6 This is a functional module diagram of a pre-loaded block device implementation apparatus applicable to a multi-core heterogeneous hardware system of the present application;

[0050] Figure 7 This is a hardware structure diagram of a preloaded block device implementation device applicable to a multi-core heterogeneous hardware system in this application. DETAILED DESCRIPTION

[0051] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0052] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0053] In the first aspect, an embodiment of the present application provides a method for implementing a preloaded block device suitable for a multi-core heterogeneous hardware system. The method is suitable for scenarios in which a secondary system has a fast startup service that needs to access a block device and the service needs to support persistent storage capabilities in a multi-core heterogeneous system-on-chip, and can simultaneously meet the needs of fast startup and persistent storage.

[0054] In one embodiment, referring to Figure 1 , Figure 1 This is a flow chart of the implementation method of the pre-loaded block device applicable to multi-core heterogeneous hardware systems. Figure 1 As shown, the implementation method of the preload block device applicable to a multi-core heterogeneous hardware system includes:

[0055] S1: Preload block device data to the pre-requested memory address through SBL (Secondary Bootloader);

[0056] S2: Generate a real block device based on the block device driver registration of the main system and point it to the storage device, and the virtual block device server of the main system associates the generated real block device;

[0057] S3: Drive the memory block device module of the secondary system to generate a memory block device, and associate the generated memory block device with the corresponding virtual block device to implement preloading of the block device.

[0058] For details, see Figure 2 and Figure 3 As shown in the figure, SBL preloads block device data to the pre-applied memory address, then the block device driver of Linux1 (main system) registers to generate a real block device and points to the storage device, the virtual block device server of Linux1 associates the generated real block device, and the memory block device module of Linux2 (secondary system) generates a memory block device and associates the generated memory block device with the corresponding virtual block device.

[0059] Figure 2 In the example, / dev / sdxx represents a real block device, block represents a block device driver, virtblk_service represents a virtual block device server, UFS represents universal flash storage, DDR represents double rate synchronous dynamic random access memory, start_addr represents the starting address, end_addr represents the ending address, RPMsg represents a communication protocol based on shared memory, that is, inter-core communication, SHM represents shared memory, load_date_service represents the boot loader server, / dev / virtblk represents a virtual block device, virtblk_client represents a virtual block device client, ramblk represents a memory block device module, and the memory block device module is a special block device driver implemented in the Linux kernel. It uses memory space to simulate disk storage characteristics and provide block-based random access capabilities. kernel represents the kernel, and / dev / ramblk represents a memory block device.

[0060] Figure 3In the figure, Mailbox represents a mechanism for communication between different processor cores, that is, inter-core communication, read represents reading, write represents writing, Filesystem represents file system, Hardware represents hardware, Storage represents storage, Memory represents memory, data path represents data path, and command path represents command pool folder path.

[0061] It should be noted that the block device in this application refers to a storage device that can be read and written in fixed-size blocks (usually 512 bytes or 4KB). Block devices are usually used to implement file systems and manage data storage and access. Common block devices include hard disks, solid-state drives (SSDs), UFS, eMMC, etc. In Linux systems, they usually appear as device nodes such as / dev / sda0, sda1, sdb0, sdb1. Block devices are usually used to create file systems, such as ext4, NTFS, FAT, etc., to provide file organization, storage, and access methods. The block device of the Linux system is an abstract layer in the Linux kernel for managing storage devices. It is a software concept that ultimately points to a hardware device. Storage devices refer to hardware concepts, and common ones include hard disks, solid-state drives (SSDs), UFS, eMMC, etc.

[0062] Further, in one embodiment, see Figure 2 As shown in Figure 1, the architecture design for a virtual block device primarily consists of a primary system (which can directly access hardware storage devices), a secondary system (which cannot directly access hardware storage devices), memory devices (DDR), and storage devices (UFS, eMMC, etc.). In the architecture corresponding to a virtual block device, inter-core communication completes the control path, and shared memory completes the data path.

[0063] Inter-core communication is the control link communication method between the primary and secondary systems and is implemented by low-level hardware interrupts. Shared memory is a memory area accessible only to the primary and secondary systems.

[0064] The following is an example of the control path.

[0065] When Linux2 wants to read data, it sends Mailbox / RPMsg to Linux1. After receiving Mailbox / RPMsg, Linux1 puts the corresponding data into shared memory (SHM). Then Linux1 sends Mailbox / RPMsg to Linux2 to notify Linux2 that the data has been read. Linux2 reads the data from the shared memory (SHM).

[0066] Further, in one embodiment, see Figure 4As shown in the figure, the generation of a memory block device with persistence capability includes:

[0067] S301: The memory block device module of the secondary system obtains a memory address preloaded with block device data, registers the memory block device, and binds it to the memory address preloaded with block device data;

[0068] S302: The memory block device module of the secondary system binds the memory block device to the virtual block device;

[0069] S303: The virtual block device client of the secondary system binds the virtual block device to the real block device.

[0070] Specifically, the memory block device module of the secondary system obtains the memory address preloaded with block device data, then registers the memory block device and binds it to the memory address preloaded with block device data. After that, the memory block device module of the secondary system binds the memory block device to the virtual block device. After that, the virtual block device client of the secondary system binds the virtual block device to the real block device.

[0071] Figure 4 In the command, ramblock init indicates the initialization of the memory block device module, register blk indicates the registration of the block device, writeback service indicates the writeback server, and writeback indicates writeback.

[0072] Furthermore, in one embodiment, the method for implementing a preload block device applicable to a multi-core heterogeneous hardware system of the present application further includes:

[0073] a1: When quickly starting a service to read data streams, the SBL preloads block device data to a pre-requested memory address;

[0074] a2: The memory block device module of the secondary system generates a memory block device;

[0075] a3: The user space of the secondary system reads the generated memory block device, and the memory block device module of the secondary system starts the write-back service.

[0076] See Figure 5 As shown, for the read data flow of the quick startup service, the SBL preloads the block device data to the pre-applied memory address, and then the memory block device module of the secondary system generates a memory block device. After that, the user space of the secondary system reads the generated memory block device, and the memory block device module of the secondary system starts the write-back service.

[0077] Furthermore, in one embodiment, the method for implementing a preload block device applicable to a multi-core heterogeneous hardware system of the present application further includes:

[0078] b1: When the service writes data flow quickly, the secondary system writes the target data to the memory block device;

[0079] b2: The write-back service of the memory block device module of the secondary system waits for the primary system to start up and then writes the target data back to the virtual block device;

[0080] b3: The virtual block device client of the secondary system sends the target data to the virtual block device server of the primary system;

[0081] b4: The virtual block device server of the main system writes the target data to the real block device.

[0082] See Figure 5 As shown, for the write data flow of the quick startup service, the secondary system writes the target data to the memory block device, and then the write-back service of the memory block device module of the secondary system waits for the main system to complete the startup, and then writes the target data back to the virtual block device. Then the virtual block device client of the secondary system sends the target data to the virtual block device server of the main system, and then the virtual block device server of the main system writes the target data to the real block device.

[0083] It should be noted that the target data is the data generated when there is a block device write action. That is, when there is a block device write action, data changes will occur. The data can be file modifications, file system logs, etc.

[0084] For example, when a block device has a file system, after mounting the file system, you can read and write files in it. For example, if you write the string "hello world" to the test file / data / test.txt, then "hello world" is the data. When a block device does not have a file system, you can directly operate the block device. For example, you can directly clear the block device: dd if= / dev / zero of= / dev / ramblk_xx, where / dev / zero represents all zero data.

[0085] The embodiment of the present application is suitable for implementing a preloaded block device for a multi-core heterogeneous hardware system. By optimizing the startup process and storage device management mechanism, the system can achieve fast startup and persistent storage capabilities. By designing an efficient block device preloading mechanism, key data can be loaded in advance during the system startup phase, significantly shortening the startup time. A reliable persistent storage management strategy is provided to ensure startup performance while meeting data integrity requirements and improving storage performance.

[0086] In a second aspect, an embodiment of the present application further provides a preloading block device implementation apparatus suitable for a multi-core heterogeneous hardware system.

[0087] In one embodiment, referring to Figure 6 , Figure 6 This is a functional module diagram of a preload block device implementation device applicable to a multi-core heterogeneous hardware system. Figure 6 As shown, the pre-loading block device implementation apparatus suitable for multi-core heterogeneous hardware systems includes: a loading module, a generation module, and an execution module.

[0088] The loading module is used to preload block device data to the pre-applied memory address through SBL; the generation module is used to generate a real block device based on the block device driver registration of the main system and point to the storage device, and the virtual block device server of the main system is associated with the generated real block device; the execution module is used to drive the memory block device module of the secondary system to generate a memory block device, and associate the generated memory block device with the corresponding virtual block device to realize the preloading of the block device.

[0089] In this application, the architecture corresponding to the virtual block device includes a primary system, a secondary system, a memory device, and a storage device;

[0090] In the architecture corresponding to the virtual block device, the control path is completed by inter-core communication, and the data path is completed by shared memory.

[0091] In the present application, the inter-core communication is a control link communication mode between the main system and the secondary system; the shared memory is a memory area accessible only to the main system and the secondary system.

[0092] On the third aspect, an embodiment of the present application provides a preloading block device implementation device suitable for a multi-core heterogeneous hardware system. The preloading block device implementation device suitable for a multi-core heterogeneous hardware system can be a personal computer (PC), a laptop computer, a server, and other devices with data processing functions.

[0093] Reference Figure 7 , Figure 7 Schematic diagram of the hardware structure of a preload block device implementation device applicable to a multi-core heterogeneous hardware system involved in the embodiment of the present application. In the embodiment of the present application, the preload block device implementation device applicable to a multi-core heterogeneous hardware system may include a processor, a memory, a communication interface, and a communication bus.

[0094] The communication bus may be of any type and is used to interconnect the processor, memory, and communication interface.

[0095] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces. These interfaces are used to implement preloaded block devices suitable for multi-core heterogeneous hardware systems, interconnecting internal devices and other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet, fiber, or ATM interfaces; user devices can be displays or keyboards.

[0096] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0097] The processor may be a general-purpose processor that can call a preloaded block device implementation program for a multi-core heterogeneous hardware system stored in a memory and execute the preloaded block device implementation method for a multi-core heterogeneous hardware system provided in an embodiment of the present application. For example, the general-purpose processor may be a central processing unit (CPU). The method executed when the preloaded block device implementation program for a multi-core heterogeneous hardware system is called can be referred to the various embodiments of the preloaded block device implementation method for a multi-core heterogeneous hardware system of the present application, and will not be further described here.

[0098] Those skilled in the art will understand that Figure 7 The hardware structure shown in the figure does not constitute a limitation to the present application and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0099] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium.

[0100] The computer-readable storage medium of the present application stores a preloading block device implementation program suitable for a multi-core heterogeneous hardware system, wherein when the preloading block device implementation program suitable for a multi-core heterogeneous hardware system is executed by a processor, the steps of the preloading block device implementation method suitable for a multi-core heterogeneous hardware system as described above are implemented.

[0101] Among them, the method implemented when the preloading block device implementation program applicable to a multi-core heterogeneous hardware system is executed can refer to the various embodiments of the preloading block device implementation method applicable to a multi-core heterogeneous hardware system of this application, and will not be repeated here.

[0102] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit the "first", "second" and "third" to different types.

[0103] In the description of the embodiments of this application, the words "exemplary," "for example," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary," "for example," or "for example" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0104] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0105] In some processes described in the embodiments of the present application, multiple operations or steps are included that appear in a specific order. However, it should be understood that these operations or steps may not be performed in the order in which they appear in the embodiments of the present application or may be performed in parallel. The sequence numbers of the operations are only used to distinguish between different operations, and the sequence numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations or steps may be performed in sequence or in parallel, and these operations or steps may be combined.

[0106] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, or the part that contributes to the existing technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above and includes a number of instructions for enabling a terminal device to execute the methods described in each embodiment of this application.

[0107] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for implementing a preload block device suitable for a multi-core heterogeneous hardware system, characterized in that: The method for implementing a preload block device applicable to a multi-core heterogeneous hardware system includes: Preload block device data to pre-requested memory addresses through SBL; A real block device is generated based on the block device driver registration of the main system and points to the storage device, and the virtual block device server of the main system is associated with the generated real block device; Drive the memory block device module of the secondary system to generate a memory block device, and associate the generated memory block device with the corresponding virtual block device to implement preloading of the block device; The generation of a memory block device specifically includes: The memory block device module of the secondary system obtains the memory address preloaded with the block device data, registers the memory block device, and binds it to the memory address preloaded with the block device data; The memory block device module of the secondary system binds the memory block device to the virtual block device; The virtual block device client of the secondary system binds the virtual block device to the real block device.

2. The method for implementing a preload block device suitable for a multi-core heterogeneous hardware system according to claim 1, characterized in that: The architecture corresponding to the virtual block device includes the main system, secondary system, memory device, and storage device; In the architecture corresponding to the virtual block device, the control path is completed by inter-core communication, and the data path is completed by shared memory.

3. The method for implementing a preload block device suitable for a multi-core heterogeneous hardware system according to claim 2, characterized in that: The inter-core communication is a control link communication method between the primary system and the secondary system; The shared memory is a memory area accessible only to the primary system and the secondary system.

4. The method for implementing a preload block device suitable for a multi-core heterogeneous hardware system according to claim 1, wherein: The method further comprises: When quickly starting a service to read data streams, the SBL preloads block device data to a pre-requested memory address; The memory block device module of the secondary system generates a memory block device; The user space of the secondary system reads the generated memory block device, and the memory block device module of the secondary system starts the write-back service.

5. The method for implementing a preload block device suitable for a multi-core heterogeneous hardware system according to claim 1, wherein: The method further comprises: When the business writes data stream in the fast startup mode, the secondary system writes the target data to the memory block device; The write-back service of the memory block device module of the secondary system waits for the primary system to start up and then writes the target data back to the virtual block device; The virtual block device client of the secondary system sends target data to the virtual block device server of the primary system; The virtual block device server of the main system writes the target data to the real block device.

6. The method for implementing a preload block device suitable for a multi-core heterogeneous hardware system according to claim 5, characterized in that: The target data is the data generated when there is an action of writing a block device.

7. A preload block device implementation device suitable for a multi-core heterogeneous hardware system, characterized in that: The preloading block device implementation device suitable for a multi-core heterogeneous hardware system includes: Loading module, which is used to preload block device data to pre-requested memory addresses through SBL; A generation module is used to generate a real block device based on the block device driver registration of the main system and point it to the storage device, and the virtual block device server of the main system is associated with the generated real block device; an execution module, which is used to drive the memory block device module of the secondary system to generate a memory block device, and associate the generated memory block device with the corresponding virtual block device to implement preloading of the block device; The generation of a memory block device specifically includes: The memory block device module of the secondary system obtains the memory address preloaded with the block device data, registers the memory block device, and binds it to the memory address preloaded with the block device data; The memory block device module of the secondary system binds the memory block device to the virtual block device; The virtual block device client of the secondary system binds the virtual block device to the real block device.

8. The preload block device implementation apparatus for a multi-core heterogeneous hardware system according to claim 7, characterized in that: The architecture corresponding to the virtual block device includes the main system, secondary system, memory device, and storage device; In the architecture corresponding to the virtual block device, the control path is completed by inter-core communication, and the data path is completed by shared memory.

9. The preloading block device implementation apparatus applicable to a multi-core heterogeneous hardware system according to claim 8, characterized in that: The inter-core communication is a control link communication method between the primary system and the secondary system; The shared memory is a memory area accessible only to the primary system and the secondary system.

Images