Method and device for running embedded system, embedded system and chip

Abstract

The application discloses a running method and device of an embedded system, the embedded system and a chip, and the method comprises the following steps: allocating a group of to-be-allocated services to corresponding operating systems in the embedded system according to resource dynamic allocation rules, the resource dynamic allocation rules comprise performing resource dynamic allocation according to at least one of the following: service response speed, service resource occupancy rate, service coupling degree, service importance, the embedded system comprises a first operating system and a second operating system, and the response speed of the first operating system is higher than that of the second operating system; determining resource allocation results corresponding to the group of to-be-allocated services, the resource allocation results are used for indicating processing resources of a processor corresponding to each to-be-allocated service in the group of to-be-allocated services, and the processing resources of the processor comprise processor cores; and allocating the processing resources of the processor to the first operating system and the second operating system according to the operating systems corresponding to each to-be-allocated service and the resource allocation results.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to an embedded system operation method and apparatus, an embedded system, and a chip. Background Technology

[0002] With the rapid development of the semiconductor industry and integrated circuit technology, multi-core processors have become important computing units in many fields. In application scenarios sensitive to response speed, a multi-core processor can handle tasks that are not sensitive to response speed, while the acceleration hardware can handle tasks that are sensitive to response speed. However, in this approach, because most of the processing resources (e.g., core resources) of the multi-core processor are idle, the overall utilization rate of processing resources is low. Summary of the Invention

[0003] This application provides an embedded system operation method and apparatus, an embedded system and a chip, to at least solve the problem in the related art where the overall utilization rate of processing resources is low because most of the processing resources of a multi-core processor are idle.

[0004] According to one aspect of the embodiments of this application, an embedded system operation method is provided, comprising: allocating a set of services to be allocated to corresponding operating systems in the embedded system according to a dynamic resource allocation rule, wherein the dynamic resource allocation rule includes dynamic resource allocation based on at least one of the following: service response speed, service resource occupancy rate, service coupling degree, and service importance; the embedded system includes a first operating system and a second operating system, the first operating system and the second operating system running on a processor, and the first operating system having a higher response speed than the second operating system; determining a resource allocation result corresponding to the set of services to be allocated, wherein the resource allocation result is used to indicate the processing resources of the processor corresponding to each service in the set of services to be allocated, the processor's processing resources including processor cores; and allocating the processor's processing resources to the first operating system and the second operating system according to the operating system corresponding to each service to be allocated and the resource allocation result.

[0005] According to another aspect of the embodiments of this application, an embedded system is also provided, including: a first operating system and a second operating system, the first operating system and the second operating system running on a processor, the first operating system having a higher response speed than the second operating system; a service management module, configured to allocate a group of services to be allocated to corresponding operating systems according to a resource dynamic allocation rule, wherein the resource dynamic allocation rule includes dynamic resource allocation based on at least one of the following: service response speed, service resource occupancy rate; a resource dynamic allocation module, configured to determine a resource allocation result corresponding to the group of services to be allocated, wherein the resource allocation result is used to indicate the processing resources of the processor corresponding to each service in the group of services to be allocated, the processor's processing resources including processor cores; and a resource adaptive scheduling module, configured to allocate the processor's processing resources to the first operating system and the second operating system according to the operating system corresponding to each service to be allocated and the resource allocation result.

[0006] According to another embodiment of this application, an embedded system is also provided, comprising: a chip and at least two operating systems, wherein the chip includes a processor, a hardware controller, a first bus, and a second bus, wherein the bandwidth of the first bus is higher than the bandwidth of the second bus, and the first bus is configured in a multi-master multi-slave mode, and the second bus is configured in a single-master multi-slave mode; the at least two operating systems run on the processor, wherein the processing resources of the processor are dynamically allocated to the at least two operating systems, and the processing resources of the processor include processor cores; the at least two operating systems communicate through the first bus; and the at least two operating systems control the hardware controller through the second bus.

[0007] According to another aspect of the embodiments of this application, an embedded system operating device is also provided, comprising: a first allocation unit, configured to allocate a set of services to be allocated to corresponding operating systems in the embedded system according to a dynamic resource allocation rule, wherein the dynamic resource allocation rule includes dynamic resource allocation based on at least one of the following: service response speed, service resource occupancy rate, service coupling degree, and service importance; the embedded system includes a first operating system and a second operating system, the first operating system and the second operating system running on a processor, and the response speed of the first operating system being higher than that of the second operating system; a first determination unit, configured to determine a resource allocation result corresponding to the set of services to be allocated, wherein the resource allocation result is used to indicate the processing resources of the processor corresponding to each service in the set of services to be allocated, and the processing resources of the processor including processor cores; and a second allocation unit, configured to allocate the processing resources of the processor to the first operating system and the second operating system according to the operating system corresponding to each service to be allocated and the resource allocation result.

[0008] According to another aspect of the embodiments of this application, a chip is also provided, wherein the chip includes at least one of programmable logic circuits and executable instructions, the chip operates in an electronic device for implementing the steps in any of the above method embodiments.

[0009] According to another aspect of the embodiments of this application, a BMC chip is also provided, comprising: a storage unit and a processing unit connected to the storage unit, wherein the storage unit is used to store a program, and the processing unit is used to run the program to perform the steps in any of the above method embodiments.

[0010] According to another aspect of the embodiments of this application, a motherboard is also provided, comprising: at least one processor; at least one memory for storing at least one program; wherein when the at least one program is executed by the at least one processor, the at least one processor performs the steps in any of the above method embodiments.

[0011] According to another aspect of the embodiments of this application, a server is also provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor is used to implement the steps in any of the above method embodiments when executing the program stored in the memory.

[0012] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0013] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0014] In this embodiment, different operating systems of an embedded system are run on different processing resources of the processor. A set of services to be allocated is assigned to the corresponding operating system in the embedded system according to a dynamic resource allocation rule. This dynamic resource allocation rule includes dynamic resource allocation based on at least one of the following: service response speed, service resource occupancy rate, service coupling degree, and service importance. The embedded system includes a first operating system and a second operating system, both running on the processor. The first operating system has a higher response speed than the second operating system. A resource allocation result is determined corresponding to the set of services to be allocated. This resource allocation result indicates the processing resources of the processor corresponding to each service in the set of services to be allocated. The processor's processing resources include processor cores. Based on the operating system corresponding to each service to be allocated and the resource allocation result, the processor's processing resources are allocated to the first and second operating systems. The device runs at least two operating systems for the embedded system. Different operating systems have different response speeds and can be used to run services with different response speed requirements. Based on dynamic resource allocation rules, the processor's pending tasks are allocated to different operating systems and to different processing resources. Thus, the processor's processing resources can be dynamically allocated to different operating systems based on the correspondence between pending tasks and operating systems, and between pending tasks and processing resources. Through the above service execution method, no additional acceleration hardware is needed. At the same time, since all services are executed by the processor's processing resources, additional processing of services that were originally executed by acceleration hardware on top of the services originally executed by the processor can increase the amount of services that the processor can handle, thereby improving the utilization rate of processing resources. This solves the problem of low overall utilization of core resources in related technologies due to most of the processing resources of multi-core processors being idle. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the hardware environment for an embedded system operation method according to an embodiment of this application;

[0018] Figure 2 This is a flowchart illustrating an optional embedded system operation method according to an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of an optional embedded system operation method according to an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of another optional method of operating an embedded system according to an embodiment of this application;

[0021] Figure 5 This is a schematic diagram of another optional method of operating an embedded system according to an embodiment of this application;

[0022] Figure 6 This is a schematic diagram of another optional method of operating an embedded system according to an embodiment of this application;

[0023] Figure 7 This is a schematic diagram of another optional method of operating an embedded system according to an embodiment of this application;

[0024] Figure 8 This is a flowchart illustrating another optional method for operating an embedded system according to an embodiment of this application;

[0025] Figure 9 This is a flowchart illustrating another optional method for operating an embedded system according to an embodiment of this application;

[0026] Figure 10 This is a schematic diagram of an optional embedded system according to an embodiment of this application;

[0027] Figure 11 This is a schematic diagram of another optional embedded system according to an embodiment of this application;

[0028] Figure 12 This is a structural block diagram of an optional embedded system operating device according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] The methods and embodiments provided in this application can be executed on a server, computer terminal, device terminal, or similar computing device. Taking running on a server as an example, Figure 1 This is a schematic diagram of the hardware environment for an embedded system operation method according to an embodiment of this application. For example... Figure 1 As shown, a server may include one or more ( Figure 1 Only one is shown in the image. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. In one exemplary embodiment, the server may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server described above. For example, the server may also include components that are more complex than... Figure 1 The more or fewer components shown, or having the same Figure 1 Equivalent functions or ratios shown Figure 1 The functions shown have more different configurations.

[0032] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the operating method of the embedded system in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a server via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0033] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the server's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0034] This embodiment provides a method for operating an embedded system, applied to the aforementioned server. Figure 2 This is a flowchart illustrating an optional embedded system operation method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0035] Step S202: Assign a set of services to be allocated to the corresponding operating system in the embedded system according to the dynamic resource allocation rules.

[0036] The embedded system operation method in this embodiment can be applied to scenarios where services run on the processor's processing resources and where processing resources are dynamically balanced and scheduled. The aforementioned embedded system can be an embedded multi-system, which refers to running multiple operating systems (e.g., a first operating system, a second operating system, etc.) on a multi-core processor within the embedded system. These operating systems run simultaneously within the same embedded system. The multiple operating systems can be of the same type or different types, such as heterogeneous operating systems (operating systems of different architectures). Service execution on the processor can be performed in parallel using the processing resources of multiple cores of the processor. The processor can be a multi-core processor, such as an 8-core processor, or a processor containing other numbers of cores. This embodiment does not limit the number of cores included in a multi-core processor.

[0037] In related technologies, with the rapid development of the semiconductor industry and integrated circuit technology, multi-core processors have become important computing units in fields such as cloud computing, AI (Artificial Intelligence), big data, industrial internet, and 5G (5th Generation Mobile Communication Technology). To achieve hardware computing resource sharing, virtualization technology can be introduced to improve the utilization of multi-core processors. This involves creating multiple virtual machines based on the processor hardware platform, with each virtual machine running an independent operating system.

[0038] However, virtual machine-based operating systems, due to the added overhead of virtual machine management, generally cannot meet the real-time requirements of business applications. Therefore, in application scenarios sensitive to response speed (related to business real-time performance), the operating system is typically run directly on a dedicated physical machine. This "bare metal" processor usage significantly reduces business processing latency. In various industries of embedded system development (e.g., servers, IoT), to achieve increasingly powerful system management functions, the business processes they support are also systematically divided according to different levels of response speed requirements (real-time requirements), and different hardware implementation platforms are configured for different business types. For example, complex and diverse non-real-time business processes are handled by multi-core CPUs (Central Processing Units, the core of computer system computation and control, and the final execution unit for information processing and program execution), while business processes with high response speed requirements are implemented by dedicated acceleration hardware. The acceleration hardware here may include, but is not limited to: FPGA (Field Programmable Gate Array), CPLD (Complex Programmable Logic Device), or ASIC (Application Specific Integrated Circuit) chips.

[0039] However, in embedded systems with multi-core processors and acceleration hardware solutions, all processing resources (e.g., processor cores) typically run only a single type of operating system, and most processing resources are idle most of the time, resulting in low overall resource utilization. Common embedded products (e.g., mobile phones, tablets) usually run multiple cores with a single operating system (e.g., Android, iOS, Windows), and the CPU core load is mostly below 30% (CPU capacity is often more than sufficient). The CPU operates on a time-slice basis, remaining idle when not in use. Furthermore, investing in acceleration hardware resources such as FPGAs / CPLDs to handle time-sensitive tasks is detrimental to cost control.

[0040] To at least partially solve the aforementioned technical problems, this embodiment employs a method of running different operating systems of the embedded system on different processing resources of the processor. Different operating systems have different response speeds and can be used to run services with varying response speed requirements. Based on dynamic resource allocation rules, the processor's pending tasks are allocated to different operating systems and different processing resources. This allows for dynamic allocation of processor resources to different operating systems based on the correspondence between pending tasks and operating systems, and between pending tasks and processing resources. This service execution method eliminates the need for additional acceleration hardware, facilitating cost control. Furthermore, since all services are executed by the processor's internal processing resources, the additional processing of services originally handled by acceleration hardware on top of the processor's existing processing capacity increases the workload of the processor, thereby improving the overall utilization of processing resources.

[0041] In this embodiment, the embedded system includes a first operating system and a second operating system. The first operating system has a higher response speed than the second operating system. Both operating systems run on a processor, specifically on different processing resources of the processor. These processing resources can include at least one of the following: processing resources of the first operating system (processing resources scheduled to the first operating system), processing resources of the second operating system (processing resources scheduled to the second operating system), and unallocated processing resources. Here, the processor can be a multi-core processor (e.g., an eight-core processor). The processor's processing resources (i.e., processor resources) can include processor cores (processor hard cores) and other types of resources, such as controller logic units, external interfaces, and bus resources.

[0042] During processor operation, a set of services to be assigned can be acquired, namely, services to be allocated to the first operating system and the second operating system. Since different services to be assigned may differ in terms of response speed, resource utilization, coupling with other services, and importance, dynamic resource allocation rules can be pre-configured. These rules can include rules for assigning services to their corresponding operating systems, allowing the corresponding operating system's processing resources to execute the assigned service. Optionally, the dynamic resource allocation rules can include dynamic resource allocation based on at least one of the following: service response speed, service resource utilization, service coupling, and service importance. Different allocation rules can have corresponding priorities; for example, the priorities, in descending order, are: service importance, service coupling, service response speed, and service resource utilization. Based on the source dynamic allocation rules, a set of services to be assigned (or tasks to be assigned; different services to be assigned may correspond to different processes) can be allocated to the corresponding operating systems in the embedded system, resulting in the service allocation results.

[0043] Optionally, based on the constraint of response time, the first operating system can be an operating system with explicit and fixed time constraints. All processing (task scheduling) needs to be completed within the fixed time constraints, otherwise the system will malfunction. It can be a Real-Time Operating System (RTOS), such as FreeRTOS, RTLinux, etc., or it can be a real-time operating system in other embedded systems. The second operating system does not have this characteristic. The second operating system generally adopts a fair task scheduling algorithm. When the number of threads / processes increases, CPU time needs to be shared. Task debugging is uncertain, and it can be called a non-real-time operating system. For example, Contiki, HeliOS, Linux (GNU / Linux, a freely distributable Unix-like operating system), etc., or it can be a non-real-time operating system in other embedded systems. Among them, the Linux system is a multi-user, multi-tasking operating system based on POSIX (Portable Operating System Interface) that supports multi-threading and multi-CPU.

[0044] Correspondingly, the services allocated to the first operating system are typically real-time services. Real-time services are those that need to be scheduled within a specified time. These services require the processor to process them quickly enough, and the results must be able to control the production process or provide a rapid response to the processing system within that timeframe. A typical example is the control of robotic arms in industrial control, which is a real-time service. The system needs to take timely measures before detecting any malfunctions by the robotic arm; otherwise, serious consequences may occur. The services allocated to the second operating system are typically non-real-time services. Non-real-time services are those that are not sensitive to scheduling time and have a certain tolerance for scheduling delays. For example, a server reading sensor data from a temperature sensor.

[0045] It should be noted that a real-time operating system is an operating system that can accept and process external events or data at a sufficiently fast speed when they occur, and whose processing results can control the production process or make a rapid response to the processing system within a specified time, schedule all available resources to complete real-time business, and control all real-time business to run in a coordinated manner. It has the characteristics of timely response and high reliability.

[0046] Optionally, assigning a set of pending services to the corresponding operating system can be performed by the service management module, such as... Figure 3 As shown, the service management module can be a software module running on a first operating system or a second operating system. Taking running on a second operating system as an example, the service management module can be implemented by software in a Linux system. This service management module can allocate a set of services to be assigned to the corresponding operating system in the embedded system according to dynamic resource allocation rules.

[0047] Step S204: Determine the resource allocation result corresponding to a group of services to be allocated, wherein the resource allocation result is used to indicate the processing resources of the processor corresponding to each service to be allocated in the group of services to be allocated.

[0048] After assigning each pending service to its corresponding operating system, processing resources can be allocated to each service based on the allocation results, resulting in a resource allocation outcome for a set of pending services. When allocating processing resources to pending services, services allocated to the first operating system can be allocated processing resources from the first operating system, and services allocated to the second operating system can be allocated processing resources from the second operating system. Furthermore, considering load balancing, if there are unallocated processing resources, these resources can be allocated to some services.

[0049] Processor resources can be dynamically allocated in units of time slices. Considering the frequent switching of operating systems to which processing resources belong and that business processing time is not necessarily an integer multiple of time slices, which may lead to an extension of the response time of some business, processor resources can be allocated to the first and second operating systems in units of processor cores. That is, processor cores are allocated to the corresponding operating system in units of the entire processor core, and the number of processor cores allocated to each operating system is an integer, and the number of processor cores allocated to different operating systems is different.

[0050] Optionally, determining the resource allocation result corresponding to a set of services to be allocated can be performed by the dynamic resource allocation module, such as... Figure 3 As shown, the resource dynamic allocation module can be a software module running on a first operating system or a second operating system. Taking the second operating system as an example, the resource dynamic allocation module can be implemented by a software module in the second operating system. It can dynamically allocate processing resources for business based on the output of the business management module. Here, the software module can be a program module with preset functions. For example, for the resource dynamic allocation module, it can be a program module with resource dynamic allocation function, and for the business management module, it can be a program module with business management function. Each software module can be deployed and adjusted as a whole and can be applied in different application projects.

[0051] Step S206: Based on the operating system corresponding to each service to be assigned and the resource allocation result, allocate the processor's processing resources to the first operating system and the second operating system.

[0052] Based on the operating system corresponding to each pending service and the resource allocation results, the processor's processing resources can be allocated to the first operating system and the second operating system. Optionally, the processor's unallocated processing resources can be allocated to its corresponding operating system. The unallocated processing resources can be determined based on the correspondence between unallocated processing resources and pending services, as well as the correspondence between pending services and operating systems.

[0053] Optionally, allocating processor processing resources to the first and second operating systems can be performed by a resource adaptive scheduling module (e.g., a kernel adaptive scheduling module). This resource adaptive scheduling module can be a software module running on either the first or second operating system. Taking the second operating system as an example, the resource adaptive scheduling module can be implemented by software in a Linux system. It can perform the actual scheduling of processor processing resources (e.g., processor hard core resources) based on the output of the business management module and the output of the resource dynamic allocation module. Figure 4As shown, after resource scheduling by the core resource adaptive module, M cores out of (M+N) cores are scheduled to the real-time operating system, and N cores are scheduled to the non-real-time operating system.

[0054] For example, heterogeneous operating systems (heterogeneous operating systems) can run on different hard cores of the same processor, enabling the entire processor system to perform parallel processing of both real-time and non-real-time tasks. Simultaneously, by adaptively adjusting the processor hard core resources (e.g., processor cores) occupied by different operating systems, a significant improvement in processor resource utilization can be achieved. Here, heterogeneity refers to different types of operating systems running on the same multi-core processor in an embedded system, and multiple systems refer to multiple operating systems running on the same multi-core processor in an embedded system, with these operating systems running simultaneously in time.

[0055] It's important to note that servers, in general, possess at least high scalability and stability. Since enterprise networks are not static, in today's information-driven world, a lack of scalability will hinder server usage and consequently impact the company's future development. Therefore, scalability is a fundamental requirement for servers; only with high scalability can better utilization be guaranteed in the future. Scalability encompasses both hardware and software aspects. Because servers are significantly more complex than computers, both hardware and software configurations are crucial. Achieving more functionality is unimaginable without comprehensive software support.

[0056] In addition, because servers need to process large amounts of data to support the continuous operation of business, servers have another very important characteristic, such as high stability. If the data transmission of the server cannot run stably, it will undoubtedly have a great impact on the operation of business.

[0057] This application leverages the high scalability of servers by introducing a dual software system—a first operating system and a second operating system—to generate hardware interface signals. It also incorporates hardware devices such as GPLD and BMC chips to adjust the transmission voltage of the hardware interface signals and monitor the operating status of other internal server components. Based on this, the application uses the first operating system to generate the hardware interface signals corresponding to request commands. First, the first operating system obtains the request command; then, it determines multiple logical bit information corresponding to the request command; finally, it generates the hardware interface signals corresponding to the request command based on the multiple logical bit information and a timer. As can be seen from the above, this application generates the hardware interface signals corresponding to request commands through the first operating system, thus achieving the technical effect of simulating hardware interface signal generation using software. This eliminates the need for hardware logic design that requires the chip itself to have related hardware interface signals, reducing both the design complexity and cost of the chip. This application achieves the goal of generating hardware interface signals using a software system without requiring hardware logic design of the chip itself, thereby reducing the design complexity of the chip and solving the technical problem of high chip design costs caused by the need for hardware logic design with a controller in related technologies.

[0058] In addition, the introduction of a dual software system of first and second operating systems can also ensure the stability of the server. Since the business response speed of the second operating system is slower than that of the first operating system, using the first operating system with a faster business response speed to generate hardware interface signals can ensure that the generation of hardware interface signals will not be interrupted, thereby ensuring that the hardware interface signals can be continuously and stably output.

[0059] Through the above steps, a set of pending services is allocated to the corresponding operating system in the embedded system according to the dynamic resource allocation rules. The dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed, service resource occupancy rate, service coupling degree, and service importance. The embedded system includes a first operating system and a second operating system, both running on a processor. The first operating system has a higher response speed than the second operating system. A resource allocation result corresponding to the set of pending services is determined, where the resource allocation result indicates the processing resources of the processor corresponding to each pending service in the set. The processor's processing resources include processor cores. Based on the operating system corresponding to each pending service and the resource allocation result, the processor's processing resources are allocated to the first and second operating systems. This solves the problem in related technologies where the overall utilization rate of core resources is low due to most processing resources of multi-core processors being idle, thus improving the utilization rate of processing resources.

[0060] In one exemplary embodiment, the above method further includes:

[0061] S11 generates a rule structure by reading the rule configuration file, where the rule structure is used to record the dynamic allocation rules of resources.

[0062] Dynamic resource allocation rules can be configured based on rule configuration files. By reading the rule configuration file, a rule structure can be generated to record the dynamic resource allocation rules. Here, the rule configuration file can be a load balancing strategy file (payload_balance.config). The load balancing strategy file can be used to configure the classification methods for various running services (or processes), the evaluation principles for real-time levels, etc. Different parameters can be configured in the load balancing strategy file to define the dynamic resource allocation rules. An example of a load balancing strategy configuration file is as follows:

[0063] classification kinds = 2 / / A value of 1 indicates that processes are classified according to attributes such as importance and unimportance; otherwise, processes are classified according to a preset classification method (such as real-time and non-real-time).

[0064] real-time grade evaluation = 2 / / A value of 1 indicates that the average CPU utilization rate within the past statistical minutes is used as the principle for evaluating the real-time grade of the process; otherwise, the preset priority is used as the principle for evaluating the real-time grade of the process.

[0065] statistic minutes = 5 / / This represents the statistical time (in minutes) for the average utilization rate of each process. It is valid when the real-time grade evaluation is 1.

[0066] Optionally, the dynamic resource allocation rules can be stored in the load balancing strategy module. This module can be a software module running on a first or second operating system (e.g., a software module running on a Linux system). It can provide policy guidance to the business management module, including classification methods for various services (or processes) running in the system, and evaluation principles for real-time performance levels. The business management module can classify and manage services in the system according to their real-time performance levels, further guiding the resource adaptive scheduling module to reallocate processor resources. For example, it can perform the actual classification of services based on the output of the load balancing strategy module, generating a list containing real-time and non-real-time services.

[0067] It should be noted that the above classification method and real-time grade evaluation principles are open; users can define their own methods or principles. The rules upon which the business management module performs business management can be dynamically configured, and further rules can be set based on existing rules. Multiple rules with the same function can be set in the business management module, but there should be no contradictions between them. That is, the rule currently in use can be determined based on rule selection conditions such as rule configuration time and rule priority, thus avoiding contradictions between rules. The configuration file load_balance.config describes one possible scenario. In the configuration file, the classification_kinds variable indicates the specific classification criteria (e.g., by business importance or real-time performance) and classification categories (e.g., important business and general business, real-time business and non-real-time business, etc.), while the real-time_grade_evaluation variable indicates the real-time evaluation criteria (which can be based on the average CPU utilization rate within the past statistic_minutes or a preset business priority). The real-time grade type is user-defined and can be defined as high, normal, and low, or further subdivided.

[0068] The output of the load balancing strategy module includes the configured classification method, real-time performance evaluation principles, etc. In software implementation, this can be a specific configuration file (such as load_balance.config) or a structure variable. These files or structure variables can ultimately be accessed by the business management module to obtain the specific load balancing strategy.

[0069] In this embodiment, by reading the rule configuration file and generating a rule structure to record the dynamic allocation rules of resources, the convenience of information configuration can be improved.

[0070] In one exemplary embodiment, the above method further includes:

[0071] S21, obtain the rule update configuration file through the external interface of the second operating system, wherein the rule update configuration file is used to update the configured dynamic resource allocation rules;

[0072] S22, update the rule structure using the rule update configuration file to update the resource dynamic allocation rules recorded in the rule structure.

[0073] The rule structure can be in a fixed format, meaning it cannot be modified during the operation of the embedded system, or it can be in a flexibly configurable format, meaning it can be configured and changed through a configuration file of a specific format. In this embodiment, a rule update configuration file can be obtained, which is used to update the configured dynamic resource allocation rules; using the rule update configuration file, the rule structure can be updated, thereby updating the dynamic resource allocation rules recorded in the rule structure.

[0074] When updating the rule structure using the rule update configuration file, you can either directly generate a new rule structure based on the rule update configuration file and replace the existing rule structure with the newly generated rule structure, or you can update the parameter values ​​of the corresponding rule parameters in the rule structure using the parameter values ​​of the rule parameters indicated by the rule update configuration file.

[0075] Optionally, the configuration file in a specific format can be read through the external interface of either the first or second operating system. Considering the required workload, the dynamic resource scheduling of the embedded system can be handled by the second operating system. When obtaining the rule update configuration file, it can be obtained through the external interface of the second operating system.

