Embedded system operation method and device, embedded system and chip

Abstract

This application discloses an operating method and apparatus for an embedded system, an embedded system, and a chip. The method includes the step of allocating a group of services to be allocated to a corresponding operating system in the embedded system according to a resource dynamic allocation rule, where the resource dynamic allocation rule includes performing resource dynamic allocation according to at least one of 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, and the response speed of the first operating system is higher than that of the second operating system; the step of determining a resource allocation result corresponding to a group of services to be allocated, where the resource allocation result is used to indicate the processing resources corresponding to each service to be allocated in a group of services to be allocated among the processing resources of a processor including processor cores; and the step of allocating 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.

Description

[Technical Field]

[0001] FIELD OF THE INVENTION The present application relates to the field of computers, and more particularly to methods and apparatus for operating embedded systems, embedded systems and chips. [Background technology]

[0002] With the rapid development of the semiconductor industry and integrated circuit technology, multi-core processors have become important computing units in multiple fields. In application scenarios where response time is critical, the multi-core processor can handle services that are not response time-sensitive, while the acceleration hardware handles services that are response time-sensitive. However, this service processing method results in many of the multi-core processor's processing resources (e.g., core resources) remaining idle, resulting in low overall utilization of the processing resources. Summary of the Invention [Problem to be solved by the invention]

[0003] The embodiments of the present application provide an embedded system operating method and apparatus, an embedded system, and a chip for solving at least a problem in the related art in which many processing resources of a multi-core processor are idle, resulting in low overall utilization of the processing resources. [Means for solving the problem]

[0004] According to one aspect of an embodiment of the present application, there is provided a method for operating an embedded system, comprising the steps of: allocating a group of allocation target services to corresponding operating systems of the embedded system in accordance with a dynamic resource allocation rule, wherein the dynamic resource allocation rule includes performing dynamic resource allocation according to at least one of a service response speed, a service resource occupancy rate, a service coupling degree, and a service importance, the embedded system including a first operating system and a second operating system running on a processor, the response speed of the first operating system being higher than that of the second operating system; determining a resource allocation result corresponding to the group of allocation target services, wherein the resource allocation result is used to indicate processing resources of the processor including a processor core, corresponding to each allocation target service in the group of allocation target services; and allocating processing resources of the processor to the first operating system and the second operating system in accordance with the operating systems corresponding to each allocation target service and the resource allocation result.

[0005] According to another aspect of the present application, there is further provided an embedded system including: a first operating system and a second operating system running on a processor, wherein the response speed of the first operating system is higher than that of the second operating system; a service management module that allocates a group of allocation target services to corresponding operating systems in accordance with a resource dynamic allocation rule including performing dynamic resource allocation according to at least one of a service response speed and a service resource occupancy rate; a resource dynamic allocation module that determines a resource allocation result corresponding to the group of allocation target services, wherein the resource allocation result is used to indicate a processing resource corresponding to each allocation target service in the group of allocation target services out of processing resources of the processor including processor cores; and a resource adaptive scheduling module that allocates the processing resources of the processor to the first operating system and the second operating system in accordance with the operating systems corresponding to each allocation target service and the resource allocation result.

[0006] According to another aspect of the present application, there is further provided an embedded system including a chip and at least two operating systems, wherein the chip includes a processor, a hardware controller, a first bus set in a multi-master multi-slave mode, and a second bus set in a single-master multi-slave mode, wherein the bandwidth of the first bus is higher than the bandwidth of the second bus, the at least two operating systems operate based on the processor, processing resources of the processor including a processor core are dynamically allocated to the at least two operating systems, the at least two operating systems communicate via the first bus, and the at least two operating systems exercise control over the hardware controller via the second bus.

[0007] According to another aspect of the present application, there is further provided an operating device for an embedded system, including: a first allocation unit that allocates a group of allocation target services to corresponding operating systems of the embedded system in accordance with a dynamic resource allocation rule, the dynamic resource allocation rule including performing dynamic resource allocation according to at least one of a service response speed, a service resource occupancy rate, a service coupling rate, and a service importance, the embedded system including a first operating system and a second operating system running on a processor, the response speed of the first operating system being higher than that of the second operating system; a first determination unit that determines a resource allocation result corresponding to the group of allocation target services, the resource allocation result being used to indicate a processing resource corresponding to each allocation target service in the group of allocation target services out of processing resources of the processor including a processor core; and a second allocation unit that allocates processing resources of the processor to the first operating system and the second operating system in accordance with the operating systems corresponding to each allocation target service and the resource allocation result.

[0008] According to another aspect of the present application, there is further provided a chip comprising at least one of a programmable logic circuit and executable instructions, the chip operating in an electronic device and performing the steps of any one of the method embodiments described above. According to another aspect of the present application, there is further provided a BMC chip including memory cells that store a program and a processing unit connected to the memory cells, the processing unit running the program to implement the steps in any one of the method embodiments described above.

[0009] According to another aspect of the present application, there is further provided a motherboard including at least one processor and at least one memory 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 implements the steps in any one of the method embodiments described above.

[0010] According to another aspect of the present application, there is further provided a server including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus, the memory stores a computer program, and the processor executes the program stored in the memory to implement the steps in any one of the method embodiments described above.

[0011] According to another aspect of the present application, there is further provided a computer-readable storage medium having stored thereon a computer program, the computer program being configured, when run, to perform the steps of any one of the method embodiments described above. According to another aspect of the present application, there is further provided an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform steps in any one of the method embodiments described above. [Effects of the Invention]

[0012] In an embodiment of the present application, a method for running different operating systems of an embedded system on different processing resources of a processor includes the steps of: allocating a group of allocation target services to corresponding operating systems of the embedded system according to a dynamic resource allocation rule, the dynamic resource allocation rule including performing dynamic resource allocation according to at least one of a service response speed, a service resource occupancy rate, a service coupling degree, and a service importance, the embedded system including a first operating system and a second operating system running on the processor, the response speed of the first operating system being higher than that of the second operating system; determining a resource allocation result corresponding to the group of allocation target services, the resource allocation result being used to indicate a processing resource corresponding to each allocation target service in the group of allocation target services among the processing resources of the processor including the processor cores; and determining an operating system corresponding to each allocation target service. and allocating the processing resources of the processor to the first operating system and the second operating system according to the rating system and the resource allocation result. In an embedded system where at least two operating systems run on the processor and the response speeds of the different operating systems are different, the operating systems can be used to run services that have different requirements for response speed. Based on the resource dynamic allocation rule, the processing resources of the processor can be dynamically allocated to the different operating systems and the processing resources according to the correspondence between the services to be run and the operating systems and the correspondence between the services to be run and the processing resources. With the above service execution method, there is no need to add additional acceleration hardware. Furthermore, since all services are executed by the processing resources within the processor, in addition to the services originally executed by the processor,By additionally processing the services performed by the acceleration hardware, the purpose of increasing the amount of services processed by the processor can be achieved, and the technical effect of increasing the utilization rate of processing resources can be achieved, thereby solving the problem existing in the related art that many of the processing resources of a multi-core processor are idle, resulting in low overall utilization rate of core resources. [Brief explanation of the drawings]

[0013] The drawings herein are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application, and together with the specification serve to explain the principles of the present application. In order to more clearly explain the technical solutions in the embodiments of the present application or related art, the drawings that need to be used in describing the embodiments or related art will be briefly described below, and obviously, those skilled in the art can also derive other drawings from these drawings without paying creative labor. [Figure 1] 1 is a schematic diagram of a hardware environment of an embedded system operating method according to an embodiment of the present application; [Figure 2] 1 is a schematic flow chart of a method of operating a selective embedded system according to an embodiment of the present application; [Figure 3] 1 is a schematic diagram of a method of operation of a selective embedded system according to an embodiment of the present application. [Figure 4] 1 is a schematic diagram of another selective embedded system operation method according to an embodiment of the present application. [Figure 5] 1 is a schematic diagram of another alternative method of operation of an embedded system according to an embodiment of the present application. [Figure 6] 1 is a schematic diagram of another alternative method of operation of an embedded system according to an embodiment of the present application. [Figure 7] 1 is a schematic diagram of another alternative method of operation of an embedded system according to an embodiment of the present application. [Figure 8] 1 is a schematic flow chart of another selective embedded system operation method according to an embodiment of the present application; [Figure 9]1 is a schematic flow chart of another alternative method of operation of an embedded system according to an embodiment of the present application. [Figure 10] FIG. 1 is a schematic diagram of a selective embedding system according to an embodiment of the present application. [Figure 11] FIG. 2 is a schematic diagram of another selective embedding system according to an embodiment of the present application. [Figure 12] FIG. 2 is a block diagram of the architecture of an operating device for a selective embedded system according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0014] In order to help those skilled in the art understand the solution of the present application better, the technical solutions in the embodiments of the present application will be described below clearly and completely with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments that those skilled in the art can obtain without paying creative labor should fall within the scope of protection of the present application.

[0015] In addition, terms such as "first," "second," etc. in the specification and claims of this application and the above drawings are not necessarily used to describe a particular order or sequence, but are used to distinguish between similar objects. It should be understood that the data used in this application may be interchanged as appropriate so that the embodiments of this application described herein may be performed in an order other than that illustrated or described herein. It should also be understood that the terms "comprise" and "have," and any variations thereof, are intended to be non-exclusively inclusive. For example, a procedure, method, system, product, or apparatus comprising a series of steps or units need not be limited to the explicitly recited steps or units, but may further include other steps or units inherent in the procedure, method, product, or apparatus.

[0016] The method embodiments provided in the present application may be executed in a server, a computer terminal, a device terminal, or a similar computing device. Taking the example of operating on a server, FIG. 1 is a schematic diagram of a hardware environment for the embedded system operating method according to the present application. As shown in FIG. 1, the server may include one or more processors 102 (only one of which is shown in FIG. 1 ) (the processor 102 may include, but is not limited to, a processing unit such as a microprocessor MCU or a programmable logic device FPGA) and memory 104 for storing data. 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 appreciate that the structure shown in FIG. 1 is merely schematic and does not limit the structure of the server. For example, the server may further include more or fewer components than those shown in FIG. 1, or may have a different configuration with the same or more functions than those shown in FIG. 1.

[0017] The memory 104 may be used to store computer programs, such as software programs and modules of application software, such as computer programs corresponding to the operation methods of the embedded system in the embodiments of the present application. The processor 102 executes various functional applications and data processing, i.e., realizes the above-described methods, by running the computer programs stored in the memory 104. The memory 104 may include high-speed random 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 examples, the memory 104 may also include memory located remotely from the processor 102, which may be connected to a server via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0018] The transmission device 106 receives or transmits data via a network. A specific example of the network may include a wireless network provided by a carrier of the server. In one example, the transmission device 106 includes a network interface controller (NIC) that can communicate with the Internet by connecting to other network devices via a base station. In one example, the transmission device 106 may be a radio frequency (RF) module that communicates with the Internet wirelessly.

[0019] In this embodiment, an operating method of an embedded system applied to the above-mentioned server is provided. FIG. 2 is a schematic flowchart of an operating method of an optional embedded system according to an embodiment of the present application. As shown in FIG. 2, the flow includes steps S202, S204, and S206. In step S20, the group of allocation target services is allocated to the corresponding operating systems of the embedded system according to the resource dynamic allocation rule.

[0020] The method for operating an embedded system in this embodiment can be applied to a scenario in which a service runs on the processing resources of a processor and dynamically balances the scheduling of the processing resources. The embedded system may be an embedded multi-system, which refers to multiple operating systems (e.g., a first operating system, a second operating system, etc.) running on a multi-core processor of the embedded system. These operating systems run simultaneously in the same embedded system. The multiple operating systems may be the same type of operating system or different types of operating systems, such as heterogeneous operating systems (different types of operating systems with different architectures). The execution of the service on the processor may be performed in parallel using the processing resources of multiple cores of the processor. The processor may be a multi-core processor, such as an 8-core processor, or a processor with another number of cores. This embodiment does not limit the number of cores included in the multi-core processor.

[0021] 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). In order to realize the sharing of hardware computing resources, virtualization technology can be introduced to improve the utilization rate of multi-core processors, that is, multiple virtual machines are virtualized based on the processor hardware platform, and each virtual machine runs an independent operating system.

[0022] However, virtual machine-based operating systems generally cannot meet the real-time requirements of services due to the increased overhead of virtual machine management, etc. Therefore, in application scenarios that are sensitive to response speed (related to the real-time requirements of services), it is common to run the operating system directly on a physical machine, and using such a "bare metal" processor can significantly reduce service processing delays. In various industrial fields where embedded systems are developed (e.g., servers, Internet of Things, etc.), to realize increasingly demanding system management functions, the services supported therein are similarly divided based on the overall consideration of the different degrees of response speed requirements (real-time requirements), and different hardware implementation platforms are allocated to different service types. For example, complex and diverse non-real-time services are executed by a multi-core processor CPU (Central Processing Unit, the calculation and control core of a computer system; the CPU is the final execution unit for information processing and program operation), while services with high response speed requirements are implemented by dedicated acceleration hardware. Acceleration hardware herein includes, but is not limited to, FPGA (Field Programmable Gate Array), CPLD (Complex Programmable Logic Device), or ASIC (Application Specific Integrated Circuit) chips.

[0023] However, in embedded systems, solutions that use multi-core processors and acceleration hardware typically run only a single type of operating system on all of the processor's processing resources (e.g., processor cores), and many of the processing resources are idle most of the time, resulting in low overall utilization of the processing resources. Common embedded products (e.g., mobile phones, tablets) typically run operating systems (e.g., Android, iOS, Windows) on multiple cores, and in most cases, the CPU core load occupancy rate is less than 30% (CPU capacity is usually excessive). The CPU operates according to time slices and is idle when not occupied. Furthermore, in order to support some response-time-sensitive services, the use of acceleration hardware resources such as FPGAs / CPLDs is increased, which is detrimental to cost control.

[0024] To at least partially solve the above technical problems, this embodiment uses a method of running different operating systems of an embedded system on different processing resources of a processor, where the different operating systems can be used to execute services with different response speeds and different requirements for the response speed, and allocates the services to be executed by the processor to the different operating systems and the different processing resources based on a dynamic resource allocation rule. In this way, the processing resources of the processor can be dynamically allocated to the different operating systems based on the correspondence between the services to be executed and the operating systems and the correspondence between the services to be executed and the processing resources. This service execution method does not require additional acceleration hardware, making it easy to control costs. Furthermore, because all services are executed by the processing resources within the processor, by additionally processing services originally executed by the acceleration hardware in addition to the services originally executed by the processor, the amount of services processed by the processor can be increased, thereby improving the overall utilization rate of the processing resources.

[0025] In this embodiment, the embedded system includes a first operating system and a second operating system, the first operating system having a higher response speed than the second operating system, the first operating system and the second operating system running on a processor, i.e., running on different processing resources of the processor, the processing resources of the processor may include at least one of the processing resources of the first operating system (the processing resources scheduled for the first operating system), the processing resources of the second operating system (the processing resources scheduled for the second operating system), and unallocated processing resources, where the processor may be a multi-core processor (e.g., an 8-core processor), and the processing resources of the processor (i.e., the processor resources) may include processor cores (processor cores) and may also include other types of resources, such as a controller logic unit, an external interface, a bus resource, etc.

[0026] During the operation of the processor, a group of target services, i.e., services to be assigned to the first operating system and the second operating system, can be obtained. Because different target services may have differences in response speed, service resource occupancy, service coupling with other services, service importance, etc., dynamic resource allocation rules need to be pre-established. The dynamic resource allocation rules may include rules for service allocation, so that services can be assigned to corresponding operating systems and the processing resources of the corresponding operating systems can execute the assigned services. Optionally, the dynamic resource allocation rules may include dynamic resource allocation according to at least one of service response speed, service resource occupancy, service coupling, and service importance. Different allocation rules may have corresponding priorities, for example, the priorities are service importance, service coupling, service response speed, and service resource occupancy, in descending order. According to the dynamic resource allocation rules, a group of target services (or target tasks; different target services correspond to different processes) can be assigned to corresponding operating systems in the embedded system to obtain a service allocation result.

[0027] Alternatively, the first operating system may be an operating system with a clearly fixed time constraint based on response time constraints, where all processing procedures (task scheduling) must be completed within the fixed time constraints, otherwise an error will occur in the system. It may be a real-time operating system (RTOS) such as FreeRTOS or RTLinux (registered trademark), or a real-time operating system for other embedded systems. The second operating system does not have this characteristic. It generally has a fair task scheduling algorithm, requires CPU time sharing as the number of threads / processes increases, and has uncertainty in task debugging. It can be called a non-real-time operating system, such as Contiki, HeliOS, or Linux (registered trademark) (collectively known as GNU / Linux, a freely propagating Unix-like operating system), or may be a non-real-time operating system for other embedded systems. The Linux system is an operating system that supports multi-user, multi-tasking, multi-threading, and multi-CPU based on the POSIX (Portable Operating System Interface).

[0028] Correspondingly, the services assigned to the first operating system are typically real-time services, which refer to services that need to be scheduled within a certain time frame and require a processor to process them at a sufficiently fast speed so that the processing results can be used to control production procedures or respond quickly to a processing system within a certain time frame. A typical scenario in industrial control is the control of a robot arm, which requires the system to take timely action before detecting an incorrect operation of the robot arm, otherwise serious consequences may occur. The services assigned to the second operating system are typically non-real-time services, which refer to services that are not sensitive to scheduling time and can tolerate a certain degree of scheduling delay, such as reading sensor data from a temperature sensor in a server.

[0029] A real-time operating system is an operating system that can receive external events or data when they occur, process them at a sufficiently fast speed, and control the production procedure or processing system within a predetermined time using the processing results, schedule all available resources to complete real-time services, and control all real-time services to work in a coordinated manner. The operating system has the characteristics of timely response and high reliability.

[0030] Optionally, the step of allocating the group of target services to corresponding operating systems may be performed by a service management module, which is a software module running on the first operating system or the second operating system, as shown in Figure 3. For example, the service management module running on the second operating system can be implemented by software in a Linux system. The service management module can allocate the group of target services to corresponding operating systems of the embedded system according to the resource dynamic allocation rule.

[0031] In step S204, a resource allocation result corresponding to the group of allocation target services is determined, and the resource allocation result is used to indicate the processing resources of the processor corresponding to each allocation target service in the group of allocation target services. After each target service is assigned to a corresponding operating system, processing resources corresponding to each target service are assigned according to the service assignment result, thereby obtaining a resource assignment result corresponding to one group of target services. When assigning processing resources to the target services, the processing resources of the first operating system can be assigned for the service assigned to the first operating system, and the processing resources of the second operating system can be assigned for the service assigned to the second operating system. At the same time, in consideration of load balance, if there are unallocated processing resources, the unallocated processing resources can be assigned to some of the services.

[0032] The processing resources of the processor can be dynamically allocated in units of time slices, and considering that the operating systems to which the processing resources belong are frequently switched and the service processing time is not necessarily an integer multiple of the time slice, which results in a long response time for some services, the processing resources can be allocated to the first operating system and the second operating system in units of processor cores, i.e., the processor cores of the processor are allocated to the corresponding operating systems in units of the entire processor core, the number of processor cores allocated to each operating system is an integer, and the processor cores allocated to different operating systems are different from each other.

[0033] Optionally, determining the resource allocation results corresponding to a group of allocation target services may be performed by a dynamic resource allocation module. As shown in FIG. 3, the dynamic resource allocation module may be a software module running on the first operating system or the second operating system. For example, when running on the second operating system, the dynamic resource allocation module is implemented by a software module in the second operating system, and can dynamically allocate processing resources to services according to the output of the service management module. The software module may be a program module with pre-defined functions. For example, the dynamic resource allocation module may be a program module with dynamic resource allocation functions, and the service management module may be a program module with service management functions. Each type of software module can be laid out and adjusted as a whole and can be applied to different application processes.

[0034] In step S206, the processing resources of the processor are allocated 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. The processing resources of the processor can be allocated 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. Unallocated processing resources of the processor can be selectively allocated to the corresponding operating system, and the unallocated processing resources may be determined based on the correspondence between the unallocated processing resources and the service to be allocated and the correspondence between the service to be allocated and the operating system.

[0035] Optionally, allocating the processor's processing resources to the first operating system and the second operating system may be performed by a resource adaptive scheduling module (e.g., a core adaptive scheduling module), which may be a software module running on the first operating system or the second operating system. For example, the resource adaptive scheduling module may be implemented by software in a Linux system, and may complete the actual scheduling operation for the processor's processing resources (e.g., processor hard core resources) according to the output of the service management module and the output of the resource dynamic allocation module. As shown in Figure 4, through resource scheduling by the core resource adaptive module, M cores of the (M+N) cores are scheduled to the real-time operating system, and N cores are scheduled to the non-real-time operating system.

[0036] For example, by running different operating systems (heterogeneous operating systems) on different cores of the same processor, the entire processor system can have the ability to process real-time and non-real-time services in parallel, and by adaptively adjusting the processor core resources (e.g., processor cores) occupied by the different operating systems, significant improvement in processor resource utilization can be achieved. Here, "heterogeneous" refers to different types of operating systems running on the same multi-core processor of an embedded system, and "multi-system" refers to the number of operating systems running on the same multi-core processor of an embedded system, and these operating systems run in parallel from a time perspective.

[0037] Furthermore, servers have the characteristics of at least high scalability and high stability. Since it is impossible for a company's network to remain unchanged for a long period of time, in this age of network informationization, if a server does not have a certain level of scalability, it will affect the use of the server in the company and even the company's future development. Therefore, scalability has become the most basic characteristic required for a server, and only if it has high scalability can it guarantee better future use. Scalability includes not only hardware scalability but also software scalability. Compared with computers, the functions of servers are much more complex, so not only the hardware configuration but also the software configuration is very important. To achieve more functions, it is unthinkable without comprehensive software support.

[0038] In addition, because servers need to process large amounts of data to support the continuous operation of services, servers must have very important characteristics such as high stability. If the server's data transmission cannot operate stably, it will undoubtedly have a significant impact on the development of services.

[0039] The solution of the present application utilizes the highly scalable characteristics of a server by booting dual software systems, namely, a first operating system and a second operating system, which generate hardware interface signals, and simultaneously booting hardware devices such as a GPLD and a BMC chip, which are used to adjust the transmission voltage of the hardware interface signals and monitor the operating status of other devices within the server. In addition, the present application uses a method in which the first operating system generates a hardware interface signal corresponding to a request command, by first obtaining the request command through the first operating system, then determining a plurality of logical bit information corresponding to the request command, and finally generating the hardware interface signal corresponding to the request command according to the plurality of logical bit information and a timer. As can be seen from the above, the present application achieves the technical effect of generating a hardware interface signal using a software method by having the first operating system generate a hardware interface signal corresponding to the request command, and further achieves the objective of eliminating the need for a chip itself to have hardware logic design related to the hardware interface signal, thereby reducing the difficulty and cost of chip design. The present application achieves the purpose of using a software system to generate hardware interface signals, eliminating the need for hardware logic design of hardware interface signals for the chip, thereby reducing the difficulty of chip design and solving the technical problem in related art that the chip itself needs to have the hardware logic design of the controller, which results in high chip design costs.

[0040] In addition, the introduction of a dual software system consisting of a first operating system and a second operating system ensures the stability of the server. Since the service response speed of the second operating system is slower than that of the first operating system, using the first operating system, which has a faster service response speed, to generate hardware interface signals can ensure that the generation of hardware interface signals is not interrupted, thereby ensuring continuous and stable output of hardware interface signals.

[0041] The above steps include: allocating a group of allocation target services to corresponding operating systems in the embedded system in accordance with a dynamic resource allocation rule, where the dynamic resource allocation rule includes performing dynamic resource allocation according to at least one of service response speed, service resource occupancy rate, service coupling degree, and service importance, where the embedded system includes a first operating system and a second operating system running on a processor, and the response speed of the first operating system is higher than that of the second operating system; determining a resource allocation result corresponding to the group of allocation target services, where the resource allocation result is used to indicate a processing resource corresponding to each allocation target service in the group of allocation target services among the processing resources of the processor including processor cores; and allocating the processing resources of the processor to the first operating system and the second operating system in accordance with the operating systems corresponding to each allocation target service and the resource allocation result, thereby solving the problem present in the related art that the overall utilization rate of core resources is low due to many processing resources of a multi-core processor being idle, and improving the utilization rate of processing resources.

[0042] In one exemplary embodiment, the method further comprises: The method includes step S11 of generating a rule structure for recording dynamic resource allocation rules by reading the rule setting file.

