Data transmission method, device, chip and electronic device for multi-core heterogeneous chips

Abstract

The present application provides a data transmission method for a multi-core heterogeneous chip, which is applied to a multi-core heterogeneous chip, and the multi-core heterogeneous chip includes at least a first hardware domain and a second hardware domain. The method includes: a client located in the first hardware domain sends first data to a first binder driver corresponding to the client; the first binder driver determines the inter-core communication mode of the first data; the first binder driver sends the first data to a server located in the second hardware domain based on the inter-core communication mode; the inter-core communication mode is: the first inter-core communication mode or the second inter-core communication mode; the first inter-core communication mode includes: using on-chip memory to store the first data, and transmitting the first data based on a thread mailbox mailbox interrupt; the second inter-core communication mode includes: using shared memory to store the first data, and transmitting the first data based on a mailbox interrupt. In this way, the latency and load of the multi-core heterogeneous chip can be reduced.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a data transmission method, device, chip and electronic device for multi-core heterogeneous chips. Background Art

[0002] System on Chip (SoC) can be composed of multiple single-core processors or multi-core processors. Multi-core heterogeneous chips are a type of system-level chip. Multi-core heterogeneous chips can include multiple hardware domains. Each hardware domain runs an operating system. There is a need for data interaction between the operating systems. For example, an operating system of a multi-core heterogeneous chip needs to use the data of another operating system of the multi-core heterogeneous chip, or a process on an operating system of a multi-core heterogeneous chip needs to communicate with a process on another operating system of the multi-core heterogeneous chip. In this scenario, data needs to be transmitted between the two hardware domains. Therefore, how to transmit data between the two hardware domains with lower latency and central processing unit (CPU) occupancy is an urgent problem to be solved. Summary of the invention

[0003] The embodiments of the present application provide a data transmission method, device, chip and electronic device for a multi-core heterogeneous chip, which can reduce the latency and load of the multi-core heterogeneous chip.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] In a first aspect, an embodiment of the present application provides a data transmission method for a multi-core heterogeneous chip, the method being applied to a multi-core heterogeneous chip, the multi-core heterogeneous chip comprising at least a first hardware domain and a second hardware domain, the method comprising:

[0006] The client located in the first hardware domain sends first data to a first binder driver corresponding to the client;

[0007] The first binder driver determines the inter-core communication mode of the first data;

[0008] The first binder driver sends the first data to the server located in the second hardware domain based on the inter-core communication mode;

[0009] Among them, the inter-core communication mode is: the first inter-core communication mode or the second inter-core communication mode; the first inter-core communication mode includes: using on-chip memory to store the first data, and transmitting the first data based on mailbox interrupt; the second inter-core communication mode includes: using shared memory to store the first data, and transmitting the first data based on thread mailbox (mailbox) interrupt.

[0010] In some embodiments, the first binder driver determines the inter-core communication mode of the first data, including:

[0011] The first binder driver determines whether the data size of a single transmission of the first data is greater than a first threshold;

[0012] If the data size of the single transmission of the first data is greater than the first threshold, the first binder driver determines that the inter-core communication mode of the first data is the second inter-core communication mode;

[0013] If the data size of a single transmission of the first data is smaller than the first threshold, the first binder driver determines that the inter-core communication mode of the first data is the first inter-core communication mode.

[0014] In some embodiments, the first binder driver sending the first data to the server located in the second hardware domain based on the inter-core communication method includes:

[0015] The first binder driver sends the data transmission request to the second binder driver corresponding to the server based on the inter-core communication mode;

[0016] The second binder driver determines a service process based on the data transmission request;

[0017] The second binder driver converts the first data from user state to kernel state;

[0018] Transmitting the first data in the kernel state from the first binder driver to the second binder driver through the determined inter-core communication mode;

[0019] The second binder driver stores the received first data into the memory space corresponding to the service process.

[0020] In some embodiments, before the client located in the first hardware domain sends the first data to the first binder driver corresponding to the client, the method further includes:

[0021] The client sends the name of the first service to be registered to the first binder driver corresponding to the client;

[0022] The first binder driver determines the service management process based on the name of the first service to be registered;

[0023] Based on the determined service management process, the first service to be registered is registered.

[0024] In some embodiments, registering the first service to be registered based on the determined service management process includes:

[0025] If the service management process is a remote service management process, the first binder driver sends a service message of the first to-be-registered service to a second binder driver corresponding to the remote service management process based on the first inter-core communication mode;

[0026] The second binder driver sends the service message of the first service to be registered to the remote service management process;

[0027] The remote service management process creates a service list in user mode and saves the service message of the first service to be registered.

[0028] In some embodiments, before the client located in the first hardware domain sends the first data to the first binder driver corresponding to the client, the method further includes:

[0029] The server sends the name of the second service to be registered to the second binder driver corresponding to the server;

[0030] The second binder driver determines the service management process based on the name of the second service to be registered;

[0031] Based on the determined service management process, register the second service to be registered.

[0032] In some embodiments, registering the second service to be registered based on the determined service management process includes:

[0033] If the service management process is a remote service management process, the second binder driver sends a service message of the second service to be registered to the first binder driver corresponding to the remote service management process based on the first inter-core communication mode;

[0034] The first binder driver sends the service message of the second service to be registered to the remote service management process;

