A data sharing method, device, chip and electronic device

Abstract

The present application discloses a method, device, chip and electronic device for data sharing, wherein the method for data sharing is applied to a multi-core heterogeneous system chip, wherein the system chip includes multiple hardware domains, wherein the multiple hardware domains are hard-isolated, wherein one of the hardware domains is connected to an embedded multimedia card, and a virtual backend for accessing the embedded multimedia card is set in the one hardware domain, and a virtual front end for communicating with the virtual backend is respectively set in at least two hardware domains other than the first hardware domain, wherein the embedded multimedia card includes a primary physical partition and a secondary physical partition, wherein there is at least one shared partition corresponding to each of the multiple hardware domains on the secondary physical partition, and the method includes: obtaining a first access request from the first hardware domain. The present application can significantly improve the efficiency of sharing large amounts of data between different hardware domains by implementing a data sharing mechanism between multiple hardware domains.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus, chip, and electronic device for data sharing. Background Art

[0002] In multi-core heterogeneous chips, there are multiple hard-isolated hardware domains, requiring data storage for these domains. Currently, embedded multimedia cards (eMMC) are used to store this data.

[0003] In practical applications, there is a need to share data across different hardware domains. For example, there is a need to share large amounts of data between the Multimedia Processing Domain and the Application Processing Domain. However, eMMC storage solutions do not allow resource sharing between different domains, thus failing to meet user needs. If shared memory is used to achieve this data sharing, it will place extremely high demands on memory capacity. Summary of the Invention

[0004] To address the aforementioned technical problems, the purpose of this application is to provide a data sharing method, apparatus, chip, and electronic device. The data sharing method is applied to a multi-core heterogeneous system-on-a-chip (SoC). The SoC includes multiple hardware domains, which are hard isolated from each other. One hardware domain is connected to an embedded multimedia card, and a virtual backend for accessing the embedded multimedia card is configured in the first hardware domain. Virtual frontends for communicating with the virtual backend are respectively configured in at least two other hardware domains besides the first hardware domain. The embedded multimedia card includes a primary physical partition and a secondary physical partition. At least one shared partition corresponding to each of the multiple hardware domains exists on the secondary physical partition. The method includes:

[0005] Obtain a first access request for the first hardware domain, wherein the first access request is an access request for the second-level physical partition;

[0006] Based on the first access request, obtain the mapping relationship between the shared partition of the second hardware domain and the shared partition of the first hardware domain;

[0007] Based on the mapping relationship, the first hardware domain is controlled to access the shared partition of the second hardware domain.

[0008] As an optional embodiment, the first hardware domain and the second hardware domain are capable of inter-core communication, and the method further includes:

[0009] Determine the update frequency of the data in the shared partition of the second hardware domain;

[0010] Obtain a second access request for the first hardware domain, wherein the second access request includes an access request for the second hardware domain and an update request for a shared partition of the second hardware domain;

[0011] Based on the update frequency and the second access request, obtain the updated data;

[0012] Based on the updated data, update the shared partition of the second hardware domain.

[0013] As an optional embodiment, determining the mapping relationship between the shared partition of the second hardware domain and the shared partition of the first hardware domain based on the first access request includes:

[0014] Based on the first access request, the first physical address of the access object is obtained, wherein the access object is any partition in the second-level physical partition;

[0015] The second physical address of the shared partition of the second hardware domain is obtained through the embedded multimedia card;

[0016] If a mapping relationship is found between the first physical address and the second physical address, the second physical address is mapped to the first physical address.

[0017] As an optional embodiment, the method further includes:

[0018] When both the first hardware domain and the second hardware domain access the shared partition of the second hardware domain, the access of the first hardware domain to the shared partition of the second hardware domain is suspended, so that the second hardware domain can access the shared partition of the second hardware domain.

[0019] If the target data is obtained in the second hardware domain, the first hardware domain continues to access the shared partition of the second hardware domain.

[0020] As an optional embodiment, the method further includes:

[0021] When both the first hardware domain and the second hardware domain access the shared partition of the second hardware domain, obtain updated data;

[0022] Based on the updated data, the first hardware domain is suspended from accessing the shared partition of the second hardware domain, so that the second hardware domain can update the shared partition of the second hardware domain.

[0023] The first hardware domain re-accesses the shared partition of the second hardware domain, wherein the shared partition stores the updated data.

[0024] As an optional embodiment, the storage space of the shared partition of the first hardware domain is the same as the storage space of the shared partition of the second hardware domain.

[0025] As an optional embodiment, the storage space of the shared partition of the first hardware domain is smaller than the storage space of the shared partition of the second hardware domain, and the method further includes:

[0026] Divide the physical address of the shared partition of the second hardware domain into multiple sub-physical addresses;

[0027] Based on the multiple sub-physical addresses, the embedded multimedia card maps the multiple sub-physical addresses to the shared partition of the first hardware domain in stages.

