Cross-system interaction method, apparatus, and chip

Abstract

The application discloses a cross-system interaction method, device and chip, and the method comprises the following steps: acquiring various attribute categories of a reference operating system, and sending the various attribute categories to various non-reference operating systems; determining target attribute categories corresponding to the various non-reference operating systems from the various attribute categories through the various non-reference operating systems, and sending requests generated based on the target attribute categories to the reference operating system. The cross-system interaction method improves the interoperability between different operating systems, and provides strong support for the intelligent development of automobile embedded systems.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of chip design, testing and production, in particular to a cross-system interaction method and device and a chip. BACKGROUND

[0002] With the continuous development of automotive technology, embedded systems are increasingly popular in modern vehicles. These systems usually run on various operating systems, such as Android, Linux, QNX, FreeRTOS, etc. These operating systems each have their own characteristics and provide different functions and services to meet the needs of vehicle intelligence and automation. However, as the number of embedded systems within the vehicle increases, the demand for data sharing and information exchange between systems also increases.

[0003] In vehicles, information exchange between multiple embedded systems not only improves the collaborative working ability of the system, but also provides more rich functions and better user experience. For example, the navigation system can share location information with the car entertainment system to recommend appropriate music or radio content based on the driver's location. At the same time, the safety system of the vehicle also needs to exchange information with other systems to monitor and respond to potential safety risks in real time.

[0004] Currently, cross-operating system information transmission mainly relies on network communication technology or inter-core communication technology on System On Chip (SoC). However, these existing technologies have some limitations in practical applications. Cross-operating system communication technology based on network protocols is limited by network bandwidth, delay and security in some scenarios, making it difficult to meet real-time and reliability requirements. While inter-core communication-based technology can achieve low-latency data transmission, the upper operating system often cannot naturally support and recognize information from other operating systems, resulting in increased complexity of information exchange. In addition, the operating system layer needs to perform a large number of connection establishment and information transmission operations, which not only increases development costs, but also may affect the overall performance and stability of the system. SUMMARY

[0005] Therefore, the embodiments of the present application provide a cross-system interaction method, which is applied to a chip including at least two different processor cores, the processor cores respectively form hardware domains with their corresponding hardware resources, different hardware domains are deployed with different operating systems and have inter-core communication between different operating systems, the method comprises: obtaining each attribute category of a reference operating system, and sending each attribute category to each non-reference operating system; determining a target attribute category corresponding to each non-reference operating system from each attribute category through each non-reference operating system, and sending a request generated based on the target attribute category to the reference operating system.

[0006] Optionally, before sending the request generated based on the target attribute category to the benchmark operating system, the method further includes: querying the cached attribute data for each target attribute category in each non-benchmark operating system to see if there is corresponding attribute data; if the attribute data corresponding to the target attribute category exists in the non-benchmark operating system, obtaining the attribute data corresponding to the target attribute category; if the attribute data corresponding to the target attribute category does not exist in the non-benchmark operating system, generating a request based on the target attribute category.

[0007] Optionally, the method further includes: cyclically detecting whether a setting attribute request from a non-baseline operating system has been received by the base operating system according to a preset period; analyzing the setting attribute request by the base operating system to obtain the attribute category to be set and the attribute data to be set; determining whether the attribute category to be set is cached in the base operating system; if the attribute category to be set is cached in the base operating system, determining whether the attribute data to be set is the same as the attribute data cached in the base operating system; if they are different, updating the attribute data cached in the base operating system based on the attribute data to be set.

[0008] Alternatively, the method may also include: determining whether the attribute category to be set is a read-only attribute category through the benchmark operating system; if the attribute category to be set is a read-only attribute category, sending a setting failure message to the non-benchmark operating system.

[0009] Alternatively, the method may also include: if the attribute category to be set is not a read-only attribute category, determining whether the non-baseline operating system has permission to set the attribute category to be set through the baseline operating system; if the non-baseline operating system does not have permission to set the attribute category to be set, sending a setting failure message to the non-baseline operating system.

[0010] Alternatively, the method may also include: if the base operating system does not contain the attribute category to be set, determining whether the attribute category to be set belongs to a cross-system attribute category through the base operating system; if the attribute category to be set belongs to a cross-system attribute category, writing the attribute category to be set and the attribute data to be set into the base operating system.

[0011] As an option, the method further comprises: periodically querying, by the reference operating system, whether there is an attribute data acquisition request of a non-reference operating system according to a preset period; if there is an attribute data acquisition request of a non-reference operating system, analyzing, by the reference operating system, the attribute data acquisition request to obtain an attribute category in the attribute data acquisition request; determining whether the attribute category in the attribute data acquisition request is cached in the reference operating system; if the attribute category is cached in the reference operating system and attribute data corresponding to the attribute category is not cached, determining whether the attribute category is associated with a non-reference operating system; if the attribute category is associated with a non-reference operating system, sending the attribute category to the associated non-reference operating system, returning, by the associated non-reference operating system, attribute data corresponding to the attribute category to the reference operating system, and returning, by the reference operating system, the attribute data corresponding to the attribute category to the non-reference operating system.

[0012] As an option, the method further comprises: if the attribute category is cached in the reference operating system and attribute data corresponding to the attribute category is not cached and the attribute category is not associated with a non-reference operating system, returning, by the reference operating system, waiting attribute data change notification information to the non-reference operating system; acquiring, by the non-reference operating system, changed attribute data corresponding to the attribute category from the reference operating system based on the waiting attribute data change notification information.

[0013] Embodiments of the present application also provide a cross-system interaction device, applied to a chip including at least two different processor cores, the processor cores respectively forming hardware domains with corresponding hardware resources, different hardware domains being deployed with different operating systems and the different operating systems having inter-core communication, the device comprising: an acquisition module, configured to acquire each attribute category of a reference operating system and send each attribute category to each non-reference operating system; and a determination module, configured to determine, by each non-reference operating system, a target attribute category corresponding to the non-reference operating system from each attribute category and send a request generated based on the target attribute category to the reference operating system.

[0014] Embodiments of the present application also provide a chip, which is integrated with the above cross-system interaction device.

[0015] Embodiments of the present application also provide an electronic device, which comprises a processor and a memory, the memory storing an executable program, and the memory executing the executable program to perform the steps of the above method.

[0016] Embodiments of the present application also provide a storage medium, which carries one or more computer programs, and the one or more computer programs are executed by a processor to implement the steps of the above method.

[0017] The cross-system interaction method of the embodiments of the present application can achieve efficient information interaction by establishing an inter-core communication mechanism between different hardware domains, share attribute categories between the benchmark operating system and the non-benchmark operating system, help quickly identify and respond to information requests, reduce the delay of information transmission, and deploy different operating systems on the same chip, making the system flexible to adapt to various application scenarios. Through the automatic attribute category acquisition and request generation process, developers no longer need to write complex code for information interaction between different operating systems, reducing development workload and time, thereby reducing development costs. Dynamically adjust and expand the functions of different operating systems as needed. By simply adding new attribute categories, the system's functionality can be easily expanded to meet future technological development needs. And through efficient interaction between different operating systems, users can enjoy a smoother and more consistent operating experience. For example, the in-vehicle entertainment system can better work with the navigation system to provide personalized services and information, thereby improving overall user satisfaction. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 A structural diagram of cross-system interaction of different operating systems of different hardware domains of the embodiments of the present application;

[0019] Figure 2 A flowchart of the cross-system interaction method of the embodiments of the present application;