[0035] The remote service management process creates a service list in user mode and saves the service message of the second service to be registered.

[0036] In some embodiments, before the client located in the first hardware domain sends the first data to the first binder driver corresponding to the client, the method further includes:

[0037] The first binder driver sends a first service request to the second binder driver based on the first inter-core communication mode;

[0038] The second binder driver sends the first service request to a remote service management process corresponding to the second binder driver;

[0039] The remote service management process determines a first target service process based on the first service request, and converts a first remote identifier corresponding to the first target service process into a first local identifier corresponding to the first target service process;

[0040] The remote service management process sends the first local identifier to the second binder driver;

[0041] The second binder driver sends the first local identifier to the first binder driver;

[0042] The first binder driver sends the first local identifier to the client.

[0043] In some embodiments, before the client located in the first hardware domain sends the first data to the first binder driver corresponding to the client, the method further includes:

[0044] The second binder driver sends a second service request to the first binder driver based on the first inter-core communication mode;

[0045] The first binder driver sends the second service request to a remote service management process corresponding to the first binder driver;

[0046] The remote service management process determines a second target service process based on the second service request, and converts a second remote identifier corresponding to the second target service process into a second local identifier corresponding to the second target service process;

[0047] The remote service management process sends the second local identifier to the first binder driver;

[0048] The first binder driver sends the second local identifier to the second binder driver;

[0049] The second binder driver sends the second local identifier to the server.

[0050] In a second aspect, an embodiment of the present application provides a data transmission device of a multi-core heterogeneous chip, the device is located in the multi-core heterogeneous chip, the device includes at least a first hardware domain and a second hardware domain, the first hardware domain includes a client and a first binder driver, and the second hardware domain includes a server;

[0051] The client is used to send first data to the first binder driver;

[0052] The first binder driver is used to determine an inter-core communication mode of the first data, and send the first data to the server based on the inter-core communication mode;

[0053] Among them, the inter-core communication mode is: the first inter-core communication mode or the second inter-core communication mode; the first inter-core communication mode includes: using on-chip memory to store the first data, and transmitting the first data based on mailbox interrupt; the second inter-core communication mode includes: using shared memory to store the first data, and transmitting the first data based on mailbox interrupt.

[0054] In some embodiments, the first binder driver is specifically used to determine whether the data size of a single transmission of the first data is greater than a first threshold;

[0055] If the data size of the single transmission of the first data is greater than the first threshold, the first binder driver determines that the inter-core communication mode of the first data is the second inter-core communication mode;

[0056] If the data size of a single transmission of the first data is smaller than the first threshold, the first binder driver determines that the inter-core communication mode of the first data is the first inter-core communication mode.

[0057] In some embodiments, the first binder driver is specifically used to send the data transmission request to the second binder driver corresponding to the server based on the inter-core communication mode;

[0058] The second binder driver determines a service process based on the data transmission request;

[0059] The second binder driver converts the first data from user state to kernel state;

[0060] Transmitting the first data in the kernel state from the first binder driver to the second binder driver through the determined inter-core communication mode;

[0061] The second binder driver stores the received first data into the memory space corresponding to the service process.

[0062] In some embodiments, the client is used to send the name of the first service to be registered to the first binder driver corresponding to the client;

[0063] The first binder driver determines the service management process based on the name of the first service to be registered;

[0064] Based on the determined service management process, the first service to be registered is registered.

[0065] In some embodiments, if the service management process is a remote service management process, the first binder driver is used to send a service message of the first service to be registered to a second binder driver corresponding to the remote service management process based on the first inter-core communication mode;

[0066] The second binder driver sends the service message of the first service to be registered to the remote service management process;

[0067] The remote service management process creates a service list in user mode and saves the service message of the first service to be registered.

[0068] In some embodiments, the server is further used to send the name of the second service to be registered to the second binder driver corresponding to the server;

[0069] The second binder driver determines the service management process based on the name of the second service to be registered;

[0070] Based on the determined service management process, register the second service to be registered.

[0071] In some embodiments, if the service management process is a remote service management process, the second binder driver is further used to send a service message of the second service to be registered to the first binder driver corresponding to the remote service management process based on the first inter-core communication mode;

[0072] The first binder driver is used to send the service message of the second service to be registered to the remote service management process;

[0073] The remote service management process creates a service list in user mode and saves the service message of the second service to be registered.

[0074] In some embodiments, the first binder driver is further configured to send a first service request to the second binder driver based on the first inter-core communication mode;

[0075] The second binder driver sends the first service request to a remote service management process corresponding to the second binder driver;

[0076] The remote service management process determines a first target service process based on the first service request, and converts a first remote identifier corresponding to the first target service process into a first local identifier corresponding to the first target service process;

[0077] The remote service management process sends the first local identifier to the second binder driver;

[0078] The second binder driver sends the first local identifier to the first binder driver;

[0079] The first binder driver is used to send the first local identifier to the client.

[0080] In some embodiments, the second binder driver is further configured to send a second service request to the first binder driver based on the first inter-core communication mode;

[0081] The first binder driver is further used to send the second service request to a remote service management process corresponding to the first binder driver;

[0082] The remote service management process determines a second target service process based on the second service request, and converts a second remote identifier corresponding to the second target service process into a second local identifier corresponding to the second target service process;

[0083] The remote service management process sends the second local identifier to the first binder driver;