[0043] The dynamic resource allocation rules may be set based on a rule setting file, and a rule structure for recording the dynamic resource allocation rules can be generated by reading the rule setting file. The rule setting file may be a load balance policy file (payload_balance.config), which can be used to set the classification method of various running services (or processes), evaluation principles such as real-time level, etc. In the load balance policy file, the dynamic resource allocation rules can be set with different parameters. An example of a load balance policy setting file is as follows: classification kinds=2 / / A value of 1 indicates that the process is classified by important attributes and non-important attributes, etc. Otherwise, the process is classified according to the preset classification method (real-time and non-real-time, etc.); real-time grade evaluation=2 / / A value of 1 indicates that the process real-time level is evaluated based on the average CPU occupancy rate within the past statistical minutes; otherwise, the process real-time level is evaluated based on the preset priority. statistic minutes=5 / / Represents the statistical time (unit: minute) of the average occupancy rate of each process. This is valid when real-time grade evaluation is 1.

[0044] Optionally, the dynamic resource allocation rules can be stored in a load balance policy module, which may be a software module running on the first operating system or the second operating system (e.g., a software module running on a Linux system), and can provide the service management module with policy guidance including a classification method for various services (or processes) running in the system, an evaluation principle for real-time level, etc. The service management module can divide and manage services in the system according to their real-time level, and further guide the resource adaptive scheduling module to reallocate processor resources. Illustratively, an actual classification of services is performed according to the output of the load balance policy module to generate a list including real-time services and non-real-time services.

[0045] The above classification method and real-time performance evaluation principle are open, allowing users to define their own methods or principles. The rules based on which the service management module manages services can be dynamically configured, allowing additional rules to be configured based on existing rules. The service management module can configure multiple rules with the same function without conflicts between them. That is, it can determine the currently used rule among rules with the same role based on rule selection conditions such as the rule configuration time and rule priority, thereby avoiding conflicts between rules. The above configuration file, load_balance.config, illustrates one possible scenario. In the configuration file, the classification_kinds variable indicates specific classification criteria (e.g., service importance or real-time performance) and classification categories (e.g., critical services and general services, real-time services and non-real-time services, etc.). The real-time_grade_evaluation variable indicates real-time performance evaluation criteria (e.g., average CPU utilization over the past statistic_minutes or preset service priority). The real-time performance level type can be customized by the user and can be defined as three types: high, low, and very high, and can be further subdivided.

[0046] The output of the load balance policy module is the configured classification method, real-time level evaluation principle, etc., which can be a specific configuration file (such as the load_balance.config file) or a structure variable when the software is implemented. These files or structure variables can ultimately be accessed by the service management module to obtain the specific load balance policy. According to this embodiment, by reading the rule setting file, a rule structure for recording the dynamic resource allocation rules is generated, thereby improving the convenience of information setting.

[0047] In one exemplary embodiment, the method further comprises: S21: obtaining a rule update configuration file for updating the configured resource dynamic allocation rule through an external interface of the second operating system; and S22 updating the rule structure using the rule update setting file to update the dynamic resource allocation rules recorded in the rule structure.

[0048] The rule structure may be in a fixed format that is not allowed to be modified during operation of the embedded system, or in a flexibly configurable format that can be set and changed using a configuration file in a specific format. In this embodiment, a rule update configuration file that updates the configured dynamic resource allocation rules can be obtained, and the rule structure can be updated using the rule update configuration file, thereby updating the dynamic resource allocation rules recorded in the rule structure.

[0049] When updating a rule structure using a rule update setting file, a new rule structure may be generated directly according to the rule update setting file and the existing rule structure may be replaced with the newly generated rule structure, or the parameter values ​​of the rule parameters indicated by the rule update setting file may be used to update the parameter values ​​of the corresponding rule parameters of the rule structure.

[0050] Optionally, the configuration file in a specific format may be read by an external interface of the first operating system or the second operating system, and in consideration of the amount of services that need to be processed, the second operating system may be responsible for operations of the embedded system, such as dynamic resource scheduling. When obtaining the rule update configuration file, the rule update configuration file may be obtained through the external interface of the second operating system.

[0051] For example, the load balance policy module may have a fixed format or may be configured via an external interface of the Linux system. For example, a configuration file (load_balance.config) of a specific format as described above can be defined, and settings and changes can be made by reading and writing the file. The external interface refers to the external interface of the multi-core processor and may be a network interface, a Serial Peripheral Interface (SPI) controller interface, a Universal Asynchronous Receiver / Transmitter (UART) serial port, or any other path through which data can be acquired from the outside. The hardware used to read the file and the specific file location can vary depending on the implementation. For example, a configuration file can be loaded from a Web (World Wide Web) interface via a network interface, a configuration file can be read from the card's SPI Flash (flash memory) via an SPI controller, or a configuration file can be obtained from a serial port data transmission / reception software tool on another PC (personal computer) via a UART serial port.

[0052] According to this embodiment, the flexibility of setting the dynamic resource allocation rules can be improved by acquiring a rule update setting file and updating the rule structure using the acquired rule update setting file. In one exemplary embodiment, the step of allocating a group of allocation target services to corresponding operating systems of the embedded system in accordance with the resource dynamic allocation rule includes: The method includes S31 of allocating to a first operating system, among the services to be allocated in one group, those services to be allocated whose service response speed requirements are equal to or greater than a set response speed threshold, and allocating to a second operating system, among the services to be allocated in one group, those services to be allocated whose service response speed requirements are smaller than the set response speed threshold.

[0053] When allocating the services to be allocated, the services to be allocated can be allocated to corresponding operating systems based on the service response speed requirements of the services to be allocated. The service response speed can be used to evaluate the real-time level of the service, and the higher the service response speed requirement, the more sensitive the service is to the scheduling time and response speed of the operating system. The higher the real-time level, the faster the operating system needs to process the services with high service response speed requirements at a sufficiently fast speed, so that the processing results can control the production procedure or respond quickly to the processing system within a predetermined time. Services with lower service response speed requirements can tolerate scheduling delays to a certain extent.

[0054] A service to be assigned whose service response speed requirement is equal to or greater than the set response speed threshold is sensitive to the scheduling time and response speed of the operating system, and this type of service to be assigned can be assigned to a first operating system (e.g., a real-time service is assigned to a real-time operating system). A service to be assigned whose service response speed requirement is smaller than the set response speed threshold is not sensitive to the response speed and scheduling time, and this type of service to be assigned can be assigned to a second operating system (e.g., a non-real-time service is assigned to a non-real-time operating system). Here, the service response speed requirement can be indicated by a service response speed indication parameter, and the set response speed threshold can be a millisecond-level response speed threshold or a second-level response speed threshold, such as 100 ms, 200 ms, 1 s, etc., and this embodiment does not limit the set response speed threshold.

[0055] Optionally, when allocating a group of services to be allocated to corresponding operating systems of 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, where the first service list is used to record the services to be allocated to the first operating system and the second service list is used to record the services to be allocated to the second operating system, i.e., the service allocation result includes the first service list and the second service list, and the output first service list and second service list can be used to perform a dynamic scheduling procedure of the processor's processing resources.

[0056] For example, if we divide system services into real-time level categories, obtain a list of real-time and non-real-time services, and assume there are a total of 20 services, the real-time services are Service 1 and Service 2, and the non-real-time services are Service 3 to Service 20. Here, the service management module can classify services that are currently being executed. When the BMC system first starts, all services that the system is currently attempting to execute are already known to the system, so the service management module classifies these services once according to the output of the load balance module. After classification, different services are assigned to different operating systems (RTOS system and Linux system) and executed. During subsequent operation, if the number of service processes changes (e.g., some processes stop or new processes start), the service management module continues to perform service division, dividing and managing existing services in real time according to the load balance policy. The service management module may be a process resident in the Linux system, which itself is always running and manages and divides currently running processes.

[0057] According to this embodiment, by allocating the services to be allocated to the corresponding operating systems according to the service response speed requirements, it is possible to guarantee the timeliness of the response to the services that are sensitive to the scheduling time. In one exemplary embodiment, the step of allocating a group of allocation target services to corresponding operating systems of the embedded system in accordance with the resource dynamic allocation rule includes: The method includes S41 of allocating to a first operating system those services among the group of services to be allocated whose service resource occupancy rate is less than a first occupancy rate threshold, and allocating to a second operating system those services among the group of services to be allocated whose service resource occupancy rate is equal to or greater than the first occupancy rate threshold.

[0058] When allocating a service to be allocated, the service to be allocated can be allocated to a corresponding operating system based on the resource occupancy of the service to be allocated. The service resource occupancy can be the average occupancy of a service to a processing resource within a unit time (for example, the CPU occupancy per minute), and the magnitude of the service resource occupancy affects the response speed of this service and the response speed of subsequent services. Therefore, the real-time level of a service can be evaluated based on the service resource occupancy. The higher the service resource occupancy, the greater the impact on the scheduling time and response speed of the operating system, and the lower the real-time level. A service with a low service resource occupancy does not have a large impact on the scheduling time and response speed of the operating system, and the higher the real-time level.

[0059] A service to be assigned whose service resource occupancy rate is less than a first occupancy rate threshold does not have a significant impact on the scheduling time and response speed of the operating system, and thus this type of service to be assigned can be assigned to a first operating system. A service to be assigned whose service resource occupancy rate is equal to or greater than the first occupancy rate threshold has a significant impact on the scheduling time and response speed of the operating system, and therefore this type of service to be assigned can be assigned to a second operating system. Here, the first occupancy rate threshold can be set as needed, and can be 10%, 15%, 20%, or other threshold, or the first occupancy rate threshold can be dynamically adjusted.

[0060] According to this embodiment, the services to be allocated are allocated to the corresponding operating systems according to the service resource occupancy rate, thereby ensuring the timeliness of the response to the services with low service resource occupancy rates. In one exemplary embodiment, the step of allocating a group of allocation target services to corresponding operating systems of the embedded system in accordance with the resource dynamic allocation rule includes: S51 assigning to the first operating system, among the services to be assigned in one group, those services to be assigned whose service coupling with the assigned services of the first operating system is equal to or greater than a first coupling threshold; The method includes at least one of S52 of allocating to the second operating system, among the services to be allocated in one group, those services to be allocated whose service coupling with the allocated services of the second operating system is equal to or greater than a second coupling threshold.

[0061] When allocating the services to be allocated, the services to be allocated can be allocated to corresponding operating systems based on the service coupling degree of the services to be allocated. The service coupling degree can be used to represent the degree of association between the services to be allocated and the allocated services of each operating system. If one service to be allocated has a high service coupling degree with the allocated services of one operating system, it is inappropriate to allocate it to another operating system. Therefore, the services to be allocated can be allocated to corresponding operating systems based on the service coupling degree between the services to be allocated and the allocated services of each operating system.

[0062] Service coupling can be optionally evaluated based on the relationship between service inputs and outputs, and can be expressed in different coupling levels: if there is no relationship between service inputs and outputs, the coupling level is low (or other coupling levels where there is no relationship between services); if the execution of one service depends on the output of another application (the service cannot start without that output as input), the coupling level between services is high; and if the execution of one service uses the output of another application but that output does not interfere with the normal execution of the service (it is sufficient for the service to obtain that output when the service is executed up to the corresponding operation, and the corresponding operation is an operation that is not a core operation), the coupling level between services is medium. Service coupling can also be expressed as a numerical value, and service coupling can be evaluated based on one or more coupling conditions (e.g., association between inputs and outputs), and the numerical value corresponding to the coupling condition that is met is determined as the value of the service coupling.

[0063] If a service to be assigned whose coupling with assigned services of a first operating system is equal to or greater than a first coupling threshold exists in a group of assigned services, this type of service to be assigned can be assigned to the first operating system, and if a service to be assigned whose service coupling with assigned services of a second operating system is equal to or greater than the first coupling threshold exists in a group of assigned services, this type of service to be assigned can be assigned to the second operating system.

[0064] For example, the service management module, in addition to generating a real-time service list and a non-real-time service list, is also responsible for separating, evaluating, and managing services. That is, the service management module finds out from all real-time services those services that can be handed over to the real-time operating system to run independently of all real-time services, so as to facilitate the hardware resource dynamic allocation module in reallocating processor resources. For services that cannot be handed over to the real-time operating system to run independently of all real-time services, if the service has a high degree of service coupling with non-real-time services, it can be assigned to the non-real-time operating system.

[0065] Here, some services have real-time requirements but frequently interact with other non-real-time services in the system (i.e., the degree of service coupling is high). In this case, to improve the overall data interaction efficiency, this type of service is assigned to a non-real-time operating system. In addition, there is one type of real-time service that is relatively independent. In this case, it is sufficient to separate it into a real-time operating system, which is the "separation" operation. The criteria for determining whether services are independent are not unique, and may be the closeness of the relationships between the above services or other indicators that interest users.

[0066] The reallocation policy is open, and possible policies are as follows: when the system first runs, the service management module allocates processor cores according to the ratio of the number of services allocated to the real-time operating system and the non-real-time operating system, and during subsequent operation, adjusts the resource allocation according to the core resource occupancy of each of the two systems; from this perspective, the reallocation procedure is a procedure that cooperates with the core preemption and release procedure.

[0067] In an optional embodiment, the service running on the first operating system includes, but is not limited to, a hardware interface signal generation service. In this embodiment, a hardware interface signal generation procedure is provided, and the procedure includes steps 1 to 3.

[0068] In step 1, a request command is obtained by the first operating system. Here, the request command may be a command to generate a hardware interface signal. For example, the hardware interface signal may be a PECI signal, and the request command is a PECI request command based on the PECI protocol. The hardware interface signal may be a hardware interface signal of another protocol type, such as an HDMI (High Definition Multimedia Interface) signal, an RGMII (Reduced Gigabit Media Independent Interface, a parallel bus) signal, an SGMII (Serial Gigabit Media Independent Interface, a single-transmission serial bus) signal, a GPIO (General-Purpose Input / Output) signal, or an SPI (Serial Peripheral Interface) signal. In addition, the request command may be a request command of another protocol type. For example, if the hardware interface signal is a GPIO signal, the request command is a GPIO request command. This application does not particularly limit the specific types of the request command and the hardware interface signal.

[0069] In step 2, a plurality of pieces of logical bit information corresponding to the request command are determined. In step 2, after the first operating system receives the request command, it can obtain a plurality of logical bit information corresponding to the request command through analysis, and the plurality of logical bit information has a priority among them. The first operating system can generate a waveform signal (i.e., a hardware interface signal) corresponding to the request command using the plurality of logical bit information corresponding to the request command, so that information including the request command can be transmitted to other devices through the hardware interface signal.

[0070] Optionally, the request command includes at least one field, and each field can be represented by a logical bit 0 or 1. Based on this, the corresponding conversion relationship between each field and the logical bit 1 or 0 is the logical bit information corresponding to the field. When the request command corresponds to multiple fields, the request command corresponds to multiple logical bit information. In addition, each logical bit can be represented by a combination of a high-level signal and a low-level signal. For example, a logical bit 0 can be represented by a combination of a high-level signal with a first predetermined duration and a low-level signal with a second predetermined duration, and a logical bit 1 can be represented by a combination of a high-level signal with a second predetermined duration and a low-level signal with the first predetermined duration, and the first predetermined duration is different from the second predetermined duration. Based on this, since each logical bit contains not only a high level signal but also a low level signal, each logical bit is actually represented by a waveform signal of one section (the conversion between high level signal and low level signal appears as a waveform), and since a request command corresponds to multiple logical bit information, it also corresponds to multiple logical bits, so the hardware interface signal corresponding to the request command is a waveform signal obtained by combining the waveform signals corresponding to each logical bit information.

[0071] In step 3, a hardware interface signal corresponding to the request command is generated according to the plurality of logical bit information and the timer. Optionally, the timer in step 3 may be a timing program in the first operating system, or may be a register on a chip where the first operating system is located, and the timer can provide at least a timing function and a counting function. The present application uses the timing function and counting function of the timer to combine multiple logical bit information to generate a hardware interface signal corresponding to the request command.

[0072] For example, assume that the chip is a BMC chip and the hardware interface signal is a PECI signal. It should be noted that in the related art, in order to realize PECI communication between the BMC chip and components such as a CPU, the BMC chip itself must have a hardware logic design including a PECI controller, which results in a problem of high BMC chip design costs. In other words, in the related art, in order to generate a PECI signal on the BMC chip, the hardware logic design of the PECI controller must be implemented on the BMC chip in advance. In the present application, the PECI signal can be generated on the BMC chip using only the first operating system, eliminating the need to implement the hardware logic design of the PECI controller on the BMC chip, thereby reducing the difficulty and cost of BMC chip design.

[0073] Based on the above steps, this embodiment adopts a method in which the first operating system generates a hardware interface signal corresponding to the request command, in which the first operating system first obtains the request command, then determines a plurality of logical bit information corresponding to the request command, and finally generates a hardware interface signal corresponding to the request command according to the plurality of logical bit information and a timer.

[0074] As can be seen from the above, in this embodiment, the first operating system generates a hardware interface signal corresponding to the request command, thereby simulating the technical effect of generating a hardware interface signal using a software method. Furthermore, there is no need to perform hardware logic design for the hardware interface signal on the chip, and the purpose of generating the hardware interface signal using a software system is achieved, which not only reduces the difficulty of chip design but also reduces chip design costs.

[0075] Optionally, when the first operating system detects a first request triggered by the second operating system, the first operating system acquires request data, the first operating system and the second operating system 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 the service response speed of the first operating system. Finally, the first operating system analyzes the request data to obtain a request command.

[0076] Optionally, before obtaining the requested data, the second operating system can store the requested data in a target memory (i.e., a storage space on the processor), and after the storage of the requested data is completed, the second operating system can trigger a first request, which is used to notify the first operating system to read the requested data from the target memory, and the target memory is a memory accessible to both the first operating system and the second operating system.

[0077] In an alternative embodiment, the first operating system can further receive response data corresponding to the hardware interface signal, where the transmission format of the response data is the same as the transmission format of the hardware interface signal, and then the first operating system can further adjust the data structure of the response data to a second data structure. Also, after adjusting the data structure of the response data to the second data structure, a second request is triggered by the first operating system, and the second request is used to notify the second operating system to read the response data.

[0078] For example, the first operating system is an RTOS system, the second operating system is a Linux system, and the hardware interface signal is a PECI signal. Regarding the command request procedure, first, for a higher-level application related to the PECI service in the Linux system (such as fault diagnosis, CPU temperature acquisition, etc.), a PECI request command is actively initiated as needed. These request commands include, but are not limited to, the basic Ping() command, the command to acquire the CPU temperature, and the command to read the MSR register information. The codes of different PECI request commands are implemented by corresponding interface functions.

[0079] Optionally, the Linux system writes request data such as the target address, read length, command code, and para parameter of each request command to the target memory according to the PECI protocol specification, and after all the request data is written to the target memory, the Linux system generates a first request and notifies the RTOS system, where the first request may be an SGI interrupt request (software generated interrupt, a communication interrupt request between processor cores).

[0080] It should be noted that in the procedure in which the second operating system stores the request data in the target memory, the second operating system stores the request data in the target memory according to the form of a first data structure, and the first data structure includes at least a device address, a write length, a read length, a command code and request parameters, wherein the device address is used to characterize the address of the target device, the target device is a device that generates response data based on a hardware interface signal, the command code is used to distinguish different request commands, the write length is used to characterize the number of bytes starting from the command code to the end of the request data, the read length is used to characterize that the request data includes the number of bytes including the completion code and the read data, and the request parameters are used to characterize the parameters of the request command.

[0081] In the command response procedure, the RTOS system receives the response data transmitted from the PECI bus, then analyzes the data and converts the response data signal form from the hardware interface signal form to the software signal form, for example, by identifying the waveform change between high and low level signals in the hardware interface signal, thereby obtaining corresponding logic bit information, and obtaining software signal data based on the logic information. The analyzed response data is adjusted by the command parameter structuring module and written to the target memory. After writing the entire analyzed response data, the RTOS system triggers a second request to notify the Linux system. Upon detecting the second request, the Linux system actively reads the analyzed response data stored in the target memory, processes the data, and then returns it to the upper application. Here, the second request may be an SGI interrupt request.

[0082] The target memory may be a shared memory, or may be other memory such as a random access memory (abbreviated as RAM) or a flash memory (Flash). In an optional embodiment, after generating a hardware interface signal corresponding to the request command according to the logic bit information and the timer, the first operating system can convert the voltage of the hardware interface signal to obtain a target hardware interface signal.

[0083] Optionally, the first operating system can input a hardware interface signal to a voltage conversion device to obtain a target hardware interface signal output from the voltage conversion device. The voltage conversion device can be a CPLD, and the CPLD can be connected to a target device, which can be a CPU in a server. The above service can be applied to generating a PECI signal instead of a PECI interface, but can also be applied to other hardware interfaces.

[0084] As can be seen from the above, the first and second operating systems of the embedded system are combined to realize data interaction within the embedded system through inter-core interrupts and memory sharing. A request command waveform generation functional module is built in the RTOS system, and hardware interface signal communication between the embedded system and external devices is realized through software simulation. Furthermore, by fully utilizing the high real-time characteristics of the RTOS system, timing accuracy is ensured when simulating request command waveforms, and the system is characterized by flexibility and high efficiency. This significantly reduces the difficulty of chip design. Using software simulation to generate hardware interface signals provides more possibilities for optimizing the design between communication functions and other service functions in the embedded system. Furthermore, the chip design and manufacturing costs are reduced by eliminating the need for a dedicated controller for implementing hardware interface signal communication.

[0085] In an optional embodiment, the service running on the first operating system includes, but is not limited to, a serial port switching service. In this embodiment, a serial port switching procedure is provided, and the procedure includes steps 1 and 2. In step 1, if it is detected 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.

[0086] Optionally, when a user initiates serial port switching, the second operating system can detect whether it has received a user-initiated serial port switching command, where the serial port switching command must include information about the target serial port to be switched to, such as the serial port number of the target serial port to be switched to.

[0087] In one alternative example, the format of the serial port switching command is:<switch_command_app-n number-t sleep_time> where switch_command_app characterizes the switch command program, -n represents the target serial port number to be switched to, the value of number can be 1, 2, or 3, and -t represents how long to sleep from the start of the command before performing the switch operation, with sleep_time units in seconds.

[0088] When performing serial port switching, a number can be assigned to the serial port that can currently perform serial port switching, so that when performing subsequent serial port switching, the target serial port is switched using the serial port number. In one alternative embodiment, serial ports that can currently perform serial port switching include BMC Linux system serial ports, server BIOS (Basic Input Output System) serial ports, and SMART NIC (network interface controller) serial ports, and correspondingly, 1 can represent the BMC Linux system serial ports, 2 can represent the server BIOS serial ports, and 3 can represent the SMART NIC serial ports.

[0089] In step 2, the first operating system performs serial port switching according to the serial port switching command. Optionally, when it is detected that the second operating system has received the serial port switching command, the second operating system immediately sends the serial port switching command to the first operating system. Note that the first operating system and the second operating system are each run on two processor cores, and then inter-core communication is used between the first operating system and the second operating system, which helps to improve the reliability of signal transmission.

[0090] Furthermore, the response speed of the first operating system to commands is much faster than the response speed of the second operating system to commands, which allows the first operating system to respond quickly to serial port switching commands and complete the switching operation within an extremely short time.

[0091] To summarize the above, the software function of serial port switching is realized by replacing the CPLD or FPGA with the first operating system and the second operating system running on the same processor. When the second operating system receives a serial port switching command, it forwards the serial port switching command to the first operating system, and the first operating system switches the serial ports according to the serial port switching command. This avoids the related art's method of connecting each serial port with a CPLD or FPGA and then using a switch structure in the CPLD or FPGA to switch the serial ports, thereby reducing hardware costs. Furthermore, after the first operating system receives the serial port switching command, the serial port switching can be completed in a very short time. Therefore, the technical method proposed in this technical solution not only effectively reduces the serial port switching cost, but also effectively improves the efficiency of serial port switching.

[0092] In order to enable the second operating system to perform serial port switching, the serial port switching procedure provided in this embodiment includes the steps of: the serial port switching command includes at least the serial port number of the target serial port; and before the first operating system performs serial port switching based on the serial port switching command, the first operating system obtains an analysis rule for the serial port switching command from the target memory; and analyzing the serial port number of the target serial port in the serial port switching command based on the analysis rule to determine an equipment corresponding to the serial port number, where the target serial port is a serial port of the equipment and the target serial port is connected to a chip.