[0020] Figure 3 A schematic diagram of the cross-system interaction method of the embodiments of the present application applied to the attribute framework;

[0021] Figure 4 A flowchart of the cross-system interaction method of another embodiment of the present application;

[0022] Figure 5 A flowchart of the cross-system interaction method of another embodiment of the present application;

[0023] Figure 6 A schematic diagram of the cross-system interaction method of the embodiments of the present application applied to the attribute framework;

[0024] Figure 7 A flowchart of the cross-system interaction method of another embodiment of the present application;

[0025] Figure 8 A flowchart of the cross-system interaction method of another embodiment of the present application;

[0026] Figure 9 A flowchart of the cross-system interaction method of another embodiment of the present application;

[0027] Figure 10 A flowchart of the cross-system interaction method of another embodiment of the present application;

[0028] Figure 11 Flowchart of a cross-system interaction method according to another embodiment of the application;

[0029] Figure 12 Structural diagram of a cross-system interaction of different operating systems of different hardware domains according to another embodiment of the application;

[0030] Figure 13 Block diagram of a cross-system interaction apparatus according to an embodiment of the application;

[0031] Figure 14 Structural block diagram of an electronic device according to an embodiment of the application. DETAILED DESCRIPTION

[0032] Various aspects and features of the present application are described herein with reference to the accompanying drawings.

[0033] It is to be understood that various alterations, modifications, and improvements can be made to the embodiments of the application herein disclosed. Accordingly, it is intended to embrace all such alterations, modifications, and improvements as fall within the scope and spirit of the application.

[0034] The accompanying drawings incorporated in and forming a part of the specification illustrate embodiments of the present application and, together with the general description of the application given above, and the detailed description of the embodiments given below, serve to explain the principles of the present application.

[0035] These and other characteristics, features and advantages of the present application will become apparent from the following description, taken with the accompanying drawings, illustrating preferred forms of various embodiments of the present application.

[0036] It is also to be understood that the application is not limited to the particular implementations illustrated herein, but the right to all equivalents thereof is reserved.

[0037] The above and other aspects, features and advantages of the present application will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which:

[0038] Specific embodiments of the present application are described herein with reference to the accompanying drawings. However, it should be noted that the application is merely an example of the application, which can be implemented in various ways. Well-known and / or repetitive functions and structures are not described in detail to avoid unnecessary or redundant details that would obscure the application. Therefore, the specific structural and functional details of the application described herein are not intended to be limiting, but are merely representative of the application and are used as a basis for the claims and representative of the application.

[0039] The specification can use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in other embodiments,” which can refer to one or more embodiments according to the present application.

[0040] For the convenience of understanding the cross-system interaction method of the present application, the detailed description of at least one technical term involved in implementing the method is listed below.

[0041] System on Chip (SoC) refers to integrating multiple hardware components such as Central Processing Unit (CPU), memory controller, Graphics Processing Unit (GPU), etc. on a single chip to realize a complete computing system. The SOC can contain a die or multiple dies of the same or different wafers.

[0042] Multi-core heterogeneity refers to a chip architecture design that integrates multiple processing cores (nuclei) and at least two of these cores differ in structure, function, or performance. Some tasks may be more suitable for high-performance general-purpose processor cores, while other tasks may require more specialized processor cores to improve efficiency. Multi-core heterogeneity can better balance performance, power consumption, and cost factors, providing more flexible and efficient solutions.

[0043] System on Chip (SoC) integrates multiple hardware components such as Central Processing Unit (CPU), memory controller, Graphics Processing Unit (GPU), etc. These hardware resources are configured as multiple different hardware component sets, called hardware domains, and each operating system runs independently in each hardware domain. Each hardware domain works independently to prevent mutual interference or influence, improving the reliability, stability, and anti-interference ability of the SOC.

[0044] Inter-core communication refers to communication between different hardware domains within the SOC, including asynchronous message passing through the mailbox mechanism and data sharing across hardware domains through shared memory mechanisms.

[0045] A security domain is one or more hardware domains that include at least one of the following features: a high functional safety architecture, running an operating system that meets high functional safety requirements, and handling tasks that meet high functional safety requirements.

[0046] Real-time Operating System (RTOS) is an operating system specifically designed to handle real-time tasks.

[0047] The cross-system interaction method of the application is applied to a chip including at least two different processor cores, the processor cores respectively form hardware domains with their corresponding hardware resources, different hardware domains are deployed with different operating systems and have inter-core communication between different operating systems, and the method comprises: obtaining each attribute category of a reference operating system, and sending each attribute category to each non-reference operating system; determining a target attribute category corresponding to each non-reference operating system from each attribute category through each non-reference operating system, and sending a request generated based on the target attribute category to the reference operating system.

[0048] For example, the chip including at least two different processor cores can be a SOC, the SOC contains multiple hardware domains, each hardware domain is a set of hardware resources such as processor cores, clock controllers, interrupt controllers, GPUs, etc., and the hardware domain can be configured to run different operating systems. Heterogeneous hardware domains refer to different hardware resource sets, such as different processor core types or other hardware resources, which result in different hardware domains that cannot be scheduled by the same operating system. It can be understood that the reference operating system in the application can implement communication between different types of operating systems. For example, obtaining each attribute category of the reference operating system and sending each attribute category to each non-reference operating system, determining a target attribute category corresponding to each non-reference operating system from each attribute category through each non-reference operating system, and sending a request generated based on the target attribute category to the reference operating system, at this time the reference operating system can obtain data corresponding to the target attribute category from the non-reference operating system based on the request, and can display the obtained data to the screen.

[0049] It can be understood that during the chip design phase, developers can pre-write logic according to system requirements and hardware architecture to determine which operating system to select as the reference operating system during initialization. For example, available resources in each hardware domain can be evaluated, such as processor core performance, memory size, peripheral interface, etc., to determine the most suitable operating system. If a hardware domain has more computing resources and memory, a powerful and resource-demanding operating system can be selected as the reference. According to the functional requirements of the system, an operating system that best meets these requirements is selected. For example, if the system requires real-time processing capability, a real-time operating system (RTOS) can be selected as the reference. When selecting the reference operating system, compatibility with other operating systems needs to be considered to ensure smooth information exchange between different hardware domains. In this process, the chip will execute pre-programmed logic to automatically select the most suitable reference operating system and prepare for subsequent initialization and configuration.

[0050] In addition to the pre-programmed logic, the chip can also dynamically select the reference operating system based on the configuration file during initialization. For example, the configuration file lists the version number, characteristics and functional modules of each operating system, helping the system to make a choice when starting. The configuration file can contain specific parameters for different hardware domains, such as memory allocation, priority settings, etc., which will affect the selection of the reference operating system. The configuration file may also define the startup order and dependency relationship between operating systems, ensuring that all necessary system components and services can be loaded in the correct order during startup. During initialization, the operating system reads the configuration file and dynamically selects the reference operating system based on the settings and conditions in it. The advantage of this method is that it allows the system to be flexible and adaptable to different application requirements according to the changes in the actual running environment.

[0051] Specifically, after the chip is powered on, it enters the initialization phase. The operating system automatically detects the status and available resources of each hardware domain. The configuration file is read from the memory to obtain relevant information of the operating system. If there is pre-programmed logic, the reference operating system will be selected according to the logic judgment. If there is no pre-programmed logic, the reference operating system will be selected according to the information in the configuration file. When the reference operating system is determined, the operating system will be loaded and necessary initialization and configuration will be performed. After the reference operating system is successfully started, other non-reference operating systems can be started as needed.