[0084] The first binder driver is used to send the second local identifier to the second binder driver;

[0085] The second binder driver is used to send the second local identifier to the server.

[0086] In a third aspect, an embodiment of the present application provides a multi-core heterogeneous chip, wherein the multi-core heterogeneous chip comprises:

[0087] processor, memory, and bus;

[0088] The memory stores executable instructions;

[0089] The processor communicates with the memory via the bus, and when the processor executes the executable instructions stored in the memory, the data transmission method of the multi-core heterogeneous chip is implemented.

[0090] In a fourth aspect, an embodiment of the present application provides a component on a transportation device, wherein the component includes a multi-core heterogeneous chip, and the multi-core heterogeneous chip can implement the data transmission method of the multi-core heterogeneous chip mentioned above.

[0091] In a fifth aspect, an embodiment of the present application provides an electronic device, wherein the electronic device includes a multi-core heterogeneous chip, and the multi-core heterogeneous chip can implement the data transmission method of the multi-core heterogeneous chip mentioned above.

[0092] The data transmission method of a multi-core heterogeneous chip provided in an embodiment of the present application, the multi-core heterogeneous chip includes at least a first hardware domain and a second hardware domain, and the method includes: a client located in the first hardware domain sends first data to a first binder driver corresponding to the client; the first binder driver determines the inter-core communication mode of the first data; the first binder driver sends the first data to a server located in the second hardware domain based on the inter-core communication mode; wherein the inter-core communication mode is: the first inter-core communication mode or the second inter-core communication mode; the first inter-core communication mode includes: using on-chip memory to store the first data, and transmitting the first data based on mailbox interrupts; the second inter-core communication mode includes: using shared memory to store the first data, and transmitting the first data based on mailbox interrupts. The data transmission method of a multi-core heterogeneous chip provided in an embodiment of the present application can realize cross-domain binder communication between multiple systems on a multi-core heterogeneous chip. Different inter-core communication methods can be used for different sizes of single-transmission data. For scenarios where the single-transmission data is small and the security requirements are high, the data can be stored in on-chip memory. When storing data in on-chip memory, it can not only enable multiple hardware domains to access the data in shared memory, avoiding high chip load and high latency caused by multiple data copies; but also, the data to be transmitted is stored inside the multi-core heterogeneous chip, which improves the security of data transmission. For scenarios where the single-transmission data is large and the security requirements are high, the data can be stored in shared memory. When storing data in shared memory, it can enable multiple hardware domains to access the data in shared memory, avoiding high chip load and high latency caused by multiple data copies. BRIEF DESCRIPTION OF THE DRAWINGS

[0093] Figure 1 It is a processing flow diagram of a data transmission method for a multi-core heterogeneous chip provided in an embodiment of the present application;

[0094] Figure 2 It is a schematic diagram of a processing flow of a first binder driver sending first data to a server located in a second hardware domain based on an inter-core communication method provided in an embodiment of the present application;

[0095] Figure 3 It is a schematic diagram of communication between a server and a client provided in an embodiment of the present application;

[0096] Figure 4 This is a schematic diagram of the process flow of a client obtaining a remote service provided by an embodiment of the present application;

[0097] Figure 5 It is a schematic diagram of the processing flow of the server obtaining remote services provided by the embodiment of the present application;

[0098] Figure 6 This is a schematic diagram of the process flow of a client obtaining a remote service provided by an embodiment of the present application;

[0099] Figure 7 It is a schematic diagram of the processing flow of the server obtaining remote services provided by the embodiment of the present application;

[0100] Figure 8 It is a schematic diagram of the composition structure of the data transmission device of the multi-core heterogeneous chip provided in the embodiment of the present application;

[0101] Fig. 9 It is a schematic diagram of the structure of a multi-core heterogeneous chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0102] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0103] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0104] In the following description, the terms "first\second" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0105] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0106] It should be understood that in the various embodiments of the present application, the size of the serial number of each implementation process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0107] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0108] 1) In the embodiments of the present application, the SoC chip may be a multi-core heterogeneous chip, which refers to a chip that integrates two or more processor cores in a single chip, and each processor core can act as an independent processor to independently run the instructions stored in the memory corresponding to the processor core. Multi-core heterogeneous chips can bring more combined advantages in performance, cost, power consumption, size, etc. Different architectures perform their respective functions and each plays the unique advantages of the original architecture.

[0109] The multi-core heterogeneous chip in the embodiment of the present application can be applied to transportation equipment, including but not limited to balancing vehicles, cars, buses, subways, trains, and airplanes.

[0110] 2) Hardware domain is a set of hardware collections, which may include hardware resources such as processor cores, interrupt controllers, clock controllers and memories. The number of processor cores in the hardware collection can be one or more. One hardware domain runs one operating system, and different hardware domains can run different operating systems.

[0111] The IP cores in each hardware domain are divided into large cores and small cores. The large cores are suitable for running operating systems with high performance, while the small cores are suitable for running operating systems with low performance, high speed and greater security. Information is transmitted between different hardware domains through inter-core communication channels.

[0112] 3) Binder driver is a lightweight kernel driver that provides remote procedure call function and is responsible for data transfer and communication between processes. Binder driver can connect different applications and systems to achieve efficient collaboration between different applications or different service systems.

