Operating system execution control method, device, embedded system and chip

Abstract

Embodiments of the present application provide a method and apparatus for controlling the execution of an operating system, an embedded system, and a chip. The embedded system includes a chip and at least two operating systems. The chip includes a processor, a hardware controller, a first bus, and a second bus. The bandwidth of the first bus is higher than that of the second bus. The first bus is configured in a multi-master / multi-slave mode, and the second bus is configured in a single-master / multi-slave mode. At least two operating systems are executed based on the processor. At least two operating systems communicate via the first bus. At least two operating systems realize control to the hardware controller via the second bus. According to the present application, the problem that the execution efficiency of the operating system is low is solved, and the effect of improving the execution efficiency of the operating system is achieved.

Description

[Technical Field]

[0001] The present application relates to the field of computers, and in particular to a method, device, embedded system and chip for controlling the execution of an operating system. [Background technology]

[0002] Current devices such as servers, personal computers, and industrial computers often use a system architecture that includes hardware devices such as CPLDs (Complex Programmable Logic Devices) and EC (Embedded Controller) chips, or hardware logic devices such as control chips, in addition to an operating system to control the device. However, the use of hardware logic devices such as CPLDs, EC chips, and control chips inevitably leads to an increase in system costs. In addition, the increase in the number of hardware logic devices requires interactions between devices in the system, which significantly affects the execution efficiency of the operating system. In the related art, no effective solution has yet been proposed to the problem of low execution efficiency of operating systems. Summary of the Invention [Problem to be solved by the invention]

[0003] The embodiments of the present application provide a method, apparatus, embedded system and chip for controlling the execution of an operating system to at least solve the problem of low execution efficiency of the operating system in the related art. [Means for solving the problem]

[0004] According to a first aspect, there is provided an embedded system including a chip and at least two operating systems, The chip provides an embedded system including a processor, a hardware controller, a first bus, and a second bus, the bandwidth of the first bus being higher than the bandwidth of the second bus, the first bus being configured in a multi-master / multi-slave mode, and the second bus being configured in a single-master / multi-slave mode, and at least two operating systems running on the processor, the at least two operating systems communicating via the first bus, and the at least two operating systems exercising control over the hardware controller via the second bus.

[0005] According to a second aspect, there is provided an embedded system including a first operating system, a second operating system, a controller, and a processor, wherein the first operating system and the second operating system are executed based on the processor, and the controller is configured to detect the execution state of the first operating system during the execution process and control the processor resources used by the first operating system based on the execution state.

[0006] According to a third aspect, there is provided a method for controlling execution of an operating system, comprising: Detecting the execution status of the first operating system during the execution process, the first operating system and the second operating system being executed based on the processor; and controlling the processor resources used by the first operating system based on the execution state.

[0007] According to a fourth aspect, there is provided an execution control device for an operating system, comprising: a first detection module configured to detect an execution state of a first operating system in an execution process, wherein the first operating system and a second operating system are executed based on a processor; and a control module configured to control processor resources used by the first operating system based on the execution state.

[0008] According to a fifth aspect, there is further provided a chip including at least one of programmable logic circuitry and executable instructions, the chip being configured to be executed on an electronic device and to perform the steps of any of the method embodiments described above. According to a fifth aspect, there is further provided a BMC chip including a storage unit and a processing unit connected to the storage unit, wherein the storage unit is configured to store a program and the processing unit is configured to execute the program, in order to implement the steps of any of the method embodiments described above.

[0009] According to a seventh aspect, there is further provided a motherboard including at least one processor and at least one storage device configured to store 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 of any of the method embodiments described above.

[0010] According to an eighth aspect, there is further provided a server including a processor, a communication interface, a storage device, and a communication bus, wherein the processor, the communication interface, and the storage device communicate with each other via the bus, the storage device is configured to store a computer program, and the processor is configured to realize the steps in any of the above method embodiments when executing the program stored by the storage device.

[0011] According to a ninth aspect, there is further provided a non-volatile readable storage medium having stored thereon a computer program, the computer program being configured, when executed by a processor, to implement the steps of any of the method embodiments described above. According to a tenth aspect, there is further provided an electronic device comprising a storage device and a processor, wherein the storage device stores a computer program, and the processor is configured to execute the computer program to implement the steps of any of the method embodiments described above. [Effects of the Invention]

[0012] According to the present application, the first operating system and the second operating system are executed based on a processor, and the execution state of the first operating system is detected during the execution process, and the processor resources used by the first operating system are controlled based on the execution state. Since the first operating system and the second operating system are both executed based on the same processor, it is possible to avoid an increase in hardware and reduce system costs, and it is also possible to control the processor resources used during the execution process of the operating systems, and to rationally utilize the processor resources to support inter-system execution, thereby solving the technical problem of low operating system execution efficiency and achieving the technical effect of improving the execution efficiency of the operating systems. [Brief explanation of the drawings]

[0013] [Figure 1] 1 is a schematic diagram of a hardware environment of an operating system execution control method according to an embodiment of the present application; [Figure 2] 1 is a flow diagram of a method for controlling the execution of an operating system according to an embodiment of the present application; [Figure 3] 1 is a schematic diagram of an operating service handover process according to an embodiment of the present application; [Figure 4] 2 is a schematic diagram of a processor core occupation process according to an embodiment of the present application; [Figure 5] 1 is a schematic diagram 1 of a processor resource control process according to an embodiment of the present application; [Figure 6]2 is a schematic diagram 2 of a processor resource control process according to an embodiment of the present application; [Figure 7] FIG. 2 is a schematic diagram of a service data interaction process according to an embodiment of the present application; [Figure 8] 1 is a schematic diagram 1 of the execution process of the first operating system according to an embodiment of the present application; [Figure 9] 2 is a schematic diagram 2 of the execution process of the first operating system according to an embodiment of the present application; [Figure 10] 1 is a schematic diagram of a system abnormality monitoring process according to an embodiment of the present application; [Figure 11] 1 is a schematic diagram of an embedded system according to an embodiment of the present application. [Figure 12] FIG. 1 is a block diagram of a selectable BMC chip architecture according to an embodiment of the present application. [Figure 13] FIG. 2 is a schematic diagram of a communication process of service data between operating systems according to an alternative embodiment of the present application. [Figure 14] FIG. 1 is a schematic diagram of a service management process in an embedded system according to an alternative embodiment of the present application. [Figure 15] FIG. 2 is a schematic diagram of a task scheduling process according to an alternative embodiment of the present application. [Figure 16] 2 is a schematic diagram 2 of an embedded system according to an embodiment of the present application. [Figure 17] FIG. 2 is a flow diagram of an execution controller architecture of an operating system according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, the present invention will be described in detail with reference to the drawings and examples. It should be noted that terms such as "first," "second," etc. in the specification, claims, and brief description of the drawings of this application are used to distinguish between similar objects and are not necessarily used to describe a particular order or chronological sequence.

[0015] An embodiment of the method provided by the present application may be executed on a server, a computer terminal, a device terminal, or a similar computing device. As an example of execution on a server, FIG. 1 is a schematic diagram of a hardware environment for a method of controlling the execution of an operating system according to an embodiment of the present application. As shown in FIG. 1, the server may include one or more (only one is shown in FIG. 1) processors 102 (processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device) and a storage device 104 configured to store data. In an exemplary embodiment, the server may further include a transmission device 106 having communication capabilities and an input / output device 108. Those skilled in the art will appreciate that the structure shown in FIG. 1 is for illustrative purposes only and does not limit the structure of the server. For example, the server may include more or fewer assemblies than those shown in FIG. 1, or may have a different configuration with equivalent or greater functionality than those shown in FIG. 1.

[0016] The storage device 104 may be configured to store computer programs, such as application software programs and modules and corresponding computer programs for an operating system execution control method according to an embodiment of the present invention. The processor 102 executes the computer programs stored in the storage device 104 to perform various functional applications and data processing and realize the above-described methods. The storage device 104 may include a high-speed random storage device, and may also include non-volatile storage devices, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state storage devices. In some examples, the storage device 104 may further include storage devices located remotely from the processor 102, and these remote storage devices are connected to a server via a network. Examples of the above-described network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0017] The transmission device 106 is configured to transmit and receive data over a network. Optional examples of the network may include a wireless network provided by the server's communications provider. In one example, the transmission device 106 includes a network interface controller (NIC) and 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 configured to communicate with the Internet wirelessly.

[0018] This embodiment provides an operating system execution control method that is applicable to the above hardware environment. FIG. 2 is a flow chart of the operating system execution control method according to the embodiment of the present application. As shown in FIG. 2, the flow includes: A step S202 of detecting the running state of the first operating system during the running process, wherein the first operating system and the second operating system are executed based on the processor; and a step S204 of controlling the processor resources used by the first operating system based on the execution state.

[0019] In the above steps, the first operating system and the second operating system are executed based on a processor, and the execution state of the first operating system is detected during the execution process, and the processor resources used by the first operating system are controlled based on the execution state. Since the first operating system and the second operating system are both executed based on the same processor, it is possible to avoid an increase in hardware and reduce system costs, and it is also possible to control the processor resources used during the execution process of the operating systems, and to rationally utilize the processor resources to support inter-system execution, thereby solving the technical problem of low operating system execution efficiency and achieving the technical effect of improving the operating system execution efficiency.

[0020] Here, the execution body of the above steps may be, but is not limited to, a server, a device, a motherboard, a chip, a processor, an embedded system, etc. Optionally, in an embodiment, the above-mentioned first operating system and second operating system may be, but are not limited to, two heterogeneous or homogeneous operating systems, that is, the types of the first operating system and the second operating system may be the same or different.

[0021] For example, the first operating system and the second operating system may be different operating systems, and the first operating system and the second operating system may be different in sensitivity to response time, for example, the first operating system may be more sensitive to response time than the second operating system, or the first operating system and the second operating system may be different in resource usage, for example, the first operating system may have a lower service usage and resource usage than the second operating system.

[0022] The first and second operating systems may be, but are not limited to, two different types of operating systems deployed in a processor of an embedded system, i.e., embedded operating systems. Embedded operating systems are divided into real-time operating systems (RTOS) and non-real-time operating systems depending on their sensitivity to response time. Real-time operating systems may include, but are not limited to, Free RTOS (Free Real-Time Operating System) and RT Linux (Real Time Linux). Non-real-time operating systems may include, but are not limited to, contiki (Contiki Operating System), HeliOS (Helix Operating System), and Linux (Linux Operating System).

[0023] An embedded system is a dedicated computer system configured as a device to control, monitor, or support the operation of machines or equipment. Embedded systems are application-centric and based on computer technology, and the software and hardware can be tailored to meet the strict requirements of the application system for dedicated computer systems, such as functionality, reliability, cost, volume, and power consumption. Defined from the application object, an embedded system is a combination of software and hardware and can also cover auxiliary devices such as machines.

[0024] From a hardware perspective, the embedded system may include, but is not limited to, hardware devices such as a processor, a storage device, and peripheral circuits, and the first and second operating systems are executed based on the embedded system. From a software perspective, the embedded system may include, but is not limited to, a microcomputer abstraction layer, an operating system, and an application program, and the first and second operating systems are operating systems in the embedded system.

[0025] Optionally, in this embodiment, the above-mentioned operating system execution control method can be executed by, but is not limited to, a control logic implemented in an embedded system, which realizes control, allocation, and scheduling of hardware and software resources such as heterogeneous dual operating systems, processors, and storage devices in the embedded system.

[0026] The above-mentioned method for controlling the execution of an operating system can be executed by the first operating system or by a function module for resource control provided in the first operating system, but is not limited thereto. In the technical solution provided in step S202, during the execution of the first operating system, its execution state may indicate, but is not limited to, its execution status. The execution status may be one-dimensional or multi-dimensionally considered comprehensively, but is not limited to these. For example, the execution status may include, but is not limited to, the usage status of software and hardware resources, the execution status of instructions, the execution status of operating services, etc.

[0027] Optionally, in this embodiment, the execution process of the first operating system may be, but is not limited to, the entire process from power-on to power-off, during which the first operating system may always be awake, or may have both a wake-up stage and a sleep stage, but is not limited thereto. In the technical solution provided in the above step S204, the processor resources used by the first operating system may include, but are not limited to, operating services, processor cores, memory space in the processor (e.g., memory, cache memory), timers, registers, and input / output interfaces.

[0028] Optionally, in this embodiment, the control of the processor resources may be to control one of them independently, or to control multiple processor resources in cooperation, but is not limited thereto. Optionally, in this embodiment, the control of the processor resources may include, but is not limited to, operations such as release, occupation, allocation, and reclamation. The processor resources used are rationally controlled based on the execution state of the first operating system during execution, thereby improving resource utilization and the execution efficiency of the operating system.

[0029] In an exemplary embodiment, the detected execution state can determine the controlled processor resources, e.g., detecting a service state can control the adjustment of an operating service, and detecting a system state can control the usage of processor cores. Furthermore, different detection objects can be configured based on the processor resources that need to be controlled, e.g., adjusting an operating service can detect a service state, and if the usage of processor cores needs to be controlled, a system state can be detected.

[0030] When the first operating system executes an operating service, the service status may reflect the execution status of the first operating system. Alternatively, if it is necessary to control an operating service in the operating system, the service status of the operating service may be detected. For example, in step S202, the first operating system may detect a service status included in the execution status of the target operating service executed by the processor, but this is not limiting.

[0031] Alternatively, in this embodiment, the target operating service may be an operating service that has certain requirements for the system's execution performance and operating environment, but is not limited to this, for example, a fan control service that has certain requirements for execution time, a log retracing service that has certain requirements for data storage space, an interface switching service and a hardware interface waveform signal simulation service that have certain requirements for response speed, etc.

[0032] Optionally, in this embodiment, the service status of an operating service may indicate, but is not limited to, the execution status of the operating service in each dimension, such as whether the operating service is interrupted or is executing to a certain extent (e.g., whether the execution time reaches a threshold or whether the execution result reaches a predetermined result). When the target service state reaches the target service state, i.e., when the operating service has executed to a certain extent, the service can be subjected to control operations consistent with the target service state, thereby realizing control appropriate to the current service state, such as migrating the operating service from one operating system to another, starting and stopping the operating service, pausing and restoring the operating service, etc. For example, in the above step S204, if it is detected that the service state is the target service state, the target operating service is released, the processor resources include the target operating service, and the second operating system is used to execute the target operating service.

[0033] Optionally, in this embodiment, when the target operating service reaches a target service state, such as when the operating service is interrupted and has executed to a certain extent (for example, when the execution time reaches a threshold or the execution result reaches a predetermined result), the target operating service is released from the first operating system and the second operating system continues to execute the target operating service, thereby realizing the operating service to execute alternately in the operating systems, and finally, the operating service can be executed in an operating system that is more suitable for execution.

[0034] The service state of the target operating service executed by the first operating system may be that the target operating service executed by the first operating system is interrupted by the second operating system, for example, when the second operating system receives a first interrupt request sent to the first operating system, it is determined that the service state is detected to be the target service state, and the first interrupt request is used to request taking over the target operating service. Alternatively, the service state of the target operating service executed by the first operating system may be that the target operating service reaches a target service attribute, for example, when the service attribute of the target operating service reaches the target service attribute, it is determined that the service state is detected to be the target service state.

[0035] Optionally, in this embodiment, when the target operating service performs operating system conversion can be determined by the second operating system, but is not limited thereto. When the second operating system decides to take over the target operating service, it can send a first interrupt request to the first operating system to indicate that it will take over the target operating service. When the first operating system receives the first interrupt request, it can be considered that the service state of the target operating service executed by the first operating system has already reached the target service state, and it will respond to the first interrupt request and take over the execution of the target operating service by the second operating system.

[0036] Optionally, in this embodiment, the service attributes of the target operating service may include, but are not limited to, an execution time length, an execution result, and an execution load, etc. The execution time length reaching the target service attribute may be, but is not limited to, an execution time length reaching a predetermined length, the execution result reaching the target service attribute may be, but is not limited to, an execution of a predetermined execution result for the target operating service, and the execution load reaching the target service attribute may be, but is not limited to, an execution resource occupied by the operating service exceeding or about to exceed the allowable range of the first operating system.

[0037] Alternatively, in this embodiment, when the target operating service performs the operating system conversion may be determined by the service attributes of the target operating service itself, but is not limited thereto. It can be considered that when the target operating service executes until the service attributes reach the target service attributes, the service state of the target operating service executed by the first operating system has already reached the target service state, and the execution of the target operating service is taken over by the second operating system.

[0038] In an exemplary embodiment, the eligibility of the second operating system to take over the target operating service may be determined by, but is not limited to, establishing a determination mechanism, for example, when obtaining a first interrupt request, responding to the first interrupt request, determining whether the second operating system will take over the target operating service, and releasing the target operating service if the second operating system will take over the target hardware controller.

[0039] Optionally, in this embodiment, when the first interrupt request is obtained, the target operating service executed by the first operating system does not need to be immediately released, but the second operating system determines whether to take over the target operating service, and the second operating system determines whether it is eligible to take over the target operating service. If the second operating system determines to take over the target operating service, it releases the target operating service executed by the first operating system.

[0040] In the mechanism for determining whether the second operating system is eligible to inherit the target operating service, if the second operating system is not eligible to inherit the target operating service, the second operating system can refuse to inherit the target operating service. For example, after determining whether the second operating system is eligible to inherit the target operating service, if the second operating system is not eligible to inherit the target operating service, a second interrupt request is sent to the second operating system, and the second interrupt request is used to indicate that the second operating system refuses to inherit the target operating service.

[0041] Optionally, in this embodiment, the refusal of the second operating system to take over the target operating service may be, but is not limited to, notifying or indicating to the second operating system by sending an interrupt request between systems. Optionally, in this embodiment, if the second operating system does not take over the target operating service, the second interrupt request does not need to be sent, and the first operating system does not release the target operating service but continues to run the target operating service, and thus the second operating system cannot take over the target operating service.

[0042] After sending a second interrupt request to the second operating system to deny the second operating system from taking over the target operating service, the first operating system continues to execute the target operating service until the second operating system satisfies the takeover condition of the target operating service (e.g., the service attribute reaches the target attribute), and then the first operating system releases the target operating service to the second operating system and notifies the second operating system to take over and execute it.

[0043] After the target operating service running in the first operating system is released, the second operating system can actively detect that the target operating service has been released and take over the target operating service. Alternatively, when the second operating system actively sends a first interrupt request to request to take over the target operating service, the second operating system can directly take over the target operating service by default unless it receives a second interrupt request within a certain period of time that denies the takeover of the target operating service, thereby improving the efficiency of taking over the target operating service.

[0044] When releasing a target operating service to be executed by the first operating system, an interrupt request can be actively sent to the second operating system to notify the second operating system that the target operating service has been released, for example, a third interrupt request can be sent to the second operating system, the third interrupt request is used to indicate that the first operating system has released the target hardware controller, and the second operating system is used to execute the target operating service in response to the third interrupt request.

[0045] When the service attributes of the target operating service reach the target service attributes, the first operating system actively releases the target operating service and can send a third interrupt request to the second operating system to notify the second operating system that the target operating service has been released. After receiving the third interrupt request, the second operating system takes over and executes the target operating service.

[0046] 3 is a schematic diagram of an operating service takeover process according to an embodiment of the present application, as shown in FIG. 3, the second operating system sends a first interrupt request to the first operating system to request that the first operating system take over the target operating service running on the first operating system, and if the first operating system allows the second operating system to take over the target operating service, it releases the target operating service, and the second operating system takes over the target operating service and runs the target operating service on the second operating system, and if the first operating system refuses to allow the second operating system to take over the target operating service, it sends a second interrupt request to the second operating system to refuse to allow the second operating system to take over the target operating service, and the first operating system continues to run the target operating service.

[0047] Furthermore, the system state of the first operating system may reflect the execution state of the first operating system, and the processor cores used by the first operating system may be rationally controlled based on the execution state of the first operating system, but is not limited thereto. Alternatively, if it is necessary to control the processor cores used by the operating system, the system state of the operating system may be detected. For example, in the above step S202, the system state of the first operating system may be detected, and the execution state may include, but is not limited to, the system state, and the first operating system may be executed based on the target processor core in the processor.

[0048] Optionally, in this embodiment, the target processor core may be, but is not limited to, a processor core in the processor that is assigned to a first operating system and configured to run the first operating system, and the number of target processor cores may be, but is not limited to, one or more. Optionally, in this embodiment, the system state of the operating system may indicate, but is not limited to, the execution status of the operating system in each dimension, such as whether the operating system is interrupted or has executed to a certain extent (e.g., whether the execution time reaches a threshold or whether the execution result reaches a predetermined result).

[0049] When the system state reaches the target system state, i.e., when the operating system has executed to a certain extent, the processor cores used by the operating system can be controlled to operate in accordance with the target system state, and finally, the processor cores can be allocated and utilized rationally. For example, in the above step S204, when it is detected that the system state is the target system state, the target processor core is released, the processor resources include the target processor core, and the second operating system is used to add the target processor core to a scheduling resource pool of the second operating system, and the scheduling resource pool includes the processor cores in the processors allocated to the second operating system.

[0050] Optionally, in this embodiment, when the system state of the first operating system reaches a target system state, such as when the operating system is interrupted or has executed to a certain extent (for example, when the execution time reaches a threshold, when the execution result reaches a predetermined result, or when the execution load is lower than a predetermined value), the target processor core used by the first operating system is released, and the second operating system uses the target processor core, thereby realizing alternate use of the processor core between the operating systems and ultimately achieving more rational utilization of the processor core.

[0051] The system state of the first operating system reaching the target system state may be determined as the first operating system being interrupted by the second operating system, for example, when the second operating system receives a fourth interrupt request sent to the first operating system, the system state is determined to be detected as the target system state, and the fourth interrupt request is used to request the seizure of the target processor core. Alternatively, the system state of the first operating system reaching the target system state may be determined as the system attribute of the first operating system reaching the target system attribute, for example, when the system attribute of the first operating system reaches the target system attribute, the system state is determined to be detected as the target system state.

[0052] Optionally, in this embodiment, when the target processor core performs operating system conversion can be determined by the second operating system, but is not limited to this. When the second operating system decides to take over the target processor core, it can send a fourth interrupt request to the first operating system to indicate that it will take over the target processor core. When it receives the fourth interrupt request, it can be considered that the system state of the first operating system has already reached the target system state, and in response to the fourth interrupt request, it releases the target processor core, and the second operating system takes over the target processor core and adds it to the scheduling resource pool for use.

[0053] Optionally, in this embodiment, after the second operating system receives the fourth interrupt request sent to the first operating system, the data currently being executed in the first operating system can be pushed to the stack, the first operating system enters a sleep state, and the second operating system occupies the target processor core for scheduling and use.

[0054] Optionally, in this embodiment, the second operating system can issue the fourth interrupt request based on its own requirements for processor core resources, but is not limited thereto. For example, the second operating system can detect whether the resource occupancy rate of the core assigned to it is higher than a certain threshold, or whether the resource remaining amount of the core assigned to it is sufficient to execute the next process. If the resource occupancy rate is higher than a certain threshold or the remaining amount is not sufficient to execute the next process, the second operating system can consider that it requires an additional processor core, and the second operating system can actively send a fourth interrupt request to the first operating system to request it to occupy the target processor core, thereby reducing its execution pressure and supporting the execution of the next process.

[0055] In an alternative embodiment, when the second operating system (e.g., Linux) detects that the core resource occupancy rate allocated to it is high (e.g., the occupancy rate is higher than 95% of the total resource amount), it can send a fourth interrupt request to the first operating system (e.g., RTOS), and after the first operating system (RTOS) receives the fourth interrupt request, it memorizes the service location it is running (e.g., pushes execution data onto a stack) and releases the target processor core it uses, and the second operating system (Linux) occupies the target processor core and assigns threads that need to be executed to the target processor core, or schedules threads in other processor cores with high occupancy rates to be executed on the target processor core.

[0056] Optionally, in this embodiment, the system attributes of the operating system may include, but are not limited to, the system's execution time length, execution result, execution load, etc. The system's execution time length reaching the target system attribute may be, but is not limited to, the system's execution time length reaching a predetermined length of time, the system's execution result reaching the target service attribute may be, but is not limited to, the operating system performing a predetermined execution result, and the system's execution load reaching the target system attribute may be, but is not limited to, the operating system's resource occupancy falling below or approaching a predetermined resource occupancy lower limit.

[0057] Optionally, in this embodiment, when the target processor core performs the operating system conversion may be determined by the system attributes of the operating system itself, but is not limited thereto, and it can be considered that when the operating system runs until the system attributes reach the target system attributes, the system state of the operating system reaches the target system state and the target processor core can be occupied by the second operating system.

[0058] In an exemplary embodiment, the eligibility of the second operating system to occupy the target processor core may be determined by, but is not limited to, establishing a determination mechanism, for example, when a fourth interrupt request is obtained, determining whether the second operating system occupies the target processor core in response to the fourth interrupt request, and releasing the target processor core if the second operating system occupies the target processor core.