[0052] Through the above process, the chip can flexibly select the reference operating system according to the pre-programmed logic or the configuration file during the initialization phase. This not only improves the efficiency of system startup, but also enhances the flexibility and scalability of the system, laying the foundation for subsequent multi-operating system collaboration.

[0053] Reference Figure 1 In the three heterogeneous hardware domains (e.g., first hardware domain, second hardware domain, security domain) of the SOC, the first hardware domain, the second hardware domain, and the security domain are respectively configured to run Android, Linux, and a real-time operating system (RTOS). When the chip starts, the RTOS in the security domain starts faster, which can be used as the reference operating system mentioned above, and the control screen 1 and the screen 2 both display the boot animation provided by the RTOS.

[0054] When the Android operating system is started, a system start completion message is triggered, an event property is formed, the property is broadcasted through a property control module, and when the RTOS in the security domain detects the property, it can recognize the message through the same protocol, and it can obtain the Android system screen through an inter-core communication channel with the Android system and display the screen on screen 1. Similarly, when the Linux start is detected, the RTOS can recognize the corresponding message through a similar property mechanism, control the acquisition of the Linux start screen, and display the screen on screen 2.

[0055] The cross-system interaction method based on inter-core communication will be described in detail below with reference to the accompanying drawings. Figure 2 The flowchart of the cross-system interaction method of the embodiment of the present application. The cross-system interaction method is applied to a chip including at least two different processor cores, the processor cores form hardware domains with their corresponding hardware resources, different hardware domains deploy different operating systems, and the different operating systems have inter-core communication.

[0056] As shown in Figure 2 The cross-system interaction method includes steps S210 and S220.

[0057] In step S210, each attribute category of the reference operating system is obtained, and each attribute category is sent to each non-reference operating system.

[0058] For example, the hardware domain architecture shown in Figure 1 The reference operating system can be the RTOS in the security domain, and the non-reference operating system can be the Android in the first hardware domain and the Linux in the second hardware domain.

[0059] It can be understood that the message form of the operating system running in different hardware domains is configured as an attribute (property), the property is a pair of key / value combinations, the key and the value are both string types, the key can be 32 bytes, and the value can be 64 bytes. The size of the key / value can be set to different sizes according to system requirements. Each attribute category described above can be a corresponding key, and the attribute data corresponding to the attribute category is a value. In this embodiment, the operating system running in different hardware domains writes its attribute category and corresponding attribute data into a storage module during the startup process. After the reference operating system and the non-reference operating system are started, the attribute categories of each operating system in the storage module can be read by the reference operating system, and these attribute categories are sent to the non-reference operating system.

[0060] By configuring the message format of operating systems running on different hardware domains as properties, an efficient and structured information transmission mechanism is achieved. In addition, key / value pairings enable the system to flexibly define and transmit various attribute data, enhancing the interoperability and collaboration capabilities between different operating systems. This not only improves the efficiency of information sharing between systems, but also provides a good foundation for subsequent system integration and functional expansion.

[0061] refer to Figure 3 This diagram illustrates the overall architecture of System Properties and the interaction logic between its various modules. For example, the storage module stores the attribute categories and corresponding data for each operating system. This storage module can be understood as the central information storage, ensuring data accessibility across different components. It can interact with other modules (such as the kernel processing module and resource loader), providing attribute categories and attribute data for subsequent processing and use. The kernel processing module obtains persistent storage attributes through the storage module and manages the attribute categories and attribute data of each operating system in different hardware domains through the communication module. The communication module facilitates information transfer between different operating systems, enabling inter-kernel communication between the base operating system and non-base operating systems. In this embodiment, the attribute categories and attribute data of different operating systems can be sent to the base operating system through the communication module and the kernel processing module. The base operating system can then share the attribute categories and attribute data of each operating system with the non-base operating system. In this embodiment, the base operating system can obtain the attribute categories and attribute data from the storage module through the rpmsg driver. The rpmsg driver connects to the communication module, processes information from the kernel processing module, and sends it to the base operating system.

[0062] In some embodiments, to better store attribute categories and attribute data for different operating systems, the attribute categories and attribute data in the aforementioned storage module can be transferred to the EMMC (Embedded Multimedia Card). The EMMC is a storage device that can be used to persistently store attribute categories and attribute data for various operating systems. The resource loader (res_loader) can interact with the storage module to obtain the attribute categories and attribute data from the storage module and provide them to the EMMC.

[0063] pass Figure 3The illustrated attribute framework enables efficient information sharing between operating systems running in different hardware domains through the collaborative work of the storage module, core processing module, and communication module. The resource loader and rpmsg driver further enhance the system's flexibility and scalability, ensuring timely information delivery and processing. This architecture provides a solid foundation for realizing the intelligence and automation of automotive embedded systems.

[0064] In step S220, the target attribute category corresponding to each attribute category is determined from each attribute category by each non-baseline operating system, and the request generated based on the target attribute category is sent to the baseline operating system.

[0065] For example, a non-baseline operating system filters out target attribute categories related to its desired functions from all attribute categories sent by the baseline operating system. For instance, the specific attribute categories that the non-baseline operating system is interested in could be categories related to functionality, performance requirements, or resource management.

[0066] refer to Figure 1 As shown, the Android system in the first hardware domain can obtain Android, Linux, and / or RTOS-related attribute categories from the attribute categories sent by the RTOS in the security domain. Similarly, the Linux system in the second hardware domain can obtain Android, Linux, and / or RTOS-related attribute categories from the attribute categories sent by the RTOS in the security domain. Once the target attribute categories are determined, the non-baseline operating system will construct a request based on these categories. The content of this request typically includes the request type, target attribute category, data format, etc. In this embodiment, the request type refers to the data type of the request (e.g., reading attribute data), the target attribute category lists all target attribute categories that need to be obtained, and the data format can mean that the requested data format must follow a preset protocol to ensure that the baseline operating system can correctly parse and process it. Through the above steps, the non-baseline operating system can effectively obtain the required attribute categories from the baseline operating system. This not only improves the efficiency of information sharing between systems but also enhances the collaborative working capabilities between various operating systems, providing a foundation for realizing complex multi-operating system environments.

[0067] The cross-system interaction method provided in this embodiment enables efficient information exchange by establishing an inter-core communication mechanism between different hardware domains. Attribute category sharing between the baseline and non-baseline operating systems facilitates rapid identification and response to information requests, reduces information transmission latency, and allows for the deployment of different operating systems on the same chip, enabling the system to flexibly adapt to various application scenarios. By automating the attribute category acquisition and request generation process, developers no longer need to write complex code for information interaction between different operating systems, reducing development workload and time, thereby lowering development costs. The functionality of different operating systems can be dynamically adjusted and expanded as needed. By simply adding new attribute categories, the system's functionality can be easily expanded to meet the needs of future technological developments. Furthermore, by achieving efficient interaction between different operating systems, users can enjoy a smoother and more consistent operating experience. For example, in-vehicle entertainment systems can better collaborate with navigation systems to provide personalized services and information, thereby improving overall user satisfaction.

[0068] Figure 4 A flowchart of another embodiment of the cross-system interaction method of this application is shown below. Figure 4 As shown, before sending the request generated based on the target attribute category to the benchmark operating system, the above method further includes steps S410 and S420.

[0069] In step S410, each non-baseline operating system queries the cached attribute data to determine if corresponding attribute data exists for each target attribute category.