[0076] For example, the load balancing strategy module can be in a fixed format or can be configured through the external interface of the Linux system. For example, a specific format configuration file (load_balance.config) can be defined as mentioned above, and configuration changes can be made through file read and write methods.

[0077] It should be noted that the external interface refers to the interface of the multi-core processor. This can be a network interface, an SPI (Serial Peripheral Interface) controller interface, a UART (Universal Asynchronous Receiver / Transmitter) serial port, etc., as long as a path for obtaining data from the outside world is available. The hardware used for reading files and the specific file location can be implemented in different ways. For example, a network interface can load a configuration file from a Web (World Wide Web) interface; an SPI controller can read a configuration file from the board's SPI Flash memory; and a UART serial port can obtain a configuration file from serial data transceiver software tools on another PC (Personal Computer).

[0078] This embodiment improves the flexibility of configuring dynamic resource allocation rules by obtaining a rule update configuration file and using the obtained rule update configuration file to update the rule structure.

[0079] In an exemplary embodiment, allocating a set of services to be assigned to the corresponding operating system in the embedded system according to dynamic resource allocation rules includes:

[0080] S31, assign the services in a set of pending services whose service response speed requirement is greater than or equal to the set response speed threshold to the first operating system, and assign the services in a set of pending services whose service response speed requirement is less than the set response speed threshold to the second operating system.

[0081] When allocating pending services, the services can be assigned to the corresponding operating systems based on their response speed requirements. Service response speed can be used to assess the real-time performance level of a service. Higher response speed requirements mean greater sensitivity to the operating system's scheduling time and response speed. Services with high real-time performance requirements need to be processed by the operating system at a sufficiently fast speed, and the processing results must be able to control the production process or provide a rapid response to the processing system within a specified timeframe. Services with lower response speed requirements have a certain tolerance for scheduling delays.

[0082] For services to be allocated with a response speed requirement greater than or equal to a set response speed threshold, which are sensitive to the operating system's scheduling time and response speed, such services can be assigned to the first operating system (e.g., real-time services are assigned to a real-time operating system). For services to be allocated with a response speed requirement less than the set response speed threshold, which are not sensitive to response speed and scheduling time, such services can be assigned to the second operating system (e.g., non-real-time services are assigned to a non-real-time operating system). Here, the service response speed requirement can be indicated by a service response speed indicator parameter, and the set response speed threshold can be a millisecond-level or second-level response speed threshold, such as 100ms, 200ms, 1s, etc. In this embodiment, the set response speed threshold is not limited.

[0083] Optionally, when assigning a set of services to the corresponding operating system in the embedded system, a first service list corresponding to the first operating system and a second service list corresponding to the second operating system can be output. The first service list is used to record the services assigned to the first operating system, and the second service list is used to record the services assigned to the second operating system. That is, the service allocation result includes the first service list and the second service list. The output first service list and the second service list can be used for the dynamic scheduling process of processor processing resources.

[0084] For example, the system's services can be classified into real-time levels to obtain a list of real-time and non-real-time services. Assume there are a total of 20 services, of which real-time services are services 1 and 2, and non-real-time services are services 3 to 20.

[0085] Here, the business management module can categorize the currently pending business processes. When the BMC system runs for the first time, since all the business processes to be run are known to the system, the business management module categorizes these business processes based on the output of the load balancing module. After categorization, different business processes will be assigned to different operating systems (RTOS and Linux systems) for execution. During subsequent operation, if the number of business processes changes (e.g., some processes hang, or new processes start), the business management module will continue to perform business segmentation, real-time partitioning and management of existing business processes according to the load balancing strategy. The business management module can be a resident process in the Linux system; it is always running and manages and partitions the currently running processes.

[0086] In this embodiment, by allocating the services to be assigned to the corresponding operating system according to the service response speed requirements, the timeliness of the service response for services sensitive to scheduling time can be guaranteed.

[0087] In an exemplary embodiment, allocating a set of services to be assigned to the corresponding operating system in the embedded system according to dynamic resource allocation rules includes:

[0088] S41, assign the services with a service resource utilization rate less than the first utilization rate threshold in a group of services to the first operating system, and assign the services with a service resource utilization rate greater than or equal to the first utilization rate threshold in a group of services to the second operating system.

[0089] When allocating pending services, the services can be assigned to the corresponding operating systems based on their resource utilization rate. Resource utilization rate can be the average percentage of processing resources consumed by the service per unit of time (e.g., CPU utilization per minute). The level of resource utilization rate affects the response speed of the current service and subsequent services. Therefore, the real-time performance level of a service can be assessed based on its resource utilization rate. A higher resource utilization rate has a greater impact on the operating system's scheduling time and response speed, resulting in a lower real-time performance level. Conversely, services with low resource utilization rates have little impact on the operating system's scheduling time and response speed, resulting in a higher real-time performance level.

[0090] For pending services with a resource utilization rate less than the first utilization rate threshold, their impact on the operating system's scheduling time and response speed is minimal, and such pending services can be assigned to the first operating system. For pending services with a resource utilization rate greater than or equal to the first utilization rate threshold, their impact on the operating system's scheduling time and response speed is significant; therefore, such pending services can be assigned to the second operating system. Here, the first utilization rate threshold can be configured as needed, and it can be 10%, 15%, 20%, or other thresholds. Furthermore, this first utilization rate threshold can be dynamically adjusted.

[0091] In this embodiment, by allocating the services to be allocated to the corresponding operating system according to the service resource utilization rate, the timeliness of response to services with low service resource utilization rate can be guaranteed.

[0092] In an exemplary embodiment, a set of services to be allocated is assigned to the corresponding operating system in the embedded system according to dynamic resource allocation rules, including at least one of the following:

[0093] S51, assign the services to be allocated from a group of services to be allocated that have a service coupling degree with the allocated services of the first operating system that is greater than or equal to the first coupling degree threshold to the first operating system;

[0094] S52, assign the services to be allocated from a group of services to be allocated that have a service coupling degree with the allocated services of the second operating system that is greater than or equal to the second coupling degree threshold to the second operating system.

[0095] When allocating services to be assigned, the services can be assigned to the corresponding operating systems based on their service coupling degree. Service coupling degree represents the degree of association between the service to be assigned and the already assigned services in each operating system. If a service to be assigned has a high service coupling degree with the already assigned services in a particular operating system, it is not suitable to assign it to another operating system. Therefore, services to be assigned can be assigned to the corresponding operating systems based on their service coupling degree with the already assigned services in each operating system.

[0096] Optionally, business coupling can be evaluated by the correlation between the inputs and outputs of a business. Business coupling can be represented by different coupling levels. If there is no relationship between the inputs and outputs of a business, the coupling level is low (or another coupling level indicating no correlation between businesses). If the execution of a business depends on the output of another application (the business cannot start without this output as input), the coupling level between businesses is high. If the execution of a business uses the output of another application, but this output does not hinder the normal execution of the business (the output can be obtained when the business executes the corresponding operation, and the corresponding operation is not a core operation), the coupling level between businesses is medium. Alternatively, business coupling can also be represented numerically. Business coupling can be evaluated by one or more coupling conditions (e.g., the correlation between inputs and outputs), and the numerical value corresponding to the satisfied coupling conditions is determined as the numerical value of the business coupling.

[0097] If a group of pending services contains a pending service whose service coupling degree with the already allocated services of the first operating system is greater than or equal to the first coupling degree threshold, then such pending services can be allocated to the first operating system. If a group of pending services contains a pending service whose service coupling degree with the already allocated services of the second operating system is greater than or equal to the first coupling degree threshold, then such pending services can be allocated to the second operating system.

[0098] For example, in addition to generating lists of real-time and non-real-time services, the service management module is also responsible for service decoupling assessment and management. That is, it identifies services from all real-time services that can be independently run by the real-time operating system so that the hardware resource dynamic allocation module can reallocate processor resources. For services that cannot be independently run by the real-time operating system, if their coupling with non-real-time services is high, they can be assigned to the non-real-time operating system.

[0099] Here, some services, while requiring real-time performance, interact frequently with other non-real-time services within the system (i.e., high business coupling). In such cases, to improve overall data interaction efficiency, these services are assigned to the non-real-time operating system. Conversely, there is another type of real-time service that is relatively independent. In this case, it is sufficient to assign it to the real-time operating system; this process is known as "decoupling." The criteria for determining whether a service is independent are not singular; they can be the degree of correlation between the aforementioned services, or other metrics of concern to users.

[0100] The reallocation strategy is open. One possible strategy is: when the system runs for the first time, processor cores are allocated according to the ratio of the number of services allocated by the business management module to the real-time operating system and the non-real-time operating system. During subsequent operation, the resource allocation is adjusted according to the core resource utilization rate of each system. From this perspective, the reallocation process and the core preemption and release process are mutually coordinated.

[0101] In an optional implementation, the services running on the first operating system may include, but are not limited to, the generation of hardware interface signals. This implementation provides a hardware interface signal generation process, which includes the following steps:

[0102] Step 1: Obtain the request command through the first operating system. Here, the request command can be a command to generate a hardware interface signal. For example, if the hardware interface signal is a PECI signal, then the request command is a PECI request command based on the PECI protocol. The hardware interface signal can also be a hardware interface signal of other protocol types, such as HDMI (High Definition Multimedia Interface) signals, RGMII (Reduced Gigabit Media Independent Interface) signals, SGMII (Serial Gigabit Media Independent Interface) signals, GPIO (General Purpose Input / Output) signals, SPI (Serial Peripheral Interface) signals, etc. Based on this, the request command can also be a request command of other protocol types. For example, when the hardware interface signal is a GPIO signal, the request command is a GPIO request command. This application does not specifically limit the specific types of the request command and the hardware interface signal.

[0103] Step 2: Determine the multiple logical bit information corresponding to the request command.

[0104] In step 2, after receiving the request command, the first operating system can analyze and obtain multiple logical bit information corresponding to the request command. Among them, there is a sequential order among the multiple logical bit information. The first operating system can generate the waveform signal (i.e., hardware interface signal) corresponding to the request command through the multiple logical bit information, and then transmit the information contained in the request command to other devices through the hardware interface signal.

[0105] Optionally, the request command includes at least one field, each of which can be represented by a logic bit 0 or 1. The conversion relationship between each field and a logic bit 1 or 0 constitutes the logic bit information corresponding to that field. When the request command corresponds to multiple fields, it corresponds to multiple logic bit information. Furthermore, each logic bit can be represented by a combination of high-level and low-level signals. For example, logic bit 0 can be represented by a combination of a high-level signal of a first preset duration and a low-level signal of a second preset duration; logic bit 1 can be represented by a high-level signal of a second preset duration and a low-level signal of a first preset duration, where the first and second preset durations are different. Since each logic bit contains both high-level and low-level signals, each logic bit is actually represented by a waveform signal (the transformation between high and low level signals is presented as a waveform). Because the request command corresponds to multiple logic bit information, i.e., multiple logic bits, the hardware interface signal corresponding to the request command is a waveform signal obtained by combining the waveform signals corresponding to each logic bit information.

[0106] Step 3: Generate the hardware interface signal corresponding to the request command based on multiple logic bit information and timer.

[0107] Optionally, the timer in step 3 can be a timing program in the first operating system, or it can be a register on the chip where the first operating system resides. The timer must provide at least timing and counting functions. This application uses the timing and counting functions of a timer, combined with multiple logic bit information, to generate the hardware interface signal corresponding to the request command.

[0108] It is worth noting that, taking the BMC chip as an example and the PECI signal as the hardware interface signal, in related technologies, in order to achieve PECI communication between the BMC chip and components such as the CPU, the BMC chip itself needs to have a PECI controller hardware logic design, which leads to a high design cost for the BMC chip. In other words, in related technologies, in order to generate PECI signals on the BMC chip, the hardware logic design of the PECI controller must be implemented on the BMC chip in advance. However, in this application, only the first operating system is needed to generate PECI signals on the BMC chip, without the need to implement the PECI controller hardware logic design on the BMC chip, thereby reducing the design difficulty and cost of the BMC chip.

[0109] Based on the above steps, in this embodiment, the hardware interface signal corresponding to the request command is generated by the first operating system. First, the request command is obtained through the first operating system. Then, multiple logical bit information corresponding to the request command is determined. Finally, the hardware interface signal corresponding to the request command is generated based on the multiple logical bit information and the timer.

[0110] As can be seen from the above, in this embodiment, the hardware interface signal corresponding to the request command is generated by the first operating system, thereby achieving the technical effect of simulating the generation of hardware interface signals using software. This achieves the goal of generating hardware interface signals using a software system without requiring hardware logic design of the chip's hardware interface signals, which not only reduces the design difficulty of the chip but also reduces the design cost of the chip.

[0111] Optionally, if a first request triggered by the second operating system is detected by the first operating system, request data is obtained. The first and second operating systems run on the same processor, the request data is generated by the second operating system, and the service response speed of the second operating system is slower than that of the first operating system. Finally, the first operating system parses the request data to obtain the request command.

[0112] Optionally, before obtaining the requested data, the second operating system can store the requested data in the target memory (i.e., the storage space on the processor), and after the requested data is stored, the second operating system can trigger a first request, wherein the first request is used to notify the first operating system to read the requested data from the target memory, and the target memory is memory that can be accessed by both the first and second operating systems.

[0113] In one optional embodiment, the first operating system may further receive response data corresponding to the hardware interface signal, wherein the transmission format of the response data is the same as that of the hardware interface signal. Furthermore, the first operating system adjusts the data structure of the response data to a second data structure.

[0114] In addition, after adjusting the data structure of the response data to the second data structure, the first operating system triggers a second request, which is used to notify the second operating system to read the response data.

[0115] Taking an RTOS system as the first operating system, a Linux system as the second operating system, and a PECI signal as the hardware interface signal as an example, the command request process begins with upper-layer applications in the Linux system that handle PECI services (such as fault diagnosis, CPU temperature acquisition, etc.) actively initiating PECI request commands as needed. These request commands include, but are not limited to, basic Ping() commands, commands to obtain CPU temperature, and commands to read MSR register information. The code implementation of different PECI request commands is completed by the corresponding interface functions.

[0116] Optionally, the Linux system writes the target address, read / write length, command code, para parameters, and other request data for each request command into the target memory according to the PECI protocol specification. After all the request data has been written to the target memory, the Linux system generates a first request to notify the RTOS system. This first request can be an SGI interrupt request (software-generated interrupt, a communication interrupt request between processor cores).

[0117] It should be noted that during the process of storing the request data into the target memory through the second operating system, the second operating system stores the request data into the target memory in the form of a first data structure. The first data structure includes at least a device address, write length, read length, command code, and request parameters. The device address is used to identify the address of the target device, which is a device that generates response data based on hardware interface signals. The command code is used to distinguish different request commands. The write length is used to identify the number of bytes from the start of the command code to the end of the request data. The read length is used to identify the number of bytes in the request data, including the completion code and the read data. The request parameters are used to identify the parameters of the request command.

[0118] In the command response process, the RTOS system receives the response data from the PECI bus and then parses it to convert the signal format of the response data from hardware interface signals to software signals. For example, it identifies waveform changes between high and low level signals in the hardware interface to obtain the corresponding logic bit information, and then uses this logic bit information to derive the software signal data. The parsed response data is adjusted by the command parameter structuring module and written to the target memory. After all the parsed response data has been written, the RTOS system triggers a second request to notify the Linux system. The Linux system detects the second request, actively reads the parsed response data stored in the target memory, processes the data, and returns it to the upper-layer application. This second request can be an SGI interrupt request.

[0119] The target memory can be shared memory or other types of memory, such as Random Access Memory (RAM), Flash memory, etc.

[0120] In one alternative embodiment, after generating the hardware interface signal corresponding to the request command based on the logic bit information and the timer, the first operating system can convert the voltage of the hardware interface signal to obtain the target hardware interface signal.

[0121] Optionally, the first operating system can input the hardware interface signal to a voltage conversion device to obtain the target hardware interface signal output by the voltage conversion device. The aforementioned voltage conversion device can be a CPLD, and the CPLD can be connected to the target device, which can be the CPU in a server. It should be noted that the above functionality can be applied not only to generating PECI signals by replacing the PECI interface, but also to other hardware interfaces.

[0122] As described above, by combining the first and second operating systems of the embedded system, data interaction within the embedded system is achieved through inter-core interrupts and shared memory. A waveform generation module for request commands is built into the RTOS system, and communication between the embedded system and external devices via hardware interface signals is achieved through software simulation. Furthermore, by fully utilizing the high real-time performance of the RTOS system, the timing accuracy during the simulation of request command waveforms is ensured, resulting in flexibility and efficiency. This significantly reduces chip design complexity. Because hardware interface signals are generated through software simulation, more possibilities are provided for optimizing the design of communication functions and other business functions within the embedded system. Simultaneously, by eliminating the need for a dedicated controller in the chip for hardware interface signal communication, chip design and manufacturing costs are reduced.

[0123] In an optional implementation, the services running on the first operating system may include, but are not limited to, serial port switching services. This implementation provides a serial port switching process, which includes the following steps:

[0124] Step 1: Upon detecting that the second operating system has received a serial port switching command, the second operating system sends the serial port switching command to the first operating system.

[0125] Optionally, when a user initiates a serial port switch, the second operating system can detect whether it has received the user-initiated serial port switch command. It should be noted that the serial port switch command must include information about the target serial port to which the user is switching; for example, the command may include the serial port number of the target serial port.

[0126] In an optional instance, the format of the serial port switching command can be:<switch_command_app–nnumber–t sleep_time> `switch_command_app` represents the switching instruction program, `-n` represents the target serial port number to switch to, and the value of `number` can be 1, 2, or 3. `-t` represents how long to sleep after the instruction is initiated before executing the switching action, and `sleep_time` is in seconds.

[0127] It should be noted that when implementing serial port switching, the serial ports that can be switched can be numbered so that the target serial port can be switched by serial port number in subsequent serial port switching.

[0128] In an optional embodiment, the serial ports that can be switched currently include: the BMC Linux system serial port, the server BIOS (Basic Input Output System) serial port, and the SMART NIC (network interface controller) serial port. Correspondingly, 1 can represent the BMC Linux system serial port, 2 can represent the server BIOS serial port, and 3 can represent the SMART NIC serial port.

[0129] Step 2: The first operating system performs serial port switching according to the serial port switching command.

[0130] Optionally, upon detecting that the second operating system has received a serial port switching command, the second operating system will immediately send the serial port switching command to the first operating system. It should be noted that the first and second operating systems can be run on two separate processor cores, and inter-core communication can be used between them, which can help improve the reliability of signal transmission.

[0131] It should be noted that the first operating system responds to instructions much faster than the second operating system. This allows the first operating system to quickly respond to serial port switching commands and complete the switching process in a very short time.

[0132] In summary, by using a first operating system and a second operating system running on the same processor to replace the CPLD or FPGA for implementing the serial port switching software function, when the second operating system receives a serial port switching command, it forwards the command to the first operating system. The first operating system then switches the serial port according to the command. This avoids the need to connect the various serial ports using a CPLD or FPGA and then use the switching structure in the CPLD or FPGA to implement serial port switching, thus reducing hardware costs. Furthermore, the first operating system can quickly complete the serial port switching after receiving the command. Therefore, the technical method proposed in this solution can effectively reduce the cost of serial port switching and improve its efficiency.

[0133] In order for the second operating system to realize serial port switching, in the serial port switching process provided in this embodiment, the serial port switching instruction includes at least: the serial port number of the target serial port. Before the first operating system executes the serial port switching according to the serial port switching instruction, the following steps are included: the first operating system obtains the parsing rules of the serial port switching instruction from the target memory; the serial port number of the target serial port in the serial port switching instruction is parsed according to the parsing rules to determine the device corresponding to the serial port number, wherein the target serial port is the serial port of the device and the target serial port is connected to the chip.

[0134] The serial port switching process performed by the first operating system based on the serial port switching instructions includes: determining the serial port address of the device through the first operating system; and mapping the target serial port to the target output interface of the chip based on the serial port address.

[0135] In order for the first operating system to achieve serial port switching, the first operating system can parse the serial port switching command and then obtain the device corresponding to the target serial port.

[0136] In an optional embodiment, the parsing rules for serial port switching commands can be customized based on the specific chip or server motherboard, and these rules are stored in a target memory, which can be a storage medium such as an electrically erasable programmable read-only memory (EEROM) or non-volatile memory (flash memory). It should be noted that the target memory may or may not be deployed within the chip. Storing the parsing rules in the target memory improves data security, and the ability to customize the parsing rules according to different chips or server motherboards provides good programmability and scalability.

[0137] After the first operating system receives the serial port switching command, it reads the parsing rules of the serial port switching command from the target memory, and then uses the parsing rules to parse the serial port number of the target serial port in the serial port switching command to obtain the device corresponding to this serial port number.

[0138] After obtaining the device corresponding to the serial port number, the first operating system can map the target serial port to the target output interface of the chip using the device's serial port address. Once the device's serial port address is mapped to the target output interface, access to the device can be achieved through the target output interface. It should be noted that the serial port switching commands and parsing rules can be configured according to the model of the chip used and the types of the first and second operating systems.

[0139] In the serial port switching method provided in Embodiment 1 of this application, the chip includes a serial data bus. Before determining the serial port address of the device through the first operating system, the method further includes: determining multiple devices connected to the serial port of the serial data bus; and mapping the serial port of each device to the memory of the chip through the serial data bus to obtain the serial port address of each device.

[0140] Optionally, the chip also includes a serial data bus. The TX and RX ports of multiple devices are connected to this serial data bus. For example, the serial ports include the BMC Linux system serial port (UART1), the server BIOS serial port (UART2), and the SMART NIC serial port (UART3). UART stands for Universal Asynchronous Receiver / Transmitter. The serial data bus maps the TX and RX data of different serial ports (UART1, UART2, and UART3) to different address spaces in the BMC memory. In other words, the serial data bus maps the serial port of each device to the chip's memory. For example, the UART1 TX and RX buffers represent the serial port address of UART1, the UART2 TX and RX buffers represent the serial port address of UART2, and the UART3 TX and RX buffers represent the serial port address of UART3.

[0141] When a user issues a serial port switching command, the Real-Time Operating System (RTOS) selects one of three different memory segments mapped by the UART and exchanges data from one of these memory segments with the client, thus simulating the serial port switching circuit of a CPLD hardware. It should be noted that if the serial ports of different devices cannot be distinguished, developers cannot accurately pinpoint which device's serial port is faulty during maintenance. Therefore, serial port switching is necessary to locate the problem.

[0142] In this embodiment, after mapping the target serial port to the target output interface of the chip according to the serial port address, if the target output interface is connected to the target smart network card, the process includes: detecting whether an access request to the target serial port is received through the smart network card; if an access request to the target serial port is received, the access request is forwarded to the target serial port through the smart network card.

[0143] Optionally, the target output interface of the chip can also be connected to a target smart network card. The smart network card then detects whether a user's access request for the target serial port has been received. If such a request is received, serial port access to the device can be directly achieved through the target smart network card, implementing SOL (Serial over LAN, a specification of data packet format and protocol). These steps improve the efficiency of serial port access to the device.

[0144] In an optional embodiment, after mapping the target serial port to the target output interface of the chip based on the serial port address, the method further includes the following steps: obtaining the execution result of the serial port switching instruction through a first operating system, wherein the execution result is one of the following: switching successful or switching failed; and sending the execution result to a second operating system through the first operating system.

[0145] The second operating system receives the execution result of the serial port switching command. The execution result, sent from the first operating system to the second operating system, is one of the following: serial port switching successful or serial port switching failed. After switching the serial port, the first operating system obtains the execution result of the serial port switching command and then feeds it back to the second operating system, informing it of whether the serial port switching was successful or failed.

[0146] To improve the success rate of serial port switching, this embodiment, after receiving the execution result of the serial port switching command through the second operating system, further includes: if the execution result is a failure, repeating the step of sending the serial port switching command from the second operating system to the first operating system until the execution result is successful, or the number of serial port switching operations exceeds a preset number. If the number of serial port switching operations exceeds the preset number, a prompt signal is triggered through the second operating system, wherein the prompt signal is used to indicate that the serial port switching has failed.

[0147] If the serial port switching command fails to execute, the process of sending the serial port switching command from the second operating system to the first operating system needs to be repeated until the execution result is successful, or until the number of serial port switching attempts exceeds a preset number (which can be set to 3). If the number of serial port switching attempts exceeds the preset number, the corresponding second operating system will trigger a prompt signal to indicate that the serial port switching has failed, so that this situation can be handled promptly.

[0148] Before the first operating system detects that it has received a serial port switching command, the process further includes: after the second operating system starts up, the second processor core triggers a first interrupt and sends a first signal to the first operating system; the first operating system detects the operating status of multiple serial ports in the chip based on the first signal and obtains the detection result; the first processor core triggers a second interrupt and sends the detection result to the second operating system via a second signal; the second operating system receives the detection result to determine the number of normally operating serial ports in the chip.

[0149] After the second processor core triggers the first interrupt and sends the first signal to the first operating system, it checks whether the first operating system has received the first signal. If the first operating system receives the first signal, it checks the operating status of multiple serial ports in the chip to obtain the detection result.

[0150] After the second operating system has finished booting, the second processor core triggers the first interrupt (IPI interrupt, IPI, inter-processor interrupt) to send the first signal to the first operating system. The first operating system can know that the second operating system has started normally through the first signal and can interact normally with the second operating system. In addition, the first operating system will detect the running status of multiple serial ports in the chip based on the first signal to determine whether all serial ports are running normally.

[0151] After the first operating system receives the detection results, the first processor core triggers a second interrupt to send the detection results to the second operating system via a second signal. The second operating system uses the detection results to determine the number of switchable serial ports (i.e., the number of normally functioning serial ports mentioned above) so that it can subsequently switch between these serial ports. Meanwhile, to enable the first operating system to perform serial port switching more quickly, after the first operating system completes its detection, it begins to block and wait to receive serial port switching commands from the second operating system.