[0059] Optionally, in this embodiment, when the fourth interrupt request is obtained, the target processor core does not need to be released immediately, but the second operating system determines whether to occupy the target processor core, the second operating system determines the eligibility to occupy the target processor core, and when the second operating system determines to occupy the target processor core, the target processor core is released, and the second operating system occupies the target processor core.

[0060] In the mechanism for determining whether the second operating system is eligible to occupy the target processor core, if the second operating system is not eligible to occupy the target processor core, the second operating system can deny the second operating system from occupying the target processor core. For example, if the second operating system is not eligible to occupy the target processor core, the mechanism can send a fifth interrupt request to the second operating system, which indicates that the second operating system is denied from occupying the target processor core.

[0061] Optionally, in this embodiment, the refusal of the second operating system to occupy the target processor core may be, but is not limited to, notifying or indicating to the second operating system by sending an interrupt request between systems. Optionally, in this embodiment, if the second operating system does not occupy the target processor core, the second interrupt request does not need to be sent, and the first operating system does not release the target processor core but continues to occupy the target processor core, so that the second operating system cannot occupy the target processor core.

[0062] After sending a fifth interrupt request to the second operating system to deny the second operating system from occupying the target processor core, the first operating system continues to occupy the target processor core until the second operating system satisfies a target processor core occupancy condition (e.g., the system attribute reaches the target system attribute), and then the first operating system releases the target processor core to the second operating system and notifies the second operating system to take over and run.

[0063] 4 is a schematic diagram of a processor core occupation process according to an embodiment of the present application. As shown in FIG. 4, a first operating system is executed based on a target processor core. During the execution process, a second operating system sends a second interrupt request to the first operating system to request it to occupy the target processor core used by it. If the second operating system allows the occupation, it releases the target processor core, and the second operating system occupies the target processor core and adds it to the scheduling resource pool. If the second operating system does not allow the occupation, it sends a fifth interrupt request to the second operating system to reject it.

[0064] After the target processor core used by the first operating system is released, the second operating system can actively detect that the target processor core has been released and occupy the target processor core. Alternatively, when the second operating system actively sends a fourth interrupt request to request occupancy of the target processor core, the second operating system can directly occupy the target processor core by default unless it receives a fifth interrupt request denying occupancy of the target processor core within a certain period of time, thereby improving the efficiency of occupying the target processor core.

[0065] When the first operating system actively releases the target processor core for use, the first operating system may actively send an interrupt request to the second operating system to notify the second operating system that the target processor core has been released, for example, by sending a sixth interrupt request to the second operating system, where the sixth interrupt request is used to indicate that the first operating system has released the target processor core, and the second operating system may respond to the sixth interrupt request to add the target processor core to its scheduling resource pool.

[0066] When the system attributes reach the target system attributes, the first operating system can actively release the target processor core and send a sixth interrupt request to the second operating system to notify the second operating system that the target processor core has been released, and after receiving the sixth interrupt request, the second operating system service occupies the target processor core for resource scheduling and use.

[0067] In an alternative embodiment, if a first operating system (e.g., an RTOS) determines during execution that no threads require scheduling (e.g., the operating system's resource occupancy falls below or is about to fall below a predetermined lower limit), it can trigger active sleeping of the first operating system (RTOS), and the first operating system (RTOS) sends a sixth interrupt request to a second operating system (e.g., Linux), which stores the location to execute (e.g., pushes data to be executed onto a stack) and then sleeps, and the second operating system (Linux) adds the target processor core to its scheduling resource pool for scheduling and use after receiving the sixth interrupt request.

[0068] In a selectable application scenario, the chip is equipped with dual operating systems that run on a multi-core processor CPU, the first operating system may be, but is not limited to, an RTOS, and the second operating system may be, but is not limited to, Linux, CPU core 0 is assigned to the RTOS, and the remaining cores are assigned to Linux. Figure 5 is a schematic diagram 1 of a processor resource control process according to an embodiment of the present application. As shown in Figure 5, the RTOS periodically wakes up and runs, and the RTOS and Linux alternately occupy and schedule CPU core 0. In the time slice (T4, T5) when the RTOS schedules CPU core 0, Linux generates an interrupt to take over CPU core 0 at time T4-1 (corresponding to the fourth interrupt request above) and puts the RTOS to sleep. In this case, the RTOS stores the current situation in a stack and goes to sleep, then releases CPU core 0 to Linux and takes it over. After Linux scheduling is completed, at time T5-1, the RTOS generates an interrupt to preempt CPU core 0 and wakes up the RTOS. From time T5-1, the RTOS begins to enter round-robin mode, occupying CPU core 0 for scheduling.

[0069] In this embodiment, the inheritance of operating services between systems and the occupation of processors may be independent, but are not limited thereto, for example, only the inheritance of operating services or only the occupation of processor cores, and the occupation may be simultaneous, that is, not only the inheritance of operating services but also the occupation of processor cores.

[0070] In an alternative embodiment, the operating service is a device control service, for example, to describe the second operating system inheriting the processor resources of the first operating system. According to this embodiment, a boot control process for an operating system is provided, which includes: 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 first bus to control the execution state of the target device.

[0071] In devices such as servers, personal computers, and industrial computers, specific devices can be configured to perform or execute related operating systems. In the related art, these devices typically start operating after the system is powered on. However, after the system is powered on, the operating system running on the processor can normally take over and control the running status of the specific devices after a certain period of time, but during the boot process of the operating system, the specific devices are out of control.

[0072] For example, after the system is turned on, the fan starts to operate. After the system is turned on, the operating system running on the CPU will take over the fan normally after a certain period of time and can set the fan speed. Therefore, during the operating system startup process, the fan is out of control.

[0073] For example, to control the fan during the boot process of an operating system, a server uses a control method that combines a BMC and a CPLD, a personal computer uses an EC chip control method (the EC chip adjusts the fan speed according to the temperature), and an industrial computer uses a custom chip control method. During the boot process of the operating systems of a server, personal computer, and industrial computer, the CPLD, EC chip, and custom chip intervene to control the fan speed, and after the operating system has fully started, the application program in the operating system controls the fan.

[0074] To solve at least some of the above technical problems, a startup control method for a multi-core multi-system (e.g., a multi-core dual system) can be used, where different operating systems of an embedded system are run on different processor cores of a processor, and the response speeds of the different operating systems are different. In the event that the second operating system does not start up, does not restart, or cannot control the running state of a specific device, the running state of the specific device can be controlled by a second operating system whose response speed is faster than that of the second operating system. This can avoid the situation where the running state of a specific device cannot be controlled, and has excellent scalability without requiring additional costs.

[0075] In this embodiment, a first operating system running on a first processor core of a processor controls a hardware controller of a target device via a first bus to control the execution state of the target device under circumstances where a second operating system does not start, restart, or control the execution state of a specific device. The target device described herein may be a fan or other device that needs to run at system startup. For a fan, the corresponding hardware is a fan controller such as a PWM (Pulse Width Modulation) controller or a FanTach (fan rotation speed) controller. In this specification, a conventional first operating system (e.g., an RTOS system) is used instead of a CPLD, an EC chip, or a custom chip, reducing hardware costs and providing excellent scalability by enabling device control through software.

[0076] For example, a dual system consisting of an RTOS system and a Linux system is implemented based on a dual-core BMC, and a fan is implemented based on a multi-core system. Utilizing the high real-time characteristics of the RTOS system, during the startup process of the Linux system, the RTOS system controls the fan instead of the CPLD, EC chip, and custom chip. That is, it takes over the control process for the fan and controls the running status of the fan at a sufficient speed.

[0077] Step B, booting to launch 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 booted to start on the second processor core of the processor so that the second operating system runs on the second processor core. In this specification, booting the second operating system on the second processor core refers to scheduling the second processor core to the second operating system, and the system files or mirror files of the operating system can be stored on the chip where the processor resides or in a storage device off-chip, such as an external RAM (Random Access Memory).

[0078] Step C: After the second operating system is started, the second operating system takes over the hardware controller via the first bus to take over the control process of the target device. After the second operating system has booted, the first operating system can always control the execution state of the target device. Considering that running multiple operating systems on a multi-core processor requires data interaction between multiple operating systems and it is convenient to have one operating system perform overall control of the device, the second operating system can also take over the control process of the target device. For example, the second operating system can take over the hardware controller via the first bus. The second operating system can take over the control process of the target device by sending a device takeover request to the first operating system after booting, for example, by sending an interrupt request via the second bus to request taking over the hardware controller of the target device. The first operating system can receive the device takeover request from the second operating system and transfer the control process of the target device to the second operating system. It can also execute operations related to the transfer of the control process of the target device, such as stopping the execution of a service (process) that controls the execution state of the target device.

[0079] For example, after the Linux system has fully booted, the RTOS system will hand over the fan control process to the Linux system, which will then control the fan. The above process can also be performed after the system is powered on, i.e., using the boot method of a multi-core dual system, the RTOS system can be started first to facilitate early intervention in fan control. After the Linux system has fully booted, the RTOS system will hand over the fan control process to the Linux system for control.

[0080] In an exemplary embodiment, the first operating system running on the first processor core of the processor further includes, before the step of controlling the hardware controller of the target device via the first bus, a step of waking up the first processor core via the processor after powering on the chip on which the processor is located, and a step of executing a boot loader program of the first operating system on the first processor core and booting the first operating system to start on the first processor core.

[0081] The entire system can be divided into two stages, an initial startup stage and a real-time execution 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 execution stage. Regarding the initial startup stage, when the system is powered on, the initial startup stage is initiated, that is, the chip containing the processor is powered on, and one core is woken up to perform the boot operation of the operating system after the system is powered on, and the remaining cores are in a sleep state at the time, and the woken up core may be the first processor core.

[0082] Optionally, after powering on, the system first executes a preset core scheduling policy (start-up boot policy), that is, executes the core scheduling policy by the processor core of the processor. The core scheduling policy may be stored in RAM or Norflash (non-volatile flash memory) in the SOC chip (System on Chip). The scheduling policy can be flexibly arranged according to different design needs. Its main functions include specifying the initial processing resources (processor cores) that need to run different operating systems and determining the boot process of different operating systems. Powering on the chip refers to powering on the SOC chip.

[0083] After the first processor core is woken up, the boot loader program boots and runs the first operating system on the first processor core, and the first processor core can be booted so that the first operating system starts on the first processor core through the boot loader program. The boot loader program can be located in a computer or other computer application and refers to a program for booting to load an operating system, for example, a specific program of Boot ROM, where the specific program refers to code for booting to start an operating system and belongs to the Boot Loader program, and Boot ROM is a small masked read-only memory (MASK ROM) or write-protected flash memory built into the processor chip in a CPU chip.

[0084] In the initial boot stage, the boot loader program boots the operating system so that it starts on the corresponding processor core, thereby improving the success rate of booting the operating system and at the same time preparing for the real-time execution stage. In an exemplary embodiment, controlling a hardware controller of a target device via a first bus by a first operating system executing on a first processor core of a processor includes 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 sending a device control command to the hardware controller via the first bus based on the sensor data of the designated sensor by the first control task, so that the hardware controller controls the execution state of the target device in accordance with the device control command.

[0085] The operating system's control of a hardware controller of a target device may be a control task (service) in a processor core that executes the operating system controlling the hardware controller, and the control task described in this specification may refer to the corresponding control task. For the hardware controller of the target device, a first control task (first control process) of a first operating system may be executed in a first processor core, and the hardware controller may be controlled by the first control task.

[0086] Control of the hardware controller may be based on sensor data from a sensor. Different target devices may have different parameters affecting their execution, and the acquired sensor data may vary accordingly. The target device may be a device that runs immediately after the chip is powered on, and the corresponding sensor is a designated sensor. There are multiple types of designated sensors, including, but not limited to, at least one of a temperature sensor, a humidity sensor, and a noise sensor. The first control task is executed by the first processor core, and therefore the first processor core can read the 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 in a memory space designated by the designated sensor. In this embodiment, the location where the sensor data from the designated sensor is read is not limited.

[0087] The read sensor data of the designated sensor may be sensor data within a certain period of time, may be all sensor data since the target device was started, or may be sensor data that satisfies other time constraints. After acquiring the sensor data of the designated sensor, the first control task can control the running state of the target device based on the sensor data of the designated sensor. The control of the running state of the target device can be achieved 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 running state of the target device based on the device control command.

[0088] Optionally, the first control task may determine a desired execution state of the target device based on sensor data from a designated sensor, and if the current execution state of the target device differs from the desired execution state, generate the device control command. The device control command may be controlled to adjust the execution state of the target device to the desired execution state. The device control command may be transmitted to a hardware controller of the target device via a first bus. The first bus is the same as in the previous embodiment, and therefore will not be described here.

[0089] By reading the sensor data of the designated sensor, the target device is controlled based on the sensor data, the running state of the target device is controlled, and the resource utilization rate is improved. In an exemplary embodiment, the step of transmitting, by the first control task, a device control instruction to the hardware controller via the first bus based on sensor data of the designated sensor includes the step of determining, by the first control task, a target parameter value of an execution parameter of the target device based on the sensor data of the designated sensor, where the device execution parameter is a parameter for controlling the execution state of the target device; and the step of transmitting, by the first control task, a device control instruction including the target parameter value to the hardware controller via the first bus.

[0090] The first control task may determine a desired running state of the target device based on sensor data from a designated sensor. The desired running state may be indicated by a parameter value of a device's running parameter, and the device's running parameter may be a parameter for controlling the running state of the target device. Different types of devices may correspond to different running parameters. For example, a running parameter of a fan may be a rotation speed, and other types of devices may have other running parameters. The desired running state may correspond to a target parameter value of the running parameter of the target device.

[0091] After determining the target parameter value of the execution parameter of the target device, the above device control command can include the target parameter value, that is, the first control task sends the device control command including the target parameter value to the hardware controller, and the method of sending the device control command to the hardware controller is the same as in the above-mentioned embodiment, so the description will be omitted here.

[0092] The parameter values ​​of the execution parameters of the target device are determined based on the sensor data, and the device control command includes the determined parameter values, thereby improving the control accuracy of the device. In an exemplary embodiment, determining, by the first control task, a target parameter value for an performance parameter of the target device based on sensor data from a designated sensor includes, if the target device is a fan, determining, by the first control task, a target parameter value for an performance parameter of the fan based on sensor data from the designated sensor.

[0093] The target device may be a fan, and may be configured as a fan for dissipating heat from a server or other device in which it is located, i.e., a heat dissipation fan. In this case, the device's running parameters may be the running parameters of the fan, and the running parameters of the fan may include one or more, but are not limited to, at least one of the rotation speed, rotation period, and period switching time, and may also be other running parameters. This embodiment does not limit this.

[0094] Accordingly, determining, by the first control task, a target parameter value for the performance parameter of the target device based on the sensor data of the designated sensor may be determining, by the first control task, a target parameter value for the performance parameter of the fan based on the sensor data of the designated sensor. After obtaining the target parameter value, the first control task controls the performance state of the fan by sending a device control command including the target parameter value to a hardware controller of the fan via the first bus.

[0095] Controlling the state of the fan may be to quickly control the running state of the fan in a system power-on scenario, a system reboot scenario, or other scenarios, thereby improving the real-time nature of the fan control. In an exemplary embodiment, when the target device is a fan, determining a target parameter value for an execution parameter of the fan based on sensor data of a designated sensor by the 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 for a rotation speed of the fan based on 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.

[0096] 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, and the placement positions of the temperature sensors may be selectively selected, and different temperature sensors may have different placement positions. Optionally, the sensor data of the temperature sensor may be used to indicate the temperature detected by the temperature sensor, and accordingly, the first task may determine a target rotation speed value of the fan rotation speed based on the sensor data of the temperature sensor, where the fan rotation speed is positively correlated with the temperature detected by the temperature sensor.

[0097] When there are multiple temperature sensors, the maximum temperature detected by the multiple temperature sensors can be determined based on the sensor data of each temperature sensor, and the fan rotation speed can be determined based on the maximum temperature detected by the multiple temperature sensors, which can ensure the safety of device operation compared to determining the fan rotation speed based on the average temperature detected by the multiple temperature sensors. In a scenario where there are multiple fans, the rotation speed of each fan can be determined based on the maximum or average temperature detected by the temperature sensor attached to each fan.

[0098] For example, instead of a processing unit such as a CPLD, EC chip, or custom chip, the fan speed can be controlled by a first operating system (e.g., an RTOS system) (allowing real-time control of the BMC fan). When the system is first powered on, the first processor core (e.g., CPU0, which may be woken up by hardware) can be woken up, and the first processor core executes a boot loader program (e.g., a program specified in Boot ROM), which loads and starts the first operating system. The first processor core reads temperature-related sensor data and controls the fan (e.g., controls the fan speed), fully simulating the processing unit completing the fan control. When controlling the fan speed, the first operating system can adjust the fan speed by calculating a PWM value based on the temperature sensor. In this manner, the first operating system can control the fan speed during the boot process of the second operating system.

[0099] In an exemplary embodiment, the step of booting a second operating system to launch on a second processor core of the processor includes, for the first processor core, executing a two-stage program loader and waking up the second processor core with the two-stage program loader, and, by the second processor core, executing a generic boot loader of the second operating system to boot the second operating system to launch on the first processor core.

[0100] In this embodiment, when booting an operating system, a second program loader (abbreviated as SPL) can be loaded into an internal memory such as a static random-access memory (SRAM) inside the SOC, and the SPL can load a universal boot loader program (abbreviated as U-Boot) into a random-access memory (RAM). The second program loader can be booted to load a second operating system, and can also be booted to load a first operating system.

[0101] The second operating system can execute a two-stage program loader for the first processor core, wake up the second processor core by the two-stage program loader, and execute a generic boot loader (general-purpose boot loader program) of the second operating system by the second processor core to boot the second operating system to start on the first processor core. In this specification, the two-stage program loader boots to load a boot program of the second operating system, and the boot program of the second operating system includes a generic boot loader.

[0102] The second stage program loader is the code that executes in the first stage of the generic boot loader program, and can carry the second stage code of the generic boot loader program to system memory (system RAM, off-chip memory) for execution. The generic boot loader program is open source software that complies with the GPL (General Public License) agreement and can be considered a bare metal synthesis routine.

[0103] For example, after powering on the system, the processor first wakes up the CPU0 core so that the RTOS system can run as fast as possible, and then boots the RTOS system using a program in Boot ROM. During the boot process of the RTOS system, U-Boot continues to load using SPL, and U-Boot boots the second operating system on CPU1 until the Linux system boots normally.

[0104] Boot ROM is a specific program in the internal ROM of a chip (e.g., an SOC chip) and is the boot code of U-Boot. Boot ROM reads hardware startup information (e.g., dial switch settings) and reads the uboot-spl code (i.e., SPL) from a specified startup medium (e.g., SD, MMC, etc.). SPL is mainly used to initialize external RAM and environment, and load the actual U-Boot mirror image into external RAM for execution. The external RAM can be (Double Data Rate Synchronous Dynamic Random-Access Memory) or other RAM.

[0105] The two-stage program loader wakes up the second processor core, and then the second processor core executes a general-purpose boot loader program to boot the second operating system in the corresponding processor core, ultimately improving the convenience and success rate of the operating system. As an alternative example, the boot process of a multi-core dual system will be described below by taking an RTOS system and a Linux system as an example.

[0106] In order to take over fan management as quickly as possible, the RTOS system can be started as soon as possible, and after the Linux system has finished booting, the Linux system will take over the fan control process. The boot process of the multi-core dual system is as follows: When you first power on the system, step 1 wakes up CPU0, Step 2: CPU0 executes a specified program in Boot ROM, loads and starts the RTOS system; Step 3: during the boot process of the RTOS system, waking up CPU1 to boot U-Boot and launching a fan control program (FanCtrl_RTOS_APP) in the first operating system; CPU1 booting U-Boot includes an SPL stage and a U-Boot stage, and step 4 enters the SPL stage by calling SPL; In the SPL stage, SPL performs step 5, which boots U-Boot to start up. The U-Boot stage includes step 6 of loading the Linux cores (CPU1 to CPUN) and starting the BMC service program and the fan control program (FanCtrl_Linux_APP) in the second operating system.

[0107] According to this alternative embodiment, during the boot and running process of the dual system, the RTOS system is first started to control the fan, and after Linux is started, the second operating system takes over the fan control process, ultimately ensuring fast fan control when the system is powered on and improving fan control efficiency. In an exemplary embodiment, after the step of the second operating system taking over the hardware controller via the first bus, if the second operating system waits for reboot, the second operating system wakes up the first operating system via the second bus to take over the control process of the target device, and the method includes the steps of the first operating system taking over the hardware controller via the first bus and controlling the second operating system to reboot.

[0108] When a system crash occurs and the system needs to be restarted, such as by receiving a reboot command, the second operating system first wakes up the first operating system, and the first operating system takes over the hardware controller to take over the control process of the target device. Waking up the first operating system may be performed via the second bus, and the first operating system taking over the hardware controller may be performed via the first bus.

[0109] When the second operating system reboots, it takes over the control process of the target device by waking up the first operating system, which can improve the control reliability of the device. In an exemplary embodiment, when the second operating system is waiting to reboot, the second operating system issues a system wake-up interrupt to the first operating system via the second bus, the system wake-up interrupt being used to wake up the first operating system.

[0110] The first operating system can be woken up by an inter-core interrupt. When the second operating system is waiting to reboot (e.g., due to a system crash or receiving a reboot command), the second operating system can issue 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 the hardware controller, it can control the second operating system to reboot. After the second operating system reboots, it can take over the hardware controller again. The hardware controller takeover process is the same as in the previous embodiment, so a description thereof will be omitted here.

[0111] In an exemplary embodiment, the first operating system may have a higher priority for occupancy of the processor core assigned to it, but is not limited thereto, or which operating system currently uses the processor core assigned to the first operating system may be determined by negotiation between the operating systems. If the target processor assigned for use by the first operating system is already occupied by the second operating system, when the first operating system wakes up to run, it may detect whether the target processor core is released, and if released, the first operating system may execute based on the target processor core. If not released, it may send a seventh interrupt request to the second operating system to request that the second operating system release the target processor core, and after the second operating system releases the target processor core in response to the seventh interrupt request, the first operating system executes based on the target processor core. For example, when a target processor core in a processor has already been added to a scheduling resource pool of a second operating system and the first operating system is woken up to run, the scheduling resource pool includes processor cores assigned to the second operating system, and when the first operating system is woken up and detects that the second operating system has already released the target processor core, the first operating system is run based on the target processor core.

[0112] Alternatively, in this embodiment, the target processor core may already be added to the scheduling resource pool of the second operating system, which may indicate that the target processor core is already occupied. In this case, when the first operating system is woken up and running, the second operating system may actively release the target processor core. Furthermore, the second operating system may continue to occupy the target processor core until the first operating system actively requests that it release the target processor core.

[0113] Alternatively, in this embodiment, the first operating system may detect whether the target processor core is released, and if it detects that the target processor core is not released, it may request the second operating system to release the target processor core by an interrupt request. For example, if it detects that the target processor core is not released, it may send a seventh interrupt request to the second operating system, which is used to request the second operating system to release the target processor core, and the second operating system may release the target processor core in response to the seventh interrupt request. Optionally, in this embodiment, the second operating system can directly release the target processor core after receiving the seventh interrupt request, but is not limited thereto, or can determine whether to release the target processor core, and then decide whether to immediately release the target processor core to the first operating system, or can release the target processor core to the first operating system after obtaining the execution result through continued execution, but is not limited thereto.

[0114] In the above-mentioned selectable application scenario, FIG. 6 is a schematic diagram 2 of the processor resource control process according to an embodiment of the present application. As shown in FIG. 6, during the time slices (T3, T4) in which Linux schedules CPU core 0, the RTOS is in a sleep state. At time T3-1, the RTOS may be woken up by an interrupt event reported by the hardware. Linux memorizes the process location running on CPU core 0. The RTOS occupies CPU core 0. After completing the processing of the interrupt event reported by the hardware, the RTOS enters a sleep state again at time T4-1. In this case, the RTOS reports an interrupt to Linux to release CPU core 0. Linux continues to schedule CPU core 0 according to a predetermined period and recovers the running process on the location.

[0115] During the execution of the operating systems, service data may be exchanged between them, and the exchange may be realized by, but not limited to, cooperative transmission via storage space and interrupt requests. The operating systems may exchange data via storage space and send instructions to each other via interrupt requests. For example, the first operating system may acquire service data generated during its execution based on the processor, store the service data in the storage space of the processor, and send an eighth interrupt request to the second operating system service system. The eighth interrupt request is used to request the second operating system to read the service data from the storage space, and the second operating system may read the service data from the storage space in response to the eighth interrupt request.

[0116] Optionally, in this embodiment, the service data generated during the process of the first operating system being executed based on the processor is stored in the memory space of the processor, and notifies the second operating system by an eighth interrupt request, and the second operating system reads the service data from the memory space, and finally realizes the interaction of the service data.

[0117] Optionally, in this embodiment, the service data of the interaction between the operating systems may be, but is not limited to, all data that needs to be transmitted between the systems in the process of the operating systems executing the operating services, such as service process data and service result data. Alternatively, in this embodiment, the memory space in the processor may be, but is not limited to, a dedicated memory location allocated for the interaction process between operating systems, and is called a shared memory, which may be, but is not limited to, continuously reallocated according to the operating system (i.e., each operating system corresponds to a portion of the dedicated shared memory).

[0118] The eighth interrupt request for requesting the second operating system to read service data from the memory space may include information (e.g., a memory address) of the shared memory corresponding to the first operating system, and the second operating system responds to the eighth interrupt request and reads the service data from the indicated shared memory. In this embodiment, each interrupt request can be transmitted between systems by a software protocol or by a hardware module, but is not limited thereto. For example, an interrupt request is transmitted in the form of a mailbox in a hardware module. A mailbox channel is established between the first operating system and the second operating system, service data is read and written in the storage space, and the interrupt request is transmitted through the mailbox channel.

[0119] According to an alternative embodiment, a method for communication between cores is provided, the method comprising the following steps: Step a: the first operating system transmits target data (the above-mentioned service data) to a target virtual channel (the above-mentioned storage space) in the processor memory.

[0120] Alternatively, the first operating system and the second operating system may be real-time operating systems or non-real-time operating systems, the first operating system and the second operating system may be single-core operating systems or multi-core operating systems, the target data is data to be sent, the target virtual channel is a part of an idle storage space, and the first operating system sending the target data to the target virtual channel in the processor memory refers to the CPU core of the first operating system writing the data to be sent to the target virtual channel.

[0121] Step b: sending an interrupt notification message (the above eighth interrupt request) to the second operating system; Optionally, the CPU core of the first operating system sends an interrupt notification message to the CPU core of the second operating system, and the interrupt notification message including the address of the target virtual channel is used to notify the second operating system to read target data from the target virtual channel, and the interrupt notification message can be triggered by software or by hardware.

[0122] Step c, the second operating system retrieves the target data from the target virtual channel in the memory in response to the interrupt notification message. Optionally, the CPU core of the second operating system responds to the interrupt notification message, analyzes the address of the target virtual channel from the interrupt notification message, then locates the target virtual channel in memory based on the analyzed address, obtains target data from the target virtual channel, and realizes data interaction between the first operating system and the second operating system.

[0123] Through the above steps, when multiple operating systems running on a processor need to transmit data to each other, the first operating system that sends the data sends the target data to a target virtual channel in the processor memory and sends an interrupt notification message to the second operating system, and the second operating system that receives the data retrieves the target data from the target virtual channel in response to the interrupt notification message, thereby solving the problems of resource waste and high dependency on operating systems during inter-core communication and achieving the effects of reducing resource waste during inter-core communication and reducing dependency on operating systems.

[0124] In an exemplary embodiment, the memory includes a data storage area and a metadata storage area, the data storage area is divided into a plurality of storage units, each storage unit configured to store service data, and the metadata storage area is configured to store the size and occupancy status of each storage unit of the data storage area. Optionally, the target virtual channel may be composed of one or more storage units of the storage area, and the metadata storage area may be divided into storage chips in the same number as the number of storage units, and each storage chip may be configured to record the size and occupied status of one storage unit, and the size of the storage unit may be indicated by the start address and end address of the storage unit, or by the start address and length of the storage unit, and the occupied status may include an occupied state and an unoccupied state and may be indicated by the numerical value of an idle flag.

[0125] In an 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, determining at least one storage unit in the data storage area that is idle and has a total space greater than or equal to the length of the target data based on the read record, and obtaining the target virtual channel; and setting the state of the at least one storage unit in the metadata storage area corresponding to the virtual channel to an occupied state, and storing the target data in the target virtual channel.

[0126] In addition, to ensure that the target data is written continuously to the memory, the written target virtual channel must have an idle 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 storage unit recorded in the metadata storage area can be read to find an idle storage unit that meets the data storage needs.

[0127] For example, if the size of each storage unit is equal and the length of the target data is greater than the length of one storage space, the number of required storage units is determined based on the length of the target data, and then a number of idle, consecutive storage units that meet the storage needs are found from among them, and a target virtual channel is configured.

[0128] For example, the size of each storage unit is equal, and the data storage area is pre-combined to obtain multiple virtual channels of different sizes, each virtual channel being composed of one or more storage units. The occupancy status of each virtual channel recorded in the metadata storage area can be read to find an idle virtual channel whose length is greater than the length of the target data, i.e., the target virtual channel. When the system software needs to request shared memory space, it determines whether the length of the requested data is greater than the maximum length of the data stored in the virtual channel. If it is greater than the maximum length of the data stored in the virtual channel, the system software can transmit the data to be transmitted multiple times to ensure that the length of the data transmitted each time is less than or equal to the maximum length of the data stored in the virtual channel, ultimately ensuring smooth communication.

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

[0130] That is, after extracting the target data from the storage unit corresponding to the target virtual channel, the second operating system sets the state of the storage unit 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. In an 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 in memory, obtaining the target virtual channel, setting the state of the target virtual channel to an occupied state, and storing the target data in the target virtual channel.

[0131] Optionally, both the real-time operating system and the non-real-time operating system have a driving layer, and after the driving layer receives the target data to be sent, the calling interface finds the target virtual channel from the memory, and sets the state of the target virtual channel to an occupied state after finding the target virtual channel to avoid other systems requesting to use the target virtual channel during the data writing process, and then writes the target data to the target virtual channel.

[0132] In an exemplary embodiment, when the first operating system includes an application layer, the application layer is provided with a man-machine interface, and before the step of the drive layer of the first operating system determining the virtual channel in an idle state in the memory, the step of the application layer of the first operating system receiving data to be sent input by a user through the man-machine interface, packaging the data to be sent in a predetermined format, obtaining target data, and calling a data write function to transmit the target data to the drive layer through a predetermined communication interface, wherein the predetermined communication interface is provided in the drive layer.

[0133] Optionally, the application layer fills the data to be sent according to a predetermined format to obtain target data, and then generates a device file ipidev in the / dev path of the system; when the application needs to read or write data from the drive layer, it can first use the open function provided by the system to open the device file / dev / ipidev, and then use the write function provided by the system to send the target data from the application layer to the drive layer; the drive layer puts the data into a target virtual channel in the shared memory, and then triggers an interrupt to notify the second operating system to read the data.

[0134] In an 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 by the interrupt handling function, and retrieving the target data from the target virtual channel.

[0135] In an exemplary embodiment, the step of determining the target virtual channel from memory by an interrupt handling function and obtaining the target data from the target virtual channel includes the steps of calling a target task by the interrupt handling function, the target task determining the target virtual channel from memory, and obtaining the target data from the target virtual channel.

[0136] Optionally, the interrupt handling function sends a task notification to wake up the target task to extract data, and the target task first finds the target virtual channel from the shared memory via the call interface, and then reads and analyzes the target data from the target virtual channel. In an exemplary embodiment, when the second operating system includes an application layer, the memory includes a feature flag, the feature flag indicating a target function, and the step of determining a target virtual channel from the memory by an interrupt handling function and obtaining target data from the target virtual channel includes the steps of: obtaining the feature flag and the target virtual channel from the memory by the interrupt handling function, and sending address information of the target virtual channel to a target application program matching the feature flag, where the target application program is 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 target application program through a predetermined communication interface, where the predetermined communication interface is provided in the drive layer, and the target application program processing the target data based on the processing function matching the feature flag to perform the target function.

[0137] Optionally, after the second operating system receives the interrupt notification message, the application layer calls a corresponding interrupt handling function to find the target virtual channel in memory, obtains the address information of the target virtual channel, and then creates a device file ipidev under the system's / dev path. When the application layer needs to read or write data from the drive layer, it can first use the open function provided by the system to open the device file / dev / ipidev, and then use the read function provided by the system to read the target data in the target virtual channel. That is, the drive layer finds the corresponding target data from the shared memory based on the address information of the target virtual channel, and returns the target data and the length of the target data to the application layer. In an exemplary embodiment, the drive layer sets the target virtual channel to an idle state.

[0138] In addition, application programs in different application layers can realize different functions using the target data. The memory stores a function flag indicating the target function that the application program realizes using the target data. Optionally, the function flag can be set to Net Fn , Cmd can be, in case of system initialization, Net Fn , Cmd and application program PID are registered in the driver, and the driver 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.

[0139] For example, NetFn=1, Cmd=1 indicates that the first and second operating systems send "hello word" to each other. An array is initialized when the system starts up, and the array has 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, which is 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, and if it determines that NetFn=1, Cmd=1, it executes the corresponding processing function of "hello word", HelloCmdHandler, to complete the corresponding function.

[0140] In an exemplary embodiment, the data storage area includes a plurality of memory channels, each memory channel consisting of one or more storage units; a plurality of records are stored in the metadata storage area, each record 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; the first operating system reads the records in the metadata storage area and determines, based on the read records, at least one idle storage unit in the storage area whose total space is equal to or greater than the length of the target data; and the step of obtaining the target virtual channel includes the steps of: traversing the records stored in the metadata storage area and determining whether there is a first target record indicating that the memory channel is idle and the size of the memory channel is equal to or greater than the length of the target data; and if there is the first target record, determining the memory channel indicated by the channel ID in the first target record as the target virtual channel.

[0141] The data storage area is divided into n virtual memory channels, and the size of each memory channel does not have to be equal. That is, the sizes of the n virtual memory channels are 20*m, 21*m, 22*m, 23*m ... 2n-1*m, respectively, where m is the size of one storage unit. The following structure is set as the metadata management memory channel:

[0142] 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

[0143] where uint32_t Flag indicates the state of the memory channel, for example, 0xA5A5A5A5 indicates that this channel is not idle, otherwise it is idle; uint16_t ChannelId indicates the channel ID; uint8_t SrcId indicates the source CPU ID, where source CPU refers to the CPU for writing data to the memory channel; uint8_t NetFn and uint8_t Cmd are function parameters; uint32_t Len is the length of the data stored in the memory channel; uint32_t ChannelSize indicates the size of the memory channel; uint8_t *pData indicates the start address of the memory channel; "CheckSum" refers to a checksum. When the first operating system needs to send data, it calculates a checksum for the data to be sent using a checksum algorithm and sends the checksum to the second operating system. When the second operating system receives the data and the checksum, it calculates a checksum based on the received data using the same checksum algorithm and compares the calculated checksum with the received checksum. If they match, it indicates that the received data is valid; if they do not match, it indicates that the received data is invalid. Each virtual memory channel corresponds to a structure record, which is stored at the start of the shared memory according to an incremental channel ID. After the system is powered on, these structure records are initialized. If the initialization flag is 0, it indicates that the channel is idle. The initialization channel ID is 0, 1, 2, ... n-1, respectively. The initialization channel size is the size of the corresponding virtual memory channel, and the initialization pData indicates the start address of the corresponding virtual memory channel.

[0144] In an exemplary embodiment, when determining a target virtual channel, the first operating system uses the interface GetEmptyChannel to search all memory channels for a virtual channel that meets the following two conditions based on the size of the target data to be sent. These conditions are: 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 can meet the storage needs of the target data). After finding a target virtual channel that meets the above conditions, the first operating system sets the state of the channel to non-idle, i.e., sets the idle flag Flag in the channel structure IpiHeader to 0xA5A5A5A5, and then copies the target data into the target virtual channel.