[0070] In step S420, if attribute data corresponding to the target attribute category exists in the non-baseline operating system, the attribute data corresponding to the target attribute category is obtained; or if attribute data corresponding to the target attribute category does not exist in the non-baseline operating system, a request is generated based on the target attribute category.

[0071] For example, target attribute categories can be specific target attribute categories that the non-baseline operating system needs to focus on, and these categories are closely related to the functions and performance metrics required for its operation. For example, Android or Linux systems might focus on attributes such as CPU utilization, memory status, and network connectivity. The local cache is a temporary storage area in memory for attribute data stored by the non-baseline operating system. Its main purpose is to improve system performance by quickly accessing and reducing the frequency of requests to the baseline operating system. The cache typically stores data in key / value pairs, where the key is a unique identifier for the attribute (such as an attribute ID), and the value is the specific data associated with that attribute. For example, before generating a request and sending it to the baseline operating system, the non-baseline operating system can query the local cache based on the ID of the target attribute category to check if corresponding attribute data exists. The non-baseline operating system first determines the unique ID of the target attribute category, which is used for lookup in the cache. If the non-baseline operating system contains this ID, it accesses the local cache based on this ID, performs a lookup operation, checks if attribute data corresponding to that ID exists, and if the corresponding attribute data is found in the local cache, the non-baseline operating system will directly retrieve the data from the cache without sending a request to the baseline operating system. The attribute data obtained in this embodiment can be used for the operation and function implementation of the non-baseline operating system, such as resource management and performance optimization. Conversely, if the corresponding attribute data is not found in the local cache, the non-baseline operating system will generate a request to query the baseline operating system for the required attribute data.

[0072] By querying the attribute data in the local cache before sending a request to the benchmark operating system, the efficiency of information retrieval can be significantly improved. This mechanism reduces the dependence on the benchmark operating system, lowers the communication burden, and ensures that the non-benchmark operating system can respond quickly to user requests or system requirements. Through reasonable management and utilization of the local cache, the system can achieve more efficient resource use and a better user experience.

[0073] Figure 5 A flowchart of another embodiment of the cross-system interaction method of this application is shown below. Figure 4 As shown, the above method further includes steps S510 to S540.

[0074] In step S510, the base operating system cyclically checks whether a setting attribute request from a non-base operating system has been received according to a preset cycle.

[0075] For example, after booting, the baseline operating system (such as a secure domain RTOS) can set a preset detection cycle based on system requirements. This cycle can be a fixed time interval (such as per second, per minute, etc.) or dynamically adjusted according to system load. The baseline operating system then cyclically checks for setting attribute requests from non-baseline operating systems (such as Android or Linux) based on the preset time intervals. Setting attribute requests can instruct the baseline operating system to modify existing attribute categories and their corresponding attribute data in the storage module. For example, the non-baseline operating system may need to update the value of a certain attribute to reflect the current system state. Setting attribute requests can also instruct the baseline operating system to add new attribute categories and corresponding attribute data to the storage module, allowing the system to dynamically adjust according to new requirements or functional expansions.

[0076] Specifically, taking RTOS with the baseline operating system as the security domain and Android and / or Linux systems with the non-baseline operating system as the first hardware domain and / or the second hardware domain as examples:

[0077] After booting, the RTOS begins to periodically detect requests from Android and / or Linux. If the Android or Linux system sends a request to set attributes, the RTOS will receive and parse the request. Based on the instructions of the request, the RTOS updates the attribute categories in the storage module or adds attribute data to ensure that all systems can access the latest information.

[0078] By periodically and cyclically detecting setting attribute requests from non-baseline operating systems, the baseline operating system can dynamically manage and update attribute data. This mechanism not only improves the system's flexibility and responsiveness but also ensures information sharing and collaborative work between different operating systems. Through reasonable request processing and data updates, the system can better adapt to ever-changing application needs and environments.

[0079] In step S520, the attribute request is analyzed by the benchmark operating system to obtain the attribute category and attribute data to be set.

[0080] For example, the base operating system can parse the setting attribute request based on a communication protocol agreed upon with the non-base operating system to extract the attribute category to be set and the attribute data to be set from the setting attribute request. In this embodiment, the attribute category to be set can be the attribute category to be modified, and the attribute data to be set can be the attribute data to be modified. Alternatively, the attribute category to be set can also be the attribute category to be added, and the attribute data to be set can also be the attribute data to be added.

[0081] Specifically, taking RTOS with the baseline operating system as the security domain and Android and / or Linux systems with the non-baseline operating system as the first hardware domain and / or the second hardware domain as examples:

[0082] After the RTOS detects a request for an attribute to be set from Android and / or Linux, it parses the detected request according to the communication protocol agreed upon between the RTOS and Android and / or Linux to extract the attribute category and attribute data to be set from the request.

[0083] In step S530, it is determined whether the attribute category to be set is cached in the base operating system. If the attribute category to be set is cached in the base operating system, it is determined whether the attribute data to be set is the same as the attribute data cached in the base operating system.

[0084] For example, the base operating system accesses the storage module to check if the attribute category to be set is cached in the base operating system. For instance, the base operating system searches the storage module using the attribute category ID. If the corresponding attribute category is found, the next comparison process begins; if not, the attribute category needs to be added. In this embodiment, if the attribute category to be set is stored in the storage module, the base operating system extracts the attribute data corresponding to the category ID from the storage module. Then, the base operating system compares the attribute data to be set with the attribute data in the storage module to ensure that the attribute data to be set and the attribute data in the storage module have the same format (e.g., data type, structure). For example, the attribute data to be set is compared item by item with the attribute data in the storage module to determine if they are the same.

[0085] In step S540, if they are different, the attribute data cached in the base operating system is updated based on the attribute data to be set.

[0086] For example, if the attribute data to be set is the same as the attribute data in the storage module, the base operating system may not perform any updates. This reduces unnecessary storage operations and improves system efficiency. In this case, the base operating system can record the result of the operation to indicate that the attribute data has not changed. If the attribute data to be set is different from the attribute data in the storage module, the base operating system will prepare to update the attribute data in the storage module. For example, it may replace the attribute data in the storage module with the new attribute data to be set.

[0087] By checking the storage module of the benchmark operating system to see if the attribute category to be set exists in the cache, and if so, retrieving the corresponding attribute data based on that category and comparing it with the cached data, the benchmark operating system effectively manages attribute data updates. This process ensures system efficiency, reduces unnecessary storage operations, and maintains data consistency and accuracy. Through reasonable cache management and data comparison mechanisms, the benchmark operating system can better adapt to dynamically changing application requirements.

[0088] In this embodiment, if the attribute category to be set is not found in the storage module of the base operating system, the attribute category to be set can be added to the storage module, and the corresponding newly added attribute data to be set can be stored in the storage module.

[0089] refer to Figure 6 As shown, taking an RTOS with the baseline operating system as the security domain and an Android and / or Linux system with a non-baseline operating system as the first hardware domain and / or the second hardware domain as an example:

[0090] After the RTOS boots up, the property service within the RTOS can start automatically or periodically according to preset tasks. Once started, the property service retrieves persistent storage attributes from the storage module and loads them into a local queue. It then loads RAM-based attributes into the local queue and initializes temporary storage attributes. The RTOS client, upon startup, can establish a connection with the property service (i.e., the server). The RTOS client can retrieve various categories from the attribute list in the local queue and synchronize them to the Android and / or Linux systems. Upon receiving the categories, the Android and / or Linux systems can filter out the attribute categories of interest and check their local cache for corresponding attribute data. If the cache does not contain the data, a request can be generated based on the filtered attribute categories to retrieve the corresponding attribute data from the RTOS. For example, upon receiving this request, the RTOS client can query the attribute list in the local queue to find the attribute data matching the request, i.e., retrieve the attribute value corresponding to the attribute category of interest to Android and / or Linux, and return the matching attribute data to the Android and / or Linux systems. In this embodiment, the RTOS can also periodically check for setting attribute requests from Android and / or Linux systems, and also send its own setting attribute requests. These requests are used to update attribute data in the storage module of the RTOS or add attribute categories and attribute data. After updating or adding attribute data in the storage module based on the setting attribute requests, the RTOS can notify the Android and / or Linux systems of the data change. This allows the RTOS to promptly notify the Android and / or Linux systems of its successful request response, enabling them to retrieve the changed attribute data from the RTOS later according to their actual needs.

[0091] Figure 7 A flowchart of another embodiment of the cross-system interaction method of this application is shown below. Figure 7 As shown, before sending the request generated based on the target attribute category to the benchmark operating system, the above method further includes steps S710 and S720.

[0092] In step S710, the baseline operating system determines whether the attribute category to be set is a read-only attribute category.

[0093] For example, the benchmark operating system detects a setting attribute request from a non-benchmark operating system (such as Android or Linux) within a preset period. The benchmark operating system parses the received request, extracts the attribute category ID to be set, and determines whether the attribute category ID is a read-only attribute category. This read-only attribute category represents an attribute category that is not allowed to be modified by the non-benchmark operating system. For example, these categories can usually be defined by the benchmark operating system, representing certain key system parameters or status information, or these categories may also involve attribute categories corresponding to the privacy content of each operating system. The benchmark operating system can maintain a list or set of read-only attribute categories, which defines which attribute categories are read-only. The benchmark operating system matches the extracted attribute category ID to be set with the list of read-only attribute categories. If the attribute category to be set is determined to be read-only, the benchmark operating system will refuse to make any modifications to that attribute; that is, the non-benchmark operating system only has the right to read the data of that attribute, but cannot modify it.

[0094] In step S720, if the attribute to be set is a read-only attribute, a setting failure message is sent to the non-baseline operating system.

[0095] For example, if the attribute to be set is a read-only attribute, the base operating system can send a setting failure message to the non-base operating system. This message indicates that the requested attribute is read-only and the setting request is rejected. If the attribute to be set is not read-only, the base operating system will continue to process the request, for example, by modifying or adding attribute data based on the attribute to be set in the request. In this embodiment, regardless of whether the request is rejected or allowed, the base operating system can record detailed information about the request, including the source of the request, the requested attribute category, and the response result.

[0096] By parsing attribute setting requests and determining whether the attribute to be set is read-only, the benchmark operating system can effectively manage access permissions for attribute data. This process ensures system security and stability, preventing unauthorized modification of critical attribute data by non-benchmark operating systems. Simultaneously, through reasonable request processing and permission management mechanisms, the benchmark operating system can maintain data consistency and reliability in a multi-operating system environment.

[0097] Figure 8 A flowchart of another embodiment of the cross-system interaction method of this application is shown below. Figure 8 As shown, before sending the request generated based on the target attribute category to the benchmark operating system, the above method further includes steps S810 and S820.

[0098] In step S810, if the attribute category to be set is not a read-only attribute category, the base operating system determines whether the non-base operating system has permission to set the attribute category to be set.

[0099] For example, the benchmark operating system detects a setting attribute request from a non-benchmark operating system (such as Android or Linux) within a preset period. The benchmark operating system parses the received request, extracts the attribute category ID to be set, and determines whether the attribute category ID is a read-only attribute category. If the attribute category is not read-only, the benchmark operating system determines whether the non-benchmark operating system has permission to set the attribute category, i.e., whether the non-operating system has permission to set the attribute category. For example, if the attribute category is not read-only, the benchmark operating system will further check whether the non-benchmark operating system has permission to set that attribute category. The benchmark operating system can define different non-benchmark operating systems' setting permissions for each attribute category. Specifically, the benchmark operating system matches the extracted attribute category ID with the permissions of the non-benchmark operating system to confirm whether it has permission to set the attribute. If the non-benchmark operating system is authorized to set the attribute category, the benchmark operating system will continue to process the request, allowing the setting of that attribute category, such as updating the attribute data in the storage module.

[0100] In step S820, if the non-baseline operating system does not have permission to set the attribute category to be set, a setting failure message is sent to the non-baseline operating system.

[0101] For example, if the non-baseline operating system does not have permission to modify the attribute category to be set, the baseline operating system will refuse to respond to the request. The baseline operating system can send a setting failure message to the non-baseline operating system, indicating that it does not have permission to set the attribute category. In this embodiment, the baseline operating system can record detailed information about this request, including: the source of the request, the requested attribute category ID, and the response result.

[0102] By detecting, parsing, and judging permissions for attribute setting requests, the baseline operating system can effectively manage the setting permissions for attribute data. This process ensures the security and stability of the system and prevents unauthorized updates of critical attribute data by non-baseline operating systems.

[0103] Figure 9 A flowchart of another embodiment of the cross-system interaction method of this application is shown below. Figure 9 As shown, before sending the request generated based on the target attribute category to the benchmark operating system, the above method further includes steps S910 and S920.

[0104] In step S910, if the base operating system does not contain the attribute category to be set, the base operating system determines whether the attribute category to be set belongs to a cross-system attribute category.

[0105] For example, the benchmark operating system detects a setting attribute request from a non-benchmark operating system (such as Android or Linux) within a preset period. The benchmark operating system parses the received request, extracts the attribute category ID to be set, and determines whether the attribute category ID is cached in the benchmark operating system. If the benchmark operating system does not contain the attribute category to be set, it can further determine whether the attribute category to be set belongs to a cross-system attribute category. A cross-system attribute category refers to attribute categories that are shared or used between different operating systems. These attribute categories usually have a specific format or prefix for easy identification. The benchmark operating system will check the attribute category ID to be set according to preset format rules, for example, determining whether the attribute category to be set begins with a specific prefix (such as "cdm"). If the attribute category ID to be set begins with "cdm", it will be determined that the attribute category is a cross-system attribute category.

[0106] In step S920, if the attribute category to be set belongs to a cross-system attribute category, the attribute category to be set and the attribute data to be set are written to the base operating system.

[0107] For example, after parsing the attribute setting request, the benchmark operating system determines whether the attribute category to be set belongs to a cross-system attribute category. If the attribute category to be set is determined to be a cross-system attribute category, the benchmark operating system can write the attribute category to be set and its corresponding attribute data to the storage module, for example, by using an appropriate storage interface and protocol to write the attribute category and data to a specified location in the storage module. Alternatively, if the attribute category to be set does not belong to a cross-system attribute category, the benchmark operating system will refuse to set the attribute category. The benchmark operating system will construct a setting failure message indicating that the requested attribute category is not allowed to be set, and send the setting failure message back to the non-benchmark operating system.

[0108] By judging the category of the attribute to be set, the base operating system can flexibly handle setting requests across system attribute categories, effectively avoiding the situation where the base operating system responds to invalid setting attribute requests, which would lead to increased load. This process ensures the security and stability of the system.

[0109] Figure 10 A flowchart of another embodiment of the cross-system interaction method of this application is shown below. Figure 10As shown, before sending the request generated based on the target attribute category to the benchmark operating system, the above method further includes steps S1010 to S1050.