[0113] 4) Inter-core communication: There is a need for information communication between different hardware domains. The communication method between hardware domains is called inter-core communication. Inter-core communication has more advantages than communication between chips. For example, it does not need to transmit data outside the chip, which greatly improves the security and speed of data transmission. There are many forms of inter-core communication, such as the Mailbox mechanism suitable for transmitting instructions and the shared memory mechanism suitable for sharing data.

[0114] Mailbox is a mechanism or data structure used for communication between different processing cores. It can be used to pass messages and trigger events between different processors, cores or hardware modules.

[0115] Mailbox can be viewed as a shared, bidirectional communication interface that contains one or more registers for storing messages or control information. The sender can write messages into the registers of the Mailbox, and the receiver can read these messages and process them accordingly. That is, the sender can control the receiver or instruct the receiver to perform corresponding operations by writing messages or control information into the registers of the Mailbox.

[0116] In semiconductor chips, Mailbox is often used for communication between processors, such as between multi-core processors, SoCs, or multiple independent functional modules. Through the Mailbox mechanism, different processing units can work together, share data, synchronize operations, and trigger events, thereby achieving more efficient system collaboration and resource sharing.

[0117] It should be noted that the implementation of Mailbox may vary depending on the chip architecture, communication protocol or design requirements, but in general, it exists to achieve reliable and efficient communication and data exchange between processing units.

[0118] 4) Process is the smallest unit of computer resource allocation. Each process has its own independent resources and is isolated from other processes. Different processes can access each other's resources and coordinate work.

[0119] In the related art, when two or more processes communicate, data is copied from one process to another process by copying data. However, copying data will bring higher load and higher latency to the chip.

[0120] The data transmission method for multi-core heterogeneous chips provided in the embodiments of the present application can at least solve the above problems.

[0121] A processing flow diagram of a data transmission method for a multi-core heterogeneous chip provided in an embodiment of the present application is as follows: Figure 1 As shown, at least the following steps may be included:

[0122] Step S101: a client located in a first hardware domain sends first data to a first binder driver corresponding to the client.

[0123] The data transmission method of a multi-core heterogeneous chip provided in an embodiment of the present application is applied to a multi-core heterogeneous chip. The multi-core heterogeneous chip includes at least a first hardware domain and a second hardware domain. The multi-core heterogeneous chip may also include other hardware domains in addition to the first hardware domain and the second hardware domain.

[0124] In some embodiments, the client of the first hardware domain pre-negotiates the data format of the first data with the receiver of the first data, and the client of the first hardware domain constructs the first data according to the pre-negotiated data format. The client of the first hardware domain sends the constructed first data to the corresponding first binder driver.

[0125] Step S102: The first binder driver determines the inter-core communication mode of the first data.

[0126] In some embodiments, the inter-core communication mode includes at least a first inter-core communication mode and a second inter-core communication mode. The first inter-core communication mode includes: using on-chip memory to store the first data, and transmitting the first data based on mailbox interrupts. The second inter-core communication mode includes: using shared memory to store the first data, and transmitting the first data based on mailbox interrupts; the shared memory can be a memory space opened on a double data rate synchronous dynamic random access memory (DDR SDRAM) of a multi-core heterogeneous chip, and the data stored in the memory space can be accessed by multiple systems or multiple hardware domains.

[0127] In some embodiments, when the client of the first hardware domain constructs the first data, it can know the size of the first data and the data size of the first data transmitted in a single time; when the client of the first hardware domain transmits the first data to the first binder driver, it can notify the first binder driver of the data size of the first data transmitted in a single time. Alternatively, when the first binder driver receives the first data sent by the client of the first hardware domain, it can calculate the data size of the first data transmitted in a single time. After the first binder driver determines the data size of the first data transmitted in a single time by any of the above methods, the first binder driver determines whether the data size of the first data transmitted in a single time is greater than the first threshold; if the data size of the first data transmitted in a single time is greater than the first threshold, the first binder driver determines that the inter-core communication mode of the first data is the second inter-core communication mode; if the data size of the first data transmitted in a single time is less than the first threshold, the first binder driver determines that the inter-core communication mode of the first data is the first inter-core communication mode.

[0128] In an embodiment of the present application, when the data size of the first data transmitted in a single time is greater than the first threshold value, it indicates that the data volume of the first data is large, and the first data can be stored in a shared memory to save memory space. When the data size of the first data transmitted in a single time is less than the first threshold value, it indicates that the data volume of the first data is small, and the first data can be stored in an on-chip memory. Whether the first data is stored in a shared memory or in an on-chip memory, it can avoid high chip load and high latency caused by multiple copies of the first data when different systems or processes need to use the first data.

[0129] Step S103: The first binder driver sends the first data to the server located in the second hardware domain based on the inter-core communication method.

[0130] In some embodiments, the first binder driver sends the first data to the server of the second hardware domain based on the inter-core communication mode determined in step S102.

[0131] In specific implementation, the first binder driver sends the first data to the second binder driver corresponding to the server of the second hardware domain based on the inter-core communication mode determined in step S102; the second binder driver then sends the first data to the server of the second hardware domain.

[0132] In the embodiment of the present application, a schematic diagram of a processing flow of sending first data to a server located in a second hardware domain based on an inter-core communication method by a first binder driver is shown in FIG. Figure 2 As shown, at least the following steps may be included:

[0133] Step S201: The first binder driver sends a data transmission request to the second binder driver corresponding to the server based on the inter-core communication method.

[0134] In some embodiments, the inter-core communication mode in which the first binder driver sends the data transmission request to the second binder driver may be a first inter-core communication mode.

[0135] Step S202: The second binder driver determines a service process based on the data transmission request.

[0136] In some embodiments, the second binder driver determines the service process based on the handle carried in the data transfer request.

[0137] Step S203: The second binder driver converts the first data from the user state to the kernel state.

[0138] In some embodiments, the second binder driver converts the first data from the user state to the kernel state through copy_from_user.

[0139] Step S204: transmitting the first data in the kernel state from the first binder driver to the second binder driver through the determined inter-core communication mode.

[0140] Step S205: The second binder driver stores the received first data into the memory space corresponding to the service process.

[0141] In some embodiments, the second binder driver may store the first data in the mmap memory space corresponding to the service process.

[0142] In the embodiment of the present application, a schematic diagram of communication between the server and the client is shown as follows: Figure 3 As shown, the first binder driver has a corresponding first service manager process, and the second binder driver has a corresponding second ServiceManager process; the Service Manager process is a daemon process of the binder driver, and its handle is 0, which is used to provide registration service and query service functions. When the client sends the first data to the server, it must first obtain the corresponding handle of the server through the Service Manager process; then, the client can communicate with the server through the first binder driver and the second binder driver.

[0143] In an embodiment of the present application, the first hardware domain can run an Android system, and the second hardware domain can run a Linux system. Alternatively, the second hardware domain can run an Android system, and the first hardware domain can run a Linux system. The data transmission method of a multi-core heterogeneous chip provided in an embodiment of the present application can realize cross-domain binder communication between multiple systems on a multi-core heterogeneous chip. Different inter-core communication methods can be used for different data sizes of a single transmission. For scenarios where the data of a single transmission is small and the security requirements are high, the data can be stored through on-chip memory; when storing data through on-chip memory, not only can multiple hardware domains access the data in the shared memory, but also high chip load and high latency caused by multiple copies of the data can be avoided; moreover, the data to be transmitted is stored inside the multi-core heterogeneous chip, which improves the security of data transmission. For scenarios where the data of a single transmission is large and the security requirements are high, the data can be stored through shared memory; when storing data through shared memory, multiple hardware domains can access the data in the shared memory, and high chip load and high latency caused by multiple copies of the data can be avoided.

[0144] Above Figures 1 to 3 Describes the process of binder communication between the server and the client. Figures 1 to 3Before the binder communication process shown, both the server and the client need to register the service; the process of the server and the client registering the local service is the same as the prior art and will not be repeated here; the process of the server registering the remote service and the client registering the remote service will be explained respectively.

[0145] The present application embodiment provides a schematic diagram of a process flow for a client to obtain a remote service, such as Figure 4 As shown, at least the following steps may be included:

[0146] Step S401: The client sends the name of a first service to be registered to a first binder driver corresponding to the client.

[0147] Step S402: The first binder driver determines a service management process based on the name of the first service to be registered.

[0148] In some embodiments, the first binder driver determines whether the first service to be registered is a local service or a remote service based on the name of the first service to be registered; if the first service to be registered is a local service, the corresponding service management process is determined to be a local service management process. If the first service to be registered is a remote service, the corresponding service management process is determined to be a remote service management process.

[0149] Step S403: register the first service to be registered based on the determined service management process.

[0150] In an embodiment of the present application, the service management process is a remote service management process, then the first binder driver sends the service message of the first service to be registered to the second binder driver corresponding to the remote service management process based on the first inter-core communication method; the second binder driver sends the service message of the first service to be registered to the remote service management process; the remote service management process creates a service list in user mode and saves the service message of the first service to be registered.

[0151] The service message of the first service to be registered may include: the name and handle of the first service to be registered.

[0152] The present application embodiment provides a schematic diagram of a process flow for a server to obtain a remote service, such as Figure 5 As shown, at least the following steps may be included:

[0153] Step S501, the server sends the name of the second service to be registered to the second binder driver corresponding to the server;

[0154] Step S502: The second binder driver determines a service management process based on the name of the second service to be registered.

[0155] In some embodiments, the second binder driver determines whether the second service to be registered is a local service or a remote service based on the name of the second service to be registered; if the second service to be registered is a local service, the corresponding service management process is determined to be a local service management process. If the second service to be registered is a remote service, the corresponding service management process is determined to be a remote service management process.

[0156] Step S503: register the second service to be registered based on the determined service management process.

[0157] In an embodiment of the present application, the service management process is a remote service management process, then the second binder driver sends the service message of the second service to be registered to the first binder driver corresponding to the remote service management process based on the first inter-core communication method; the first binder driver sends the service message of the second service to be registered to the remote service management process; the remote service management process creates a service list in user mode and saves the service message of the second service to be registered.

[0158] The service message of the second service to be registered may include: the name and handle of the second service to be registered.

[0159] Above Figure 4 and Figure 5 The specific implementation process of registering services on the client and server is described respectively, and the specific implementation process of obtaining remote services on the client and server is described below.

[0160] The present application embodiment provides a schematic diagram of a process flow for a client to obtain a remote service, such as Figure 6 As shown, at least the following steps may be included:

[0161] Step S601: The first binder driver sends a first service request to the second binder driver based on a first inter-core communication mode.

[0162] In some embodiments, the first service request is used by the client to obtain a remote service.

[0163] Step S602: The second binder driver sends the first service request to the remote service management process corresponding to the second binder driver.

[0164] Step S603: The remote service management process determines a first target service process based on the first service request, and converts a first remote identifier corresponding to the first target service process into a first local identifier corresponding to the first target service process.

[0165] In some embodiments, the remote service management process determines the service process based on the service process name carried in the data transmission request, and identifies the service process as the target process. Specifically, the remote service management process queries the remote test_service binder_ref, and uses the desc in the binder_ref of the service process as a handle to identify the service process as the target process. The first local identifier is added to the desc in the binder_ref of the service process, and the first remote identifier of the desc in the binder_ref of the service process is deleted.

[0166] Step S604: The remote service management process sends the first local identifier to the second binder driver.

[0167] Step S605: The second binder driver sends the first local identifier to the first binder driver.

[0168] In some embodiments, the second binder driver sends the first local identifier to the first binder driver based on a first inter-core communication method.

[0169] Step S606: The first binder driver sends the first local identifier to the client.

[0170] The present application embodiment provides a schematic diagram of a process flow for a server to obtain a remote service, such as Figure 7 As shown, at least the following steps may be included:

[0171] Step S701: The second binder driver sends a second service request to the first binder driver based on the first inter-core communication mode.

[0172] In some embodiments, the second service request is used by the server to obtain a remote service.

[0173] Step S702: The first binder driver sends the second service request to the remote service management process corresponding to the first binder driver.

[0174] Step S703: The remote service management process determines a second target service process based on the second service request, and converts a second remote identifier corresponding to the second target service process into a second local identifier corresponding to the second target service process.

[0175] In some embodiments, the remote service management process determines the service process based on the service process name carried in the data transmission request, and identifies the service process as the target process. Specifically, the remote service management process queries the remote test_service binder_ref, and uses the desc in the binder_ref of the service process as the handle to identify the service process as the target process. A second local identifier is added to the desc in the binder_ref of the service process, and the second remote identifier of the desc in the binder_ref of the service process is deleted.

[0176] Step S704: The remote service management process sends the second local identifier to the first binder driver.

[0177] Step S705: The first binder driver sends the second local identifier to the second binder driver.

[0178] In some embodiments, the first binder driver sends the second local identifier to the second binder driver based on a first inter-core communication method.

[0179] Step S706: The second binder driver sends the second local identifier to the server.

[0180] Based on the above Figures 1 to 7 The data transmission method of the multi-core heterogeneous chip shown, whether it is based on the first inter-core communication method for data transmission or the second inter-core communication method for data transmission, notifies each hardware domain or each system to store data or read data through mailbox interrupts, so that each hardware domain can communicate between processes with a lower delay. Since the binder communication mechanism is adopted between each hardware domain, the existing binder interface can be reused, saving hardware costs. By storing data in on-chip memory, the data of each hardware domain is only stored on the multi-core heterogeneous chip, which improves the security of inter-process communication data.

[0181] The embodiment of the present application also provides a data transmission device of a multi-core heterogeneous chip, wherein the data transmission device of the multi-core heterogeneous chip is located in the multi-core heterogeneous chip, and the composition structure of the data transmission device of the multi-core heterogeneous chip is as follows: Figure 8 As shown, it at least includes a first hardware domain 01 and a second hardware domain 02, the first hardware domain 01 includes a client 801 and a first binder driver 802, and the second hardware domain 02 includes a server 803;

[0182] The client 801 is used to send first data to the first binder driver 802;

[0183] The first binder driver 802 is used to determine an inter-core communication mode of the first data, and send the first data to the server 803 based on the inter-core communication mode;

[0184] Among them, the inter-core communication mode is: the first inter-core communication mode or the second inter-core communication mode; the first inter-core communication mode includes: using on-chip memory to store the first data, and transmitting the first data based on mailbox interrupt; the second inter-core communication mode includes: using shared memory to store the first data, and transmitting the first data based on mailbox interrupt.

[0185] In some embodiments, the first binder driver 802 is specifically used to determine whether the data size of a single transmission of the first data is greater than a first threshold;

[0186] If the data size of the first data transmitted in a single time is greater than the first threshold, the first binder driver 802 determines that the inter-core communication mode of the first data is the second inter-core communication mode;

[0187] If the data size of a single transmission of the first data is smaller than the first threshold, the first binder driver 802 determines that the inter-core communication mode of the first data is the first inter-core communication mode.

[0188] In some embodiments, the first binder driver 802 is specifically used to send the data transmission request to the second binder driver corresponding to the server 803 based on the inter-core communication mode;

[0189] The second binder driver determines a service process based on the data transmission request;

[0190] The second binder driver converts the first data from user state to kernel state;

[0191] Transmitting the first data in the kernel state from the first binder driver 802 to the second binder driver through the determined inter-core communication mode;

[0192] The second binder driver stores the received first data into the memory space corresponding to the service process.

[0193] In some embodiments, the client 801 is used to send the name of the first service to be registered to the first binder driver 802 corresponding to the client 801;

[0194] The first binder driver 802 determines the service management process based on the name of the first service to be registered;

[0195] Based on the determined service management process, the first service to be registered is registered.