[0145] In an exemplary embodiment, when the memory channel is occupied, the metadata of the memory channel further includes an ID of a source CPU core of the target data and an ID of a destination CPU core of the target data, and the step of the second operating system reading the record in the metadata storage area and determining the target virtual channel based on the read record includes the steps of traversing the records in the metadata storage area and determining whether there is a second target record, wherein the second target record indicates that the memory channel is in an occupied state and the ID of the destination CPU core is the ID of a CPU core of the second operating system and the ID of the source CPU core is not the ID of a CPU core of the second operating system, and if there is the second target record, determining the memory channel indicated by the channel ID in the second target record as the target virtual channel.

[0146] That is, the target virtual channel is a virtual channel among all channels that meets the following three conditions: 1. The idle flag Flag in the channel structure IpiHeader is equal to 0xA5A5A5A5 (i.e., indicating that the channel is in an occupied state), 2. The TargetId in the channel structure is equal to the ID of the current CPU (i.e., indicating that the destination CUP of the target data is the CUP of the second operating system), and 3. The TargetId in the channel structure is not equal to the SrcId (i.e., indicating that the target data is not sent by the CPU of the second operating system).

[0147] When the idle flag is represented by one bit, 0 indicates that the channel is idle and 1 indicates that the channel is not idle. If the flag changes from the original 0 to 1, the system will read the flag and consider the channel to be not idle, resulting in a communication error. In this embodiment, the idle flag is set to a multi-bit special character such as 0xA5A5A5A5. The probability of multiple bits changing to a special character at the same time is much smaller than the probability of a single bit changing, which prevents changes to bits on the storage medium from affecting the value of the flag, ultimately improving communication security.

[0148] In an exemplary embodiment, the metadata storage area stores a mapping table, the mapping table has a plurality of records, and each record is used to record the occupied state of one storage unit; the first operating system reads the records in the metadata storage area and determines at least one idle storage unit in the data storage area whose total space is equal to or greater than the length of the target data; and the step of obtaining the target virtual channel includes the steps of determining a predetermined number of storage units to be occupied by the target data, scanning each record in order from an initial position of the mapping table, and when scanning the predetermined number of consecutive target records, determining consecutive storage units indicated by the predetermined number of target records, wherein the target records characterize the storage units as being in an idle state; and determining the consecutive storage units as the target virtual channel.

[0149] In addition, in order to facilitate data storage and retrieval, when the operating system transmits service data, it needs to occupy consecutive storage units in memory. Therefore, it is necessary to first determine the number of storage units in the memory request command. Since the memory space of each storage unit is the same, the predetermined number of consecutive storage units required can be calculated based on the size of the required memory space. The predetermined number is denoted as numb.

[0150] Optionally, the first operating system traverses the records from an index position in the mapping table, where the index position may be the starting position of the mapping table, and starts from the starting position of the mapping table, queries each record in the mapping table in order, and determines whether there are numy or more consecutive records of idle memory pages. If there are records that satisfy the above condition, determine consecutive storage units in the processor by recording their correspondence with the memory pages, and determine the consecutive storage units as target virtual channels, and write data to the target virtual channels.

[0151] In an exemplary embodiment, the interrupt message includes a starting address and a predetermined number of consecutive storage units, and the step of the second operating system reading the record in the metadata storage area and determining the target virtual channel based on the read record includes the steps of scanning each record in order from an initial position of the mapping table, and when the scanning finds that the starting addresses of consecutive storage units are recorded, determining the storage unit indicated by the scanned address and the predetermined number minus 1 consecutive storage units as the target virtual channel.

[0152] Optionally, the consecutive storage units refer to consecutive storage units whose number is equal to numb, and each record in the mapping table has a starting address of the corresponding storage unit. When the second operating system scans the starting address of the consecutive storage units whose number is equal to numb from the mapping table, it indicates that it is scanning the starting address of the target virtual channel. The storage unit indicated by the starting address and numb-1 consecutive storage units after the storage unit constitute the target virtual channel. To complete data interaction with the first operating system, the second operating system reads data from the target virtual channel.

[0153] In an exemplary embodiment, a counter records the successive target records scanned, and in the process of scanning each record sequentially from the initial position of the mapping table according to the number of storage units, if a target record is currently being scanned, the counter is controlled to be incremented by 1, and if a non-target record is currently being scanned, the counter is controlled to be cleared to 0. Optionally, determine whether there are a predetermined number of consecutive target records, i.e., whether there are a predetermined number of consecutive storage units, based on the magnitude relationship between the value of the counter and the number of required storage units; optionally, the count of the counter is denoted as cntr; if the scanned storage unit is idle, add 1 to cntr; if the scanned storage unit is not idle, clear the accumulated number of consecutive storage units cntr to 0; continue searching for idle consecutive storage units from one address after the storage unit, until cntr is equal to numb, indicating that an idle consecutive storage unit that meets the memory need has been found; if there is no cntr greater than or equal to numb after scanning the entire mapping table, the current dynamic memory request has failed, indicating that there are not a predetermined number of consecutive storage units.

[0154] In an exemplary embodiment, the first operating system reads a record in the metadata storage area, and determines at least one idle storage unit in the data storage area based on the read record, whose total space is equal to or greater than the length of the data, and before obtaining the target virtual channel, the method further includes a step in which the first operating system sends a memory request command and locks the memory of the processor, wherein the memory request command is used to request use of the memory of the processor, and if the memory is successfully locked, a step in which the first operating system reads the record in the mapping table.

[0155] Alternatively, the memory request command is a command sent from an operating system running on a processor to request the use of the processor's memory. To prevent conflicts caused by multiple operating systems simultaneously requesting the use of the processor's memory, when an operating system sends a memory request command, it first locks the processor's memory and can request the use of the memory only if the locking is successful. The locking operation refers to the exclusive operation of the memory request. Unless the current operating system successfully locks and unlocks the memory, other servers are not authorized to request the use of the processor's memory.

[0156] In an exemplary embodiment, locking the processor's memory includes determining whether it is currently in a locked state, where the locked state indicates that the memory is in a state where it is being requested for use; locking the memory if the memory is currently in an unlocked state; and determining that locking the memory failed if the memory is currently in a locked state and requesting to lock the processor's memory again after a predetermined length of time until the memory is successfully locked or until the number of lock requests is greater than a predetermined number.

[0157] Before the processor executes, it is necessary to initialize the metadata storage area and the data storage area in the processor, and optionally initialize the records stored in the mapping table in the metadata storage area and initialize the memory management information. Before requesting memory, set the memory management information as follows:

[0158] typedef struct { uint32_t MemReady; uint32_t MemLock; }MallocMemInfo_T;

[0159] Here, the member variable MemLock of the structure MallocMemInfo_T indicates whether the initialization of the shared memory is complete, and if the variable MemReady is 0xA5A5A5A5, it indicates that the initialization has already been completed and the memory can be dynamically requested or released normally, and the member variable MemReady of the structure MallocMemInfo_T indicates whether it is locked.

[0160] Alternatively, if the variable MemLock is read as 0, it indicates that there is no system or task requesting memory, i.e., the memory is currently locked. If the variable MemLock is read as 0xA5A5A5A5, it indicates that there is a system or task requesting memory, and that the memory needs to be requested after the current request is completed, and the current lock request will fail.

[0161] In an exemplary embodiment, when locking memory, if a locking failure occurs, the memory is requested to be locked again after waiting a predetermined length of time until the locking is successful, for example, the predetermined length of time may be 100 microseconds. In an exemplary embodiment, if a lock request fails and the number of repeated requests exceeds a predetermined number, it indicates that the processor memory is unavailable for allocation for the current length of time, and the requesting operation is halted. For example, the predetermined number may be three times, and if the number of lock requests is greater than three, a message indicating that current memory is unavailable may be returned to the requesting operating system.

[0162] Optionally, if there is a target virtual channel in the processor's memory space that can be used by the first operating system, the first operating system stores the target data to be transmitted in the corresponding target virtual channel, and in an exemplary embodiment, updates the occupation status of the processor's memory space based on the data writing status of the first operating system, i.e., changes the target's contiguous memory space from an unoccupied state to an occupied state, and at the same time unlocks the memory so that other systems or tasks can request the memory.

[0163] In an exemplary embodiment, the method unlocks the memory if a predetermined number of consecutive target records are not scanned. Optionally, if a predetermined number of consecutive idle storage units are not detected after scanning the records in the mapping table, it indicates that the processor's memory cannot provide enough space memory pages to the first operating system, and the current dynamic memory request fails and the memory is unlocked.

[0164] In an exemplary embodiment, an interrupt notification message is sent to the second operating system by way of a software interrupt. The step of sending an interrupt notification message to the second operating system by way of a software interrupt includes the steps of writing an interrupt number and an ID of a CPU core of the second operating system to a predetermined register of the processor, and generating an interrupt notification message based on the interrupt number and the ID of the CPU core of the second operating system.

[0165] Alternatively, the soft interrupt is an interrupt generated by software, and the software can send an interrupt to the CPU core that runs it, or can send an interrupt to another CPU core. The predetermined register may be a GICD_SGIR register, and to generate a software interrupt, the software can write an SGI (Software Generated Interrupts) interrupt number and a target CPU ID to the GICD_SGIR register, and the SGI interrupt number is a soft interrupt number for communication between cores.

[0166] In a multi-core heterogeneous operating system, in order to achieve maximum compatibility with the current resource allocation method, numbers 8 to 15 (a total of 8 interrupts) are used to indicate the inter-core interrupt vector table. If the first operating system is an RTOS operating system and the second operating system is a Linux operating system, one possible allocation method for the vector table is shown in Table 1.

[0167] [Table 1]

[0168] In an exemplary embodiment, an interrupt notification message is sent to the second operating system by way of a hardware interrupt. Alternatively, a hardware interrupt refers to an interrupt generated by a hardware device, and may be a private peripheral interrupt or a shared peripheral interrupt. A hard interrupt is an interrupt generated by hardware outside the CPU and is random, while a soft interrupt is an interrupt generated by software running on the CPU executing an interrupt instruction and is preset. This embodiment does not limit the method of generating an interrupt notification message.

[0169] According to an alternative embodiment, a memory sharing scheme is provided, which comprises the following steps: Step 101: receiving a memory request command and locking the memory of the processor, the memory request command is used to request the use of the memory of the processor.

[0170] Alternatively, the memory request command is a command sent from an operating system running on a processor to request the use of the processor's memory. In order to prevent multiple operating systems from simultaneously requesting the use of the processor's memory, when an operating system sends a memory request command, it first locks the processor's memory, and can request the use of the memory as long as the locking is successful. The locking operation refers to the exclusive operation of the memory request. After the current operating system successfully locks it, other servers will not have the right to request the use of the processor's memory unless it unlocks it.

[0171] In the memory sharing method provided by an embodiment of the present application, before locking the memory of a processor, the method further includes the steps of determining whether the memory is currently in a locked state, where the locked state indicates that the memory is in a state where it is being requested for use, and locking the memory if the memory is currently in an unlocked state. Optionally, since multiple operating systems or multiple tasks may simultaneously request use of memory, resulting in contention, the processor's memory may only be locked by one system or task at a time quantum, and therefore the current operating system may lock the memory as long as it detects that the memory is currently in a locked state.

[0172] Optionally, determine whether the memory is in a locked state by determining whether a predetermined variable stored in the memory is a predetermined value, and if the predetermined variable is not a predetermined parameter value, it indicates that the memory is not in a locked state, there is no other system or task requesting the memory, and the locking is successful; otherwise, it indicates that the predetermined variable is a predetermined parameter, and at the current time, the memory is in a locked state, and another system or task other than the operating system is requesting memory space, and the locking fails.

[0173] After determining whether the memory is currently in a locked state, the memory sharing method further includes the steps of: determining that locking the memory has failed if the memory is currently in a locked state; and, if locking the memory has failed, requesting to lock the processor's memory again after a predetermined length of time until the memory is successfully locked or until the number of lock requests is greater than a predetermined number.

[0174] Optionally, when locking memory, if a locking failure occurs, a request to lock the memory again is made after waiting a predetermined length of time until the locking is successful, for example, the predetermined length of time may be 100 microseconds. In an exemplary embodiment, if a lock request fails and the number of repeated requests exceeds a predetermined number, it indicates that the processor memory is unavailable for allocation for the current length of time, and the requesting operation is halted. For example, the predetermined number may be three times, and if the number of lock requests is greater than three, a message indicating that current memory is unavailable may be returned to the requesting operating system.

[0175] Step 102: If the memory is successfully locked, read the occupied status of the memory, and determine based on the occupied status of the memory whether there is an idle target memory space in the memory, and the size of the target memory space is equal to or greater than the memory size requested by the memory request command. If the lock request is successful, the operating system requests memory from the processor, and optionally scans the information for recording the occupied state of the memory to determine whether the target memory space exists, that is, whether the memory has a contiguous memory space that is in an unoccupied state and meets the memory usage needs, and meeting the memory usage needs means that the size of the memory space is equal to or greater than the memory size requested by the operating system.

[0176] In addition, when requesting memory, non-contiguous memory space can be used, and a pointer can be added after one or more smallest memory blocks to point to the next smallest memory block obtained by the request, and at the same time, when reading or writing data, data can be read or written between data blocks based on the memory address and the pointer. This embodiment does not limit the form of the target memory space.