[0028] The purpose of this application embodiment is to provide a data sharing device applied to a multi-core heterogeneous system chip. The system chip includes multiple hardware domains, which are hard isolated from each other. One hardware domain is connected to an embedded multimedia card, and a virtual backend for accessing the embedded multimedia card is set in the one hardware domain. Virtual frontends for communicating with the virtual backend are respectively set in at least two hardware domains other than the first hardware domain. The embedded multimedia card includes a primary physical partition and a secondary physical partition. At least one shared partition corresponding to each of the multiple hardware domains exists on the secondary physical partition. The device includes:

[0029] The acquisition unit is configured to acquire a first access request for a first hardware domain, wherein the first access request is an access request for the secondary physical partition;

[0030] The determining unit is configured to obtain the mapping relationship between the shared partition of the second hardware domain and the shared partition of the first hardware domain based on the first access request.

[0031] An access unit is configured to control the first hardware domain to access the shared partition of the second hardware domain based on the mapping relationship.

[0032] The purpose of this application embodiment is to provide a chip including multiple hardware domains, which are hard isolated from each other. Each hardware domain includes at least a security domain, an application domain, and a multi-purpose domain. A virtual backend that communicates with an embedded multimedia card is provided on the security domain. Virtual frontends that communicate with the virtual backend are respectively provided on the application domain and the multi-purpose domain. Inter-core communication exists between the application domain and the multi-purpose domain.

[0033] The purpose of this application is to provide an electronic device, including a processor and a storage device, wherein the storage device stores an executable program, and the storage device executes the executable program to perform the steps of the method described above.

[0034] The beneficial effects of the embodiments of this application are as follows:

[0035] This application can significantly improve the efficiency of sharing large amounts of data between different hardware domains by implementing a data sharing mechanism between multiple hardware domains, especially in scenarios that require frequent data exchange, such as multimedia processing domains and application processing domains.

[0036] This application allows data sharing through an embedded multimedia card without increasing the amount of shared memory, thereby optimizing the utilization of storage resources and avoiding excessive memory requirements caused by using shared memory. Attached Figure Description

[0037] Figure 1 This is a flowchart illustrating a data sharing method according to an embodiment of this application;

[0038] Figure 2 This is a flowchart of the data sharing method step S0 according to an embodiment of this application;

[0039] Figure 3 This is a flowchart of step S12 of the data sharing method in an embodiment of this application;

[0040] Figure 4 This is a flowchart of step S2 of the data sharing method in an embodiment of this application;

[0041] Figure 5 This is a flowchart of step S3 of the data sharing method in an embodiment of this application;

[0042] Figure 6 This is a flowchart of step S4 of the data sharing method in an embodiment of this application;

[0043] Figure 7 Structural framework of the data sharing apparatus according to embodiments of this application Figure 1 ;

[0044] Figure 8 Structural framework of the data sharing apparatus according to embodiments of this application Figure 2 ;

[0045] Figure 9 This is a structural block diagram of the data sharing method in the embodiments of this application. Figure 1 ;

[0046] Figure 10 This is a structural block diagram of the data sharing method in the embodiments of this application. Figure 2 . Detailed Implementation

[0047] Various embodiments and features of this application are described herein with reference to the accompanying drawings.

[0048] It should be understood that various modifications can be made to the embodiments described herein. Therefore, the above description should not be considered as limiting, but merely as an example of embodiments. Other modifications within the scope and spirit of this application will be apparent to those skilled in the art.

[0049] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the present application and, together with the general description of the present application given above and the detailed description of the embodiments given below, serve to explain the principles of the present application.

[0050] These and other features of this application will become apparent from the following description of preferred forms of embodiments given as non-limiting examples, with reference to the accompanying drawings.

[0051] It should also be understood that although this application has been described with reference to some specific examples, those skilled in the art can certainly implement many other equivalent forms of this application.

[0052] The above and other aspects, features and advantages of this application will become more apparent when taken in conjunction with the accompanying drawings and in view of the following detailed description.

[0053] Specific embodiments of this application are described thereafter with reference to the accompanying drawings; however, it should be understood that the claimed embodiments are merely examples of this application, which can be implemented in various ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that could obscure the application. Therefore, the specific structural and functional details claimed herein are not intended to be limiting, but merely serve as the basis and representative basis for the claims to teach those skilled in the art to use this application in a variety of substantially any suitable detailed structures.

[0054] This specification may use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in other embodiments,” all of which may refer to one or more of the same or different embodiments according to this application.

[0055] In the field of multi-core heterogeneous chips, the embedded multimedia card (eMMC) is an embedded storage solution that integrates flash memory storage and controller functions. Multi-core heterogeneous chips exist in multiple hardware isolation domains, and not every hardware domain has an eMMC controller.

[0056] Therefore, an eMMC virtualization scheme is adopted to access the eMMC. The security domain has a virtual eMMC backend for actual reading and writing of the eMMC. The multi-function domain and application domain have virtual eMMC frontends for communicating with the security domain's eMMC backend, reading and writing data through the backend, and then transmitting the data back to the frontend.

[0057] To ensure the security of eMMC used by each hardware domain, there are primary and secondary physical partitions on the eMMC. The backend can achieve full access to all partitions; the frontend is restricted by the backend and can only access the corresponding secondary physical partition. Other areas of the eMMC are not visible to it; for example, the frontend of the multi-function domain can only access the MP secondary partition, and the frontend of the application domain can only access the AP secondary partition.