[0152] In an optional embodiment, the first operating system is an RTOS. When the second operating system is Linux, the first operating system runs on CPU0 and the second operating system runs on CPU1. The preparation steps before serial port switching include: when the Linux system on CPU1 starts up to a specific stage, CPU1 will trigger an IPI interrupt to notify the RTOS system on CPU0 that Linux has started normally and can interact normally with Linux on CPU1. After receiving the IPI interrupt from CPU1, the RTOS system will start the serial port switching controller program to check whether UART1, UART2, and UART3 are normal. Then, CPU0 will trigger another IPI interrupt to notify the Linux operating system on CPU1 that the RTOS system has started up completely. At the same time, the reported information includes the number of serial ports that the RTOS operating system on CPU0 has that can be switched. Then, the RTOS operating system on CPU0 will start blocking and waiting to receive the switching instruction issued by the operating system on CPU1.

[0153] If the second operating system malfunctions, a serial port switching command is sent to the first operating system via the service terminal; the first operating system then performs the serial port switching according to the command.

[0154] Because the second operating system performs more functions and handles a larger workload, it may experience operational errors or require a restart. When the second operating system malfunctions, a serial port switching command can be directly sent to the first operating system via a service terminal to ensure the first operating system can perform the serial port switching normally. It should be noted that the service terminal can be a terminal on the server where the chip resides.

[0155] The above steps ensure that the first operating system does not depend on the second operating system to switch serial ports, thus improving the independence of the first operating system in performing serial port switching.

[0156] In summary, in the serial port switching process provided in this embodiment, a first operating system and a second operating system running on the same processor are used to replace the CPLD or FPGA to implement the serial port switching software function. When the second operating system receives a serial port switching command, it forwards the command to the first operating system. The first operating system then switches the serial port according to the command, avoiding the use of hardware to implement serial port switching, thus reducing hardware costs. Furthermore, the first operating system can quickly complete the serial port switching in a very short time after receiving the command. Therefore, the above process can effectively reduce the cost of serial port switching and improve its efficiency.

[0157] In this embodiment, by assigning the services to be allocated to the corresponding operating system according to the degree of service coupling, the accuracy of service processing for multiple services with high degree of service coupling can be guaranteed.

[0158] In an exemplary embodiment, allocating a set of services to be assigned to the corresponding operating system in the embedded system according to dynamic resource allocation rules includes:

[0159] S61, assign a set of pending services containing sensitive information to the target operating system, wherein the target operating system is the operating system with low interaction frequency with the user object between the first operating system and the second operating system.

[0160] In this embodiment, for the service to be assigned that contains sensitive data (e.g., passwords and other sensitive information) (which may be an important and sensitive service, such as a service that is not intended to be exposed to users), it can be assigned to the target operating system. The target operating system provides hard-core level security protection and isolation for the service to be assigned that contains sensitive information. Here, the target operating system is the operating system with a low frequency of interaction with the user, or the operating system with a fast response speed, such as the first operating system, which is the first operating system.

[0161] For example, this business processing module is responsible for further hard-core level security protection and isolation of system business. That is, it divides important and sensitive business (that should not be exposed to users) into real-time business, ultimately enabling these business to be offloaded from the non-real-time operating system to the real-time operating system, achieving a security protection effect. Here, the different business segments divided by this business processing module can be organized in the form of structures during software implementation. By designing a security space between heterogeneous operating systems, sensitive business is offloaded from the non-real-time operating system to the real-time operating system, achieving the goal of hard-core level security protection. Here, sensitive business refers to security-related business, such as business involving user passwords, identity information, and other personal privacy-related matters.

[0162] Here, "hardcore level" refers to the isolation of services at the processor core level. Sensitive services are allocated to the real-time operating system (RTOS) (the cores occupied by the ROS differ from those of the non-real-time operating system, thus representing core-level isolation). Compared to the non-real-time operating system, the ROS interacts with users less frequently and to a lesser extent, making it difficult for users to "detect" sensitive data generated by the services running on it. For upper-layer applications, user authentication management, security encryption, and other services fall under these important and sensitive categories. By forcibly classifying these services as real-time services through the service management module, subsequent dynamic allocation of hardware resources allows these services to run on the ROS, achieving a secure isolation effect.

[0163] This embodiment demonstrates how, by assigning services containing sensitive information to operating systems with low user interaction frequency, hard-core level security protection and isolation can be implemented for system services, thereby improving the security of service execution.

[0164] In an exemplary embodiment, determining the resource allocation result corresponding to a set of services to be allocated includes:

[0165] S71, based on the allocation results of a set of services to be allocated, and combined with the resource utilization of the processing resources of the first operating system and the processing resources of the second operating system, generate a resource mapping table between the services to be allocated and the processing resources of the processor.

[0166] In this embodiment, the allocation results of a set of pending services are used to indicate the correspondence between the pending services and the operating system. Services allocated to an operating system are typically executed using that operating system's processing resources. However, if the workload allocated to a particular operating system is too large and there are currently unallocated processing resources, unallocated processing resources can be allocated to the pending services allocated to that operating system. Therefore, based on the allocation results of a set of pending services, combined with the resource utilization of the first and second operating systems, a resource mapping table between pending services and processor processing resources can be generated to indicate the processing resources allocated to each pending service.

[0167] Here, each pending service is mapped to only one processor core, while the same processor core can be mapped to multiple pending services. Different services can be mapped to the same processor core by occupying different time slices on that core. At any given time, only one service occupies the same processor core; that is, it is used to execute only one service. Different services allocated to an operating system can determine their time slices for occupying the same processor resource based on allocation time, service response speed requirements, or other methods.

[0168] For example, the dynamic resource allocation module dynamically adjusts processor resources based on the output of the business management module, forming a resource mapping table between different services and actual hardware resources. This optimizes the deployment structure of different hardware resources under heterogeneous operating systems, thereby improving the overall system hardware resource utilization. The aforementioned dynamic resource allocation process is managed and configured by software in the second operating system.

[0169] Taking an eight-core processor (core 1 to core 8) as an example, the processor cores already scheduled to the first operating system include core 1, and the processor cores already scheduled to the second operating system include core 2, core 3, and core 4. There are 6 services to be allocated: real-time services are service 1 and service 2, and non-real-time services are service 3 to service 6. The corresponding processor cores are allocated to the 6 services: core 1 is allocated to service 1, core 5 is allocated to service 2, core 2 is allocated to service 3, core 3 is allocated to service 4, core 4 is allocated to service 5, and core 6 is allocated to service 6.

[0170] This embodiment demonstrates how dynamic allocation of processing resources can be achieved by dynamically allocating processing resources based on the correspondence between business operations and operating systems, combined with the resource usage of different operating systems. This ensures the rationality of processing resource allocation.

[0171] In an exemplary embodiment, the processor's processing resources are allocated to a first operating system and a second operating system based on the operating system corresponding to each service to be assigned and the resource allocation result, including:

[0172] S81, if it is determined from the resource allocation results that there are corresponding pending services among the unallocated processing resources of the processor, the unallocated processing resources are allocated to the operating system to which the pending service corresponding to the unallocated processing resources is allocated.

[0173] When allocating processing resources, if there are corresponding pending tasks among the unallocated processing resources of the processor, that is, if unallocated processing resources have been allocated to pending tasks, the unallocated processing resources can be allocated to the operating system to which the pending task corresponding to the unallocated processing resources was allocated.

[0174] Optionally, the resource adaptive scheduling module can perform actual scheduling actions on the processor's processing resources based on the results of dynamic hardware resource allocation. The resource adaptive scheduling module schedules a portion of the processor cores to execute services allocated to the first operating system, such as... Figure 4 The M cores of core group 1 shown in the diagram schedule the remaining processor cores to run services allocated to the second operating system, such as... Figure 4 The N cores of core group 2 shown in the figure.

[0175] Taking the aforementioned eight-core processor as an example, based on the service allocation and resource allocation results, the unallocated core 4 can be allocated to the first operating system, and the unallocated cores 5 and 6 can be allocated to the Linux system. The entire scheduling process can be dominated by the second operating system.

[0176] In this embodiment, unallocated processor resources are scheduled to the corresponding operating system based on the resource allocation results, which can improve the utilization rate of processor resources.

[0177] In one exemplary embodiment, the above method further includes:

[0178] S91 handles the preemption and release of processing resources between the first and second operating systems.

[0179] In this embodiment, in addition to dynamically allocating processor resources based on the services to be allocated, during the operation of each operating system, the preemption and release of processing resources can be performed between the first and second operating systems based on the usage status (load) of the processing resources of the operating systems. Here, the dynamic allocation of processing resources can be based on resource scheduling methods executed by control logic modules other than the first and second operating systems, while the preemption and release of processing resources are resource scheduling methods actively initiated by the first and second operating systems.

[0180] Optionally, the preemption and release of processing resources can be performed by a core preemption and release module, which can be a software module running on a first operating system and / or a second operating system. Taking running on both the first and second operating systems as an example, the core preemption and release module mainly performs dynamic preemption and release of processor cores by heterogeneous operating systems during real-time system operation to maximize processor resource utilization. Successful resource preemption by one operating system means successful resource release by the other operating system; conversely, failure to preempt resources by one operating system means failure to release resources by the other operating system. Figure 5 As shown, after core preemption and release, P cores out of (M+N) cores are scheduled to the real-time operating system, and (M+NP) cores are scheduled to the non-real-time operating system.

[0181] Here, the core preemption and release module can be used to enable the heterogeneous operating system to dynamically preempt and release processing resources such as processor cores during real-time operation, so as to maximize the utilization of processor resources.

[0182] This embodiment demonstrates how, by preempting and releasing processing resources between different operating systems, processing resources can be dynamically adjusted based on the operating system's load during operation, thereby improving the rationality of resource utilization and increasing the efficiency of business processing.

[0183] In one exemplary embodiment, preemption and release of processing resources between a first operating system and a second operating system includes:

[0184] S101 performs resource preemption and release between the first and second operating systems through the inter-core communication interface.

[0185] In related technologies, solutions where dedicated acceleration hardware executes tasks requiring high response speeds suffer from low communication bus speeds between the processor and the acceleration hardware (e.g., CPU and FPGA / CPLD), resulting in overall poor performance. In this embodiment, resource preemption and release are achieved between the first and second operating systems via an inter-core communication interface. Specifically, one operating system can send a request to another operating system to preempt or release processing resources. Compared to interaction via a communication bus, interaction through the processor's internal inter-core communication interface offers a higher communication speed, improving overall communication performance.

[0186] For example, the inter-core communication interface module can be used to facilitate communication and interaction between the first and second operating systems. During core preemption and release, the preempting and releasing parties can inform each other of their respective states (such as busy / idle status) through the inter-core communication interface. Specific signal events are also needed to characterize the behavior of the heterogeneous operating systems (such as preemption behavior). Therefore, using this inter-core communication interface module for core preemption and release can maintain the balance of hard core resources in heterogeneous operating systems, ensuring a high processor utilization rate.

[0187] Optionally, the preemption and release of processing resources between different operating systems can be accomplished through inter-core interrupts, such as SGI (Software Generated Interrupt, inter-core interrupt in Linux). One operating system can send a resource preemption request (e.g., kernel preemption request) or a resource release request (e.g., kernel release request) to another operating system via IPI (Inter-Processor Interrupt) to request the preemption or release of processing resources. Taking Linux as an example, inter-core communication can be achieved based on a custom interrupt vector table and interrupt events between heterogeneous operating systems. Here, IPI is an interrupt triggered between multiple cores within a SOC (System on Chip), which is different from common peripheral interrupts. Therefore, the core can reserve some interrupt numbers specifically for IPI; on the ARM 64 architecture (a CPU architecture), these are the 16 interrupt numbers 0-15.

[0188] Optionally, the preemption and release process depends on the real-time load of the heterogeneous operating systems. For example, when the load of the second operating system increases rapidly and more processor cores are needed, it can send a core preemption request to the first operating system through IPI to preempt the processor cores of the first operating system. If the first operating system is idle at this time (e.g., no task scheduling) or at least some of its core resources are idle, it will release the core resources to the second operating system. At this time, the second operating system successfully preempts the cores, which also means that the first operating system successfully releases the cores.

[0189] It should be noted that the core preemption and release process is a dynamic and iterative process. Each core preemption and release is accompanied by adjustments to the processor's hard core resources, such as... Figure 5 As shown, after one round of preemption and release, the number of cores in core group 1 becomes P, and the number of cores in the core group becomes M+NP. Furthermore, the core preemption and release process can be coordinated with load balancing strategies, business management, and resource adaptive scheduling (e.g., core adaptive scheduling) to jointly determine the final core adjustment result.

[0190] Here, the joint determination of core adjustment results by different modules means that when a system needs to preempt more core resources, the success or failure of the preemption depends on the joint decision of modules such as load balancing strategy, business management, and core adaptive adjustment. For example, in one possible scenario, when the second operating system needs more resources, although the first operating system is currently idle (dormant), it cannot release core resources to the second operating system because it will soon need to wake up and run an important business thread that also requires a lot of resources. The criteria for judging the importance of the business and the final decision not to allocate resources to the second operating system all involve the participation of modules such as load balancing strategy, business management, and core adaptive adjustment. The strategies of these modules are also open-ended, which means that the final core adjustment result they jointly determine is the result of the combined effect of these strategies.

[0191] This embodiment utilizes the inter-core communication interface to preempt and release processing resources between different operating systems, thereby improving communication speed and overall communication performance.

[0192] In one exemplary embodiment, preemption and release of processing resources between a first operating system and a second operating system are performed via an inter-kernel communication interface, including:

[0193] S111, the first interaction request of the first operating system is transmitted to the second operating system through the inter-core communication interface. The first interaction request is used to request resource interaction with the second operating system. The resource interaction includes one of the following: resource preemption and resource release.

[0194] S112, obtain the first interaction response returned by the second operating system in response to the first interaction request through the inter-core communication interface, wherein the first interaction response is used to instruct the first operating system to perform resource interaction with the second operating system according to the first interaction response.

[0195] In this embodiment, considering that most of the services processed by the processor are those with low requirements for service response speed, the workload of the services processed by the first operating system is usually small. Therefore, the first operating system can request to preempt the processing resources of the second operating system or actively release the processing resources it occupies to the second operating system through the inter-core communication interface. Optionally, the preemption and release of processing resources can be carried out through a request-response interaction.

[0196] When the first operating system needs to preempt processing resources from the second operating system or actively release processing resources to the second operating system, it can transmit a first interaction request to the second operating system through the inter-core communication interface to request a resource interaction between the two operating systems, either preemption or release. Upon receiving the first interaction request, the second operating system can determine, based on its own load and other factors, whether to allow the first operating system to occupy at least a portion of its processing resources or to accept the processing resources released by the first operating system. It then returns a first interaction response to the first operating system through the inter-core communication interface, enabling the first operating system to interact with the second operating system based on the first interaction response.

[0197] It should be noted that the preemption and release of the aforementioned processing resources are at the operating system level (i.e., negotiation of processing resource scheduling is completed between the first and second operating systems), and not the actual scheduling of processing resources. The actual scheduling of processing resources is completed by the resource adaptive scheduling module.

[0198] This embodiment improves the utilization of processing resources by enabling resource interaction between different operating systems through a request-response mechanism, and by allowing the faster operating system to proactively release processing resources to the slower operating system.

[0199] In one exemplary embodiment, the above method further includes:

[0200] S121, detect the resource utilization rate of the processing resources of the first operating system;

[0201] S122, if it is determined that the first operating system needs to interact with the second operating system based on the resource utilization rate of the processing resources of the first operating system, the first interaction request is transmitted to the second operating system through the inter-core communication interface.

[0202] In this embodiment, the preemption and release process of processing resources may depend on the real-time load of the heterogeneous operating systems. Different operating systems may run load detection modules for detecting the load of the system, which may belong to the system control module within this system. For the first operating system, a first system control module may run on it. The load detection module in this system control module can detect the resource utilization rate of the first operating system's processing resources. The resource utilization rate of the first operating system's processing resources can be used to represent the load of the first operating system. The higher the resource utilization rate, the heavier the system load; conversely, the lower the resource utilization rate, the lighter the system load.

[0203] Based on the resource utilization rate of the first operating system's processing resources, it can be determined whether the first operating system needs to interact with the second operating system. For example, if the current resource utilization rate of an operating system (e.g., the first operating system) is too high (reaching a specified utilization threshold), or if the future resource utilization rate of an operating system is determined to be too high (reaching a specified utilization threshold) based on the business to be executed by the operating system, it can be determined that the operating system needs to preempt the processing resources of another operating system (e.g., the second operating system). If the resource utilization rate is too low (below another specified utilization threshold), it can be determined that the operating system needs to release processing resources to the other operating system. Optionally, if it is determined that the first operating system needs to interact with the second operating system, the step of transmitting a first interaction request to the second operating system through the inter-core communication interface can be triggered.

[0204] This embodiment improves the utilization of processing resources by enabling resource interaction between different operating systems through a request-response mechanism, and by allowing the faster operating system to proactively release processing resources to the slower operating system.

[0205] In one exemplary embodiment, the above method further includes at least one of the following:

[0206] S131, if the resource utilization rate of the processing resources of the first operating system is greater than or equal to the first utilization rate threshold, it is determined that the first operating system is to preempt the processing resources of the second operating system.

[0207] S132, if the processing resources of the first operating system are idle and there is no business to be executed by the first operating system, determine that the processing resources of the first operating system should be released to the second operating system.

[0208] In this embodiment, a threshold for the resource utilization rate of the processing resources of the first operating system can be preset, namely, the first utilization rate threshold. If the resource utilization rate of the processing resources of the first operating system is greater than or equal to the first utilization rate threshold, it can be determined that the current load of the first operating system is too heavy and it needs to preempt the processing resources of the second operating system to meet its own business needs.

[0209] Optionally, since the first operating system has a faster response speed than the second operating system, it is typically used for specific tasks. However, the triggering of these specific tasks is somewhat random, and the frequency of these tasks is usually low. Therefore, there is a certain probability that the processing resources of the first operating system will be idle and there will be no tasks waiting for the first operating system to execute. In this case, it can be determined that the first operating system needs to release at least some of its processing resources to the second operating system.

[0210] Here, when the processing resources of the first operating system are idle, the queue of pending business operations corresponding to the first operating system can be searched. If the queue of pending business operations is empty (i.e., there are no pending business operations), it is determined that the first operating system does not have any pending business operations within a certain time range. If the queue of pending business operations is not empty (i.e., it contains pending business operations), then even if the first operating system is not currently executing any business operations, it will not release processing resources to the second operating system.

[0211] This embodiment improves the rationality of resource scheduling and increases the utilization rate of processing resources by preempting processing resources when their utilization rate is too high and releasing them when they are idle and there are no subsequent tasks to be processed.

[0212] In one exemplary embodiment, the above method further includes:

[0213] S141, if there is no service scheduling in the first operating system and no service to be allocated to the first operating system, control the first operating system to enter a hibernation state.

[0214] In this embodiment, the first operating system may run periodically based on the processor; or, the first operating system may run based on the processor in response to a received wake-up request; or, the first operating system may run based on the processor based on the matching degree between the current operation service generated on the processor and the first operating system. The first operating system may hibernate after running; during the hibernation period of the first operating system, the second operating system adds the processor resources (e.g., processor cores) used by the first operating system to the scheduling resource pool (i.e., the available resource pool) of the second operating system.

[0215] Optionally, if the first operating system has no service scheduling and no services to be allocated to it (e.g., the resource utilization rate of the first operating system is lower than or about to fall below its set minimum utilization rate), it can be triggered to actively hibernate, that is, actively enter a hibernation state. Before controlling the first operating system to enter a hibernation state, the core resources of the first operating system can be released to the second operating system (resource release can be performed through interrupt requests); the system state data of the first operating system can also be saved, for example, by pushing the aforementioned data onto the stack, so that after the first operating system is woken up, it can be restored to its previous running state based on the saved system state data.

[0216] For example, when the first operating system has no task scheduling (i.e., is in an idle state), the first operating system sends a kernel release request to the second operating system. At this time, the kernel resources of the first operating system will be taken over by the second operating system, and the first operating system will enter a hibernation state.

[0217] In one optional application scenario, a first operating system (e.g., an RTOS) is periodically woken up to run. The first and second operating systems alternately occupy and schedule the same processing resource (which could be a processor core, e.g., CPU core 0). This same processor resource can be the first processing resource, and correspondingly, the second operating system's processing resource can be the second processing resource. During the time slice when the first operating system schedules the first processing resource, the second operating system generates an interrupt to take over the first processing resource at the first moment, causing the first operating system to hibernate. At this time, the first operating system saves its state in its stack, goes into hibernation, and then releases the first processing resource to the second operating system for takeover. After the second operating system completes its scheduling, it generates an interrupt at the second moment to preempt the first processing resource, waking up the first operating system. From this moment on, the first operating system re-enters the round-robin mode to occupy and schedule the first processing resource.

[0218] In the above-mentioned optional application scenarios, during the time slice when the second operating system schedules the first processing resource, the first operating system is in a sleep state. At the third moment, the first operating system may be woken up due to an interrupt event reported by the hardware. The second operating system will preserve the state of the process running on the first processing resource. The first operating system occupies the first processing resource. After processing the interrupt event reported by the hardware, it enters a sleep state again at the fourth moment. At this time, the first operating system reports an interrupt to release the first processing resource to the second operating system. The second operating system continues to schedule the first processing resource according to the set period and restores the running process.

[0219] Optionally, in this embodiment, when the first operating system runs periodically, the duration of a single running cycle can be the same as or different from the interval between two running cycles. During the interval between two running cycles, the first operating system may, but is not limited to, be in a dormant state, and the second operating system will use the processing resources allocated to the first operating system. If the duration of a single running cycle is the same as the interval between two running cycles, the first and second operating systems alternately occupy the processing resources allocated to the first operating system for the same duration. If the duration of a single running cycle is different from the interval between two running cycles, the first and second operating systems alternately occupy the processing resources allocated to the first operating system for different durations. The duration occupied by the first operating system may be longer than the duration occupied by the second operating system, or vice versa.

[0220] In an optional implementation, taking the device triggering the wake-up of the first operating system as an example, a wake-up strategy for the first operating system (such as an RTOS) in a trigger mode is provided. The trigger mode can be started by an interrupt initiated by a device in the first operating system bus domain. The first operating system bus domain connects devices 0 to N. When the first operating system is in a sleep state, assuming that device 0 triggers an interrupt to the first operating system at a certain moment, the first operating system is immediately woken up. After being woken up, the first operating system first triggers an interrupt to preempt the first processing resources to the second operating system. After receiving the interrupt, the second operating system first releases the first processing resources and saves the context (pushing the running data onto the stack). Then, the first operating system schedules the first processing resources to process the operation business indicated by the interrupt triggered by device 0. If it is currently in polling mode, the subsequent processing process is the same as the polling mode described above, which will not be repeated here.

[0221] In this embodiment, when all processing resources (e.g., kernel resources) of one operating system have been released to another operating system and the occupied processing resources are zero, the operating system is controlled to enter a hibernation state. Since the operating system is allowed to release all processing resources to another operating system, the utilization rate of processing resources is improved.

[0222] In one exemplary embodiment, transmitting a first interaction request from the first operating system to the second operating system via an inter-core communication interface includes at least one of the following:

[0223] S151, the first preemption request with the first interrupt number is transmitted to the second operating system through the inter-core communication interface, wherein the first preemption request is used to request to preempt the processing resources of the second operating system;

[0224] S152, the resource release request with interrupt number 2 is transmitted to the second operating system through the inter-core communication interface. The resource release request is used to request the release of the processing resources occupied by the resource release system to the second operating system.

[0225] In this embodiment, the preemption and release of processing resources between different operating systems can be accomplished through inter-core interrupts. Different interrupt events can be defined for different resource interaction types, and different interrupt events can correspond to different interrupt numbers. The interrupt number assigned to the first interrupt event in which the first operating system requests the second operating system to preempt processing resources is the first interrupt number, and the interrupt number assigned to the second interrupt event in which the first operating system actively releases processing resources to the second operating system is the second interrupt number.

[0226] As an optional implementation, the first interaction request can be a first preemption request, that is, a request to preempt the processing resources of the second operating system. The first operating system can transmit the first preemption request with the first interrupt number to the second operating system through the inter-core communication interface. That is, the triggering source of the inter-core communication interrupt with the first interrupt number is the first operating system, and the response source is the second operating system. The meaning of this inter-core communication interrupt is that the first operating system preempts the processing resources of the second operating system.

[0227] As another optional implementation, the first interaction request can be a resource release request, that is, a request to release the processing resources occupied by the first operating system to the second operating system. The first operating system can transmit the resource release request with the second interrupt number to the second operating system through the inter-core communication interface. That is, the triggering source of the inter-core communication interrupt with the second interrupt number is the first operating system, and the response source is the second operating system. The meaning of this inter-core communication interrupt is that the first operating system actively releases the processing resources to the second operating system.

[0228] In this embodiment, by allocating interrupt numbers for preempting and actively releasing processing resources between different operating systems, and by performing resource scheduling between operating systems through inter-core communication interrupts, the accuracy of resource scheduling is improved.

[0229] In one exemplary embodiment, preemption and release of processing resources between a first operating system and a second operating system are performed via an inter-kernel communication interface, including:

[0230] S161, the second interaction request of the second operating system is transmitted to the first operating system through the inter-core communication interface, wherein the second interaction request is used to request to preempt the processing resources of the first operating system;

[0231] S162, obtain the second interactive response returned by the first operating system in response to the second interactive request through the inter-core communication interface, wherein the second interactive response is used to indicate whether the first operating system allows the second operating system to preempt the processing resources of the first operating system.

[0232] In this embodiment, considering that most of the services processed by the processor are those with low requirements for response speed, the second operating system typically handles a larger volume of traffic. Therefore, the second operating system can request to preempt the processing resources of the first operating system through the inter-core communication interface. Optionally, the preemption of processing resources can be performed through a request-response interaction.

[0233] When the second operating system needs to preempt the processing resources of the first operating system, it can transmit a second interaction request to the first operating system through the inter-core communication interface, requesting resource interaction with the first operating system with the goal of resource preemption. After receiving the second interaction request, the first operating system can determine whether to allow the second operating system to occupy at least a portion of its processing resources based on its own load and other factors, and return the second interaction response to the second operating system through the inter-core communication interface, thereby enabling the second operating system to interact with the first operating system based on the second interaction response.