[0177] Step 103: if the memory has the target memory space, feed back the address information of the target memory space to the sender of the memory request command, update the occupied status of the memory, and unlock the memory. The sender refers to the operating system for sending the memory request command. In the case of communication between cores, the operating system sends and receives data through the shared memory. In the process of sending and receiving data, the operating system needs to determine the address information of the requested memory space in order to store the data using the address returned by the requested memory.

[0178] Optionally, if the processor memory space has a target memory space for the operating system, address information of the target contiguous space is sent to the operating system, and the operating system stores the data to be transmitted in the corresponding memory space based on the address information. In an exemplary embodiment, the occupied state of the processor's memory space is updated based on the data writing status of the operating system, i.e., the target memory space is changed from an unoccupied state to an occupied state, and the lock state before dynamically requesting the memory is released so that other operating systems can request to use the processor's memory space.

[0179] Through the above steps, a memory request command is received and the memory of the processor is locked. 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, based on the occupied status of the memory, it is determined whether there is an idle target memory space in the memory. If the size of the target memory space is equal to or greater than the size of the memory requested by the memory request command and there is target memory space in the memory, the address information of the target memory space is fed back to the sender of the memory request command, the occupied status of the memory is updated, and the memory is unlocked, thereby solving the problems of low utilization efficiency, low flexibility, and excessive dependency on the operating system of the shared memory between multiple cores, and achieving the effects of improving the flexibility and utilization efficiency of the shared memory and reducing dependency on the operating system.

[0180] In the memory sharing method, the memory includes a metadata storage area and a data storage area, the data storage area is configured to store service data, a mapping table is stored in the metadata storage area, and the mapping table is configured to record the occupied state of the data storage area, and the step of reading the occupied state of the memory and determining whether there is idle target memory space in the memory based on the occupied state of the memory includes the step of reading the record in the mapping table from the metadata storage area and determining whether there is target memory space in the data storage area based on the record in the mapping table.

[0181] The occupied state of the memory is queried by querying the records in the mapping table, and the occupied state of the data storage area is read by selectively obtaining a metadata storage area stored in the processor, identifying a mapping table in the metadata storage area, and traversing the records in the mapping table to determine whether the data storage area has a continuous memory space that is idle and meets the memory usage needs.

[0182] In a memory sharing method provided by an embodiment of the present application, the data storage area is composed of a plurality of memory pages, the mapping table includes a plurality of records, each record is used to record the occupied state of one memory page, and the step of reading the records in the mapping table from the metadata storage area and determining whether the data storage area has the target memory space based on the records in the mapping table includes the steps of determining a predetermined number of memory pages requested by the memory request instruction, scanning each record in order from an initial position of the mapping table, and determining that the memory has the target memory space when scanning a consecutive predetermined number of target records, wherein the target record indicates that the memory page is in an idle state.

[0183] The data storage area is divided into multiple allocation units according to the same memory size, and each allocation unit is referred to 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 mapping table are memory page records. Each memory page record is used to record the occupied status of the memory page, and the number of memory page records in the mapping table is the same as the number of memory pages in the data storage area.

[0184] 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 the number of memory pages according to the data storage area and divides the same number of records into them, which are marked as memory page records. The records of all memory pages are combined into a mapping table, and the records of all memory pages in the mapping table correspond one-to-one to all memory pages in the data storage area. The record of each memory page indicates the allocation status of the corresponding memory page, i.e., whether the memory page is occupied or not.

[0185] Alternatively, since the service data handled by the operating system needs to occupy consecutive memory pages in the processor, it is necessary to first determine the predetermined number of memory pages in the memory request command. Since the memory space of each memory page is the same, the predetermined number of consecutive memory pages required can be calculated based on the size of the required memory space, and the predetermined number is denoted as numb.

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

[0187] In the memory sharing method provided by the embodiment of the present application, after scanning each record in the mapping table in order from the initial position, the method determines that there is no target memory space in the memory when scanning all records in the mapping table is completed and there are no consecutive predetermined number of target records. Optionally, starting from the start position of the mapping table, it is determined whether the memory page records in the mapping table have a contiguous space with a number equal to or greater than numb memory pages, and if the scan through the mapping table is completed and no contiguous predetermined number of idle memory pages are found, it indicates that the target memory space is unavailable.

[0188] In the memory sharing method provided by the embodiment of the present application, a counter is used to record the number of scanned target records. In the process of scanning each record in turn from the initial position of the mapping table, if the current target record is scanned, the counter is controlled to be incremented by 1. If a non-target record is scanned, the counter is controlled to be cleared to 0, and the non-target record indicates that the memory page is in an occupied state.

[0189] If necessary, the value of the counter is compared with the number of required memory pages to determine whether there are a predetermined number of consecutive target records, i.e., whether there is target memory space. Optionally, the count of the counter is denoted as cntr. If a scanned memory page is idle, cntr is incremented by 1. If the scanned memory page is not idle, the accumulated number of consecutive memory pages in the idle state, cntr, is cleared to 0. Starting from one address after the memory page, idle consecutive storage units are continuously searched until cntr is equal to numb, indicating that idle consecutive memory pages that meet the memory need have been found. In the process of scanning the entire mapping table, if cntr is smaller than numb, it indicates that the current dynamic memory request has failed and the target memory space is not available.

[0190] In the memory sharing method provided by the embodiment of the present application, when the initial location is the last location in the mapping table, the step of feeding back address information of the target memory space to the sender of the memory request command includes the step 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.

[0191] Alternatively, when scanning the mapping table, the scanning method can be to start scanning from the first position or the last position of the mapping table. If the scanning method is to scan from the last position of the mapping table, if the value cntr indicated by the counter is equal to or greater than a predetermined number numb, record the start address of the corresponding memory page of the last memory page scanned, and set the status of these memory pages to non-idle in the memory pages, and set the start address to the start address of the entire consecutive memory pages of this memory request command.

[0192] In an exemplary embodiment, the address is fed back to the operating system issuing the memory request command, and the operating system performs a data write operation to memory based on the address information. In the memory sharing method provided by the embodiment of the present application, when the initial location is the first location in the mapping table, the step of feeding back address information of the target memory space to the sender of the memory request command includes the step of determining the first scanned target record among 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.

[0193] Alternatively, if the scanning method is to scan from the first position of the mapping table, if the value cntr indicated by the counter is equal to or greater than a predetermined number numb, the address recorded in the first scanned memory page is sent as the starting address to the operating system that issues the memory request command, and the operating system performs a data write operation on the memory based on the address information.

[0194] In the memory sharing method provided by the embodiment of the present application, in the process of scanning each record in order from the initial position of the mapping table, the first target record among the scanned consecutive target records is stored in a predetermined variable. Optionally, the predetermined variable refers to a variable of a mapping table for storing address information of the initial location, denoted as offset, and every time idle consecutive memory pages are scanned, the value cntr indicated by the counter is incremented by 1, and if the value cntr indicated by the counter is equal to or greater than a predetermined number numb, the address information currently stored in offset is the address of the first target record.

[0195] In a memory sharing method provided by an embodiment of the present application, after reading an occupied state of a memory and determining whether the memory has an idle target memory space based on the occupied state of the memory, the method includes a step of unlocking the memory if the memory does not have an idle target memory space. Optionally, after scanning the memory page records in the mapping table, if it is found that the memory page records do not contain a predetermined number of consecutive idle memory pages, i.e., do not contain the target memory space, it indicates that the processor's memory cannot provide enough space memory pages to the first operating system, and the current dynamic memory request fails, and the memory is unlocked.

[0196] In a memory sharing method provided by an embodiment of the present application, the memory includes a metadata storage area and a data storage area, the data storage area is configured to store service data, and memory management information is stored in the metadata storage area, and the step of determining whether the memory is currently in a locked state includes the steps of reading the memory management information stored in the metadata storage area and determining whether the memory management information includes predetermined information, where the predetermined information indicates that the memory is in a locked state; determining that the memory is currently in an unlocked state if the memory management information includes the predetermined information; and determining that the memory is currently in a locked state if the memory management information does not include the predetermined information.

[0197] To determine whether the processor's memory is in a locked state, it is necessary to use the memory management information in the metadata storage area. Optionally, when the memory management information in the metadata storage area is obtained, the basis is used to determine whether the memory management information contains specified information, and the specified information is used to indicate whether the memory is in a locked state. If the memory management information does not contain the specified information, it indicates that the memory is currently in an unlocked state; otherwise, it indicates that the memory is in a locked state.

[0198] In the memory sharing method provided by an 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 is completed, and before receiving a memory request command, the method further includes a step of initializing the first field information and the second field information stored in the data storage area.

[0199] Before the embedded system executes, it is necessary to initialize the metadata storage area and the data storage area in the processor, and optionally initialize the records of memory pages stored in the mapping table in the metadata storage area, and initialize memory management information. Optionally, the memory management information is composed of first field information and second field information, i.e., the first field information is used to indicate whether it is locked or not, and the second field information is used to indicate whether initialization is completed or not, and before requesting memory, the memory management information is set as follows:

[0200] typedef struct { uint32_t MemReady; uint32_t MemLock; }MallocMemInfo_T;

[0201] Here, the member variable MemLock (second field information) of the structure MallocMemInfo_T indicates whether initialization of the shared memory is complete, and the member variable MemReady (first field information) of the structure MallocMemInfo_T indicates whether it is locked or not. When MemLock is 0, it indicates that there is no system or task currently requesting memory, i.e., it is not locked. When MemLock is 0xA5A5A5A5, it indicates that there is a system or task requesting memory, and after the current request is completed, another system or task will need to request memory. When the variable MemReady is 0xA5A5A5A5, it indicates that initialization has already been completed, and memory can be dynamically requested or released normally.

[0202] In the memory sharing method provided by 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 mapping table to the occupied state. Optionally, when the operating system needs to occupy the target memory space, identify address information of multiple memory pages in the target memory space, and according to the correspondence between the memory pages and the records of the memory pages, update the records of the memory pages in the mapping table area of ​​the metadata storage area, and change them from an unoccupied state to an occupied state.

[0203] According to an alternative embodiment, a method for communication between operating systems is provided, the method comprising the following steps: Step 201: receiving a memory request command from a first operating system and locking a memory of a processor, the memory request command being used to request the use of the memory of the processor; In addition, to prevent multiple operating systems from simultaneously requesting the processor's memory space, resulting in a request failure, when the first operating system sends a memory request command, it requests a lock on the processor's memory, and as long as the lock request is successful, it can request the memory.

[0204] Optionally, determining whether the locking is successful is done by determining whether a predetermined variable stored in the memory is a predetermined value, and if the predetermined variable is not a predetermined parameter value, it indicates that there is no other system or task requesting the memory and the locking is successful; otherwise, it indicates that the predetermined variable is a predetermined parameter and at the current time, another system or task other than the operating system is requesting memory space and the locking fails.

[0205] Step 202: 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 equal to or greater than the memory size requested by the memory request instruction; Optionally, if the lock request is successful, based on the memory request command issued by the operating system, the information recording the occupied state of the memory is scanned to determine whether the target memory space exists, i.e., the processor determines whether there is a contiguous memory space in an unoccupied state. In an exemplary embodiment, it determines whether the size of the contiguous memory space in an unoccupied state is equal to or greater than the memory size requested by the operating system, and obtains a determination result.

[0206] Step 203: if the memory has the target memory space, feed back the address information of the target memory space to the first operating system, update the occupied status of the memory, and unlock the memory; Optionally, after the judgment result indicates that there is a target memory space for the operating system in the processor's memory space, the address information of the target contiguous space is sent to the operating system, and the operating system stores the data to be transmitted in the corresponding memory space based on the address information.

[0207] Optionally, update the occupied state of the processor's memory space based on the data writing status of the operating system, i.e., change the target memory space from an unoccupied state to an occupied state, and release the lock state before the dynamic request. Step 204: In response to a storage operation of the first operating system, store the target data in the target memory space, and send address information of the contiguous memory space to the second operating system; Optionally, after the memory request is successful, the first operating system stores the target data to be transmitted in the requested target memory space, and sends the address information of the target memory space to a second operating system cooperating with the first operating system, notifying the second operating system to obtain the data.

[0208] Step 205: receiving the acquisition command sent by the second operating system according to the address information, and sending the target data stored in the target memory space to the second operating system. Optionally, after the second operating system receives the address information of the target memory space, it sends a data acquisition command, and the embedded system receives the command and sends the target data stored in the target memory space to the second operating system.

[0209] Through the above steps, a memory request command from the first operating system is received and the memory of the processor is locked. 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, based on the occupied status of the memory, it is determined whether there is an idle target memory space in the memory. If the size of the target memory space is equal to or greater than the size of the memory requested by the memory request command and there is a target memory space in the memory, the address information of the target memory space is fed back to the sender of the memory request command, the occupied status of the memory is updated, and the memory is unlocked. In response to a store operation from 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 and sends the target data stored in the target memory space to the second operating system. This solves the problems of low utilization efficiency, low flexibility, and excessive dependency on the operating system of the shared memory between multiple cores, and achieves the effects of improving the flexibility and utilization efficiency of the shared memory and reducing dependency on the operating system.

[0210] In an exemplary embodiment, when a first operating system uses a physical address to read and write data and a second operating system uses a virtual address to read and write data, the second operating system converts the address information of the target memory space into a virtual address, and then accesses the memory through the virtual address and reads the target data from the target memory space.

[0211] In inter-core communication, when data is sent or received via shared memory, the address returned by the dynamically requested memory is used. However, different systems may use different address systems. For example, the real-time operating system may be the first operating system and the non-real-time operating system may be the second operating system. When accessing shared memory, the real-time operating system 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, maps it to a virtual address, and operates based on the virtual address. Optionally, vBase is the virtual base address of the shared memory under the non-real-time operating system (assuming the physical real address of the shared memory is 0x96000000), and pBase is the physical base address of the shared memory under the real-time operating system (i.e., 0x96000000).

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

[0213] In the real-time operating system, the address returned by the dynamically requested memory is the physical address pData, and in the real-time operating system, Offset=pData-pBase, and data is sent 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.

[0214] In an exemplary embodiment, the memory includes a metadata storage area and a data storage area, the data storage area being composed of a plurality of memory pages, each memory page being used to store service data, the metadata storage area storing a mapping table, the mapping table including a plurality of records, each record being used to record the occupied state of one memory page, and the step of reading the occupied state of the memory and determining whether the memory has idle target memory space based on the occupied state of the memory includes the steps of determining a predetermined number of memory pages requested by the memory request instruction, scanning each record in order from an initial position of the mapping table, and determining that the memory has the target memory space when scanning a consecutive predetermined number of target records, wherein the target record indicates that the memory page is idle.

[0215] Optionally, obtain a metadata storage area stored in the processor, and identify a mapping table in the metadata storage area; start from an index position in the mapping table, traverse the records of each memory page, query each memory page record in the mapping table in order, and determine whether there are a predetermined number or more of consecutive memory page records that record idle memory pages; if there are memory page records that satisfy the above condition, determine that the processor has the target memory space according to the correspondence between the memory page records and the memory pages.

[0216] In an exemplary embodiment, if the initial location is the last location in the 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 in 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.

[0217] Optionally, when scanning the mapping table, the scanning method can be to start scanning from the first position or the last position of the mapping table, and if the scanning method is to scan from the last position of the mapping table, record the start address of the corresponding memory page of the last scanned memory page, and set these memory pages to non-idle, and set the start address as the start address of the entire continuous memory page of the current memory request command. In an exemplary embodiment, the address is fed back to the operating system that issues the memory request command, and the operating system performs a data write operation to the memory based on the address information.

[0218] This embodiment further provides a memory sharing method, which includes the steps of: before an operating system issues a memory request command, determining whether a lock request is necessary to prevent multiple operating systems from simultaneously requesting processor memory space and causing contention, and determining whether the lock will be successful; if the determination result indicates that the dynamically requested memory is successfully locked, calculating the number of contiguous memory pages that need to be allocated based on the memory size in the issued memory request command, and marking the number of memory pages as nmemb; if the determination result indicates that the lock request fails, waiting for a certain time (100 microseconds), and then requesting again until the request is successful; and not requesting memory if the number of lock requests is a predetermined number (3 times) or more.

[0219] In an exemplary embodiment, after successfully requesting the lock, the processor's metadata storage area is initialized, the last position of the mapping table is denoted as offset, the number of contiguous memory pages required is calculated based on the size of the required memory space in the memory request instruction, the number of memory pages is denoted as nmemb, and a counter for recording the number of memory pages is located, denoted as cmemb. Next, obtain the mapping table of the metadata storage area in the processor, and start from the offset in the mapping table, scan the entire mapping table, record the correspondence between the memory pages stored in the mapping table and the memory pages in the data storage area, find consecutive idle memory pages, if the current scanned memory page is occupied, then offset=offset-cmemb, then clear the data cmemb of consecutive idle memory pages accumulated in the counter to 0, then find consecutive idle memory pages again from the new offset position, if the memory is idle, i.e., if it is in an idle state, add 1 to the counter value cmemb, and then offset=offset-1, continue to judge the next memory page until cmemb is equal to nmemb, i.e., if the data in the counter is equal to the size of the required memory space, it indicates that consecutive memory pages that meet the requirements have been scanned.

[0220] In an exemplary embodiment, the memory pages that satisfy the requirements are marked as occupied in the corresponding mapping table, the starting address of the last found memory page is set as the starting address of the entire dynamically requested contiguous memory pages, the dynamically requested memory is unlocked, and the current dynamic memory request is successful. In the process of scanning the entire mapping table, if the offset value is less than 0, it indicates that there is no memory page that satisfies the operating system's usage requirements, so the dynamically requested memory is unlocked and the current dynamic memory request fails.

[0221] Furthermore, if it is found that the space is not sufficient after dynamically requesting the space, the size can be dynamically adjusted, and optionally, an updated memory request command can be issued again to lock the memory. If the locking is successful, if the memory space requested by the updated memory request command becomes larger, it is determined whether there is sufficient memory space after the contiguous memory of the requested target. If so, the request is successful. If the memory space requested by the updated memory request command becomes smaller, part of the memory space is released.

[0222] In this embodiment, multiple storage areas are divided, and space is dynamically requested according to the required size using index positions, and the space is released after use. Furthermore, if it is found that the space is not sufficient after dynamically requesting the space, the size can be dynamically adjusted, ultimately achieving the effect of improving the flexibility and usage efficiency of the shared memory. In this embodiment, Figure 7 is a schematic diagram of the interaction process of service data according to an embodiment of the present application, as shown in Figure 7, the first operating system generates service data during the execution process and determines that the service is required by or needs to be sent to the second operating system, in this case, the first operating system stores the service data in its storage space and sends an eighth interrupt request to the second operating system, and the second operating system reads the service data from the storage space in response to the eighth interrupt request and performs subsequent processing.

[0223] The first operating system may have different execution mechanisms, including, but not limited to, controlling the first operating system to execute periodically based on the processor, or controlling the first operating system to execute based on the processor in response to a received wake-up request, or controlling the first operating system to execute based on the processor based on the compatibility between the operating service generated by the processor and the first operating system.

[0224] Optionally, in this embodiment, the execution mechanism of the first operating system may include, but is not limited to, periodic execution and triggered execution, where periodic execution is called a polling mode, and triggered execution is called a trigger mode, and may include, but is not limited to, a request-based trigger, where a wake-up request triggers the first operating system to wake up and run, and a condition-based trigger, where a compatibility between the operating service and the first operating system triggers the first operating system to wake up and run.

[0225] Optionally, in this embodiment, when the first operating system periodically executes, the length of one execution cycle and the length of the interval between two execution cycles may be the same or different. During the interval between two execution cycles, the first operating system may be in a sleep state, and the second operating system may use the processor core assigned to the first operating system, but this is not limited to this. When the length of one execution cycle and the length of the interval between two execution cycles are the same, the first operating system and the second operating system alternately occupy the processor core assigned to the first operating system for the same period. When the length of one execution cycle and the length of the interval between two execution cycles are different, the first operating system and the second operating system alternately occupy the processor core assigned to the first operating system for different periods. The length of time occupied by the first operating system may be longer than the length of time occupied by the second operating system, or the length of time occupied by the second operating system may be longer than the length of time occupied by the first operating system.

[0226] Based on different execution scenarios, different system functions may use different execution mechanisms to execute the first operating system, but are not limited to this, and may more flexibly find a more compatible execution mechanism than the current execution scenario and system function to execute the first operating system and improve the processing efficiency of the operating service.

[0227] In an alternative embodiment, a wake-up policy for a first operating system (e.g., an RTOS) in polling mode is provided. FIG. 8 is a schematic diagram 1 illustrating the execution process of a first operating system according to an embodiment of the present application. As shown in FIG. 8, the round-robin mode may be a polling scheduling mode based on time slices, which can periodically wake up and run the RTOS based on a predetermined time. In the execution process of a multi-system (taking a dual system of Linux and an RTOS as an example) in this mode, (T0, T1) = (Tn, T(n+1)), where n is a non-zero positive integer. That is, the dual systems alternately occupy CPU core 0 for the same period. In the (T0, T1) time slice, the RTOS schedules CPU core 0 to execute a process. In the (T1, T2) time slice, Linux schedules CPU core 0 to execute its process. During this time slice, the RTOS is in a sleep state, and in subsequent time slices, they similarly execute according to the periodic schedule.

[0228] Regarding the trigger-by-request method in the trigger mode, the wake-up request may be, but is not limited to, issued by a device connected to the first operating system, or may be, but is not limited to, issued by a second operating system. In an alternative embodiment, a wakeup policy for a first operating system (e.g., an RTOS) in trigger mode is provided, taking as an example a device triggering the wakeup and execution of a first operating system. FIG. 9 is a schematic diagram 2 of the execution process of a first operating system according to an embodiment of the present application. As shown in FIG. 9, the trigger mode may be initiated by an interrupt from a device in an RTOS bus domain. The RTOS bus domain is connected to devices 0 to N. When the RTOS is in a sleep state, assume that device 0 triggers an interrupt to the RTOS at a certain time. The RTOS is woken up. After waking up, the RTOS first triggers an interrupt to Linux to preempt CPU core 0. After receiving the interrupt, Linux first releases CPU core 0 and stores the current state (pushes data to be executed onto the stack). The RTOS system then schedules CPU core 0 to process the operating service indicated by the interrupt triggered by device 0. If the current mode is polling mode, the subsequent process is the same as that of the polling mode described above, and therefore will not be described here.

[0229] When the second operating system triggers the first operating system to wake up and run, if the second operating system currently occupies a processor core assigned to the first operating system, the second operating system releases the processor core, and after waking up, the first operating system can use the processor core to process operating services assigned to the second operating system.

[0230] In an alternative embodiment, the service executed in the first operating system may include, but is not limited to, a hardware interface signal generation service, and this embodiment provides a hardware interface signal generation process, which includes the following steps: Step 11: Obtain the request command by the first operating system.

[0231] In step 11, 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 may be a PECI request command based on the PECI protocol. Alternatively, 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-channel serial bus) signal, a GPIO (General-Purpose Input / Output) signal, or an SPI (Serial Peripheral Interface) signal. Therefore, 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. The present application does not particularly limit the selectable types of the request command and the hardware interface signal.

[0232] Step 12: Determine a plurality of logical bit information corresponding to the request command. In step 12, after the first operating system obtains the request command, it can analyze the logical bit information corresponding to the request command, and there is also an order among the plurality of logical bit information, and the first operating system can generate a waveform signal (i.e., a hardware interface signal) corresponding to the request command according to the plurality of logical bit information corresponding to the request command, and finally transmit the request command to other devices through the hardware interface signal.

[0233] Optionally, the request command includes at least one field, and each field may be represented by a logical bit 0 or 1. Therefore, the corresponding conversion relationship between each field and the logical bit 0 or 1 is logical bit information corresponding to the field. When the request command corresponds to multiple fields, the request command corresponds to multiple logical bit information. Note that each logical bit may be represented by a combination of a high-level signal and a low-level signal. For example, logical bit 0 may be represented by a combination of a high-level signal for a first predetermined time length and a low-level signal for a second predetermined time length, and logical bit 1 may be represented by a combination of a high-level signal for a second predetermined time length and a low-level signal for the first predetermined time length, where the first predetermined time length and the second predetermined time length are different. Therefore, since each logical bit includes both a high-level signal and a low-level signal, each logical bit is actually represented by a waveform signal (the conversion between a high-level signal and a low-level signal is displayed as a waveform), and since a request command corresponds to multiple logical bit information, i.e., multiple logical bits, 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.

[0234] Step 13: generating a hardware interface signal corresponding to the request command according to the plurality of logical bit information and the timer. Alternatively, the timer in step 13 may be a timing program of the first operating system, or may be a register in 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 a request command.

[0235] It should be noted that, for example, if the chip is a BMC chip and the hardware interface signal is a PECI signal, in order to realize PECI communication between the BMC chip and a device such as a CPU, the BMC chip itself must have a hardware logic design of a PECI controller, which causes a problem of high BMC chip design costs. That is, in the related art, in order to generate a PECI signal in the BMC chip, the hardware logic design of the PECI controller must be realized in advance in the BMC chip. In the present application, only a first operating system is required to generate a PECI signal in the BMC chip, and there is no need to realize a hardware logic design of a PECI controller in the BMC chip, which reduces the difficulty and cost of designing the BMC chip.