[0058] However, there is a need for sharing large amounts of data between the application domain and the multi-functional domain, and using shared memory would require extremely high memory capacity.

[0059] To address the aforementioned problems, embodiments of this application provide a data sharing method, such as... Figure 8 As shown, a system-on-a-chip (SoC) for multi-core heterogeneous architecture is provided. The SoC includes multiple hardware domains that are hard isolated from each other. One hardware domain is connected to an embedded multimedia card and a virtual backend for accessing the embedded multimedia card is set in the first hardware domain. Virtual frontends for communicating with the virtual backend are set in at least two other hardware domains besides the first hardware domain. The embedded multimedia card includes a primary physical partition and a secondary physical partition. At least one shared partition corresponding to each of the multiple hardware domains exists on the secondary physical partition.

[0060] In this embodiment, multi-core heterogeneity refers to a chip architecture design that integrates multiple processing cores, at least two of which differ in structure, function, or performance. Some tasks may be better suited to high-performance general-purpose processor cores, while others may require more specialized processor cores to improve efficiency. Multi-core heterogeneity can better balance factors such as performance, power consumption, and cost, providing a more flexible and efficient solution.

[0061] A System-on-a-Chip (SoC) integrates multiple hardware components, such as a central processing unit (CPU), memory controller, and graphics processing unit (GPU). These hardware resources are configured into multiple sets of different hardware components, called hardware domains. Each operating system runs independently in its respective hardware domain. The independent operation of each hardware domain prevents mutual interference or influence, improving the SoC's reliability, stability, and anti-interference capabilities.

[0062] The application domain (AP domain) is one or more hardware domains, indicating that the hardware domain has strong computing performance and can support applications with high computing power requirements. The security domain (Safety domain / secure domain) is one or more hardware domains, including at least one of the following characteristics: possessing a highly functionally safe architecture, running an operating system that meets high functional safety requirements, and handling tasks with high functional safety requirements. The multi-purpose domain (MP domain) is one or more hardware domains configured with processor components of a certain processing capacity, as well as specific hardware components that respond to various different needs, such as a graphics processing unit (GPU) and a display processor (DP), for handling multiple types of tasks.

[0063] In computer systems, the backend typically refers to a server or service provider, while the frontend refers to a client or user interface. In this application, virtual backend and virtual frontend refer to software-simulated backends and frontends used for data exchange between hardware domains.

[0064] A primary physical partition is the largest storage area division, while a secondary physical partition is a smaller storage area further divided within a primary physical partition. A shared partition refers to an area on the embedded multimedia card that can be accessed by multiple hardware domains for data sharing.

[0065] In this embodiment, the multi-core heterogeneous system-on-a-chip (SoC) includes multiple physically isolated hardware domains. One domain is connected to an embedded multimedia card, and a virtual backend is configured in this domain to access the embedded multimedia card. Virtual frontends communicating with the virtual backend are configured in at least two other hardware domains. One hardware domain is a security domain, and the other at least two hardware domains are an application domain and a multi-function domain.

[0066] The embedded multimedia card is divided into primary and secondary physical partitions, with the secondary physical partition containing multiple shared partitions corresponding to various hardware domains. At least one shared partition is configured for each hardware domain.

[0067] like Figure 1 As shown, the method includes:

[0068] S11. Obtain a first access request from the first hardware domain, wherein the first access request is an access request to the secondary physical partition. In this embodiment, the system first needs to receive an access request from the first hardware domain (e.g., the application domain), which is for data stored on the secondary physical partition on the embedded multimedia card. The first access request includes information such as the type, size, and location of the data to be accessed.

[0069] S12. Based on the first access request, obtain the mapping relationship between the shared partition of the second hardware domain and the shared partition of the first hardware domain.

[0070] In this embodiment, after receiving a first access request from a first hardware domain, the system needs to determine the mapping relationship between the shared partition of the first hardware domain and the shared partition of a second hardware domain (e.g., a multi-functional domain). The mapping relationship refers to how to translate the first access request from the first hardware domain into an actual access to the shared partition of the second hardware domain. This typically involves looking up a mapping table that defines the correspondence between the shared partitions of the two domains.

[0071] S13. Based on the mapping relationship, control the first hardware domain to access the shared partition of the second hardware domain.

[0072] In this embodiment, once the mapping relationship is determined, the system will use this information to control access from the first hardware domain to the shared partition of the second hardware domain. That is, the system will direct access requests from the first hardware domain to the correct physical address based on the mapping relationship, thereby allowing the first hardware domain to access data stored in the shared partition of the second hardware domain.

[0073] In application, when a hardware domain needs to access data in a shared partition of another hardware domain on an embedded multimedia card, its virtual front end sends an access request to the virtual back end of the hardware domain connected to the embedded multimedia card. The virtual back end looks up the mapping relationships and then controls one hardware domain to access the shared partition of another hardware domain based on these mapping relationships.

[0074] For example, such as Figure 9 or Figure 10 As shown, both the multi-function domain (MP domain) and the application domain (AP domain) need to access some video files stored on the embedded multimedia card.