[0196] In some embodiments, if the service management process is a remote service management process, the first binder driver 802 is used to send a service message of the first service to be registered to a second binder driver corresponding to the remote service management process based on the first inter-core communication mode;

[0197] The second binder driver sends the service message of the first service to be registered to the remote service management process;

[0198] The remote service management process creates a service list in user mode and saves the service message of the first service to be registered.

[0199] In some embodiments, the server 803 is further used to send the name of the second service to be registered to the second binder driver corresponding to the server 803;

[0200] The second binder driver determines the service management process based on the name of the second service to be registered;

[0201] Based on the determined service management process, register the second service to be registered.

[0202] In some embodiments, if the service management process is a remote service management process, the second binder driver is further used to send a service message of the second service to be registered to the first binder driver 802 corresponding to the remote service management process based on the first inter-core communication mode;

[0203] The first binder driver 802 is used to send the service message of the second service to be registered to the remote service management process;

[0204] The remote service management process creates a service list in user mode and saves the service message of the second service to be registered.

[0205] In some embodiments, the first binder driver 802 is further configured to send a first service request to the second binder driver based on the first inter-core communication mode;

[0206] The second binder driver sends the first service request to a remote service management process corresponding to the second binder driver;

[0207] The remote service management process determines a first target service process based on the first service request, and converts a first remote identifier corresponding to the first target service process into a first local identifier corresponding to the first target service process;

[0208] The remote service management process sends the first local identifier to the second binder driver;

[0209] The second binder driver sends the first local identifier to the first binder driver 802;

[0210] The first binder driver 802 is used to send the first local identifier to the client 801.

[0211] In some embodiments, the second binder driver is further configured to send a second service request to the first binder driver based on the first inter-core communication mode;

[0212] The first binder driver 802 is further configured to send the second service request to a remote service management process corresponding to the first binder driver 802;

[0213] The remote service management process determines a second target service process based on the second service request, and converts a second remote identifier corresponding to the second target service process into a second local identifier corresponding to the second target service process;

[0214] The remote service management process sends the second local identifier to the first binder driver 802;

[0215] The first binder driver 802 is used to send the second local identifier to the second binder driver;

[0216] The second binder driver is used to send the second local identifier to the server 803.

[0217] The present application also provides a multi-core heterogeneous chip, the structural diagram of the multi-core heterogeneous chip is as follows: Fig. 9 As shown, the chip includes: a processor 410, a memory 450 and a bus 440; the various modules in the chip are coupled together through the bus 440. It can be understood that the bus 440 is used to realize the connection and communication between these modules. In addition to the data bus, the bus 440 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Fig. 9 Various buses are labeled as bus 440.

[0218] The processor 410 has signal processing capability, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware models, etc., wherein the general-purpose processor may be a microprocessor or any conventional processor, etc.

[0219] The memory 450 stores executable instructions for implementing the data transmission method of the multi-core heterogeneous chip provided in the embodiment of the present application. The data transmission method of the multi-core heterogeneous chip can be implemented by Figure 8 The client 801, the first binder driver 802 and the server 803 in the data transmission device of the multi-core heterogeneous chip shown are implemented; the memory 450 can be removable, non-removable or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drive, optical disk drive, etc. The memory 450 optionally includes one or more storage devices that are physically far away from the processor 410.

[0220] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof.

[0221] In some embodiments, the multi-core heterogeneous chip may further include:

[0222] Operating system 451, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0223] The network communication module 452 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420 . Exemplary network interfaces 420 include: Bluetooth, Wireless LAN (WiFi), and Universal Serial Bus (USB).

[0224] An embodiment of the present application also provides a component on a transportation device, wherein the component includes a multi-core heterogeneous chip, and the multi-core heterogeneous chip can execute the data transmission method of the multi-core heterogeneous chip.

[0225] In some optional embodiments, the components may be components at the circuit board level, components at the automotive electrical system level, or components of an automotive assembly. As an example, the components may be the engine, chassis, body, and electrical and electronic equipment of the vehicle. The electrical and electronic equipment of the vehicle may include headlights for lighting, management equipment for controlling the engine, central control equipment for receiving broadcasts, navigation, listening to music, entertainment, etc.

[0226] The embodiment of the present application also provides an electronic device, the electronic device includes a multi-core heterogeneous chip, and the multi-core heterogeneous chip can execute the data transmission method of the multi-core heterogeneous chip. The electronic device can be a transportation device, and the transportation device includes but is not limited to a balance car, a car, a bus, a train or an airplane.

[0227] The embodiment of the present application provides a computer-readable storage medium storing executable instructions, wherein the executable instructions are stored. When the executable instructions are executed by a processor, the processor will be triggered to execute the cross-hardware domain shared memory management method provided by the embodiment of the present application, for example, Figures 1 to 7 The data transmission method of a multi-core heterogeneous chip is shown.

[0228] In some embodiments, the computer-readable storage medium may be a ferroelectric random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface memory, an optical disk, or a CD-ROM; or it may be various devices including one or any combination of the above memories.

[0229] In some embodiments, executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, model, subroutine or other unit suitable for use in a computing environment.

[0230] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0231] An embodiment of the present application provides a computer program product, which includes a computer program / instruction. When the computer program / instruction is executed by a processor, the data transmission method of the multi-core heterogeneous chip described in the present application is implemented.