[0093] The step of performing serial port switching by the first operating system based on the serial port switching command includes the step of determining a serial port address of the device by the first operating system, and the step of mapping the target serial port to the target output interface of the chip based on the serial port address.

[0094] To enable the first operating system to perform serial port switching, the first operating system can analyze the serial port switching command and further obtain the device corresponding to the target serial port. In an alternative embodiment, analysis rules for serial port switching commands can be customized according to differences in chips or server motherboards, and the analysis rules can be stored in a target memory. The target memory can be a storage medium such as an electrically erasable programmable read-only memory (EEPROM), a non-volatile memory (flash), or the like. The target memory can be located on the chip or off-chip. Storing the analysis rules in the target memory improves data security and allows the analysis rules to be customized according to differences in chips or server motherboards, thereby providing relatively good programmability and scalability.

[0095] After the first operating system receives the serial port switching command, it reads the analysis rule of the serial port switching command from the target memory, and then uses the analysis rule to analyze 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. After obtaining the device corresponding to the serial port number, the first operating system can map the serial port address of the device to the target output interface of the target serial port chip. After mapping the serial port address of the device to the target output interface, access to the device can be achieved through the target output interface. The serial port switching command and analysis rules can be set according to the model number of the chip used and the types of the first and second operating systems.

[0096] In the serial port switching method provided in Example 1 of the present application, the chip includes a serial data bus, and before determining the serial port address of the device by the first operating system, the method further includes the steps of determining a plurality of devices connected to serial ports of the serial data bus, and mapping the serial port of each device to the memory of the chip via the serial data bus to obtain the serial port address of each device. Optionally, the chip also includes a serial data bus, connecting the TX and RX ports of multiple devices. For example, the serial ports include a BMC Linux system serial port (UART1), a server BIOS serial port (UART2), and a SMART NIC serial port (UART3). A UART (Universal Asynchronous Receiver / Transmitter) is a universal asynchronous transceiver. The serial port data bus maps the TX and RX data of the different serial ports, UART1, UART2, and UART3, to different address spaces in the BMC memory. That is, the serial data bus maps each device's serial port to the chip's memory. For example, the UART1 TX and RX buffers are the serial port addresses of the serial port UART1, the UART2 TX and RX buffers are the serial port addresses of the serial port UART2, and the UART3 TX and RX buffers are the serial port addresses of the serial port UART3.

[0097] When a serial port switching command is issued by the user, the first operating system (RTOS) selects one of three different sections of memory with different UART mappings and passes the memory data from that section to the client, thereby simulating the CPLD hardware serial port switching circuit. Furthermore, if the serial ports of different devices cannot be distinguished, developers will be unable to accurately locate the serial port of the device with the problem during maintenance. Therefore, locating the abnormality problem must be achieved by serial port switching.

[0098] In this embodiment, after mapping the target serial port to the target output interface of the chip based on the serial port address, if the target output interface is connected to a target smart network card, the method includes the steps of detecting whether an access request to the target serial port is received through the smart network card, and if an access request to the target serial port is received, forwarding the access request to the target serial port through the smart network card.

[0099] Optionally, the chip's target output interface is connected to a target smart network card, and the smart network card can then detect whether it receives a user's request to access the target serial port. If it receives a request to access the target serial port, it can directly use the target smart network card to achieve serial port access to the device, thereby realizing the SOL (Serial over LAN, a specification for encapsulated packet format and protocol) function. The above steps improve the efficiency of serial port access to the device.

[0100] In one 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 steps of: obtaining an execution result of the serial port switching command by the first operating system, where the execution result is one of switching success and switching failure; and sending the execution result to the second operating system by the first operating system.

[0101] The second operating system receives the execution result of the serial port switching command, and the execution result is sent by the first operating system to the second operating system, where the execution result is one of success or failure of the serial port switching. After the first operating system completes the serial port switching, it obtains the execution result of the serial port switching command and then feeds back the execution result of the serial port switching command to the second operating system, notifying the second operating system of the success or failure of the serial port.

[0102] To improve the success rate of serial port switching, this embodiment further includes, after receiving the execution result of the serial port switching command by the second operating system, if the execution result is unsuccessful, repeatedly issuing a serial port switching command by the second operating system to the first operating system until the execution result is successful or until the number of attempts to switch the serial port exceeds a preset number. If the number of attempts to switch the serial port exceeds the preset number, the second operating system triggers a prompting signal, which is used to prompt the user that the serial port has failed.

[0103] If the execution result of the serial port switching command is an execution failure, the step of issuing the serial port switching command by the second operating system to the first operating system needs to be repeatedly executed until the execution result is a success or until the number of times of serial port switching exceeds a preset number, where the preset number can be set to 3. If the number of times of serial port switching exceeds the preset number, the corresponding second operating system triggers an indication signal to indicate that the serial port switching has failed, so as to handle this situation in a timely manner.

[0104] Before the first operating system detects that it has detected and received a serial port switching command, and after the second operating system has completed booting, the method includes the steps of the second processor core triggering a first interrupt and sending a first signal to the first operating system; the first operating system detecting the operating states of multiple serial ports in the chip based on the first signal and obtaining a detection result; the first processor core triggering a second interrupt and sending the detection result to the second operating system via the second signal; and the second operating system receiving the detection result and determining the number of serial ports in the chip that are operating normally.

[0105] The method includes a step of detecting whether the first operating system receives the first signal after the second processor core triggers a first interrupt and sends a first signal to the first operating system, and a step of detecting the operating states of multiple serial ports in the chip by the first operating system if the first operating system receives the first signal, and obtaining a detection result.

[0106] After the second operating system has finished booting, the second processor core triggers a first interrupt (IPI interrupt, IPI, inter-processor interrupts) and sends a first signal to the first operating system, and the first operating system can know through the first signal that the second operating system has started up normally and can interact with the second operating system normally. The first operating system then detects the operating status of multiple serial ports on the chip according to the first signal and determines whether all serial ports are operating normally.

[0107] After the first operating system detects and obtains the detection result, the first processor core triggers a second interrupt and sends the detection result to the second operating system through a second signal, and the second operating system determines the number of serial ports that can be switched (i.e., the number of serial ports that are operating normally) according to the detection result, and subsequently performs serial port switching for these serial ports. In addition, in order to enable the first operating system to more quickly perform serial port switching, after the first operating system completes the detection, the first operating system begins to block and wait for a serial port switching command from the second operating system.

[0108] In an alternative embodiment, the first operating system is an RTOS and the second operating system is Linux. The first operating system runs on CPU0 and the second operating system runs on CPU1. The preparation step before serial port switching is as follows: when the Linux system on CPU1 has booted up to a certain stage, CPU1 triggers an IPI interrupt to notify the RTOS system on CPU0 that Linux has booted up successfully and can interact with Linux on CPU1 successfully. After receiving the IPI interrupt from CPU1, the RTOS system launches a serial port switching controller program to check whether UART1, UART2, and UART3 are normal. Then, CPU0 triggers another IPI interrupt to notify the Linux operating system on CPU1 that the RTOS system has booted up successfully. The reported information includes the number of switchable serial ports that the RTOS operating system on CPU0 has. Then, the RTOS operating system on CPU0 begins blocking to wait for a switching command from the operating system on CPU1.

[0109] If the second operating system is operating abnormally, a serial port switching command is issued to the first operating system via the service terminal, and the first operating system performs serial port switching according to the serial port switching command. The second operating system has many functions to run and a large amount of services to be provided, and therefore may malfunction or need to be restarted. If the second operating system malfunctions, the service terminal can directly issue a serial port switching command to the first operating system, ensuring that the first operating system can normally switch the serial port. The service terminal may be a terminal on the server where the chip is located.

[0110] The above steps ensure that the first operating system performs serial port switching without depending on the second operating system, and ensure the independence of the first operating system in performing serial port switching. To summarize, in the serial port switching procedure provided in this embodiment, the software function of serial port switching is realized by using a first operating system and a second operating system running on the same processor to replace a CPLD or FPGA. When the second operating system receives a serial port switching command, the second operating system forwards the serial port switching command to the first operating system. The first operating system then switches the serial port in accordance with the serial port switching command, thereby avoiding the need to use a hardware method to perform serial port switching and reducing hardware costs. Furthermore, the first operating system can complete the serial port switching in a very short time after receiving the serial port switching command. Therefore, the above procedure not only effectively reduces the serial port switching cost, but also effectively improves the efficiency of serial port switching.

[0111] According to this embodiment, by allocating the target services to the corresponding operating systems in accordance with the service coupling degree, it is possible to guarantee the accuracy of the service processing for a plurality of services with high service coupling degrees. In one exemplary embodiment, the step of allocating a group of allocation target services to corresponding operating systems of the embedded system in accordance with the resource dynamic allocation rule includes: The method includes a step of assigning a service to be assigned that includes sensitive information among a group of services to be assigned to a target operating system, in which the target operating system is an operating system that has a low frequency of interaction with the user among a first operating system and a second operating system, S61.

[0112] In this embodiment, an assigned service (which may be an important sensitive service, such as a service that should not be exposed to users) containing sensitive data (e.g., sensitive information such as a password) may be assigned to a target operating system, and the target operating system can provide hardcore level security protection and isolation to the assigned service containing sensitive information, and the target operating system is an operating system that has a low frequency of interaction with the user or an operating system with a fast response speed, for example, the first operating system, among the first operating system and the second operating system.

[0113] For example, the service processing module is responsible for further implementing hardcore-level security protection and isolation for system services, i.e., dividing important sensitive services (which should not be exposed to users) into real-time services, and finally offloading these services from the non-real-time operating system to the real-time operating system to achieve security protection. Here, the different services divided by the service processing module can be organized in the form of a structure when implemented in software. By designing a security space between heterogeneous operating systems, sensitive services can be offloaded from the non-real-time operating system to the real-time operating system to achieve the goal of hardcore-level security protection. Here, sensitive services refer to security-related services, such as services related to the user's personal privacy, such as user passwords and identity information.

[0114] Here, the term "hardcore level" refers to the isolation of services at the processor core level, i.e., the allocation of sensitive services to the real-time operating system (the cores occupied by the real-time operating system are different from those of non-real-time operating systems, and therefore belong to the core-level isolation). Because the real-time operating system interacts less frequently and to a lesser extent with users than non-real-time operating systems, it is difficult for users to "detect" sensitive data from services running on it. For higher-level applications, services such as user identity authentication management and security encryption belong to the above-mentioned critical sensitive services. The service management module forcibly separates these services into real-time services, and subsequently, when dynamically allocating hardware resources, these services can be run on the real-time operating system, achieving the effect of security isolation.

[0115] According to this embodiment, by assigning services containing sensitive information to operating systems that have low frequency of user interaction, a hardcore level of security protection and isolation can be provided to system services, thereby improving the security of service execution.

[0116] In one exemplary embodiment, the step of determining resource allocation results corresponding to a group of allocated services includes: The method includes S71 of generating a resource mapping table between the services to be allocated to one group and the processing resources of the processor by combining the resource usage status of the processing resources of the first operating system and the resource usage status of the processing resources of the second operating system according to the allocation result of the services to be allocated to one group.

[0117] In this embodiment, the allocation result of the group of services to be assigned is used to indicate the correspondence between the services to be assigned and the operating systems, and the services to be executed that are assigned to an operating system are usually executed using the processing resources of that operating system, and if the amount of services assigned to a certain operating system is too large and there are currently unallocated processing resources, the unallocated processing resources may be allocated to the services to be assigned to the certain operating system. Therefore, according to the allocation result of the group of services to be assigned, a resource mapping table between the services to be assigned to the group and the processing resources of the processor can be generated by combining the resource usage status of the processing resources of the first operating system and the resource usage status of the processing resources of the second operating system, and the processing resources allocated to each service to be assigned can be indicated.

[0118] Here, each assigned service has a mapping relationship with only one processor core, and the same processor core can have a mapping relationship with multiple assigned services, and different services can have a mapping relationship with the same processor core by occupying different time slices of the same processor core. At the same time, the same processor core is occupied by only one service, i.e., it executes only one service. Different services assigned to an operating system can determine the time slices to occupy the same processor resource according to the allocation time, service response speed requirements, or other methods.

[0119] For example, the dynamic resource allocation module dynamically adjusts processor resources according to the output of the service management module, forms a resource mapping table between different services and actual hardware resources, and optimizes the layout structure of hardware resources in the heterogeneous operating systems to achieve the purpose of improving the utilization rate of the hardware resources of the entire system. The above dynamic resource allocation procedure is managed and configured by software in the second operating system.

[0120] Taking an eight-core processor (core 1 to core 8) as an example, the processor cores scheduled to the first operating system include core 1, and the processor cores scheduled to the second operating system include core 2, core 3, and core 4. There are six services to be assigned, with real-time services being service 1 and service 2, and non-real-time services being service 3 to service 6. Corresponding processor cores are assigned to the six services: core 1 is assigned to service 1, core 5 is assigned to service 2, core 2 is assigned to service 3, core 3 is assigned to service 4, core 4 is assigned to service 5, and core 6 is assigned to service 6.

[0121] According to this embodiment, the processing resources are dynamically allocated based on the correspondence between the services and the operating systems, taking into account the usage status of the processing resources of different operating systems, thereby ensuring the rationality of the allocation of the processing resources. In one exemplary embodiment, the step of allocating the processing resources of the processor to the first operating system and the second operating system according to the operating systems corresponding to the services to be allocated and the resource allocation results includes: If it is determined according to the resource allocation result that a service to be allocated corresponding to an unallocated processing resource among the processing resources of the processor exists, the method includes S81 of allocating the unallocated processing resource to the operating system to which the service to be allocated corresponding to the unallocated processing resource has been allocated.

[0122] When allocating processing resources, if an unallocated processing resource among the processor's processing resources has a corresponding service to be allocated, i.e., if the unallocated processing resource is allocated to the service to be allocated, the unallocated processing resource can be allocated to the operating system to which the service to be allocated corresponding to the unallocated processing resource has been allocated.

[0123] Optionally, the resource adaptive scheduling module may complete an actual scheduling operation on the processing resources of the processor according to the result of the dynamic allocation of the hardware resources. The resource adaptive scheduling module may schedule some of the processor cores, such as the M cores in core group 1 shown in FIG. 4, to run the services assigned to the first operating system, and schedule the remaining processor cores, such as the N cores in core group 2 shown in FIG. 4, to run the services assigned to the second operating system.

[0124] Taking the aforementioned 8-core processor as an example, according to the service allocation results and resource allocation results, the unallocated core 4 is assigned to the first operating system, and the unallocated cores 5 and 6 are assigned to the Linux system. The entire scheduling procedure can be controlled by the second operating system. According to this embodiment, based on the resource allocation result, the unallocated processor resources are scheduled to the corresponding operating systems, thereby improving the utilization rate of the processor resources.

[0125] In one exemplary embodiment, the method further comprises: The system includes a step S91 for preempting and releasing processing resources between the first operating system and the second operating system. In this embodiment, in addition to dynamically allocating processor resources based on the service to be allocated, the procedure for each operating system can also include preempting and releasing processing resources between the first and second operating systems based on the usage status (load status) of the operating systems' processing resources. Here, the dynamic allocation of processing resources is a resource scheduling method executed based on a control logic module other than the first and second operating systems, and the preemption and release of processing resources is a resource scheduling method actively initiated by the first and second operating systems.

[0126] Optionally, the preemption and release of processing resources may be performed by a core preemption and release module, which may be a software module running on the first operating system and / or the second operating system. For example, running on the first and second operating systems, the core preemption and release module primarily completes 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 another operating system. Correspondingly, failure of resource preemption by one operating system means failure of resource release by the other operating system. As shown in FIG. 5, through core preemption and release, P cores of the (M+N) cores are scheduled to the real-time operating system, and (M+NP) cores are scheduled to the non-real-time operating system.

[0127] Here, the core preemption and release module may complete the heterogeneous operating system dynamically preempting and releasing processing resources such as processor cores during real-time operation of the heterogeneous operating system to achieve the purpose of maximizing the utilization rate of processor resources. In this embodiment, by preempting and releasing processing resources between different operating systems, processing resources can be dynamically adjusted based on the load status of the operating system while the operating system is running, thereby improving the rationality of resource utilization and improving the efficiency of service processing.

[0128] In one exemplary embodiment, the step of preempting and releasing processing resources between the first operating system and the second operating system includes: The method includes S101 for preempting and releasing processing resources between the first operating system and the second operating system via the inter-core communication interface.

[0129] In related art solutions where services requiring high response speeds are executed using dedicated acceleration hardware, the communication bus speed between the processor and the acceleration hardware (e.g., CPU and FPGA / CPLD) is slow, resulting in poor overall performance. In this embodiment, processing resource preemption and release are performed between a first operating system and a second operating system via an inter-core communication interface. That is, one operating system sends a request to preempt or release a processing resource to another operating system via the inter-core communication interface to perform the preemption or release of the processing resource. Compared to interaction via a communication bus, interaction via an internal inter-core communication interface within the processor provides a higher communication speed and improves overall communication performance.

[0130] For example, the inter-core communication interface module can complete the communication and interaction functions between the first operating system and the second operating system. In the procedure of preempting and releasing a core, the preempting party and the releasing party can notify each other of their respective states (e.g., busy or idle) through the inter-core communication interface. A specific signal event is required to characterize the behavior (preemption behavior) of the different operating systems. Therefore, by performing the preemption and release of cores using the inter-core communication interface module, the hard-core resources of the different operating systems can be balanced, ensuring high processor occupancy.

[0131] Selective preemption and release of processing resources between different operating systems can be achieved through inter-core interrupts, such as SGI (Software Generated Interrupt, or software-triggered interrupt, or inter-core interrupt in Linux systems). One operating system issues a resource preemption request (e.g., core preemption request) or resource release request (e.g., core release request) to another operating system via an IPI (Inter-Processor Interrupt), which preempts or releases processing resources. Taking the Linux system as an example, inter-core communication is achieved through a customized interrupt vector table and interrupt events between different operating systems. Here, IPIs are interrupts triggered between multiple cores within a SOC (System on Chip) and are different from general peripheral device interrupts. Therefore, cores can reserve some interrupt numbers specifically for IPIs. In the ARM64 architecture (CPU architecture), there are 16 interrupt numbers, from 0 to 15.

[0132] Optionally, the preemption and release procedures depend on the real-time load situation of the heterogeneous operating systems. For example, if the load of the second operating system increases rapidly and requires the support of more processor cores, it can issue a core preemption request to the first operating system via the IPI to preempt the processor cores of the first operating system. At this time, if the first operating system is in an idle state (e.g., no task scheduling) or at least some of its core resources are in an idle state, it releases the core resources to the second operating system. This means that the second operating system core has been successfully preempted and the first operating system core has been successfully released.

[0133] The core preemption and release procedure is a dynamically repeated procedure, and each core preemption and release always involves an adjustment of processor hard core resources. As shown in Figure 5, after one 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. In addition, the core preemption and release procedure can cooperate with modules such as load balancing policy, service management, and resource adaptive scheduling (e.g., core adaptive scheduling) to jointly determine the final core adjustment result.

[0134] Here, different modules jointly determining the core allocation result means that when a system needs to preempt more core resources, modules such as the load balance policy, service management, and core adaptive scheduling must jointly determine whether the preemption is ultimately successful. For example, in one possible scenario, when a second operating system requires more resources, the first operating system is idle (sleeping). However, the first operating system will soon wake up an important service thread to run. Because this thread also requires more resources, the first operating system cannot release the core resources to the second operating system. In this procedure, the criteria for breaking the importance of a service and the final operation of not allocating resources to the second operating system all involve modules such as the load balance policy, service management, and core adaptive scheduling. These modules also have the characteristic of being open to their respective policies, so that the final core allocation result they jointly determine is the result of the joint operation of these policies.

[0135] This embodiment enables preemption and release of processing resources between different operating systems via the inter-core communication interface, thereby improving communication speed and overall communication performance. In one exemplary embodiment, the step of preempting and releasing processing resources between the first operating system and the second operating system via the inter-core communication interface includes: S111: transmitting a first interaction request of the first operating system to the second operating system through the inter-core communication interface, the first interaction request being used to request a resource interaction with the second operating system, the resource interaction including one of a resource preemption and a resource release; and S112, a step of obtaining a first interaction response returned by the second operating system in response to the first interaction request via the inter-core communication interface, the first interaction response being used to instruct the first operating system to perform resource interaction with the second operating system according to the first interaction response.

[0136] In this embodiment, for the first operating system, considering that most of the services processed by the processor do not have high requirements for service response speed, the service volume of the services processed by the first operating system is usually small, so the first operating system can request preemption of processing resources of the second operating system through the inter-core communication interface, or actively release the processing resources it occupies to the second operating system. Optionally, the preemption and release of processing resources can be performed in a request-response interaction manner.

[0137] When it is necessary to preempt a processing resource of a second operating system or actively release a processing resource to the second operating system, the first operating system can transmit a first interaction request of the first operating system to the second operating system via the inter-core communication interface to request one of resource interactions, i.e., resource preemption and resource release, with the second operating system. After receiving the first interaction request, the second operating system can determine, based on its load status, whether to allow the first operating system to occupy at least a portion of its processing resource or whether to receive the processing resource released by the first operating system, and return a first interaction response to the first operating system via the inter-core communication interface, so that the first operating system can perform resource interaction with the second operating system according to the first interaction response.

[0138] It should be noted that the above preemption and release of processing resources is not actual scheduling of processing resources, but scheduling of processing resources performed at the operating system level (i.e., negotiation between the first operating system and the second operating system to complete scheduling of processing resources), and when actually scheduling processing resources, the actual scheduling of processing resources is completed by the resource adaptive scheduling module.

[0139] This embodiment allows resource interaction between different operating systems in a request-response manner, and allows an operating system with a fast response speed to actively release processing resources to an operating system with a slow response speed, thereby improving the utilization rate of processing resources.

[0140] In one exemplary embodiment, the method further comprises: S121 detecting a resource utilization rate of a processing resource of the first operating system; and S122, when the first operating system determines to perform resource interaction with the second operating system according to the resource utilization rate of the processing resource of the first operating system, triggering transmission of a first interaction request to the second operating system via the inter-core communication interface.

[0141] In this embodiment, the preemption and release procedures for processing resources may be determined according to the real-time load conditions of the different operating systems. A load detection module for detecting the load conditions of the systems may run in the different operating systems, which may belong to a system control module in the present system. A first system control module may run on a first operating system, and the load detection module in the system control module may detect the resource utilization rate of the processing resources of the first operating system. The resource utilization rate of the processing resources of the first operating system may be used to represent the load conditions of the first operating system. The higher the resource utilization rate of the processing resources, the heavier the system load. Conversely, the lower the resource utilization rate of the processing resources, the lighter the system load.

[0142] Depending on the resource utilization of the processing resources of the first operating system, the first operating system can determine whether a resource interaction with a second operating system is required. For example, if it is determined that a current resource utilization of one operating system (e.g., the first operating system) is too high (reaches a specified utilization threshold) or that a future resource utilization of the operating system according to services executed by the one operating system will be too high (reaches a specified utilization threshold), the operating system can determine that it needs to preempt the processing resources of another operating system (e.g., the second operating system); if the resource utilization is too low (below another specified utilization threshold), the operating system can determine that it needs to release the processing resources to the other operating system. Optionally, if the first operating system determines to perform a resource interaction with the second operating system, it can trigger a step of transmitting a first interaction request to the second operating system via the inter-core communication interface.

[0143] In this embodiment, resource interaction between different operating systems is performed in a request-response manner, and an operating system with a fast response speed actively releases processing resources to an operating system with a slow response speed, thereby improving the utilization rate of processing resources.

[0144] In one exemplary embodiment, the method further comprises: S131: determining that the first operating system preempts the processing resource of the second operating system when the resource utilization rate of the processing resource of the first operating system is equal to or greater than a first utilization rate threshold; At least one of S132, in which the first operating system decides to release the processing resources to the second operating system when the processing resources of the first operating system are idle and there are no services for the first operating system to run, is included.

[0145] In this embodiment, a resource utilization threshold of the processing resources of the first operating system can be preset, i.e., for a first utilization threshold, if the resource utilization of the processing resources of the first operating system is equal to or greater than the first utilization 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 service needs.

[0146] Optionally, the first operating system typically processes some specific services because it has a faster response speed than the second operating system, but the trigger for the specific services is somewhat random and the general service frequency is generally low, so there is a certain probability that the processing resources of the first operating system are idle and there are no services for the first operating system to execute. In this case, the first operating system can decide to release at least some of the processing resources to the second operating system.