[0075] When an AP domain needs to access a video file on an embedded multimedia card, the front end of the AP domain sends an access request to the back end of the security domain, requesting access to a specific data block in the secondary physical partition of the embedded multimedia card (i.e., the shared partition of the application domain).

[0076] After receiving an access request from the AP domain, the backend of the security domain looks up a predefined mapping table. This table describes the correspondence between the shared partitions of the MP domain and the shared partitions of the AP domain on the embedded multimedia card. For example, the mapping table might show that shared partition 1 of the AP domain corresponds to shared partition 2 of the MP domain.

[0077] Based on the mapping table, the system knows that the data requested by the AP domain is actually stored in shared partition 2 of the MP domain. It then controls the AP domain's access requests, directing them to shared partition 2 of the MP domain, allowing the AP domain to read or write the required video files.

[0078] Through this process, the AP domain can efficiently access data stored in the MP domain's shared partition, achieving efficient data sharing without relying on shared memory. This approach not only improves data sharing efficiency but also reduces memory capacity requirements while maintaining data security and consistency. Through the physical address mapping of the embedded multimedia card, the two domains can flexibly share and process large volumes of data, meeting the data sharing needs between different hardware domains in multi-core heterogeneous chips.

[0079] In one embodiment, such as Figure 2 As shown, the first hardware domain and the second hardware domain can communicate with each other. Inter-core communication refers to communication between different hardware domains within a System on Chip (SoC), including asynchronous message passing via a mailbox mechanism and cross-hardware domain data sharing via a shared memory mechanism. The method also includes:

[0080] S01. Determine the update frequency of the data in the shared partition of the second hardware domain.

[0081] In this embodiment, the update frequency of data in the shared partition of a second hardware domain (e.g., a multi-functional domain) is monitored and recorded. The update frequency refers to how often data is modified in the shared partition, which may vary depending on application requirements and could be updated once per second, per minute, or per hour.

[0082] A shared partition refers to a data storage area that can be accessed and modified by multiple hardware domains. For example, the first hardware domain is an application domain, and the second hardware domain is a multi-functional domain. The multi-functional domain can access its own shared partition, and the application domain can also access the shared partition of the multi-functional domain using the method described in this application.

[0083] S02. Obtain a second access request for the first hardware domain, wherein the second access request includes an access request for the second hardware domain and an update request for the shared partition of the second hardware domain.

[0084] In this embodiment, the system needs to receive a second access request from a first hardware domain (e.g., an application domain). This request includes not only general access to the second hardware domain, but also specifically an update request for a shared partition of the second hardware domain, indicating that the first hardware domain wishes to read the latest data from the shared partition of the second hardware domain.

[0085] S03. Based on the update frequency and the second access request, obtain the update data.

[0086] In this embodiment, the latest data is obtained based on the update frequency of the shared partition of the second hardware domain and the second access request of the first hardware domain. If the update frequency is high, the system may check for new data more frequently. Updated data refers to new data that needs to be written to the shared partition, which may be generated by operations or calculations in the hardware domain.

[0087] S04. Based on the updated data, update the shared partition of the second hardware domain.

[0088] In this embodiment, the acquired updated data is used to update the shared partition of the second hardware domain. This involves writing new data or replacing old data to ensure that the data in the shared partition is up-to-date.

[0089] When applied, the first hardware domain and the second hardware domain can communicate with each other. By determining the update frequency of the data in the shared partition, and obtaining the access and update requests of the first hardware domain to the second hardware domain and its shared partition, the updated data is obtained based on the update frequency and access requests, and the shared partition of the second hardware domain is updated.

[0090] For example, the first hardware domain is the application domain (AP domain), the second hardware domain is the multi-function domain (MP domain), and the system monitors the shared partition of the MP domain and finds that the data is updated every 5 seconds.

[0091] The AP domain needs the latest data for video analysis, so it sends a second access request to the MP domain. This request includes access to and update requests for the MP domain, hoping to obtain the latest data.

[0092] Based on the MP domain's update frequency (every 5 seconds) and the AP domain's second access request, the system retrieves the latest data. The system then writes the retrieved updated data to the AP domain's shared partition, updating the stored data. In this way, any domain requiring the latest data can obtain it from the AP domain's shared partition.

[0093] This application ensures timely data updates through update frequency and second access requests, thereby ensuring that the data accessed by different hardware domains is the latest data, and can ensure the consistency of data shared between multiple hardware domains.

[0094] In another embodiment, a higher update frequency means that the data stored in the shared partition does not change frequently. In this case, the timeliness requirement for the data is not high, so there is no need to frequently update the data in the shared partition. This can reduce unnecessary data transfer and processing, improving efficiency, especially in scenarios where data changes infrequently.

[0095] In one embodiment, such as Figure 3As shown, determining the mapping relationship between the shared partition of the second hardware domain and the shared partition of the first hardware domain based on the first access request includes:

[0096] S121. Based on the first access request, obtain the first physical address of the access object, wherein the access object is any partition in the secondary physical partition.

[0097] In this embodiment, the first access request refers to an access request issued by the first hardware domain for a secondary physical partition in the embedded multimedia card. The first physical address refers to the address of the object accessed by the first hardware domain in the embedded multimedia card (such as a shared partition of the first hardware domain in the secondary physical partition).