[0236] As can be seen from the contents of steps 11 to 13, this embodiment uses a method of generating a hardware interface signal corresponding to a request command by the first operating system, which first obtains the request command by the first operating system, 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 based on the plurality of logical bit information and a timer.

[0237] As can be seen from the above, in this embodiment, the first operating system generates hardware interface signals corresponding to the request commands, and achieves the technical effect of simulating and generating hardware interface signals using a software method. Furthermore, the chip itself achieves the purpose of not having hardware logic design for the relevant hardware interface signals, which not only reduces the difficulty of chip design but also reduces chip design costs.

[0238] Therefore, this embodiment achieves the objective of using a software system to generate hardware interface signals, without needing to implement the hardware logic design of the hardware interface signals on the chip, thereby reducing the difficulty of chip design, and further solves the technical problem that in related technologies, the chip itself needs to have the hardware logic design of the controller, resulting in high chip design costs.

[0239] Optionally, when the first operating system detects a first request triggered by the second operating system, the first operating system obtains 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 response speed of the service of the second operating system is slower than that of the service of the first operating system, and finally, the first operating system analyzes the request data and obtains the request command.

[0240] Optionally, before obtaining the requested data, the second operating system can store the requested data in a target memory (i.e., a storage space in the processor), and after the storage of the requested data is completed, the second operating system triggers 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 that can be accessed by both the first operating system and the second operating system.

[0241] 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 further adjusts the data structure of the response data to a second data structure. 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.

[0242] 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 process, first, in the Linux system, upper-level applications related to PECI services (such as fault diagnosis and CPU temperature acquisition) selectively issue PECI request commands. These request commands include, but are not limited to, the basic Ping() command, the CPU temperature acquisition command, and the MSR register (Machine Specific Register) information acquisition command. The code realization of different PECI request commands is completed by the corresponding interface functions.

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

[0244] It should be noted that in the process of storing the request data in the target memory by the second operating system, 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, an instruction code and request parameters, wherein the device address is used to indicate the address of the target device, the target device is a device for generating response data based on a hardware interface signal, the instruction code is used to distinguish different request commands, the write length is used to indicate the number of bytes from the start of the instruction code to the end of the request data, the read length is used to indicate the number of bytes in the request data including the completion code and the read data, and the request parameters are used to indicate parameters of the request command.

[0245] During the instruction response process, the RTOS system receives the response data transmitted via the PECI path and then analyzes the data to convert the response data signal format from the hardware interface signal format to the software signal format. For example, it identifies waveform changes between high and low levels of the hardware interface signal, obtains corresponding logic bit information, and then obtains software signal data based on the logic bit information. The parsed response data is adjusted using the instruction parameter structuring module and written to the target memory. After all of the parsed response data has been written, the RTOS system triggers a second request to notify the Linux system. Linux detects the second request, actively reads the parsed response data stored in the target memory, processes the data, and returns it to the upper application. Here, the second request may be an SGI interrupt request.

[0246] In addition to the shared memory, the target memory may be other memories such as a random access memory (abbreviated as RAM) or a flash memory. In an alternative embodiment, after generating a hardware interface signal corresponding to the request command based on the logical 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.

[0247] Optionally, the first operating system can input a hardware interface signal to the voltage conversion device and obtain a target hardware interface signal output from the voltage conversion device. Optionally, the voltage conversion device may be a CPLD, and the CPLD may be connected to a target device, and the target device may be a CPU in a server.

[0248] It should be noted that the above services are not only applicable to replacing the PECI interface and generating PECI signals, but also applicable to other hardware interfaces. As can be seen from the above, the first and second operating systems are combined to realize data interaction in the embedded system through inter-core interrupts and memory sharing. A request command waveform generation functional module is built into the RTOS system, and hardware interface signal communication between the embedded system and external devices is realized through software simulation. By fully utilizing the high real-time capabilities of the RTOS system, timing accuracy during request command waveform simulation is ensured, resulting in flexibility and high efficiency. This significantly reduces the difficulty of chip design, and using software simulation to generate hardware interface signals provides more opportunities for optimizing the design between communication functions and other service functions in the embedded system. At the same time, the elimination of a specially configured on-chip controller for hardware interface signal communication reduces chip design and manufacturing costs.

[0249] In an alternative embodiment, the service running in the first operating system may include, but is not limited to, a serial port switching service, and this embodiment provides a serial port switching process, which includes the following steps: Step 21: if the second operating system detects that it receives a serial port switching command, the second operating system sends the serial port switching command to the first operating system.

[0250] Optionally, when a user initiates serial port switching, the second operating system can detect whether a user-initiated serial port switching command is received, where the serial port switching command includes information about a target serial port to be switched to, for example, the serial port number of the target serial port to be switched to.

[0251] In the example available, the format of the serial port switching command is:<switch_command_app-n number-t sleep_time> where switch_command_app indicates the switch command program, -n indicates the switched target serial port number, the value of number may be 1, 2, or 3, -t indicates how long to sleep after the command is started to perform the switch operation, and the unit of sleep_time is seconds.

[0252] When switching serial ports, the serial ports that can currently be switched can be assigned numbers, so that when switching serial ports later, the target serial port can be switched by the serial port number. In an alternative embodiment, currently, serial ports that can be switched include BMC Linux system serial ports, server BIOS (Basic Input Output System) serial ports, and SMART NIC (network interface controller) serial ports, and accordingly, 1 indicates the BMC Linux system serial port, 2 indicates the server BIOS serial port, and 3 indicates the SMART NIC serial port.

[0253] Step 22: The first operating system switches the serial port according to the serial port switching command. Optionally, when the second operating system detects that it receives a serial port switching command, the second operating system immediately sends a serial port switching command to the first operating system. Note that the first operating system and the second operating system can each run on two processor cores, and the first operating system and the second operating system use inter-core communication, which helps improve the reliability of signal transmission.

[0254] Furthermore, the command response speed of the first operating system is much faster than that of the second operating system, so that the first operating system can respond quickly to serial port switching commands and complete the switching process in a very short time. In short, instead of using a CPLD or FPGA, the first operating system and the second operating system are executed on the same processor to realize the serial port switching software function. When the second operating system receives a serial port switching command, the second operating system sends the serial port switching command to the first operating system, and the first operating system switches the serial port according to the serial port switching command. This avoids the need in the related art to connect each serial port using a CPLD or FPGA and then use a switch structure in the CPLD or FPGA to switch the serial port, thereby reducing hardware costs. After receiving the serial port switching command, the first operating system can quickly complete the serial port switching in a very short time. Therefore, the technical solution provided by this means can effectively reduce the serial port switching cost and effectively improve the serial port switching efficiency.

[0255] In order to realize serial port switching by the second operating system, in the serial port switching process provided by this embodiment, 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 process includes the steps of: obtaining, by the first operating system, an analysis rule for the serial port switching command from the target storage device; and analyzing, based on the analysis rule, the serial port number of the target serial port in the serial port switching command, and determining a device corresponding to the serial port number, where the target serial port is a serial port of the device, and the target serial port is connected to the chip.

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

[0257] In order for the first operating system to quickly realize the serial port switching, the first operating system can analyze the serial port switching 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 various chips or server motherboards, and the analysis rules can be stored in a target storage device. The target storage device can be a storage medium such as an electrically erasable programmable read-only memory (EEPROM) or a non-volatile memory (flash). The target storage device may or may not be located within the chip. Storing the analysis rules in the target storage device improves data security, and customizing the analysis rules according to various chips and server motherboards provides excellent programmability and scalability.

[0258] 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 storage device, 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. After obtaining the device corresponding to the serial port, the first operating system can map the target serial port to the target output interface of the chip according to the address of the serial port of the device, and after mapping the address of the serial port of the device to the target output interface, the device can be accessed through the target output interface.

[0259] The serial port switching command and analysis rules can be set according to the type of chip used and the types of the first and second operating systems. In the serial port switching method provided by Example 1 of the present application, the chip includes a serial data bus, and before determining the address of the serial port of the device by the first operating system, the method further includes the steps of determining a plurality of devices connected to the serial ports of the serial data bus, and mapping the serial port of each device in the memory of the chip through the serial data bus, and obtaining the address of the serial port of each device.

[0260] Optionally, the chip further includes a serial data bus, and the TX and RX of the serial ports of multiple devices are connected to the serial data bus. 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). UART (Universal Asynchronous Receiver / Transmitter) refers to a universal asynchronous receiver / transmitter. The serial data bus can map the TX and RX data of different serial ports, UART1, UART2, and UART3, into different address spaces in the BMC memory. That is, the serial data bus maps the serial ports of each device within 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.

[0261] When the user issues a serial port switching command, the first operating system (RTOS) selects three different memory segments (select one from the three) mapped by the UART, and interacts with the client using the data in one memory segment, thereby achieving the purpose of simulating the CPLD hardware serial port switching circuit. Furthermore, if it is not possible to distinguish between the serial ports of different devices, developers will not be able to accurately identify which device's serial port has a problem during maintenance, and will therefore need to identify the location of the abnormality by switching between serial ports.

[0262] In this embodiment, after mapping the target serial port to the target output interface of the chip according to the address of the serial port, if the target output interface can be connected to the target intelligent network card, the following steps are included: detecting whether an access request to the target serial port is received by the intelligent network card; and if an access request to the target serial port is received, forwarding the access request to the target serial port by the intelligent network card.

[0263] Optionally, the target output interface of the chip can be connected to a target intelligent network card, and then the intelligent network card can detect whether a user receives a request to access the target serial port, and if a request to access the target serial port is received, the target intelligent network card can directly realize access to the serial port of the device, and realize the SOL (Serial over LAN, Specification of Data Packet Format and Protocol) function.The above steps improve the efficiency of accessing the serial port of the device.

[0264] In an optional embodiment, after mapping the target serial port to the target output interface of the chip based on the address of the serial port, the method further includes obtaining an execution result of the serial port switching command by the first operating system, the execution result being one of successful or unsuccessful switching, and sending the execution result to the second operating system by the first operating system.

[0265] The second operating system receives an execution result of the serial port switching command, and the execution result is sent by the first operating system to the second operating system, and the execution result is one of successful serial port switching and unsuccessful serial port switching. After switching the serial port, the first operating system 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, and notifies the second operating system that the serial port switching is successful or unsuccessful.

[0266] 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 serial port switching exceeds a predetermined number. If the number of serial port switching exceeds the predetermined number, triggering a prompt signal by the second operating system, the prompt signal is used to prompt the user that the serial port switching has failed.

[0267] If the execution result of the serial port switching command is unsuccessful, 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 successful or the number of serial port switching times exceeds a predetermined number, which may be 3 times. If the number of serial port switching times exceeds the predetermined number, a prompt will be issued that the serial port switching has failed, and in order to handle this situation in a timely manner, the corresponding second operating system will trigger a prompt signal.

[0268] Before detecting that the first operating system receives a serial port switching command, the method further includes the steps of: after the second operating system is started, the second processor core triggering a first interrupt and sending a first signal to the first operating system; detecting the running status of multiple serial ports in the chip based on the first signal by the first operating system and obtaining a detection result; triggering a second interrupt by the first processor core and sending the detection result to the second operating system by a second signal; and receiving the detection result by the second operating system to determine the number of serial ports in the chip that run normally.

[0269] The second processor core triggers a first interrupt and sends a first signal to the first operating system, and then detects whether the first operating system receives the first signal; if the first operating system receives the first signal, detects the running status of multiple serial ports on the chip through the first operating system, and obtains a detection result.

[0270] After the second operating system starts up, 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 knows from the first signal that the second operating system has started up successfully and can interact with the second operating system normally. The first operating system then detects the running status of multiple serial ports on the chip based on the first signal and determines whether all serial ports are running normally.

[0271] After the first operating system detects 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. The second operating system determines the number of switchable serial ports (i.e., the number of serial ports that run normally) according to the detection result, and then performs serial port switching for those serial ports. At the same time, in order to enable the first operating system to switch serial ports more quickly, after the first operating system completes the detection, the first operating system begins to block and waits for a serial port switching command sent by the second operating system.

[0272] 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 switching the serial port includes the following steps: when the Linux system running on CPU1 starts up to a certain stage, CPU1 triggers an IPI interrupt to notify the RTOS system on CPU0 that Linux has started up successfully and can interact with Linux on CPU1 successfully; after receiving the IPI interrupt from CPU1, the RTOS system starts 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 started up; at the same time, the reported information includes the number of switchable serial ports in the RTOS operating system on CPU0; then the RTOS operating system on CPU0 starts to block and waits to receive a switching command from the operating system on CPU1.

[0273] When the second operating system is running and an abnormal situation occurs, the server terminal issues a serial port command to the first operating system, and the first operating system switches the serial port according to the serial port switching command. Since the second operating system has many functions and is responsible for a large number of services, it may run abnormally or require a reboot. When the second operating system runs abnormally, the server terminal can directly issue a serial port switching command to the first operating system to ensure that the first operating system can switch the serial port normally. The server terminal may be a terminal in the server where the chip is located.

[0274] The above steps ensure that the first operating system can switch the serial port without relying on the second operating system, and improve the independence of the first operating system in switching the serial port. In summary, in the serial port switching process provided by this embodiment, instead of using a CPLD or FPGA, the first operating system and the second operating system are executed on the same processor to implement the serial port switching software function. When the second operating system receives a serial port switching command, the second operating system sends the serial port switching command to the first operating system. The first operating system then switches the serial port according to the serial port switching command, thereby avoiding the need to implement serial port switching through hardware and reducing hardware costs. After receiving the serial port switching command, the first operating system can quickly complete the serial port switching in a very short time. Therefore, the above process effectively reduces the serial port switching cost and effectively improves the serial port switching efficiency.

[0275] For triggering by a condition in the trigger mode, the compatibility between the current operating service and the first operating system may indicate, but is not limited to, whether the operating service generated by the processor is suitable for processing by the first operating system; by allocating an appropriate operating service to the first operating system, rational allocation of operating services is realized, and further, the processing efficiency of the operating service is improved.

[0276] In this embodiment, the execution of the first operating system based on the processor can be controlled in the following ways, but is not limited to these: detecting service information of the current operating service generated by the processor, and if it is detected that the compatibility between the service information and the first operating system is higher than a compatibility threshold, controlling the first operating system to execute the current operating service based on the processor.

[0277] Optionally, in this embodiment, the compatibility between the operating service and the first operating system may be represented by, but is not limited to, the compatibility between the service information of the operating service and the first operating system, and the service information may include, but is not limited to, any dimension having processing requirements, such as the response speed of the service, the resource occupancy rate of the service, the coupling degree of the service, and the importance of the service.

[0278] Optionally, in this embodiment, if the compatibility between the service information and the first operating system is higher than a compatibility threshold, it indicates that the operating service is suitable for running on the first operating system. The compatibility threshold may be, but is not limited to, dynamically adjustable based on the current resource usage or running requirements of the first operating system. Therefore, the adaptability and flexibility of the first operating system is increased.

[0279] In this embodiment, the service information of the current operating service generated by the processor may be detected by, but is not limited to, the following methods: detecting a target response speed and / or a target resource occupancy of the current operating service; the service information includes a target response speed and / or a resource occupancy, where the target response speed is the response speed required by the current operating service from the processor, and the target resource occupancy is the amount of resources required by the current operating service from the processor; and if the target response speed is below a speed threshold and / or the target resource occupancy is below an occupancy threshold, determining that the compatibility between the service information and the first operating system is higher than the compatibility threshold.

[0280] Optionally, in this embodiment, the service information may include, but is not limited to, a target response speed and / or a resource occupancy. The target response speed is the response speed required by the current operating service from the processor, and the target resource occupancy is the amount of resources required by the current operating service from the processor. The requirements of the current operating service regarding the processor's response speed may be considered separately, or the requirements of the current operating service regarding the processor's available resources may be considered separately. Furthermore, the current operating service may be allocated by taking both into consideration comprehensively.

[0281] In alternative embodiments, each operating system may be allocated operating services and processing resources in the following manner, but not limited to: According to a dynamic resource allocation rule, a set of allocation target services are allocated to corresponding operating systems in an embedded system, and the dynamic resource allocation rule can dynamically allocate resources based on at least one of, but not limited to, a response speed of the service, a resource occupancy rate of the service, a coupling degree of the service, and an importance of the service, and the embedded system includes a first operating system and a second operating system, the first operating system and the second operating system run on a processor, and the response speed of the first operating system is higher than that of the second operating system.

[0282] determining a resource allocation result corresponding to the set of allocated services, the resource allocation result being used to indicate a processing resource corresponding to each allocated service among the set of allocated services among the processing resources of the processor, the processing resources of the processor including a processor core; The processing resources of the processor are allocated to the first operating system and the second operating system based on the results of allocation of the operating systems and resources corresponding to each of the allocation target services.

[0283] During the execution process of the processor, a set of target services to be allocated, i.e., services to be allocated to the first operating system and the second operating system, can be obtained. Because each target service may have different dimensions, such as response speed, resource occupancy rate, coupling rate with other services, and importance, a dynamic resource allocation rule can be pre-configured. The dynamic resource allocation rule may include rules for allocating services to the corresponding operating system to execute the assigned services using the processing resources of the corresponding operating system. Optionally, to dynamically allocate resources, the dynamic resource allocation rule may include at least one of the response speed, resource occupancy rate, coupling rate, and importance of the service. Different allocation rules may have corresponding priorities. For example, the priorities are, in descending order, service importance, coupling rate, response speed, and resource occupancy rate. According to the dynamic resource allocation rule, a set of target services to be allocated (or target services; different target services may correspond to different processes) can be allocated to the corresponding operating system in the embedded system, and a service allocation result can be obtained.

[0284] Alternatively, the first operating system may be an operating system with a clear time constraint based on response time constraints, requiring all processing steps (task scheduling) to be completed within a certain time frame or the system will fail. It may be a real-time operating system (RTOS) such as FreeRTOS or RTLinux, or another real-time operating system for embedded systems. The second operating system does not have this characteristic. It generally uses a fair task scheduling algorithm, and as the number of threads / processes increases, CPU time must be shared, making task debugging uncertain. Therefore, it can be considered a non-real-time operating system, such as Contiki, HeliOS, or Linux (full name GNU / Linux, a freely distributable Unix-based operating system). It may also be a non-real-time operating system for embedded systems. The Linux system is a multi-user, multi-tasking, multi-threaded, and multi-CPU operating system based on the Portable Operating System Interface (POSIX).

[0285] Accordingly, the services assigned to the first operating system are typically real-time services, which refer to services that must be scheduled within a certain time frame and require the processor to process them at a sufficiently fast speed so that the processing results can control the production process or respond quickly to the processing system within a certain time frame. A typical scenario is controlling a robot arm in industrial control, which is a real-time service, and the system must take timely action before detecting a malfunction 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 affected by scheduling time and have a certain tolerance for scheduling delays, such as reading sensor data from a temperature sensor from a server.

[0286] A real-time operating system refers to an operating system that can accept and process external events and data at a sufficiently fast speed when they are generated, control the production process within a certain time, or quickly respond to the processing system with the processing results, schedule all available resources to complete real-time services, and control all real-time services to be executed in a coordinated manner, and has characteristics such as timely response and high reliability.

[0287] After each allocation target service is allocated to a corresponding operating system, processing resources corresponding to each allocation target service can be allocated based on the service allocation result, and a resource allocation result corresponding to one set of allocation target services can be obtained. When allocating processing resources to allocation target services, the processing resources of the first operating system can be allocated to the service allocated to the first operating system, and the processing resources of the second operating system can be allocated to the service allocated to the second operating system. At the same time, in consideration of load balancing, if there are unallocated processing resources, the unallocated processing resources can be allocated to some services.

[0288] The processing resources of the processor can be dynamically allocated in units of time slices, and since 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 may result in an extended 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. That is, the processor cores of the processor are allocated to the corresponding operating systems in whole processor core units, the number of processor cores allocated by each operating system is an integer, and the processor cores allocated by different operating systems are different from each other.

[0289] The processing resources of the processor can be allocated to the first operating system and the second operating system based on the allocation results of the operating systems and resources corresponding to each allocation target service. Optionally, unallocated processing resources of the processor can be allocated to the corresponding operating systems, and the unallocated processing resources can be determined based on the correspondence between the unallocated processing resources and the allocation target services and the correspondence between the allocation target services and the operating systems.

[0290] Optionally, allocating the processing resources of the processor to the first operating system and the second operating system may be performed by a resource auto-adaptation scheduling module (e.g., a core auto-adaptation scheduling module). The resource auto-adaptation scheduling module may be a software module executed in the first operating system or the second operating system. Taking the software module executed in the second operating system as an example, the resource auto-adaptation scheduling module may be realized by software of a Linux system, and may complete an actual scheduling operation for the processing resources of the processor (e.g., the hard core resources of the processor) based on the output of the service management module and the output of the resource dynamic allocation module. For example, after the resources are scheduled by the core resource auto-adaptation 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.

[0291] For example, different operating systems (heterogeneous operating systems) can be run on different cores of the same processor, so that the entire processor system has parallel processing capabilities for real-time services and non-real-time services, and at the same time, the processor's hard core resources (such as processor cores) occupied by different operating systems can be automatically and adaptively adjusted, thereby significantly improving the utilization of processor resources.In this specification, "heterogeneous" refers to different types of operating systems running on the same multi-core processor of an embedded system, and "multi-system" refers to multiple operating systems running on the same multi-core processor of an embedded system, with these operating systems running simultaneously in the time dimension.

[0292] Optionally, the above process generates a rule structure by reading a rule configuration file, and the rule structure is used to record the resource dynamic allocation rules. The dynamic resource allocation rules may be configured based on a rule configuration file, and a rule structure for recording the dynamic resource allocation rules can be generated through the read rule configuration file. The rule configuration file may be a load balancing policy file (payload_balance.config), which can be used to configure the classification method of various running services (or processes), the real-time level evaluation principle, etc. In the load balancing policy file, different parameters can be used to configure the dynamic resource allocation rules. An example of a load balancing policy configuration file is as follows:

[0293] classification kinds =2 / / If the value is 1, it indicates that processes are classified according to attributes such as criticality and non-criticality, otherwise it indicates that processes are classified according to a predetermined classification method (e.g., real-time and non-real-time), real-time grade evaluation=2 / / If the value is 1, it indicates that the average CPU occupancy rate in the past statistic minutes is used as the evaluation principle for the real-time level of the process; otherwise, it indicates that the given priority is used as the evaluation principle for the real-time level of the process. statistic minutes =5 / / indicates the statistical time (unit: minute) of the average occupancy rate of each process, and is valid when real-time grade evaluation is 1.

[0294] Optionally, the dynamic resource allocation rules can be stored in a load balancing policy module. In this specification, the load balancing policy module 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 policy guidance to the service management module, including a classification method for various services (or processes) running on the system, a real-time level evaluation principle, etc. The service management module can divide and manage services in the system according to their real-time levels, and can optionally guide the resource auto-adaptive scheduling module to reallocate processor resources. Illustratively, an actual classification of services can be performed based on the output of the load balancing policy module, and a list including real-time services and non-real-time services can be generated.

[0295] The above classification method and real-time level evaluation principles are open, allowing users to define their own specific methods or principles. The service management module can dynamically configure rules for service management, allowing selectable rules to be configured based on existing rules. The service management module can configure multiple rules with the same function, but without conflict between the rules. That is, the currently used rule with the same effect can be determined 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, describes possible situations. In the configuration file, the classification_kinds variable indicates selectable classification criteria (e.g., service importance or real-time) and classification categories (e.g., critical services vs. general services, real-time services vs. non-real-time services, etc.). The real-time_grade_evaluation variable indicates the evaluation criteria for real-timeness (e.g., the average CPU occupancy rate within the past statistic_minutes or a predetermined service priority). The real-time level type can be defined by the user and can be defined as high, standard, or low, or can be further subdivided.

[0296] The output of the load balancing policy module is the configured classification method, real-time level evaluation principle, etc., and when implemented by software, it may be a selectable configuration file (e.g., load_balance.config file) or a structure variable, which can finally be accessed by the service management module to obtain a selectable policy for load balancing.

[0297] According to this embodiment, in order to record the dynamic resource allocation rules, a rule structure is generated by reading the rule configuration file, thereby improving the convenience of information configuration. Optionally, the above process includes the steps of obtaining a rule update configuration file via an external interface of the second operating system, where the rule update configuration file is used to update the configured resource dynamic allocation rules, and updating the rule update configuration using the rule update configuration file to update the resource dynamic allocation rules recorded in the rule update configuration.