[0234] It should be noted that the above-mentioned preemption of processing resources is the scheduling of processing resources at the operating system level (i.e., the negotiation of processing resource scheduling is completed between the first operating system and the second operating system), and not the actual scheduling of processing resources. When the actual scheduling of processing resources is carried out, the resource adaptive scheduling module completes the actual scheduling of processing resources.

[0235] This embodiment improves resource utilization and response speed by enabling resource interaction between different operating systems through a request-response mechanism.

[0236] In one exemplary embodiment, the above method further includes:

[0237] S171, Detect the resource utilization rate of the processing resources of the second operating system;

[0238] S172, if it is determined that the second operating system is about to preempt the processing resources of the first operating system based on the resource utilization rate of the processing resources of the second operating system, the second interaction request is transmitted to the first operating system through the inter-core communication interface.

[0239] In this embodiment, the preemption process for processing resources may depend on the real-time load of the heterogeneous operating systems. Different operating systems may run load detection modules for detecting the load of the system being processed; these modules may belong to the system control module within the system. For the second operating system, a second system control module may run on it. The load detection module in this system control module can detect the resource utilization rate of the second operating system's processing resources. The resource utilization rate of the second operating system's processing resources can be used to represent the load of the second operating system. The higher the resource utilization rate, the heavier the system load; conversely, the lower the resource utilization rate, the lighter the system load.

[0240] Based on the resource utilization rate of the second operating system's processing resources, it can be determined whether the second operating system needs to interact with the first operating system's resources. For example, if the current resource utilization rate is too high (reaching a specified utilization threshold) or if the future resource utilization rate is determined to be too high (reaching a specified utilization threshold) based on the pending business, it can be determined that the second operating system needs to preempt the first operating system's processing resources. If it is determined that the second operating system needs to interact with the first operating system's resources, the step of transmitting the second interaction request to the first operating system through the inter-core communication interface can be triggered.

[0241] This embodiment improves the utilization of processing resources by enabling resource interaction between different operating systems through a request-response mechanism, and by allowing the slower operating system to proactively preempt the processing resources of the faster operating system.

[0242] In one exemplary embodiment, the above method further includes at least one of the following:

[0243] S181, if the current resource utilization rate of the second operating system is greater than or equal to the second utilization rate threshold, determine the processing resources of the second operating system to be preempted.

[0244] S182, if the resource utilization rate of the processing resources of the second operating system is determined to be greater than or equal to the third utilization threshold based on the executing business and the pending business of the second operating system, the processing resources of the second operating system to be preempted are determined.

[0245] In this embodiment, considering the complexity of business processing, there may be coupling relationships between businesses, and the importance of a business affects the operating system it is allowed to be allocated to. In addition, there may be differences in the priority processing levels between different businesses. The second operating system can comprehensively consider multiple factors such as its own resource utilization, its pending business, and pending execution business to determine whether it needs to preempt the processing resources of the first operating system.

[0246] As an optional implementation, a threshold for the resource utilization rate of the processing resources of the second operating system can be preset, namely, the second utilization threshold. If the resource utilization rate of the processing resources of the second operating system is greater than or equal to the second utilization threshold, it can be determined that the current load of the second operating system is too heavy and it needs to preempt the processing resources of the first operating system to meet its own business needs.

[0247] As another optional implementation, in addition to the currently executing business, the second operating system also needs to process the business already allocated to it. Therefore, a threshold for the resource utilization rate of the second operating system's processing resources can be preset, namely, the third utilization rate threshold. If the resource utilization rate of the second operating system's processing resources is determined to be greater than or equal to the third utilization rate threshold based on the executing business and the pending business of the second operating system, it can be determined that the second operating system is about to preempt the processing resources of the first operating system. It can be determined that the second operating system is about to be overloaded and needs to preempt the processing resources of the first operating system to meet its own business needs.

[0248] In addition to executing assigned services (which may include currently executing services as well as assigned services), the second operating system may also process services with high coupling between the currently pending services (i.e., newly added pending services) and its assigned services. Therefore, a threshold for the resource utilization rate of the second operating system's processing resources can be preset, namely the fourth utilization threshold, and a threshold for the coupling between the newly added pending services and the assigned services, namely the third coupling threshold. If the current resource utilization rate of the second operating system's processing resources is greater than or equal to the fourth utilization threshold, and the coupling between the newly added pending services and the assigned services of the second operating system is greater than or equal to the third coupling threshold, it can be determined that the second operating system is about to be overloaded and needs to preempt the processing resources of the first operating system to meet its own business needs.

[0249] Optionally, the second utilization threshold and the third utilization threshold can be the same or different. For example, both can be 50%, 60% or other values. The fourth utilization threshold can be a value less than the second and third utilization thresholds, for example, 40%, or other utilization thresholds. In this embodiment, no limitation is made on each utilization threshold.

[0250] This embodiment determines the operating system's resource scheduling requirements based on the currently executing business, the currently executing business and the allocated business, or the currently executing business, the allocated business and the newly added business to be allocated. This can improve the flexibility of resource scheduling and also improve the utilization rate of processing resources.

[0251] In one exemplary embodiment, the above method further includes:

[0252] S191, if the service priority of the service being executed in the first operating system is not lower than the service priority of the service to be executed in the second operating system, it is determined that the first operating system refuses the second operating system from preempting the processing resources of the first operating system.

[0253] S192, if the service priority of the service being executed in the first operating system is lower than the service priority of the service to be executed in the second operating system, it is determined that the first operating system allows the second operating system to preempt the processing resources of the first operating system.

[0254] For the first operating system, if it is currently idle and has no assigned tasks to execute, or no tasks that must be assigned to it, the first operating system can directly determine whether to allow the second operating system to preempt its processing resources. If the first operating system is currently processing tasks, has assigned tasks to execute, or has tasks that must be assigned to it, then it needs to consider factors such as the task priority of these tasks to determine whether to allow the second operating system to occupy the first operating system's processing resources.

[0255] Optionally, if the service priority of the service being executed by the first operating system is not lower than the service priority of the service to be executed by the second operating system, it means that the urgency of the service being executed by the first operating system is not lower than the urgency of the service to be executed by the second operating system, and the first operating system refuses to allow the second operating system to preempt the processing resources of the first operating system. Conversely, if the service priority of the service being executed by the first operating system is lower than the service priority of the service to be executed, it means that the urgency of the service being executed by the first operating system is lower than the urgency of the service to be executed by the second operating system, and the first operating system allows the second operating system to preempt the processing resources of the first operating system.

[0256] Here, although the response speed of the first operating system is higher than that of the second operating system, and services with higher priority are usually allocated to the first operating system first, considering the coupling relationship between services, services with higher priority may also be allocated to the second operating system. Therefore, resource preemption can be based on service priority. Alternatively, resource preemption can be allowed only when the service priority of both the service currently executing in the first operating system and the service to be executed is not lower than the service priority of the service to be executed in the second operating system.

[0257] This embodiment improves the flexibility and rationality of resource scheduling by scheduling processing resources between operating systems based on factors such as comprehensive business priorities.

[0258] In one exemplary embodiment, transmitting a second interaction request from the second operating system to the first operating system via an inter-core communication interface includes:

[0259] S201, the second preemption request with the third interrupt number is transmitted to the first operating system through the inter-core communication interface, wherein the second preemption request is used to request to preempt the processing resources of the first operating system.

[0260] In this embodiment, similar to the previous embodiments, the preemption and release of processing resources between different operating systems can be accomplished through inter-core interrupts. Different interrupt events can be defined for different resource interaction types, and different interrupt events can correspond to different interrupt numbers. Among them, the interrupt number assigned to the third interrupt event in which the second operating system requests the first operating system to preempt processing resources is the third interrupt number.

[0261] Optionally, the second interaction request can be a second preemption request, that is, a request to preempt the processing resources of the first operating system. The second operating system can transmit the second preemption request with the third interrupt number to the first operating system through the inter-core communication interface. That is, the triggering source of the inter-core communication interrupt with the third interrupt number is the second operating system, and the response source is the first operating system. The meaning of this inter-core communication interrupt is that the second operating system preempts the processing resources of the first operating system.

[0262] This embodiment improves the accuracy of resource scheduling by allocating interrupt numbers for preempting processing resources between different operating systems and performing resource scheduling between operating systems through inter-core communication interrupts.

[0263] In one exemplary embodiment, obtaining a second interactive response returned by the first operating system in response to a second interactive request through an inter-core communication interface includes at least one of the following:

[0264] S211, the resource release enable response with interrupt number 4 is transmitted to the second operating system through the inter-core communication interface, wherein the resource release enable response is used to instruct the first operating system to allow the second operating system to preempt the processing resources of the first operating system;

[0265] S212, the resource release rejection response with interrupt number 5 is transmitted to the second operating system through the inter-core communication interface. The resource release rejection response is used to instruct the first operating system to reject the second operating system from preempting the processing resources of the first operating system.

[0266] In this embodiment, similar to the previous embodiments, the preemption and release of processing resources between different operating systems can be accomplished through inter-core interrupts. Different interrupt events can be defined for different resource interaction types, and different interrupt events can correspond to different interrupt numbers. The interrupt number assigned to the fourth interrupt event and the fifth interrupt event when the second operating system requests a resource preemption response from the second operating system is the fifth interrupt number. The fourth interrupt event is an interrupt event that allows resource preemption, and the fifth interrupt event is an interrupt event that rejects resource preemption.

[0267] As an optional implementation, if the first operating system determines that the second operating system is allowed to occupy at least a portion of its processing resources, the first operating system can transmit the allowed resource release response with interrupt number four to the second operating system through the inter-core communication interface. That is, the triggering source of the inter-core communication interrupt with interrupt number four is the first operating system, and the response source is the second operating system. The meaning of this inter-core communication interrupt is that the first operating system passively releases processing resources to the second operating system.

[0268] As another optional implementation, if the first operating system determines that it will refuse the second operating system from using its processing resources, the first operating system can transmit a resource release refusal response with interrupt number 5 to the second operating system through the inter-core communication interface. That is, the triggering source of the inter-core communication interrupt with interrupt number 5 is the first operating system, and the response source is the second operating system. The meaning of this inter-core communication interrupt is that the first operating system refuses to release processing resources to the second operating system.

[0269] In this embodiment, by allocating interrupt numbers for allowing and denying preemption of processing resources between different operating systems, resource scheduling between operating systems is performed through inter-core communication interrupts, thereby improving the accuracy of resource scheduling.

[0270] As an optional example, the following explanation uses RTOS and Linux systems as examples to illustrate inter-core communication interrupts. In Linux, inter-core communication can be achieved based on a custom interrupt vector table and interrupt events between heterogeneous operating systems. The Linux operating system fully utilizes undefined bit numbers in SGI to customize terminal signals, reducing the cost of inter-core communication. Undefined bit numbers can be 8-15. In multi-core heterogeneous operating systems, to maximize compatibility with current resource allocation methods, bit numbers 8-15 (a total of 8 interrupts) are used to represent the inter-core interrupt vector table. A feasible allocation scheme for the vector table is shown in Table 1:

[0271] Table 1

[0272] 1 8 RTOS kernel Linux kernel RTOS system actively releases CPU cores 2 9 Linux kernel RTOS kernel Linux system requests takeover of CPU core 3 10 RTOS kernel Linux kernel RTOS system passively releases CPU cores 4 11 RTOS kernel Linux kernel RTOS system refuses to release CPU cores 5 12 RTOS kernel Linux kernel RTOS preempts CPU cores

[0273] Among them, the first interrupt number corresponds to interrupt number 12, the second interrupt number corresponds to interrupt number 8, the third interrupt number corresponds to interrupt number 9, the fourth interrupt number corresponds to interrupt number 10, and the fifth interrupt number corresponds to interrupt number 11.

[0274] As shown in Table 1, active release refers to the following: When the RTOS system has no service scheduling (i.e., is in an idle state), it sends an SGI interrupt with interrupt number 8 to the Linux system. At this time, the core resources of the RTOS will be taken over by the Linux system, and the RTOS system will enter a hibernation state. Passive release refers to the following: When the service load of the Linux system increases sharply, it sends an SGI interrupt with interrupt number 9 to the RTOS system. If the process currently being executed by the RTOS system is allowed to be interrupted (processes on the RTOS system have priorities, which can be configured according to the actual situation; if the priority is higher than interrupt 9, it cannot be interrupted, and if it is lower, it can be interrupted), the RTOS system will send an SGI interrupt with interrupt number 10 to the Linux system and passively release the CPU core resources it occupies for the Linux system to schedule. After that, the RTOS system enters a hibernation state. If the RTOS system is not allowed to be interrupted at this time, it will send an SGI interrupt with interrupt number 11 to the Linux system to inform the Linux system that the core resources of the RTOS cannot be released at this time. At this time, the Linux system will continue to execute according to the current running strategy without any changes.

[0275] It should be noted that the inter-core communication vector table is not unique and is not limited to the inter-core communication vector table specified in Table 1 above.

[0276] In an optional implementation, a method for inter-core communication is provided. The method includes the following steps:

[0277] Step 1: The first operating system sends the target data (which may be business data) to the target virtual channel (which may be storage space) in the processor memory.

[0278] Optionally, the target data is the data to be sent, and the target virtual channel is a free storage space in memory. The first operating system sending the target data to the target virtual channel in the processor memory means that the CPU core of the first operating system writes the data to be sent into the target virtual channel.

[0279] Step 2: The first operating system sends an interrupt notification message (which can be the aforementioned inter-core interrupt request) to the second operating system. Optionally, the CPU core of the first operating system sends an interrupt notification message to the CPU core of the second operating system. The interrupt notification message may carry the address of the target virtual channel, which is used to notify the second operating system to obtain the target data from the target virtual channel. The interrupt notification message may be software-triggered or hardware-triggered.

[0280] Step 3: The second operating system responds to the interrupt notification message and retrieves the target data from the target virtual channel in memory. Optionally, the CPU core of the second operating system responds to the interrupt notification message, parses the address of the target virtual channel from the interrupt notification message, locates the target virtual channel in memory based on the parsed address, and retrieves the target data from the target virtual channel, thereby realizing data interaction between the first and second operating systems.

[0281] Through the above steps, when multiple operating systems running on the processor need to transfer data to each other, the first operating system sending the data sends the target data to the target virtual channel in the processor's memory and sends an interrupt notification message to the second operating system. The second operating system receiving the data responds to the interrupt notification message and retrieves the target data from the target virtual channel. This solves the problems of wasted resources and strong dependence on the operating system in the inter-core communication process, and achieves the effect of reducing the waste of resources and dependence on the operating system in the inter-core communication process.

[0282] In one exemplary embodiment, the memory includes a data storage area and a metadata storage area. The data storage area is divided into multiple storage units, each of which is used to store business data. The metadata storage area is used to store the size and occupancy status of each storage unit in the data storage area.

[0283] Optionally, the target virtual channel consists of one or more storage units in the data storage area. The metadata storage area can be divided into storage slices with the same number of storage units. Each storage slice is used to record the size and occupancy status of a storage unit. The size of the storage unit can be represented by the starting address and ending address of the storage unit, or by the starting address and the length of the storage unit. The occupancy status includes occupied status and unoccupied status, which can be represented by the value of the free flag.

[0284] In an exemplary embodiment, the first operating system sending target data to a target virtual channel in the processor memory includes: the first operating system reading records in the metadata storage area, determining at least one storage unit in the data storage area that is in an idle state and has a total space greater than or equal to the length of the target data based on the read records, and obtaining a target virtual channel; setting the state of at least one storage unit in the metadata storage area corresponding to the target virtual channel to an occupied state, and storing the target data in the target virtual channel.

[0285] It should be noted that in order to ensure that the target data can be written to memory continuously, the target virtual channel to be written to needs to be a free storage space with a length greater than or equal to that of the target data. Since memory is divided into a metadata storage area and a data storage area, the occupancy status of each storage unit recorded in the metadata storage area can be read to find the storage unit that is free and can meet the data storage requirements.

[0286] For example, if each storage unit is the same size, and the length of the target data is greater than the length of a storage space, then the required number of storage units is determined based on the length of the target data. From this, multiple storage units that are idle, consecutive, and whose quantity meets the data storage requirements are identified to form the target virtual channel.

[0287] For example, each storage unit is of equal size, and the data storage area has pre-combined the storage units to obtain multiple virtual channels of different sizes. Each virtual channel is composed of one or more storage units. The system can read the occupancy status of each virtual channel recorded in the metadata storage area, and find the virtual channel that is idle and whose length is greater than the length of the target data, i.e., the target virtual channel. It should be noted that when the system software needs to request shared memory space, it will determine whether the length of the data to be requested is greater than the maximum length of data that the virtual channel can store. If it is greater than the maximum length of data that the virtual channel can store, the system software can send the data to be sent in multiple parts, ensuring that the length of each sent data is less than or equal to the maximum length of data that the virtual channel can store, thereby ensuring smooth communication.

[0288] In one exemplary embodiment, the second operating system responds to an interrupt notification message and retrieves target data from a target virtual channel in memory by: the second operating system reading records in the metadata storage area, determining the target virtual channel based on the read records, retrieving the target data from at least one storage unit corresponding to the target virtual channel, and setting the state of at least one storage unit to an idle state.

[0289] In other words, after the second operating system extracts the target data from the storage unit corresponding to the target virtual channel, in order not to affect the use of the target virtual channel by other systems or tasks, it sets the state of the storage unit corresponding to the target virtual channel to an idle state.

[0290] In an exemplary embodiment, the first operating system sending target data to a target virtual channel in the processor memory includes: the driver layer of the first operating system receiving the target data, determining a virtual channel in an idle state in the memory to obtain the target virtual channel; setting the state of the target virtual channel to an occupied state, and storing the target data in the target virtual channel.

[0291] Optionally, both real-time and non-real-time operating systems have a driver layer. After receiving the target data to be sent, the driver layer calls an interface to find the target virtual channel in memory. To prevent other systems from requesting to use the target virtual channel during the data writing process, after finding the target virtual channel, the status of the target virtual channel is set to occupied, and then the target data is written to the target virtual channel.

[0292] In an exemplary embodiment, when the first operating system includes an application layer, the application layer provides a human-computer interaction interface. Before the driver layer of the first operating system determines a virtual channel in an idle state in memory, the application layer of the first operating system can receive user-inputted data to be sent through the human-computer interaction interface, encapsulate the data to be sent in a preset format to obtain target data, and call a data writing function to transmit the target data to the driver layer through a preset communication interface, wherein the preset communication interface is set on the driver layer.

[0293] Optionally, the application layer fills the data to be sent according to a preset format to obtain the target data, and then generates a device file ipidev in the system's / dev path. When the application layer needs to read or write data from the driver layer, it can first use the system's built-in open function to open the device file / dev / ipidev, and then use the system's built-in write function to send the target data from the application layer to the driver layer. The driver layer then puts the data in the target virtual channel in shared memory and triggers an interrupt to notify the second operating system to retrieve the data.

[0294] In one exemplary embodiment, the second operating system responds to an interrupt notification message and obtains target data from a target virtual channel in memory by: the second operating system triggering an interrupt handling function based on the interrupt notification message, determining the target virtual channel from memory through the interrupt handling function, and obtaining the target data from the target virtual channel.

[0295] In one exemplary embodiment, determining the target virtual channel from memory through an interrupt handler function and obtaining target data from the target virtual channel includes: calling the target task through the interrupt handler function, wherein the target task determines the target virtual channel from memory and obtains target data from the target virtual channel.

[0296] Optionally, the interrupt handler sends a task notification to wake up the target task responsible for data extraction. The target task first searches for the target virtual channel in shared memory by calling the interface, and then reads the target data from the target virtual channel and performs data parsing.

[0297] In one exemplary embodiment, when the second operating system includes an application layer, a function identifier is stored in memory, indicating a target function. Determining a target virtual channel from memory via an interrupt handler function and obtaining target data from the target virtual channel includes: determining the function identifier and the target virtual channel from memory via the interrupt handler function, and sending the address information of the target virtual channel to a target application matching the function identifier, wherein the target application is a target application in the application layer; the target application calls a data reading function to transmit the address information to the driver layer via a preset communication interface; the driver layer obtains the target data from the target virtual channel and transmits the target data to the target application layer program; wherein the preset communication interface is set in the driver layer; and the target application processes the target data according to the processing function matching the function identifier to execute the target function.

[0298] Optionally, after the second application system receives the interrupt notification message, the application layer calls the corresponding interrupt handling function to find the target virtual channel in memory, obtain the address information of the target virtual channel, and then generate a device file ipidev in the system's / dev path. When the application layer needs to read or write data from the driver layer, it can first use the system's built-in open function to open the device file / dev / ipidev, and then use the system's built-in read function to read the target data in the target virtual channel. That is, the driver layer finds the corresponding target data in shared memory according to the address information of the target virtual channel and returns the target data and the length of the target data to the application layer. In an exemplary embodiment, the state of the target virtual channel is set to idle.

[0299] It should be noted that different applications at the application layer can use target data to implement different functions. Function identifiers are stored in memory, indicating the target functions that the application implements through the target data. Optionally, the function identifier can be Net or Cmd. During system initialization, Net, Cmd and the application PID are registered to the driver. The driver layer can find the application PID based on the received NetFn and Cmd, and send the data to the corresponding application according to the PID.

[0300] For example, NetFn = 1 and Cmd = 1 indicates that the first and second operating systems exchange "helloworld" messages. At system startup, an array is initialized with three columns: NetFn, Cmd, and the corresponding handler function for NetFn and Cmd, denoted as xxCmdHandler. For instance, when the second operating system receives a message from the first operating system, it retrieves NetFn and Cmd from the message, determines that NetFn = 1 and Cmd = 1, and then executes the corresponding handler function HelloCmdHandler to perform the appropriate function.

[0301] In an exemplary embodiment, the data storage area includes multiple memory channels, each memory channel consisting of one or more storage units. The metadata storage area stores multiple records, each record used to record the metadata of a memory channel. The metadata of each memory channel includes at least the channel ID of the memory channel, the size of the memory channel, and the occupied status of the memory channel. The first operating system reads the records in the metadata storage area and determines, based on the read records, at least one storage unit in the data storage area that is in an idle state and has a total space greater than or equal to the length of the target data. Obtaining the target virtual channel includes: traversing the records stored in the metadata storage area and determining whether there exists a first target record indicating that the memory channel is in an idle state and the size of the memory channel is greater than or equal to the length of the target data; if the first target record exists, determining the memory channel indicated by the channel ID recorded in the first target record as the target virtual channel.

[0302] It should be noted that the data storage area can be divided into n virtual memory channels, each of which can be of different sizes. That is, the sizes of the n virtual channels are 20*m, 21*m, 22*m, 23*m...2n-1*m, where m is the size of a storage unit. The following structure is set up as metadata to manage the memory channels:

[0303] typedef struct{

[0304] uint32_t Flag;

[0305] uint16_t ChannelId;

[0306] uint8_t SrcId;

[0307] uint8_t NetFn;

[0308] uint8_t Cmd;

[0309] uint32_t Len;

[0310] uint32_t ChannelSize;

[0311] uint8_t*pData;

[0312] uint8_t CheckSum;

[0313] }IpiHeader_T

[0314] In this configuration, `uint32_t Flag` represents the state of the memory channel; for example, 0xA5A5A5A5 indicates that the channel is not empty, otherwise it is empty. `uint16_t ChannelId` represents the channel ID. `uint8_t SrcId` represents the source CPU ID, which is the CPU that writes data to the memory channel. `uint8_t NetFn` and `uint8_t Cmd` are function parameters. `uint32_t Len` is the length of the data stored in the memory channel. `uint32_t ChannelSize` represents the size of the memory channel. `uint8_t *pData` refers to the starting address of the memory channel. `uint8_t CheckSum` is the checksum. When the first operating system needs to send data, it calculates the checksum value using a checksum algorithm and sends it to the second operating system. Upon receiving the data and checksum, the second operating system calculates the checksum value using the same checksum algorithm and compares it with the received checksum value. If they match, the received data is valid; otherwise, the received data is invalid. Each virtual memory channel corresponds to a structure record. These structure records are stored sequentially at the beginning of the shared memory in ascending order of channel ID. After the system powers on, these structure records are initialized. The initialization Flag is 0 to indicate that the channel is empty. The initialization ChannelId is 0, 1, 2...n-1 in sequence. The initialization ChannelSize is the size of the corresponding virtual memory channel. The initialization pData points to the starting address of the corresponding virtual memory channel.

[0315] In an exemplary embodiment, when determining the target virtual channel, the first operating system uses the GetEmptyChannel interface to search for a virtual channel among all memory channels that meets the following two conditions based on the size of the target data to be sent: the idle flag Flag in the channel structure IpiHeader is not equal to 0xA5A5A5A5 (i.e., the channel is in an idle state), and the channel size ChannelSize in the channel structure IpiHeader is greater than or equal to the size of the target data (i.e., the memory size can meet the storage requirements of the target data). After finding a target virtual channel that meets the above conditions, the state of the channel is set to non-empty, that is, the idle flag Flag in the channel structure IpiHeader is set to 0xA5A5A5A5, and then the target data is copied into the target virtual channel.

[0316] In an exemplary embodiment, when a memory channel is occupied, the metadata of the memory channel also includes the ID of the source CPU core of the target data and the ID of the destination CPU core of the target data. The second operating system reads records in the metadata storage area, and determining the target virtual channel based on the read records includes: traversing the records stored in the metadata storage area, determining whether a second target record exists, wherein the second target record indicates that the memory channel is occupied and the ID of the destination CPU core is the ID of the CPU core of the second operating system, and the ID of the source CPU core is not the ID of the CPU core of the second operating system; if a second target record exists, the memory channel indicated by the channel ID recorded in the second target record is determined as the target virtual channel.

[0317] In other words, a target virtual channel is a virtual channel that meets the following three conditions among all channels: First, the idle flag Flag in the channel structure IpiHeader is equal to 0xA5A5A5A5 (i.e., indicating that the channel is occupied); second, the TargetId in the channel structure is equal to the ID of the current CPU (i.e., indicating that the destination CPU of the target data is the CPU of the second operating system); and third, the TargetId in the channel structure is not equal to SrcId (i.e., indicating that the target data was not sent by the CPU of the second operating system).