[0147] Here, when the processing resources of the first operating system are in an idle state, search for a service queue to be executed corresponding to the first operating system, and if the service queue to be executed is empty (i.e., contains a service to be executed), determine that the first operating system does not have a service to be executed within a certain time range; if the service queue to be executed is not empty (i.e., contains a service to be executed), do not release the processing resources to the second operating system even if the first operating system is not currently executing a service.

[0148] According to this embodiment, if the resource utilization rate of a processing resource is too high, the processing resource is preempted, and if the processing resource is idle and there are no subsequent services that need to be processed, the processing resource is released, thereby improving the rationality of resource scheduling and improving the utilization rate of the processing resource. In one exemplary embodiment, the method further comprises: If the first operating system has no service scheduling and no service to be allocated to the first operating system, S141 is included, in which the first operating system is controlled to enter a sleep state.

[0149] In this embodiment, the first operating system may operate based on the periodicity of the processor, or the first operating system may operate based on the processor in response to a received wake-up request, or the first operating system may operate based on the processor according to the degree of match between the service of a current operation generated by the processor and the first operating system. The first operating system may sleep after completing its operation, and the second operating system may add processor resources (e.g., processor cores) used by the first operating system to the scheduling resource pool (i.e., available resource pool) of the second operating system while the first operating system is sleeping.

[0150] Optionally, when the first operating system has no service scheduling and no services to be allocated to the first operating system (for example, the resource occupancy rate of the first operating system is lower than the set lower limit of occupancy rate but will soon be lower), the first operating system can be actively triggered to sleep, i.e., actively enter a sleep state. Before controlling the first operating system to enter a sleep state, the core resources of the first operating system can be first released to the second operating system (resource release can be performed in the form of an interrupt request), and the system context data of the first operating system can be saved, for example, the saved system context data can be pushed onto a stack so that the first operating system can be restored to its previous working state after waking up.

[0151] For example, when the first operating system has no tasks to schedule (i.e., is in an idle state), the first operating system sends a core release request to the second operating system, at which time management of the core resources of the first operating system is handed over to the second operating system, and the first operating system enters a sleep state.

[0152] In one alternative application scenario, a first operating system (e.g., an RTOS) periodically wakes up to operate, and the first operating system and a second operating system alternately occupy and schedule the same processing resource (which may be a processor core, such as CPU core 0). The resource of the same processor may be the first processing resource, and correspondingly, the processing resource of the second operating system may be the second processing resource. During a time slice in which the first operating system schedules the first processing resource, the second operating system generates an interrupt that assumes management of the first processing resource at a first time point, so that the first operating system can only go to sleep. In this case, the first operating system saves a current state to a stack and goes to sleep, then releases the first processing resource to the second operating system, which then assumes management of it. After the second operating system completes scheduling, the first operating system generates an interrupt that preempts the first processing resource at a second time point, waking up the first operating system. From this point on, the first operating system again enters a polling mode and begins occupying and scheduling the first processing resource.

[0153] In the above selective application scenario, within the time slice in which the second operating system schedules the first processing resource, the first operating system is in a sleep state, and at a third time point, the first operating system may be woken up by an interrupt event reported by the hardware, and the second operating system reserves the process running on the first processing resource. After the first operating system occupies the first processing resource and handles the interrupt event reported by the hardware, it also enters a sleep state at a fourth time point, at which time the first operating system reports an interrupt to the second operating system to release the first processing resource, and the second operating system subsequently schedules the first processing resource according to the set period and resumes the on-site operating process.

[0154] Optionally, in this embodiment, when the first operating system operates periodically, the duration of a single operating cycle may be the same as or different from the interval between two operating cycles. During the interval between two operating cycles, the first operating system may be in a sleep state, but is not limited to this state, and the second operating system uses the processing resources allocated to the first operating system. When the duration of a single operating cycle is the same as the interval between two operating cycles, the first and second operating systems alternately occupy the processing resources allocated to the first operating system for the same duration. When the duration of a single operating cycle is different from the interval between two operating cycles, the first and second operating systems alternately occupy the processing resources allocated to the first operating system for different durations. The duration of the first operating system's occupancy may be longer than the duration of the second operating system's occupancy, or the duration of the second operating system's occupancy may be longer than the duration of the first operating system's occupancy.

[0155] In an alternative embodiment, a device may trigger a first operating system to wake up and operate. The device may provide a wake-up policy for the first operating system (such as an RTOS) in a trigger mode. The trigger mode may be initiated by an interrupt initiated by a device in the bus domain of the first operating system. The bus domain of the first operating system has devices 0 to N connected to it. When the first operating system is in a sleep state, device 0 may trigger an interrupt and send it to the first operating system at some point, after which the first operating system is woken up. After being woken up, the first operating system may first trigger an interrupt to preempt the first processing resource and send it to the second operating system. After the second operating system receives the interrupt, it first releases the first processing resource and saves the current state (pushes the active data onto the stack). Then, the first operating system schedules the first processing resource to process the operation service indicated by the interrupt triggered by device 0. If the current mode is a polling mode, the subsequent processing procedures are the same as those in the polling mode, and detailed descriptions thereof are omitted here.

[0156] According to this embodiment, when all processing resources (e.g., core resources) of one operating system have already been released to another operating system and the processing resources occupied are zero, the operating system is controlled to enter a sleep state and is allowed to release all processing resources to another operating system, thereby improving the utilization rate of processing resources.

[0157] In one exemplary embodiment, transmitting the first interaction request of the first operating system to the second operating system via the inter-core communication interface includes: S151: transmitting a first preemption request to a second operating system via an inter-core communication interface, the first preemption request having an interrupt number equal to a first interrupt number, the first preemption request being used to request preemption of a processing resource of the second operating system; A resource release request having an interrupt number of a second interrupt number is transmitted to the second operating system via the inter-core communication interface, and the resource release request is First Operating System The method includes at least one of S152, which is used to request the second operating system to release the processing resources occupied by the first operating system.

[0158] In this embodiment, preempting and releasing processing resources between different operating systems may be achieved by inter-core interrupts, where different interrupt events can be defined to correspond to different resource interaction types, and the different interrupt events can correspond to different interrupt numbers, where the interrupt number assigned to the first interrupt event in which the first operating system requests preemption processing resources from the second operating system 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.

[0159] As an optional embodiment, the first interaction request may be a first preemption request, i.e., a request to request preemption of processing resources of the second operating system, and the first operating system may transmit the first preemption request, whose interrupt number is the first interrupt number, to the second operating system via the inter-core communication interface, i.e., the inter-core communication interrupt, whose interrupt number is the first interrupt number, is triggered by the first operating system and responded to by the second operating system, and the meaning of this inter-core communication interrupt is that the first operating system preempts processing resources of the second operating system.

[0160] As another optional embodiment, the first interaction request may be a resource release request, i.e., a request for requesting the first operating system to release the processing resources occupied by it to the second operating system, and the first operating system may transmit the resource release request, whose interrupt number is a second interrupt number, to the second operating system via the inter-core communication interface, i.e., the trigger source of the inter-core communication interrupt, whose interrupt number is the second interrupt number, is the first operating system and the responder is the second operating system, and the meaning of this inter-core communication interrupt is that the first operating system actively releases the processing resources to the second operating system.

[0161] In this embodiment, by assigning interrupt numbers for preemption and active release of processing resources between different operating systems, resource scheduling between operating systems is performed in the manner of inter-core communication interrupts, thereby improving the accuracy of resource scheduling.

[0162] In one exemplary embodiment, the step of preempting and releasing processing resources between the first operating system and the second operating system via the inter-core communication interface includes: S161: transmitting a second interaction request of the second operating system to the first operating system via the inter-core communication interface, the second interaction request being used to request preemption of a processing resource of the first operating system; and S162, a step of obtaining a second interaction response returned by the first operating system in response to the second interaction request via the inter-core communication interface, the second interaction response being used by the first operating system to indicate whether or not to allow the second operating system to preempt processing resources of the first operating system.

[0163] In this embodiment, for the second operating system, considering that most of the services processed by the processor do not have high requirements for service response speed, the service volume of the services processed by the second operating system is generally large, so that the second operating system can request preemption of processing resources of the first operating system through the inter-core communication interface. Optionally, the preemption of processing resources may be performed in a request-response interaction manner.

[0164] When it is necessary to preempt the processing resources of the first operating system, the second operating system can transmit a second interaction request of the second operating system to the first operating system via the inter-core communication interface to request a resource interaction with the first operating system aimed at resource preemption. After receiving the second interaction request, the first operating system determines whether to allow the second operating system to occupy at least a portion of its processing resources based on its own load status, etc., and returns a second interaction response to the second operating system via the inter-core communication interface, so that the second operating system can perform a resource interaction with the first operating system according to the second interaction response.

[0165] It should be noted that the above processing resource preemption is not actual processing resource scheduling, but operating system level processing resource scheduling (i.e., negotiation between the first operating system and the second operating system to complete processing resource scheduling), and when actually scheduling the processing resource, the actual scheduling of the processing resource is completed by the resource adaptive scheduling module.

[0166] This embodiment uses a request-response method for resource interaction between different operating systems, thereby improving the utilization rate of processing resources and also improving the response speed of service processing. In one exemplary embodiment, the method further comprises: S171 detecting a resource utilization rate of a processing resource of the second operating system; and S172, when the second operating system determines to preempt the processing resources of the first operating system according to the resource utilization rate of the processing resources of the second operating system, triggering transmission of a second interaction request to the first operating system via the inter-core communication interface.

[0167] In this embodiment, the processing resource preemption procedure may depend on the real-time load status of the different operating systems. A load detection module for detecting the system load status may run in the different operating system, and may belong to a system control module in the present system. A second system control module may run on the second operating system, and the load detection module in the system control module may detect the resource utilization rate of the processing resources of the second operating system. The resource utilization rate of the processing resources of the second operating system may be used to indicate the load status of the second operating system. The higher the resource utilization rate of the processing resources, the heavier the system load; conversely, the lower the resource utilization rate of the processing resources, the lighter the system load.

[0168] According to the resource utilization of the processing resources of the second operating system, the second operating system can determine whether it needs to perform resource interaction with the first operating system, for example, if it determines that the current resource utilization is too high (reaches a specified utilization threshold) or that the future resource utilization according to the service to be performed is too high (reaches a specified utilization threshold), the second operating system can determine that it needs to preempt the processing resources of the first operating system. If the second operating system determines to perform resource interaction with the first operating system, it can trigger to perform a step of transmitting a second interaction request to the first operating system via the inter-core communication interface.

[0169] This embodiment allows resource interaction between different operating systems in a request-response manner, and allows an operating system with a slower response speed to actively preempt the processing resources of an operating system with a faster response speed, thereby improving the utilization of processing resources. In one exemplary embodiment, the method further comprises: S181: determining that the second operating system preempts processing resources of the second operating system when the current resource utilization rate of the second operating system is equal to or greater than a second utilization rate threshold; and at least one of S182, in which the second operating system determines to preempt the processing resources of the second operating system when it determines, according to the running services and the services to be run by the second operating system, that the resource utilization of the processing resources of the second operating system is equal to or greater than a third utilization threshold.

[0170] In this embodiment, taking into account the complexity of service processing, there may be a coupling relationship between services, the importance of a service will affect the operating system to which it is allowed to be allocated, and there may also be differences in the processing priorities of different services. The second operating system will determine whether it needs to preempt the processing resources of the first operating system by taking into account multiple factors such as its own resource utilization rate, the service to be allocated, and the service to be executed.

[0171] As an optional embodiment, a resource utilization threshold of the processing resources of the second operating system, i.e., a second utilization threshold, can be preset. When the resource utilization of the processing resources of the second operating system is equal to or greater than the second utilization threshold, 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 service needs.

[0172] As another optional embodiment, in addition to the currently running services, the second operating system also needs to process services that have been allocated to the second operating system. Therefore, a resource utilization threshold of the processing resources of the second operating system, i.e., a third utilization threshold, can be preset. If it is determined that the resource utilization of the processing resources of the second operating system is equal to or greater than the third utilization threshold according to the services currently running by the second operating system and the services to be run by the second operating system, the second operating system can determine to preempt the processing resources of the first operating system, and the second operating system can determine that it will soon be overloaded and need to preempt the processing resources of the first operating system to meet its own service needs.

[0173] In addition to executing allocated services (which may include currently running services and may also include allocated services), the second operating system may also process services that are currently to be allocated (i.e., newly added services to be allocated) that have a high service coupling with the allocated services. Therefore, a resource utilization threshold for the processing resources of the second operating system, i.e., a fourth utilization threshold, and a service coupling threshold for the newly added services to be allocated and the allocated services, i.e., a third coupling threshold, can be preset. If the current resource utilization of the processing resources of the second operating system is equal to or greater than the fourth utilization threshold and the service coupling between the newly added services to be allocated and the allocated services of the second operating system is equal to or greater than the third coupling threshold, it can be determined that the second operating system will soon be overloaded and needs to preempt the processing resources of the first operating system to meet its service needs.

[0174] Optionally, the second utilization rate threshold may be the same as or different from the third utilization rate threshold, for example, both may be 50%, 60% or other values, and the fourth utilization rate threshold may be a value smaller than the second utilization rate threshold and the third utilization rate threshold, for example, 40%, or may be another utilization rate threshold, and this embodiment does not limit each utilization rate threshold. This embodiment determines the resource scheduling needs of the operating system based on the currently running services of the operating system, the currently running services and allocated services, or the currently running services and allocated services and newly added services to be allocated, thereby improving the flexibility of resource scheduling and also improving the utilization rate of processing resources.

[0175] In one exemplary embodiment, the method further comprises: S191: if a service priority of a service being executed by the first operating system is not lower than a service priority of a service to be executed by the second operating system, the first operating system determines to deny the second operating system from preempting a processing resource of the first operating system; and S192, in which the first operating system determines to allow the second operating system to preempt processing resources of the first operating system if the service priority of the running service of the first operating system is lower than the service priority of the service to be run by the second operating system.

[0176] When the first operating system is currently idle and has no assigned services to run or no services to be assigned to the first operating system, the first operating system can directly determine whether to allow the second operating system to preempt its processing resources. When the first operating system is currently processing a service, has assigned services to run, or has assigned services to be assigned to the first operating system, the first operating system determines whether to allow the second operating system to occupy the processing resources of the first operating system by combining factors such as the service priority of the above services.

[0177] Optionally, if the service priority of the running service of the first operating system is not lower than the service priority of the service to be run by the second operating system, indicating that the importance of the running service of the first operating system is not lower than the importance of the service to be run by the second operating system, the first operating system denies the second operating system from preempting the processing resources of the first operating system. If the service priority of the running service of the first operating system is lower than the service priority of the service to be run, indicating that the importance of the running service of the first operating system is lower than the importance of the service to be run by the second operating system, the first operating system determines to allow the second operating system to preempt the processing resources of the first operating system.

[0178] In this case, when the response speed of the first operating system is faster than the response speed of the second operating system, services with higher service priorities are usually preferentially assigned to the first operating system. However, considering the connection relationships between services, services with higher service priorities may also be assigned to the second operating system. Therefore, resource preemption may be determined based on service priority. Only when the service priorities of the running service and the service to be executed of the first operating system are not lower than the service priority of the service to be executed of the second operating system, may processing resource preemption be considered.

[0179] According to this embodiment, by scheduling processing resources between operating systems by taking into account factors such as service priority, it is possible to improve the flexibility and rationality of resource scheduling.

[0180] In one exemplary embodiment, transmitting the second interaction request of the second operating system to the first operating system via the inter-core communication interface includes: The method includes a step S201 of transmitting a second preemption request, the interrupt number of which is a third interrupt number, to the first operating system via the inter-core communication interface, the second preemption request being used to request preemption of a processing resource of the first operating system.

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

[0182] Optionally, the second interaction request may be a second preemption request, i.e., a request to preempt the processing resources of the first operating system, and the second operating system may transmit the second preemption request, whose interrupt number is the third interrupt number, to the first operating system via the inter-core communication interface, i.e., the inter-core communication interrupt, whose interrupt number is the third interrupt number, is triggered by the second operating system and responded to by the first operating system, and the meaning of this inter-core communication interrupt is that the second operating system preempts the processing resources of the first operating system.

[0183] In this embodiment, interrupt numbers are assigned to preempt processing resources between different operating systems, and resource scheduling between operating systems is performed using an inter-core communication interrupt method, thereby improving the accuracy of resource scheduling.

[0184] In one exemplary embodiment, the step of obtaining a second interaction response returned by the first operating system in response to the second interaction request via the inter-core communication interface includes: S211: sending a resource release permission response, whose interrupt number is the fourth interrupt number, to the second operating system via the inter-core communication interface, where the resource release permission response is used to instruct the first operating system to allow the second operating system to preempt the processing resource of the first operating system; The method includes at least one of steps S212, in which a resource release refusal response having an interrupt number of the fifth interrupt number is transmitted to the second operating system via the inter-core communication interface, the resource release refusal response being used to instruct the first operating system to refuse to allow the second operating system to preempt the processing resources of the first operating system.

[0185] In this embodiment, similar to the previous embodiment, the preemption and release of processing resources between different operating systems can be completed by inter-core interrupts, and different interrupt events can be defined to correspond to different resource interaction types, and the different interrupt events can correspond to different interrupt numbers, and the interrupt number assigned to the fourth interrupt event and the fifth interrupt event, in which the second operating system requests to return a resource preemption response to 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 denies resource preemption.

[0186] As an optional embodiment, when the first operating system determines to allow the second operating system to occupy at least a portion of its processing resources, the first operating system can transmit a resource release permission response having an interrupt number of the fourth interrupt number to the second operating system via the inter-core communication interface, i.e., the trigger source of the inter-core communication interrupt having the interrupt number of the fourth interrupt number is the first operating system and the responder is the second operating system, and the meaning of this inter-core communication interrupt is that the first operating system passively releases the processing resources to the second operating system.

[0187] As another optional embodiment, if the first operating system determines to deny the second operating system from occupying its processing resources, the first operating system can transmit a resource release refusal response having an interrupt number of the fifth interrupt number to the second operating system via the inter-core communication interface, i.e., the trigger source of the inter-core communication interrupt having the interrupt number of the fifth interrupt number is the first operating system and the responder is the second operating system, and the meaning of this inter-core communication interrupt is that the first operating system refuses to release the processing resources to the second operating system.

[0188] In this embodiment, an interrupt number for allowing preemption of processing resources between different operating systems and an interrupt number for denying preemption of processing resources are assigned, and resource scheduling between operating systems is performed using an inter-core communication interrupt method, thereby improving the accuracy of resource scheduling.

[0189] As an alternative, the following explanation of inter-core communication interrupts is given using an RTOS system and a Linux system as examples. In a Linux system, inter-core communication can be implemented based on a customized interrupt vector table and interrupt events between different operating systems. The Linux operating system makes full use of SGI undefined bit numbers to customize terminal signals and reduce the cost of inter-core communication. The undefined bit numbers can be numbers 8 to 15. In a multi-core heterogeneous operating system, to maximize compatibility with current resource allocation methods, numbers 8 to 15 (a total of eight interrupts) are used to characterize the inter-core interrupt vector table. One possible vector table allocation method is shown in Table 1.

[0190] [Table 1]

[0191] Here, the aforementioned first interrupt number corresponds to interrupt number 12, the aforementioned second interrupt number corresponds to interrupt number 8, the aforementioned third interrupt number corresponds to interrupt number 9, the aforementioned fourth interrupt number corresponds to interrupt number 10, and the aforementioned fifth interrupt number corresponds to interrupt number 11.

[0192] As shown in Table 1, active release means that when the RTOS system has no service scheduling (i.e., is in an idle state), an SGI interrupt with interrupt number 8 is sent to the Linux system, and the Linux system takes over management of the RTOS core resources, causing the RTOS system to enter a sleep state. Passive release means that when the service load on the Linux system suddenly increases, an SGI interrupt with interrupt number 9 is sent to the RTOS system, allowing the process running on the RTOS system to be suspended (each process on the RTOS system has a priority, which can be set according to the actual situation). If the priority is higher than interrupt 9, it cannot be interrupted, but lower priority, 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's scheduling and use. After that, the RTOS system enters a sleep 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 notify the Linux system. In this case, the RTOS core resources will not be released, and the Linux system will continue to run according to its current operating policy and will not change.

[0193] Note that the inter-core communication vector table is not unique and is not limited to the inter-core communication vector table shown in Table 1 above. In one alternative embodiment, a method for communicating between cores is provided. The method includes steps 1 to 3.

[0194] In step 1, a first operating system sends target data (which may be service data) to a target virtual channel (which may be storage space) in a processor memory. Optionally, the target data is data to be sent, the target virtual channel is an area of ​​idle storage space in memory, and 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 to the target virtual channel.

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

[0196] In step 3, the second operating system responds to the interrupt notification message to obtain target data from the target virtual channel in the memory. Optionally, the CPU core of the second operating system responds to the interrupt notification message to analyze the address of the target virtual channel from the interrupt notification message, then locate the target virtual channel in the memory according to the analyzed address, obtain the target data from the target virtual channel, and implement data interaction between the first operating system and the second operating system.

[0197] Through the above steps, when multiple operating systems running on a processor need to transmit data to each other, the first operating system sending the data will send the target data to a target virtual channel in the processor memory and send an interrupt notification message to the second operating system, and the second operating system receiving the data will retrieve the target data from the target virtual channel in response to the interrupt notification message, thereby solving the problems of resource waste and heavy dependency on operating systems in inter-core communication procedures and achieving the effect of reducing resource waste and dependency on operating systems in inter-core communication procedures.

[0198] In one exemplary embodiment, the memory includes a data storage area and a metadata storage area, the data storage area is divided into a plurality of memory cells, each memory cell being used to store service data, and the metadata storage area is used to store the size and occupancy status of each memory cell in the data storage area. Optionally, the target virtual channel is composed of one or more memory cells in the data storage area, the metadata storage area is divided into memory chips with the same number as the number of memory cells, each memory chip records the size and occupied state of the memory cell, the size of the memory cell can be characterized by the starting address and ending address of the memory cell, or can also be characterized by the starting address and length of the memory cell, the occupied state includes an occupied state and an unoccupied state, and can be characterized by the value of an idle flag.

[0199] In one exemplary embodiment, the step of the first operating system sending the target data to the target virtual channel in the processor memory includes the steps of the first operating system reading a record in the metadata storage area, and determining, according to the read record, at least one memory cell from 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; and setting the state of the at least one memory cell 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.

[0200] In addition, in order to ensure continuous writing of target data to memory, the target virtual channel to be written must be idle and have a storage space that is equal to or greater than the length of the target data. Since the memory is divided into a metadata storage area and a data storage area, the occupancy status of each memory cell recorded in the metadata storage area can be read, thereby finding memory cells that are idle and meet the data storage requirements.

[0201] For example, if the size of each memory cell is equal and the length of the target data is longer than the length of one storage space, the number of memory cells required is determined according to the length of the target data, and from among them, a number of memory cells that are idle, consecutive, and satisfy the data storage requirements are found to form the target virtual channel. Furthermore, for example, each memory cell may be the same size, and multiple virtual channels of different sizes may be obtained by combining memory cells in advance in the data storage area, each virtual channel consisting of one or more memory cells. The system software can read the occupation status of each virtual channel recorded in the metadata storage area and find a virtual channel that is in an idle state and whose length is longer than the length of the target data, i.e., the target virtual channel. When it is necessary to request shared memory space, the system software determines whether the length of the data to be requested is longer than the maximum length for storing data in the virtual channel. If it is longer than the maximum length for storing data in the virtual channel, the system software transmits the data to be sent in multiple parts, ensuring that the length of the data sent each time is less than the maximum length for storing data in the virtual channel, thereby ensuring smooth communication.

[0202] In one exemplary embodiment, the step of the second operating system responsive to the interrupt notification message to obtain target data from the target virtual channel in the memory includes the steps of the second operating system reading a record in a metadata storage area and determining the target virtual channel according to the read record; and obtaining the target data from at least one memory cell corresponding to the target virtual channel and setting a state of the at least one memory cell to an idle state.

[0203] That is, after the second operating system extracts the target data from the memory cell corresponding to the target virtual channel, it sets the state of the memory cell corresponding to the target virtual channel to an idle state so as not to affect the use of the target virtual channel by other systems or tasks.