[0298] The rule structure may be in a fixed format, i.e., one that cannot be changed during runtime of the embedded system, or in a flexibly configurable format, i.e., one whose configuration can be changed by a configuration file in a specific format. In this embodiment, a rule update configuration file can be obtained, and the rule update configuration file can be used to update the configured dynamic resource allocation rules, and the rule update configuration can be updated using the rule update configuration file to update the dynamic resource allocation rules recorded in the rule update configuration.

[0299] When updating a rule structure using a rule update configuration file, a new rule structure can be directly generated based on the rule update configuration file and the existing rule structure can be replaced with the newly generated rule structure, and the parameter values ​​of the rule parameters indicated in the rule update configuration file can also be used to update the parameter values ​​of the corresponding rule parameters in the rule structure.

[0300] Alternatively, the configuration file in a specific format may be read by the external interfaces of the first and second operating systems, and considering the amount of services to be processed, the second operating system may be primarily responsible for dynamic resource scheduling of the embedded system. When obtaining the rule update configuration file, the rule update configuration file may be obtained through the external interface of the second operating system.

[0301] For example, the load balancing policy module may be in a fixed format or may be configured through an external interface of the Linux system. For example, a file (load_balance.config) of the aforementioned specific format may be defined, and the configuration may be changed by reading and writing the file. The external interface is 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, etc., and only needs to acquire data from the outside. The hardware used to read the file and the file location can be implemented in different ways. For example, the configuration file can be loaded from a World Wide Web (WEB) interface via a network interface, the configuration file can be read from the board's SPI Flash (flash memory) via an SPI controller, or the configuration file can be acquired from a serial port data transmission / reception software tool on another personal computer (PC) via a UART serial port.

[0302] According to this embodiment, the rule update configuration file is obtained and used to update the rule structure, thereby improving the flexibility of the structure of the dynamic resource allocation rules. Alternatively, the set of allocated services can be allocated to corresponding operating systems in the embedded system based on the resource dynamic allocation rule in the following manner, but not limited to, the services among the set of allocated services whose response speed is higher than a predetermined response speed threshold are allocated to the first operating system, and the services among the set of allocated services whose response speed is lower than a predetermined response speed threshold are allocated to the second operating system.

[0303] When allocating the target services, the target services can be allocated to corresponding operating systems based on the response speed requirements of the target services. The response speed of the service can be used to evaluate the real-time level of the service. The higher the requirement for the response speed of the service, the greater the impact on the scheduling time and response speed of the operating system, and the higher the real-time level. Services with high response speed requirements need to be processed by the operating system at a sufficiently fast speed, and their processing results can control the production process within a certain time or respond quickly to the processing system. Services that do not require high service response speed have a certain tolerance for scheduling delays.

[0304] An assignment target service whose response speed requirement is equal to or greater than a predetermined response speed threshold is affected by the scheduling time and response speed of the operating system, and therefore can be assigned to a first operating system (e.g., assigning a real-time service to a real-time operating system). An assignment target service whose response speed requirement is less than a predetermined response speed threshold is not affected by the scheduling time and response speed, and therefore can be assigned to a second operating system (e.g., assigning a non-real-time service to a non-real-time operating system). In this specification, the response speed requirement of a service can be indicated by an indication parameter of the response speed of the service, and the predetermined response speed threshold may be a millisecond-level response speed threshold such as 100 milliseconds or 200 milliseconds, or a second-level response speed threshold such as 1 second, and this embodiment does not limit the predetermined response speed threshold.

[0305] Optionally, when allocating a set of allocation target services to corresponding operating systems in the embedded system, a first service list corresponding to the first operating system and a second service list corresponding to the second operating system can be output, where the first service list is used to record the services allocated to the first operating system and the second service list is used to record the services 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 are used to perform a dynamic scheduling process of processor processing resources.

[0306] For example, suppose the real-time level of the system's services is divided, a list of real-time services and non-real-time services is obtained, and there are a total of 20 services, among which the real-time services are Service 1 and Service 2, and the non-real-time services are Service 3 to Service 20. In this specification, the service management module can classify currently executed services. When the BMC system is run for the first time, all services currently executed by the system are recognized by the system, and the service management module classifies these services once based on the output of the load balancing module. After classification, different services are assigned to different operating systems (RTOS system and Linux system) and executed. During subsequent execution, if the number of processes for a service changes (for example, if a process is paused or frozen, or a new process is launched), the service management module can further continue to divide the services and divide and manage existing services in real time according to the load balancing policy. The service management module may be a resident process in the Linux system, always running, and manages and divides currently executing processes.

[0307] According to this embodiment, by allocating allocation target services to corresponding operating systems in accordance with the response speed requirements of the services, it is possible to ensure a rapid response to services that are affected by the scheduling time. Alternatively, the set of allocated services may be allocated to corresponding operating systems in the embedded system based on the resource dynamic allocation rule in the following manner, but not limited to, allocating the allocated services of the set of allocated services whose resource occupancy rate is less than a first occupancy rate threshold to a first operating system, and allocating the allocated services of the set of allocated services whose resource occupancy rate is equal to or greater than the first occupancy rate threshold to a second operating system.

[0308] When allocating a target service, the target service can be allocated to a corresponding operating system based on the resource occupancy of the target service. The resource occupancy of a service can be the average proportion of the service to the processing resources per unit time (for example, the CPU occupancy per minute). The level of the resource occupancy of a service affects the response speed of this service and the response speed of subsequent services, so the real-time level of the service can be evaluated based on the resource occupancy of the service. The higher the resource occupancy of a service, the greater the impact on the scheduling time and response speed of the operating system, resulting in a lower real-time level. A service with a low resource occupancy of a service has little impact on the scheduling time and response speed of the operating system, resulting in a higher real-time level.

[0309] An assigned service whose resource occupancy rate is less than a first occupancy rate threshold has a small impact on the scheduling time and response speed of the operating system, and can be assigned to a first operating system. An assigned service whose resource occupancy rate is equal to or greater than the first occupancy rate threshold has a large impact on the scheduling time and response speed of the operating system, and can be assigned to a second operating system. In this specification, the first occupancy rate can be selectively set and can be 10%, 15%, 20%, or other threshold, and the first occupancy rate threshold can be dynamically adjusted.

[0310] According to this embodiment, by allocating allocation target services to corresponding operating systems in accordance with the resource occupancy rate of the service, it is possible to ensure a quick response to services with low resource occupancy rates. Optionally, the set of allocated services may be allocated to corresponding operating systems in the embedded system according to the resource dynamic allocation rule by at least one of the following ways, but not limited to:

[0311] assigning to the first operating system, among the set of assignment target services, those assignment target services whose degree of coupling with the assigned services of the first operating system is equal to or greater than a first coupling threshold; Among the set of services to be assigned, those services to be assigned whose degree of coupling with the already assigned services of the second operating system is equal to or greater than a second coupling threshold are assigned to the second operating system.

[0312] When allocating the target service, the target service can be allocated to a corresponding operating system based on the coupling degree of the target service. The coupling degree of a service can be used to indicate the degree of association between the target service and the assigned services in each operating system. If a target service has a high coupling degree with an assigned service in one operating system, it is not appropriate to allocate it to another operating system. Therefore, the target service can be allocated to a corresponding operating system based on the coupling degree between the target service and the assigned services in each operating system.

[0313] Alternatively, the coupling level of a service can be evaluated based on the relationship between the input and output of the service. The coupling level of a service can be indicated by different coupling levels. When there is no relationship between the input and output of a service, the coupling level is low (or another coupling level indicating no relationship between the services). When the execution of a service depends on the output of another application (the service cannot start without that output as input), the coupling level between the services is high. When the execution of a service uses the output of another application, but the output does not interfere with the normal execution of the service (the service only needs to obtain the output when executing the corresponding operation, and the corresponding operation is not a core operation), the coupling level between the services is medium. Note that the coupling level of a service can also be indicated by a numerical value. The coupling level of a service can be evaluated based on one or more coupling conditions (e.g., the relationship between input and output), and the numerical value corresponding to the satisfied coupling condition can be determined as the coupling value of the service.

[0314] If a set of services to be assigned includes a service whose degree of coupling with an already assigned service of a first operating system is equal to or greater than a first coupling threshold, such a service to be assigned can be assigned to the first operating system, and if a set of services to be assigned includes a service whose degree of coupling with an already assigned service of a second operating system is equal to or greater than a first coupling threshold, such a service to be assigned can be assigned to the second operating system.

[0315] For example, in addition to generating a real-time service list and a non-real-time service list, the service management module is also responsible for separating and evaluating and managing services, i.e., finding out services that can be executed independently by the real-time operating system from all real-time services so that the hardware resource dynamic allocation module can reallocate processor resources; and for services that cannot be executed independently by the real-time operating system, if they have a high degree of coupling with non-real-time services, they can be allocated to the non-real-time operating system.

[0316] In this specification, some services require real-time performance but frequently interact with other non-real-time services in the system (i.e., the service is highly coupled). In this case, such services are assigned to a non-real-time operating system to improve the overall efficiency of data interaction. Another type of real-time service is relatively independent itself. In this case, it is only necessary to separate it into a real-time operating system, and this process is called "separation" operation. The criterion for judging the independence of services is not limited to one, and may be the closeness of the relationship between the above services or an indicator of other users' concerns.

[0317] The reallocation policy is open, and one possible policy is as follows: when the system is first run, the service management module allocates processor cores based on the ratio of the number of services allocated to the real-time operating system and the non-real-time operating system; during subsequent run times, the resource allocation is adjusted based on the core resource occupancy of each of the dual systems; from this perspective, the reallocation process and the core preemption and release process are mutually cooperative processes.

[0318] According to this embodiment, by allocating allocation target services to corresponding operating systems in accordance with the degree of coupling of the services, it is possible to ensure the accuracy of processing for a plurality of services with high degrees of coupling. Optionally, a set of allocated services can be allocated to corresponding operating systems in the embedded system based on the resource dynamic allocation rule in the following manners, but not limited to:

[0319] The assigned service including the confidential information among the set of assigned services is assigned to a target operating system, and the target operating system is an operating system that interacts less frequently with the user among the first operating system and the second operating system. In this embodiment, an assigned service (which may be an important and confidential service, for example, a service that should not be disclosed to users) containing confidential data (e.g., confidential information such as a password) may be assigned to a target operating system, and the target operating system may provide hardcore security protection isolation for the assigned service containing confidential information. In this specification, the target operating system is an operating system that has a low interaction frequency with the user, among the first operating system and the second operating system, or an operating system with a fast response speed, such as the first operating system.

[0320] For example, the service processing module selectively performs hardcore security isolation for the service system, i.e., divides important and sensitive services (that should not be exposed to users) into real-time services, and finally realizes offloading of these services from the non-real-time operating system to the real-time operating system, thereby achieving the effect of security protection. In this specification, 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, thereby achieving the goal of hardcore security protection. In this specification, sensitive services refer to security-related services such as user passwords, identity information, and other services related to the user's personal privacy.

[0321] In this specification, "hard core" refers to services being separated in terms of processor cores, i.e., sensitive services being assigned to the real-time operating system (since the cores occupied by the real-time operating system are different from those of the non-real-time operating system, this separation is considered core-based). Compared to non-real-time operating systems, real-time operating systems interact less frequently and to a lesser extent with users, making it difficult for users to "detect" sensitive data generated by services running on them. For higher-level applications, services such as user identity authentication management and security encryption are classified as critical sensitive services. The service management module forcibly separates these services into real-time services, allowing them to be run on the real-time operating system during subsequent dynamic hardware resource allocation, thereby achieving the effect of security isolation.

[0322] According to this embodiment, by assigning the assigned services containing confidential information to operating systems that have low frequency of user interaction, the system's services can be isolated with hardcore level security protection, improving the security of service execution. Optionally, the allocation result of resources corresponding to a set of allocated services may be determined by, but not limited to, the following manner:

[0323] Based on the allocation results of one set of allocation targets, the utilization status of the processing resources of the first operating system and the utilization status of the processing resources of the second operating system are combined to generate a mapping table of allocation target services and processor processing resources.

[0324] In this embodiment, the allocation result of the set of allocated services is used to indicate the correspondence between the allocation target services and the operating systems, and the execution target services allocated to an operating system are usually executed by the processing resources of the operating system. When the amount of services allocated to an operating system is too large and there are currently unallocated processing resources, the unallocated processing resources can also be allocated to the allocation target services allocated to the operating system. Therefore, based on the allocation result of the set of allocated targets, a mapping table between the allocation target services and the processor's processing resources can be generated by combining the processing resource usage status of the first operating system and the processing resource usage status of the second operating system, so as to indicate the processing resources allocated to each allocation target service.

[0325] In this specification, each assigned service has a mapping relationship with only one processor core, and the same processor core has 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., used to execute only one service. Different services assigned to the operating system can determine the time slices to occupy the same processor resource according to the allocation time, the response speed requirements of the service, or other methods.

[0326] For example, the dynamic resource allocation module dynamically adjusts processor resources based on the output of the service management module, forms a mapping table between different services and actual hardware resources, optimizes the allocation structure of different hardware resources in different operating systems, and achieves the goal of improving the utilization rate of hardware resources in the entire system. The dynamic resource allocation process can be managed and configured by software in the second operating system.

[0327] 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, the processor cores scheduled to the second operating system include core 2, core 3, and core 4, there are six services to be assigned, the real-time services are service 1 and service 2, and the non-real-time services are service 3 to service 6, and the six services are assigned corresponding processor cores, with core 1 assigned to service 1, core 5 assigned to service 2, core 2 assigned to service 3, core 3 assigned to service 4, core 4 assigned to service 5, and core 6 assigned to service 6.

[0328] According to this embodiment, the processing resources are dynamically allocated by combining the processing resource usage status of different operating systems based on the correspondence between services and operating systems, thereby ensuring the rationality of the allocation of processing resources. Alternatively, the processing resources of the processor can be allocated to the first operating system and the second operating system based on the operating system corresponding to each allocation target service and the resource allocation result in the following manner, but not limited thereto: based on the resource allocation result, if an unallocated processing resource among the processing resources of the processor has a corresponding allocation target service, the unallocated processing resource is allocated to the operating system to which the allocation target service corresponding to the unallocated processing resource is assigned.

[0329] When allocating processing resources, any unallocated processing resources among the processor's processing resources have a corresponding target service for allocation, i.e., when allocating an unallocated processing resource to a target service for allocation, the unallocated processing resource can be allocated to an operating system to which the target service for allocation corresponding to the unallocated processing resource has been allocated.

[0330] Optionally, the resource auto-adaptive scheduling module can complete an actual scheduling operation for the processing resources of the processor based on the result of the hardware resource dynamic allocation. The resource auto-adaptive scheduling module schedules some of the processor cores, such as the M cores in the core group 1, to execute services assigned to the first operating system, and schedules the remaining processor cores, such as the N cores in the core group 2, to execute services assigned to the second operating system.

[0331] Taking the aforementioned 8-core processor as an example, based on the service allocation result and resource allocation result, the unallocated core 4 can be allocated to the first operating system, and the unallocated cores 5 and 6 can be allocated to the Linux system. The entire scheduling process can be controlled by the second operating system. According to this embodiment, unallocated processing resources are scheduled to the corresponding operating systems based on the resource allocation results, so that the utilization rate of processor resources can be improved.

[0332] The first operating system can be controlled to enter a sleep state after execution, for example, the first operating system is controlled to go to sleep after execution. The end of execution of the first operating system may be the end of an execution cycle, the completion of processing a wake-up request, or the completion of processing a current operating service. After the first operating system goes to sleep, the second operating system can occupy the processor cores allocated to the first operating system, thereby improving resource utilization. For example, after the first operating system is controlled to go to sleep after execution, the second operating system is notified to allow the second operating system to occupy the processor cores used by the first operating system, and the second operating system is used to add the target processor cores used by the first operating system to a scheduling resource pool of the second operating system during the sleep period of the first operating system, where the scheduling resource pool includes other processors in the processor except for the target processor cores.

[0333] Optionally, in this embodiment, the manner of notifying the second operating system to occupy the processor core used by the first operating system may include, but is not limited to, sending an interrupt request to the second operating system, after the first operating system goes to sleep, notifying the second operating system to use the processor core used by the first operating system by sending an interrupt request to the second operating system, and the second operating system responds to the interrupt request and adds the target processor core used by the first operating system to a scheduling resource pool for scheduling and use.

[0334] In an exemplary embodiment, the operating service running on the second operating system can be monitored, but is not limited thereto. If an abnormal operating service is detected, the first operating system can take over the execution of the abnormal operating service, thereby preventing the abnormal execution of the operating service from affecting the entire process and improving the success rate and efficiency of service execution. For example, if the operating service running on the second operating system is monitored and it is detected that an abnormal operating service is running on the second operating system, the first operating system can take over the abnormal operating service.

[0335] Optionally, in this embodiment, the second operating system can be monitored by, but not limited to, the processor or the first operating system, and the monitored abnormal operating service (e.g., an operating service whose service thread is paused or frozen) can be inherited by the first operating system, or the monitored abnormal operating service can be assigned to an operating system in the multi-operating system that has a high compatibility with the abnormal operating service for inheritance.

[0336] Optionally, in this embodiment, the manner of monitoring the operating service running on the second operating system may include, but is not limited to, monitoring a heartbeat signal, monitoring a service log, etc. For example, if it is monitored that an abnormality log is generated, it is determined that the operating service has become abnormal. In an exemplary embodiment, the operating services running on the second operating system may be monitored by, but not limited to, receiving a heartbeat signal from each operating service running on the second operating system, and determining an operating service whose frequency of the heartbeat signal does not match the corresponding target frequency as an abnormal operating service.

[0337] Optionally, in this embodiment, each operating service running on the second operating system generates a heartbeat signal, and the heartbeat signals of different operating services have different frequencies. The heartbeat signal of each operating service running on the second operating system is connected to the monitoring side of the operating service, for example, the processor or the first operating system compares the frequency of the connected heartbeat signal with the target frequency corresponding to the operating service, and inherits the operating service whose heartbeat signal frequency does not match the corresponding target frequency as an abnormal operating service.

[0338] Alternatively, in this embodiment, whether the frequency of the heartbeat signal matches the corresponding target frequency may be determined by comparing whether they are a perfect match, but is not limited to this, and if they are a perfect match, it is determined that they match, and if they are not a perfect match, it is determined that they do not match. Alternatively, a certain error range may be given, but is not limited to this, and whether the frequency of the heartbeat signal matches may be determined by comparing whether it is within an error range of the target frequency, and if it is within the error range, it is determined that they match, and if it is not within the error range, it is determined that they do not match.

[0339] In an exemplary embodiment, after the first operating system takes over the abnormal operating service, the abnormal operating service in the second operating system can be restarted by, but not limited to, sending a restart command to the second operating system, and the restart command is used to indicate that the abnormal operating service should be restarted.

[0340] Optionally, in this embodiment, the restart command is used to indicate restarting the abnormal operating service, and after receiving the restart command, the second operating system initializes the abnormal operating service until it is executed again. Optionally, in this embodiment, after the abnormal operating service in the second operating system is executed again, the first operating system can return the inherited abnormal operating service to the second operating system, the first operating system can store the current execution site of the abnormal operating service in the shared memory and send an interrupt request to the second operating system, the second operating system can read the current execution site of the abnormal operating service from the shared memory and load the abnormal operating service to execute thereon, and finally, the abnormal operating service can continue to run, and the execution efficiency of the service is also improved.

[0341] 10 is a schematic diagram of a system abnormality monitoring process according to an embodiment of the present application, in which a first operating system executes a heartbeat signal of an operating service executed by a second operating system, and detects an abnormal operating service whose frequency of the heartbeat signal does not match the target frequency, the first operating system takes over and continues to run the abnormal operating service in the second operating system, and sends a restart command to the second operating system so that the second operating system can restart the abnormal operating service.

[0342] In an exemplary embodiment, the dual system can be started in the following manner, including but not limited to: boot to start the first operating system, and boot to start the second operating system. Optionally, in this embodiment, the first operating system is booted first, and then the second operating system is booted. The first operating system may be a simple operating system with a fast startup process, but is not limited thereto. During the startup process of the second operating system, the first operating system can execute an operating service that is highly urgent or an operating service that is useful for starting the second operating system, which ultimately improves the startup efficiency of the operating systems or the processing efficiency of the operating services.

[0343] Optionally, in this embodiment, the first operating system and the second operating system can be started in sequence, but are not limited to this; the first operating system can be started faster than the second operating system, but are not limited to this; the first operating system may have simpler conditions than the second operating system to start, but are not limited to this; the first operating system can be started first and then execute a service that meets the conditions required for the second operating system to start, or the service of the second operating system to start can be accelerated; and finally, the multi-system can start up and execute services quickly with high efficiency.

[0344] For example, after booting to start the first operating system, the first operating system performs services (e.g., services such as fan execution, parameter control, etc.) to control the chip's environmental parameters to meet the startup requirements of the second operating system, and ultimately the chip's environmental parameters can quickly realize the environment required for the startup and execution of the second operating system, thereby improving the startup efficiency and execution efficiency of the operating systems.

[0345] Alternatively, in this embodiment, the first operating system may be booted by, but not limited to, a boot program of the first operating system, and the second operating system may be booted by, but not limited to, a boot program of the second operating system, or both may be booted sequentially by the same boot loader program.

[0346] In an exemplary embodiment, the first operating system may be booted by, but is not limited to, the following method: the chip is powered on and started up, the processor wakes up the first processor core assigned to the first operating system, and the first processor core executes the boot program of the first operating system, booting the first operating system to start up.

[0347] Optionally, in this embodiment, the first processor core of the first operating system can be determined based on the processor cores in the processor on which the first operating system resides, but is not limited thereto, for example, the processor on which the first operating system resides may include, but is not limited to, multiple processor cores (processor core 0 to processor core N), and one or more processor cores (e.g., processor core 0) of the multiple processor cores can be assigned to the first operating system as the first processor core of the first operating system, but is not limited thereto.

[0348] Optionally, in this embodiment, the boot program of the first operating system can be stored in a specific memory space in the chip and used to specifically start the first operating system, but is not limited thereto. Optionally, in this embodiment, the first processor core of the above-mentioned first operating system may be configured to execute a boot program of the first operating system, but is not limited thereto, and can start the first operating system by executing the boot program of the first operating system, but is not limited thereto.

[0349] In an exemplary embodiment, the boot program of the first operating system can be executed on the first processor core to boot the startup of the first operating system in the following manner, but is not limited to the following: the first processor core executes a two-stage program loader, the boot program of the first operating system includes the two-stage program loader, and the two-stage program loader loads the first operating system. Optionally, in this embodiment, the boot program of the first operating system may include, but is not limited to, a second program loader, and the first processor core can load the first operating system by executing the second program loader (SPL).

[0350] In an exemplary embodiment, the second operating system may be booted by, but is not limited to, the following method: a two-stage program loader wakes up a second processor core assigned to the second operating system, and the second processor core executes the boot program of the second operating system to boot the second operating system.

[0351] Optionally, in this embodiment, the second processor core of the second operating system can be determined based on the processor core in the processor in which the second operating system resides, but is not limited thereto, for example, the processor in which the second operating system resides may include multiple processor cores (processor core 0 to processor core N), but is not limited thereto, and one or more processor cores (for example, processor core 1 to processor core N) of the multiple processor cores can be assigned to the second operating system as the second processor core of the second operating system, but is not limited thereto.

[0352] Optionally, in this embodiment, the second-stage program loader may wake up a second processor core of a second operating system, for example, but not limited to, after the second-stage program loader completes loading of the first operating system, the second-stage program loader may wake up a second processor core of the second operating system, or, during the process of using the second-stage program loader to load the first operating system, the second-stage program loader may wake up a second processor core of the second operating system, for example, but not limited to,

[0353] Optionally, in this embodiment, the second processor core can be booted to run a boot program of the second operating system to start the second operating system, but is not limited thereto. In an exemplary embodiment, the boot program of the second operating system can be executed on the second processor core to boot the startup of the second operating system in the following manner, but is not limited to the following: the second processor core executes a generic boot loader, the boot program of the second operating system includes a generic boot loader, and the generic boot loader loads the second operating system.

[0354] Optionally, in this embodiment, the second processor core can execute a generic boot loader to load the second operating system, but is not limited to this, and the generic boot loader may include, but is not limited to, U-Boot (Universal Boot Loader). In an exemplary embodiment, the two-stage program loader can be executed in the first processor core in the following manner, but is not limited to this: a boot storage device in the chip performs a clean boot test on the code of the two-stage program loader, and if the test result is normal, the first processor core executes the two-stage program loader.

[0355] Optionally, in this embodiment, the boot program of the operating system may include, but is not limited to, a second-stage program loader, and the boot program of the operating system may be used as the above-mentioned boot storage device, and the code of the second-stage program loader included in the boot program of the operating system may be verified by the boot storage device, but is not limited to this. For example, the second-stage program loader of the first operating system (the second-stage program loader may be, but is not limited to, an SPL) may be obtained based on the boot program of the first operating system (the boot program may be, but is not limited to, a BootROM), and the code of the second-stage program loader may be verified based on the boot storage device of the first operating system (the boot storage device may be, but is not limited to, a BootROM).