[0110] In step S1010, the baseline operating system cyclically queries whether there are attribute data acquisition requests from non-baseline operating systems according to a preset period.

[0111] For example, in a multi-operating system environment, effective attribute data exchange is required between the base operating system and the non-base operating system to ensure proper system operation and data consistency. After booting, the base operating system performs a series of initialization steps, including loading an attribute list from the storage module. This list contains available attribute categories in the system, each related to the system's configuration, state, or other critical parameters. The base operating system extracts attribute categories from the storage module and sends them to the non-base operating system. Upon receiving the attribute categories from the base operating system, the non-base operating system parses this data. This parsing process includes extracting the attribute category IDs. Then, based on its own needs, the non-base operating system selects target attribute categories from the received categories. These target attribute categories may be specific attributes that the non-base operating system needs to access or modify during operation. Based on the selected target attribute categories, the non-base operating system constructs a request, typically an attribute data retrieval request, designed to request specific attribute data from the base operating system. Furthermore, tasks processed during the operation of the non-base operating system may involve retrieving attribute data. At this point, the non-baseline operating system can proactively establish an attribute data acquisition request. This request can be based on the needs of the current task to ensure that the latest attribute data is obtained. The non-baseline operating system will send the proactively established request to the baseline operating system, requesting to obtain specific attribute data.

[0112] After the benchmark operating system starts up, it can periodically query whether there are attribute data acquisition requests from non-benchmark operating systems according to a preset time period (e.g., every second or every minute). The benchmark operating system will parse the request content, obtain the target attribute category ID, and retrieve the corresponding attribute data from the storage module based on the ID.

[0113] In step S1020, if there is an attribute data acquisition request from a non-baseline operating system, the attribute data acquisition request is analyzed through the baseline operating system to obtain the attribute categories in the attribute data acquisition request.

[0114] For example, the benchmark operating system checks for attribute data retrieval requests from non-benchmark operating systems within a preset period. The benchmark operating system parses the received attribute data retrieval requests and extracts key fields. For instance, it confirms the nature of the request to ensure that it is indeed an attribute data retrieval request and retrieves the attribute category ID contained in the request.

[0115] By analyzing the attribute data acquisition requests of non-baseline operating systems, the baseline operating system can effectively identify and extract the required attribute category information. This process ensures that the system can quickly respond to the requests of non-baseline operating systems, provide the required attribute data, and maintain the consistency and accuracy of the data.

[0116] In step S1030, it is determined whether the attribute category in the attribute data retrieval request is cached in the base operating system.

[0117] For example, the benchmark operating system checks whether there are attribute data retrieval requests from non-benchmark operating systems within a preset period. The benchmark operating system parses the received attribute data retrieval requests to extract attribute categories. After extracting the attribute categories, the benchmark operating system can query the storage module to see if the attribute category is cached based on the extracted attribute categories. For example, it can traverse the attribute list in the storage module to see if the attribute category is included. If it is included, it is determined that the extracted attribute category is cached in the benchmark operating system; otherwise, it is determined that the extracted attribute category is not cached in the benchmark operating system.

[0118] In step S1040, if the attribute category is cached in the base operating system and the attribute data corresponding to the attribute category is not cached, it is determined whether the attribute category has an associated non-base operating system.

[0119] For example, in a multi-operating system environment, the base operating system needs to effectively handle attribute data retrieval requests and retrieve the corresponding attribute data from the storage module based on the requested attribute category. Upon receiving an attribute data retrieval request from a non-base operating system, the base operating system first checks whether its storage module caches the requested attribute category. If the attribute category exists in the cache, the base operating system proceeds to the next step, retrieving the attribute data corresponding to that attribute category from the storage module. If the attribute data cannot be successfully retrieved from the storage module, the base operating system records this situation, indicating that the storage module only caches the attribute category but not the corresponding attribute data. In this case, the base operating system can determine whether there is an associated non-base operating system based on the attribute category ID. These non-base operating systems can provide the attribute data for that attribute category. The associated non-base operating systems are typically predefined during system design, including Android or Linux systems. In this embodiment, the base operating system can query the non-base operating system associated with the attribute category ID through a maintained configuration or mapping table. If an associated non-base operating system is found, the base operating system will send a request to that non-base operating system, requesting it to provide the corresponding attribute data.

[0120] In step S1050, if there is an associated non-baseline operating system, the attribute category is sent to the associated non-baseline operating system, the attribute data corresponding to the attribute category is returned to the baseline operating system through the associated non-baseline operating system, and the attribute data corresponding to the attribute category is returned to the non-baseline operating system through the baseline operating system.

[0121] For example, after the base operating system determines that the attribute category extracted from the attribute data retrieval request has not been cached in the storage module, it determines whether there is an associated non-base operating system for that attribute category. If there is an associated non-base operating system, the attribute category is sent to the associated non-base operating system. The associated non-base operating system then returns the attribute data corresponding to the attribute category to the base operating system, and the base operating system then returns the attribute data corresponding to the attribute category to the non-base operating system. For example, the base operating system is an RTOS in the security domain, the non-base operating system is Android in the first hardware domain, and the non-base operating system is Linux in the second hardware domain. The RTOS detects attribute data retrieval requests from Android cyclically according to a preset period. The RTOS parses the attribute data retrieval request to extract the attribute category. Then, based on the extracted attribute category, the RTOS traverses the attribute list in the storage module to see if it contains the attribute category. When it is determined that the attribute list contains the attribute category, it continues to determine whether the attribute list contains the attribute data corresponding to the attribute category. If the attribute list does not cache the corresponding attribute data, it can be determined whether there is an associated non-base operating system for that attribute category, for example, the non-base operating system associated with the attribute category is Linux in the second hardware domain. In this scenario, the RTOS can send the attribute category to Linux. After receiving the attribute category, Linux can retrieve the corresponding attribute data from its local cache and return it to the RTOS. The RTOS can then return the attribute data received from Linux to Android.

[0122] Through the above process, the base operating system can effectively handle attribute data retrieval requests, ensuring that when the corresponding data is not found in the storage module, the required attribute data can be obtained through the associated non-base operating system. This not only improves the system's flexibility and responsiveness, but also ensures data consistency and accuracy, providing necessary support for collaborative work in a multi-operating system environment.

[0123] Figure 11 A flowchart of another embodiment of the cross-system interaction method of this application is shown below. Figure 11 As shown, before sending the request generated based on the target attribute category to the benchmark operating system, the above method further includes steps S1110 and S1120.

[0124] In step S1110, if the attribute category is cached in the base operating system and the attribute data corresponding to the cached attribute category is not stored in the non-base operating system, the base operating system returns a message waiting for attribute data change notification to the non-base operating system.

[0125] For example, in a multi-operating system environment, when the base operating system determines that the attribute category retrieved from the attribute data retrieval request is not cached in the storage module, the base operating system can determine whether there is an associated non-base operating system for that attribute category. If it is confirmed that there is no associated non-base operating system for that attribute category, the base operating system will add that attribute category to a specific list. This specific list is used to track attribute categories that do not have cached attribute data and are not associated with a non-base operating system but need to be managed. When the base operating system receives an attribute data change request for that attribute category, it will parse the request to extract the changed attribute data. Then, the base operating system will add the received attribute data to the specific list and establish a mapping relationship between the attribute data and the attribute category. At this time, the base operating system can send a "waiting for data change" communication message to the non-base operating system that sent the attribute data retrieval request. This message is used to notify the non-base operating system of the current status of the attribute category. After receiving the waiting for data change communication message, the non-base operating system can request the attribute data from the specific list from the base operating system based on this message.