[0318] It should be noted that if a single bit is used to represent the idle flag (Flag), where 0 indicates an empty channel and 1 indicates a non-empty channel, and the Flag, originally 0, suddenly changes to 1, the system will assume the channel is not empty after reading the Flag, leading to communication errors. In this embodiment, the idle flag is set to multiple special characters, such as 0xA5A5A5A5. Since the probability of multiple bits simultaneously changing to special characters is much lower than the probability of a single bit changing, this prevents changes in storage medium bits from affecting the Flag value, thereby improving communication security.

[0319] In an exemplary embodiment, the metadata storage area stores a state mapping table with multiple records. Each record records the occupied state of a storage unit. The first operating system reads the records in the metadata storage area and determines, based on the read records, at least one storage unit in the data storage area that is in an idle state and has a total space greater than or equal to the length of the target data, to obtain the target virtual channel. This includes: determining a preset number of storage units to be occupied by the target data; sequentially scanning each record from the initial position of the state mapping table; when a preset number of consecutive target records are scanned, determining the consecutive storage units indicated by the preset number of target records, wherein the target records represent that the storage units are in an idle state; and determining the consecutive storage units as the target virtual channel.

[0320] It should be noted that, in order to facilitate data storage and retrieval, since the operating system needs to occupy contiguous storage units in memory when transmitting business data, it is first necessary to determine the number of storage units in the memory allocation instruction. Since each storage unit has the same memory space, the preset number of contiguous storage units required can be calculated from the required memory space size, denoted as numb.

[0321] Optionally, the first operating system traverses records from the index position in the state mapping table. The index position can be the starting position of the state mapping table. Starting from the starting position of the state mapping table, it sequentially queries each record in the state mapping table to determine whether there are any consecutive records with free memory pages greater than or equal to numb. If there are records that meet the above conditions, it determines the contiguous storage unit in the processor through the correspondence between the record and the memory page, and determines the contiguous storage unit as the target virtual channel to write data to the target virtual channel.

[0322] In an exemplary embodiment, the interrupt notification message includes the starting address of a contiguous storage unit and a preset number. The second operating system reads records in the metadata storage area, and determining the target virtual channel based on the read records includes: sequentially scanning each record from the initial position of the state mapping table; if a record with the starting address of a contiguous storage unit is scanned, the storage unit indicated by the scanned address and a preset number minus one contiguous storage unit are determined as the target virtual channel.

[0323] Optionally, a contiguous storage unit refers to a contiguous storage unit with a quantity equal to numb. Each record in the state mapping table also records the starting address of the corresponding storage unit. If the second operating system finds a record with the starting address of a contiguous storage unit equal to numb in the mapping table, it means that the starting address of the target virtual channel has been scanned. The storage unit indicated by the starting address and the numb-1 contiguous storage units following that storage unit constitute the target virtual channel. The second operating system obtains data from the target virtual channel to complete the data interaction with the first operating system.

[0324] In one exemplary embodiment, a counter is used to record the continuous target records that are scanned. During the process of scanning each record sequentially from the initial position of the state mapping table according to the number of storage units, the counter is incremented when a target record is currently scanned, and the counter is reset to zero when a non-target record is currently scanned.

[0325] Optionally, the relationship between the counter value and the required number of storage units is used to determine whether there is a preset number of consecutive target records, i.e., whether there is a preset number of consecutive storage units. Optionally, the counter count is recorded as cntr. If a scanned storage unit is empty, cntr is incremented by 1. If a scanned storage unit is not empty, the accumulated number of consecutive, free storage units cntr is cleared to zero, and the search for consecutive, free storage units continues from the address after that storage unit. This continues until cntr equals numb, indicating that consecutive, free storage units that meet the memory requirements have been found. If, after scanning the entire state mapping table, there is no cntr greater than or equal to numb, it indicates that the dynamic memory allocation has failed and the preset number of consecutive storage units does not exist.

[0326] In an exemplary embodiment, before the first operating system reads records in the metadata storage area and determines at least one storage unit in the data storage area that is in an idle state and has a total space greater than or equal to the length of the target data based on the read records, and obtains the target virtual channel, the method further includes: the first operating system sending a memory request instruction and performing a locking operation on the processor's memory, wherein the memory request instruction is used to request the use of the processor's memory; if the memory locking is successful, reading records in the status mapping table.

[0327] Optionally, a memory request instruction is an instruction issued by the operating system running on the processor to request the use of the processor's memory. It should be noted that, in order to prevent conflicts caused by multiple operating systems requesting the use of the processor's memory at the same time, the operating system first performs a locking operation on the processor's memory when sending a memory request instruction. Only after the locking is successful can the memory be requested and used. The locking operation refers to the exclusive operation of memory request. After the current operating system successfully locks the memory, if the lock is not released, other servers do not have the right to request the use of the processor's memory.

[0328] In an exemplary embodiment, performing a locking operation on the processor's memory includes: determining whether the memory is currently in a locked state, wherein the locked state indicates that the memory is in a state of being requested for use; if the memory is not currently in a locked state, performing a locking operation on the memory; if the memory is currently in a locked state, determining that the locking of the memory has failed, and after a preset time period, requesting to lock the processor's memory again, until the memory is successfully locked, or until the number of times the locking request is greater than a preset number.

[0329] Before the processor runs, the metadata storage area and data storage area in the processor need to be initialized. Optionally, the records stored in the state mapping table in the metadata storage area and the memory management information need to be initialized.

[0330] Before performing a memory allocation operation, configure the memory management information as follows:

[0331] typedef struct{

[0332] uint32_t MemReady;

[0333] uint32_t MemLock;

[0334] MallocMemInfo_T;

[0335] Among them, the member variable MemLock of the structure MallocMemInfo_T indicates whether the shared memory has been initialized, and the variable MemReady is 0xA5A5A5A5, which means that the initialization operation has been completed and memory can be dynamically allocated and released normally; the member variable MemReady of the structure MallocMemInfo_T represents whether it is locked.

[0336] Optionally, if the variable MemLock is read as 0, it means that no system or task is currently requesting memory, i.e., the memory is not currently locked. If the variable MemLock is read as 0xA5A5A5A5, it means that a system or task is requesting memory, and it is necessary to wait for this request to be completed before requesting memory again; the current request for locking has failed.

[0337] In an exemplary embodiment, if a locking operation on memory fails, the memory is requested again after a preset waiting period until the locking is successful. For example, the preset waiting period can be 100 microseconds.

[0338] In one exemplary embodiment, if the lock acquisition request fails and the number of repeated requests exceeds a preset number, indicating that the memory in the processor is in an unallocable state for the current duration, the acquisition operation is stopped. For example, the preset number of requests could be 3. If the number of lock acquisition requests exceeds 3, a message indicating that the current memory is unavailable can be returned to the operating system that sent the request.

[0339] Optionally, after a target virtual channel exists in the processor's memory space that can be used by the first operating system, the first operating system stores the target data to be transmitted into the corresponding target virtual channel. In an exemplary embodiment, the occupancy status of the processor's memory space is updated according to the data writing status of the first operating system, that is, the target contiguous memory space is changed from an unoccupied state to an occupied state. At the same time, in order to allow other systems or tasks to request memory, the lock on the memory is released.

[0340] In one exemplary embodiment, the method further includes: releasing the lock on the memory if no consecutive preset number of target records are scanned.

[0341] Optionally, if a preset number of consecutive, idle storage units are not detected after scanning the records in the state mapping table, it indicates that there are not enough memory pages in the processor's memory for the first operating system to use. The dynamic memory allocation fails, and the memory lock is released.

[0342] In one exemplary embodiment, an interrupt notification message is sent to the second operating system via a software interrupt. Optionally, sending the interrupt notification message to the second operating system via a software interrupt includes: writing an interrupt number and the CPU core ID of the second operating system into a preset register of the processor, and generating an interrupt notification message based on the interrupt number and the CPU core ID of the second operating system.

[0343] Optionally, a software interrupt is an interrupt generated by software. Software can send interrupts to its own CPU core or to other CPU cores. The default register can be the GICD_SGIR register. A software interrupt can be generated by writing the SGI (Software Generated Interrupts) interrupt number and the destination CPU ID to the GICD_SGIR register. The SGI interrupt number is a software interrupt number reserved for inter-core communication.

[0344] Optionally, a hardware interrupt refers to an interrupt generated by a hardware device. It can be a private peripheral interrupt or a shared peripheral interrupt. It should be noted that a hardware interrupt is an interrupt introduced by hardware outside the CPU and has randomness, while a software interrupt is an interrupt introduced by software running in the CPU executing an interrupt instruction and is pre-set. This embodiment does not limit the way interrupt notification messages are generated.

[0345] In one alternative implementation, a method for sharing memory is provided. The method includes the following steps:

[0346] Step 1: Receive a memory request instruction and perform a locking operation on the processor's memory. The memory request instruction is used to request the use of the processor's memory.

[0347] Optionally, a memory allocation instruction is an instruction issued by the operating system running on the processor to request the use of the processor's memory. It can be sent by the first operating system. It should be noted that, to prevent conflicts caused by multiple operating systems simultaneously requesting processor memory, a locking operation is first performed on the processor's memory when the operating system sends a memory allocation instruction. Only after successful locking can memory be requested. The locking operation is an exclusive operation for memory allocation; if the lock is not released after the current operating system successfully locks the memory, other servers do not have the right to request the use of the processor's memory.

[0348] In the shared memory method provided in the embodiments of this application, before performing a locking operation on the processor's memory, the method further includes: determining whether the memory is currently in a locked state, wherein the locked state indicates that the memory is in a state of being requested for use; and performing a locking operation on the memory if the memory is not currently in a locked state.

[0349] Optionally, since multiple systems or tasks may conflict when they request memory at the same time, the processor's memory can only be locked by one system or task at a time. Therefore, the current operating system can only perform a locking operation on the memory if it is detected that the current memory is not in a locked state.

[0350] Optionally, the state of memory lock can be determined by checking whether the preset variable stored in memory is a preset value. If the preset variable is not a preset parameter value, it indicates that the memory is not locked and no other system or task is requesting memory space, so the locking is successful. Conversely, if the preset variable is a preset parameter, it indicates that the memory is locked at the current moment and other systems or tasks besides the operating system are requesting memory space, so the locking fails.

[0351] In this shared memory method, after determining whether the memory is currently in a locked state, the method further includes: if the memory is currently in a locked state, determining that locking the memory has failed; if locking the memory has failed, requesting to lock the processor's memory again after a preset time, until the memory is successfully locked, or until the number of times the lock request is greater than a preset number.

[0352] Optionally, if the memory locking operation fails, the memory lock can be requested again after a preset waiting period until the lock is successfully acquired. For example, the preset waiting period can be 100 microseconds.

[0353] In one exemplary embodiment, if the lock acquisition request fails and the number of repeated requests exceeds a preset number, indicating that the memory in the processor is in an unallocable state for the current duration, the acquisition operation is stopped. For example, the preset number of requests could be 3. If the number of lock acquisition requests exceeds 3, a message indicating that the current memory is unavailable can be returned to the operating system that sent the request.

[0354] Step 2: If the memory is successfully locked, read the memory's occupied status and determine whether there is a free target memory space in the memory based on the memory's occupied status. The size of the target memory space is greater than or equal to the size of the memory requested by the memory allocation instruction.

[0355] After successfully acquiring the lock, the operating system requests memory from the processor. Optionally, based on the memory request instruction issued by the operating system, it scans information recording the memory occupancy status to determine if a target memory space exists. That is, it determines whether there is a contiguous, unoccupied memory space in the processor that can satisfy the memory usage requirement. Satisfying the memory usage requirement means that the size of the memory space is greater than or equal to the memory size requested by the operating system. In an exemplary embodiment, the determination result is obtained by checking whether the size of the contiguous, unoccupied memory space is greater than or equal to the memory size requested by the operating system.

[0356] It should be noted that non-contiguous memory spaces can also be used when allocating memory. A pointer can be added after a non-minimum memory block to point to the next allocated minimum memory block. Furthermore, during data read / write operations, data can be read and written across data blocks based on the storage address and the pointer. This embodiment does not limit the form of the target memory space.

[0357] Step 3: If the target memory space exists in memory, the address information of the target memory space is fed back to the sender of the memory request instruction, the memory occupancy status is updated, and the lock on the memory is released. Here, the sender refers to the operating system (e.g., the first operating system) that sent the memory request instruction. It should be noted that since the operating system uses shared memory to send and receive data during inter-core communication and uses the address returned by the requested memory to access data during the data sending and receiving process, it is necessary to determine the address information of the requested memory space.

[0358] Optionally, after a target memory space (which may be indicated by the aforementioned judgment result) exists in the processor's memory space that can be used by the operating system, the address information of the target contiguous space is sent to the operating system, and the operating system stores the data to be transmitted into the corresponding memory space according to the address information.

[0359] In one exemplary embodiment, the occupancy status of the processor's memory space is updated according to the data writing status of the operating system. That is, the target memory space is changed from an unoccupied state to an occupied state, and the locking operation before dynamic memory allocation is released so that other operating systems can request and use the processor's memory space.

[0360] By following the steps above, the problems of low efficiency, poor flexibility, and excessive reliance on the operating system in shared memory among multiple kernels can be solved, thereby improving the flexibility and efficiency of shared memory and reducing dependence on the operating system.

[0361] In this shared memory method, the memory includes a metadata storage area and a data storage area. The data storage area is used to store business data. The metadata storage area stores a state mapping table, which is used to record the occupied status of the data storage area. Reading the occupied status of the memory and determining whether there is free target memory space in the memory based on the occupied status includes: reading the record in the state mapping table from the metadata storage area and determining whether there is target memory space in the data storage area based on the record in the state mapping table.

[0362] The memory occupancy status is queried by querying records in the status mapping table. Optionally, the metadata storage area stored in the processor is obtained, and the status mapping table in the metadata storage area is identified. By traversing the records in the status mapping table, the occupancy status of the data storage area is read, and it is determined whether there is a continuous, idle memory space in the data storage area that meets the memory usage requirements.

[0363] In the shared memory method provided in this application embodiment, the data storage area consists of multiple memory pages, and the status mapping table contains multiple records. Each record is used to record the occupied state of a memory page. Reading the records in the status mapping table from the metadata storage area and determining whether there is a target memory space in the data storage area based on the records in the status mapping table includes: determining a preset number of memory pages requested by the memory request instruction; sequentially scanning each record from the initial position of the status mapping table; and determining that there is a target memory space in memory when a preset number of consecutive target records are scanned, wherein the target record indicates that the memory page is in an idle state.

[0364] It should be noted that the data storage area is divided into multiple allocation units of the same memory size, and each allocation unit is recorded as a memory page. For example, if the memory space of the data storage area is A bytes and the allocation unit is B bytes, then the data storage area contains A / B memory pages. The records in the status mapping table are also memory page records. Each memory page record is used to record the occupied status of a memory page. The number of memory page records in the status mapping table is the same as the number of memory pages in the data storage area.

[0365] Figure 6 This is a schematic diagram illustrating the relationship between the state mapping table and memory pages in the shared memory method according to embodiments of this application, such as... Figure 6 As shown, the data storage area is the dynamically allocated memory block area, and the metadata storage area includes the dynamically allocated memory mapping table area. The mapping table area divides the memory pages in the data storage area into the same number of records, and records these records as memory page records. All memory page records are combined into a status mapping table. There is a one-to-one correspondence between all memory page records in the status mapping table and all memory pages in the data storage area. Each memory page record represents the allocation status of the corresponding memory page, that is, whether the memory page is occupied.

[0366] Optionally, since the business data coordinated by the operating system requires the use of contiguous memory pages in the processor, it is first necessary to determine the preset number of memory pages in the memory request instruction. Since each memory page has the same memory space, the preset number of contiguous memory pages required can be calculated from the required memory space size, denoted as numb.

[0367] In an exemplary embodiment, after obtaining the state mapping table in the processor's metadata storage area, the memory page records are traversed from the index position in the state mapping table. The index position can be the starting position of the state mapping table. Starting from the starting position of the state mapping table, each memory page record in the state mapping table is queried in turn to determine whether there are consecutive memory page records with a free memory page value greater than or equal to numb. If there are memory page records that meet the above conditions, the existence of the target memory space in the processor is determined by the correspondence between memory page records and memory pages.

[0368] In the shared memory method provided in this application embodiment, after scanning each record sequentially from the initial position of the state mapping table, the method further includes: if all records in the state mapping table have been scanned and there is no consecutive preset number of target records, determining that there is no target memory space in memory.

[0369] Optionally, starting from the beginning of the state mapping table, the memory page records in the state mapping table are queried to determine whether there is a contiguous space with a number of memory pages greater than or equal to numb. If no contiguous free memory pages of a preset number are found after scanning the entire state mapping table, it indicates that there is no target memory space.

[0370] In the shared memory method provided in this application embodiment, the number of target records scanned is recorded by a counter. During the process of scanning each record sequentially from the initial position of the state mapping table, when a target record is currently scanned, the counter is incremented by one, and when a non-target record is currently scanned, the counter is cleared to zero. A non-target record indicates that the memory page is in an occupied state.

[0371] Optionally, the existence of a consecutive preset number of target records, i.e., the existence of a target memory space, can be determined by using the relationship between the counter value and the number of memory pages required. Optionally, the counter count is recorded as cntr. If a scanned memory page is empty, cntr is incremented by 1. If a scanned memory page is not empty, the accumulated number of consecutive, free memory pages cntr is cleared to zero, and the search for consecutive empty memory pages continues from the address after that memory page. This continues until cntr equals numb, indicating that consecutive, free memory pages that meet the memory requirements have been found. If cntr is less than numb after scanning the entire state mapping table, it indicates that the dynamic memory allocation has failed and the target memory space does not exist.

[0372] In the shared memory method provided in this application embodiment, when the initial position is the last position in the state mapping table, feeding back the address information of the target memory space to the sending end of the memory request instruction includes: determining the last scanned target record among a consecutive preset number of target records, and feeding back the starting address of the memory page indicated by the last scanned target record to the sending end.

[0373] Optionally, when scanning the state map, the scanning method can be selected to scan from the first position of the state map or to scan from the last position of the state map. When the scanning method is to scan from the last position of the state map, when the value cntr displayed by the counter is greater than or equal to the preset number numb, the starting address of the last memory page scanned is recorded, and the state of these memory pages is set to non-null in the memory page record. The starting address is used as the starting address of the entire contiguous memory page of this memory allocation instruction.

[0374] In one exemplary embodiment, the address is fed back to the operating system that issued the memory request instruction, and the operating system performs data writing operations on the memory based on the address information.

[0375] In the shared memory method provided in this application embodiment, the initial position is the first position in the state mapping table. Feeding back the address information of the target memory space to the sending end of the memory request instruction includes: determining the first scanned target record among a consecutive preset number of target records, and feeding back the starting address of the memory page indicated by the first scanned target record to the sending end.

[0376] Optionally, when the scanning method is to scan from the first position of the state map table, if the value cntr displayed by the counter is greater than or equal to the preset number numb, the address recorded in the first memory page scanned is taken as the starting address and sent to the operating system that issued the memory request instruction. The operating system then performs data writing operations on the memory based on the address information.

[0377] In the shared memory method provided in this application embodiment, during the process of sequentially scanning each record from the initial position of the state mapping table, the first target record among the scanned consecutive target records is stored by a preset variable.

[0378] Optionally, the preset variable refers to the variable in the state mapping table used to store the address information of the initial position, and is denoted as offset. When a free and contiguous memory page is scanned, the value cntr displayed by the counter is incremented by 1. If the value cntr displayed by the counter is greater than or equal to the preset number numb, the address information currently stored in offset is used as the address of the first target record.

[0379] In the shared memory method provided in this application embodiment, after reading the occupied state of the memory and determining whether there is a free target memory space in the memory based on the occupied state of the memory, the method further includes: releasing the lock on the memory when there is no free target memory space in the memory.

[0380] Optionally, after scanning the memory page records in the status map, if a predetermined number of contiguous, free memory pages are detected (i.e., the target memory space is not included), it indicates that there are not enough memory pages in the processor's memory for the operating system to use. The dynamic memory allocation fails, and the memory lock is released.

[0381] In the shared memory method provided in this application embodiment, the memory includes a metadata storage area and a data storage area. The data storage area is used to store business data, and the metadata storage area stores memory management information. Determining whether the memory is currently in a locked state includes: reading the memory management information stored in the metadata storage area; determining whether the memory management information contains preset information, wherein the preset information indicates that the memory is in a locked state; if the memory management information contains the preset information, determining that the memory is currently not in a locked state; if the memory management information does not contain the preset information, determining that the memory is currently in a locked state.

[0382] To determine whether the processor's memory is in a locked state, it is necessary to use the memory management information in the metadata storage area. Optionally, when obtaining the memory management information in the metadata storage area, it is necessary to determine whether the memory management information contains preset information, which is used to indicate whether the memory is in a locked state. If the memory management information does not contain the preset information, it indicates that the current memory is in an unlocked state, and vice versa.

[0383] In the shared memory method provided in this application embodiment, the memory management information includes a first field information and a second field information. The first field information is used to describe whether the memory is in a locked state, and the second field is used to describe whether the memory has been initialized. Before receiving the memory request instruction, the method further includes: initializing the first field information and the second field information stored in the data storage area.

[0384] Before the embedded system runs, the metadata storage area and data storage area in the processor need to be initialized. Optionally, the memory page records stored in the state mapping table in the metadata storage area should be initialized, and the memory management information should be initialized.

[0385] Optionally, the memory management information consists of a first field and a second field. The first field indicates whether the device is locked, and the second field indicates whether initialization is complete.

[0386] In the shared memory method provided in this application embodiment, updating the occupied state of memory includes: changing the state of the memory page corresponding to the target memory space recorded in the state mapping table to the occupied state.

[0387] Optionally, when the operating system needs to occupy the target memory space, by identifying the address information of multiple memory pages in the target memory space, and according to the correspondence between memory pages and memory page records, the memory page records in the state mapping table area of ​​the metadata storage area are updated, changing them from an unoccupied state to an occupied state. Further, the occupancy status of the processor's memory space is updated according to the data writing status of the operating system, that is, the target memory space is changed from an unoccupied state to an occupied state, and the locking operations performed before dynamically allocating memory are released.

[0388] Optionally, in response to the storage operation of the first operating system, the target data is stored in the target memory space, and the address information of the contiguous memory space is sent to the second operating system; the target data stored in the target memory space is sent to the second operating system in response to the retrieval instruction sent by the second operating system based on the address information.

[0389] Here, after successfully allocating memory, the first operating system requests the target memory space containing the target data to be transmitted and sends the address information of that target memory space to the second operating system, which works in conjunction with the first operating system, instructing the second operating system to retrieve the data. Optionally, after receiving the address information of the target memory space, the second operating system issues a data retrieval command, and the embedded system receives the command and sends the target data stored in the target memory space to the second operating system.

[0390] Through the above steps, the system receives a memory request instruction from the first operating system and performs a locking operation on the processor's memory. The memory request instruction is used to request and use the processor's memory. If the memory is successfully locked, the system reads the memory's occupied status and determines whether there is a free target memory space in the memory. The size of the target memory space is greater than or equal to the size of the memory requested by the memory request instruction. If the target memory space exists, the address information of the target memory space is fed back to the sender of the memory request instruction, the memory's occupied status is updated, and the memory lock is released. In response to the first operating system's storage operation, the target data is stored in the target memory space, and the address information of the contiguous memory space is sent to the second operating system. Finally, the system receives a fetch instruction from the second operating system based on the address information and sends the target data stored in the target memory space to the second operating system. This process solves the problems of low efficiency, poor flexibility, and excessive reliance on the operating system in shared memory among multiple kernels, achieving the effect of improving the flexibility and efficiency of shared memory while reducing dependence on the operating system.

[0391] In an exemplary embodiment, when the first operating system uses physical addresses to perform data read and write operations and the second operating system uses virtual addresses to perform data read and write operations, the second operating system converts the address information of the target memory space into a virtual address and uses the virtual address to access memory and read the target data from the target memory space.

[0392] When sending and receiving data using shared memory in inter-core communication, the addresses returned by dynamically allocated memory are used. However, different systems may use different address systems. For example, a real-time operating system (RTOS) is the first operating system, and a non-RTOS is the second operating system. In the ROS, shared memory can be accessed directly using physical addresses, while in the non-RTOS, physical addresses cannot be used directly. Therefore, mapped virtual addresses are required. After the second operating system receives the address information of the target memory space, it converts it using the address information offset, maps it to a virtual address, and performs operations based on the virtual address. Optionally, the shared memory virtual base address is vBase in the non-RTOS (assuming the actual physical address of the shared memory is 0x96000000); the shared memory physical base address is pBase in the ROS (i.e., 0x96000000).

[0393] In a non-real-time (RTO) operating system, dynamically allocated memory returns a virtual address, vData. In a RTO, Offset = vData – vBase. Data is sent from the RTO to the RTO, and the RTO accesses the dynamically allocated shared memory using the address pData = pBase + Offset. In a RTO, dynamically allocated memory returns a physical address, pData. In a RTO, Offset = pData – pBase. Data is sent from the RTO to the RTO, and the RTO accesses the dynamically allocated shared memory using the address vData = vBase + Offset.

[0394] In an exemplary embodiment, the memory includes a metadata storage area and a data storage area, which are similar to those in the previous embodiments and will not be described in detail here. Optionally, the metadata storage area stored in the processor is obtained, and the state mapping table in the metadata storage area is identified. Starting from the index position in the state mapping table, each memory page record is traversed, and each memory page record in the state mapping table is queried in turn to determine whether there are consecutive memory page records with a number of free memory pages greater than or equal to a preset number. If there are memory page records that meet the above conditions, the existence of a target memory space in the processor is determined by the correspondence between memory page records and memory pages.

[0395] This embodiment also provides a method for sharing memory, which includes: before the operating system issues a memory request instruction, in order to prevent multiple operating systems from requesting the processor's memory space at the same time and causing a conflict, a locking operation is required, and it is determined whether the locking is successful; if the determination result indicates that the dynamic memory request locking is successful, the number of contiguous memory pages to be allocated is calculated based on the memory size in the issued memory request instruction, and recorded as nmemb; if the determination result indicates that the lock request fails, the request is reissued after waiting for a period of time (which can be 100 microseconds) until the request is successful; if the number of lock request failures is greater than a preset number (the preset number can be three), the memory request is terminated.

[0396] In an exemplary embodiment, after successfully acquiring a lock, the processor's metadata storage area is initialized, and the last position of the state map table is recorded as offset. The required number of contiguous memory pages is calculated based on the memory space size requested in the memory request instruction and recorded as nmemb. A counter for recording the number of memory pages is set and recorded as cmemb. Then, the state map table of the processor's metadata storage area is retrieved, and the entire state map table is scanned starting from the offset position. By matching the memory page records stored in the state map table with the memory pages in the data storage area, a contiguous memory map is found. If the currently scanned memory page is occupied, the offset is set to offset - cmemb, and the accumulated data of consecutive empty memory pages cmemb in the counter is cleared to zero. The search for consecutive empty memory pages starts again from the new offset position. If the scanned memory page is empty, i.e., in an idle state, the counter value cmemb is incremented by 1, and offset is set to offset - 1. The search continues for the next memory page until cmemb equals nmemb, i.e., the counter data is equal to the required memory space size, indicating that consecutive memory pages that meet the requirements have been scanned.

[0397] In an exemplary embodiment, the memory pages that meet the requirements are marked as occupied in the corresponding state mapping table, the starting address of the last memory page found is used as the starting address of the entire contiguous memory pages dynamically allocated, the lock of the dynamically allocated memory is released, and the dynamic memory allocation is successful.

[0398] If the value of offset is less than 0 during the scanning of the entire state map, it indicates that there are no suitable memory pages available for the operating system to use, and the lock for dynamically allocated memory is released, resulting in the failure of this dynamic memory allocation.

[0399] Furthermore, if the space is insufficient after dynamic allocation, the size can be dynamically adjusted. An updated memory allocation instruction can be issued again, and a locking operation can be performed on the memory. If the locking is successful, if the memory space required by the updated memory allocation instruction is increased, it is checked whether the required memory space exists after the already allocated contiguous memory. If it exists, the allocation is successful. If the memory space required by the updated memory allocation instruction is decreased, some memory space is released.

[0400] This embodiment divides the memory into multiple storage areas, dynamically allocates space based on the actual required size using index positions, and releases the space after use. Furthermore, it can dynamically adjust the size of the allocated space if it is found to be insufficient, thereby improving the flexibility and efficiency of shared memory.

[0401] In one exemplary embodiment, the above method further includes at least one of the following:

[0402] S221, merge the processing resources of the second operating system that the first operating system has preempted into the available resource pool of the first operating system;

[0403] S222, merge the processing resources of the first operating system that the second operating system has preempted or the processing resources that the first operating system has actively released to the second operating system into the available resource pool of the second operating system.

[0404] In this embodiment, the scheduling of processing resources can be achieved by merging the corresponding processing resources into the available resource pool of the corresponding operating system. Correspondingly, in a scenario where the first operating system preempts the processing resources of the second operating system, if the preemption is successful, the processing resources of the second operating system preempted by the first operating system can be merged into the available resource pool of the first operating system. In scenarios where the second operating system preempts the processing resources of the first operating system, or where the first operating system actively releases processing resources to the second operating system, if the preemption or release is successful, the processing resources of the first operating system preempted by the second operating system or the processing resources actively released by the first operating system can be merged into the available resource pool of the first operating system.

[0405] For example, the resource adaptive scheduling module can work with the processor framework of the first operating system and the processor framework of the second operating system to configure and implement the processor hard core resource pool. For example, in the Linux system's SMP (Symmetrical Multi-Processing) framework, a group of processors (multiple CPUs) are brought together on a computer. The CPUs share the memory subsystem and bus structure. SMP scheduling is the process of arranging / migrating processes to suitable CPUs to maintain a balanced load on each CPU.

[0406] Taking Linux as an example, the CPU scheduling mechanism of an operating system is as follows: Tasks (i.e., business processes) in Linux are generally maintained by a task queue. The process scheduler determines which processes (corresponding to tasks) in the queue can be executed by the CPU. Simultaneously, the dispatcher module in Linux transfers CPU control to the process selected by the process scheduler. The selected CPUs come from the CPU resource pool in Linux (i.e., the aforementioned available resource pool), meaning that Linux can schedule these CPUs in the resource pool to participate in the actual execution of processes.

[0407] The process scheduler can suspend a running process and transfer it to the running queue to start another process. It determines which process in the ready queue and in main memory can be executed by the CPU (transferring CPU control to this process) after a clock interrupt, I / O (Input / Output) interrupt, system call, or other types of signals.

[0408] In this embodiment, by merging the scheduled processing resources into the available resource pool of the corresponding operating system, the scheduling of processing resources can be facilitated, thereby improving the efficiency of processing resource scheduling.

[0409] In one exemplary embodiment, the above method further includes:

[0410] S232, after the chip where the processor is located is powered on, the first operating system is booted and run on the first initial processing resource by the bootloader, and the second operating system is booted and run on the second initial processing resource by the bootloader. The first initial processing resource is the initial processing resource of the processor that corresponds to the first operating system, and the second initial processing resource is the initial processing resource of the processor that corresponds to the second operating system.

[0411] The entire system can be divided into two phases based on its operating time: the initial startup phase and the real-time operation phase. The aforementioned dynamic scheduling of processing resources is executed during the real-time operation phase. The initial startup phase begins with system power-on, specifically, the power-on of the chip containing the processor. After power-on, one core is awakened to execute the operating system boot process, while the remaining cores remain in a dormant state. Upon power-on, the system first executes a preset core scheduling policy (boot policy). This policy is executed by one core of the processor and is stored in the on-chip RAM or Norflash (non-volatile flash memory). This scheduling policy can be flexibly configured according to different design requirements. Its main functions include: specifying the initial processing resources required for different operating systems (e.g., specifying the initial cores required for the first and second operating systems), and determining the boot process for heterogeneous operating systems.

[0412] Of the processor's processing resources, the initial processing resource corresponding to the first operating system is called the first initial processing resource, and the initial processing resource corresponding to the second operating system is called the second initial processing resource. After the system is powered on, the first operating system can be booted and run on the first initial processing resource by a boot loader, and the second operating system can be booted and run on the second initial processing resource by a boot loader. Here, the boot loader, located on the computer or other computer application, refers to the program that boots the operating system.

[0413] Here, the chip can be a BMC (Baseboard Management Controller, a management and control chip in a server platform) chip, which refers to a SOC chip based on an ARM multi-core architecture that integrates various peripheral hardware IPs (Intelligent Peripherals). The BMC chip is placed on the motherboard (server motherboard), and chip power-on refers to power-on at the SOC chip level.

[0414] After the system powers on, a designated processor core can be woken up first. This core then uses a bootloader to guide the various operating systems to start on their respective initial processing resources. A bootloader is a program used to load the operating system; for example, it's a built-in program in the Bootrom (on-chip ROM) of the CPU. Built-in programs refer to the code that boots the operating system and belong to the BootLoader program.

[0415] In this embodiment, during the initial startup phase, the bootloader guides each operating system to start on the initial processing resources corresponding to each operating system, which can improve the success rate of operating system startup and prepare for the real-time operation phase.

[0416] In one exemplary embodiment, the first initial processing resource is a designated processor core among the processor cores of the processor, and the second initial processing resource is other processor cores among the processor cores of the processor besides the designated processor core.

[0417] In this embodiment, the initial processing resources may include initial processor cores. The first initial processing resource may be at least one processor core among the processor cores of the processor, and the second initial processing resource may be at least a portion of the other processor cores besides the first initial processing resource. Optionally, to ensure system startup efficiency, the first initial processing resource may be a designated processor core among the processor cores of the processor, while the second initial processing resource may be other processor cores besides the designated processor core.

[0418] For example, for an eight-core processor (CPU0 to CPU7), the specified processor core can be CPU0 (or another processor core). That is, the initial processing resources of the first operating system are CPU0, and the initial processing resources of the second operating system are CPU1 to CPU7.

[0419] In this embodiment, by specifying a particular processor core as the initial processing resource for one operating system, and using the other processor cores of the processor as the initial processing resource for another operating system, the ease of booting can be improved.

[0420] In one exemplary embodiment, booting a first operating system on a first initial processing resource via a bootloader includes:

[0421] S241, the first operating system is booted and run on the first initial processing resource via the secondary program loader.

[0422] In this embodiment, the operating system can be booted using a Second Program Loader (SPL). SPL is the code executed in the first stage of u-boot and can move the second-stage u-boot code into memory for execution. Its main responsibility is loading the operating system program code into RAM. Here, u-boot is a bootloader for embedded systems, primarily supporting various computer system architectures such as PPC, ARM, AVR32, MIPS, x86, 68k, Nios, and MicroBlaze.

[0423] In this embodiment, the corresponding operating system is booted and run on the initial processing resources through a secondary program loader, which is compatible with the existing system boot process and improves the efficiency of system boot.

[0424] In one exemplary embodiment, the above method further includes:

[0425] S251 performs a security boot check on the code of the secondary program loader using a preset program embedded in the boot chip on the device's motherboard. The secondary program loader is executed only after the security boot check result is normal.

[0426] Before using a secondary program loader to boot the operating system, in order to improve the success rate of the operating system boot, a preset program embedded in the boot chip on the device motherboard can perform a security boot check on the code of the secondary program loader to determine whether the secondary program loader is normal. If the result of the security boot check of the secondary program loader is normal, the operating system can be booted through the secondary program loader. If the result of the security boot check of the secondary program loader is abnormal, an error message will be displayed and the boot process of the operating system will be terminated.

[0427] For example, after the system is powered on, the inherent program in the core boot ROM of the configuration part performs a security boot check on the code in the SPL part through the boot ROM program (a set of programs embedded in the ROM chip on the device motherboard). If the check result is normal, the SPL code is executed.

[0428] This embodiment demonstrates how performing a security boot check on the secondary program loader can improve the security of operating system startup.

[0429] In one exemplary embodiment, booting a second operating system on a second initial processing resource via a bootloader includes:

[0430] S261, the second initial processing resource is awakened by the secondary program loader and the generic bootloader is executed to boot and run the second operating system.

[0431] When booting the second operating system, a secondary program loader can first wake up the second initial processing resources, and then execute a general loader to boot and run the second operating system. For example, SPL boots the first operating system on some cores (e.g., core 1, CPU0), while simultaneously waking up other cores (e.g., cores 2 to M+N, CPU1 to CPU M+N-1) to execute uboot code (a bootloader primarily used for embedded systems) to boot and run the second operating system. Through this stage, the Server Management Control Unit (BMC) system can achieve normal booting of both the first and second operating systems based on one or more processor cores, preparing for the real-time operation phase.

[0432] In this embodiment, by first waking up the initial processing resources and then guiding the execution of the general bootloader to boot and run the corresponding operating system, the efficiency of system booting and running can be improved.

[0433] The operation method of the embedded system in this embodiment will be explained below with reference to an optional example. In this optional example, the first operating system is an RTOS system, the second operating system is a Linux system (or other non-real-time operating systems), and the processing resource is the processor core.

[0434] To ensure the normal operation of various types of services in embedded systems, improve processor core utilization, and keep server hardware costs within a reasonable range, this optional example provides a method for dynamic balancing and scheduling of processor resources among embedded heterogeneous multi-systems. Based on multi-core processors, it schedules different service types to different core groups for execution according to a core adaptive scheduling (i.e., resource adaptive scheduling) method. Simultaneously, it incorporates system architecture designs such as service management, load balancing, dynamic resource allocation, and inter-core communication interfaces. This achieves the parallel operation of real-time and non-real-time embedded heterogeneous operating systems on multiple cores of the same processor, improving the overall utilization of processor cores and significantly reducing the investment in hardware acceleration resources required to handle real-time services. Furthermore, the multi-core processor utilizes a high-speed internal bus, greatly improving communication performance and achieving the goals of significantly reducing design costs and improving computational performance.

[0435] Taking the BMC management unit in a server platform (applicable to embedded products using multi-core SOCs, such as mobile phones, tablets, and set-top boxes) as an example, the operation method of the embedded system in this optional example can be divided into two stages: the initial startup stage and the real-time operation stage. See [link to relevant documentation]. Figure 7 The implementation architecture shown is for dynamic balancing scheduling of processor resources among embedded heterogeneous multi-systems. The CPU balancing scheduling process during the initial startup phase can be as follows: Figure 8 As shown, the above process may include the following steps:

[0436] Step S802: Configure some of the inherent programs in the core boot rom;

[0437] Step S804: The Bootrom program (i.e., the aforementioned inherent program) performs a secure boot check on the SPL (stored in Norflash). The secure boot check mainly involves hash verification of the uboot, Linux, and RTOS images to be booted. The result is compared with the stored result. If the comparison matches, the boot process proceeds normally; otherwise, the boot process fails. The SPL configures some CPU registers to select which cores to wake up and from which address to load the system image.

[0438] Step S806: Determine whether the security check has passed. If the security check has passed, proceed to step S808. If the security check has failed, proceed to step S810.

[0439] Step S808: Execute the SPL code. On the one hand, SPL boots and runs the RTOS system on some cores, and on the other hand, wakes up other cores to boot and execute uboot code, thereby booting and running the Linux system.

[0440] Step S810, End.

[0441] Once the heterogeneous operating system boots up, the system enters the real-time operation phase. (See also...) Figure 7 The real-time operation phase is completed collaboratively by functional modules such as load balancing strategies, business management, dynamic resource allocation, core adaptive scheduling (i.e., resource adaptive scheduling), core preemption and release, and inter-core communication. Combined with... Figure 7 and Figure 9 During the real-time operation phase, the process of running the embedded system in this optional example may include the following steps:

[0442] In step S902, the service management module performs the actual classification of the services to be allocated based on the output of the load balancing strategy module, and generates a list containing real-time services and a list containing non-real-time services.

[0443] The load balancing strategy module provides policy guidance to the service management module, including classification methods for various services (or processes) running in the system and principles for evaluating real-time performance levels. After the RTOS and Linux systems boot, the service management module, based on the output of the load balancing strategy module, performs the actual classification of services to be allocated, generating a list containing real-time services and a list containing non-real-time services. The two lists output by the load balancing strategy module represent the mapping between services and the operating system.

[0444] For BMC applications, to achieve robust and comprehensive management of the server platform, a large number of business processes need to run on the platform. In this case, the business management module needs to rationally categorize these business processes. One feasible categorization method is to classify services such as server health status monitoring, IPMI (Intelligent Platform Management Interface) interaction, component monitoring, serial port redirection, asset information management, and web access as non-real-time services; while classifying services such as fan control and PECI (Platform Environment Control Interface) communication as real-time services.

[0445] In step S904, the resource dynamic allocation module dynamically adjusts the processor resources (including processor hard cores and controller logic units, etc.) according to the output results of the service management module, forming a resource mapping table between different services and actual hardware resources.

[0446] The mapping table generated by the dynamic resource allocation module is a resource mapping table between services and processor resources. It includes processor resources already allocated to various operating systems, as well as processor resources not allocated to any operating system. When mapping services to actual hardware resources, priority is given to allocating processor cores from the RTOS system for real-time services. If all processor cores in the RTOS system are already allocated to one or more services, then unallocated processor cores are considered for real-time services. Similarly, processor cores from the Linux system are allocated for non-real-time services. If all processor cores in the Linux system are already allocated to one or more services, then unallocated processor cores are considered for real-time services. Therefore, there are situations where unallocated processor cores are allocated to either real-time or non-real-time services.

[0447] In practical applications, the hardware resources of the BMC, such as its processor cores and peripheral controllers, are dynamically mapped to the actual BMC business logic. For example, after the server boots up, core 1 in the BMC runs an RTOS system, controlling PWM (Pulse Width Modulation) and PECI peripheral controllers to implement fan speed control and fault diagnosis, while cores 2 through N run Linux systems to control I2C (Inter-Integrated Circuit) and other controllers to implement component monitoring. During system operation, a dynamic allocation table for BMC resources is dynamically generated based on system load and other factors, preparing for the next step of core adaptive scheduling.

[0448] Here, the output resource mapping table can be: X cores and xxx controllers (certain types of controllers) for real-time services, and Y cores and xxxx controllers (certain types of controllers) for non-real-time services. Some services not only rely on computing resources (corresponding to processor cores) but also on specific hardware interfaces (corresponding to controllers on the SOC). For example, services that require network interfaces need to be placed in the same operating system (RTOS system or Linux system) as the corresponding network controller.

[0449] In step S906, the core adaptive scheduling module completes the actual scheduling action of the processor hard core resources based on the result of dynamic allocation of hardware resources.

[0450] The core adaptive scheduling module performs actual scheduling of processor hard core resources based on the outputs of the business management module and the resource dynamic allocation module. For example, it schedules a portion of the processor hard cores to execute real-time tasks, such as... Figure 6 The core group 1 has M cores; the remaining processor hard cores are scheduled to run non-real-time tasks, such as... Figure 6The processor has N cores in core group 2. The entire scheduling process is led by the Linux system, specifically configured using Linux's SMP framework to manage the processor's hard core resource pool. Here, the total number of available processor cores is M+N, where M≥1 and N≥1.

[0451] In step S908, during the real-time operation of the system, the core preemption and release module dynamically preempts and releases the processor cores across heterogeneous operating systems.

[0452] The preemption and release process depends on the real-time load of the heterogeneous operating systems to maximize processor resource utilization. For example, when the number of users remotely accessing the BMC increases from 1 to 20, the web access traffic to the BMC surges, requiring more processor cores from the Linux system. In this situation, the Linux system will issue a core preemption request to the RTOS system via IPI. If the RTOS system is idle (i.e., no task scheduling), it will release core resources to the Linux system. At this point, the Linux system successfully preempts the core, gaining more processor resources to handle the increased business demands. This core preemption and release mechanism significantly improves the user experience for remote server management.

[0453] The core preemption and release process is a dynamic and iterative process. Each core preemption and release is accompanied by adjustments to the processor's hard core resources, such as... Figure 6 As shown, after one round of preemption and release, the number of cores in core group X becomes P, and the number of cores in core group Y becomes M+NP. Furthermore, the core preemption and release process requires coordination with load balancing strategies, business management, and core adaptive adjustment modules to jointly determine the final core adjustment result.

[0454] The aforementioned cycle refers to the continuous resource contention and release that occurs between the RTOS and Linux systems during normal operation, due to resource shortages on one side. This cyclical process involves the coordinated operation of modules such as "business management (a dynamically partitioned process), dynamic hardware resource allocation, and core adaptive scheduling." These modules all operate on a non-real-time system (Linux system), as most major business operations are performed on Linux, allowing for easier access to and awareness of more information and status updates.

[0455] The aforementioned multiple modules jointly determining the core adjustment outcome means that when a system needs to preempt more core resources, the success of the preemption depends on the combined efforts of modules such as load balancing strategies, business management, and core adaptive adjustment. For example, in one possible scenario, when the Linux system needs more resources, even though the RTOS system is currently in a dormant or idle state, it may be unable to release core resources to the Linux system because the RTOS system will soon need to wake up and run an important business thread that also requires significant resources. The resource scheduling process described above, involving criteria for judging business importance and the final decision not to allocate resources to the Linux system, all involve the participation of modules such as load balancing strategies, business management, and core adaptive adjustment. The open nature of each module's strategy means that the final core adjustment outcome, jointly determined by these modules, is a result of the combined effect of these strategies.

[0456] Here, the RTOS system does not occupy any CPU core resources after hibernation. When it is woken up (for example, by an interrupt generated by a peripheral or wake-up timer), it regains control of the specified core resource (e.g., core 0) through an inter-core interrupt. During the period from hibernation to regaining core control, the RTOS system does not require the participation of the core.

[0457] The following explanation uses an eight-core processor (cores 1 to 8) as an example to illustrate the dynamic resource balancing scheduling method among embedded heterogeneous multi-systems. It assumes that the real-time operating system (RTOS) and the non-real-time operating system (Linux) are respectively an RTOS system and a Linux system. The dynamic resource balancing scheduling process can include the following steps:

[0458] Step 1: Power on the system and run the preset boot strategy. Boot the RTOS system based on core 1 (CPU0) and the Linux system based on core 8 (CPU7).

[0459] Step 2: The Linux system's business management module classifies the system's business real-time performance based on the load balancing strategy module, and obtains a list of real-time and non-real-time services. Assume there are a total of 20 services, of which real-time services are services 1 and 2, and non-real-time services are services 3 to 20.

[0460] Step 3: Based on the service list output by the service management module, start the resource dynamic allocation module and the core adaptive scheduling module. Through the SMP framework of the Linux system, divide the 8 processor cores into processor core group 1 (assuming it contains cores 1 and 2) and core group 2 (assuming it contains cores 3 to 8). At this time, the system allocates the resources of core group 1 to the RTOS operating system to execute service 1 and service 2, and allocates the resources of core group 2 to the Linux system to execute service 3 to service 20.

[0461] Step 4: During system operation, both the RTOS and Linux operating systems monitor their respective load conditions. When one side's business load is too heavy, it will initiate a core preemption action through the inter-core communication interface. When the other side receives the core preemption request, it will determine whether to release hard core resources to the other side based on its own load conditions.

[0462] For example, if the Linux system detects a sharp increase in its own load at a certain moment, it will initiate a core preemption interrupt request to the RTOS system via the inter-core communication interface before exhausting its own computing resources (corresponding to the SGI interrupt with interrupt number 9 in Table 1). After receiving the core preemption interrupt request, the RTOS system checks the busy / idle status of its own cores. If it finds an idle core (e.g., core 2 is idle), it releases core 2 and sends a core release interrupt response signal to the Linux system via the inter-core communication interface (corresponding to the SGI interrupt with interrupt number 10 in Table 1). After receiving the interrupt response signal, the Linux system merges core 2 into the available resource pool through the SMP framework. At this point, the processor hard cores have undergone a new adjustment, that is, the RTOS system occupies core 1, and the remaining 7 cores are occupied by the Linux system.

[0463] Step 5: Update system load information and return to step 2.

[0464] Unlike multi-core single-system and multi-core fixed-system (each core running a specific operating system) approaches in related technologies, the method provided in this optional example dynamically allocates different hardware processor cores to real-time and non-real-time operating systems based on actual business needs. This achieves dynamic scheduling of processor resources among embedded heterogeneous multi-systems based on processor hard cores at the hardware and software system architecture level. Because processor hard cores are dynamically allocable, the heterogeneous operating systems coexisting in the system can obtain reasonable processor computing resources according to their own business load. This enhances the processor's ability to handle real-time business, comprehensively improves the utilization rate of processor cores, increases computing performance, and ultimately saves hardware costs.

[0465] In one optional application scenario, the following explanation illustrates the operation method of the embedded system in this embodiment, taking into account an application scenario where two operating systems alternately control the operating state of the same device (i.e., the target device). The processing system of the first operating system includes a first processor core, and the processing resources of the second operating system include a second processor core. In this embodiment, a startup control process for an operating system is provided, which includes the following steps:

[0466] Step A involves controlling the hardware controller of the target device via a second bus through a first operating system running on the first processor core of the processor, thereby controlling the operating status of the target device.

[0467] For devices such as servers, personal computers, and industrial control computers, specific devices can be configured to perform operations related to the device's operation. In related technologies, these specific devices typically begin working after the system is powered on. However, after the system powers on, the operating system running on the processor takes some time to take over the specific devices and control their operational status. During the operating system startup process, the specific devices are uncontrollable.

[0468] For example, the fan starts working after the system is powered on. However, the operating system running on the CPU takes some time to take over the fan and set its speed. Therefore, the fan is uncontrollable during the operating system startup process.

[0469] For example, in order to control the fan during the operating system startup process, the server uses a BMC combined with CPLD control, the personal computer uses an EC chip control (the EC chip adjusts the fan speed according to the temperature), and the industrial computer uses a custom chip control. During the startup process of the operating system of the server, personal computer, and industrial computer, the CPLD, EC chip, and custom chip will intervene to control the fan speed. After the operating system has fully started up, the control of the fan will be handed over to the application in the operating system.

[0470] To at least partially solve the above-mentioned technical problems, a multi-core, multi-system (e.g., multi-core dual-system) boot control method can be adopted, in which different operating systems of the embedded system run on different processor cores of the processor. Different operating systems have different response speeds. In cases where the second operating system fails to boot, restarts, or otherwise cannot control the operating state of a specific device, the first operating system, which has a higher response speed than the second operating system, can control the operating state of the specific device. This can reduce the uncontrollable situation of the operating state of the specific device. At the same time, it does not require additional costs and also has good scalability.

[0471] In this embodiment, when the second operating system is not started, restarted, or otherwise unable to control the operating state of the target device, the hardware controller of the target device can be controlled via the second bus through the first operating system to control the operating state of the target device. The target device here can be a fan, or other devices that need to run upon system startup. For a fan, the corresponding hardware controller is a fan controller, such as a PWM (Pulse Width Modulation) controller or a FanTach (fan speed) controller. Using the first operating system (e.g., an RTOS system) instead of traditional CPLDs, EC chips, or custom chips saves hardware costs and offers higher scalability since device control is implemented in software.

[0472] For example, a dual-system architecture based on a BMC dual-core, consisting of an RTOS system and a Linux system, can be implemented. A fan can be implemented based on a multi-core dual-system architecture. Taking advantage of the high real-time performance of the RTOS system, during the Linux system boot process, the RTOS system can replace the CPLD, EC chip, and custom chip to control the fan, that is, take over the fan control and control the fan's operating status at a sufficiently fast speed.

[0473] Step B boots the second operating system on the second processor core of the processor.

[0474] When the system powers on or the second operating system restarts, it can boot the second operating system from the second processor core, allowing the second operating system to run on the second processor core. Here, booting the second operating system from the second processor core means scheduling the second processor core to the second operating system. The operating system's system files or image files can be stored on the processor chip or in external memory, such as external RAM.

[0475] Step C: After the second operating system starts up, the second operating system takes over the hardware controller via the second bus to take control of the target device.

[0476] After the second operating system boots up, the first operating system can continue to control the operating state of the target device. However, considering the need for data interaction between multiple operating systems running on a multi-core processor, and to facilitate overall device control by a single operating system, the second operating system can also take over control of the target device. For example, the second operating system can take over the hardware controller via a second bus. The second operating system can take over control of the target device by sending a device takeover request to the first operating system after booting up, for example, by sending an interrupt request via the first bus, to request takeover of the target device's hardware controller. The first operating system can receive the device takeover request from the second operating system, transfer control of the target device to the second operating system, and perform operations related to the transfer of control, such as stopping the business (processes) used to control the operating state of the target device.

[0477] For example, after the Linux system has fully booted, the RTOS system transfers control of the fan to the Linux system, which then controls the fan. This process can be performed after the system powers on; that is, using a multi-core dual-system boot method, the RTOS system boots first to facilitate earlier intervention in fan control, and then the RTOS system transfers control of the fan to the Linux system after the Linux system has fully booted.

[0478] In one exemplary embodiment, before the first operating system running on the first processor core controls the hardware controller of the target device via the second bus, the method further includes: after the chip containing the processor is powered on, waking up the first processor core through the processor; and running a bootloader of the first operating system through the first processor core to boot the first operating system on the first processor core.

[0479] The entire system can be divided into two phases according to its working time: the initial startup phase and the real-time operation phase. The startup control method in this embodiment can be executed in either the initial startup phase or the real-time operation phase. For the initial startup phase, the initial startup phase begins when the system is powered on, that is, when the chip where the processor is located is powered on. After the system is powered on, one core will be woken up to execute the operating system's boot process, while the other cores are temporarily in a dormant state. The core that is woken up can be the first processor core.

[0480] Optionally, after power-on, the system will first execute a preset core scheduling policy (boot policy), that is, the core scheduling policy is executed by one of the processor cores. The core scheduling policy can be stored in the RAM or Norflash (non-volatile flash memory) on the SOC chip. The scheduling policy can be flexibly configured according to different design requirements. Its main functions include: specifying the initial processing resources (processor cores) required for different operating systems to run, and determining the boot process of heterogeneous operating systems. Chip power-on can refer to power-on at the SOC chip level.

[0481] After the first processor core wakes up, a first operating system can be booted and run on the first processor core via a bootloader. The first processor core can boot the first operating system from the first processor core via a bootloader. The bootloader program can reside on the computer or other computer applications; it refers to the program used to boot the operating system. For example, the built-in program in the BootROM refers to the code that boots the operating system and belongs to the Bootloader program. The BootROM is a small mask ROM (Read-Only Memory) or write-protected flash memory embedded within the processor chip on the CPU.

[0482] During the initial startup phase, booting the operating system onto the corresponding processor core via a bootloader can improve the success rate of the operating system startup and prepare it for the real-time operation phase.

[0483] In one exemplary embodiment, a first operating system running on a first processor core controls a hardware controller of a target device via a second bus, including: executing a first control task on the first processor core, wherein the first control task is used to control the hardware controller; reading sensor data of a designated sensor corresponding to the target device through the first processor core; and sending device control instructions to the hardware controller via the second bus based on the sensor data of the designated sensor through the first control task, so that the hardware controller controls the operating state of the target device according to the device control instructions.

[0484] The operating system controls the hardware controller of the target device through control tasks (services) executed on the processor core where the operating system runs. Here, "control task" refers to a specific control process. For the hardware controller of the target device, a first control task (first control process) of the first operating system can be executed on the first processor core, and this first control task controls the hardware controller.

[0485] Controlling the hardware controller can be based on sensor data. For different target devices, the parameters affecting their operation can differ, and correspondingly, the required sensor data can also vary. The target device can be one that operates immediately upon chip power-on, and its corresponding sensor is a designated sensor. The designated sensor can be of various types, including but not limited to at least one of the following: temperature sensor, humidity sensor, noise sensor, etc. Since the first control task runs on the first processor core, the sensor data of the designated sensor can be read through the first processor core. The sensor data of the designated sensor can be stored in the designated sensor's internal storage space, or transferred from the designated sensor to the designated storage space. In this embodiment, the location for reading the sensor data of the designated sensor is not limited.

[0486] The sensor data read from the specified sensor can be sensor data within a single time period, or all sensor data since the target device was started, or sensor data that meets other time constraints. After acquiring the sensor data from the specified sensor, the first control task can control the operating state of the target device based on the sensor data. Controlling the operating state of the target device can be achieved by the first control task sending device control commands to the hardware controller of the target device, so that the hardware controller can control the operating state of the target device according to the device control commands.

[0487] Optionally, the first control task can determine the expected operating state of the target device based on sensor data from a specified sensor. If the current operating state of the target device differs from the expected operating state, the aforementioned device control command can be generated to adjust the operating state of the target device to the expected operating state. The aforementioned device control command can be sent to the hardware controller of the target device via a second bus. The second bus is similar to that in the previous embodiments and will not be described in detail here.

[0488] By reading sensor data from designated sensors and controlling the target device based on this data, the operating status of the device is controlled, thereby improving resource utilization.

[0489] In one exemplary embodiment, sending a device control command to a hardware controller via a second bus based on sensor data from a specified sensor by a first control task includes: determining target parameter values ​​for device operating parameters of a target device based on sensor data from a specified sensor by the first control task, wherein the device operating parameters are parameters that control the operating state of the target device; and sending a device control command carrying the target parameter values ​​to the hardware controller via the second bus by the first control task.

[0490] The first control task is to determine the expected operating state of the target device based on sensor data from designated sensors. The expected operating state can be represented by the parameter values ​​of the device's operating parameters, which are parameters that control the operating state of the target device. Different types of devices may have different corresponding operating parameters. For example, for a fan, the corresponding operating parameter might be its rotational speed; for other types of devices, the operating parameters might be different. The expected operating state can correspond to the target parameter values ​​of the target device's operating parameters.

[0491] After determining the target parameter value of the device's operating parameters, the target parameter value can be carried in the aforementioned device control instruction. That is, the device control instruction carrying the target parameter value is sent to the hardware controller through the first control task. The method of sending the device control instruction to the hardware controller can be similar to that in the previous embodiment, and will not be described in detail here.

[0492] Determining the parameter values ​​of the target device's operating parameters based on sensor data and incorporating these values ​​into the device control commands can improve the accuracy of device control.

[0493] In one exemplary embodiment, determining the target parameter value of the device operating parameters of the target device based on sensor data of a specified sensor by a first control task includes: when the target device is a fan, determining the target parameter value of the fan operating parameters of the fan based on sensor data of a specified sensor by the first control task.

[0494] The target device can be a fan, specifically a fan used to cool the server or other equipment it resides in; that is, a cooling fan. In this case, the device operating parameters can be fan operating parameters, which may include one or more of the following, including but not limited to at least one of the following: rotation speed, rotation cycle, cycle switching time, and other operating parameters. This embodiment does not limit these parameters.

[0495] Correspondingly, the target parameter value for determining the device operating parameters of the target device based on sensor data from a specified sensor by the first control task can be: the target parameter value for determining the fan operating parameters by the first control task based on sensor data from a specified sensor. After obtaining the target parameter value, the first control task sends a device control command carrying the target parameter value to the fan's hardware controller via the second bus, thereby controlling the fan's operating status.

[0496] By controlling the operating status of the fan, the fan's operating status can be quickly controlled in scenarios such as system power-on, system restart, or other situations, improving the timeliness of fan control.

[0497] In an exemplary embodiment, when the target device is a fan, determining the target parameter value of the fan's operating parameters based on sensor data from a specified sensor via a first control task includes: when the target device is a fan and the specified sensor is a temperature sensor, determining the target speed value of the fan's rotational speed based on sensor data from the temperature sensor via the first control task, wherein the fan's rotational speed is positively correlated with the temperature detected by the temperature sensor.

[0498] In scenarios where the target device is a fan, the designated sensor can be a temperature sensor. There can be one or more temperature sensors, and their placement can be configured as needed; different temperature sensors can be placed in different locations. Optionally, the sensor data from the temperature sensor represents the temperature detected by the sensor. The first control task can then determine the target fan speed based on this sensor data. Here, the fan speed is positively correlated with the temperature detected by the temperature sensor.

[0499] When there are multiple temperature sensors, the highest temperature detected by all sensors can be determined based on the data from each sensor. The fan speed can then be determined based on this highest temperature, which ensures safer operation compared to determining the fan speed based on the average temperature detected by all sensors. Alternatively, for scenarios with multiple fans, the speed of each fan can be determined based on the highest or average temperature detected by the temperature sensor matched to each fan.

[0500] For example, a first operating system (e.g., an RTOS system) can be used to replace processing units such as CPLDs, EC chips, and custom chips to control fan speed (this can be real-time BMC fan control). When the system is powered on, the first processor core (e.g., CPU0, which can be hardware-activated) can be woken up. The first processor core runs a bootloader (e.g., a specified program in the BootROM), loads the first operating system, and reads various temperature-related sensor data to perform fan control (e.g., fan speed control), completely simulating the fan regulation function of the aforementioned processing units. During fan speed control, the first operating system can calculate PWM values ​​based on the temperature sensors, and then adjust the fan speed accordingly. In this way, the first operating system can control the fan speed during the startup of the second operating system.

[0501] In one exemplary embodiment, booting a second operating system on a second processor core of a processor includes: executing a secondary program loader through a first processor core to wake up the second processor core by the secondary program loader; and running a general boot loader for the second operating system through the second processor core to boot the second operating system on the first processor core.

[0502] In this embodiment, when the operating system is booted, a secondary program loader can be loaded into the internal memory, such as the static random access memory (SRAM) inside the SOC. The SPL can be responsible for loading the universal boot loader (U-Boot) into the random access memory. The secondary program loader can boot the second operating system and also boot the first operating system.

[0503] For the second operating system, a secondary program loader can be executed through the first processor core to wake up the second processor core. Through the second processor core, a generic boot loader (generic bootloader) for the second operating system can be run, thereby booting the second operating system on the first processor core. Here, the bootloader of the second operating system loads the boot program of the second operating system, which may include the generic bootloader.

[0504] It should be noted that the secondary program loader is the code executed in the first stage of the generic bootloader. It is responsible for moving the code from the second stage of the generic bootloader to system memory (also called off-chip memory) for execution. The generic bootloader is open-source software that follows the GPL (General Public License) license and can be regarded as a bare-metal synthesis routine.

[0505] For example, after the system is powered on, the processor will first wake up the CPU0 core so that the RTOS system can run as quickly as possible; then it will use the program in BootROM to boot the RTOS system; during the boot process of the RTOS system, it will continue to load U-Boot through SPL, and U-Boot will boot the second operating system on CPU1 until the Linux system boots normally.

[0506] It should be noted that the Boot ROM is a program embedded in the internal ROM of a chip (e.g., a SOC chip), and it is the boot code for uboot. The Boot ROM reads the hardware's boot information (e.g., DIP switch settings) and reads the uboot-spl code (i.e., SPL) from a specified boot medium (e.g., SD, MMC, etc.). The SPL is mainly responsible for initializing the external RAM and environment, and loading the actual uboot image into the external RAM for execution. The external RAM can be DDR (Double Data Rate Synchronous Dynamic Random Access Memory) or other types of RAM.

[0507] By waking up the second processor core through a secondary program loader, and then having the second processor core run a general bootloader to boot the second operating system on the corresponding processor core, the ease and success rate of operating system startup can be improved.

[0508] As an optional example, the boot process of a multi-core dual-system is explained below using RTOS and Linux systems as examples.

[0509] To take over fan management as quickly as possible, the RTOS system should be booted first. After the Linux system has booted up, the Linux system should take over fan control. The boot process of a multi-core dual-system may include the following steps:

[0510] Step 1: Wake up CPU0 when the system is powered on;

[0511] Step 2: CPU0 runs the specified program in BootROM to load the RTOS system and start it up;

[0512] Step 3: During the RTOS system startup process, wake up CPU1 to boot u-boot and start the fan control program (FanCtrl_RTOS_APP) in the first operating system;

[0513] Step 4: CPU1 booting u-boot may include the SPL stage and the Uboot stage. The SPL stage is entered by calling SPL.

[0514] Step 5: In the SPL stage, SPL boots U-Boot.

[0515] Step 6: During the U-boot stage, load the Linux kernel (CPU1~CPUN) and start the BMC business program and the fan control program (FanCtrl_Linux_APP) in the second operating system.

[0516] This optional example demonstrates how, during the dual-system boot and operation process, the RTOS system is first started to control the fan, and then the second operating system takes over control of the fan after the Linux system boots. This ensures rapid fan control upon system power-up and improves fan control efficiency.

[0517] In one exemplary embodiment, after the hardware controller is taken over by the second operating system via the second bus, the method further includes: if the second operating system is to be restarted, waking up the first operating system via the first bus through the second operating system, and having the first operating system take over the hardware controller via the second bus to take control of the target device; and controlling the second operating system to perform a system restart.

[0518] When a system crash or a reboot command is received, requiring a restart, the second operating system can first wake up the first operating system, which then takes over the hardware controller to control the target device. Waking up the first operating system can be performed via the first bus, and the first operating system taking over the hardware controller can be performed via the second bus.

[0519] When the second operating system restarts, the reliability of device control can be improved by waking up the first operating system to take over control of the target device.

[0520] In one exemplary embodiment, when the second operating system is to be restarted, waking up the first operating system via the first bus through the second operating system includes: when the second operating system is to be restarted, initiating a system wake-up interrupt to the first operating system via the first bus through the second operating system, wherein the system wake-up interrupt is used to wake up the first operating system.

[0521] The first operating system can be woken up via an inter-kernel interrupt. If the second operating system needs to be restarted (e.g., due to a system crash or receiving a reboot command), the second operating system can initiate a system wake-up interrupt to the first operating system to wake it up. This system wake-up interrupt can be an active wake-up interrupt. After the first operating system takes over the hardware controller, it can control the second operating system to perform a system restart. After the second operating system restarts, it can regain control of the hardware controller. The process of taking over the hardware controller is similar to that in the previous embodiments and will not be described in detail here.

[0522] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0523] According to another aspect of the embodiments of this application, an embedded system for implementing the above-described embedded system operation method is also provided. The embedded system can run on the BMC chip, wherein the embedded system may include:

[0524] The first operating system and the second operating system run on the processor, and the first operating system has a faster response speed than the second operating system.

[0525] The business management module is used to allocate a set of services to the corresponding operating system according to the dynamic resource allocation rules. The dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed and service resource utilization rate.

[0526] The resource dynamic allocation module is used to determine the resource allocation result corresponding to a group of services to be allocated. The resource allocation result is used to indicate the processing resources of the processor corresponding to each service to be allocated in the group of services to be allocated. The processing resources of the processor include processor cores.

[0527] The resource adaptive scheduling module is used to allocate the processor's processing resources to the first operating system and the second operating system according to the operating system corresponding to each service to be assigned and the resource allocation result.

[0528] In this embodiment, the first operating system and the second operating system can be similar to those in the previous embodiments, and will not be described in detail here. The business management module, the resource dynamic allocation module, and the resource adaptive scheduling module can be software modules running under the first operating system or the second operating system. By dividing the modules as described above, it is convenient to develop and maintain different functional modules. At the same time, for the resource dynamic allocation rules, the flexibility of resource allocation can be improved by flexibly setting the resource dynamic allocation rules.

[0529] The embedded system described above includes: a first operating system and a second operating system, both running on a processor, with the first operating system having a higher response speed than the second operating system; a service management module, used to allocate a set of pending services to the corresponding operating systems according to dynamic resource allocation rules, wherein the dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed, service resource occupancy rate; a dynamic resource allocation module, used to determine the resource allocation result corresponding to the set of pending services, wherein the resource allocation result indicates the processing resources of the processor corresponding to each pending service in the set of pending services, and the processor's processing resources include processor cores; and a resource adaptive scheduling module, used to allocate the processor's processing resources to the first and second operating systems according to the operating system corresponding to each pending service and the resource allocation result, thereby solving the problem of low overall utilization of core resources in related technologies due to most of the processing resources of multi-core processors being idle, and improving the utilization rate of processing resources.

[0530] In one exemplary embodiment, the embedded system further includes:

[0531] The load balancing strategy module is used to generate a rule structure by reading the rule configuration file. The rule structure is used to record the dynamic allocation rules of resources.

[0532] The load balancing strategy module in this embodiment is similar to that in the previous embodiments, and will not be described again here. Here, the load balancing strategy module can be a software module under the first operating system or the second operating system. By configuring the load balancing strategy to be stored in a separate software module, the load balancing strategy can be easily and flexibly adjusted.

[0533] In one exemplary embodiment, the load balancing strategy module is further used for

[0534] The rule update configuration file is obtained through the external interface of the second operating system. The rule update configuration file is used to update the configured dynamic resource allocation rules. The rule structure is updated using the rule update configuration file to update the dynamic resource allocation rules recorded in the rule structure.

[0535] In this embodiment, the resource dynamic allocation rules stored in the load balancing strategy module can be flexibly configured through the external interface of the second operating system. The configuration method is similar to that in the previous embodiment and will not be described in detail here.

[0536] In an exemplary embodiment, the service management module is configured to allocate a set of services to the corresponding operating system according to the allocation rules corresponding to the service response speed in the resource dynamic allocation rules by performing the following steps:

[0537] The service to be assigned from a set of pending services is assigned to the first operating system if the service response speed requirement is greater than or equal to the set response speed threshold, and the service to be assigned from a set of pending services is assigned to the second operating system if the service response speed requirement is less than the set response speed threshold.

[0538] In this embodiment, the way the business management module allocates pending businesses based on business response speed is similar to that in the previous embodiments, and will not be described again here.

[0539] In an exemplary embodiment, the service management module is configured to allocate a set of services to the corresponding operating system according to the allocation rules corresponding to the service resource utilization rate in the dynamic resource allocation rules by performing the following steps:

[0540] The service to be allocated from a group of pending services whose service resource utilization rate is less than the first utilization rate threshold is allocated to the first operating system, and the service to be allocated from a group of pending services whose service resource utilization rate is greater than or equal to the first utilization rate threshold is allocated to the second operating system.

[0541] In this embodiment, the way the business management module allocates pending businesses based on business resource occupancy is similar to that in the previous embodiments, and will not be described again here.

[0542] In one exemplary embodiment, the service management module is further configured to assign a set of services to be allocated to the corresponding operating system by performing at least one of the following steps:

[0543] The services to be assigned from a group of services to be assigned that have a service coupling degree with the already assigned services of the first operating system that is greater than or equal to a first coupling degree threshold are assigned to the first operating system.

[0544] The services to be assigned from a group of services to be assigned that have a service coupling degree with the already assigned services of the second operating system that is greater than or equal to the second coupling degree threshold are assigned to the second operating system.

[0545] In this embodiment, the way the business management module allocates the business to be assigned based on the degree of business coupling is similar to that in the previous embodiments, and will not be described again here.

[0546] In an exemplary embodiment, the service management module is further configured to assign a set of services to be allocated to the corresponding operating system by performing the following steps:

[0547] A set of pending business services containing sensitive information is assigned to a target operating system, wherein the target operating system is the operating system with low interaction frequency with the user among the first operating system and the second operating system.

[0548] In this embodiment, the way the service management module assigns services containing sensitive information to the first operating system is similar to that in the previous embodiments, and will not be described again here.

[0549] It should be noted that the business management module allocates pending services based on business response speed and business resource utilization based on the dynamic resource allocation rules stored in the load balancing strategy module. However, the allocation of pending services based on business coupling and business importance (e.g., whether it contains sensitive information) can be performed by the business management module based on its pre-configured information. Since the resource allocation rules based on business coupling and business importance are usually stable, while business response speed and business resource utilization can be flexibly configured based on requirements, storing the dynamic resource allocation rules based on at least one of business response speed and business resource utilization in a separate software module can balance the flexibility and simplicity of rule configuration.

[0550] In an exemplary embodiment, the resource dynamic allocation module is used to determine the resource allocation result corresponding to a set of services to be allocated by performing the following steps:

[0551] Based on the allocation results from the business management module, and combined with the resource utilization of the first operating system and the second operating system, a resource mapping table is generated that maps the services to be allocated to the processor's processing resources.

[0552] In this embodiment, the method by which the resource dynamic allocation module generates a resource mapping table of a set of services to be allocated and the processing resources of the processor is similar to that in the previous embodiments, and will not be repeated here.

[0553] In one exemplary embodiment, the resource dynamic allocation module allocates the processor's processing resources to the first operating system and the second operating system on a per-processor-core basis.

[0554] In an exemplary embodiment, the resource adaptive scheduling module is configured to allocate processor processing resources to a first operating system and a second operating system by performing the following steps:

[0555] If, based on the resource allocation results, it is determined that there are corresponding pending services among the unallocated processing resources of the processor, the unallocated processing resources are allocated to the operating system to which the pending service corresponding to the unallocated processing resources is allocated.

[0556] In this embodiment, the resource adaptive scheduling module allocates unallocated processing resources to the operating system in a similar manner to the previous embodiments, and will not be described again here.

[0557] In one exemplary embodiment, the embedded system further includes:

[0558] The resource preemption and release module is used to preempt and release processing resources between the first operating system and the second operating system.

[0559] In this embodiment, the resource preemption and release module handles resource preemption and release between different operating systems in a similar manner to the previous embodiments, and will not be described in detail here.

[0560] In one exemplary embodiment, the resource preemption and release module processes resource preemption and release between the first operating system and the second operating system through an inter-core communication interface.

[0561] In an exemplary embodiment, the resource preemption and release module is used to perform the following steps to preempt and release processing resources between the first operating system and the second operating system via the inter-core communication interface:

[0562] The first interaction request of the first operating system is transmitted to the second operating system through the inter-core communication interface. The first interaction request is used to request resource interaction with the second operating system. The resource interaction includes one of the following: resource preemption and resource release.

[0563] The first interaction response returned by the second operating system in response to the first interaction request is obtained through the inter-core communication interface. The first interaction response is used to instruct the first operating system to perform resource interaction with the second operating system based on the first interaction response.

[0564] In this embodiment, the resource preemption and release module interacts with the first and second operating systems through the inter-core communication interface in a manner similar to that in the previous embodiments, and will not be described in detail here.

[0565] In one exemplary embodiment, the embedded system further includes:

[0566] The first system control module is used to detect the resource utilization rate of the processing resources of the first operating system. If it is determined that the first operating system needs to interact with the second operating system based on the resource utilization rate of the processing resources of the first operating system, the resource preemption and release module is triggered to transmit the first interaction request to the second operating system through the inter-core communication interface.

[0567] In this embodiment, the method by which the first system control module triggers resource interaction based on the resource utilization rate of the first operating system's processing resources is similar to that in the previous embodiments, and will not be repeated here.

[0568] In an exemplary embodiment, the first system control module is further configured to perform at least one of the following steps: if the resource utilization rate of the processing resources of the first operating system is greater than or equal to a first utilization threshold, determine that the first operating system is to preempt the processing resources of the second operating system; if the processing resources of the first operating system are idle and there is no business to be executed by the first operating system, determine that the first operating system is to release the processing resources to the second operating system.

[0569] In this embodiment, the method by which the first system control module determines the type of resource interaction to be performed by the first operating system is similar to that in the previous embodiments, and will not be repeated here.

[0570] In an exemplary embodiment, the first system control module is further configured to control the first operating system to enter a hibernation state when there is no service scheduling and no service to be allocated to the first operating system.

[0571] In this embodiment, the method by which the first system control module controls the first operating system to enter a hibernation state is similar to that in the previous embodiments, and will not be described again here.

[0572] In an exemplary embodiment, the resource preemption and release module is configured to transmit a first interaction request from the first operating system to the second operating system via an inter-core communication interface by performing at least one of the following steps:

[0573] The first preemption request with the first interrupt number is transmitted to the second operating system through the inter-core communication interface. The first preemption request is used to request to preempt the processing resources of the second operating system.

[0574] The resource release request with interrupt number 2 is transmitted to the second operating system through the inter-core communication interface. The resource release request is used to request the release of the processing resources occupied by the first operating system to the second operating system.

[0575] In this embodiment, the resource preemption and release module interacts with resources through inter-core interrupts in a manner similar to that in the previous embodiments, and will not be described in detail here.

[0576] In an exemplary embodiment, the resource preemption and release module is used to perform the following steps to preempt and release processing resources between the first operating system and the second operating system via the inter-core communication interface:

[0577] The second interactive request from the second operating system is transmitted to the first operating system through the inter-core communication interface. The second interactive request is used to request the preemption of the processing resources of the first operating system.

[0578] The second interactive response returned by the first operating system in response to the second interactive request is obtained through the inter-core communication interface. The second interactive response is used to indicate whether the first operating system allows the second operating system to preempt the processing resources of the first operating system.

[0579] In this embodiment, the resource preemption and release module interacts with the first and second operating systems through the inter-core communication interface in a manner similar to that in the previous embodiments, and will not be described in detail here.

[0580] In one exemplary embodiment, the embedded system further includes:

[0581] The second system control module is used to detect the resource utilization rate of the processing resources of the second operating system. If it is determined that the second operating system is about to preempt the processing resources of the first operating system based on the resource utilization rate of the processing resources of the second operating system, the resource preemption and release module is triggered to transmit the second interaction request to the first operating system through the inter-core communication interface.

[0582] In this embodiment, the second system control module triggers resource interaction based on the resource utilization rate of the processing resources of the second operating system in a similar manner to that in the previous embodiment, and will not be described in detail here.

[0583] In one exemplary embodiment, the second system control module is further configured to perform at least one of the following steps:

[0584] If the current resource utilization rate of the processing resources of the second operating system is greater than or equal to the second utilization threshold, it is determined that the processing resources of the second operating system to be preempted are to be determined.

[0585] If the resource utilization rate of the processing resources of the second operating system is determined to be greater than or equal to the third utilization threshold based on the business being executed in the second operating system and the business to be executed in the second operating system, then the processing resources of the second operating system to be preempted are determined.

[0586] In this embodiment, the second system control module determines the resource interaction to be performed by the second operating system in a manner similar to that in the previous embodiments, and will not be described in detail here.

[0587] In an exemplary embodiment, the first operating system is further configured to: determine that the first operating system refuses the second operating system from preempting the processing resources of the first operating system if the service priority of the service being executed in the first operating system is not lower than the service priority of the service to be executed in the second operating system; and determine that the first operating system allows the second operating system to preempt the processing resources of the first operating system if the service priority of the service being executed in the first operating system is lower than the service priority of the service to be executed in the second operating system.

[0588] In this embodiment, the embedded system determines whether the first operating system allows the second operating system to use its processing resources in a similar way to the previous embodiments, and will not be described again here.