[0098] S122. Obtain the second physical address of the shared partition of the second hardware domain through the embedded multimedia card.

[0099] In this embodiment, the second physical address refers to the address of the shared partition of the second hardware domain in the embedded multimedia card.

[0100] S123. If a mapping relationship is found between the first physical address and the second physical address, the second physical address is mapped to the first physical address.

[0101] In this embodiment, the mapping relationship refers to mapping an address in one address space to an address in another address space, so that two different hardware domains can access the same storage area.

[0102] In application, to achieve data sharing between a first hardware domain and a second hardware domain, it is necessary to determine the mapping relationship between their shared partitions. This process includes obtaining the physical address of the secondary physical partition specified in the access request of the first hardware domain, obtaining the physical address of the shared partition of the second hardware domain, and querying whether a mapping relationship exists between these two addresses. If a mapping relationship exists, the first hardware domain can access the shared partition of the second hardware domain through its physical address.

[0103] For example, the first hardware domain is an application domain (AP domain), and the second hardware domain is a multi-function domain (MP domain). The application domain needs to access some data in the shared partition of the multi-function domain.

[0104] The AP domain issues an access request, seeking to access an image data partition (i.e., the AP domain's shared partition) within the secondary physical partition of the embedded multimedia card, specifying that the first physical address of this partition is 0x1000. The access request also includes a request to access the MP domain's shared partition.

[0105] The system obtains the second physical address of the shared partition of the MP domain as 0x2000 through the embedded multimedia card.

[0106] The system checks the mapping table and finds a mapping relationship between 0x1000 and 0x2000, mapping 0x2000 to 0x1000. Thus, when the AP domain attempts to access address 0x1000, the system automatically redirects it to address 0x2000, allowing the AP domain to access image data in the MP domain's shared partition.

[0107] This application simplifies the data sharing process by querying the mapping relationship of physical addresses, allowing direct access to shared data through the mapping relationship, reducing the transmission latency between different hardware domains, and improving the efficiency of data access.

[0108] In one embodiment, such as Figure 4 As shown, the method further includes:

[0109] S21. When both the first hardware domain and the second hardware domain access the shared partition of the second hardware domain, suspend the first hardware domain's access to the shared partition of the second hardware domain, so that the second hardware domain can access the shared partition of the second hardware domain.

[0110] In this embodiment, access to the shared partition by the second hardware domain takes precedence over access to the shared partition of the second hardware domain by the first hardware domain. Pausing access refers to temporarily halting access to the shared partition by one hardware domain so that another hardware domain can access the shared partition.

[0111] Specifically, when the first hardware domain accesses the shared partition of the second hardware domain, the second hardware domain also needs to access its shared partition. At this time, the system will suspend the access of the first hardware domain so that the second hardware domain can access its shared partition without interference, in order to avoid data conflicts and ensure data consistency.

[0112] S22. If the target data is obtained by the second hardware domain, the first hardware domain continues to access the shared partition of the second hardware domain.

[0113] In this embodiment, once the second hardware domain has completed access to the shared partition and obtained the required target data, the system will allow the first hardware domain to resume access to the shared partition of the second hardware domain. This ensures that the first hardware domain can continue its operations after the data has been used by the second hardware domain.

[0114] When this application is used, if both the first hardware domain and the second hardware domain need to access the shared partition of the second hardware domain, the system will suspend the first hardware domain's access to allow the second hardware domain to access its shared partition first. Once the second hardware domain obtains the required target data, the first hardware domain can continue to access the shared partition.

[0115] For example, the first hardware domain is an application domain (AP domain) and the second hardware domain is a multi-function domain (MP domain). When the AP domain accesses the shared partition of the MP domain, the MP domain also needs to access its shared partition.

[0116] The system detected a conflict and decided to suspend access for the AP domain so that the MP domain can access the shared partition first. For example, the MP domain might need to read some critical configuration files for data processing, while the AP domain might want to read some non-critical media files.

[0117] After access to the AP domain is suspended, the MP domain accesses the shared partition to read the necessary configuration files. This operation is critical because it can affect subsequent operations of the MP domain.

[0118] Once the MP domain has read the configuration file and resumed its data processing, the system lifts the suspension on access to the AP domain. The AP domain can now continue to access the MP domain's shared partitions and read media files. Since reading media files is not urgent, subsequent access will not affect the AP domain's operations.

[0119] This application avoids data conflicts that may occur when multiple hardware domains access a shared partition simultaneously by suspending access from one hardware domain. Allowing one hardware domain to access the shared partition preferentially reduces waiting time and improves data access efficiency. By coordinating access from different hardware domains, the stability and reliability of the system can be enhanced.

[0120] In one embodiment, such as Figure 5 As shown, the method further includes:

[0121] S31. When both the first hardware domain and the second hardware domain access the shared partition of the second hardware domain, obtain updated data.

[0122] In this embodiment, when the first hardware domain accesses the shared partition of the second hardware domain, the second hardware domain also needs to access its shared partition. At this time, the system first obtains updated data. Updated data refers to new data after modification or addition to the data in the shared partition.

[0123] S32. Based on the updated data, suspend the first hardware domain's access to the shared partition of the second hardware domain, so that the second hardware domain updates the shared partition of the second hardware domain.

[0124] In this embodiment, when it is determined that updated data has been obtained, pausing access refers to temporarily stopping a hardware domain's access to shared resources in order to perform data updates or other operations, avoid data conflicts, and ensure data consistency.

[0125] S33. The first hardware domain re-accesses the shared partition of the second hardware domain, wherein the shared partition stores the updated data.

[0126] In this embodiment, re-access refers to resuming access to the shared resource after a pause; this can be either continuing access or restarting access altogether. If the information required by the first hardware domain is only a portion of the updated data, then re-access must start from the beginning. If the information required by the first hardware domain is unrelated to the updated data, then access can continue without starting from the beginning.

[0127] In application, when the first hardware domain accesses the shared partition of the second hardware domain, the second hardware domain also needs to access its shared partition. First, it retrieves updated data. Then, based on this updated data, it suspends the first hardware domain's access so that the second hardware domain can update its shared partition. After the update is complete, the first hardware domain can re-access the shared partition, which now stores the latest updated data.

[0128] For example, the first hardware domain is an application domain (AP domain) and the second hardware domain is a multi-function domain (MP domain). When the AP domain accesses the shared partition of the MP domain, the MP domain also needs to access its shared partition.

[0129] The system detected that both domains needed to access the shared partition and obtained the latest updated data, which was the data that the MP domain needed to write to the shared partition.

[0130] The system suspends access to the AP domain so that the MP domain can update its shared partition. The MP domain writes the new data to the shared partition. After the MP domain completes the update, the system notifies the AP domain that it can re-access the MP domain's shared partition, and the AP domain can now access the latest data.

[0131] This application ensures that access to shared resources is controlled during data updates, thereby avoiding data inconsistencies and access conflicts. Simultaneously, it guarantees that all hardware domains ultimately have access to the latest data, improving the overall system efficiency and stability.

[0132] In one embodiment, the storage space of the shared partition of the first hardware domain is the same as the storage space of the shared partition of the second hardware domain.

[0133] In this embodiment, a shared partition refers to a storage area that can be accessed and used by multiple hardware domains, and having the same storage space means that the shared partition of the first hardware domain and the shared partition of the second hardware domain have the same storage capacity.

[0134] In this application, during system initialization, the system allocates the same amount of storage space to the shared partition of the first and second hardware domains. The two hardware domains store data in their respective shared partitions as needed. The system may monitor the storage usage of each hardware domain to ensure that the allocated storage space is not exceeded.

[0135] Since the storage space is the same, system management becomes simpler because there is no need to develop different management strategies for storage spaces of different sizes.

[0136] In one embodiment, such as Figure 6 As shown, the storage space of the shared partition of the first hardware domain is smaller than the storage space of the shared partition of the second hardware domain. The method further includes:

[0137] S41. Divide the physical address of the shared partition of the second hardware domain into multiple sub-physical addresses;

[0138] In this embodiment, a physical address refers to an address on the actual storage device. A sub-physical address refers to a smaller address space into which a large physical address space is divided. This is similar to dividing a large storage area (shared partition) into multiple smaller storage areas, each with its own physical address. This improves the flexibility of address management, allowing for finer control and access to different data areas.

[0139] S42. Based on the plurality of sub-physical addresses, the embedded multimedia card maps the plurality of sub-physical addresses to the shared partition of the first hardware domain in stages.

[0140] In this embodiment, mapping refers to the process of associating addresses in one address space with addresses in another. Based on sub-physical addresses, these sub-address spaces of the second hardware domain are mapped to the shared partition of the first hardware domain. The first hardware domain can access specific data areas of the shared partition of the second hardware domain through these mappings without needing to access the entire shared partition.

[0141] In this application, the storage space of the shared partition of the first hardware domain is smaller than the storage space of the shared partition of the second hardware domain. To solve this problem, this application divides the physical address of the shared partition of the second hardware domain into multiple sub-physical addresses, and then maps these sub-physical addresses to the shared partition of the first hardware domain. This allows the first hardware domain to access specific data areas of the shared partition of the second hardware domain without needing to access the entire shared partition.

[0142] For example, the first hardware domain is an application domain (AP domain), and the second hardware domain is a multi-function domain (MP domain). The shared partition of the MP domain has a large physical address range, for example, from 0x10000000 to 0x1000FFFF.

[0143] To manage this space more efficiently, the system divides this large address range into multiple sub-physical addresses, such as four sub-regions, each with a size of 0x00010000. This results in four sub-physical addresses: 0x10000000, 0x10010000, 0x10020000, and 0x10030000. These sub-physical addresses are then mapped to shared partitions within the AP domain. This allows the AP domain to access specific data areas of the MP domain through these mappings.

[0144] This application can utilize storage space more effectively by mapping the sub-physical addresses of the second hardware domain to the first hardware domain, especially when the storage space of the first hardware domain is small.

[0145] In summary, as Figure 9 or Figure 10 As shown, the data sharing method is as follows:

[0146] When an AP domain needs to access data in the shared partition of an MP domain, the AP domain first sends a second access request to the MP domain through inter-core communication. At this time, based on the update frequency of the MP domain's shared partition, it is determined whether the data in the MP domain's shared partition needs to be updated frequently. If so, the MP domain obtains the updated data to update its own shared partition, ensuring that the data in the MP domain's shared partition is up-to-date when the AP domain accesses it subsequently.

[0147] If the data in the MP domain's shared partition does not need to be updated or has been updated, the AP domain's virtual front end directly sends a first request to the security domain's virtual back end. This request indicates that the AP domain needs to access the data in the MP domain's shared partition and includes the AP domain's shared partition's first physical address.

[0148] After receiving the first access request, the backend of the security domain determines the second physical address of the shared partition of the MP domain and whether there is a mapping relationship between the shared partition of the MP domain and the shared partition of the AP domain.

[0149] If a mapping relationship exists, the physical address of the MP domain's shared partition on the embedded multimedia card is mapped to the AP domain's shared partition according to the mapping relationship, ensuring that the AP domain can access the data of the MP domain's shared partition through its shared partition.

[0150] The AP domain can begin reading and writing operations to its shared partition. In practice, these read and write operations are translated by the backend into read and write operations to the MP domain's shared partition. Therefore, the AP domain can directly process data in the MP domain's shared partition via an embedded multimedia card, without relying on shared memory.

[0151] During the process of the AP domain accessing the MP domain's shared partition, the MP domain also needs to access its shared partition. The system detects a conflict and decides to suspend the AP domain's access so that the MP domain can access the shared partition first.

[0152] After access to the AP domain is suspended, the MP domain accesses the shared partition and reads the necessary configuration files. Once the MP domain has read the configuration files and resumed its data processing, the system lifts the suspension on access to the AP domain. The AP domain can now resume accessing the MP domain's shared partition and reading media files.

[0153] Additionally, when the system detects that both domains need to access the shared partition and have obtained the latest updated data, the system suspends access for the AP domain so that the MP domain can update its shared partition. The MP domain writes the new data to the shared partition, and after the MP domain completes the update, the system notifies the AP domain that it can re-access the MP domain's shared partition, and the AP domain can now access the latest data.

[0154] This application also provides a data sharing device, such as... Figure 7 As shown, a system-on-a-chip (SoC) for multi-core heterogeneous architecture is described. The SoC includes multiple hardware domains, which are hard isolated from each other. One hardware domain is connected to an embedded multimedia card (EMC). A virtual backend for accessing the EMC is configured in this hardware domain. Virtual frontends for communicating with the virtual backend are configured in at least two other hardware domains besides the first hardware domain. The EMC includes a primary physical partition and a secondary physical partition. At least one shared partition corresponding to each of the multiple hardware domains exists on the secondary physical partition. The device includes:

[0155] The acquisition unit is configured to acquire a first access request for a first hardware domain, wherein the first access request is an access request for the secondary physical partition;

[0156] The determining unit is configured to obtain the mapping relationship between the shared partition of the second hardware domain and the shared partition of the first hardware domain based on the first access request.

[0157] An access unit is configured to control the first hardware domain to access the shared partition of the second hardware domain based on the mapping relationship.

[0158] Specifically, the first target device is determined to be in write mode, meaning the device is ready to receive new firmware or software updates. For example, the first target device is a flash memory device.

[0159] It should be noted that the principle of the data sharing device provided in this application embodiment to solve the technical problem is similar to that of the data sharing method provided in this application embodiment. Therefore, the implementation of the data sharing device provided in this application embodiment can refer to the implementation of the data sharing method provided in this application embodiment, and repeated details will not be repeated.

[0160] This application also provides a chip, such as... Figure 8 As shown, it includes multiple hardware domains, which are hard isolated from each other. Each hardware domain includes at least a security domain, an application domain, and a multi-purpose domain. A virtual backend that communicates with the embedded multimedia card is set on the security domain. Virtual frontends that communicate with the virtual backend are set on the application domain and the multi-purpose domain, respectively. Inter-core communication exists between the application domain and the multi-purpose domain.

[0161] This application also provides an electronic device, including a processor and a storage device, wherein the storage device stores an executable program, and the storage device executes the executable program to perform the steps of the method described above.

[0162] This application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the aforementioned display method.

[0163] This application provides a storage medium that carries one or more computer programs, which, when executed by a processor, implement the steps of the method described above.

[0164] It should be understood that in the embodiments of this application, the processor may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0165] It should also be understood that the memory mentioned in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0166] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, the memory (storage module) is integrated into the processor.