[0204] In one exemplary embodiment, the step of the first operating system sending target data to a target virtual channel in processor memory includes the steps of a drive layer of the first operating system receiving the target data, determining an idle virtual channel from memory to obtain the target virtual channel, and setting the state of the target virtual channel to an occupied state and recording the target data to the target virtual channel.

[0205] Optionally, both the real-time operating system and the non-real-time operating system have a drive layer, and after receiving target data to be transmitted, the drive layer calls an interface to search for a target virtual channel in memory, and after finding the target virtual channel, sets the state of the target virtual channel to an occupied state, and then writes the target data to the target virtual channel, in order to prevent other systems from requesting to use the target virtual channel while data is being written.

[0206] In one exemplary embodiment, when the first operating system includes an application layer, the application layer is provided with a man-machine interaction interface. Before the drive layer of the first operating system determines an idle virtual channel from memory, the application layer of the first operating system can receive data to be sent input by a user through the man-machine interaction interface, packetize the data to be sent using a preset format to obtain target data, and call a data write function to transmit the target data to the drive layer via a preset communication interface. The preset communication interface is provided on the drive layer.

[0207] Optionally, the application layer pads the data it needs to send according to a preset format to obtain target data, and then creates a device file ipidev in the system's / dev path. When the application layer reads or writes data from or to the drive layer, it first uses the system's own open function to open the device file / dev / ipidev, and then uses the system's own write function to send the target data from the application layer to the drive layer. The drive layer places the data in a target virtual channel in shared memory, and then triggers an interrupt to notify the second operating system that it has taken the data.

[0208] In one exemplary embodiment, the step of the second operating system retrieving the target data from the target virtual channel in the memory in response to the interrupt notification message includes the step of the second operating system triggering an interrupt handling function based on the interrupt notification message, determining the target virtual channel from the memory in the interrupt handling function, and retrieving the target data from the target virtual channel.

[0209] In one exemplary embodiment, determining the target virtual channel from memory in the interrupt handling function and obtaining the target data from the target virtual channel includes calling the target task in the interrupt handling function, and the target task determining the target virtual channel from memory and obtaining the target data from the target virtual channel. Optionally, the interrupt handling function sends a task notification to wake up a target task responsible for extracting data, and the target task first calls an interface to find the target virtual channel from the shared memory, and then reads the target data from the target virtual channel and performs data analysis.

[0210] In one exemplary embodiment, when the second operating system includes an application layer, a function identifier indicating a target function is stored in the memory, and the step of determining a target virtual channel from the memory with an interrupt handling function and obtaining target data from the target virtual channel includes the steps of: determining a function identifier and a target virtual channel from the memory with an interrupt handling function and sending address information of the target virtual channel to a target application program matching the function flag, the target application program being a target application program in the application layer; and the target application program calling a data reading function to transmit the address information to the drive layer through a preset communication interface, the drive layer obtaining the target data from the target virtual channel and transmitting the target data to the target application layer program, the preset communication interface being provided in the drive layer, and the target application program processing the target data according to the processing function matching the function identifier to perform the target function.

[0211] Optionally, after the second application system receives the interrupt notification message, the application layer calls a corresponding interrupt handling function to find the target virtual channel in memory, obtain the address information of the target virtual channel, and then create a device file ipidev in the system's / dev path. When the application layer needs to read data from the drive layer, it can first use the open function provided by the system itself to open the device file / dev / ipidev, and then use the read function provided by the system itself to read the target data in the target virtual channel. That is, the drive layer finds the corresponding target data in the 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 one exemplary embodiment, the state of the target virtual channel is set to idle.

[0212] In addition, application programs in different application layers can perform different functions using target data, and function identifiers indicating target functions that application programs perform using target data are stored in the memory. The function identifiers are selectively stored in the Net Fn , Cmd can also be used to initialize the system, Net Fn , Cmd and the PID of the application program are registered in the drive, and the drive layer can find the PID of the application program according to the received NetFn and Cmd, and send data to the corresponding application program according to the PID.

[0213] For example, NetFn=1, Cmd=1 indicates that the first and second operating systems send "hello word" to each other. When the system starts up, a number array is initialized, with a total of three columns: the first column is NetFn, the second column is Cmd, and the third column corresponds to the processing function of NetFn and Cmd, denoted as xxCmdHandler. For example, when the second operating system receives a message sent from the first operating system, it obtains NetFn and Cmd from the message, determines that NetFn=1, Cmd=1, and executes the processing function HelloCmdHandler corresponding to "hello word" to complete the corresponding function.

[0214] In one exemplary embodiment, the data storage area includes a plurality of memory channels, each of which is composed of one or more memory cells; the metadata storage area stores a plurality of records, each of which is used to record metadata of one memory channel, and the metadata of each memory channel includes at least a channel ID of the memory channel, a size of the memory channel, and an occupied state of the memory channel; and the step of the first operating system reading the records in the metadata storage area and determining, according to the read record, at least one memory cell from the data storage area that is in an idle state and whose total space is equal to or greater than the length of the target data to obtain the target virtual channel includes the steps of: traversing the records stored in the metadata storage area to determine whether there is a first target record indicating that the memory channel is in an idle state and whose size is equal to or greater than the length of the target data; and 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.

[0215] In addition, the data storage area can be divided into n virtual memory channels, and each memory channel can have a different size. That is, the sizes of the n virtual channels are 20*m, 21*m, 22*m, 23*m...2n-1*m in order, where m is the size of one memory cell. The following structure is set as the metadata management memory channel:

[0216] typedef struct{ uint32_t Flag; uint16_t ChannelId; uint8_t SrcId; uint8_t NetFn; uint8_t Cmd; uint32_t Len; uint32_t ChannelSize; uint8_t *pData; uint8_t CheckSum; }IpiHeader_T

[0217] Here, uint32_t Flag represents the state of the memory channel, for example, 0xA5A5A5A5 means that the channel is not empty, otherwise it is empty; uint16_t ChannelId represents the channel ID; uint8_t SrcId represents the ID of the source CPU, which means the CPU that writes data to the memory channel; uint8_t NetFn and uint8_t Cmd are function parameters; uint32_t Len represents the length of the data stored in the memory channel; uint32_t ChannelSize represents the size of the memory channel; uint8_t *pData represents the start address of the memory channel; "CheckSum" refers to a checksum. When the first operating system needs to send data, it calculates a check value for the data to be sent using a checksum algorithm and sends the check value to the second operating system. When the second operating system receives the data and the check value, it calculates a check value using the same checksum algorithm according to the received data, compares the calculated check value with the received check value, and if they match, it declares the received data valid; if they do not match, it declares the received data invalid. Each virtual memory channel corresponds to one structure record, and these structure records are stored at the start of the shared memory in order according to the channel ID increasing order. After the system is powered on, these structure records are initialized. The initialization flag is 0, indicating that the channel is empty, and the initialization channel ID is 0, 1, 2, ... n-1, in order. The initialization channel size corresponds to the size of the virtual memory channel, and the initialization pData points to the start address of the corresponding virtual memory channel.

[0218] In one exemplary embodiment, when determining the target virtual channel, the first operating system uses the interface GetEmptyChannel to search all memory channels according to the size of the target data to be transmitted for a virtual channel that satisfies the following conditions: 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 equal to or greater than the size of the target data (i.e., the memory size meets the storage requirements of the target data). After finding a target virtual channel that satisfies the above conditions, the first operating system sets the state of the channel to non-empty, i.e., sets the idle flag Flag in the channel structure IpiHeader to 0xA5A5A5A5, and then copies the target data to the target virtual channel.

[0219] In one exemplary embodiment, when a memory channel is occupied, the metadata of the memory channel includes an ID of a source CPU core of the target data and an ID of a target CPU core of the target data, and the step of the second operating system reading a record in the metadata storage area and obtaining a target virtual channel according to the read record includes the steps of: traversing the records stored in the metadata storage area to determine whether a second target record exists, wherein the second target record indicates that the memory channel is in an occupied state, the ID of the target CPU core is the ID of a CUP core of the second operating system, and the ID of the source CPU core is not the ID of a CUP core of the second operating system; and if the second target record exists, determining the memory channel indicated by the channel ID recorded in the second target record as the target virtual channel.

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

[0221] When the idle flag is represented by one bit, 0 indicates that the channel is empty and 1 indicates that the channel is not empty; if the flag is originally 0 but suddenly changes to 1, the system will read the flag and assume that the channel is not empty, resulting in a communication error. In this embodiment, the idle flag is set to a special character of multiple bits, for example, 0xA5A5A5A5, and the probability of multiple bits simultaneously changing to a special character is much smaller than the probability of a single bit suddenly changing, preventing sudden changes in bits on the storage medium from affecting the value of the flag, thereby improving communication security.

[0222] In one exemplary embodiment, a state mapping table is stored in the metadata storage area, and the state mapping table has a plurality of records, each record is used to record the occupied state of one memory cell, and the step of the first operating system reading the records in the metadata storage area and determining at least one memory cell from the data storage area according to the read records that is in an idle state and whose total space is equal to or greater than the length of the target data to obtain a target virtual channel includes the steps of determining a predetermined number of memory cells that should be occupied by the target data, scanning each record in order from an initial position of the state mapping table, and when the predetermined number of consecutive target records are scanned, determining consecutive memory cells indicated by the predetermined number of target records, where the target records characterize the memory cells as being in an idle state, and determining the consecutive memory cells as the target virtual channel.

[0223] In addition, in order to facilitate data storage and retrieval, the operating system needs to occupy consecutive memory cells in the memory when transmitting service data. Therefore, it is necessary to first determine the number of memory cells in the memory application command. Since the memory space of each memory cell is the same, the predetermined number of consecutive memory cells required can be calculated from the size of the required memory space, which is denoted as numb.

[0224] Optionally, the first operating system traverses records from an index position of the state mapping table, where the index position may be the starting position of the state mapping table. Starting from the starting position of the state mapping table, the first operating system sequentially queries each record of the state mapping table to determine whether there are numb or more consecutive records that record consecutive idle memory pages. If there are records that meet the above condition, the first operating system determines consecutive memory cells of the processor according to the correspondence between the records and the memory pages, determines the consecutive memory cells as a target virtual channel, and writes data to the target virtual channel.

[0225] In one exemplary embodiment, the interrupt notification message includes a starting address and a predetermined number of consecutive memory cells, and the step of the second operating system reading a record in the metadata storage area and obtaining a target virtual channel according to the read record includes the steps of: scanning each record in order from an initial position of the state mapping table; and, when the starting address where consecutive memory cells are recorded is scanned, determining the memory cell indicated by the scanned address and the consecutive memory cells obtained by subtracting 1 from the predetermined number as the target virtual channel.

[0226] Optionally, consecutive memory cells are consecutive memory cells whose number is equal to numb, and each record in the state mapping table also records the starting address of the corresponding memory cell. When the second operating system scans the record of the starting address of consecutive memory cells whose number is equal to numb from the mapping table, it is described as having scanned the starting address of the target virtual channel, and the memory cell indicated by the starting address and numb-1 consecutive memory cells after the memory cell constitute the target virtual channel, and the second operating system obtains data from the target virtual channel to complete the data interaction of the first operating system.

[0227] In one exemplary embodiment, a counter records the successive target records scanned, and while scanning each record sequentially from the initial position of the state mapping table according to the number of memory cells, if a target record is currently scanned, the counter is controlled to increment by 1, and if a non-target record is currently scanned, the counter is controlled to clear to zero.

[0228] Optionally, by utilizing the magnitude relationship between the counter value and the number of required memory cells, it is determined whether a predetermined number of consecutive target records exist, i.e., whether a predetermined number of consecutive memory cells exist; Optionally, the count of the counter is denoted as cntr; if the scanned memory cell is empty, add 1 to cntr; if the scanned memory cell is not empty, add 1 to cntr; The accumulated number of consecutive, idle memory cells, cntr, is cleared to zero, and then a search for consecutive, idle memory cells is started from the address next to the memory cell. When cntr is equal to numb, it indicates that consecutive, idle memory cells that meet the memory requirements have been found. If cntr is not equal to or greater than numb after the entire state mapping table has been scanned, it indicates that the dynamic application of this memory has failed, and the preset number of consecutive memory cells does not exist.

[0229] In one exemplary embodiment, before the step of the first operating system reading a record in the metadata storage area and, according to the read record, determining from the data storage area at least one memory cell that is in an idle state and whose total space is equal to or greater than the length of the target data to obtain a target virtual channel, the method further includes the step of the first operating system sending a memory request command and performing a lock operation on the processor's memory, wherein the memory request command is used to request use of the processor's memory; and the step of reading a record in the state mapping table if the memory is successfully locked.

[0230] Optionally, a memory request command is a command issued by an operating system running on a processor to request the use of the processor's memory. In order to prevent conflicts in requests caused by multiple operating systems requesting the use of the processor's memory in parallel, when an operating system sends a memory request command, it first performs a lock operation on the processor's memory, and only after the lock is successful can it request the use of the memory. A lock operation is an exclusive operation for memory request, and after the current operating system has successfully locked it, other servers will not have the right to request the use of the processor's memory unless the lock is released.

[0231] In one exemplary embodiment, performing a lock operation on the processor's memory includes determining whether the memory is currently in a locked state, where a locked state characterizes the memory as being in a state where it has been requested for use; performing a lock operation on the memory if the memory is not currently in a locked state; and determining that locking the memory has failed if the memory is currently in a locked state, and reapplying to lock the processor's memory after a preset duration until the memory is successfully locked or until the number of lock requests is greater than a preset number.

[0232] Before the processor operates, it is necessary to perform an operation to initialize the metadata storage area and the data storage area in the processor, and optionally to initialize the records stored in the state mapping table in the metadata storage area and to initialize the memory management information.

[0233] Before applying for memory, configure the memory management information as follows: typedef struct { uint32_t MemReady; uint32_t MemLock; }MallocMemInfo_T; Here, the member variable MemLoc of the structure MallocMemInfo_T indicates whether the initialization of the shared memory is complete, and the variable MemReady is 0xA5A5A5A5, which indicates that the initialization operation is complete and the memory can be dynamically claimed and released normally. The member variable MemReady of the structure MallocMemInfo_T indicates whether it is locked or not.

[0234] Optionally, if the read variable MemLock is 0, it means that there is no system or task requesting memory, that is, the memory is not currently locked. If the read variable MemLock is 0xA5A5A5A5, it means that there is a system or task requesting memory, and it needs to request again after the current request is completed, and the current request for locking has failed.

[0235] In one exemplary embodiment, when performing an operation to lock a memory, if there is a situation where the locking fails, the memory lock is applied again after waiting for a preset duration until the locking is successful, for example, the preset duration may be 100 microseconds. In one exemplary embodiment, if a lock request fails and the number of repeated requests exceeds a preset number, it indicates that the processor's memory is unavailable for allocation for the current duration, and the request operation is stopped. For example, the preset number may be three times, and if the number of lock requests exceeds three, a message is returned to the operating system that sent the request indicating that memory is currently unavailable.

[0236] Optionally, if there is a target virtual channel in the processor's memory space that can be provided for use by the first operating system, the first operating system stores the target data that needs to be transmitted in the corresponding target virtual channel, and in one exemplary embodiment, updates the occupation status of the processor's memory space according to the data writing status of the first operating system, i.e., changes the target contiguous memory space from an unoccupied state to an occupied state, and unlocks the memory to allow other systems or tasks to request the memory.

[0237] In one exemplary embodiment, the method further includes unlocking the memory if a preset number of consecutive target records have not been scanned. Optionally, if a predetermined number of contiguous, idle memory cells are not found after scanning the records in the state mapping table, this indicates that there are not enough memory pages in the processor's memory available for use by the first operating system, and the current dynamic memory request fails and the memory is unlocked.

[0238] In one exemplary embodiment, an interrupt notification message is sent to the second operating system in the manner of a software interrupt. Optionally, sending the interrupt notification message to the second operating system in the manner of a software interrupt includes writing an interrupt number and an ID of a CPU core of the second operating system to a preset register of the processor, and generating the interrupt notification message according to the interrupt number and the ID of the CPU core of the second operating system.

[0239] The software interrupt is selectively generated by software, and the software may send the interrupt to the CPU core that executes it or to another CPU core. The preset register may be a GICD_SGIR register, and software can write an SGI (Software Generated Interrupts) interrupt number and a target CPU ID to the GICD_SGIR register to generate a software interrupt, and the SGI interrupt number is a software interrupt number reserved for inter-core communication.

[0240] Alternatively, a hardware interrupt refers to an interrupt generated by a hardware device, and may be an interrupt of a private peripheral device or an interrupt of a shared peripheral device. The hardware interrupt is an interrupt triggered by hardware outside the CPU and is random, while the software interrupt is an interrupt triggered by software running on the CPU executing an interrupt command and is preset. In this embodiment, the method of the interrupt notification message is not limited.

[0241] In one alternative embodiment, a method for memory sharing is provided, the method including steps 1 to 3. In step 1, a memory request command is received and a lock operation is performed on the memory of the processor, where the memory request command is used to request the use of the memory of the processor.

[0242] Alternatively, the memory request command may be a command issued by an operating system running on the processor to request use of the processor's memory, and may be sent by the first operating system. To prevent conflicts caused by multiple operating systems requesting use of the processor's memory in parallel, when an operating system sends a memory request command, it first performs a lock operation on the processor's memory, and only after the lock is successful can it request use of the memory. The lock operation is an exclusive operation to request memory, and after the current operating system successfully locks it, other servers will not have the right to request use of the processor's memory unless the lock is released.

[0243] In a memory sharing method provided in an embodiment of the present application, before performing a lock operation on a memory of a processor, the method includes a step of determining whether the memory is currently in a locked state, where the locked state characterizes the memory as being in a state where it is requested for use, and a step of performing the lock operation on the memory if the memory is not currently in a locked state.

[0244] Optionally, when multiple systems or tasks request memory use in parallel, conflicting requests will occur. Therefore, the processor's memory can only be locked by one system or task at a time. Therefore, if the operating system detects that the memory is currently unlocked, it can only perform a lock operation on the memory.

[0245] Optionally, the memory is determined to be in a locked state by determining whether a preset variable stored in the memory is a preset value. If the preset variable is not a preset parameter value, it indicates that the memory is not in a locked state, there are no other systems or tasks requesting memory space, and the locking is successful. Conversely, if the preset variable is a preset parameter, it indicates that the memory is currently in a locked state, there are other systems or tasks other than the operating system requesting memory space, and the locking is unsuccessful.

[0246] The method for memory sharing further includes, after determining whether the memory is currently in a locked state, determining that an attempt to lock the memory has failed if the memory is currently in a locked state, and, if an attempt to lock the memory has failed, reapplying to lock the processor's memory after a preset duration until the memory is successfully locked or until the number of attempts to lock is greater than a preset number.

[0247] Optionally, when performing a memory locking operation, if there is a locking failure, the memory locking is reapplied for after waiting a preset duration until the locking is successful, for example, the preset duration may be 100 microseconds. In one exemplary embodiment, if a lock request fails and the number of repeated requests exceeds a preset number, it indicates that the processor memory is unavailable for allocation for the current duration, and the request operation is stopped. For example, the preset number may be three times, and if the number of lock requests exceeds three, a message is returned to the operating system that sent the request indicating that memory is currently unavailable.

[0248] In step 2, if the memory is successfully locked, read the occupied state of the memory, and determine whether there is an idle target memory space in the memory according to the occupied state of the memory, and the size of the target memory space is larger than the memory size requested by the memory request command.

[0249] After the lock request is successful, the operating system requests the processor's memory, and optionally scans the information for recording the memory occupation state in response to a memory request command issued by the operating system to determine whether the target memory space exists, that is, whether there is a memory space that is not occupied by the processor, is contiguous, and satisfies the memory usage requirements, where satisfying the memory usage requirements means that the memory space size is equal to or greater than the memory size requested by the operating system. In one exemplary embodiment, the determination is made as to whether the size of the unoccupied, contiguous memory space is greater than the memory size requested by the operating system, and a determination result is obtained.

[0250] When requesting memory, it is also possible to use non-contiguous memory space, and a pointer pointing to the smallest memory block to be acquired in the next request is added after the block that is not the smallest memory block, and when reading or writing data, data can be read or written across data blocks according to the stored address and pointer. In this embodiment, the form of the target memory space is not limited.

[0251] In step 3, if the target memory space exists in the memory, the address information of the target memory space is fed back to the sender of the memory request command, the occupied state of the memory is updated, and the memory is unlocked. Here, the sender is the operating system (e.g., the first operating system) that sends the memory request command. Note that when the operating system communicates between cores, it uses the shared memory to send and receive data, and during data transmission and reception, it accesses the data using the address returned by the requested memory, so it is necessary to determine the address information of the requested memory space.

[0252] Optionally, if there is a target memory space (which may be indicated by the above-mentioned judgment result) in the processor's memory space that can be provided for use 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 that needs to be transmitted in the corresponding memory space according to the address information.

[0253] In one exemplary embodiment, the occupation state of the processor's memory space is updated according to the data writing status of the operating system, i.e., the target memory space changes from an unoccupied state to an occupied state, and the lock operation before dynamically claiming the memory is released, thereby allowing other operating systems to claim the use of the processor's memory space.

[0254] The above steps solve the problems of low utilization efficiency, inflexibility, and excessive dependency on the operating system of shared memory between multiple kernels, and achieve the effects of improving the flexibility and utilization efficiency of shared memory and reducing dependency on the operating system. In the memory sharing method, the memory includes a metadata storage area and a data storage area, the data storage area is used to store service data, and the metadata storage area stores a state mapping table for recording the occupied state of the data storage area, and the step of reading the occupied state of the memory and determining whether an idle target memory space exists in the memory according to the occupied state of the memory reads a record in the state mapping table from the metadata storage area and determines whether a target memory space exists in the data storage area according to the record in the state mapping table.

[0255] The occupied state of the memory is queried by querying the records in the state mapping table, and the metadata storage area stored in the processor is selectively obtained to identify the state mapping table in the metadata storage area, and the occupied state of the data storage area is read by traversing the records in the state mapping table to determine whether the data storage area has a memory space that is contiguous, idle, and meets the memory usage requirements.

[0256] In a memory sharing method provided in an embodiment of the present application, the data storage area is composed of a plurality of memory pages, and the state mapping table includes a plurality of records, each of which records the occupied state of one memory page. The step of reading the records in the state mapping table from the metadata storage area and determining whether the target memory space is included in the data storage area according to the records in the state mapping table includes the steps of determining a predetermined number of memory pages requested by the memory request command, scanning each record in order from an initial position of the state mapping table, and determining that the target memory space exists in memory when the predetermined number of consecutive target records have been scanned, wherein the target record indicates that the memory page is in an idle state.

[0257] The data storage area is divided into multiple allocation units according to the same memory size, and each allocation unit is recorded as one memory page. For example, if the memory space of the data storage area is A bytes and the divided allocation unit is B bytes, the data storage area includes a total of A / B memory pages, and the records in the state mapping table are memory page records. Each memory page record is used to record the occupied state of one memory page, and the number of memory page records in the state mapping table is the same as the number of memory pages in the data storage area.

[0258] FIG. 6 is a schematic diagram of the relationship between the state mapping table and memory pages in a memory sharing method according to an embodiment of the present application. As shown in FIG. 6, the data storage area is a dynamically allocated memory block area, and the metadata storage area includes a dynamically allocated memory mapping table area. The mapping table area divides records into the same number as the number into which the data storage area is divided into memory pages, and these records are referred to as memory page records. All memory page records are combined into a state mapping table. All memory page records in the state mapping table have a one-to-one correspondence with all memory pages in the data storage area, and each memory page record represents the allocation status of the corresponding memory page, i.e., whether the memory page is occupied or not.

[0259] Optionally, the service data operated by the operating system needs to occupy consecutive memory pages of the processor, so first, the predetermined number of memory pages in the memory request command needs to be determined. Since the memory space of each memory page is the same, the predetermined number of consecutive memory pages needed can be calculated from the required memory space size, which is denoted as numb.

[0260] In one exemplary embodiment, after obtaining a state mapping table in a metadata storage area of ​​the processor, traverse the memory page records from an index position in the state mapping table, where the index position may be the starting position of the state mapping table. Starting from the starting position of the state mapping table, query each memory page record in the state mapping table in order to determine whether there are numb or more memory page records that record consecutive idle memory pages. If there are memory page records that meet the above conditions, determine that the target memory space exists in the processor according to the correspondence between the memory page records and the memory pages.

[0261] In the memory sharing method provided in the embodiment of the present application, after scanning each record in the state mapping table in order from the initial position, the method includes the step of determining that there is no target memory space in the memory when scanning all records in the state mapping table is completed and there is no predetermined number of consecutive target records.