[0589] In an exemplary embodiment, the resource preemption and release module is configured to transmit a second interaction request from the second operating system to the first operating system via the inter-core communication interface by performing the following steps:

[0590] The second preemption request with the third interrupt number is transmitted to the first operating system through the inter-core communication interface. The second preemption request is used to request to preempt the processing resources of the first operating system.

[0591] In this embodiment, the resource preemption and release module interacts with resources through inter-core interrupts in a manner similar to that in the previous embodiments, and will not be described in detail here.

[0592] In an exemplary embodiment, the resource preemption and release module is configured to obtain a second interactive response returned by the first operating system in response to the second interactive request through the inter-core communication interface by performing at least one of the following steps:

[0593] The resource release enable response with interrupt number 4 is transmitted to the second operating system through the inter-core communication interface. The resource release enable response is used to instruct the first operating system to allow the second operating system to preempt the processing resources of the first operating system.

[0594] The resource release rejection response with interrupt number 5 is transmitted to the second operating system through the inter-core communication interface. The resource release rejection response is used to instruct the first operating system to refuse the second operating system from preempting the processing resources of the first operating system.

[0595] In this embodiment, the resource preemption and release module interacts with resources through inter-core interrupts in a manner similar to that in the previous embodiments, and will not be described in detail here.

[0596] In one exemplary embodiment, the resource adaptive scheduling module is further configured to perform at least one of the following steps: merging the processing resources of the second operating system preempted by the first operating system into the available resource pool of the first operating system; merging the processing resources of the first operating system preempted by the second operating system or the processing resources actively released by the first operating system to the second operating system into the available resource pool of the second operating system.

[0597] In this embodiment, the resource adaptive scheduling module handles resource scheduling between different operating systems in a similar manner to the previous embodiments, and will not be described in detail here.

[0598] In one exemplary embodiment, the embedded system further includes:

[0599] The system startup module is used to boot and run a first operating system on a first initial processing resource and a second operating system on a second initial processing resource after the chip where the processor is located is powered on. The first initial processing resource is the initial processing resource of the processor that corresponds to the first operating system, and the second initial processing resource is the initial processing resource of the processor that corresponds to the second operating system.

[0600] In this embodiment, the system startup module boots and runs each operating system on the corresponding initial processing resources through the bootloader in a similar manner to the previous embodiments, and will not be described in detail here.

[0601] In one exemplary embodiment, the first initial processing resource is a designated processor core among the processor cores of the processor, and the second initial processing resource is other processor cores among the processor cores of the processor besides the designated processor core.

[0602] In an exemplary embodiment, the system startup module is configured to boot and run a first operating system on a first initial processing resource by performing the following steps:

[0603] The first operating system is booted and run on the first initial processing resource by a secondary program loader.

[0604] In this embodiment, the system startup module guides the operating system to run on the initial processing resources through a secondary program loader in a similar manner to the previous embodiments, and will not be described in detail here.

[0605] In one exemplary embodiment, the system startup module is further configured to perform a security startup check on the code of the secondary program loader using a preset program embedded in a startup chip on the device motherboard, wherein the secondary program loader is executed after the security startup check result is normal.

[0606] In this embodiment, the system startup module performs a security startup check on the code of the secondary program loader in a similar manner to that in the previous embodiments, and will not be described in detail here.

[0607] In one exemplary embodiment, the system startup module is configured to boot and run a second operating system on a second initial processing resource by performing the following steps:

[0608] The secondary program loader awakens the second initial processing resource and guides the execution of the generic bootloader to boot and run the second operating system.

[0609] In this embodiment, the system startup module boots the second operating system through a secondary program loader in a manner similar to that in the previous embodiments, and will not be described in detail here.

[0610] According to another aspect of the embodiments of this application, an embedded system for implementing the above-described embedded system operation method is also provided. The embedded system can run on the BMC chip, wherein the embedded system may include:

[0611] The first operating system and the second operating system run on the processor, and the first operating system has a faster response speed than the second operating system.

[0612] The business management module is used to allocate a set of services to the corresponding operating system according to the dynamic resource allocation rules. The dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed and service resource utilization rate.

[0613] The resource dynamic allocation module is used to determine the resource allocation result corresponding to a group of services to be allocated. The resource allocation result is used to indicate the processing resources of the processor corresponding to each service to be allocated in the group of services to be allocated. The processing resources of the processor include processor cores.

[0614] The resource adaptive scheduling module is used to allocate the processor's processing resources to the first operating system and the second operating system according to the operating system corresponding to each service to be assigned and the resource allocation result.

[0615] In this embodiment, the first operating system and the second operating system can be similar to those in the previous embodiments, and will not be described in detail here. The business management module, the resource dynamic allocation module, and the resource adaptive scheduling module can be software modules running under the first operating system or the second operating system. By dividing the modules as described above, it is convenient to develop and maintain different functional modules. At the same time, for the resource dynamic allocation rules, the flexibility of resource allocation can be improved by flexibly setting the resource dynamic allocation rules.

[0616] The embedded system described above includes: a first operating system and a second operating system, both running on a processor, with the first operating system having a higher response speed than the second operating system; a service management module, used to allocate a set of pending services to the corresponding operating systems according to dynamic resource allocation rules, wherein the dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed, service resource occupancy rate; a dynamic resource allocation module, used to determine the resource allocation result corresponding to the set of pending services, wherein the resource allocation result indicates the processing resources of the processor corresponding to each pending service in the set of pending services, and the processor's processing resources include processor cores; and a resource adaptive scheduling module, used to allocate the processor's processing resources to the first and second operating systems according to the operating system corresponding to each pending service and the resource allocation result, thereby solving the problem of low overall utilization of core resources in related technologies due to most of the processing resources of multi-core processors being idle, and improving the utilization rate of processing resources.

[0617] In one exemplary embodiment, the embedded system further includes:

[0618] The load balancing strategy module is used to generate a rule structure by reading the rule configuration file. The rule structure is used to record the dynamic allocation rules of resources.

[0619] The load balancing strategy module in this embodiment is similar to that in the previous embodiments, and will not be described again here. Here, the load balancing strategy module can be a software module under the first operating system or the second operating system. By configuring the load balancing strategy to be stored in a separate software module, the load balancing strategy can be easily and flexibly adjusted.

[0620] In one exemplary embodiment, the load balancing strategy module is further used for

[0621] The rule update configuration file is obtained through the external interface of the second operating system. The rule update configuration file is used to update the configured dynamic resource allocation rules. The rule structure is updated using the rule update configuration file to update the dynamic resource allocation rules recorded in the rule structure.

[0622] In this embodiment, the resource dynamic allocation rules stored in the load balancing strategy module can be flexibly configured through the external interface of the second operating system. The configuration method is similar to that in the previous embodiment and will not be described in detail here.

[0623] In an exemplary embodiment, the service management module is configured to allocate a set of services to the corresponding operating system according to the allocation rules corresponding to the service response speed in the resource dynamic allocation rules by performing the following steps:

[0624] The service to be assigned from a set of pending services is assigned to the first operating system if the service response speed requirement is greater than or equal to the set response speed threshold, and the service to be assigned from a set of pending services is assigned to the second operating system if the service response speed requirement is less than the set response speed threshold.

[0625] In this embodiment, the way the business management module allocates pending businesses based on business response speed is similar to that in the previous embodiments, and will not be described again here.

[0626] In an exemplary embodiment, the service management module is configured to allocate a set of services to the corresponding operating system according to the allocation rules corresponding to the service resource utilization rate in the dynamic resource allocation rules by performing the following steps:

[0627] The service to be allocated from a group of pending services whose service resource utilization rate is less than the first utilization rate threshold is allocated to the first operating system, and the service to be allocated from a group of pending services whose service resource utilization rate is greater than or equal to the first utilization rate threshold is allocated to the second operating system.

[0628] In this embodiment, the way the business management module allocates pending businesses based on...

Claims

1. An embedded system, characterized in that, include: A first operating system and a second operating system, both running on the processor, wherein the first operating system has a higher response speed than the second operating system; The business management module is used to allocate a set of services to the corresponding operating system according to the dynamic resource allocation rules, wherein the dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed, service resource utilization rate; A resource dynamic allocation module is used to determine the resource allocation result corresponding to the group of services to be allocated, wherein the resource allocation result is used to indicate the processing resources of the processor corresponding to each service to be allocated in the group of services to be allocated, and the processing resources of the processor include processor cores. The resource adaptive scheduling module is used to allocate the processing resources of the processor to the first operating system and the second operating system according to the service allocation result and the resource allocation result, wherein the service allocation result is used to indicate the operating system to which each of the group of services to be allocated is allocated, and the resource allocation result is used to indicate one or more processor cores to which each of the group of services to be allocated is allocated. The business management module is further configured to allocate the group of pending services to the corresponding operating system according to the allocation rule corresponding to the service response speed in the resource dynamic allocation rule by performing at least one of the following steps: allocating pending services in the group of pending services with a service response speed requirement greater than or equal to a set response speed threshold to the first operating system, and allocating pending services in the group of pending services with a service response speed requirement less than the set response speed threshold to the second operating system; allocating pending services in the group of pending services with a service resource occupancy rate less than a first occupancy rate threshold to the first operating system, and allocating pending services in the group of pending services with a resource occupancy rate greater than or equal to the first occupancy rate threshold to the second operating system; allocating pending services in the group of pending services containing sensitive information to the target operating system, wherein the target operating system is the operating system with a low frequency of interaction with the user among the first operating system and the second operating system; When multiple of the above steps apply, the business management module is configured to determine the implementation steps based on rule selection conditions, including configuration time and priority.

2. The embedded system according to claim 1, characterized in that, The embedded system also includes: The load balancing strategy module is used to generate a rule structure by reading the rule configuration file, wherein the rule structure is used to record the dynamic allocation rules of the resources.

3. The embedded system according to claim 2, characterized in that, The load balancing strategy module is further configured to obtain a rule update configuration file through the external interface of the second operating system, wherein the rule update configuration file is used to update the configured dynamic resource allocation rules; and to update the rule structure using the rule update configuration file to update the dynamic resource allocation rules recorded in the rule structure.

4. The embedded system according to claim 1, characterized in that, The service management module is also configured to assign the set of services to be assigned to the corresponding operating system by performing at least one of the following steps: The services to be allocated from the group of services to be allocated that have a service coupling degree greater than or equal to the first coupling degree threshold with the already allocated services of the first operating system are allocated to the first operating system. The services to be allocated from the group of services to be allocated that have a service coupling degree with the already allocated services of the second operating system that is greater than or equal to the second coupling degree threshold are allocated to the second operating system.

5. The embedded system according to claim 1, characterized in that, The dynamic resource allocation module is used to determine the resource allocation result corresponding to the group of services to be allocated by performing the following steps: Based on the allocation results of the business management module, and combined with the resource utilization of the processing resources of the first operating system and the second operating system, a resource mapping table between the set of services to be allocated and the processing resources of the processor is generated.

6. The embedded system according to claim 1, characterized in that, The resource dynamic allocation module allocates the processor's processing resources to the first operating system and the second operating system on a per-processor-core basis.

7. The embedded system according to claim 1, characterized in that, The resource adaptive scheduling module is used to allocate the processor's processing resources to the first operating system and the second operating system based on the service allocation result and the resource allocation result by performing the following steps: If, based on the resource allocation result, it is determined that there is a corresponding pending service among the unallocated processing resources of the processor, the unallocated processing resources are allocated to the operating system to which the pending service corresponding to the unallocated processing resources is allocated.

8. The embedded system according to claim 1, characterized in that, The embedded system also includes: The resource preemption and release module is used to preempt and release processing resources between the first operating system and the second operating system.

9. The embedded system according to claim 8, characterized in that, The resource preemption and release module processes resource preemption and release between the first operating system and the second operating system through the inter-core communication interface.

10. The embedded system according to claim 9, characterized in that, The resource preemption and release module is used to perform the following steps to preempt and release processing resources between the first operating system and the second operating system via the inter-core communication interface: The first interaction request of the first operating system is transmitted to the second operating system through the inter-core communication interface. The first interaction request is used to request resource interaction with the second operating system. The resource interaction includes one of the following: resource preemption and resource release. The first interaction response returned by the second operating system in response to the first interaction request is obtained through the inter-core communication interface, wherein the first interaction response is used to instruct the first operating system to perform the resource interaction with the second operating system according to the first interaction response.

11. The embedded system according to claim 10, characterized in that, The embedded system also includes: The first system control module is used to detect the resource utilization rate of the processing resources of the first operating system. If it is determined that the first operating system needs to perform the resource interaction with the second operating system based on the resource utilization rate of the processing resources of the first operating system, the resource preemption and release module is triggered to transmit the first interaction request to the second operating system through the inter-core communication interface.

12. The embedded system according to claim 11, characterized in that, The first system control module is further configured to perform at least one of the following steps: when the resource utilization rate of the processing resources of the first operating system is greater than or equal to a first utilization rate threshold, determine that the first operating system is to preempt the processing resources of the second operating system; If the processing resources of the first operating system are idle and there are no services to be executed by the first operating system, it is determined that the processing resources of the first operating system should be released to the second operating system.

13. The embedded system according to claim 11, characterized in that, The first system control module is also used to control the first operating system to enter a hibernation state when there is no service scheduling and no service to be allocated to the first operating system.

14. The embedded system according to claim 10, characterized in that, The resource preemption and release module is used to transmit a first interaction request from the first operating system to the second operating system through the inter-core communication interface by performing at least one of the following steps: The first preemption request with the first interrupt number is transmitted to the second operating system through the inter-core communication interface, wherein the first preemption request is used to request to preempt the processing resources of the second operating system. The resource release request with interrupt number 2 is transmitted to the second operating system through the inter-core communication interface. The resource release request is used to request the release of the processing resources occupied by the first operating system to the second operating system.

15. The embedded system according to claim 9, characterized in that, The resource preemption and release module is used to perform the following steps to preempt and release processing resources between the first operating system and the second operating system via the inter-core communication interface: The second interaction request of the second operating system is transmitted to the first operating system through the inter-core communication interface, wherein the second interaction request is used to request to preempt the processing resources of the first operating system; The second interactive response returned by the first operating system in response to the second interactive request is obtained through the inter-core communication interface. The second interactive response is used to indicate whether the first operating system allows the second operating system to preempt the processing resources of the first operating system.

16. The embedded system according to claim 15, characterized in that, The embedded system also includes: The second system control module is used to detect the resource utilization rate of the processing resources of the second operating system. If it is determined that the second operating system is about to preempt the processing resources of the first operating system based on the resource utilization rate of the processing resources of the second operating system, the resource preemption and release module is triggered to transmit the second interaction request to the first operating system through the inter-core communication interface.

17. The embedded system according to claim 16, characterized in that, The second system control module is also configured to perform at least one of the following steps: If the current resource utilization rate of the processing resources of the second operating system is greater than or equal to the second utilization threshold, it is determined that the second operating system is to preempt the processing resources of the first operating system. If, based on the services being executed in the second operating system and the services to be executed in the second operating system, it is determined that the resource utilization rate of the processing resources of the second operating system is greater than or equal to a third utilization threshold, then it is determined that the second operating system is to preempt the processing resources of the first operating system.

18. The embedded system according to claim 17, characterized in that, The embedded system is further configured to determine, when the service priority of the service being executed in the first operating system is not lower than the service priority of the service to be executed in the second operating system, that the first operating system refuses the second operating system from preempting the processing resources of the first operating system. If the service priority of a business being executed in the first operating system is lower than the service priority of a business to be executed in the second operating system, then the first operating system is allowed to preempt the processing resources of the first operating system.

19. The embedded system according to claim 15, characterized in that, The resource preemption and release module is used to transmit the second interactive request from the second operating system to the first operating system through the inter-core communication interface by performing the following steps: The second preemption request with the third interrupt number is transmitted to the first operating system through the inter-core communication interface, wherein the second preemption request is used to request to preempt the processing resources of the first operating system.

20. The embedded system according to claim 15, characterized in that, The resource preemption and release module is used to obtain a second interactive response returned by the first operating system in response to the second interactive request through the inter-core communication interface by performing at least one of the following steps: The resource release permission response with interrupt number 4 is transmitted to the second operating system through the inter-core communication interface. The resource release permission response is used to instruct the first operating system to allow the second operating system to preempt the processing resources of the first operating system. The resource release rejection response with interrupt number 5 is transmitted to the second operating system through the inter-core communication interface. The resource release rejection response is used to instruct the first operating system to refuse the second operating system from preempting the processing resources of the first operating system.

21. The embedded system according to claim 8, characterized in that, The resource adaptive scheduling module is further configured to perform at least one of the following steps: merging the processing resources of the second operating system preempted by the first operating system into the available resource pool of the first operating system; merging the processing resources of the first operating system preempted by the second operating system or the processing resources actively released by the first operating system to the second operating system into the available resource pool of the second operating system.

22. The embedded system according to any one of claims 1 to 21, characterized in that, The embedded system also includes: The system startup module is used to boot and run the first operating system on a first initial processing resource via a bootloader after the chip where the processor is located is powered on, and to boot and run the second operating system on a second initial processing resource via the bootloader, wherein the first initial processing resource is the initial processing resource of the processor corresponding to the first operating system, and the second initial processing resource is the initial processing resource of the processor corresponding to the second operating system.

23. The embedded system according to claim 22, characterized in that, The first initial processing resource is a designated processor core among the processor cores of the processor, and the second initial processing resource is other processor cores among the processor cores of the processor besides the designated processor core.

24. The embedded system according to claim 22, characterized in that, The system startup module is used to boot and run the first operating system on the first initial processing resource by performing the following steps: The first operating system is booted and run on the first initial processing resource by a secondary program loader.

25. The embedded system according to claim 24, characterized in that, The system startup module is also used to perform a security startup check on the code of the secondary program loader by means of a preset program embedded in the startup chip on the device motherboard, wherein the secondary program loader is executed after the security startup check result is normal.

26. The embedded system according to claim 24, characterized in that, The system startup module is used to boot and run the second operating system on the second initial processing resource by performing the following steps: The second initial processing resource is awakened by the secondary program loader, and a general bootloader is executed to boot and run the second operating system.

27. A method for operating an embedded system, characterized in that, include: A set of services to be allocated is assigned to the corresponding operating system in the embedded system according to the dynamic resource allocation rules. The dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed, service resource utilization rate, service coupling degree, and service importance. The embedded system includes a first operating system and a second operating system, which run on a processor. The response speed of the first operating system is higher than that of the second operating system. Determine the resource allocation result corresponding to the group of services to be allocated, wherein the resource allocation result is used to indicate the processing resources of the processor corresponding to each service to be allocated in the group of services to be allocated, and the processing resources of the processor include processor cores; Based on the service allocation result and the resource allocation result, the processing resources of the processor are allocated to the first operating system and the second operating system, wherein the service allocation result is used to indicate the operating system to which each of the group of services to be allocated is assigned, and the resource allocation result is used to indicate one or more processor cores to which each of the group of services to be allocated is assigned. The step of allocating a set of pending services to the corresponding operating system in the embedded system according to the dynamic resource allocation rules includes at least one of the following: allocating pending services in the set of pending services with a service response speed requirement greater than or equal to a set response speed threshold to the first operating system; and allocating pending services in the set of pending services with a service response speed requirement less than the set response speed threshold to the second operating system; allocating pending services in the set of pending services with a service resource occupancy rate less than a first occupancy rate threshold to the first operating system; and allocating pending services in the set of pending services with a resource occupancy rate greater than or equal to the first occupancy rate threshold to the second operating system; and allocating pending services containing sensitive information in the set of pending services to a target operating system, wherein the target operating system is the operating system with a low frequency of interaction with the user among the first operating system and the second operating system. The step of allocating a set of services to be allocated to the corresponding operating system in the embedded system according to the dynamic resource allocation rules further includes: when multiple of the above steps are applicable, determining the implementation steps according to the rule selection conditions, wherein the rule selection conditions include configuration time and priority.

28. The method according to claim 27, characterized in that, The method further includes: By reading the rule configuration file, a rule structure is generated, wherein the rule structure is used to record the dynamic allocation rules of the resources.

29. The method according to claim 27, characterized in that, The step of allocating a set of services to be allocated according to the dynamic resource allocation rules to the corresponding operating system in the embedded system includes at least one of the following: The services to be allocated from the group of services to be allocated that have a service coupling degree greater than or equal to the first coupling degree threshold with the already allocated services of the first operating system are allocated to the first operating system. The services to be allocated from the group of services to be allocated that have a service coupling degree with the already allocated services of the second operating system that is greater than or equal to the second coupling degree threshold are allocated to the second operating system.

30. The method according to claim 27, characterized in that, The determination of the resource allocation result corresponding to the set of services to be allocated includes: Based on the allocation results of the set of services to be allocated, and combined with the resource utilization of the processing resources of the first operating system and the processing resources of the second operating system, a resource mapping table between the set of services to be allocated and the processing resources of the processor is generated.

31. The method according to claim 27, characterized in that, The step of allocating the processor's processing resources to the first operating system and the second operating system based on the service allocation result and the resource allocation result includes: If, based on the resource allocation result, it is determined that there is a corresponding pending service among the unallocated processing resources of the processor, the unallocated processing resources are allocated to the operating system to which the pending service corresponding to the unallocated processing resources is allocated.

32. The method according to claim 27, characterized in that, The method further includes: The preemption and release of processing resources are performed between the first operating system and the second operating system through the inter-core communication interface.

33. The method according to claim 32, characterized in that, The preemption and release of processing resources between the first operating system and the second operating system via the inter-core communication interface includes: The first interaction request of the first operating system is transmitted to the second operating system through the inter-core communication interface. The first interaction request is used to request resource interaction with the second operating system. The resource interaction includes one of the following: resource preemption and resource release. The first interaction response returned by the second operating system in response to the first interaction request is obtained through the inter-core communication interface, wherein the first interaction response is used to instruct the first operating system to perform the resource interaction with the second operating system according to the first interaction response.

34. The method according to claim 32, characterized in that, The preemption and release of processing resources between the first operating system and the second operating system via the inter-core communication interface includes: The second interaction request of the second operating system is transmitted to the first operating system through the inter-core communication interface, wherein the second interaction request is used to request to preempt the processing resources of the first operating system; The second interactive response returned by the first operating system in response to the second interactive request is obtained through the inter-core communication interface. The second interactive response is used to indicate whether the first operating system allows the second operating system to preempt the processing resources of the first operating system.

35. The method according to claim 34, characterized in that, The method further includes: Detect the resource utilization rate of the processing resources of the second operating system; If, based on the resource utilization rate of the second operating system's processing resources, it is determined that the second operating system is to preempt the processing resources of the first operating system, the second interaction request is transmitted to the first operating system through the inter-core communication interface.

36. The method according to claim 35, characterized in that, The method further includes at least one of the following: If the current resource utilization rate of the processing resources of the second operating system is greater than or equal to the second utilization threshold, it is determined that the second operating system is to preempt the processing resources of the first operating system. If, based on the services being executed in the second operating system and the services to be executed in the second operating system, it is determined that the resource utilization rate of the processing resources of the second operating system is greater than or equal to a third utilization threshold, then it is determined that the second operating system is to preempt the processing resources of the first operating system.

37. The method according to claim 36, characterized in that, The method further includes: If the service priority of the pending business in the first operating system is not lower than the service priority of the pending business in the second operating system, it is determined that the first operating system refuses the second operating system from preempting the processing resources of the first operating system. If the service priority of the pending business in the first operating system is lower than that in the second operating system, it is determined that the first operating system allows the second operating system to preempt the processing resources of the first operating system.

38. The method according to any one of claims 27 to 37, characterized in that, The method further includes: After the chip containing the processor is powered on, the first operating system is booted and run on the first initial processing resource by a bootloader, and the second operating system is booted and run on the second initial processing resource by the bootloader. The first initial processing resource is the initial processing resource of the processor that corresponds to the first operating system, and the second initial processing resource is the initial processing resource of the processor that corresponds to the second operating system.

39. An operating device for an embedded system, characterized in that, include: The first allocation unit is used to allocate a set of services to the corresponding operating system in the embedded system according to the dynamic resource allocation rules. The dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed, service resource occupancy rate, service coupling degree, and service importance. The embedded system includes a first operating system and a second operating system. The first operating system and the second operating system run on the processor. The response speed of the first operating system is higher than that of the second operating system. The first determining unit is used to determine the resource allocation result corresponding to the group of services to be allocated, wherein the resource allocation result is used to indicate the processing resources of the processor corresponding to each service to be allocated in the group of services to be allocated, and the processing resources of the processor include processor cores. The second allocation unit is used to allocate the processing resources of the processor to the first operating system and the second operating system according to the service allocation result and the resource allocation result, wherein the service allocation result is used to indicate the operating system to which each of the group of services to be allocated is allocated, and the resource allocation result is used to indicate one or more processor cores to which each of the group of services to be allocated is allocated. The first allocation unit further includes at least one of the following: a first allocation module, configured to allocate services in the group of services to be allocated that have a service response speed requirement greater than or equal to a set response speed threshold to the first operating system, and to allocate services in the group of services to be allocated that have a service response speed requirement less than the set response speed threshold to the second operating system; a second allocation module, configured to allocate services in the group of services to be allocated that have a service resource utilization rate less than a first utilization rate threshold to the first operating system, and to allocate services in the group of services to be allocated that have a resource utilization rate greater than or equal to the first utilization rate threshold to the second operating system; and a third allocation module, configured to allocate services in the group of services to be allocated that contain sensitive information to a target operating system, wherein the target operating system is the operating system with a low frequency of interaction with the user among the first operating system and the second operating system. The first allocation unit is further configured to determine the implementation steps according to the rule selection conditions when multiple of the above steps are applicable, and the rule selection conditions include configuration time and priority.

40. A chip, characterized in that, The chip includes at least one of programmable logic circuitry and executable instructions, and the chip operates in an electronic device for implementing the method of any one of claims 27 to 38.

41. A BMC chip, characterized in that, include: A storage unit and a processing unit connected to the storage unit, the storage unit being used to store a program, and the processing unit being used to run the program to perform the method as described in any one of claims 27 to 38.

42. A motherboard, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as described in any one of claims 27 to 38.

43. A server, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 27 to 38.

44. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 27 to 38.

45. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 27 to 38.

Images