[0167] It should be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0168] It should also be understood that the first, second, third, fourth and various numerical designations used herein are merely for descriptive convenience and are not intended to limit the scope of this application.

[0169] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0170] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0171] In the various embodiments of this application, the order of the above-mentioned processes does not imply 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 this application.

[0172] Those skilled in the art will recognize that the various illustrative logical blocks (ILBs) and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0173] In the several embodiments provided in this application, it should be understood that the disclosed multi-chip detection methods, apparatuses, electronic devices, and storage media can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0174] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0175] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0176] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0177] The above embodiments are merely exemplary embodiments of this application and are not intended to limit this application. The scope of protection of this application is defined by the claims. Those skilled in the art can make various modifications or equivalent substitutions to this application within its substance and scope of protection, and such modifications or equivalent substitutions should also be considered to fall within the scope of protection of this application.

Claims

1. A data sharing method, characterized in that: A system chip applied to multi-core heterogeneous system, the system chip includes multiple hardware domains, the multiple hardware domains are hard-isolated, one of the hardware domains is connected to an embedded multimedia card, a virtual backend for accessing the embedded multimedia card is set in the one hardware domain, and a virtual front end for communicating with the virtual backend is respectively set in at least two hardware domains other than the first hardware domain, the embedded multimedia card includes a primary physical partition and a secondary physical partition, and at least one shared partition corresponding to each of the multiple hardware domains exists on the secondary physical partition, and the method includes: Obtaining a first access request of the first hardware domain, wherein the first access request is an access request to the secondary physical partition; Based on the first access request, obtaining a mapping relationship between the shared partition of the second hardware domain and the shared partition of the first hardware domain; Based on the mapping relationship, the first hardware domain is controlled to access the shared partition of the second hardware domain.