[0262] Optionally, starting from the start position of the state mapping table, the memory page records of the state mapping table are queried to determine whether there is a space that is contiguous and has a number of memory pages equal to or greater than numb. If, after scanning the entire state mapping table, it is not found that there is a predetermined number of contiguous idle memory pages, it indicates that the target memory space does not exist.

[0263] In the memory sharing method provided in the embodiment of the present application, a counter records the number of scanned target records, and in the procedure of scanning each record in turn from the initial position of the state mapping table, when the currently scanned target record is reached, the counter is controlled to increment by 1; when the currently scanned non-target record is reached, the counter is controlled to clear to zero, and the non-target record indicates that the memory page is in an occupied state.

[0264] Optionally, the value of the counter is used to determine whether a predetermined number of consecutive target records exist, i.e., whether the target memory space exists, based on the magnitude relationship between the value of the counter and the number of required memory pages. Optionally, the count of the counter is designated as cntr. If the scanned memory page is empty, cntr is incremented by 1. If the scanned memory page is not empty, the accumulated number of consecutive, idle memory pages, cntr, is reset to zero. Then, starting from the address next to the memory page, a consecutive, empty memory page is searched for until cntr is equal to numb, which indicates that consecutive, idle memory pages that meet the memory requirements have been found. If cntr is less than numb before the entire state mapping table has been scanned, the dynamic memory request fails, indicating that the target memory space does not exist.

[0265] In the memory sharing method provided in the embodiment of the present application, when the initial position is the last position in the state mapping table, the step of feeding back address information of the target memory space to the sender of the memory request command includes the steps of determining the last scanned target record among a predetermined number of consecutive target records, and feeding back the starting address of the memory page indicated by the last scanned target record to the sender.

[0266] When scanning the state mapping table, the scanning method can be selected to start from the first position of the state mapping table or start from the last position of the state mapping table. When the scanning method is to start from the last position of the state mapping table, if the value cntr displayed on the counter is equal to or greater than a preset number numb, the last memory page scanned will be recorded in the starting address of the corresponding memory page, and the status of these memory pages will be set as not empty in the memory page record, and the starting address will be set as the starting address of all consecutive memory pages of this memory request command.

[0267] In one exemplary embodiment, the address is fed back to the operating system that issued the memory write command, and the operating system performs a data write operation to the memory according to the address information. In the memory sharing method provided in the embodiment of the present application, the initial position is the first position in the state mapping table, and the step of feeding back address information of the target memory space to the sender of the memory request command includes the steps of determining the first scanned target record from a predetermined number of consecutive target records and feeding back the starting address of the memory page indicated by the first scanned target record to the sender.

[0268] When the scanning method is selectively performed from the first position of the state mapping table, if the value cntr displayed on the counter is equal to or greater than a preset number numb, the address of the first scanned memory page record is taken as the starting address, and sent to the operating system that issued the memory request command, and the operating system performs a data write operation on the memory according to the address information.

[0269] In the memory sharing method provided in the embodiment of the present application, in the procedure of scanning each record in order 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. The selectable preset variable is a variable for storing address information of the initial position in the state mapping table, denoted as offset. In idle state, every time consecutive memory pages are scanned, the value cntr displayed on the counter is incremented by 1. If the value cntr displayed on the counter is equal to or greater than the preset number numb, the address information stored in offset is taken as the address of the first target record.

[0270] In the memory sharing method provided in the embodiment of the present application, after reading the occupied state of the memory and determining whether there is an idle target memory space in the memory according to the occupied state of the memory, the method further includes a step of unlocking the memory if there is no idle target memory space in the memory. Optionally, after scanning the memory page records in the state mapping table, if contiguous, idle memory pages that do not contain a predetermined number are found, i.e., do not contain the target memory space, this indicates that there are not enough memory pages in the processor's memory to provide for the operating system's use, and the current dynamic memory request fails, and the memory is unlocked.

[0271] In a memory sharing method provided in an embodiment of the present application, the memory includes a metadata storage area and a data storage area, the data storage area is used to store service data, and memory management information is stored in the metadata storage area. The step of determining whether the memory is currently in a locked state includes a step of reading the memory management information stored in the metadata storage area and determining whether the memory management information includes preset information, where the preset information characterizes the memory being in a locked state; a step of determining that the memory is not currently in a locked state if the memory management information includes the preset information; and a step of determining that the memory is currently in a locked state if the memory management information does not include the preset information.

[0272] When determining whether the processor memory is in a locked state, it is necessary to use memory management information in the metadata storage area to make the determination. Optionally, when the memory management information in the metadata storage area is obtained, it is determined whether the memory management information contains preset information, and the preset information is used to characterize whether the memory is in a locked state. If the memory management information does not contain the preset information, it indicates that the memory is currently in an unlocked state, and vice versa.

[0273] In the memory sharing method provided in the embodiment of the present application, the memory management information includes first field information and second field information, the first field information is used to describe whether the memory is in a locked state, and the second field information is used to describe whether memory initialization has been completed, and before receiving a memory request command, the method further initializes the first field information and the second field information stored in the data storage area.

[0274] Before the embedded system operates, it is necessary to perform initialization operations on the processor's metadata storage area and data storage area, and optionally initialize the memory page records stored in the state mapping table in the metadata storage area and perform initialization operations on the memory management information. Optionally, the memory management information comprises first field information and second field information, the first field information being used to characterize whether locked or not, and the second field information being used to characterize whether initialization is completed or not.

[0275] In the memory sharing method provided in the embodiment of the present application, the step of updating the occupied state of the memory includes the step of changing the state of the memory page corresponding to the target memory space recorded in the state mapping table to the occupied state. When the operating system needs to selectively occupy the target memory space, it identifies the address information of multiple memory pages in the target memory space, and updates the memory page records in the state mapping table area of ​​the metadata storage area according to the correspondence between the memory pages and the memory page records, changing the state from unoccupied to occupied.Furthermore, it updates the occupation state of the processor's memory space according to the data writing status of the operating system, that is, the target memory space changes from unoccupied to occupied, and releases the lock operation before dynamically applying for the memory.

[0276] Selectably, in response to a storage operation of the first operating system, the target data is stored in the target memory space, and address information of the contiguous memory space is sent to the second operating system, an acquisition command sent by the second operating system based on the address information is received, and the target data stored in the target memory space is sent to the second operating system.

[0277] Here, after successfully requesting the memory, the first operating system stores the target data to be transferred in the requested target memory space, and sends the address information of the target memory space to the second operating system cooperating with the first operating system to request 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 transmits the target data stored in the target memory space to the second operating system.

[0278] Through the above steps, a memory request command from the first operating system is received, and a lock operation is performed on the processor's memory. The memory request command is used to request the use of the processor's memory. If the memory is successfully locked, the occupied status of the memory is read, and according to the occupied status of the memory, it is determined whether an idle target memory space exists in the memory. If the size of the target memory space is greater than the memory size requested by the memory request command and the target memory space exists in the memory, the address information of the target memory space is fed back to the sender of the memory request command, the memory occupied status is updated, and the memory is unlocked. 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 second operating system receives a fetch command sent based on the address information, and the target data stored in the target memory space is sent to the second operating system. This solves the problems of low efficiency, low flexibility, and excessive dependency on the operating system when multiple kernels share memory, and achieves the effects of improving the flexibility and utilization efficiency of memory sharing and reducing dependency on the operating system.

[0279] In one exemplary embodiment, when a first operating system performs data read / write operations using a physical address and a second operating system performs data read / write operations using a virtual address, the second operating system converts the address information of the target memory space into a virtual address, accesses the memory using the virtual address, and reads the target data from the target memory space.

[0280] When using shared memory for inter-core communication to send and receive data, the address dynamically returned by the requested memory is used. However, the addresses used by different systems may be different. For example, the real-time operating system is the first operating system and the non-real-time operating system is the second operating system. When accessing shared memory in the real-time operating system, it can directly use the physical address, while the non-real-time operating system cannot directly use the physical address to access shared memory and must use the mapped virtual address. After the second operating system receives the address information of the target memory space, it converts it using the address information offset to map it to a virtual address and operates according to the virtual address. Optionally, the virtual base address vBase of the shared memory in the non-real-time operating system (assuming the real physical address of the shared memory is 0x96000000) and the physical base address pBase of the shared memory in the real-time operating system (i.e., 0x96000000) are used.

[0281] In the non-real-time operating system, the address returned by the dynamically requested memory is also a virtual address vData, and in the non-real-time operating system, Offset = vData - vBase, and data transmission is from the non-real-time operating system to the real-time operating system, and the real-time operating system uses the address pData to access the dynamically requested shared memory pData = pBase + Offset.In the real-time operating system, the address returned by the dynamically requested memory is a physical address pData, and in the real-time operating system, Offset = pData - pBase, and data transmission is from the real-time operating system to the non-real-time operating system, and the non-real-time operating system uses the address vData to access the dynamically requested shared memory vData = vBase + Offset.

[0282] In one exemplary embodiment, the memory includes a metadata storage area and a data storage area, and the metadata storage area and the data storage area are similar to those in the previous embodiment and will not be described in detail here. Optionally, the metadata storage area stored in the processor is acquired, a state mapping table is identified in the metadata storage area, and each memory page record is traversed starting from an index position in the state mapping table, and each memory page record in the state mapping table is sequentially referenced to determine whether there are a predetermined number or more consecutive memory page records that record idle memory pages, and if there are memory page records that meet the above condition, the correspondence between the memory page records and the memory pages determines that the target memory space exists in the processor. Determine do.

[0283] This embodiment further provides a memory sharing method, which includes the steps of: before an operating system issues a memory request command, requesting a lock operation and determining whether the lock is successful, in order to prevent request conflicts caused by multiple operating systems requesting processor memory space in parallel; if the determination result shows that the dynamically requested memory lock is successful, calculating the number of consecutive memory pages that need to be allocated according to the memory size in the issued memory request command, and denoting it as nmemb; if the determination result shows that the lock request is unsuccessful, waiting for a certain time (which may be 100 microseconds), and then issuing the request again until the request is successful; and if the number of failed lock requests is greater than a preset number (which may be 3 times), withdrawing from the memory request.

[0284] In one exemplary embodiment, after the lock request is successful, an initialization operation is performed on the metadata storage area of ​​the processor, the last position of the state mapping table is marked as offset, the number of required consecutive memory pages is calculated according to the size of the memory space required in the memory request command, the number of memory pages is marked as nmemb, a counter for recording the number of memory pages is set as cmemb, and then the state mapping table in the metadata storage area of ​​the processor is obtained, and the entire state mapping table is scanned starting from the offset position of the state mapping table, and the correspondence between the memory page records stored in the state mapping table and the memory pages in the data storage area is calculated. If the scanned memory page is occupied, offset=offset-cmemb, and the counter's accumulated data of consecutive empty memory pages, cmemb, is cleared to zero, and the search for consecutive empty memory pages is resumed from the new offset position. If the scanned memory page is empty, that is, in an idle state, the counter's value, cmemb, is incremented by 1 until cmemb is equal to nmemb, and offset=offset-1, and the next memory page is determined. That is, if the counter's data is equal to the required memory space size, it indicates that consecutive memory pages that meet the request have been scanned.

[0285] In one exemplary embodiment, the memory pages that match the request are marked as occupied in the corresponding state mapping table, the starting address of the last found memory page is taken as the starting address of the entire dynamically claimed contiguous memory pages, the dynamically claimed memory is unlocked, and the current dynamic memory claim is successful. In the process of scanning the entire state mapping table, if the offset value is less than 0, it indicates that there are no memory pages that match the request and are available for use by the operating system, and the dynamically requested memory is unlocked, and the current dynamic memory request has failed.

[0286] In addition, if it is found that there is insufficient space after dynamically allocating space, the size can be dynamically adjusted, and the updated memory application command can be issued again. A lock operation is performed on the memory, and if the lock is successful, if the memory space that the updated memory application command needs to apply for becomes larger, it is determined whether there is required memory space after the already-allocated target continuous memory, and if there is, the application is successful. If the memory space that the updated memory application command needs to apply for becomes smaller, part of the memory space is released.

[0287] In this embodiment, by dividing the memory area into multiple areas, the index position is used to dynamically request the amount of space actually required, and the space is released after use is complete. Furthermore, if it is discovered that there is not enough space after dynamically requesting the space, the size can be dynamically adjusted, thereby achieving the effect of improving the flexibility and utilization efficiency of the shared memory.

[0288] In one exemplary embodiment, the method further comprises: S221: 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; The method includes at least one of S222 merging processing resources of the first operating system that have been preempted by the second operating system or processing resources that the first operating system actively releases to the second operating system into an available resource pool of the second operating system.

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

[0290] For example, the resource adaptive scheduling module can cooperate with the processor framework of the first operating system and the processor framework of the second operating system to configure and implement a processor hard core resource pool, such as the SMP (Symmetrical Multi-Processing) framework of a Linux system, in which a group of processors (multiple CPUs) are aggregated in one computer, and each CPU shares a memory subsystem and bus structure, and SMP scheduling is a procedure for scheduling / migrating processes to an appropriate CPU to maintain load balance on each CPU.

[0291] Taking the Linux system as an example, the CPU scheduling method of an operating system is as follows: tasks (i.e., services) in a Linux system are generally maintained by a task queue, and a process scheduler determines which process (corresponding to a task) in the queue can be executed by a CPU. At the same time, a dispatcher module in the Linux system transfers CPU control to the process selected by the process scheduler. The selected CPU is from the CPU resource pool (i.e., the aforementioned available resource pool) in the Linux system, and the Linux system schedules these CPUs in the resource pool to participate in the actual operation of the process.

[0292] The process scheduler pauses one running process, moves this process to the running queue, and another process can start running. After a clock interrupt, an I / O (Input / Output) interrupt, or other type of system signal is received, the process scheduler determines which process in the ready queue and in main memory can be executed by the CPU (giving control of the CPU to this process).

[0293] According to this embodiment, by merging the scheduled processing resources into the available resource pool of the corresponding operating system, it is possible to facilitate the scheduling of processing resources and improve the efficiency of scheduling processing resources. In one exemplary embodiment, the method further comprises: The method includes a step S232 in which, after powering on the chip in which the processor is located, a boot loader program is used to boot and run a first operating system on a first initial processing resource, and a boot loader program is used to boot and run a second operating system on a second initial processing resource, wherein the first initial processing resource is an initial processing resource of the processor that corresponds to the first operating system, and the second initial processing resource is an initial processing resource of the processor that corresponds to the second operating system.

[0294] The entire system is divided into two phases according to the operating period: an initial startup phase and a real-time operation phase. The aforementioned dynamic scheduling of processing resources and other procedures are performed in the real-time operation phase. Regarding the initial startup phase, the initial startup phase begins after the system is powered on, i.e., after the chip containing the processor is powered on. After the system is powered on, one core is woken up to perform the boot operation of the operating system, and the remaining cores are temporarily in a sleep state. After powering on, the system first executes a preset core scheduling policy (boot loader program policy), i.e., one core of the processor executes the core scheduling policy. The core scheduling policy is stored in 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 that different operating systems need to run on (e.g., specifying the initial cores that the first operating system and the second operating system need to run on) and determining the boot procedures of the different operating systems.

[0295] In the processor's processing resources, the initial processing resource corresponding to the first operating system is the first initial processing resource, and the initial processing resource corresponding to the second operating system is the second initial processing resource. After the system is powered on, a boot loader program can be used to boot and run the first operating system on the first initial processing resource, and a boot loader program can be used to boot and run the second operating system on the second initial processing resource. Here, a boot loader program refers to a program located in a computer or other computer application that boots and loads an operating system.

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

[0297] After the system is powered on, a designated processor core of the processor is first woken up, and each operating system is booted so that the designated processor core starts up on the corresponding initial processing resource by a boot loader program. The boot loader program is a program for booting the loading of an operating system, for example, a specific program in Bootrom (CPU on-chip ROM), and the specific program is code that boots the operating system to start up, and belongs to the BootLoader program.

[0298] According to this embodiment, in the initial startup phase, each operating system is booted by a boot loader program to start on the initial processing resources corresponding to each operating system, thereby improving the success rate of the startup of the operating system and preparing for the real-time operation phase. In one exemplary embodiment, the first initial processing resource is one designated processor core among the processor cores of the processor, and the second initial processing resource is another processor core among the processor cores of the processor other than the designated processor core.

[0299] In this embodiment, the initial processing resources include initial processor cores, and 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 some processor cores other than the first initial processing resource. Optionally, to ensure system startup efficiency, the first initial processing resource may be one designated processor core among the processor cores of the processor, and the second initial processing resource may be another processor core other than the designated processor core among the processor cores of the processor.

[0300] For example, for an eight-core processor (CPU0 to CPU7), the designated processor core may be CPU0 (or some other processor core), i.e., the initial processing resource of the first operating system is CPU0, and the initial processing resource of the second operating system is CPU1 to CPU7. According to this embodiment, a designated processor core can be designated as the initial processing resource for one operating system, and another processor core of the processor can be designated as the initial processing resource for another operating system, thereby improving the convenience of boot-up.

[0301] In one exemplary embodiment, the step of booting and running the first operating system on the first initial processing resource by the boot loader program includes: S241 includes the step of booting and running the first operating system on the first initial processing resource by the secondary program loader. In this embodiment, the operating system can be booted up using a Second Program Loader (SPL), which is part of the code executed in the first stage of uboot, and migrates and runs the second stage code of uboot into memory. SPL is mainly responsible for the program code that loads the operating system into RAM. uboot is a boot loader program used in embedded systems, and is primarily used as a boot loader program for embedded systems. It supports a variety of different computer system architectures, such as PPC, ARM, AVR32, MIPS, x86, 68k, Nios, and MicroBlaze.

[0302] According to this embodiment, the secondary program loader boots and runs the corresponding operating system on the initial processing resource, which makes it possible to accommodate the existing system startup flow and improves system startup efficiency. In one exemplary embodiment, the method further comprises: The method includes a step S251 in which a security startup check is performed on the code of the secondary program loader by a preset program in a startup chip fixed to the motherboard of the device, the secondary program loader being executed after the check result of the security startup check is normal.

[0303] Before using the secondary program loader to boot and run the operating system, in order to improve the success rate of booting the operating system, a pre-set program in a boot chip fixed on the motherboard of the equipment performs a security boot check on the code of the secondary program loader to determine whether the secondary program loader is normal; if the security boot check result of the secondary program loader is normal, the operating system can be booted to run by the secondary program loader; if the security boot check result of the secondary program loader is abnormal, an abnormality is indicated and the operating system boot procedure is aborted.