[0126] In step S1120, the non-baseline operating system obtains the changed attribute data corresponding to the attribute category from the base operating system based on the waiting attribute data change notification information.

[0127] For example, the benchmark operating system can effectively manage attribute categories that are not cached and are not associated with non-benchmark operating systems. For instance, when there is no associated non-benchmark operating system, the benchmark operating system can add the attribute category to a specific list and update the list when a change request is received. This provides a way for non-benchmark operating systems to obtain the latest attribute data, thereby maintaining data consistency and accuracy.

[0128] The following examples use an RTOS with the baseline operating system as the security domain, Android with a non-baseline operating system as the first hardware domain, and Linux with a non-baseline operating system as the second hardware domain. (Refer to...) Figure 12 Describes how to retrieve attribute data across domains. Figure 12 The first client shown can be an Android client, the second client can be a Linux client, and the management server can be a client used to manage the property services of the RTOS.

[0129] Specifically, after the RTOS boots up, the management server can connect to the property service. Once connected, it can read various attribute categories from the attribute list in the storage module. For example, the attribute list could be a persistent storage attribute table and / or a RAM base attribute table. The management server can then send the read categories to the first client and / or the second client. Upon receiving the categories, the first and / or second clients can filter out their target attribute categories. Based on these target attribute categories, they can first check if the corresponding attribute data is contained in their local attribute tables. If not, they can generate an attribute data retrieval request based on the target attribute category and send it to the management server. The management server receives and parses the request to extract the target attribute category. In this embodiment, the first and / or second clients can also proactively construct attribute data retrieval requests while processing tasks and send them to the management server. The management server receives and parses these requests to extract the attribute categories.

[0130] Based on the attribute data retrieval requests obtained through the two methods described above, the management server, upon extracting an attribute category, can first check its local attribute table. If the local attribute table does not contain the attribute category, it queries the storage module's attribute list based on the attribute category. If the attribute list contains the attribute category, it continues to query whether the attribute list contains the corresponding attribute data. If the attribute data corresponding to the attribute category is found, the management server can return it to the first client and / or the second client. If the attribute data corresponding to the attribute category is not found, the management server can query whether the storage module contains an associated non-baseline operating system based on the attribute category. For example, if the attribute category is extracted from an attribute data retrieval request sent by the first client, and the management server finds an associated non-baseline operation based on the attribute category, such as the second client's operating system (i.e., Linux), the management server can send the attribute category to Linux. Linux receives the attribute category, queries its local attribute table based on the attribute category, returns the retrieved attribute data to the management server, and then the management server receives the attribute data and returns it to the first client. In this embodiment, if the management server does not find any related non-baseline operations for a given attribute category, it can add the attribute category to a specific list. When the management server receives an attribute data change request for that attribute category, it will parse the request to extract the changed attribute data. The management server will then add the received attribute data to the specific list and establish a mapping relationship between the attribute data and the attribute category. At this point, the management server can send a "waiting for data change" communication message to the first client that sent the attribute data retrieval request. This message informs the first client of the current attribute category status. After receiving the "waiting for data change" communication message, the first client can request attribute data from the specific list from the management server based on this message.

[0131] Based on the above embodiments, the storage module of the property service supports two methods: persistent storage of properties and RAM-based properties. Persistent storage is used for properties that are not lost upon system shutdown and restart, while RAM-based properties are only temporarily added during system runtime and disappear after system shutdown. Properties supporting persistent storage can be read-only attribute categories or attribute categories that support both read and write operations. They are loaded into the persistent storage attribute table at startup. For example, read-only attribute categories may begin with `cdm.persist.xxx`, and read-write-enabled attribute categories may begin with `cdm.rw.persist.xxx`. RAM-based properties can also be read-only attribute categories or attribute categories that support both read and write operations. They are temporarily added to the RAM-based attribute table after startup. For example, read-only attribute categories may begin with `cdm.ro.xxx`, and read-write-enabled attribute categories may begin with `cdm.rw.xxx`. In this embodiment, an int-type index can also be added to the storage module to facilitate quick lookup and shorten message length. When requesting the list at startup, an id plus a name can be sent. If this domain is interested in certain properties, the id can be sent to request the corresponding value. The index is appended and reserved. For example, the first 100 items are for persistent storage, and the items after the first 100 are for RAM base storage.

[0132] Figure 13 This is a block diagram of a cross-system interaction device according to an embodiment of this application. The cross-system interaction device 1300 is applied to a chip including at least two different processor cores. Each processor core and its corresponding hardware resources form a hardware domain. Different hardware domains are deployed with different operating systems and there is inter-core communication between the different operating systems. The device includes an acquisition module 1310 and a determination module 1320.

[0133] Specifically, the acquisition module 1310 is used to acquire the various attribute categories of the benchmark operating system and send the various attribute categories to the various non-benchmark operating systems.

[0134] The determination module 1320 is used to determine the target attribute category corresponding to each attribute category from each non-baseline operating system, and send the request generated based on the target attribute category to the baseline operating system.

[0135] The cross-system interaction device 1300 enables efficient information exchange by establishing an inter-core communication mechanism between different hardware domains. Attribute category sharing between the base operating system and non-base operating systems facilitates rapid identification and response to information requests, reducing information transmission latency. Deploying different operating systems on the same chip allows the system to flexibly adapt to various application scenarios. By automating the attribute category acquisition and request generation process, developers no longer need to write complex code for information interaction between different operating systems, reducing development workload and time, thereby lowering development costs. The functionality of different operating systems can be dynamically adjusted and expanded as needed. By simply adding new attribute categories, the system's functionality can be easily expanded to meet the needs of future technological developments. Furthermore, by achieving efficient interaction between different operating systems, users can enjoy a smoother and more consistent operating experience. For example, in-vehicle entertainment systems can better collaborate with navigation systems to provide personalized services and information, thereby improving overall user satisfaction.

[0136] In some embodiments, before sending the request generated based on the target attribute category to the base operating system, the cross-system interaction device 1300 is further configured to: query the cached attribute data for each target attribute category from the cached attribute data through each non-base operating system; if the attribute data corresponding to the target attribute category exists in the non-base operating system, obtain the attribute data corresponding to the target attribute category; or if the attribute data corresponding to the target attribute category does not exist in the non-base operating system, generate a request based on the target attribute category.

[0137] In some embodiments, the cross-system interaction device 1300 is further configured to: cyclically detect whether a setting attribute request from a non-baseline operating system has been received by the base operating system according to a preset period; analyze the setting attribute request by the base operating system to obtain the attribute category to be set and the attribute data to be set; determine whether the attribute category to be set is cached in the base operating system; if the attribute category to be set is cached in the base operating system, determine whether the attribute data to be set is the same as the attribute data cached in the base operating system; if they are different, update the attribute data cached in the base operating system based on the attribute data to be set.

[0138] In some embodiments, the cross-system interaction device 1300 is further configured to: determine whether the attribute category to be set is a read-only attribute category through a base operating system; if the attribute category to be set is a read-only attribute category, send a setting failure message to a non-base operating system.

[0139] In some embodiments, the cross-system interaction device 1300 is further configured to: if the attribute category to be set is not a read-only attribute category, determine whether the non-baseline operating system has permission to set the attribute category to be set through the baseline operating system; if the non-baseline operating system does not have permission to set the attribute category to be set, send a setting failure message to the non-baseline operating system.