2. The data sharing method according to claim 1, characterized in that: The first hardware domain and the second hardware domain are capable of inter-core communication, and the method further includes: Determining an update frequency of data of the shared partition of the second hardware domain; Acquire a second access request of the first hardware domain, wherein the second access request includes an access request to the second hardware domain and an update request to a shared partition of the second hardware domain; acquiring update data based on the update frequency and the second access request; Based on the update data, the shared partition of the second hardware domain is updated.

3. The data sharing method according to claim 1, characterized in that: The determining, based on the first access request, a mapping relationship between the shared partition of the second hardware domain and the shared partition of the first hardware domain includes: Based on the first access request, obtaining a first physical address of an access object, wherein the access object is any partition in the secondary physical partition; Acquire, by means of the embedded multimedia card, a second physical address of the shared partition of the second hardware domain; When it is obtained that a mapping relationship exists between the first physical address and the second physical address, the second physical address is mapped to the first physical address.

4. The data sharing method according to claim 1, characterized in that: The method further comprises: In a case where both the first hardware domain and the second hardware domain access the shared partition of the second hardware domain, suspending the first hardware domain from accessing the shared partition of the second hardware domain so that the second hardware domain accesses the shared partition of the second hardware domain; When the second hardware domain obtains the target data, the first hardware domain continues to access the shared partition of the second hardware domain.