[0304] For example, after the system is turned on, some cores are configured to boot a specific program in Bootrom, and the Bootrom program (a group of programs fixed in a ROM chip on the device's motherboard) performs a security startup check on the code in the SPL section, and if the check result is normal, the SPL code is executed. This embodiment improves the security of operating system startup by checking the security startup of the secondary program loader.

[0305] In one exemplary embodiment, the step of booting and running the second operating system on the second initial processing resource by the boot loader program includes: The method includes S261, in which the second initial processing resource is woken up by the secondary program loader, and the general-purpose boot loader program is booted and executed to boot and run the second operating system.

[0306] When booting and running the second operating system, the secondary program loader first wakes up the second initial processing resource, then boots and runs a general-purpose load program to boot and run the second operating system. For example, the SPL boots and runs the first operating system on some cores (e.g., core 1, CPU 0), while waking up other cores (e.g., cores 2 to M+N, CPU 1 to CPU M+N-1) to boot and run uboot code (a boot loader program mainly used in embedded systems), and then boots and runs the second operating system. Through this phase, the server management control unit BMC system can achieve normal booting of the first operating system and the second operating system based on one or more processor cores, and prepare for the real-time operation phase.

[0307] This embodiment can improve the efficiency of booting and running the system by first waking up the initial processing resources, booting and running a general-purpose boot loader program, and then booting and running the corresponding operating system. The operation of the embedded system in this embodiment will be explained below with reference to an alternative example, in which the first operating system is an RTOS system, the second operating system is a Linux system (or may be another non-real-time operating system), and the processing resource is a processor core.

[0308] In order to enable the normal operation of various types of services in an embedded system, improve the utilization rate of processor cores, and keep server hardware costs within a reasonable range, this optional example provides a method for dynamically balancing processor resources among embedded heterogeneous multi-systems. Based on a multi-core processor core, different service types are scheduled to run on different core groups according to a core adaptive scheduling (i.e., resource adaptive scheduling) method, and by combining system architecture designs such as service management, load balancing, dynamic resource allocation, and inter-core communication interface, the effect of real-time embedded heterogeneous operating systems and non-real-time embedded heterogeneous operating systems running in parallel on multiple cores of the same processor can be achieved, which can improve the overall utilization rate of processor cores and significantly reduce the input of hardware acceleration resources required to handle real-time services. At the same time, the multi-core processor can use a high-speed internal bus to significantly improve communication performance, significantly reduce design costs, and achieve the goal of improving computing performance.

[0309] Taking the BMC management unit in a server platform (which can be applied to any embedded product using a multi-core SOC, such as mobile phones, tablets, set-top boxes, etc.) as an example, the operation method of the embedded system in this example can be divided into two stages: the initial startup stage and the real-time operation stage. Referring to the architecture for realizing dynamic balance scheduling of processor resources among embedded heterogeneous multi-systems shown in Figure 7, in the initial startup stage, the CPU balance scheduling procedure is as shown in Figure 8. The above procedure is as follows: Step S802 of arranging a specific program in a part of the core boot Bootrom; Step S804: The Bootrom program (i.e., the specific program mentioned above) checks the security boot against the SPL (stored in Norflash). (The security boot check mainly involves hash verification of the uboot, Linux, and RTOS mirror image to be booted, and comparing the obtained result with the stored result. If the comparison results match, the boot will be successful, and if they do not match, the boot will fail. The SPL allocates some CPU registers to select which core to wake up and from which address to load the system mirror image.) Step S806: determining whether the security check has been passed, and if the security check has been passed, executing step S808, and if the security check has not been passed, executing step S810; Step S808: Execute the SPL code, and the SPL boots and runs an RTOS system on some cores, while waking up other cores to boot and run uboot code, and further boot and run a Linux system; and step S810, which ends the process.

[0310] After the heterogeneous operating systems are booted, the system enters a real-time operation phase. Referring to Figure 7, the real-time operation phase is completed through the cooperation of functional modules such as load balance policy, service management, dynamic resource allocation, core adaptive scheduling (i.e., resource adaptive scheduling), core preemption and release, and inter-core communication. Combining Figures 7 and 9, during the real-time operation phase, the flow of the embedded system operation method in this selectable example includes steps S902 to S908.

[0311] In step S902, the service management module performs actual classification of the services to be allocated according to the output of the load balance policy module, and generates a list including real-time services and a list including non-real-time services. The load balance policy module provides policy guidance to the service management module, including methods for classifying various services (or processes) running in the system, real-time level evaluation principles, etc. After the RTOS system and Linux system boot up, the service management module performs actual classification of services to be allocated according to the output of the load balance policy module, and generates a list including real-time services and a list including non-real-time services. The two lists output by the load balance policy module are used to represent the correspondence between services and operating systems.

[0312] In BMC applications, a large number of service processes must run on the server platform to achieve robust and comprehensive management of the server platform. At this time, the service management module can rationally classify these services. A feasible classification method divides services such as server health monitoring, IPMI (Intelligent Platform Management Interface) interaction, component monitoring, serial port redirection, asset information management, and Web access into non-real-time services, and services such as fan control and PECI (Platform Environment Control Interface) communication into real-time services.

[0313] In step S904, the resource dynamic allocation module dynamically adjusts processor resources (such as processor hard core and controller logic unit) according to the output result of the service management module, and forms a resource mapping table between different services and actual hardware resources.

[0314] The mapping table formed by the resource dynamic allocation module is a resource mapping table between services and processor resources, that is, it includes processor resources that have been allocated to each operating system and processor resources that are not allocated to any operating system. When mapping services to actual hardware resources, the processor cores of the RTOS system are preferentially allocated to real-time services. When one or more services are allocated to any of the processor cores of the RTOS system, the unallocated processor cores are considered to be allocated to real-time services. The processor cores of the Linux system are allocated to non-real-time services. When one or more services are allocated to any of the processor cores of the Linux system, the unallocated processor cores are considered to be allocated to real-time services. Therefore, there are situations in which the unallocated processor cores are allocated to real-time services or non-real-time services.

[0315] In actual applications, hardware resources such as the BMC's processor cores and peripheral controllers are dynamically mapped to the BMC's actual services. After the server is started, core 1 in the BMC runs the RTOS system and controls the PWM (Pulse Width Modulation) and PECI peripheral controllers to adjust the fan speed and provide fault diagnosis services. Cores 2 through N run the Linux system and control controllers such as I2C (Inter-Integrated Circuit) to provide component monitoring services. During system operation, a dynamic allocation list of BMC resources is dynamically generated according to conditions such as system load, in preparation for the next step of the core adaptive scheduling procedure.

[0316] Here, the output resource mapping table may be X cores and xxx controllers (some types of controllers) for real-time services, and Y cores and xxxx controllers (some types of controllers) for non-real-time services. Some services not only depend on computing resources (corresponding processor cores) but also on specific hardware interfaces (corresponding controllers on SOCs). For example, if a service needs to use a network interface, the service and the corresponding network controller must be separated into the same operating system (RTOS system or Linux system).

[0317] In step S906, the core adaptive scheduling module completes an actual scheduling operation on the processor hard core resources according to the result of the dynamic allocation of hardware resources.

[0318] The core adaptive scheduling module actually schedules the processor hard core resources according to the output results of the service management module and the dynamic resource allocation module. For example, it schedules part of the processor hard core to run real-time services such as M cores in core group 1 in FIG. 6, and schedules the remaining processor hard core to run non-real-time services such as N cores in core group 2 in FIG. 6. The entire scheduling procedure is dominated by the Linux system, specifically, an SMP framework that can cooperate with Linux is realized by setting up a processor hard core resource pool. Here, the total number of available cores of the processor is M+N, where M≧1 and N≧1.

[0319] In step S908, while the system is running in real time, the core preemption and release module performs dynamic preemption and release for processor cores between heterogeneous operating systems. The preemption and release procedures depend on the real-time load conditions of the heterogeneous operating systems to maximize processor resource utilization. For example, if the number of users remotely accessing the BMC increases from 1 to 20, the BMC's web access service volume will rise sharply, requiring the Linux system to support more processor cores. In this case, the Linux system issues a core preemption request to the RTOS system via IPI. If the RTOS system is idle (i.e., there is no task scheduling), it will release core resources to the Linux system. The Linux system then successfully preempts the core, meaning that Linux obtains more processor resources to handle the newly added service requirements. The core preemption and release mechanism significantly improves the user experience in remote server management.

[0320] The core preemption and release procedure is a dynamic cyclic iteration procedure, and each core preemption and release always involves an adjustment of processor hard core resources. As shown in Figure 6, after one 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. In addition, the core preemption and release procedure cooperates with modules such as load balancing policy, service management, and core adaptive scheduling to jointly determine the final core adjustment result.

[0321] The above-mentioned cyclical repetition refers to the fact that, while the system is operating normally, the RTOS system and the Linux system constantly perform resource preemption and release actions due to resource shortages on one side. This cyclical operation procedure involves the collaborative operation of modules such as "service management (service management is a dynamic partitioning procedure) - dynamic allocation of hardware resources - core adaptive scheduling." The above-mentioned multiple modules are all non-real-time systems (Linux systems), and most of the main services are considered to be Linux systems, making it easier to obtain and sense more information and status.

[0322] The above-mentioned multiple modules jointly determine the core allocation result. This means that when a system needs to preempt more core resources, modules such as the load balance policy, service management, and core adaptive scheduling must jointly determine whether the preemption is ultimately successful. For example, if a Linux system requires more resources, the RTOS system may be in a sleep-idle state at the time. However, the RTOS system must immediately wake up an important service thread to run. Because this thread requires a large amount of resources, the RTOS system cannot release the core resources to the Linux system. The resource scheduling procedure involves the participation of modules such as the load balance policy, service management, and core adaptive scheduling, in determining the service importance and ultimately not allocating resources to the Linux system. The policies of these modules are also characterized by openness, so the final core allocation result determined by their joint decision is the result of the collaboration of these policies.

[0323] Here, after the RTOS system goes to sleep, it does not completely occupy the CPU's core resources. When it wakes up (for example, a peripheral device or a wake-up timer generates an interrupt to trigger the wake-up operation), it regains control of the specified core resource (for example, core 0) via an inter-core interrupt. From the sleep state to regaining core control, the RTOS system does not require the participation of the core at any time.

[0324] Below, we will use an 8-core processor (core 1 to core 8) as an example to interpret and explain the method of dynamic balance scheduling of processor resources between embedded heterogeneous multi-systems. Assuming that the real-time operating system and the non-real-time operating system are an RTOS system and a Linux system, respectively, the dynamic balance scheduling flow of processor resources includes steps 1 to 5.

[0325] In step 1, the system is powered on and the preset boot-up policy is run, booting the RTOS system based on core 1 (CPU0), and core 8 (CPU7) booting the Linux system. In step 2, the service management module of the Linux system realizes real-time level division of system services based on the load balance policy module, and obtains a list of real-time services and non-real-time services. Assuming there are a total of 20 services, among them, the real-time services are Service 1 and Service 2, and the non-real-time services are Service 3 to Service 20.

[0326] In step 3, according to the service list output by the service management module, the resource dynamic allocation module and the core adaptive scheduling module are launched, and the eight processor cores are divided into processor core group 1 (assumed to include cores 1 and 2) and core group 2 (assumed to include cores 3 to 8) using the SMP framework of the Linux system. In this case, the system allocates the resources of core group 1 to the RTOS operating system to execute services 1 and 2, and allocates the resources of core group 2 to the Linux system to execute services 3 to 20.

[0327] In step 4, during system operation, the RTOS operating system and the Linux operating system both monitor their respective load conditions. When one side determines that the service load is too heavy, it initiates a core preemption operation through the inter-core communication interface. When the other side receives a core preemption request, it determines whether to release hard core resources to the other side according to its own load condition.

[0328] For example, the Linux system may detect a sudden increase in its own load at a certain point and initiate a core preemption interrupt request (corresponding to the SGI interrupt with interrupt number 9 in Table 1) to the RTOS system via the inter-core communication interface before its computing resources are depleted. After receiving the core preemption interrupt request, the RTOS system checks whether its cores are busy or idle. If it finds an idle core (e.g., core 2 is idle), it releases core 2 and sends a core release interrupt response signal (corresponding to the SGI interrupt with interrupt number 10 in Table 1) to the Linux system via the inter-core communication interface. After the Linux system receives the interrupt response signal, it merges core 2 into the available resource pool via the SMP framework. In this case, the processor hard disk performs a new adjustment: the RTOS system occupies core 1, and the remaining seven cores are occupied by the Linux system.

[0329] In step 5, the system load status is updated and the process returns to step 2. Unlike the related art's multi-core single system and multi-core fixed multi-system (each core running a specific operating system), the method provided in this alternative example dynamically allocates different hardware processor cores to real-time operating systems and non-real-time operating systems according to actual service requirements, realizing a dynamic scheduling design of processor resources among embedded heterogeneous multi-systems based on processor cores from the software and hardware system architecture level. Because the processor cores can be dynamically allocated, heterogeneous operating systems coexisting in the system can obtain reasonable processor computing resources according to their own service load situations, while improving the processor's processing ability for real-time services, comprehensively increasing the utilization rate of processor cores, improving computing performance, and achieving the purpose of saving hardware costs.

[0330] In one preferred application scenario, the operating method of the embedded system in this embodiment will be explained below in conjunction with an application scenario in which two operating systems alternately control the operating state of the same device (i.e., target device), where the processing system of the first operating system includes a first processor core of a processor, and the processing resources of the second operating system include a second processor core of the processor. In this embodiment, a boot control procedure for the operating systems is provided, which includes steps A to C.

[0331] In step A, a first operating system running on a first processor core of the processor controls a hardware controller of the target device via a second bus, thereby controlling the operating state of the target device. A server, a personal computer, an industrial computer, or other device may be equipped with several specific devices that perform operations related to the device's operation. In the related art, these specific devices typically start operating when the system is powered on. After the system is powered on, an operating system running on the processor must wait a certain period before it can take over management of the specific devices and control their operating status. During the operating system's startup procedure, the specific devices are uncontrollable.

[0332] For example, after the system is powered on, the fan starts to operate. After the system is powered on, the operating system running on the CPU only takes over fan management and can set the fan speed after a certain period of time has elapsed. Therefore, the fan is out of control during the operating system startup procedure.

[0333] For example, to achieve fan control during the operating system startup procedure, servers use a control method that combines a BMC and a CPLD, personal computers use an EC chip control method (the EC chip has the function of adjusting the fan speed according to the temperature), and industrial computers use a customized chip control method. In the startup procedure of the operating systems of servers, personal computers, and industrial computers, the CPLD, EC chip, and customized chip intervene to control the fan speed, and wait for the operating system to fully start before handing over control of the fan to the application program in the operating system.

[0334] To at least partially solve the above technical problems, a startup control method for a multi-core multi-system (e.g., a multi-core double system) can be used, in which different operating systems of an embedded system run on different processor cores of a processor, and the response speeds of the different operating systems are different. When the second operating system is not started, restarts, or cannot control the operating state of a specific device, the first operating system, which has a higher response speed than the second operating system, controls the operating state of the specific device, thereby reducing the situation where the operating state of the specific device cannot be controlled, and also has very good scalability without requiring additional costs.

[0335] In this embodiment, when the second operating system is not running, when rebooting, or when it cannot control the operating state of a specific device, the first operating system controls the hardware controller of the target device via the second bus to control the operating state of the target device. The target device here may be a fan or a device that needs to operate when the system starts up. The corresponding hardware controller for the fan is a fan controller, such as a PWM (Pulse Width Modulation) controller or a FanTach (fan rotation speed) controller. Using the first operating system (e.g., an RTOS system) instead of a conventional CPLD, EC chip, or customized chip reduces hardware costs, while the device control is implemented by software, providing high scalability.

[0336] For example, a dual system, an RTOS system, and a Linux system are implemented based on the BMC dual core, and a fan is implemented based on the multi-core dual system. By utilizing the high real-time characteristics of the RTOS system, during the startup procedure of the Linux system, the RTOS system controls the fan instead of the CPLD, EC chip, or customized chip, that is, it takes over management of the fan control rights and controls the operating status of the fan at a sufficiently fast speed.

[0337] In step B, booting is performed to start a second operating system on a second processor core of the processor. When the system is powered on or the second operating system is restarted, the second operating system can be run on the second processor core by booting the second operating system on the second processor core of the processor. Here, booting the second operating system on the second processor core means scheduling the second processor core to the second operating system and storing system files or mirror files of the operating system in memory on or off the chip where the processor resides, such as an external RAM.

[0338] In step C, after the second operating system is started, the second operating system assumes control of the target device by assuming control of the hardware controller via the second bus.

[0339] After the second operating system has finished booting, the first operating system can always control the operating state of the target device. Considering the need for data interaction between multiple operating systems running on a multi-core processor and the need for one operating system to control the entire device, the second operating system may assume control of the target device. For example, the second operating system may assume control of a hardware controller via a second bus. The second operating system may assume control of the target device by sending a request to the first operating system to assume control of the device after booting, for example, by sending an interrupt request via the first bus to request that the first operating system assume control of the hardware controller of the target device. The first operating system may receive the request to assume control of the device sent by the second operating system, transfer control of the target device to the second operating system, and perform operations related to the transfer of control of the target device, such as stopping the operation of a service (process) for controlling the operating state of the target device.

[0340] For example, after the Linux system has fully booted, the RTOS system will hand over control of the fan to the Linux system, which will then control the fan. The above procedure can be performed after the system is powered on, or by using a multi-core dual-system boot method to start the RTOS system first, which is advantageous for early intervention in fan control, and waiting for the Linux system to fully boot before the RTOS system hands over control of the fan to the Linux system.

[0341] In one exemplary embodiment, before a first operating system running on a first processor core of the processor controls a hardware controller of the target device via a second bus, and after powering on the chip on which the processor resides, the method includes waking up the first processor core by the processor, and running a boot loader program of the first operating system by the first processor core, thereby booting the first operating system to start on the first processor core.

[0342] The entire system can be divided into two stages, an initial startup stage and a real-time operation stage, according to the operation period, and the startup control method in this embodiment may be performed in either the initial startup stage or the real-time operation stage. Regarding the initial startup stage, the initial startup stage begins when the system is powered on, i.e., when the chip containing the processor is powered on. After the system is powered on, one core is woken up to perform the boot operation of the operating system, and the remaining cores are temporarily in a sleep state, and the woken up core may be the first processor core.

[0343] Optionally, after powering on, the system will first execute one preset core scheduling policy (boot-up policy), that is, one processor core of the processor will execute the core scheduling policy. The core scheduling policy can be stored in RAM or Norflash (non-volatile flash memory) on the SOC chip, and the scheduling policy can be flexibly set according to different design requirements. Its main functions include specifying the initial processing resources (processor cores) that different operating systems need to run on and determining the boot procedures of the different operating systems. Powering on the chip refers to powering on at the SOC chip level.

[0344] After waking up the first processor core, the boot loader program can boot the first operating system on the first processor core to run it, which may mean that the first processor core boots the first operating system to run on the first processor core through the boot loader program. The boot loader program may be located in a computer or other computer application and refers to a program for booting the loading of an operating system, such as a specific program in a Boot ROM, where the specific program is code that boots the operating system to run and belongs to the Boot Loader program. The Boot ROM is a small masked ROM (Read-Only Memory) or write-protected flash memory built into a processor chip on a CPU chip.

[0345] In the initial startup stage, the boot loader program boots the operating system to start on the corresponding processor core, improving the success rate of the operating system startup and preparing for the real-time operation stage. In one exemplary embodiment, the step of a first operating system running on a first processor core of the processor controlling a hardware controller of a target device via a second bus includes the steps of: executing a first control task of the first operating system on the first processor core, the first control task being used to control the hardware controller; reading sensor data of a designated sensor corresponding to the target device by the first processor core; and the first control task sending a device control command to the hardware controller via the second bus in response to the sensor data of the designated sensor, and the hardware controller controlling the operating state of the target device in accordance with the device control command.

[0346] The operating system's control of the hardware controller of the target device may be such that a control task (service) on a processor core operated by the operating system controls and executes the hardware controller, and the control task may be a corresponding control task. The hardware controller of the target device may execute a first control task (first control process) of a first operating system on a first processor core, and the first control task controls the hardware controller.

[0347] Control of the hardware controller may be performed based on sensor data from a sensor. Parameters affecting the operation of different target devices may differ, and the sensor data required to be acquired may also differ accordingly. The target device may be a device that operates after the chip is powered on, and the corresponding sensor is a designated sensor. The designated sensor may be of multiple types, including but not limited to, at least one of a temperature sensor, a humidity sensor, a noise sensor, etc. Since the first control task is running on the first processor core, the first processor core reads sensor data from the designated sensor. The sensor data from the designated sensor may be stored in a memory space within the designated sensor or transmitted by the designated sensor to the designated memory space. In this embodiment, the location from which the sensor data from the designated sensor is read is not limited.

[0348] The read sensor data of the designated sensor may be sensor data within one time period, all sensor data since the target device was started, or sensor data that satisfies other time limit conditions. After acquiring the sensor data of the designated sensor, the first control task can control the operating state of the target device according to the sensor data of the designated sensor. The control of the operating state of the target device can be implemented in the following manner: the first control task sends a device control command to a hardware controller of the target device, and the hardware controller controls the operating state of the target device according to the device control command.

[0349] Optionally, the first control task may determine an expected operating state of the target device based on sensor data from a designated sensor, and if the current operating state of the target device differs from the expected operating state, generate the above-mentioned device control command, which may control the operating state of the target device to adjust to the expected operating state. The above-mentioned device control command may be transmitted to a hardware controller of the target device via a second bus. The second bus is similar to that in the previous embodiment, and therefore will not be described here.

[0350] The sensor data of a specified sensor is read and the target device is controlled according to the sensor data, thereby controlling its operating state and improving resource utilization. In one exemplary embodiment, the step of transmitting an equipment control command to the hardware controller via the second bus in response to sensor data of a specified sensor by the first control task includes the step of determining, by the first control task, a target parameter value of an equipment operating parameter of the target equipment in response to the sensor data of the specified sensor, the equipment operating parameter being a parameter for controlling the operating state of the target equipment; and transmitting, by the first control task, the equipment control command including the target parameter value to the hardware controller via the second bus.

[0351] The first control task may determine an expected operating state of the target equipment according to sensor data from a specified sensor. The expected operating state is represented by a parameter value of an equipment operating parameter. The equipment operating parameter may be a parameter that controls the operating state of the target equipment. Different types of equipment may have different corresponding equipment operating parameters. For example, a corresponding equipment operating parameter of a fan may be a rotation speed, and the equipment operating parameter of other types of equipment may be other operating parameters. The expected operating state may correspond to a target parameter value of the equipment operating parameter of the target equipment.

[0352] After determining the target parameter value of the device operating parameter of the target device, the target parameter value can be included in the above-mentioned device control command, that is, the first control task can send the device control command including the target parameter value to the hardware controller. The method of sending the device control command to the hardware controller is similar to that in the above-mentioned embodiment, and detailed description thereof will be omitted here.

[0353] The parameter values ​​of the target appliance operating parameters are determined according to the sensor data, and the determined parameter values ​​are included in the appliance control command, thereby improving the accuracy of appliance control. In one exemplary embodiment, determining a target parameter value for an equipment operating parameter of the target equipment in response to sensor data from a designated sensor by the first control task includes, if the target equipment is a fan, determining a target parameter value for a fan operating parameter of the fan in response to sensor data from the designated sensor by the first control task.

[0354] The target device may be a fan, such as a fan for dissipating heat in a server or other device. In this case, the device operating parameters may be fan operating parameters. The fan operating parameters may include one or more types, such as at least one of a rotation speed, a rotation period, and a period switching time, but are not limited thereto. Other operating parameters may also be used. This embodiment is not limited thereto.

[0355] Correspondingly, the step of determining a target parameter value for an equipment operating parameter of the target equipment in accordance with the sensor data of the designated sensor by the first control task includes the step of determining a target parameter value for a fan operating parameter of the fan in accordance with the sensor data of the designated sensor by the first control task. After obtaining the target parameter value, the first control task transmits an equipment control command including the target parameter value to a hardware controller of the fan via the second bus, thereby controlling the operating state of the fan.

[0356] By controlling the operating state of the fan, the operating state of the fan can be quickly controlled in a scenario where the system is powered on, a scenario where the system is restarted, or other scenarios, thereby improving the timeliness of the fan control. In one exemplary embodiment, when the target device is a fan, the step of determining a target parameter value of a fan operating parameter of the fan according to sensor data of a designated sensor by a first control task includes, when the target device is a fan and the designated sensor is a temperature sensor, determining a target rotation speed value of a rotation speed of the fan according to sensor data of the temperature sensor by the first control task, wherein the rotation speed of the fan is positively correlated with the temperature detected by the temperature sensor.

[0357] In a scenario where the target device is a fan, the designated sensor may be a temperature sensor, the number of the temperature sensors may be one or more, the installation positions of the temperature sensors may be arranged as needed, and different temperature sensors may be installed at different positions. Optionally, the sensor data of the temperature sensor is used to represent a temperature detected by the temperature sensor, and in this regard, the first control task can determine a target rotation speed value of the fan rotation speed according to the sensor data of the temperature sensor, and the fan rotation speed is positively correlated with the temperature detected by the temperature sensor.

[0358] When there are multiple temperature sensors, the maximum temperature detected by the multiple temperature sensors can be determined according to the sensor data of each temperature sensor, and the fan rotation speed is determined according to the maximum temperature detected by the multiple temperature sensors, thereby ensuring the security of equipment operation compared to determining the fan rotation speed according to the average temperature detected by the multiple temperature sensors. In a scenario where there are multiple fans, the rotation speed of each fan is determined based on the maximum or average temperature detected by the temperature sensor matching each fan.

[0359] For example, a first operating system (e.g., an RTOS system) can be used to control the fan speed (control the BMC fan in real time) instead of a processing unit such as a CPLD, EC chip, or customized chip. After the system is powered on, the first processor core (e.g., CPU0, which may be woken up by hardware) is woken up, and the first processor core runs a boot loader program (e.g., a program specified in BootROM), loads and starts the first operating system, and reads data from various temperature-related sensors to control the fan (e.g., control the fan speed), fully simulating the function of the processing unit to complete the fan adjustment. When controlling the fan speed, the first operating system can calculate a PWM value according to the temperature sensor and then adjust the fan speed. This method allows the first operating system to control the fan speed while the second operating system is running.

[0360] In one exemplary embodiment, the step of booting to launch a second operating system on a second processor core of the processor includes the steps of executing a secondary program loader by the first processor core, which causes the secondary program loader to wake up the second processor core, and running a generic boot loader of the second operating system by the second processor core, which causes the second operating system to boot to launch on the first processor core.

[0361] In this embodiment, when starting the operating system, a secondary program loader can be loaded into an internal memory such as a static random access memory (Static RAM, SRAM) inside the SOC, and the SPL can be responsible for loading a universal boot loader program (Universal Boot Loader, abbreviated as U-Boot) into the random access memory. The secondary program loader can boot and load the second operating system, and can also boot and load the first operating system.

[0362] In the case of the second operating system, the first processor core may execute a secondary program loader, which may wake up the second processor core, and the second processor core may run a generic boot loader (general-purpose boot loader program) for the second operating system, thereby booting the startup of the second operating system on the first processor core. Here, the secondary program loader boots and loads a boot program for the second operating system, which may include a generic boot loader.

[0363] The secondary program loader is the code executed in the first stage of a general-purpose boot loader program and can be responsible for transporting and running the second stage code of the general-purpose boot loader program in system memory (also known as system RAM or off-chip memory). The general-purpose boot loader program is open source software that complies with the General Public License (GPL) protocol and can be considered a bare computer integration routine.

[0364] For example, after powering on the system, the processor first wakes up the CPU0 core to make the RTOS system run as quickly as possible, then boots the RTOS system using a program in BootRom, and while the RTOS system is booting, it subsequently loads U-Boot using SPL, and U-Boot boots the second operating system on CPU1 until the Linux system boots successfully.

[0365] Boot ROM is a fixed program in the ROM inside a chip (e.g., an SOC chip) and is the boot code of uboot. Boot ROM reads the hardware boot information (e.g., DIP switch settings) and reads the uboot-spl code (i.e., SPL) from the specified boot medium (e.g., SD, MMC, etc.). SPL is mainly responsible for initializing the external RAM and environment, and then loads and executes the true uboot mirror image into the external RAM. The external RAM can be DDR (Double Data Rate Synchronous Dynamic RAM) or other RAM.

[0366] After the second processor core is woken up by the secondary program loader, the second processor core runs a general-purpose boot loader program, thereby booting the second operating system on the corresponding processor core, thereby improving the convenience and success rate of operating system startup.

[0367] As an example of a selectable system, the startup procedure of a multi-core dual system is explained below using an RTOS system and a Linux system.

[0368] In order to take over fan management as early as possible, the RTOS system is started as soon as possible, and after the Linux system has finished booting, the Linux system takes over fan control. The startup procedure for the multi-core dual system is as follows: Step 1 wakes up CPU0 immediately after powering on the system, Step 2: CPU0 runs a specified program in BootROM, loads the RTOS system, and starts it up. In the procedure for starting the RTOS system, step 3 wakes up CPU1 to boot u-boot and starts a fan control program (FanCtrl_RTOS_APP) in the first operating system; The steps of CPU1 booting u-boot include an SPL stage and a Uboot stage, and step 4 enters the SPL stage by calling SPL; Step 5: In the SPL stage, SPL boots to start Uboot. Step 6 includes loading the Linux cores (CPU1 to CPUN) at the Uboot stage and starting the BMC service program and the fan control program (FanCtrl_Linux_APP) in the second operating system.

[0369] In this alternative example, in the boot and operation procedure of the dual system, the RTOS system is first started to control the fan, and after the Linux system is started, the second operating system takes over management of fan control, thereby ensuring that the fan is quickly controlled when the system is powered on and improving the efficiency of fan control. In one exemplary embodiment, after the second operating system takes over management of the hardware controller via the second bus, if the second operating system is to reboot, the second operating system wakes up the first operating system via the first bus, and the first operating system takes over management of the hardware controller via the second bus, takes over management of the target device, and controls the second operating system to reboot the system.

[0370] When a reboot is required due to a system crash, receipt of a reboot command, etc., the second operating system first wakes up the first operating system, which then assumes control of the hardware controller and the target device. The first operating system's wake-up can be performed via the first bus, and the first operating system's assumption of control of the hardware controller can be performed via the second bus.

[0371] When the second operating system is rebooted, the first operating system is woken up to take over management of the control of the target device, thereby improving the reliability of device control. In one exemplary embodiment, the step of the second operating system waking up the first operating system via the first bus when the second operating system is to restart includes the second operating system sending a system wake-up interrupt to the first operating system via the first bus when the second operating system is to restart, and the system wake-up interrupt is used to wake up the first operating system.

[0372] Waking up the first operating system can be achieved by an inter-core interrupt. When the second operating system needs to reboot (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 up the first operating system. The system wake-up interrupt can be an active wake-up interrupt. After the first operating system takes over management of the hardware controller, it controls the second operating system to perform a system reboot. After the second operating system reboots, it takes over management of the hardware controller again. The procedure for taking over management of the hardware controller is similar to that of the previous embodiment, and therefore will not be described in detail here.

[0373] From the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be realized by adding a necessary general-purpose hardware platform to software, and of course, can also be realized by hardware, but the former is often a more preferred embodiment. Based on this understanding, the essential part of the technical solution of the present application, in other words, the part that contributes to the related art, can be embodied in the form of a software product, and the computer software product is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk) and includes several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to execute the method of each embodiment of the present application.

[0374] According to another aspect of the present application, there is further provided an embedded system that realizes the above-described embedded system operation method, the embedded system being operable on the above-described BMC chip, and the embedded system comprising: a first operating system and a 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 for allocating one group of allocation target services to a corresponding operating system according to a resource dynamic allocation rule, the resource dynamic allocation rule including: performing resource dynamic allocation according to at least one of a service response speed and a service resource occupancy rate; a resource dynamic allocation module that determines a resource allocation result corresponding to one group of allocation target services, the resource allocation result being used to indicate processing resources corresponding to each allocation target service in the one group of allocation target services out of processing resources of a processor including a processor core; and a resource adaptive scheduling module that allocates the processing resources of the processor to the first operating system and the second operating system according to the operating systems corresponding to the services to be allocated and the resource allocation results.

[0375] In this embodiment, the first operating system and the second operating system may be similar to those in the previous embodiment, and detailed description thereof will be omitted. The service management module, the dynamic resource allocation module, and the adaptive resource scheduling module may be software modules that operate under the first operating system or the second operating system. By dividing the modules as described above, it is possible to easily develop and maintain different functional modules. At the same time, the flexibility of resource allocation can be improved by flexibly setting the dynamic resource allocation rules.

[0376] The embedded system includes a first operating system and a second operating system running on a processor, the first operating system having a faster response speed than the second operating system; a service management module that allocates a group of allocation target services to the corresponding operating systems in accordance with a dynamic resource allocation rule, the dynamic resource allocation rule including performing dynamic resource allocation in accordance with at least one of the response speed of the service and the service resource occupancy rate; a dynamic resource allocation module that determines a resource allocation result corresponding to the group of allocation target services, the resource allocation result being used to indicate a processing resource corresponding to each allocation target service in the group of allocation target services among the processing resources of the processor including the processor cores; and a resource adaptive scheduling module that allocates the processing resources of the processor to the first operating system and the second operating system in accordance with the resource allocation result and the operating system corresponding to each allocation target service, thereby solving a problem present in the related art of low overall utilization of core resources due to many processing resources of a multi-core processor being idle, and improving utilization of processing resources.

[0377] In one exemplary embodiment, the embedded system further comprises: The load balance policy module includes a rule structure that records dynamic resource allocation rules by reading a rule configuration file. The load balance policy module in this embodiment is similar to that in the previous embodiment, and a detailed description thereof will be omitted. Here, the load balance policy module may be a software module in the first operating system or the second operating system, and the load balance policy can be configured to be stored in a single software module, thereby facilitating flexible adjustment of the load balance policy.

[0378] In one exemplary embodiment, the load balancing policy module further comprises: A rule update setting file for updating the set dynamic resource allocation rules is obtained via an external interface of the second operating system, and the rule structure is updated using the rule update setting file to update the dynamic resource allocation rules recorded in the rule structure. In this embodiment, the dynamic resource allocation rules stored in the load balancing policy module can be flexibly configured through the external interface of the second operating system, and the configuration method is similar to that in the previous embodiment, so detailed description is omitted here.

[0379] In one exemplary embodiment, the service management module: By executing a step of allocating, among the services to be allocated in one group, those services to be allocated whose service response speed requirements are equal to or greater than a set response speed threshold to a first operating system, and allocating, among the services to be allocated in one group, those services to be allocated whose service response speed requirements are smaller than the set response speed threshold to a second operating system, it is possible to allocate the services to be allocated in one group to the corresponding operating systems in accordance with an allocation rule corresponding to the service response speed among the resource dynamic allocation rules.

[0380] In this embodiment, the method by which the service management module allocates the services to be allocated according to the service response speed is similar to that in the previous embodiment, and a detailed description thereof will be omitted here. In one exemplary embodiment, the service management module: By performing a step of allocating to a first operating system those services among the group of services to be allocated whose service resource occupancy rate is less than a first occupancy rate threshold, and allocating to a second operating system those services among the group of services to be allocated whose service resource occupancy rate is equal to or greater than the first occupancy rate threshold, it is possible to allocate to a corresponding operating system one group of services to be allocated in accordance with an allocation rule corresponding to the service resource occupancy rate among the resource dynamic allocation rules.

[0381] In this embodiment, the method by which the service management module allocates the services to be allocated according to the service resource occupancy rate is similar to that in the previous embodiment, and a detailed description thereof will be omitted here. In one exemplary embodiment, the service management module further comprises: a step of allocating, to the first operating system, a service to be allocated that has a service coupling degree with a service already allocated to the first operating system equal to or greater than a first coupling degree threshold, among the services to be allocated in one group; By executing at least one of the steps of assigning to the second operating system, among the services to be assigned in one group, those services to be assigned whose service coupling with the assigned services of the second operating system is equal to or greater than a second coupling threshold, the services to be assigned in one group can be assigned to the corresponding operating system.

[0382] In this embodiment, the method by which the service management module allocates the target services according to the service coupling degree is similar to that in the previous embodiment, and a detailed description thereof will be omitted here. In one exemplary embodiment, the service management module further comprises: By executing a step of allocating a service to be allocated that includes sensitive information among one group of services to be allocated to a target operating system, the target operating system being an operating system that has a low frequency of interaction with the user among the first operating system and the second operating system, the allocation of one group of services to be allocated to the corresponding operating system is realized.

[0383] In this embodiment, the manner in which the service management module assigns the assignment target service containing sensitive information to the first operating system is similar to that in the previous embodiment, and a detailed description thereof will be omitted here. In addition, when the service management module allocates the target services based on the service response speed and service resource occupancy rate, this is done based on the dynamic resource allocation rules stored in the load balance policy module, and when the service management module allocates the target services based on the service coupling degree and service importance (for example, whether or not it contains sensitive information), this is done based on its preset setting information. Since the processing resource allocation rules based on the service coupling degree and service importance are usually stable, and the service response speed and service resource occupancy rate can be flexibly set based on requirements, by storing the dynamic resource allocation rules that perform dynamic resource allocation according to at least one of the service response speed and service resource occupancy rate in a single software module, it is possible to achieve both flexibility and simplicity in rule setting.

[0384] In one exemplary embodiment, the resource dynamic allocation module: The resource allocation result corresponding to one group of services to be allocated is determined by combining the resource utilization status of the processing resources of the first operating system and the resource utilization status of the processing resources of the second operating system according to the allocation result of the service management module, and generating a resource mapping table between one group of services to be allocated and the processing resources of the processor.

[0385] In this embodiment, the method by which the resource dynamic allocation module generates a resource mapping table between the services to be allocated to one group and the processing resources of the processor is similar to that in the previous embodiment, and a detailed description thereof will be omitted here. In one exemplary embodiment, the dynamic resource allocation module allocates processing resources of the processor to the first operating system and the second operating system on a processor core basis. In one example embodiment, the resource adaptive scheduling module: If it is determined based on the resource allocation result that an unallocated processing resource among the processor's processing resources has a corresponding service to be allocated, the processor's processing resources are allocated to the first operating system and the second operating system based on the resource allocation result and the operating system corresponding to each service to be allocated, by executing a step of allocating the unallocated processing resource to the operating system to which the service to be allocated corresponding to the unallocated processing resource has been allocated.

[0386] In this embodiment, the manner in which the resource adaptive scheduling module allocates unallocated processing resources to the operating system is similar to that in the previous embodiment, and a detailed description thereof will be omitted here. In one exemplary embodiment, the embedded system further comprises: A resource preemption and release module is included that preempts and releases processing resources between the first operating system and the second operating system.

[0387] In this embodiment, the steps of the resource preemption and release module preempting and releasing processing resources between different operating systems are similar to those in the previous embodiment, and detailed description is omitted here. In one exemplary embodiment, a resource preemption and release module preempts and releases processing resources between a first operating system and a second operating system via an inter-core communication interface.

[0388] In one exemplary embodiment, the resource preemption and release module: transmitting a first interaction request of the first operating system to the second operating system via an inter-core communication interface, the first interaction request being used to request a resource interaction with the second operating system, the resource interaction including one of a resource preemption and a resource release; and a step of obtaining a first interaction response returned by the second operating system in response to the first interaction request via the inter-core communication interface, the first interaction response being used to instruct the first operating system to perform resource interaction with the second operating system in accordance with the first interaction response, thereby realizing preemption and release of processing resources between the first operating system and the second operating system via the inter-core communication interface.

[0389] In this embodiment, the resource preemption and release module performs resource interaction between the first operating system and the second operating system through the inter-core communication interface in a manner similar to that in the previous embodiment, and detailed description thereof will be omitted here. In one exemplary embodiment, the embedded system further comprises: and a first system control module that detects resource utilization of a processing resource of the first operating system, and triggers the resource preemption and release module to transmit a first interaction request to the second operating system via the inter-core communication interface when the first operating system determines, according to the resource utilization of the processing resource of the first operating system, to perform a resource interaction with the second operating system.

[0390] In this embodiment, the manner in which the first system control module triggers resource interaction based on the resource utilization rate of the processing resource of the first operating system is similar to that in the previous embodiment, and detailed description thereof will be omitted here. In one exemplary embodiment, the first system control module further performs at least one of the following steps: determining that the first operating system preempts the processing resources of the second operating system when the resource utilization of the processing resources of the first operating system is equal to or greater than a first utilization threshold; and determining that the first operating system releases the processing resources to the second operating system when the processing resources of the first operating system are idle and there are no services for the first operating system to run.

[0391] In this embodiment, the manner in which the first system control module determines the resource interaction type that the first operating system should perform is similar to that in the previous embodiment, and detailed description thereof is omitted here. In one exemplary embodiment, the first system control module further controls the first operating system to enter a sleep state when there is no service scheduling in the first operating system and there are no services to be assigned to the first operating system.

[0392] In this embodiment, the manner in which the first system control module controls the first operating system to enter a sleep state is similar to that in the previous embodiment, and a detailed description thereof will be omitted here. In one exemplary embodiment, the resource preemption and release module: transmitting a first preemption request, the interrupt number of which is a first interrupt number, to the second operating system via the inter-core communication interface, the first preemption request being used to request preemption of a processing resource of the second operating system; By performing at least one of the following steps, the first operating system realizes transmitting a first interaction request of the first operating system to the second operating system via the inter-core communication interface: transmitting a resource release request, whose interrupt number is a second interrupt number, to the second operating system via the inter-core communication interface, wherein the resource release request is used to request the second operating system to release the processing resources occupied by the first operating system.

[0393] In this embodiment, the resource preemption and release module performs resource interaction through inter-core interrupts in a manner similar to that in the previous embodiment, and detailed description thereof will be omitted here. In one exemplary embodiment, the resource preemption and release module: transmitting a second interaction request of the second operating system to the first operating system via the inter-core communication interface, the second interaction request being used to request preemption of a processing resource of the first operating system; and (b) receiving a second interaction response returned by the first operating system in response to the second interaction request via the inter-core communication interface, the second interaction response being used by the first operating system to instruct whether or not to allow the second operating system to preempt the processing resource of the first operating system, thereby realizing preemption and release of processing resources between the first operating system and the second operating system via the inter-core communication interface.

[0394] In this embodiment, the manner in which the resource preemption and release module performs resource interaction between the first operating system and the second operating system through the inter-core communication interface is similar to that in the previous embodiment, and detailed description thereof will be omitted here. In one exemplary embodiment, the embedded system further comprises: and a second system control module that detects resource utilization of the processing resources of the second operating system, and triggers the resource preemption and release module to transmit a second interaction request to the first operating system via the inter-core communication interface when the second operating system determines, according to the resource utilization of the processing resources of the second operating system, to preempt the processing resources of the first operating system.

[0395] In this embodiment, the manner in which the second system control module triggers resource interaction based on the resource utilization rate of the processing resource of the second operating system is similar to that in the previous embodiment, and detailed description thereof will be omitted here. In one exemplary embodiment, the second system control module further comprises: determining by the second operating system to preempt the processing resource of the second operating system when the current resource utilization of the processing resource of the second operating system is greater than or equal to a second utilization threshold; When it is determined that the resource utilization of the processing resources of the second operating system is equal to or greater than a third utilization threshold, the second operating system performs at least one of the steps of determining to preempt the processing resources of the second operating system according to the services currently running on the second operating system and the services to be run by the second operating system.

[0396] In this embodiment, the manner in which the second system control module determines the resource interaction that the second operating system should perform is similar to that in the previous embodiment, and detailed description thereof is omitted here. In one exemplary embodiment, the first operating system further determines that if the service priority of the running service of the first operating system is not lower than the service priority of the service to be run by the second operating system, the first operating system will deny the second operating system from preempting the processing resources of the first operating system, and if the service priority of the running service of the first operating system is lower than the service priority of the service to be run by the second operating system, the first operating system will allow the second operating system to preempt the processing resources of the first operating system.

[0397] In this embodiment, the manner in which the first operating system in the embedded system determines whether to grant the second operating system the processing resources it occupies is similar to that in the previous embodiment, and a detailed description thereof will be omitted here. In one exemplary embodiment, the resource preemption and release module: By executing a step of transmitting a second preemption request, whose interrupt number is a third interrupt number, to the first operating system via the inter-core communication interface, the second preemption request being used to request preemption of a processing resource of the first operating system, the transmission of a second interaction request of the second operating system to the first operating system via the inter-core communication interface is realized.

[0398] In this embodiment, the resource preemption and release module performs resource interaction through inter-core interrupts in a manner similar to that in the previous embodiment, and detailed description thereof will be omitted here. In one exemplary embodiment, the resource preemption and release module: transmitting a resource release permission response, the interrupt number of which is the fourth interrupt number, to the second operating system via the inter-core communication interface, the resource release permission response being used to instruct the first operating system to allow the second operating system to preempt the processing resources of the first operating system; By perform...

Claims

1. An embedded system, a first operating system and a second operating system running on a processor, the first operating system having a higher response speed to an instruction than the second operating system; a service management module that allocates a group of allocation target services to corresponding operating systems according to a dynamic resource allocation rule, the dynamic resource allocation including performing dynamic resource allocation according to at least one of a response speed of the service and a service resource occupancy rate; a resource dynamic allocation module that determines a resource allocation result corresponding to the one group of allocation target services, the resource allocation result being used to indicate a processing resource corresponding to each allocation target service in the one group of allocation target services among processing resources of the processor including a processor core; and a resource adaptive scheduling module that allocates processing resources of the processor to the first operating system and the second operating system according to an operating system corresponding to each of the services to be allocated and a result of the resource allocation.

2. The embedded system further comprises:

2. The embedded system according to claim 1, further comprising a load balance policy module that generates a rule structure that records the dynamic resource allocation rules by reading a rule setting file.

3. 3. The embedded system according to claim 2, wherein the load balance policy module further acquires a rule update configuration file for updating the dynamic resource allocation rules that have already been set via an external interface of the second operating system, and updates the rule structure using the rule update configuration file to update the dynamic resource allocation rules recorded in the rule structure.

4. The service management module assigning, to the first operating system, a service among the group of services to be assigned whose service response speed requirement is equal to or greater than a set response speed threshold, and assigning, to the second operating system, a service among the group of services to be assigned whose service response speed requirement is less than the set response speed threshold; assigning, to the first operating system, services among the group of services to be assigned whose service resource occupancy rate is less than a first occupancy rate threshold, and assigning, to the second operating system, services among the group of services to be assigned whose service resource occupancy rate is equal to or greater than the first occupancy rate threshold; 2. The embedded system according to claim 1, wherein the embedded system performs at least one of the steps of allocating services that include sensitive information including passwords among the group of services to be allocated to a target operating system that has a low frequency of interaction with a user, among the first operating system and the second operating system, thereby realizing allocation of the services to be allocated to the corresponding operating system in accordance with an allocation rule corresponding to service response speed among the resource dynamic allocation rules.

5. The service management module further comprises: a step of allocating to the first operating system, among the services to be allocated in the one group, those services to be allocated whose service coupling degree with the assigned services of the first operating system is equal to or greater than a first coupling degree threshold, wherein the service coupling degree is used to represent a degree of association between the services to be allocated in the one group and the assigned services of the first operating system; 2. The embedded system of claim 1, further comprising: a step of assigning to the second operating system, among the group of services to be assigned, services to be assigned whose service coupling with the assigned services of the second operating system is equal to or greater than a second coupling threshold, wherein the service coupling is used to represent a degree of association between the services to be assigned and the assigned services of the second operating system, among the group of services to be assigned.

6. The resource dynamic allocation module:

2. The embedded system according to claim 1, further comprising: a step of generating a resource mapping table between the services to be allocated to the group and the processing resources of the processor by combining the resource usage status of the processing resources of the first operating system and the processing resources of the second operating system in accordance with the allocation result of the service management module, thereby determining the resource allocation result corresponding to the services to be allocated to the group.

7. 2. The embedded system according to claim 1, wherein the dynamic resource allocation module allocates the processing resources of the processor to the first operating system and the second operating system on a processor core basis.

8. The resource adaptive scheduling module:

2. The embedded system of claim 1, wherein, when it is determined based on the resource allocation result that an unallocated processing resource among the processing resources of the processor has a corresponding service to be assigned, the system executes a step of allocating the unallocated processing resource to an operating system to which the service to be assigned corresponding to the unallocated processing resource is assigned, thereby allocating the processing resources of the processor to the first operating system and the second operating system based on the operating systems corresponding to each of the services to be assigned and the resource allocation result.

9. a resource preemption and release module for preempting and releasing processing resources between the first operating system and the second operating system; 2. The embedded system of claim 1, wherein the resource preemption and release module preempts and releases processing resources between the first operating system and the second operating system via an inter-core communication interface.

10. The resource preemption and release module: transmitting a first interaction request of the first operating system to the second operating system via an inter-core communication interface, the first interaction request being used to request a resource interaction with the second operating system, the resource interaction including one of a resource preemption and a resource release; 10. The embedded system of claim 9, wherein preemption and release of processing resources between the first operating system and the second operating system via the inter-core communication interface is realized by executing the step of: obtaining a first interaction response returned by the second operating system in response to the first interaction request via the inter-core communication interface, the first interaction response being used to instruct the first operating system to perform the resource interaction with the second operating system in accordance with the first interaction response.

11. further comprising a first system control module; The first system control module detect a resource utilization rate of a processing resource of the first operating system, and when the first operating system determines to perform the resource interaction with the second operating system according to the resource utilization rate of the processing resource of the first operating system, trigger the resource preemption and release module to transmit the first interaction request to the second operating system via the inter-core communication interface; 11. The embedded system of claim 10, further comprising at least one of the steps of: determining by the first operating system to preempt the processing resources of the second operating system when resource utilization of the processing resources of the first operating system is equal to or greater than a first utilization threshold; and determining by the first operating system to release the processing resources to the second operating system when the processing resources of the first operating system are idle and there are no services for the first operating system to perform.

12. The first system control module further controls the first operating system to enter a sleep state when there is no service scheduling for the first operating system and there is no service to be assigned to the first operating system.

12. The embedded system of claim 11.

13. The resource preemption and release module: transmitting a first preemption request via an inter-core communication interface to the second operating system, the first preemption request having an interrupt number equal to a first interrupt number, the first preemption request being used to request preemption of a processing resource of the second operating system; 11. The embedded system of claim 10, further comprising: performing at least one of the following steps: transmitting a resource release request, whose interrupt number is a second interrupt number, to the second operating system via an inter-core communication interface, the resource release request being used to request the second operating system to release a processing resource occupied by the first operating system, thereby realizing transmission of a first interaction request of the first operating system to the second operating system via the inter-core communication interface.

14. The resource preemption and release module: transmitting a second interaction request of the second operating system to the first operating system via an inter-core communication interface, the second interaction request being used to request preemption of a processing resource of the first operating system; and a step of acquiring a second interaction response returned by the first operating system in response to the second interaction request via the inter-core communication interface, the second interaction response being used by the first operating system to indicate whether or not to allow the second operating system to preempt a processing resource of the first operating system, thereby realizing preemption and release of processing resources between the first operating system and the second operating system via the inter-core communication interface. The embedded system according to claim 9 .

15. 15. The embedded system of claim 14, further comprising: a second system control module that detects resource utilization of a processing resource of the second operating system, and, when the second operating system determines, in response to the resource utilization of the processing resource of the second operating system, to preempt a processing resource of the first operating system, triggers the resource preemption and release module to transmit the second interaction request to the first operating system via the inter-core communication interface.

16. The second system control module further comprises: determining by the second operating system to preempt a processing resource of the second operating system if a current resource utilization of the processing resource of the second operating system is greater than or equal to a second utilization threshold; 16. The embedded system of claim 15, further comprising: determining, in response to running services of the second operating system and services to be run by the second operating system, that resource utilization of the processing resources of the second operating system is greater than or equal to a third utilization threshold; and determining, by the second operating system, to preempt the processing resources of the second operating system if the second operating system determines that the resource utilization of the processing resources of the second operating system is greater than or equal to a third utilization threshold.

17. The resource preemption and release module: transmitting a second preemption request to the first operating system via an inter-core communication interface, the second preemption request having an interrupt number equal to a third interrupt number, the second preemption request being used to request preemption of a processing resource of the first operating system; or transmitting a resource release permission response having an interrupt number equal to a fourth interrupt number to the second operating system via an inter-core communication interface, the resource release permission response being used to instruct the first operating system to permit the second operating system to preempt a processing resource of the first operating system; 15. The embedded system of claim 14, wherein the embedded system performs at least one of the following steps: transmitting a resource release refusal response having an interrupt number of a fifth interrupt number to the second operating system via an inter-core communication interface, the resource release refusal response being used to instruct the first operating system to refuse to have the second operating system preempt a processing resource of the first operating system; and acquiring a second interaction response sent by the first operating system in response to the second interaction request via the inter-core communication interface.

18. 1. A method of operating an embedded system, comprising: allocating a group of allocation target services to corresponding operating systems of the embedded system according to a dynamic resource allocation rule, the dynamic resource allocation rule including performing dynamic resource allocation according to at least one of a service response speed, a service resource occupancy rate, a service coupling degree, and a service importance, the embedded system including a first operating system and a second operating system running on a processor, the first operating system having a higher response speed to an instruction than the second operating system; determining a resource allocation result corresponding to the one group of allocation target services, wherein the resource allocation result is used to indicate a processing resource corresponding to each allocation target service in the one group of allocation target services among processing resources of the processor including a processor core; and allocating processing resources of the processor to the first operating system and the second operating system according to the operating systems corresponding to the services to be allocated and the resource allocation result.

19. An operating device for an embedded system, a first allocation unit that allocates a group of allocation target services to corresponding operating systems of the embedded system according to a dynamic resource allocation rule, the dynamic resource allocation rule including performing dynamic resource allocation according to at least one of a service response speed, a service resource occupancy rate, a service coupling degree, and a service importance, the embedded system including a first operating system and a second operating system running on a processor, the first operating system having a higher response speed to an instruction than the second operating system; a first determination unit that determines a resource allocation result corresponding to the one group of allocation target services, the resource allocation result being used to indicate processing resources of the processor including a processor core that correspond to each allocation target service in the one group of allocation target services; and a second allocation unit that allocates processing resources of the processor to the first operating system and the second operating system according to an operating system corresponding to each of the services to be allocated and a result of the resource allocation.

Images