[0356] Alternatively, in this embodiment, the process in which the boot storage device performs a clean boot test on the code of the two-stage program loader may involve the boot storage device reading the code and identification code of the two-stage program loader, calculating the code of the two-stage program loader using a predetermined calculation method (e.g., hash calculation) to obtain a calculated value, and then comparing the calculated value with the read identification code. If the two match, the test result is normal; if the two do not match, the test result is abnormal, but this is not limited to this.

[0357] Optionally, in this embodiment, the second-stage program loader can perform a clean boot test on the generic boot loader code. The second-stage program loader reads the generic boot loader code and the identification code, and calculates the generic boot loader code using a predetermined calculation method (e.g., a hash calculation, which may be the same as or different from the calculation method used by the boot storage device to test the second-stage program loader) to obtain a calculated value. Then, the calculated value is compared with the read identification code. If the two match, the test result is normal; if the two do not match, the test result is abnormal. If the test result is normal, the generic boot loader loads the second operating system.

[0358] According to an exemplary embodiment, an example of a first operating system and a second operating system is provided. Taking a first processor core as CPU-0 and a second processor core as CPU-1 to CPU-N as an example, the first operating system and the second operating system can be started in the following manner, but not limited to the following: the chip is powered on and started up, the first processor core CPU-0 of the first operating system in the processor is woken up, and the first processor core CPU-0 is used to execute the boot program of the first operating system, which may be, but is not limited to a second-stage program loader, and a clean boot test is performed on the code of the second-stage program loader in a boot storage device (which may be, but is not limited to a BootROM) in the chip, and if the test result is normal, the first processor core executes the second-stage program loader (which may be, but is not limited to an SPL) to load the first operating system, and the second processor core wakes up the second processor cores CPU-1 to CPU-N of the second operating system, and a generic boot loader (which may be, but is not limited to a U-Boot) in the second processor core loads the second operating system.

[0359] Based on the description of the above embodiments, those skilled in the art can clearly understand that the above embodiments can be realized by software and a required general-purpose hardware platform, or of course by hardware, and in many cases, the former is a more preferred embodiment. Based on this understanding, the essence of the technical solution of the present application or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM / RAM, magnetic disk, optical disk) and includes a plurality of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, a network device, etc.) to execute the methods of various embodiments of the present application.

[0360] This embodiment further provides an embedded system for implementing the above-mentioned operating system execution control method. FIG. 11 is a schematic diagram 1 of an embedded system according to an embodiment of the present application. As shown in FIG. 11, the embedded system may include a chip and at least two operating systems, the chip including a processor 1102, a hardware controller 1104, a first bus 1106, and a second bus 1108, the bandwidth of the first bus 1106 is higher than the bandwidth of the second bus 1108, the first bus 1106 is configured in a multi-master / multi-slave mode, and the second bus 1108 is configured in a single-master / multi-slave mode, and the at least two operating systems are executed based on the processor 1102, the at least two operating systems communicate via the first bus 1106, and the at least two operating systems realize control over the hardware controller via the second bus 1108.

[0361] Here, the chip may be a BMC chip. The processor may be a multi-core processor. The hardware controller may be configured to control an external device connected to a corresponding external interface. The first bus may be configured in a multi-master / multi-slave mode and may be a bus required for communication between multiple processor cores of the processor, such as an AHB (Advanced High Performance Bus). The second bus may be configured in a single-master / multi-slave mode and may be a bus required when the processor controls the hardware controller, such as an APB (Advanced Peripheral Bus). The bandwidth of the first bus is higher than the bandwidth of the second bus.

[0362] The embedded system may include at least two operating systems, the at least two operating systems executing on a processor, the processor resources being dynamically allocated to the at least two operating systems, the processor processing resources including a processor core, the at least two operating systems communicating via a first bus, and the at least two operating systems providing control to a hardware controller via a second bus.

[0363] Optionally, the hardware controller may be one or more, and may include at least one of a controller corresponding to an external device of the chip, such as, but not limited to, an I2C, a Universal Serial Bus (USB), a UART, an Analog to Digital Converter (ADC), a Joint Test Action Group (JTAG), a Real Time Clock (RTC), a General Purpose Input / Output (GPIO), a Watch Dog Timer (WDT), a Virtual UART, a Super I / O, a Serial General Purpose Input / Output (SGPIO), a Pulse Width Modulation (PWM), a FanTach (adjusting the rotation speed of a fan), a Timer, a Platform Environment Control Interface (PECI), and a Mailbox, and may further include other types of controllers. The external interface may be one or more and may include, but is not limited to, an external interface corresponding to any of the controllers described above.

[0364] For example, an example of a BMC chip may be shown in FIG. 12, and the hardware of the BMC chip may include, but is not limited to, a SOC sub-module and a BMC out-of-band sub-module, and the SOC sub-module mainly includes an ARM core (ARM Core 1, ARM Core 2, ..., ARM Core X), and may include, but is not limited to, a DDR (Double Data Rate)4 controller (memory controller), a MAC (Media Access Control Address) controller (network controller), an SD (Secure Digital) Card / eMMC (Embedded Multi Media Card) controller (storage controller), a PCIe RC (Root Complex) controller, an SRAM (Static Random-Access Memory), and an SPI controller.

[0365] The cores and the controllers are connected to each other via a second bus, realizing interactions between the cores and the controllers. At the same time, the ARM cores are connected to the first bus (e.g., via an AXI (Advanced eXtensible Interface) bridge connection), and communication between the cores is realized through the first bus. The SOC submodule further realizes interconnection and communication between the first bus and the second bus (e.g., via a bridge conversion), thus providing a physical channel for the SOC submodule to access external devices on the second bus.

[0366] The DDR4 controller is connected to other components or devices via a DDR4 PHY (Physical Layer) interface, the MAC controller is connected to other components or devices via a (Reduced Gigabit Media Independent Interface), the SD card / eMMC controller is connected to other components or devices via an SD interface, and the PCIe RC controller is connected to other components or devices via a PCIe PHY interface.

[0367] The BMC out-of-band sub-module mainly includes controllers corresponding to chip external devices such as PWM, GPIO, FanTech (adjusting fan speed), mailbox, etc. These controllers can realize out-of-band management functions such as PECI communication to the BMC (e.g., simulating PECI using GPIO), fan adjustment control, etc. As can be seen from Figure 12, the BMC out-of-band sub-module can realize interaction with the SOC sub-module via a second bus, but is not limited to this.

[0368] The MC chip realizes interconnection between the ARM cores, storage units, and controller hardware resources within the chip via the first and second buses. The processor resource dynamic balancing scheduling mainly refers to scheduling of the ARM core resources of the BMC chip, and inter-core communication refers to communication between ARM cores. Take the Linux system preempting an RTOS system core as an example: the Linux system first sends an inter-core interrupt (interrupt number 9) from one of cores 2 through N to core 1 via the on-chip bus. In this case, if the RTOS system is idle, the preemption is permitted, and core 1 recovers the inter-core interrupt (interrupt number 10) via the first bus and releases the external device controller resource (e.g., PWM / PECI) currently mapped by core 1. The Linux system receives inter-core interrupt 10, initiates the preemption process, and adds core 1 to the Linux SMP scheduling. At the same time, it acquires the control process for the PWM / PECI external device and controls it via the second bus.

[0369] Meanwhile, the at least two operating systems include a first operating system and a second operating system, the chip loads a communication value to a first bus, and the first bus sends a communication signal including the communication value to a corresponding communication register of the second operating system, thereby realizing communication between the first operating system and the second operating system, and the communication value is used to indicate the content of the communication between the first operating system and the second operating system.

[0370] Meanwhile, the chip loads the control value to the second bus, and the second bus sends a control signal containing the control value to a corresponding register of the hardware controller to realize the control of the hardware controller by the operating system, and the control value is used to indicate the content of the control of the hardware controller by the operating system.

[0371] The operating system accesses the registers of each hardware controller to control the hardware controller (e.g., read operation and write operation). The operating system accesses the registers of each hardware controller by reading or writing to the address of the register of each hardware controller, but is not limited to this. These register addresses can be uniquely determined during chip design, but are not limited to this. For example, the operating system can achieve a specific function (e.g., the above-mentioned communication function or control value) simply by writing a specific value to a specific address (e.g., the above-mentioned communication register or register corresponding to the hardware controller). That is, different functions correspond to different control values, and the chip maintains a correspondence between the functions of the hardware controllers and the control values. For example, a control value of 00 indicates that the air conditioner accelerates in first gear, and a control value of 01 indicates that the air conditioner decelerates in first gear.

[0372] Interactions such as communication and control between the operating systems and between the operating systems and the hardware controllers can be performed via, but are not limited to, a bus. The read / write operations of the operating systems to the registers of the hardware controllers can be converted into control signals for the hardware controllers by the first bus (or the second bus). This conversion operation and the control process of the first bus (or the second bus) to the hardware controllers can be automatically implemented by hardware within the chip, but are not limited to this. This implementation process follows the rules of the bus. Here, the operating process of the first bus (or the second bus) can transmit and control physical signals related to the bus protocol, while transmitting valid data to each hardware controller via its physical data channel.

[0373] The first bus system may include, but is not limited to, three parts: a master module, a slave module, and an infrastructure. All transmissions across the first bus are initiated by the master module and responded to by the slave module. The infrastructure may include, but is not limited to, an arbiter, a multiplexer from the master module to the slave module, a multiplexer from the slave module to the master module, a decoder, a dummy slave module, and a dummy master module. Regarding the multi-master / multi-slave mode of the first bus, the master first sends a dispatch request to the arbiter, which determines when to grant the master access to the bus. After the master obtains permission, it sends data and control signals to the arbiter, which analyzes and determines the corresponding slave channel by address and then sends the request to the corresponding target side. Similarly, the decoder analyzes the response data and then returns it to the corresponding master. This multiplexing mechanism realizes many-to-many access.

[0374] In the single-master / multi-slave mode of the second bus, the second bus depends on the first bus system and can exchange services between bus systems via a bridge (bridge structure). In this case, the bridge is the master of the second bus, and other external devices (i.e., hardware controllers) are all slaves. A data request can only be sent from the master to the slave, and after receiving the request, the slave returns corresponding response data to the master. This process can realize one-to-many access, and the access does not involve arbitration and decoder analysis operations on the first bus.

[0375] In the above-described embedded system in which the first bus is configured in multi-master / multi-sleeve mode and the second bus is configured in single-master / multi-sleeve mode, the first bus in multi-master / multi-sleeve mode can use more complex logic circuits and bus protocols to complete communication between systems more efficiently, while the second bus in single-master / multi-sleeve mode can use simpler logic circuits and bus protocols to complete system control to the hardware controller, thereby reducing the structural complexity and power consumption of the entire embedded system. The arrangement and cooperation of multiple modes of the buses can further improve the performance of the embedded system.

[0376] In the above-mentioned embedded system, the first operating system and the second operating system are executed based on a processor, and communication between the operating systems and control of the hardware controller are realized by buses with different functions. Since the first operating system and the second operating system are both executed based on the same processor, it is possible to avoid an increase in hardware configuration and reduce system costs, and rationally utilize processor resources to support inter-system execution, thereby solving the technical problem of low operating system execution efficiency and achieving the technical effect of improving the operating system execution efficiency.

[0377] In an exemplary embodiment, the at least two operating systems include a first operating system and a second operating system, wherein the first operating system controls the target hardware controller to execute a target operating service based on the processor, the first operating system releases the target hardware controller via a second bus when the target operating service executes to a target service state, and the second operating system controls the target hardware controller to execute the target operating service via the second bus.

[0378] Optionally, in this embodiment, the target operating services run on the target hardware controller, and the first operating system controls the target hardware controller based on the processor, and the second operating system inherits the target operating services by inheriting the target hardware controller.

[0379] Optionally, in this embodiment, the process of taking over the target operating service is the same as in the previous embodiment, so the description thereof will be omitted here. When the target operating service reaches the target service state, the first operating system writes a specific value (i.e., the above control value) corresponding to the disabled target hardware controller into the register of the target hardware controller to achieve the purpose of disabling the target hardware controller. The specific value to be written is automatically loaded into the data channel of the second bus by the chip hardware, and finally, the first operating system realizes control over the hardware controller through the hardware method (i.e., realizes the release operation).

[0380] To achieve the purpose of the target hardware controller executing the target operating service, the second operating system writes the specific value corresponding to the target operating service (i.e., the above control value) into the register of the target hardware controller, and the specific value that needs to be written is automatically loaded into the data channel of the second bus by the chip hardware, and finally realizes the control of the hardware controller through the hardware method (i.e., realizes the execution of the target operating service).

[0381] In an exemplary embodiment, the second operating system sends a first interrupt request to the first operating system via a first bus, the first interrupt request is used to request to take over the target hardware controller, and the first operating system responds to the first interrupt request and releases the target hardware controller via the second bus, or the first operating system releases the target hardware controller via the second bus if the service attributes of the target operating service reach the target service attributes.

[0382] Optionally, in this embodiment, the second operating system can actively request to take over the target hardware controller in order to take over the target operating services, and the first operating system can also actively release the target hardware controller in order to release the target operating services.

[0383] Optionally, in this embodiment, the release and takeover process of the target hardware controller is the same as in the previous embodiment, so the description thereof will be omitted here. The second operating system writes a specific value (i.e., the above-mentioned communication value) corresponding to the first interrupt request into the interrupt register to realize sending the first interrupt request to the first operating system, and the specific value that needs to be written is automatically loaded into the data channel of the first bus by the chip hardware, and finally, the function of the interrupt request is realized in a hardware manner.

[0384] In an exemplary embodiment, the first operating system responds to the first interrupt request and determines whether the second operating system will take over the target hardware controller, and the first operating system releases the target hardware controller via the second bus if the second operating system will take over the target hardware controller.

[0385] Optionally, in this embodiment, the first operating system can determine whether the second operating system will take over the target hardware controller, and the determination process is the same as in the previous embodiment, so the description will be omitted here. In an exemplary embodiment, the first operating system sends a second interrupt request to the second operating system via the first bus if the second operating system does not take over the target hardware controller, the second interrupt request being used to indicate that the second operating system refuses to take over the target hardware controller.

[0386] Optionally, in this embodiment, the process in which the first operating system denies the second operating system from taking over the target hardware controller is the same as in the previous embodiment, and therefore, the description thereof will be omitted here. In an exemplary embodiment, the first operating system sends a third interrupt request to the second operating system, the third interrupt request is used to indicate that the first operating system has already released the target hardware controller, and the second operating system responds to the third interrupt request and controls the target hardware controller to execute a target operating service via the second bus.

[0387] Optionally, in this embodiment, the process by which the first operating system notifies the second operating system that the target hardware controller has been released is the same as in the previous embodiment, and therefore will not be described here. To achieve the purpose of the target hardware controller executing the target operating service, the second operating system writes the specific value corresponding to the target operating service (i.e., the above control value) into the register of the target hardware controller, and the specific value that needs to be written is automatically loaded into the data channel of the second bus by the chip hardware, and finally, the hardware controller is controlled by the hardware method.

[0388] In an exemplary embodiment, the at least two operating systems include a first operating system and a second operating system, the first operating system executing on a target processor core in the processor, the first operating system releasing the target processor core once it has executed to a target system state, and the second operating system adding the target processor core into a scheduling resource pool of the second operating system, the scheduling resource pool including the processor core in the processor assigned to the second operating system.

[0389] Optionally, in this embodiment, the process of at least two operating systems occupying the target processor core is the same as in the previous embodiment, and therefore, the description thereof will be omitted here. In an exemplary embodiment, the second operating system sends a fourth interrupt request to the first operating system via the first bus, the fourth interrupt request is used to request to occupy the target processor core, and the first operating system releases the target processor core in response to the fourth interrupt request, or the first operating system releases the target processor core if the system attributes reach the target system attributes.

[0390] Optionally, in this embodiment, the second operating system can actively preempt the target processor core, and the first operating system can also actively relinquish the target processor core. Optionally, in this embodiment, the process of preempting and releasing the target processor core is the same as in the previous embodiment, and therefore will not be described here.

[0391] In an exemplary embodiment, the first operating system responds to the fourth interrupt request and determines whether the second operating system occupies the target processor core, and the first operating system releases the target processor core if the second operating system occupies the target processor core. Optionally, in this embodiment, the first operating system can determine whether the second operating system occupies the target processor core, and the process is similar to that of the previous embodiment, so the description is omitted here.

[0392] In an exemplary embodiment, the first operating system sends a fifth interrupt request to the second operating system via the first bus when the second operating system does not occupy the target processor core, and the fifth interrupt request is used to indicate that the second operating system refuses to occupy the target processor core.

[0393] Optionally, in this embodiment, the process in which the first operating system denies the second operating system from occupying the target processor core is the same as in the previous embodiment, and therefore, the description thereof will be omitted here. In an exemplary embodiment, the first operating system sends a sixth interrupt request to the second operating system, the sixth interrupt request being used to indicate that the first operating system has already released the target processor core, and the second operating system adds the target processor core to its scheduling resource pool in response to the sixth interrupt request.

[0394] Optionally, in this embodiment, the process by which the first operating system notifies the second operating system that the target processor core has been released is the same as in the previous embodiment, and therefore will not be described here. In an exemplary embodiment, the at least two operating systems include a first operating system and a second operating system, a target processor core in the processor is added to a scheduling resource pool of the second operating system, the scheduling resource pool includes processor cores in the processor assigned to the second operating system, the second operating system releases the target processor core when the first operating system is woken up, and the first operating system executes based on the target processor core.

[0395] Optionally, in this embodiment, the process by which the first operating system wakes up and uses the target processor core is the same as in the previous embodiment, and therefore, the description thereof will be omitted here. In an exemplary embodiment, the second operating system releases the target processor core when the first operating system is woken up, or sends a seventh interrupt request to the second operating system when the first operating system is woken up, the seventh interrupt request being used to request that the second operating system release the target processor core, and the second operating system releases the target processor core in response to the seventh interrupt request.

[0396] Alternatively, in this embodiment, the second operating system actively releases the target processor core when the first operating system is woken up, or the first operating system actively requests that the second operating system release the target processor core, and since this process is similar to the previous embodiment, it will not be described here.

[0397] In an exemplary embodiment, the at least two operating systems include a first operating system and a second operating system, the chip further includes a memory space, the at least two operating systems control the memory space via a first bus, the first operating system generates service data in the process of being executed based on the processor, the first operating system stores the service data in the memory space via the first bus, and sends an eighth interrupt request to the second operating system via the first bus, the eighth interrupt request is used to request the second operating system to read the service data from the memory space, and the second operating system reads the service data from the memory space in response to the eighth interrupt request.

[0398] Optionally, in this embodiment, the first operating system and the second operating system can realize data interaction between the systems by transferring memory space and interrupt requests, but is not limited thereto, and the data interaction process between the systems is the same as in the previous embodiment, so a description thereof will be omitted here. To achieve the purpose of storing service data in the storage space, the first operating system writes a specific value to a specific address of the storage controller, and the specific value that needs to be written is automatically loaded into the data channel of the first bus by the chip hardware, and finally, the control and storage of the service data in the storage controller is realized in a hardware manner (i.e., the valid data is transmitted through the physical data channel).

[0399] In an example embodiment, the first operating system is executed on the processor periodically, or is executed on the processor in response to a received wake-up request, or is executed on the processor in response to a match between an operating service generated by the processor and the first operating system. Optionally, in this embodiment, the execution mechanism of the first operating system is the same as that of the previous embodiment, so the description is omitted here.

[0400] In an exemplary embodiment, the first operating system sleeps after execution, and the second operating system adds a target processor core used by the first operating system during the sleep period of the first operating system to a scheduling resource pool of the second operating system, the scheduling resource pool including other processors in the processor excluding the target processor core.

[0401] Optionally, in this embodiment, the process of refusing the second operating system to occupy the target processor core during the sleep period of the first operating system is the same as in the previous embodiment, so the description will be omitted here. In an exemplary embodiment, the at least two operating systems communicate via a communication protocol implemented by the first bus, or the at least two operating systems communicate via a communication hardware controller in the first bus, the second bus, and the hardware controller.

[0402] Optionally, in this embodiment, the at least two operating systems can communicate via a communication protocol implemented by the first bus, but is not limited thereto, that is, the communication between the cores can be realized by a software method, but is not limited thereto. Optionally, in this embodiment, at least two operating systems can communicate through a communication hardware controller in the first bus, the second bus, and the hardware controller, but is not limited thereto, that is, communication between cores can be realized by a hardware method, but is not limited thereto.

[0403] In an exemplary embodiment, the at least two operating systems communicate by sending interrupt requests between the processors via a first bus, or one of the at least two operating systems sends a system interrupt request to the first bus, which forwards the system interrupt request to a second bus, which sends the system interrupt request to a mailbox hardware module controlled by the communication hardware controller, which sends the system interrupt request to another of the at least two operating systems via the second bus and the first bus.

[0404] Optionally, in this embodiment, the preemption and release of processor resources and the interaction of service data between different operating systems can be completed by, but not limited to, an inter-core interrupt, such as an SGI (Software Generated Interrupt, an inter-core interrupt in a Linux system), and to request preemption or release of processing resources, one operating system sends a resource preemption request (e.g., a core preemption request) or a resource release request (e.g., a core release request) to another operating system by an IPI (Inter-Processor Interrupt, an inter-processor interrupt).

[0405] Optionally, in this embodiment, it can also be realized through a mailbox channel mailbox connected to a mailbox controller in the out-of-band sub-module, but is not limited thereto. In an exemplary embodiment, the at least two operating systems include a first operating system and a second operating system, the first operating system monitors operating services running on the second operating system via a first bus, and the first operating system takes over the abnormal operating service via the first bus if the operating system running on the second operating system has an abnormal operating service.

[0406] Optionally, in this embodiment, the process in which the first operating system monitors the operating service of the second operating system for abnormalities is the same as in the previous embodiment, and therefore, the description thereof will be omitted here. Each operating service of the second operating system writes a value to a specific address of the storage controller at a certain frequency, and the first operating system reads the specific address of the storage controller to achieve the purpose of monitoring the operating system running under the second operating system. The specific address of the storage controller that needs to be read is automatically loaded into the address channel of the first bus by the chip hardware, realizing the reading of the specific address of the storage controller through a hardware method, and the read value is returned to the first operating system through the data channel of the first bus through a hardware method, finally realizing monitoring by the operating service running under the second operating system.

[0407] The first operating system taking over the abnormal operating service may be to control a hardware controller corresponding to the abnormal operating service, and the first operating system writes a specific value into a register of the hardware controller of the abnormal operating service to control the hardware controller, and the specific value to be written is automatically loaded into the data channel of the first bus by the chip hardware, and finally, the control and abnormal service are taken over by the hardware controller in a hardware manner.

[0408] In an exemplary embodiment, a first operating system receives a heartbeat signal of an operating service running in a second operating system via a first bus, and the first operating system inherits an operating service whose frequency of the heartbeat signal via the first bus does not match a corresponding target frequency as an abnormal operating service.

[0409] Optionally, in this embodiment, the process of the first operating system monitoring the frequency of the heartbeat signal to monitor the operating service for abnormalities in the second operating system is the same as in the previous embodiment, so the description will be omitted here. The first operating system reads the value of a specific address of the storage controller to achieve the purpose of receiving the heartbeat signal of the operating service running in the second operating system, and the specific address of the storage controller that needs to be read is automatically loaded into the address channel of the first bus by the chip hardware, thereby realizing the reading of the specific address of the storage controller in a hardware manner, and the read value is returned to the first operating system through the data channel of the first bus in a hardware manner, finally realizing the receiving of the heartbeat signal of the operating service running in the second operating system.

[0410] In an exemplary embodiment, after the first operating system takes over the abnormal operating service, it sends a restart command to the second operating system via the first bus, and the restart command is used to indicate that the abnormal operating service should be restarted.

[0411] Optionally, in this embodiment, the process of restarting the abnormal operating service after the first operating system takes over the abnormal operating service in the second operating system is the same as in the previous embodiment, so the description will be omitted here. After taking over the abnormal operating service, the first operating system writes a specific value to a specific address of the storage controller to restart the abnormal operating service in the second operating system. The specific value to be written is automatically loaded into the data channel of the first bus by chip hardware, and the value at the specific address of the storage controller is updated in a hardware manner. The second operating system reads and analyzes the specific value, and then restarts the corresponding abnormal operating service.

[0412] In an exemplary embodiment, the chip further includes a storage device, wherein a startup boot module is stored in the storage device, and after powering on the chip, the startup boot module is executed to boot the startup of one of the at least two operating systems, and the startup boot module boots the startup of another of the at least two operating systems.