[0232] The above are only embodiments of the present application and are not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A data transmission method for a multi-core heterogeneous chip, characterized in that: The method is applied to a multi-core heterogeneous chip, the multi-core heterogeneous chip includes at least a first hardware domain and a second hardware domain, and the method includes: The client located in the first hardware domain sends first data to a first binder driver corresponding to the client; The first binder driver determines the inter-core communication mode of the first data; The first binder driver sends the first data to the server located in the second hardware domain based on the inter-core communication mode; The inter-core communication mode is: a first inter-core communication mode or a second inter-core communication mode; the first inter-core communication mode includes: using an on-chip memory to store the first data, and transmitting the first data based on a thread mailbox mailbox interrupt; the second inter-core communication mode includes: using a shared memory to store the first data, and transmitting the first data based on a mailbox interrupt; The first binder driver determines the inter-core communication mode of the first data, including: the first binder driver determines whether the data size of the first data transmitted in a single time is greater than a first threshold; if the data size of the first data transmitted in a single time is greater than the first threshold, the first binder driver determines that the inter-core communication mode of the first data is the second inter-core communication mode; if the data size of the first data transmitted in a single time is less than the first threshold, the first binder driver determines that the inter-core communication mode of the first data is the first inter-core communication mode; The first binder driver sends the first data to the server located in the second hardware domain based on the inter-core communication method, including: the first binder driver sends the data transmission request to the second binder driver corresponding to the server based on the inter-core communication method; the second binder driver determines the service process based on the data transmission request; the second binder driver converts the first data from user mode to kernel mode; transmits the first data in the kernel mode from the first binder driver to the second binder driver through the determined inter-core communication method; the second binder driver stores the received first data in the memory space corresponding to the service process.

2. The method according to claim 1, characterized in that Before the client located in the first hardware domain sends the first data to the first binder driver corresponding to the client, the method further includes: The client sends the name of the first service to be registered to the first binder driver corresponding to the client; The first binder driver determines the service management process based on the name of the first service to be registered; Based on the determined service management process, the first service to be registered is registered.

3. The method according to claim 2, characterized in that The registering the first service to be registered based on the determined service management process includes: If the service management process is a remote service management process, the first binder driver sends a service message of the first to-be-registered service to a second binder driver corresponding to the remote service management process based on the first inter-core communication mode; The second binder driver sends the service message of the first service to be registered to the remote service management process; The remote service management process creates a service list in user mode and saves the service message of the first service to be registered.

4. The method according to claim 1, characterized in that Before the client located in the first hardware domain sends the first data to the first binder driver corresponding to the client, the method further includes: The server sends the name of the second service to be registered to the second binder driver corresponding to the server; The second binder driver determines the service management process based on the name of the second service to be registered; Based on the determined service management process, register the second service to be registered.

5. The method according to claim 4, characterized in that The registering the second service to be registered based on the determined service management process includes: If the service management process is a remote service management process, the second binder driver sends a service message of the second service to be registered to the first binder driver corresponding to the remote service management process based on the first inter-core communication mode; The first binder driver sends the service message of the second service to be registered to the remote service management process; The remote service management process creates a service list in user mode and saves the service message of the second service to be registered.

6. The method according to claim 1, characterized in that Before the client located in the first hardware domain sends the first data to the first binder driver corresponding to the client, the method further includes: The first binder driver sends a first service request to the second binder driver based on the first inter-core communication mode; The second binder driver sends the first service request to a remote service management process corresponding to the second binder driver; The remote service management process determines a first target service process based on the first service request, and converts a first remote identifier corresponding to the first target service process into a first local identifier corresponding to the first target service process; The remote service management process sends the first local identifier to the second binder driver; The second binder driver sends the first local identifier to the first binder driver; The first binder driver sends the first local identifier to the client.

7. The method according to claim 1, characterized in that Before the client located in the first hardware domain sends the first data to the first binder driver corresponding to the client, the method further includes: The second binder driver sends a second service request to the first binder driver based on the first inter-core communication mode; The first binder driver sends the second service request to a remote service management process corresponding to the first binder driver; The remote service management process determines a second target service process based on the second service request, and converts a second remote identifier corresponding to the second target service process into a second local identifier corresponding to the second target service process; The remote service management process sends the second local identifier to the first binder driver; The first binder driver sends the second local identifier to the second binder driver; The second binder driver sends the second local identifier to the server.

8. A data transmission device for a multi-core heterogeneous chip, characterized in that: The device is located in a multi-core heterogeneous chip, and the device includes at least a first hardware domain and a second hardware domain, the first hardware domain includes a client and a first binder driver, and the second hardware domain includes a server; the data transmission device of the multi-core heterogeneous chip is used to implement the data transmission method of the multi-core heterogeneous chip described in any one of claims 1 to 7.

9. A multi-core heterogeneous chip, characterized in that: The multi-core heterogeneous chip includes: a processor, a memory and a bus; The memory stores executable instructions; The processor communicates with the memory via the bus, and when the processor executes the executable instructions stored in the memory, the data transmission method for the multi-core heterogeneous chip according to any one of claims 1 to 7 is implemented.

10. An electronic device, characterized in that: The electronic device comprises a chip, and the chip can implement the data transmission method of the multi-core heterogeneous chip according to any one of claims 1 to 7.

Images