5. The data sharing method according to claim 4, characterized in that: The method further comprises: In a case where both the first hardware domain and the second hardware domain access a shared partition of the second hardware domain, acquiring update data; Based on the update data, suspending the first hardware domain from accessing the shared partition of the second hardware domain, so that the second hardware domain updates the shared partition of the second hardware domain; The first hardware domain re-accesses the shared partition of the second hardware domain, wherein the shared partition stores the updated data.

6. The data sharing method according to claim 1, characterized in that: The storage space of the shared partition of the first hardware domain is the same as the storage space of the shared partition of the second hardware domain.

7. The data sharing method according to claim 1, characterized in that: The storage space of the shared partition of the first hardware domain is smaller than the storage space of the shared partition of the second hardware domain, and the method further includes: Dividing the physical address of the shared partition of the second hardware domain into a plurality of sub-physical addresses; Based on the multiple sub-physical addresses, the embedded multimedia card maps the multiple sub-physical addresses to the shared partitions of the first hardware domain in batches.

8. A data sharing device, characterized in that: A system chip applied to multi-core heterogeneous system, the system chip includes multiple hardware domains, the multiple hardware domains are hard-isolated, one of the hardware domains is connected to an embedded multimedia card, a virtual backend for accessing the embedded multimedia card is set in the one hardware domain, and a virtual front end for communicating with the virtual backend is respectively set in at least two hardware domains other than the first hardware domain, the embedded multimedia card includes a primary physical partition and a secondary physical partition, and at least one shared partition corresponding to each of the multiple hardware domains exists on the secondary physical partition, and the device includes: an acquiring unit configured to acquire a first access request of the first hardware domain, wherein the first access request is an access request to the secondary physical partition; a determining unit configured to obtain, based on the first access request, a mapping relationship between a shared partition of the second hardware domain and a shared partition of the first hardware domain; An access unit is configured to control the first hardware domain to access the shared partition of the second hardware domain based on the mapping relationship.

9. A chip, characterized in that: It comprises a plurality of hardware domains, which are hard-isolated from each other. The hardware domains comprise at least a security domain, an application domain and a multi-purpose domain. A virtual backend for communicating with an embedded multimedia card is arranged on the security domain. A virtual frontend for communicating with the virtual backend is arranged on the application domain and the multi-purpose domain respectively. Inter-core communication is performed between the application domain and the multi-purpose domain.

10. An electronic device, characterized in that: The method comprises a processor and a storage device, wherein the storage device stores an executable program, and the storage device executes the executable program to perform the steps of the method according to any one of claims 1 to 7.

Images