[0413] Optionally, in this embodiment, the boot process of the multi-operating system is the same as that in the previous embodiment, so the description thereof will be omitted here. In an exemplary embodiment, the at least two operating systems include a first operating system and a second operating system, the first operating system controls a target hardware controller to execute a target operating service based on the processor, the first operating system releases the target hardware controller via a second bus when the target operating service executes to a target service state, the second operating system controls the target hardware controller to execute the target operating service via the second bus, the first operating system executes based on a target processor core in the processor, the first operating system releases the target processor core when the first operating system executes to a target system state, and the second operating system The operating system adds the target processor core to a scheduling resource pool of the second operating system, the scheduling resource pool including the processor core assigned to the second operating system, the chip further includes a storage space, at least two operating systems control the storage space via a first bus, the first operating system generates service data in the process of being executed based on the processor, the first operating system stores the service data in the storage space via the first bus, and sends an eighth interrupt request to the second operating system via the first bus, the eighth interrupt request is used to request the second operating system to read the service data from the storage space, and the second operating system reads the service data from the storage space in response to the eighth interrupt request.

[0414] Optionally, in this embodiment, the operating systems can not only take over the hardware controller but also preempt the processor core, and the process is similar to the previous embodiment, so the description will be omitted here. According to this embodiment, there is further provided an embedded system configured to implement the above-mentioned operating system execution control method, which can be executed on the above-mentioned BMC chip, and which includes a first operating system, a second operating system, a controller, and a processor, wherein the first operating system and the second operating system are executed based on the processor, and the controller is configured to detect the execution state of the first operating system during the execution process and control the processor resources used by the first operating system based on the execution state.

[0415] In the above-mentioned embedded system, the first operating system and the second operating system are executed by a processor, and the controller detects the execution state of the first operating system during execution and controls the processor resources used by the first operating system based on the execution state. Because the first operating system and the second operating system are both executed by the same processor, it is possible to avoid increasing and deploying hardware and reduce system costs. Furthermore, it is possible to control the processor resources used during the execution of the operating systems and rationally utilize the processor resources to support inter-system execution, thereby solving the technical problem of low operating system execution efficiency and achieving the technical effect of improving the operating system execution efficiency.

[0416] In this embodiment, the first operating system and the second operating system may be similar to those in the previous embodiment, and the first operating system and the second operating system may be executed on a processor, and the controller may be software executing on the first operating system or the second operating system.

[0417] Optionally, in this embodiment, the processing logic of the controller may be located in the processor, but is not limited to this, and may further be located in the first operating system, or may be divided into a first control unit and a second control unit located in the first operating system and the second operating system, respectively, according to functions, but is not limited to this, ultimately realizing the control of processor resources between systems, the management of operating services, and service interaction, etc.

[0418] In an exemplary embodiment, the controller detects a service state of a target operating service of a first operating system executed on the processor, the execution state including a configuration including a service state; detects a system state of the first operating system, the execution state including a system state; and configures the first operating system as at least one of the configurations executed on the target processor core in the processor.

[0419] Optionally, in this embodiment, the detection of the service state and the system state by the controller is the same as in the previous embodiment, so the description will be omitted here. In an example embodiment, the controller is configured to release a target operating service when it detects that the service state is a target service state, the processor resources include the target operating service, and a second operating system is used to execute the target operating service, and / or the controller is configured to release a target processor core when it detects that the system state is a target system state, the processor resources include the target processor core, and the second operating system is used to add the target processor core to a scheduling resource pool of the second operating system, the scheduling resource pool including a processor core in the processor assigned to the second operating system.

[0420] Optionally, in this embodiment, the process of the controller controlling the target operating service and the process of releasing the target processor core are the same as those in the previous embodiment, and therefore, the description thereof will be omitted here. In an exemplary embodiment, the embedded system further includes a first service interaction thread executing in the first operating system and a second service interaction thread executing in the second operating system, and the controller is configured to determine that the service state is detected to be the target service state if the controller obtains a first interrupt request sent by the second service interaction thread to the first service interaction thread, the first interrupt request being used to request taking over the target operating service, or the controller is configured to determine that the service state is detected to be the target service state if the service attribute of the target operating service reaches the target service attribute.

[0421] Optionally, in this embodiment, the interaction process of the operating systems can be controlled by a service interaction thread respectively arranged in each operating system, but is not limited thereto. Optionally, in this embodiment, the service status detection process is the same as that in the previous embodiment, so the description is omitted here.

[0422] In an exemplary embodiment, the controller is configured to respond to the first interrupt request, determine whether the second operating system will take over the target operating service, and release the target operating service if the second operating system will take over the target operating service. Optionally, in this embodiment, the process by which the controller determines whether the second operating system takes over the target operating service is the same as in the previous embodiment, and therefore, the description thereof will be omitted here.

[0423] In an exemplary embodiment, the embedded system further includes a first service interaction thread executing in the first operating system and a second service interaction thread executing in the second operating system, wherein the first service interaction thread is used to send a second interrupt request to the second service interaction thread if the second operating system does not take over the target operating service, and the second interrupt request is used to indicate that the second operating system refuses to take over the target operating service.

[0424] Optionally, in this embodiment, the process of refusing to allow the second operating system to take over the target operating service is the same as in the previous embodiment, and therefore, the description thereof will be omitted here. In an exemplary embodiment, the embedded system further includes a first service interaction thread executing in a first operating system and a second service interaction thread executing in a second operating system, wherein the first service interaction thread is used to send a third interrupt request to the second service interaction thread, the third interrupt request is used to indicate that the target hardware controller has been released, and the second operating system is used to respond to the third interrupt request and control the target hardware controller to execute the target operating service.

[0425] Alternatively, in this embodiment, the process of notifying that the target hardware controller has already been released is the same as in the previous embodiment, and therefore will not be described here. In an exemplary embodiment, the embedded system further includes a first service interaction thread executing in the first operating system and a second service interaction thread executing in the second operating system, and the controller is configured to determine that the system state is detected to be the target system state if the controller obtains a fourth interrupt request sent by the second service interaction thread to the first service interaction thread, the fourth interrupt request being used to request occupancy of the target processor core, or the controller is configured to determine that the system state is detected to be the target system state if the system attribute of the first operating system reaches the target system attribute.

[0426] Optionally, in this embodiment, the system status detection process is the same as that in the previous embodiment, so the description is omitted here. In an exemplary embodiment, the controller is configured to respond to the fourth interrupt request, determine whether the second operating system occupies the target processor core, and release the target processor core if the second operating system occupies the target processor core.

[0427] Optionally, in this embodiment, the process by which the controller determines whether the second operating system occupies the target processor core is the same as in the previous embodiment, and therefore, the description thereof will be omitted here. In an exemplary embodiment, the embedded system further includes a first service interaction thread executing in the first operating system and a second service interaction thread executing in the second operating system, wherein the first service interaction thread is used to send a fifth interrupt request to the second service interaction thread if the second operating system does not occupy the target processor core, and the fifth interrupt request is used to indicate that the second operating system refuses to occupy the target processor core.

[0428] Optionally, in this embodiment, the process of refusing the second operating system to occupy the target processor core is the same as in the previous embodiment, and therefore, the description thereof will be omitted here. In an exemplary embodiment, the embedded system further includes a first service interaction thread executing in the first operating system and a second service interaction thread executing in the second operating system, the first service interaction thread being used to send a sixth interrupt request to the second service interaction thread, the sixth interrupt request being used to indicate that the first operating system has released the target processor core, and the second operating system being used to respond to the eighth interrupt request and add the target processor core to a scheduling resource pool.

[0429] Alternatively, in this embodiment, the process of notifying that the target processor core has already been released is the same as in the previous embodiment, and therefore will not be described here. In an exemplary embodiment, the controller is further configured to: detect whether a target processor core in the processor is already added to a scheduling resource pool of a second operating system and the target processor core will be released when the first operating system is woken up to run, the scheduling resource pool including the processor core assigned to the second operating system; and execute the first operating system based on the target processor core if it detects that the second operating system has already released the target processor core when the first operating system is woken up.

[0430] Alternatively, in this embodiment, the operating process when the first operating system is woken up is the same as in the previous embodiment, and therefore, a description thereof will be omitted here. In an exemplary embodiment, the embedded system further includes a first service interaction thread executing in the first operating system and a second service interaction thread executing in the second operating system, wherein the first service interaction thread is used to send a seventh interrupt request to the second service interaction thread if the target processor core is not released, the seventh interrupt request is used to request the second operating system to release the target processor core, and the second operating system is used to respond to the seventh interrupt request and release the target processor core.

[0431] Optionally, in this embodiment, the negotiation process for the second operating system to release the target processor core is the same as in the previous embodiment, so the description will be omitted here. In an exemplary embodiment, the embedded system further includes a first service interaction thread running in a first operating system and a second service interaction thread running in a second operating system, wherein the first service interaction thread obtains service data generated in the process of the first operating system being executed based on a processor, stores the service data in a memory space in the processor, and sends an eighth interrupt request to the second service interaction thread, wh...

Claims

1. An embedded system including a chip and at least two operating systems, the chip includes a processor, a hardware controller, a first bus, and a second bus, the bandwidth of the first bus being higher than the bandwidth of the second bus, the first bus being configured in a multi-master / multi-slave mode, and the second bus being configured in a single-master / multi-slave mode; the at least two operating systems are executed on the processor; the at least two operating systems communicate over the first bus; The embedded system, wherein the at least two operating systems implement control over a hardware controller via the second bus.

2. the at least two operating systems include a first operating system and a second operating system; The first operating system controls a target hardware controller to execute a target operating service based on the processor; the first operating system releases the target hardware controller via the second bus when the target operating service executes to a target service state; the second operating system controls the target hardware controller to execute the target operating service via the second bus; Preferably, the second operating system sends a first interrupt request to the first operating system via the first bus, the first interrupt request is used to request to take over a target hardware controller, and the first operating system responds to the first interrupt request and releases the target hardware controller via the second bus, or the first operating system releases the target hardware controller via the second bus when a service attribute of the target operating service reaches a target service attribute; Preferably, the first operating system determines whether the second operating system will take over the target hardware controller in response to the first interrupt request, and the first operating system releases the target hardware controller via the second bus if the second operating system will take over the target hardware controller; 2. The embedded system of claim 1, wherein the first operating system sends a second interrupt request to the second operating system via the first bus if the second operating system does not take over the target hardware controller, and the second interrupt request is used to indicate that the second operating system refuses to take over the target hardware controller.

3. the first operating system sends a third interrupt request to the second operating system, the third interrupt request being used to indicate that the first operating system has released the target hardware controller; 3. The embedded system according to claim 2, wherein the second operating system controls the target hardware controller to execute the target operating service via the second bus in response to the third interrupt request.

4. the at least two operating systems include a first operating system and a second operating system; the first operating system executes on a target processor core in the processor; the first operating system releases the target processor core once it has executed to the target system state; the second operating system adds the target processor core to a scheduling resource pool of the second operating system, the scheduling resource pool including processor cores in the processor assigned to the second operating system; Preferably, the second operating system sends a fourth interrupt request to the first operating system via the first bus, the fourth interrupt request is used to request to occupy the target processor core, and the first operating system releases the target processor core in response to the fourth interrupt request, or the first operating system releases the target processor core when system attributes reach target system attributes; Preferably, the first operating system determines whether the second operating system occupies the target processor core in response to the fourth interrupt request, and the first operating system releases the target processor core if the second operating system occupies the target processor core; Preferably, the first operating system sends a fifth interrupt request to the second operating system via the first bus when the second operating system does not occupy the target processor core, and the fifth interrupt request is used to indicate that the second operating system refuses to occupy the target processor core; Preferably, the first operating system sends a sixth interrupt request to the second operating system, the sixth interrupt request being used to indicate that the first operating system has already released the target processor core, and the second operating system adds the target processor core to the scheduling resource pool in response to the sixth interrupt request.

5. the at least two operating systems include a first operating system and a second operating system; a target processor core in the processor has already been added to a scheduling resource pool of the second operating system, the scheduling resource pool including processor cores assigned to the second operating system; the second operating system releases the target processor core when the first operating system is woken up; the first operating system executes on the target processor core; Preferably, the second operating system releases the target processor core when it detects that the first operating system is woken up, or sends a seventh interrupt request to the second operating system when the first operating system is woken up, the seventh interrupt request being used to request the second operating system to release the target processor core, and the second operating system releases the target processor core in response to the seventh interrupt request; Preferably, the chip further includes a storage space, and the at least two operating systems control the storage space via the first bus; the first operating system generates service data during execution based on the processor; the first operating system stores the service data in the storage space via the first bus; and sends an eighth interrupt request to the second operating system via the first bus, the eighth interrupt request being used to request the second operating system to read the service data from the storage space; the second operating system reads the service data from the storage space in response to the eighth interrupt request; Preferably, the first operating system is executed on the processor periodically, or in response to a received wake-up request, or in response to a match between a current operating service generated by the processor and the first operating system; Preferably, the first operating system sleeps after execution, and the second operating system adds a target processor core used by the first operating system to a scheduling resource pool of the second operating system during a sleep period of the first operating system, the scheduling resource pool including other processors in the processor except for the target processor core; Preferably, the first operating system monitors the operating services executed in the second operating system via the first bus, and when an abnormal operating service is found among the operating services executed in the second operating system, the first operating system takes over the abnormal operating service via the first bus; Preferably, the first operating system receives a heartbeat signal of an operating service executed in the second operating system via the first bus, and the first operating system takes over an operating service, the frequency of which does not match a corresponding target frequency, as the abnormal operating service via the first bus; Preferably, the first operating system, after taking over the abnormal operating service, sends a restart command to the second operating system through the first bus, and the restart command is used to indicate that the abnormal operating service should be restarted; Preferably, the first operating system controls a target hardware controller to execute a target operating service based on the processor, the first operating system releases the target hardware controller via the second bus when the target operating service executes to a target service state, the second operating system controls the target hardware controller to execute the target operating service via the second bus, the first operating system is executed based on a target processor core in the processor, the first operating system releases the target processor core when executed to a target system state, and the second operating system controls the target processor core to execute the second operating system's state. In addition to being in a scheduling resource pool, the scheduling resource pool includes a processor core in the processor assigned to the second operating system, the chip further includes a storage space, the at least two operating systems control the storage space via the first bus, the first operating system generates service data in the process of being executed based on the processor, the first operating system stores the service data in the storage space via the first bus, and sends an eighth interrupt request to the second operating system via the first bus, the eighth interrupt request is used to request the second operating system to read the service data from the storage space, and the second operating system reads the service data from the storage space in response to the eighth interrupt request; Preferably, the chip loads a communication value onto the first bus, and the first bus transmits a communication signal including the communication value to a corresponding communication register of the second operating system, thereby realizing communication between the first operating system and the second operating system, and the communication value is used to indicate the content of the communication between the first operating system and the second operating system.

6. the at least two operating systems communicate via a communication protocol implemented by the first bus; or the at least two operating systems communicate via a communication hardware controller in the first bus, the second bus, and the hardware controller; Preferably, the at least two operating systems communicate by sending an interrupt request between processors via the first bus, or one of the at least two operating systems sends a system interrupt request to the first bus, the first bus transfers the system interrupt request to the second bus, the second bus sends the system interrupt request to a mailbox hardware module controlled by the communication hardware controller, and the mailbox hardware module sends the system interrupt request to another one of the at least two operating systems via the second bus and the first bus; Preferably, the chip further includes a storage device, and a startup boot module is stored in the storage device. After the chip is powered on, the startup boot module is executed to boot the startup of one of the at least two operating systems, and the startup boot module boots the startup of another of the at least two operating systems. Preferably, the chip loads a control value onto the second bus, and the second bus sends a control signal including the control value to a corresponding register of the hardware controller, thereby realizing control of the hardware controller by the operating system, and the control value is used to indicate the content of control of the hardware controller by the operating system.

7. An embedded system including a first operating system, a second operating system, a controller, and a processor, wherein the first operating system and the second operating system are executed based on the processor; the controller is used to detect an execution state of the first operating system during execution, and to control processor resources used by the first operating system based on the execution state; The controller Detecting a service state of a target operating service of the first operating system executed on the processor, the execution state including the service state; and and detecting a system state of the first operating system, wherein the execution state includes the system state, and the first operating system is used for at least one of executing based on a target processor core in the processor.

8. Preferably, the controller is used to release the target operating service when it detects that the service state is a target service state, the processor resources include the target operating service, and the second operating system is used to execute the target operating service; and / or the controller is used to release the target processor core when it detects that the system state is a target system state, the processor resources include the target processor core, and the second operating system is used to add the target processor core to a scheduling resource pool of the second operating system, the scheduling resource pool including a processor core in the processor assigned to the second operating system; Preferably, the embedded system further includes a first service interaction thread running on the first operating system and a second service interaction thread running on the second operating system, and the controller is used to determine that the service state is detected to be the target service state if it receives a first interrupt request sent by the second service interaction thread to the first service interaction thread, the first interrupt request being used to request taking over the target operating service; or the controller is used to determine that the service state is detected to be the target service state if a service attribute of the target operating service reaches a target service attribute; Preferably, the controller is used to respond to the first interrupt request, determine whether the second operating system will take over the target operating service, and release the target operating service if the second operating system will take over the target operating service; Preferably, the embedded system further includes a first service interaction thread running in the first operating system and a second service interaction thread running in the second operating system, wherein the first service interaction thread is used to send a second interrupt request to the second service interaction thread if the second operating system does not take over the target operating service, and the second interrupt request is used to indicate that the second operating system refuses to take over the target operating service; Preferably, the embedded system further includes a first service interaction thread running on the first operating system and a second service interaction thread running on the second operating system, the first service interaction thread is used to send a third interrupt request to the second service interaction thread, the third interrupt request is used to indicate that a target hardware controller has been released, and the second operating system is used to control the target hardware controller to execute the target operating service in response to the third interrupt request; Preferably, the embedded system further includes a first service interaction thread running on the first operating system and a second service interaction thread running on the second operating system, and the controller is used to determine that the system state is detected to be the target system state when it receives a fourth interrupt request sent by the second service interaction thread to the first service interaction thread, the fourth interrupt request being used to request the target processor core to be occupied, or the controller is used to determine that the system state is detected to be the target system state when a system attribute of the first operating system reaches a target system attribute; Preferably, the controller is used to determine whether the second operating system occupies the target processor core in response to the fourth interrupt request, and to release the target processor core if the second operating system occupies the target processor core; Preferably, the embedded system further includes a first service interaction thread running on the first operating system and a second service interaction thread running on the second operating system, wherein the first service interaction thread is used to send a fifth interrupt request to the second service interaction thread when the second operating system does not occupy the target processor core, and the fifth interrupt request is used to indicate that the second operating system refuses to occupy the target processor core; Preferably, the embedded system further includes a first service interaction thread executing in the first operating system and a second service interaction thread executing in the second operating system, wherein the first service interaction thread is used to send a sixth interrupt request to the second service interaction thread, the sixth interrupt request is used to indicate that the first operating system has already released the target processor core, and the second operating system adds the target processor core to the scheduling resource pool in response to the sixth interrupt request; Preferably, the embedded system further includes a first service interaction thread executing in the first operating system and a second service interaction thread executing in the second operating system, wherein the first service interaction thread is used to acquire service data generated in the process of the first operating system being executed based on the processor, store the service data in a memory space in the processor, and send an eighth interrupt request to the second service interaction thread, the eighth interrupt request is used to request the second operating system to read the service data from the memory space, and the second operating system is used to read the service data from the memory space in response to the eighth interrupt request.

9. The controller further comprises: detecting whether a target processor core in the processor is already added to a scheduling resource pool of the second operating system and the target processor core is released when the first operating system is woken up to run, the scheduling resource pool including processor cores in the processor assigned to the second operating system; and the second operating system is used to execute the first operating system on the target processor core if it detects that the target processor core has already been released when the first operating system is woken up; Preferably, the embedded system further includes a first service interaction thread running in the first operating system and a second service interaction thread running in the second operating system, wherein the first service interaction thread is used to send a seventh interrupt request to the second service interaction thread when detecting that the target processor core is not released, the seventh interrupt request is used to request the second operating system to release the target processor core, and the second operating system is used to release the target processor core in response to the seventh interrupt request; Preferably, the controller is further used for controlling the first operating system to be executed periodically on the processor, or for controlling the first operating system to be executed on the processor in response to a received wake-up request, or for controlling the first operating system to be executed on the processor according to a compatibility between an operating service generated by the processor and the first operating system; Preferably, the controller is used to detect service information of a current operating service generated by the processor, and when detecting that the compatibility between the service information and the first operating system is higher than a compatibility threshold, control the first operating system to execute the current operating service based on the processor; Preferably, the controller is used to detect a target response speed and / or a target resource occupation amount of the current operating service, wherein the service information includes a target response speed and / or a resource occupation amount, the target response speed being a response speed that the current operating service requests the processor to provide, and the target resource occupation amount being an amount of resources that the current operating service requests the processor to provide, and when the target response speed is equal to or less than a speed threshold and / or the target resource occupation amount is equal to or less than an occupation threshold, the compatibility between the service information and the first operating system is higher than the compatibility threshold.

10. The controller further comprises: used to control the first operating system to sleep after execution; Preferably, the embedded system further includes a first service interaction thread running in the first operating system and a second service interaction thread running in the second operating system, the first service interaction thread being used to notify the second service interaction thread of permission to occupy a processor core used by the first operating system, and the second operating system being used to add a target processor core used by the first operating system during a sleep period of the first operating system to a scheduling resource pool of the second operating system, the scheduling resource pool including other processors in the processor excluding the target processor core.

11. the embedded system further includes a service inheritance thread executing in the first operating system; The service takeover thread monitors an operating service running on the second operating system, and if it is determined that the operating service running on the second operating system has an abnormal operating service, the service takeover thread is used to take over the abnormal operating service; Preferably, the service inheritance thread is used to receive a heartbeat signal of each operating service running in the second operating system, and determine an operating service whose frequency of the heartbeat signal does not match a corresponding target frequency as the abnormal operating service; Preferably, the service takeover thread is further used to send a restart command to the second operating system after taking over the abnormal operating service by the first operating system, and the restart command is used to indicate that the abnormal operating service should be restarted.

12. A method for controlling the execution of an operating system, comprising: detecting an execution state of a first operating system during execution, wherein the first operating system and the second operating system are executed based on a processor; controlling processor resources used by the first operating system based on the execution state; The step of detecting the execution state of the first operating system during the execution process includes: detecting a service state of a target operating service of the first operating system executed on the processor, the execution state including the service state; detecting a system state of the first operating system, the execution state including the system state, and the first operating system being executed based on a target processor core in the processor.

13. Preferably, the step of controlling processor resources used by the first operating system based on the execution state includes at least one of the following steps: if it is detected that the service state is a target service state, releasing the target operating service, the processor resources including the target operating service, and the second operating system is used to execute the target operating service; and if it is detected that the system state is a target system state, releasing the target processor core, the processor resources including the target processor core, and the second operating system is used to add the target processor core to a scheduling resource pool of the second operating system, the scheduling resource pool including processor cores in the processor assigned to the second operating system. Preferably, the method further comprises the steps of: determining that the service state is the target service state when the second operating system receives a first interrupt request sent to the first operating system, the first interrupt request being used to request taking over the target operating service; or determining that the service state is the target service state when a service attribute of the target operating service reaches a target service attribute; 13. The method of claim 12, wherein the step of releasing the target operating service when detecting that the service state is a target service state preferably includes the steps of: responding to the first interrupt request and determining whether the second operating system will take over the target operating service; and releasing the target hardware controller if the second operating system will take over the target hardware controller.

14. determining that the system state is the target system state when the second operating system receives a fourth interrupt request sent to the first operating system, the fourth interrupt request being used to request preemption of the target processor core; or If the system attributes of the first operating system reach the target system attributes, determining that the system state is the target system state is detected; Preferably, the method of claim 13, wherein the step of releasing the target processor core when detecting that the system state is a target system state includes the steps of determining whether the second operating system occupies the target processor core in response to the fourth interrupt request, and releasing the target processor core if the second operating system occupies the target processor core.

15. acquiring service data generated during the execution of the first operating system based on the processor; storing the service data in a storage space in the processor; sending an eighth interrupt request to the second operating system, the eighth interrupt request being used to request the second operating system to read the service data from the storage space, and the second operating system being used to read the service data from the storage space in response to the eighth interrupt request; Preferably, the method further includes the step of controlling the first operating system to be executed periodically based on the processor, or the step of controlling the first operating system to be executed based on the processor in response to a received wake-up request, or the step of controlling the first operating system to be executed based on the processor according to a compatibility between an operating service generated by the processor and the first operating system, Preferably, the step of controlling the first operating system to be executed based on the processor according to the compatibility between the operating service generated by the processor and the first operating system includes the steps of: detecting service information of a current operating service generated by the processor; and, if it is detected that the compatibility between the service information and the first operating system is higher than a compatibility threshold, controlling the first operating system to execute the current operating service based on the processor.

Images