[0140] In some embodiments, the cross-system interaction device 1300 is further configured to: if the base operating system does not contain the attribute category to be set, determine whether the attribute category to be set belongs to the cross-system attribute category through the base operating system; if the attribute category to be set belongs to the cross-system attribute category, write the attribute category to be set and the attribute data to be set into the base operating system.

[0141] In some embodiments, the cross-system interaction device 1300 is further configured to: cyclically query whether there is an attribute data acquisition request from a non-baseline operating system through a base operating system according to a preset period; if there is an attribute data acquisition request from a non-baseline operating system, analyze the attribute data acquisition request through the base operating system to obtain the attribute category in the attribute data acquisition request; determine whether the attribute category in the attribute data acquisition request is cached in the base operating system; if the attribute category is cached in the base operating system but the attribute data corresponding to the attribute category is not cached, determine whether the attribute category has an associated non-baseline operating system; if there is an associated non-baseline operating system, send the attribute category to the associated non-baseline operating system, return the attribute data corresponding to the attribute category to the base operating system through the associated non-baseline operating system, and return the attribute data corresponding to the attribute category to the non-baseline operating system through the base operating system.

[0142] In some embodiments, the cross-system interaction device 1300 is further configured to: if the attribute category is cached in the base operating system and there is no cached attribute data corresponding to the attribute category and no associated non-base operating system for the attribute category, return a waiting attribute data change notification message to the non-base operating system through the base operating system; and obtain the changed attribute data corresponding to the attribute category from the base operating system through the non-base operating system based on the waiting attribute data change notification message.

[0143] Based on the same concept, this application also provides a chip, on which the cross-system interaction device 1300 as described above is integrated.

[0144] This application also provides an electronic device, such as... Figure 14 As shown, it includes a processor and a memory, wherein the memory stores an executable program, and the memory executes the executable program to perform the steps of the method described above.

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

[0146] 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.

[0147] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. 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. 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).

[0148] 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, or discrete hardware component, the memory (storage module) is integrated into the processor.

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

[0150] 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.

[0151] 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.

[0152] 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.

[0153] 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.

[0154] 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.

[0155] In the embodiments provided in this application, it should be understood that the disclosed methods, devices, chips, electronic devices, and storage media can be implemented in other ways. For example, the device 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.

[0156] The units described as separate components may or may not be physically separate. 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0157] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0158] 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.

[0159] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cross-system interaction method, characterized in that, Applied to a chip comprising at least two different processor cores, wherein each processor core and its corresponding hardware resources constitute a hardware domain, different hardware domains are deployed with different operating systems and there is inter-core communication between the different operating systems, the method includes: Obtain the attribute categories of the benchmark operating system and send each attribute category to the non-benchmark operating system; Each of the non-baseline operating systems determines the corresponding target attribute category from each of the attribute categories, and sends the request generated based on the target attribute category to the base operating system; The benchmark operating system cyclically queries whether there is an attribute data acquisition request from the non-benchmark operating system according to a preset period. If there is an attribute data acquisition request from the non-baseline operating system, the attribute data acquisition request is analyzed by the baseline operating system to obtain the attribute category in the attribute data acquisition request; Determine whether the attribute category in the attribute data retrieval request is cached in the benchmark operating system; If the attribute category is cached on the baseline operating system but the attribute data corresponding to the attribute category is not cached, determine whether the attribute category has an associated non-baseline operating system; If there is an associated non-baseline operating system, the attribute category is sent to the associated non-baseline operating system, the attribute data corresponding to the attribute category is returned to the baseline operating system through the associated non-baseline operating system, and the attribute data corresponding to the attribute category is returned to the non-baseline operating system through the baseline operating system.

2. The method according to claim 1, characterized in that, Before sending the request generated based on the target attribute category to the benchmark operating system, the method further includes: Each of the aforementioned non-baseline operating systems queries the cached attribute data to determine if corresponding attribute data exists for each of the aforementioned target attribute categories. If attribute data corresponding to the target attribute category exists in the non-baseline operating system, obtain the attribute data corresponding to the target attribute category; or If the non-baseline operating system does not have attribute data corresponding to the target attribute category, the request is generated based on the target attribute category.

3. The method according to claim 1, characterized in that, The method further includes: The baseline operating system cyclically checks whether it has received a setting attribute request from the non-baseline operating system according to a preset period. The baseline operating system analyzes the attribute setting request to obtain the attribute category and attribute data to be set. Determine whether the attribute category to be set is cached in the base operating system. If the attribute category to be set is cached in the base operating system, determine whether the attribute data to be set is the same as the attribute data cached in the base operating system. If they are different, update the attribute data cached in the baseline operating system based on the attribute data to be set.

4. The method according to claim 3, characterized in that, The method further includes: The baseline operating system determines whether the attribute category to be set is a read-only attribute category. If the attribute to be set is a read-only attribute, a setting failure message is sent to the non-baseline operating system.

5. The method according to claim 4, characterized in that, The method further includes: If the attribute category to be set is not the read-only attribute category, the non-baseline operating system is determined by the base operating system to determine whether it has permission to set the attribute category to be set. If the non-baseline operating system does not have permission to set the attribute category to be set, a setting failure message is sent to the non-baseline operating system.

6. The method according to claim 3, characterized in that, The method further includes: If the benchmark operating system does not contain the attribute category to be set, the benchmark operating system determines whether the attribute category to be set belongs to a cross-system attribute category. If the attribute category to be set belongs to the cross-system attribute category, the attribute category to be set and the attribute data to be set are written to the base operating system.

7. The method according to claim 1, characterized in that, The method further includes: If the attribute category is cached on the baseline operating system and the attribute data corresponding to the attribute category is not cached on any non-baseline operating system not associated with the attribute category, the baseline operating system returns a waiting attribute data change notification message to the non-baseline operating system. The non-baseline operating system obtains the modified attribute data corresponding to the attribute category from the base operating system based on the waiting attribute data change notification information.

8. A cross-system interactive device, characterized in that, An apparatus applicable to a chip comprising at least two different processor cores, wherein each processor core and its corresponding hardware resources constitute a hardware domain, different hardware domains are deployed with different operating systems and inter-core communication exists between the different operating systems, the apparatus comprising: The acquisition module is used to acquire various attribute categories of the benchmark operating system and send each attribute category to each non-benchmark operating system; The determination module is used to determine the target attribute category corresponding to each of the attribute categories from each of the non-baseline operating systems, and send the request generated based on the target attribute category to the base operating system; The cross-system interaction device is also used to: query the baseline operating system cyclically according to a preset period to see if there is an attribute data acquisition request from the non-baseline operating system; If there is an attribute data acquisition request from the non-baseline operating system, the attribute data acquisition request is analyzed by the baseline operating system to obtain the attribute category in the attribute data acquisition request; Determine whether the attribute category in the attribute data retrieval request is cached in the benchmark operating system; If the attribute category is cached on the baseline operating system but the attribute data corresponding to the attribute category is not cached, determine whether the attribute category has an associated non-baseline operating system; If there is an associated non-baseline operating system, the attribute category is sent to the associated non-baseline operating system, the attribute data corresponding to the attribute category is returned to the baseline operating system through the associated non-baseline operating system, and the attribute data corresponding to the attribute category is returned to the non-baseline operating system through the baseline operating system.

9. A chip, characterized in that, The chip integrates the cross-system interaction device as described in claim 8.

Images